Following the recent complaints regarding the lack of proper market research in the F/OSS world, KDE users suggested paying money through Bugzilla to see their features/bugfixes done, a proposal that was denied by the core KDE developers. The lengthy discussion comes down to SuSE’s Waldo Bastian reply which illustrates once more the developer-centric nature of F/OSS (in contrast to the more user-centric nature of commercial products): “KDE will be able to sustain itself just fine without users, while it will not last a single day without developers. So when it comes to choosing between scaring away developers and scaring away users, the choice is rather easy actually.” (2nd reply)
Special Note: My article the other day that seemed to have created a huge controversy, was not about implementing every damn thing people wanted, but only implement things that are really needed by the majority and only when these things are not coming in contrast with the general direction of the project. For example, if someone was asking Gnome to implement a “KDE-alike control panel”, that should be rejected because that design is not Gnome’s way. But when someone says “make Shift+Delete to delete a file on Nautilus automatically”, that’s a legitimate feature request to be taken under consideration, and many users would expect it to be there already (that’s not my feature request btw).
It’s about market research, it’s about putting together things that really need to get done (that’s feedback filtered by a special team, not by the developers who are already under a lot of pressure). That’s what market research is about. It’s not about listen to every single idiot out there and his little or big feature request. So, don’t take my article out of context and don’t make it about myself or specific feature requests, because it is not so. It is about evolving a project to become better by taking in some well-structured user feedback in it. That’s all.
First, to all the numbskulls that replied without actually RingTFA, the quotation by Eugenia does NOT do the actual email justice. He is absolutely correct and his sentiments were expressed by myself and others in the previous threads on this subject. In fact, why are we still talking about this? If you have an issue with software you bought then take it up with whoever sold it to you (Novell, Red Hat, Sun). If you didn’t buy the software then why do you think anyone owes you anything? Gnome doesn’t owe you anything. KDE doesn’t owe you anything. GIMP doesn’t owe you anything. Aim your criticisms elsewhere because they go unheard in the developer community, as they should.
Eugenia’s biggest problem is that Gnome claims to be user-centric, yet the developers do not readily accept ideas from users. I think Havoc Pennington argued that point effectively when he said that people hanging out on Slashdot and OSNews are NOT average users and that Gnome’s ultimate goal is to be simple for the average user, not to satisfy the whim of every advanced user (aka Slashdot/OSNews readers).
Well … it seems Eugenia does not apply the same dilligence in her “journalism” that she requires from F/OSS developers. She seems to be quiet happy to post half truths, conveniently hiding the content of some of the mails and discussions that have lead to these so called ‘editorials’, as well as a tendency to overgeneralize and drawing her own conclusions, presenting them as facts, not to mention that she always knows best.
There has been a lot of ‘talk’ about the ‘responsibility’ of F/OSS developers to their users on these threads (quiet laughable most of it, not really worth relpying to any of it). Well, how about the responsibility of the media and press, when it comes to presenting news items and stories. A site with that much traffic should take a lot more care and responsibility for the information it disperses … osnews in that repect fails miserably.
The double standards and contradictions made me see osnews in a total new light … as an online journalist Eugenia has lost all credibility for me. Oh well … mod me down
Alot of noise has been made about this comment:
“KDE will be able to sustain itself just fine without users, while it will not last a single day without developers”
Don’t you people see that he’s right? the people who disagree with that comment are those who like to stare at market-shares and the like. too bad that free software are not written to gain “market-share”, it’s written because the people who write it like to do so! Seriously, the people who get their panties in a bunch because of that comment, are the same ones who feel that by merely using some software, they are somehow entitled to something! That the developers have to crawl at their feet and worship the ground the almighty user stands on. Well, it doesn’t quite work that way.
If I wrote some piece of software and I gave it away, I wouldn’t really care that how many people would use it. If it became really popular piece of software, great! If no-one wanted to use it, I wouldn’t mind. The software would be my creation for me. If some users asked me to implement a certain feature, I would consider it, but I wouldn’t feel a NEED to do it! I wouldn’t be obliged to do it in any shape or form!
What would happen in KDE had no users? It would still exists, and it would still get improved by the developers. KDE would not go away. But what would happen if KDE had no developers? No bug-fixes, no new features, no improvements, no nothing. KDE would stagnate and it would disappear. That is a fact. Users would abandon it. If KDE lost it’s user, it wouldn’t mean that KDE would disappear. But if KDE lost it’s developers, KDE would cease to be.
“Believe it or not, USERS are more important than DEVELOPERS.Without user feedback a dev can NOT develope selleble apps.”
Without DEVELOPERS there wouldn’t be any software for the USERS to give feedback on! So which is more important: the developer or the user?
And why the hell are you talking about “selling” apps? Since when did KDE-developers started selling their software? I for one got it for free!
Don’t waste your breath (-; … These so called ‘users’ have a slight distortion in their perception of reality, luckily they are a minority.
For haven’s sakes do you really believe NOVELL bought Suse because they have the best dvelopers writing S/W for fun and for free? C’mon, ask Waldo how much Suse pays him for his work.
This is exactly the kind of statement I was refering to. You obviously did not READ the email when you wrote this statement. Waldo specifially stated that if you complained to Suse and they thought it was a valid request then they would PAY people like Waldo to implement that feature. That’s how it works. You’re complaining TO the wrong people and ABOUT the wrong people. Like I said before, take it up with Novell/RedHat/Sun, or whoever.
That’s why the project is free… developers got the freedom to do whatever they want.
Wanna throw some bucks to KDE? Download the source code and hire your own people to fix the bugs/implement a feature (or do it yourself). Then submit a patch.
“KDE will be able to sustain itself just fine without users, while it will not last a single day without developers. So when it comes to choosing between scaring away developers and scaring away users, the choice is rather easy actually.”
It’s all semantics really, what does “sustain” mean? Plenty of software that’s abandoned by it’s developers continues to be used by people for years if they really like it and can’t find an alternative. Like the guy in the other thread recommending Winamp 2.8, or the 10,000s of people still using Office 97.
It’s all semantics really, what does “sustain” mean? Plenty of software that’s abandoned by it’s developers continues to be used by people for years if they really like it and can’t find an alternative. Like the guy in the other thread recommending Winamp 2.8, or the 10,000s of people still using Office 97.
I’m sure that “sustain” is not using an application that is no longer developed until, after some time in agony, it gets replaced by more modern alternatives.
Lotus Notes isn’t sustained by its current users. It’s agonizing/dead.
Just face it: developers can easily be users of their own apps. Users need quite some effort to be developers for themselves (and then they become developers). There’s no “semantics”, it’s just common sense. No developers -> no apps. No users -> no users.
Get thousands of enthusiasts to harass a free software developer for feature requests in the app he’s programming, see him leave the project for good and then think about what was a better situation: him on his own with silent users, or the users crying to the walls with an unmaintained app.
In a bakery, the bakers are getting paid to make bread per hour. In a car manufacturer the engineers are being paid for their efforts per hour. In the FOSS world this is clearly quite different.
……
I don’t think anyone has anything to complain about given that these developers are contributing their time to these projects. I can’t see many of the people complaining here going to work everyday for nothing, yet they seem to have that expectation for the FOSS developers.
I don’t buy this reasoning at all. FOSS software like linux and KDE used to be they way you describe it. Not any more, most of the main developers that work on these projects are now employed by some firm that has a stake in the general well being of the respective projects. So those developers are doing it for both “work” and “fun” and getting paid for it. So they are doing it as a part of thier job. Waldo does work for SUSE and has a stake in KDE remaining cutting edge and feature rich. If SUSE only cared for it’s corporate customers, like Waldo claims, then they wouldn’t release SUSE professional with cutting edge features for average users, who demand new features.
A true FOSS project in terms of developer involvement would liseten to it’s user base to become more popular and successful. Now that KDE, GNOME and Linux are now the big boys in the block the deverlopers have become arrogant to say the least.`
I am not advocating the bounty system, I am just surpirsed at the attitude of some of these developers.
As an Editor of material to be presented to the public, you must have noticed that writing is an artform.
The evidence depicted in this apologetic (news) item indicates poor initial thought processes in writing the first article.
Perhaps your intent was to create many responses regardless of content?
its “user base” is the people who make the project happen. people who use the software without paying back into it in any way arnt users, they are freeloaders. you know what, noone really has a problem with that… that is until they start making demands.
request, ask, plead, cajole, just dont demand. if you know a project is being funded by a corporation, then support that corporation. in return, they will pay the people they have on the payroll to please you. if you want to cut out the middle man, put up a bounty, or go on the lists and see if you can contract someone. if you actually want to be a part of the process, start contributing to the project, and your views will be better received.
jimmac has a great blog entry on the subject (someone in the comments on eugenias hissy fit linked to it)
blog link: http://jimmac.musichall.cz/weblog.php/Design/Speccing
how to get a feature implemented quickly
http://www.angelfire.com/mi/kevincharles/inkscape/ncwf.htm
how to be ignored
http://www.mail-archive.com/gimp-user%40lists.xcf.berkeley.edu/…
>>Red Hat’s Havoc Pennington & Novell’s Jimmac suggest that users write an analysis and test cases of a feature request the user wants to see implemented, because this way you might get the developer motivated to actually implement it. The problem I see with this is two fold:
a. Not many people have a clue how to write a test case or use Gimp/Photoshop to create a mockup to illustrate their point. They can only quickly describe what they need, and that’s that.
b. Normal users don’t use bugzilla. Only power users & developers do. Besides, no one likes spending time to register.
It’s the project itself that needs to do the right moves to reach its audience and take a pick on their problems, not the other way around.<<
a quote from Euginia’s article … says it all really (-;
Perhaps someone could investigate a giving system like Affero (http://www.affero.net/). Through it people can give a bit of money to their favorite cause, including free software. I don’t think it allows for a feature request ranking which would be nice to have.
I don’t see why people can’t create a feature request bounty system; dangle the money in front of anyone who wants to develop it; give the money to the winning patch; and then submit the patch to the maintainers. I suppose the patch could still be rejected, but at least it’s a start to a more user-oriented development system.
KDE will be able to sustain itself just fine without users, while it will not last a single day without developers. So when it comes to choosing between scaring away developers and scaring away users, the choice is rather easy actually.
And this, in a nutshell, is the exact arrogant, idiotic attitude that prevents F/OSS from living up to its potential. Until there is a massive cultural shift away from this kind of attitude and toward actually prioritizing users first, the commercial software development model will continue to win by leaps and bounds.
The fact that we have developers arguing that their product does not need users to survive sounds to me like Mutual Assured Destruction (MAD)!
This KDE guy should really remember what happens when developers try to impose their will on the general public… The whole “XFree86 vs. The World” debate did not fare well for XFree86.
This is not some Dilbert cartoon where some clueless idiot is running the marketing department at the expense of the engineers. MS Windows succeeded not only because of their strong arm tactics, but because they perform market research and see what consumers want and give it to them. If it comes in the shape of a $150 “update”, then so be it. At least the user got 10% of what he/she asked for.
If F/OSS developers “close” their source when it comes to features users might want, what is the difference then between them and the evil empire?
This is taken from a Microsoft developers blog:
” OSS and Deaf Developers?
I came across this rant about feature requests in Gnome. I have to confess a sense of siding with the OSS developers on this one.
The author of the editorial doesn’t get into full swing until she quotes the following statement from the Gnome web site:
A feature will be implemented if and only if there is a developer who wants to implement it.
She then extrapolates this to imply that no OSS developer is going to implement a feature request unless she has a personal use for that feature. This reasoning is both myopic and parochial.
The truth is, when you’re working on a product that’s intended for a wide variety of users, individual feature requests tend to be of limited value. That doesn’t mean I’m not interested in hearing your particular feature requests, because that’s not the point. Within the dross of anecdotal feature requests, there’s still the chance that one of them will turn out to be a gem. The truth is, however, that the vast majority of individual feature requests turn out to be bad ideas.
Perhaps an example will clarify the point. A long time ago, a user suggested that we bring back the “Style Area” feature. The feature was, and currently is, a preference in the “View” panel (you set the “width” of the style are). When that width is greater than 0, then Word displays the style of a paragraph to the left of the paragraph. This only works in “Normal” view.
That was the feature request, but it told me nothing about his problem that he was trying to solve. Well, it turns out that he had to review documents to see if they adhered to corporate style guidelines. In order to do this, he needed to be able to see both the style that’s applied to a paragraph and any direct formatting that’s been applied in addition to the style.
Well, in Word 2004, we shipped a feature that solves his high-level problem far more elegantly than the old style area solved it. This is in the “Style” area of the formatting palette. Word lists all the styles, and instances of styles plus various forms of direct formatting, that exist in your document. Each item in the list box is also a drop-down menu that provides the ability to select all instances of that list item’s combination of underlying style plus direct formatting.
With this feature, our user can now solve his particular problem by simply choosing “Select All” in the drop-down menu for combinations that don’t match his company’s style guidelines. He can then correct them all at once. If we’d just given him is direct feature request instead of trying to understand his real problem, he’d still be searching through these documents one paragraph at a time; a task that would have taken him hours to perform on a single document can now be completed in just a few minutes.
So, I think the OSNews editorial is misplaced. The difference between OSS and what we do isn’t in the extent to which we listen to what customers have to say. Rather, the really significant difference is the effort we put into understanding users’ high-level problems. That’s a very costly, and time-consuming effort. It’s not a job that hobbyist programmers, no matter how dedicated, can reasonably hope to accomplish.”
google for “oss site:blogs.msdn.com”
The 5th link, cached.
a. Not many people have a clue how to write a test case or use Gimp/Photoshop to create a mockup to illustrate their point. They can only quickly describe what they need, and that’s that.
so developers are not only supposed to be slave labor for anyone who chooses to download their work, they also have to figure out what those people want, even if they cant express it themselves? basically you (and eugenia) are saying non technical users should directly be a part of planning that is inapropriate for them, even if they cannot structure their requests in a useful manner.
b. Normal users don’t use bugzilla. Only power users & developers do. Besides, no one likes spending time to register.
bugzilla isnt rocket science, the only reason not to use it is if the users extreme lazyness is even greater then their own desire to see a stable product. opensource projects only work because people work together to make a good product.
basically, the end user wants the benefits of opensource with none of the responsability. then become irate when they are sent packing.
And this, in a nutshell, is the exact arrogant, idiotic attitude that prevents F/OSS from living up to its potential. Until there is a massive cultural shift away from this kind of attitude and toward actually prioritizing users first, the commercial software development model will continue to win by leaps and bounds.
That’s not even resembling logic – commercial software does not listen to it’s users. If they seriously did would Microsoft would have product activation oe EULA’s?
Free software seems to be doing bloody well from where I sit. The fact that a few buttons are in the wrong place or that you lack an option on a context menu are irritations, but they really have nothing to do with the quality of the software in question.
Everyone that’s saying “waaaaaah they need to listen to us more!” obviously hasn’t considered that there are a LOT of users, who are probably all asking for conflicting things. And ultimately the developers are doing it as a labour of love – if they don’t want to do something (even if that’s because they ‘don’t think it’s elegant’ or some such), they won’t. The beauty of free software is that if you don’t like it, YOU can make the change yourself.
Let’s look at a little metaphor…
Say there are a number of bakeries. One of them starts giving away it’s bread for free. It’s not too good at first, but over time they get better.
Now some of their loaves are better than their competitors. Some aren’t quite as good yet.
There are some individuals who want bread, but don’t want to pay for it. They ask the baker to make some changes to his recipes, which he refuses to do because he thinks it will make the bread worse. None of them have ever baked before in their lives, but they’re convinced they know better than him how to make his bread.
When he won’t change, they get all upset about this and tell him that he has to listen to them, because they’re the ones that are going to eat his bread, so they’re more important than him.
Obviously the baker continues to ignore them, because he wants to make the bread the way he thinks best.
Obviously it’s a bit of a silly metaphor, but I think it gets the point across – that when you step back a bit and look at what’s going on, the idea that you have some sort of possession of a project just because you use it, yet contribute nothing, is ridiculous.
There is a reason that FLOSS isn’t based on American Idol development… you end up with artists that are popular to people who like crap.
A lack of homogenization is in fact a winning strategy.
Could you imagine Outkast being born out of American Idol? They didn’t compromise, and they weren’t homogenized and they sold over 10 million copies of their last album.
Did people know they wanted that before they heard it? No… what they think they want is American idol and Barry Manilow.
Our diversity actually makes us stronger, because people can choose a distro that is more specifically suited for themselves. Just like I can choose Jazz over country or rock. If my only choice was one version of music, and I was locked in to that music forever… it would really suck… so people who are trying to sing that tune, realize that fregmentation will make more informed users in the end.
And also realize that American Idol development is for the birds, unless you thoroughly desire the rapid decline of civilization.
Direct link to above mentioned blog entry (URL seems to have changed).
http://blogs.msdn.com/rick_schaut/archive/2005/03/12/394480.aspx
I pretty much agree with this. A lot of feature requests are bad ideas after all.
This is an emotional issue. I think I’ll pass…
What’s all the fuzz about anyway?Most (real) developers devoted much of their social life to developing/their OS.They do that out of free will and in many cases very successfull.Of cource in an ideal world there would be a balanced user/developer interaction.Instead of debating about what isn’t relevant and making self fullfilling prophecies we should just continue with our creative passions.
A lot of remarks addressed at OSS dealt with OSS devs not listening to endusers in every way imaginable.One could only imagine were those remarks come from.In the propietary world they just make their products and try to make some profit.If someone doesn’t need their creation,well than he/she doesn’t buy it’s that simple.In (F)OSS it’s practically the same,if you don’t like it than don’t use it.If it all would be that bad there wouldn’t be an new KDE 3.4 for example.
It’s not the lack of user/dev interaction but the endless and often meaningless debates that are very contraproductive.
Oh well, I might as well jump into the fray. As a developer myself as well as a power user of a number of years, my opinion is that’s the height of arrogance to scare away the people that help make your software great. Developers can only do so much with their product — what makes it rock is user feedback. User feedback is CRITICAL to ensure a quality product.
But an even bigger issue for me is the hypocrisy here. People want to see F/OSS “take over the world” and destroy the Microsofts of the industry. But then when users have some legitimate complaints with popular F/OSS software, developers say, more or less, f*** you. It’s absurd, to say the least.
I know that some feature requests are stupid and developers need to use careful judgement and make their own decisions, but never, NEVER piss off your users. NEVER!!!
Jared
> People want to see F/OSS “take over the world”
More correctly, *users* want to see F/OSS “take over the world”. GNOME and KDE don’t care about world domination and neither promised to be “user focused” (see my previous post). They simply just want to create something useful for people who appreciate their work.
GNOME and KDE is trying the best they can to fulfill this goal, but “the best they can” doesn’t mean “dedicated resources to ensure that all requests are dealt with with a certain quality of service.” and it doesn’t mean “Send an email to any development mailing list. Developers enjoy wading through 100s of off-topic emails before they get to an actually on-topic post. Developers will also drop everything to ensure that all user requests will be looked it and users don’t have to worry about logging reports in Bugzilla ’cause we’ll do it for you.”
So who is a user to go to? How about the people who say that GNOME and KDE are user-focused and enterprise ready, namely Red Hat, SuSE, Ubuntu, and Linspire? If you want to complain, go to the appropriate forum for these distributes and follow the rules of the forum. *Distributions* are the place people should look for support, not GNOME and KDE.
This was mentioned several times in this thread, so apparently “Deafness” infects some OSNews readers too.
Hi there,
I realize that a big part of the quarrel is due to the fact that I haven’t been clear at explaining my intentions, in my original post.
I gave the impression that the KDE developer community should be forced to accept a feature when it has been paid for by users.
This was never my intention.
I also seem to have given the impression that, in some way, KDE policies of code quality and patch acceptance should change, to be dominated by users will.
Also this was never my intention.
I was simply trying to say that, if a developer accepts a task, then he must deliver the code he promised. Whether the code he produces is accepted into KDE is yet to be seen. No one is forcing KDE developers to do anything. His patch would be subject to the same policies and scrutiny that any patch currently is.
For all that, I am very sorry. Please accept my excuses. And, please, allow me to state, this time in a hopefully clear way, my intentions. Especially read points 2, 4, 5, and 12.
If you still feel system would threaten any of your interests, or freedoms, any at all, please let me know.
—-
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. At least for now.
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.
The 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.
—-
My best wishes to you all,
Maurizio
Only one problem I see with all of these arguing going on. I don’t see anyone here admitting the fact that developers are users too
Don’t they as users also have a say? Ahem.
very, very, very good idea. i suggested something similar in the midst of that other flame war last week, just didnt take the time to flesh it out as much as you have. this kind of thing would be extremely constructive, and i doubt the developers would have a problem with it.
considering it hasnt been implemented yet, this is just a guess, but the only flaw i can see is that it would depend on users putting their money where their mouth is.
i remember when i started hanging out on coding chans on the irc. in the message, they would put that if the answer could be gotten by a google “i feel lucky”, or is written in the api docs, or if the question was homework, dont ask or you will be kicked.
at first, i would help out people who would ask questions with an easy to find answer. after awhile, some of the regulars started giving me shit. when i asked why, they pointed out that my answering easy questions had opened the floodgate. there is a regular stream of idiocy, but when you actually start being helpful you will start becomming the teacher of billions of people who just want an answer, not to learn. so i ask “why dont you just tell them as much, and show them where to go if you dont want to help?” the answer was “we did, the first five thousand times. after that it got old. so now we flame them until they go away”(all this is paraphrasing of course)
developer attitudes can be downright hostile, but it is rarely without reason. im of the firm belief that if every user who complained about the hostility of the opensource community would read, understand, and follow ESRs excellent guidelines on how to ask smart questions, it would be a very different situation.
theres just this attitude that is guarenteed to piss people off. the expectation that you are owed free tech support by a community is unrealistic, uninformed, and offensive. if a community has to deal with it on a constant basis, is the reaction really that unexpected? i dont think so, but maybe thats just me.
that being said, you are correct in saying user feedback is vital to a project. user feedback isnt the issue here, its user demands. if i work on something in my free time that i choose to give to the benefit of everyone, it is downright disrespectful to start making demands on my free time.
Wow, I’m glad I never came onto THAT irc channel. The problem with telling users to RTFM and shut up is that often the problems they are having AREN’T in the F—– manual or the way things work are totally obtuse and unintuitive. The quality of F/OSS isn’t under fire here — the fact is that most commercial software also sucks.
The idea however is that F/OSS might suck less if developers were less intrested in just fooling around with code for their own amusement and were more interested in meeting the needs of regular Joe’s and Jane’s. I’m not accusing anyone in particular — in fact, I’m very impressed with open source software in general. My career DEPENDS on open source software. But whenever I see a certain type of smugness on the part of any developer community, I get nervous! Hopefully this is mostly just a big firestorm over nothing….
Cheers,
Jared
People should be glad for all the hard work and effort that Gnome and KDE (and other open source) developers put into their respective projects. Stop bitching and either code, write documentation and get involved or just plain well shut up.
If you don’t like the way KDE is managed, put your bloody money where your mouth is, fork it and see how long you last.
Dave
> If you don’t like the way KDE is managed, put your bloody
> money where your mouth is,
Ironically, this is what is being asked but is being denied 🙂
This issue is less black-and-white than such a polarized discussion would suggest.
At its core is the question: Does KDE want to increase its usability for non-technical users? My guess is yes – it’s one important component of competing with other GUIs – but I’m not a KDE developer so I don’t know. Assuming yes, though:
The attitude of “get involved, RTFM, or shut up” isn’t realistic if a project is to target non-technical user. They don’t want to do any of those things; they want to use their computer without fuss. So, OSS developers and projects have to make a choice: To what degree does one support users who aren’t developers or even power users? It’s perfectly reasonable, in a volunteer environment, for developers to want to work on what interests them; but if they also want to create a usable product for novices, someone has to put in the coding time to make that work.
If a project wants to support non-technical users, then it’s important to know what features and UI will work for those users. Developers, and even usability professionals, don’t always know based on their own intuitions. Asking users what features they want can be useful but also dangerous: Sometimes users don’t know what they want, or know they want _something_ but can’t quite identify it.
One important solution is to do usability testing: Set up a bunch of typical tasks; locate a bunch of typical users; and have them run through the tasks, often while talking about what they’re doing. There are plenty of usability testing labs with one-way mirrors and other fancy equipment, but usability testing can be done on the cheap with just a computer and a chair, and maybe a video camera and/or screen capture software. Take a look at Nielsen’s Usability Engineering book and his article on Guerilla HCI.
One great target for a usability test (albeit more of a GNOME than a KDE issue) is the spatial vs. browser navigation question. There is a raging debate about this, but no one seems to have done an empirical test. What’s more, the GNOME guys have implemented basically every possible permutation, so any combination of such features could be tested without much coding or any hand-waving.
Another possibility: Get some user interface designers involved to help design and choose features. UI designers won’t always be able to anticipate the results of a usability test but may have a clearer idea of what will and won’t work and be able to articulate it.
These methods can often be more helpful than listening to user feedback (though again, I do think the feedback is important too), and in fact may be more palatable to developers since they are more controlled processes and don’t involve answering to all the users at once.
One last thought: I wonder if, as far as user feedback goes, taking donations might be dangerous for two reasons: (1) The people who have money may not be the typical users or the best at identifying desirable features; and (2) I think users who donate will be mostly the more technical ones, simply by virtue of the fact that they’re aware of the OSS community. Thus the features that get donations may, again, not be those most beneficial to non-technical users.