first it was Eugenia's rant. or rather, rants... plural.
then Maurizio Colucci started a thread on kde-devel and kde-usability about setting up a way for users to vote with dollars. this caused a huge cascade of discussion. not all of it sane.
in fact, it was in this conversation that Waldo got outed and quoted by Eugenia. this annoyed me quite a bit at first. the whole discussion put my teeth on edge.
but why? i enjoy working with people who use software i write. if it weren't for the other people in the community, developers and users, i don't think i'd write software. i'd probably go off and draw lines in sand boxes instead. so what was it that sat funny?
and then it occurred to me while discussing these things with Manyoso on IRC why ...
when Eugenia complains about developers, she's expecting them to do something about it.
Marrizio's ideas also put the onus on the developers to provide a fix. but.... this is something that users want. when a software developer wants a program to do something, they usually scratch that itch and do something about it. so why is it that when the users have a problem with the social scene, they don't try and scratch their itch? why don't they try and hack the social system?
i bet if these users put their heads together they could create some (social) system that would coax and encourage developers in the direction they'd like. and no, bitching on the internet doesn't count as a social system.
so all you disgruntled users: scratch your itch. come up with some sort of system that works for you and invite the developers to it. make it inviting. make it worth our while and your while. you're the only ones who know what you want. so hack the system to get it.
Subscribe to:
Post Comments (Atom)
2 comments:
Maurizio's ideas also put the onus on the developers to provide a fix. but.... this is something that users want.
You are right. Users should get together and sponsor the creation of a structure they need.
The reason why I first tried to propose it to KDE developers is that integration of the donation system into KDE's bugzilla would have given it a sudden and big visibility, which could make the difference between failure and success.
Unfortunately, I made some wording mistake that gave the impression I was trying to harm the freedom of KDE developers to accept patches, or to produce high quality code. My bad.
However, I'll try to do something. Just to remind people, here is the idea.
1.
We supply a web site, a central place where any user can post a request for a
feature (or bug fix) that he needs. For example, he can request a patch to
KDE, or Gnome, or Xorg, which does a certain thing. Or he can request a full
application.
He only specifies the functionality, and nothing else (no money, no timeline).
2.
Those developers who need money visit the web site periodically, and look at
the requests.
On the other hand, developers who do not need money, or who do not like to be
told by users what to do, will simply ignore the web site and continue to do
what they have been doing so far: program for free and under their own guidance.
3.
If a developer freely decides to accept a task, then he posts a reply. This
reply is something like
I believe I can implement that feature for 3000$ in 5 months. Let
donations begin. Donations close in 20 days, on September 3.
Notice the developer defines one money sum (3000$) and two times (September
3, five months).
4.
When he posts the above reply, the developer is free to modify the
requirements, to rephrase them, or to specify them better. This can be useful
because, sometimes, users don't propose the best way to solve a problem.
Also, often their requests are too vague and fuzzy.
5.
Anyway, before posting the above reply, the developer had better be careful:
if the code he eventually produces were not accepted into KDE-Gnome-Xorg,
later he would receive negative ratings from the donators. This would make it
difficult for him to receive a donation next time. So, before he writes the
above offer, he had better make sure the KDE-Gnome-Xorg community is willing
to accept such a feature.
This problem, of course, does not exist if the request is about a standalone
application.
Also, the developer had better carefully choose the amount of money he asks
for: if he asks for too much, the threshold may not be reached in the given
time, and he will not be able to work at all. If he asks for too little, he
may have to stop development without delivering, which would make him receive
negative ratings.
6.
Donations begin (for that specific feature). Any user can donate freely, or
not donate at all.
Users decide whether to donate, and how much, according to the developer's
rating. Each developer has a "rating" which represents his "reputation". It
is a number that depends on how well he fulfilled previous tasks. He has been
voted directly from his previous donators, after he delivered. If he failed
to deliver what he promised, or did it badly, he will presumably have a low
reputation level, and will get fewer donations.
(Note: a consequence of the reputation system is that donations are specific
to a given developer. Donations are not only per-feature, but also
per-developer.)
7.
When a user donates (to that developer for that feature), the money is not
transferred immediately to the developer (because we still don't know if the
3000$ threshold will be reached).
Instead, when a user makes a donation, he just leaves the credit card number,
so the web site is sure he will keep his word and not withdraw his offer
later, on September 3.
8.
At any given time, before September 3, the web site shows a graph with the
overall donation. So users can quickly check how much money is needed for the
3000$ threshold to be reached.
9.
(optional) At any time, before September 3, the developer can choose to lower
the threshold, or to accept the current amount of money. This can be useful
in case some other developer is offering himself to do the same job for less.
A developer can also cancel his offer at any time, in which case no money
transfer happens, and he looses only a few reputation points.
10.
On September 3, two things can happen:
(A) The overall donation has not reached 3000$. This means that either
not enough people regard the feature as worthy of 3000$, or
that the time limit has been chosen poorly by the developer, not giving
people enough time to notice the feature.
In either case, the feature will not be implemented, and any activity for
the feature ends here.
Also, in this case no money is taken from the bank accounts of donators.
No money transfer at all has taken place.
(B) The overall donation has reached 3000$ (or it didn't but the developer
accepts nonetheless). In this case, the money is transferred to the
developer's bank account, and he starts coding. He will deliver in at
most five months (time he had previously chosen).
The money is not transferred all at once, to deter the developer from not
working or disappearing, after he got the money.
11.
During the five months of development, at any time, the developer must make
available the code developed so far. This is needed to prove he is actually
working. If he doesn't, the web site stops transferring the sum money
periodically to his bank account.
12.
After five months (time that the developer itself had chosen), the developer
publishes the final code he has produced.
This code may or may not be accepted into mainstream products, such as KDE,
Gnome, Xorg. The KDE-Gnome-Xorg communities must not change anything in their
policies of code quality, or their policies of code acceptance. They are not
forced to accept the patch. For those communities, everything continues
exactly as it was. The KDE-Gnome-Xorg developer community may not even know
that the patch was paid for, and in any case they don't need to care. All the
developer community will notice is a pleasant increase in participation from
unknown outsiders, which previously seemes to not exist.
13.
Donators give a rating to the developer. This rating will be based on
their personal level of satisfaction, in relation to what the developer promised.
In particular, if the software does not work well or was not accepted into
KDE, thee rating will presumably be bad, and the developer will find it
harder to get donations next time.
That process sounds pretty reasonable.
I can't say I've read up on the discussions about this issue. However, one thought that keeps nagging in the back of my mind when I read this sort of discussion is this: just because a feature is highly requested doesn't mean it should be implemented.
One example immediately comes to mind---and yes, I know it's cliche: GIMP's user interface. If someone implemented a system like this, how much money would be offered to make GIMP look/act exactly like Photoshop's interface? Probably a lot. And that probably means that it would finally get done, and people would stop whining about it.
However, I don't think that The GIMP's interface should be exactly like Photoshop (exclusively Photoshop on Windows, even). Photoshop's Windows interface is, for the most part, something of a hack to create a Mac-alike interface using the interfaces available on Windows, and it's not great. Yet, people have gotten used to it, so they rabidly insist that the GIMP must be the same way. Never mind that such an interface would probably be even more of a hack/bad design/inconsistent than it is on Windows.
I'm not arguing that The GIMP's interface is great as it is. However, turning it into a poor UI clone of Photoshop on Windows, which is itself a poor UI clone of Photoshop on Mac isn't exactly a great idea. At the very least, it would be better to clone the original Mac interface pieces that Adobe is trying to emulate on Windows (assuming Mac-Photoshop's interface is perfect), and at best, one could come up with an entirely new interface that's better than both.
My fear is that if voting on features were given actual monetary weight (that is, voting was given more actual force than it has on bugs.kde.org currently), such ill-thought-out but popular features would be more commonly accepted. Although I'm not a huge fan of the Gnome desktop, I think that they and Apple do have something of the right idea when they say, "the user doesn't always know what's best for him."
Sometimes popular features are popular because of the inertia of existing products, rather than because they are actually a good idea. Putting money on such features could make it harder to say "no" to them.
Of course, that's not to say that the entire idea of a pay-for-features system is bad, but it is one of the more nagging doubts I have.
Post a Comment