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."
Open Source development, as practiced by many Linux programmers, is not about pleasing the masses; it is about scratching an individual itch. As the ratio of users (ie. non-developers) to developers grows, there are bound to be more itches left unscratched.
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.
I do not mean this as a criticism, simply as an observation of how it really works. Open Source works because of individual need. You cannot expect it to do the same kind of thing as paid development (which also tends to include nasty, unpleasant bits).
We can help a little bit by giving non-developers the ability to participate in a meaningful way. Think translations, documentation, icons, loading screens, project supports, web support, whatever. A lot of this is in place today of course, but it may not be obvious to many. We may need to work on that - both making these things more obvious and 'sharing the fame' with the non-developers who help out in a meaningful way.
The criticism that Open Source is always copying is highly unfair. It is unfair because Open Source is in many ways still catching up to closed source. Many of the tools are growing stronger, but are still lagging a little bit behind. Once that gap is filled I expect the Open Source community will boldly go on to create new and innovative features. Until then... Well, there are only so many hours in a day.
We should always watch out for complacency. Something is not 'good enough' just because it works. We should instead take pride in making OUR source the very best possible. Paraphrasing Apple for a moment, we really *do* need to 'think different'. A copy of Windows is not likely to be 'best'. A copy of UNIX is not likely to be 'best' either.
If we want to evolve further, a point will come where we need to help other people onto our platform. These other people are not users perse, but rather creators of content like us. Unlike us, they create music, pictures, video, etc. We need to provide them with tools to do what *they* do best, and we need to educate them towards our mindset (Open), and they in turn will reward us by sharing *their* work.
Although this is not scratching a personal itch, the job can still be rewarding because these are generally nice and interesting people to work with.
Right, off the soapbox I go...
Excellently put. I agree completely.
On the other hand I also feel there are a few Open Source projects that, after years struggling meet the current state of the art in that particular type of application, have finally caught up with it and even surpassed it. A shining example of this would be Mozilla. For years it was a huge pile of bloat, barely useable. Now it is a stable and relatively fast browser, feature-complete by even the most rigid modern standards (at least on Windows, for linux there are still a few crucial plugins missing) and provides features that i sorely miss when, for one reason or the other, I end up using IE.
The point I'm trying to make is that much is dependent on maturity. Maturity of the code that makes up the application, but also of the team that develops it and of the community of users as a whole. And I have the distinct feeling that this maturity has been rapidly increasing that last few months.
Open Source development models do not prevent innovation. They merely provide unusual challenges. Only now are we starting to learn how to deal with those challenges effectively, especially in the arena of desktop/user software.
Pathman, Free (as in GPL) 3D Pac Man
That's odd. I started programming in the 70's and a lot of what we're working on now is exactly what we were dreaming of then. If anything, we'd have been pretty shocked and horrified to know that we'd still be working on them after <heavenly choir>the Year 2000<heavenly choir> (which once seemed as distant and hallowed, yet imminent and all-conquering as any Messiah or deity)
We cursed the limitations of our hardware and software then, but we worked with them because they were all we had. We'd spend weeks trying to trim a kilobyte or a few cycles out of a loop, not because we were virtuous (we weren't) but because we had to. Those whirring disks ran 24/7 to do crude payroll jobs that would run minutes on a desktop today.
It's been well documented, here and elsewhere, that most of our routine computing doesn't really save us much time, if any, but is simply chasing that elusive 0.1% "better output" (documents, biz data, presentations, etc.) A high school frosh today would be ashamed to hand in a report that looked like the most painstakingly prepared reports prepared for President Nixon. The addition of kerning hasn't vastly improved the content of a high school report.
Among the early computers I worked on was a triple CDC Cyber7600, which (in its initial configuration as a mere dual Cyber6600) exceeded the total computing capacity of the Soviet Union, but had a fraction of the CPU power, storage, etc. of my laptop so where's my accurate voice transcription, much less my intelligent editing and automated personal research assistant? Text recognition is just about usable for some major applications, but handwriting recognition is still barely usable
Yes, many are happy with their PDA hand-print inputs (or whatever) but it's a singing pig, we've learned not to expect Pavarotti; we're amazed it's workable at all. In ten years, we *may* achieve our 1975 dreams, and call the current state 'crap', not because of added features, but because 95% success (if one can even achieve it) *is* crap performance that we'd never accept in other daily technologies. Contrast this with, say word processing: load a PDA with 1979's AppleWriter ][ word processor, (a 190K package) and *truly competent* speech- , text- or handwriting recognition (pick one) and you'll have something that'll fly off the shelf at a kilobuck a pop, and make the cover of Time.
I don't know your age, but I assume you recall the 70's. If so, you'll recognize that these functions that we expected "any year now" back then (and are still waiting for) are just a handfull of hundreds of basic functions that are clunking along today. Our standards have dropped. We haven't even implemented the feature set we were promised then
With the Web (hypertext), wireless networking, huge storage, and a thousand other technologies, we're finally getting close to the Dynabook, which in 1974, we were promised "by 1984 at the latest". In 1994, a dynabook would still have been a total world-changing breakthrough. in 2004, it may finally be here. Added features are nothing compared to competent basic functionality. We've had programs that claim to do all this stuff for 25 years, but we're still waiting for solid human-free performance (which is largely the point of having a computer do the job) on our 1975 dreams
Before you say creeping featurism pulled us out of the Dark Ages, just give me reliable, competent worry-free versions of the stuff that was outlined in the magazines in the 70's -- software that was being written on mainframes, knowing the PC and laptop were coming, someday, and is still only in what we'd have call "commercially released beta" form 30 years later
See Von Hippel's papers here.
Enjoy,
Frank Ruscica
Adding features is easy. But I think often less is more. As an example, I compare Apple's iTunes software with MusicMatch Jukebox. I have both and I much prefer Apple's offering.
When you compare what's under the menus, MusicMatch looks like a mess. In comparison, iTunes seems clean and well designed. I think the ratio of useful features to features follows the 80-20 rule.
It's probably also the reason that I have stuck with Palm handhelds (actually a Handera) when the PocketPC's seemingly have much more to offer.
It is very difficult to make something simpler without losing any essential functionality. And of course what is essential is very subjective. But in the case of iTunes, I think Apple has done a very good job.
The worst you'll do is just ignore me. I've been waiting two years for one additional IDE drive to be added to the "quirks" list in pdc202xx.c of the Linux kernel. The architecture of the file has changed, so someone's looking at it, but no one has bothered to listen to my very simple request.
The work is done. My request was to have a specific line added; I sent the actual line, my reasoning, and my configuration to both the individual maintainer and the appropriate list. I verified that the patch works before submitting it. This would be 30 seconds of work for the maintainer, with very little risk to anything else.
I never received any response at all after multiple submissions from multiple accounts. Nothing.
This has prevented me from really going with Linux for two years. My options are:
- Add the line myself and recompile the kernel, after getting Linux up and running without the disk in question (in essence, spend 3+ hours installing, only to end up with a non-standard configuration (which some software refuses to install on)).
- Stop using my Ultra66 controller, losing that performance gain.
- Dump the problematic disk, and use a different one.
None of these options are attractive. I want to be able to just install Linux on my computer, as is, from a CD, without hassle. I still cannot do that, and no one is interested.This is my experience with the open source "process".
Good Software is not about more features! Good Software is about doing it safely, reliably and securely. Good software is about doing it well, not doing more.
Adding more features will only make the software worse. More bloat, less easy to understand and use, needs more hardware, and the documentation usually lags behind as well.
Writing software is an art form. It is an exercise in restraint and thinking before you do it, not in gluttony or adding more crap to already crappy software. The world is full of bad software with hundreds of little understood and under-documented features. I'd rather have small, well-documented and reliable software, thank you very much.
You know, one thing I've noticed is that many people tend to have a erroneous perception of the complexity of their jobs. I mean, after working (or studying) in a given field for a couple of years, you start forgetting how much you know and understand it. Many tasks seem utterly moronic to you even though a very bright specialist in another field would be completely helpless in front of them.
/. are proficient in CS/CE. Many threads on /. are totally obscure to me. Sometimes, I don't even know what is the subject. Yet, I'm often appalled by the complete lack of understanding of financial basics of the /. crowd. One example? The RIAA/P2P "debate". How many times have I read "reasonable" arguments like "A CD costs $1 to burn and the majors charge 20 bucks. They are overpricing!!!"? Yet a quick look on yahoo! finance will provide you with most majors' annual reports and you'll see that their operational profit (whoops, I do it myself, do you know what operational profit is?) represent around 5% of their sales. Does this mean that a CD costs $19 to be brought to the store? No, of course. First, the 20 bucks is not the major's revenue it's the retailer's revenue, and he keeps a margin. Then, there's sales tax in most states. Then there are fixed costs, investments that are not proportionnal to the number of CDs you sell. Then there's price elasticity: volume increases if prices decrease. Then there's competition etc... Sounds complex? It's not. For me, it's like 6th grade common sense. Yet, many educated and clever people (though unfamiliar with accounting/finance) suck at that.
The reasons are many. Language: read any doc in any field and you'll see countless acronyms, names, references that an outsider has no chance to understand. Mindset/methodology: in each field, there's a "best practice" way to present problems and solve them; and you get (grok) it only through experience. Information: every field (not only IT) is evolving quickly and most people don't know where to look for useful info; in many cases, they don't even realize that information is available.
This holds true in every field, not only scientific or technical fields. It's true in finance, sales, marketing, journalism, politics, you name it. That's the reason why it's so hard to make different kind of people to work together (like R&D and marketing). Very few people are able to reduce the level of previous expertise needed to (really) understand what they are talking about.
One illustration: My field is finance, i guess most people on
It's the same with programming. I want to code something, what should I do? Wow, lots of questions come to my mind. Which langage, which platform, which IDE, which compiler, which database? How do I use any of these things? What do these words really mean in the first place? What is their syntax? Should I write the whole thing or use an existing GUI? Which one? Does this question even make sense? I'm confident that I could do it eventually if I commit enough time. It's not worth it!!! It's far more efficient if I outsource that task to a tech-savvy person.
To conclude: No, everybody is not a developer. And even in the future, most people won't ever do something that you would call developping. The problem goes far beyond GUIs and user-friendliness. You just grossly under-estimate the amount of investment needed to develop even the simplest piece of code.
It would be nice to be sure of anything the way some people are of everything.