Slashdot Mirror
Shirky: Given Enough Eyeballs, Are Features Shallow?
cshirky writes "A persistent criticism of open source is that it is more about copying features than creating new ones. While this criticism is overblown, the literature of open source is richer on the subject of debugging than design. I've written an article about Ben Hammersley's LazyWeb.org, wondering whether open source methods plus RSS distribution can do for feature requests what open source already does for bug fixes, namely parallelize the problem in ways not available to closed source development methods."
Most projects's site actually have room for user feedback and discussion, usually in the form of forums and/or mailing lists. The problem is that most users do not bother.
I develop and maintain a few small utilities on sf.net, and on roughly a thousand downloads all i have received are two bug reports. I am sure there are plenty of people that are looking for some specific features in my programs, but when they see they are not supported i suppose they just go "oh, well" and look elsewhere. It does not even cross their minds that they could tell me, or even enter a feature request in the tracker directly.
I guess we could try to lower the treshold a bit more (e.g. with big flashing "REQUEST A FEATURE" buttons on the main page), but eventually we cannot force users to do anything.
Pathman, Free (as in GPL) 3D Pac Man
... but not necessarily in areas suits would like. It is worth it to remember that Clay Shirky (who submitted this article) is a well-known VC, so from his viewpoint it is understandable that Python would not seem very innovative.
:-))
Open source uber-successes (innovation + usability): Apache, Sendmail, Perl, Python, PHP, emacs, vim (vim adds sufficiently to vi to justify it being innovative imho)
Open source successes (usability): Nautilus, Gnome, KDE, Evolution, the Linux kernel, GPG, glibc, Mozilla, OpenSSL, OpenSSH
Open source failures*: Directory Servers, Calendaring/Groupware servers, Office software, desktop publishing tools, graphics/prepress tools (the Gimp isn't a prepress tool), message queueing systems, heavy duty databases (despite SAP/DB).
I see a pattern here: Open source does pretty well at stock protocols that fulfil community/individual needs, it has even done reasonably well at end-user desktops (Nautilus being the crowing example -- if only the rest of the Linux desktop was that good!
Where we have not done well is about stuff that solves suits' needs: directory servers and groupware being a classic example.
I think we'll need some initiative from the industry now to fill these gaps, because it is not obvious that the community is going to scratch those itches anytime soon. Sun's open-sourcing StarOffice was great, OpenOffice has a chance of catching up with MSOffice in ~2 years. I sometimes wonder what would happen if IBM were to walk the talk and open up *any* of the following: DB/2, Domino+Notes, SmartSuite.
* yes, I am aware of OpenLDAP and OpenOffice, thank you.
(Sounds like a diagnosis of venereal disease, huh?)
The reward of scratching your *own* itch is obvious. The reward of scratching other peoples' itches, especially when they are not likely to even send you a "thank you", are more dubious.
This true, and I address it in the article. LazyWeb, at least as its worked in the past, addresses this in a fashion. Rather than recap, I'll post an excerpt here:
"The canonical motivation for open source developers is that they want to "scratch an itch." In this view, most open source software is written with the developer as the primary user, with any additional use seen as a valuable but secondary side-effect.
Sometimes, though, the itch a developer has is social: they want to write software other people will adopt. In this case, the advantage of the LazyWeb is not just that a new application or feature is described clearly, but that it is guaranteed to have at least one grateful user. Furthermore, LazyWeb etiquette involves publicizing any solution that does arise, meaning that the developer gets free public attention, even if only to a select group. If writing software that gets used in the wild is a motivation, acting on a LazyWeb description is in many ways a karmically optimal move."
"How many times have we heard open sourcers (including Linus) talk with pride about how they rightfully ignore user requests and just do their own thing?"
Zero times. Maybe Linus does talk about that, but let's face it: how many users know enough about the kernel to make a useful suggestion?
Now, compare it to more user-oriented projects like GNOME and KDE. Their community of users and developers always give good responses. Always. What's this cultural shift you're talking about?
For example, look all the thousands of man years that have gone into creating KDE (for example!). And what have they done? Essentially caught up to Microsoft.
Pardon me, but I beg to differ.
There is so much thing I'm missing from KDE when I'm back at my Win2K box at work... Konqueror (the file manager part, here) is so much featurefull than Explorer, I miss so much the virtual desktop, all the little things and settings that makes it easier to set the environnement work like I want it, etc.
So, I'm sorry, but I thing that there is already a lot of innovation going in KDE, Gnome and Linux (the kernel as much as the userland)
Is underestimation having the patience to go through the 3 major email clients that are all insensitive to slow ISP response and that fail by going into fibulation or by forcing one enter their password mindlessly time and time again when the 'software' had previously determined that it was going to retain the password?
The message that you fail to understand is that problems can be solved by well developed software - but by continually chasing a percieved market demand before determining how to implement the basic functionality well is pure folly. Sadly there is a lot of Open Software that falls into this category.
When it was necessary to deal with a lot of resource problems - like in the 70s - there was motivation to become involved with the application at a detailed level. With the quick hit capability to just 'use any object' anywhere you can find one, it's all too easy to crank out an app and never really get involved with the long term problems associated with the initial ease of development.
Apologies to those few who actually choose the long torterous path....