Re: [ox-en] "open source model permits elitism"
- From: "Nadav Har'El" <nyh math.technion.ac.il>
- Date: Wed, 29 Mar 2006 11:32:05 +0200
It has been nice to see how in the last few years, free software (aka Open
Source software) has become a fad, with everyone thinking they understand
this phenomenon. But I think that what some of these people have been doing
is to explain how free software fits in their *old view* of the software
world, rather than really trying to understand the new view.
For example, in that article you quoted from the Economist:
On Sat, Mar 25, 2006, Geert Lovink wrote about "[ox-en] "open source model permits elitism"":
Open, But Not as Usual
Economist (03/18/06) Vol. 378, No. 8489, P. 73 *
The limitations of the open-source approach are becoming evident as
the methodology branches out of the software sector and into other
...
through continuous self-policing. Indeed, only a few hundred of the
approximately 130,000 open-source projects on SourceForge.net are
active because the others are unable to accommodate open source's
My understanding (based on 15 years of actually using free software, and
about 6 years of helping write it) is different.
What actually happens is that free software is a process of evolution, much
like Darwin's familiar theory: New free software projects are created all the
time; Successul projects grow, get more users and/or more developers, while
projects that are not well-adapted (do not fit the needs of users and
developers wel) die, i.e., get abandoned on source-forge. Like in biological
evolution, improvements can be done on any successful free software project
to create even more successful software, either in the form of gradual
changes, or of an abrupt "fork".
So the fact that there are many dead, cul-de-sac, open-source projects is
not a "limitation" that has just now "becoming evident", but rather a
direct consequence of how free software works, and actually is a benefit of
this model: good projects do not die, but rather evolve, while "bad"
(mal-adapted) projects die off. The proprietary software world is also
filled with dead projects (software that was never successful, or was once
successful and now dead), but with proprietary software, the death of
software often doesn't happen because of its intrinsic qualities, but
often because of other reasons, say, because a company goes bankrupt and
nobody else can take over its proprietary code and continue working on it.
those of the companies they are trying to surpass, and most projects'
core component is a close-knit group rather than a wide-ranging
community. Many open-source initiatives have set up a formal and
Again, I think that the journalist, who is probably used to the corporate
world and to very large software products, is trying to squeeze free software
into the same niche. Consider a Linux distribution, for example. It contains
software written by literally thousands of different people. These people
are by no means a "close-knit group", and are spread all over the world and
share almost nothing in common (except interest in free software, I guess).
This can happen because a single person, or a very small group, can devote
themselves to a very narrow aspect of the entire problem and solve it. For
example, let's say a group of two developped a clock application (a la xclock).
A dozen other individuals or groups can do the same, each perfecting their
own clock application. Finally, the end-users (or more realistically, the
distribution makers) can choose the one they like best, and make similar
choices for a thousand other components of the system. So the end result is
that you get a system written by thousands of programmers who are anything
but close-knit, yet individual projects remain small and look to detractors
like "close-knit", "small" and "elitistic".
Someone might reply that what I've just said only applies to small meaningless
software (such as a clock) and not to large, important, software (such as a
word processor or browser or whatever). I beg to differ. Huge, monolithic
software projects is not a "fact of life", but rather a choice made by some
projects (e.g., OpenOffice and Mozilla), often projects that started their
life as proprietary software (in this case StarOffice and Netscape). Other
projects choose to remain very componentized and distributed, and continue
to work in small groups. A good example is X-Windows, in which individual
components (the server, Window manager, basic libraries, widget libraries,
etc.) have always been develop by different groups with only small amount
of interaction. Another good example is Apache web server, which while it
(now) has some centralized infrastructure, tries to keep the seperation
between the different components, so that the small group who are crazy
about (say) SSL and HTTPS, can work on their own "close-knit" group while
people interested in (say) caching can work on that. Similar seperation
happens in the development of the Linux kernel, where a very small close-knit
group can be invloved in writing a single piece of the entire kernel (say,
one driver or one feature).
Noveck. The model permits elitism in the acceptance of contributions,
despite the egalitarian system of contribution. There is also
This is one way to put it.
But there's another way to think about it: A free software project is not
just "lines of code", but rather "lines of code"+"development process".
Just like the project's lines of code can evolve or fork, so can its
development process. A project with a bad development process (say, good
patches are not applied) can "lose" the "evolutionary contest" with other
competing projects. A project can also be forked off, with the fork employing
different development principles. This sort of "fork because I don't agree
with the original management" already happened many times, in some very
important projects - for example, with X Windows (XFree86 vs Xorg),
BSD (Free/Open/NetBSD), Apache (forking from NCSA's server),
Firefox (from Mozilla), Inkscape (forked from Sodipodi), *twm (forked off
from the original Twm window manager), OpenMosix (forked from Mosix),
and I'm sure I could come up with many more examples if I spend more
time thinking.
speculation that open source's ability to sustain its innovation as
well as the enthusiasm of contributors is limited.
Again, just like in biological evolution, "innovation" often can happen
as of a fork or a branch into new habitat, not just as slow improvements on
an existing projects inside its old habitat. Just as a random example:
I just installed Fedora Core 5, and I noticed that after more than a decade
that the "locate" command (used to quickly search for files on your system)
hasn't changed, two new things appeared:
* "mlocate", which does the same thing as the old locate but uses much
less time to update its database, by using an innovative algorithm.
* "beagle", a new full desktop search (similar to Google Desktop) application
Neither of these applications depended on people sending patches to the
original author of the "locate" command. The original "locate"'s source code
was available to build on, but when innovations came along, the innovators
did not have to confine themselves to the development process of the original
"locate" if they didn't want to (and in this case, they didn't want to).
--
Nadav Har'El | Wednesday, Mar 29 2006, 29 Adar 5766
nyh math.technion.ac.il |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |If you're looking for a helping hand,
http://nadav.harel.org.il |look first at the end of your arm.
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de