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."
I've been thinking about this for a while. One of the things that is so powerful about Open Source is that it pools the abilities of so many people. Unfortunately, the mechanisms currently in place in the Open Source world are great for pooling the skills, observations and ideas of programmers and geeks, but they're not good at all at pooling them from end users.
What i'd like to see is a kind of buzilla application completely focused on feedback from end-users. Somewhere where end users could make observations about OSS applications, and perhaps other users could vote or comment on them.
I brought a digital camera the other day. Before buying it, I could go to several web sites (for instance, amazon and cnet) and see lots of comments from other people who had used it. It was really useful to me, but of course could also be of use to the manufacturers themselves to get raw comments from end users. Open source software needs something like this so that developers can see first had what people like and dislike about their software.
They sit there, with their lightweight psychology, graphics design, philosophy, women's studies, physical education, etc degrees, and contemplate and measure cost/benefits of how the software should work. When appropriate, they poll users. They perform usability tests on actual users. They monitor how actual users use existing versions of the software in order to both spot common errors and figure out exactly what features are actually being used. They document what they do. They read books and articles on nominally the flimsiest of things, like "the psychological implications of color choice in menu design." Their feature requests sometimes border on the really difficult to implement, and sometimes quite simple.
Theirs is a full-time job. Even, if in your arrogance, you don't believe that it takes particular skill, at least grant them that it takes time to go and set up actual usability testing sessions and so forth.
The implication is that PROGRAMMERS DON'T DO DESIGN (at least, interface / features design). Or, at least, anything a programmer might do is reviewed and analyzed.
Needless to say, this is totally different than in oss/linux, where programers are really the only actors in the whole software development cycle. "design" is accomplished largely by copying other products, whcih inevitably leads to a lack of appreciation for the subtleties that make up for good interface and usability design.
Gimp and Xfig - my two favorite whipping boys, are examples number one and two of programs that nominally have the features, but in practice are painful to use compared to their closed-source equivalents (Photoshop and Visio).
The problem is as well is that there is no plausible way to get designers and similar 'soft skill' people into the OSS cycle today:
- culturally, the OSS 3l337 reject anybody without super-skills. don't even pretend that this isnt true.
- Technically, there are no mechanisms in place for this. CVS is about code. The development model is essentially about continuous 'patching' of the software rather than grand rearchitecting, which design considerations often require.
- economically, there's little hope of getting quality designers involved. Programmers barely get recognition in OSS (blowing to hell ESR's naive theories, btw). Who would care who designed what? How do you get street cred as a designer? I mean, it could happen, but it would take a pretty big mental shift.
Design = customer focus. OSS too often has this not. Profit drive causes customer focus. Alas.I've done as you suggest multiple times to no avail. The request is either not "sexy" enough or somehow not important enough. For instance, THE reason that openoffice/staroffice will NOT replace M$ Word or Wordperfect in academia/science is a total lack of ability to handle references and citations. Word and Wordperfect do this beautifully and professionally (good enough for submission and publication in professional journals) through their designed ability to work well with 3rd party apps like EndNote. I have made the request/statement to Stardivision, to Sun when they took it over (twice!), and to Openoffice.org several times over the years to no avail. Thus, these packages are mere toys for use by people who either plagerize (failing to cite references) or people who don't do serious research/writing and thus don't need to give attribution or support their ideas/claims. These tools are for letter writers and memo passers, not college students or researchers or professors.
I have also asked several groups to consider moving away from the should-be-extinct Motif interface to a modern, user friendly, SYSTEM friendly widget set (QT or Gtk). Motif IS UGLY, CLUNKY, AND NEEDS TO DIE. It has NO respect for screen size, insisting of shooting beyond your window borders such that you lose the ability (in some cases) of manipulating buttons and menus. If something happens such that you move the app interface beyond your window borders, you're screwed because it will happily reside in no mans land beyond the reach or your mouse cursor. Simple requests like this (FRIENDLY and REASONED requests, not rants) are ignored or quickly blown off. Why? Because developers don't understand nor care about endusers and app usability. As long as THEY can use the app just fine, tough shit for anyone else. My way or the highway.
This is the area that OSS cannot compete with commercial. In commercial software development, it REALLY DOES MATTER what the interface looks like (psychology is important) and principles of interface design are known and adhered to. They don't just willy-nilly toss together an interface and call it good enough.
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
We ALSO need to maintain the Unix philosphy of SMALL TOOLS THAT DO ONE THING WELL that you can combine - and perhaps develop a GUI paradigm for that, not throw the kitchen sink into every package.
Note prior to my comment - I am an "end user" (for the most part) not a developer. As such my comment may be ignorant about how things are working behind the scenes, whats possible with the existing techniques (but not actually showing up in the software...) etc. etc. etc. Anyway, on with the comment...
Amen! It seems once you start using a GUI there is a tendancy to build monolithic programs that do *everything* themselves even though all the other programs also do many of those same things. But I don't see why this has to be that way. It seems you could have some standards that organise and identify independent components (plug-ins?) by function. Perhpas something like mime types that has both a general and specific classification - like "text/spelling" for a spell checker/dictionary or "text/search" for a gui for grep etc.) Application developers would figure out which classes of plug-ins make sense to load into their program and where the particular classes and sub-classes show up in their gui (rather than putting them all under "services" like OS X).
From an end-users perspective it is *bad* that there are slightly different tools with slightly different capablities doing much the same thing from app to app to app. Every word processor or text editor needs/has a "search" function - why don't they all use the same one implemented in the same way and why can't that way be determined by me, the user, by installing the search utility of my choice that would be used by every program that needs one. For that matter lots of applications need text-editting (or word-processing, or image editing etc.) themselves - why don't they all use the same full featured application as a component rather than having their own lame version of that functionality or forcing me to launch another application; do what I need to do; copy or save the result and import/paste it into where I need it. If you really did this right there would even really be distinct "apps" you'd open a document and the components for any type(s) of data in that doc would load so you could do whatever needed to be done with whatever was in the document.
It never became a reality (at least for the end user) but it seems that Apple was working on something like this with OpenDoc.