|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Friday, 5 May 2000||Author: Rob Bos|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
Failed Free Software Projects
For every successful free software project, the landscape is littered with projects that for some reason didn't get off the ground. Littered with one-shot wonders of ICQ clients, MP3 players, and hundreds of tiny, trivial programs that are replicated a hundred times over and never really accomplish anything useful by themselves.
Free software projects -- especially the small, unimportant ones -- dissipate for a variety of reasons. People lose interest in their pet program, or get completely overwhelmed with outside factors, or whose projects become largely irrelevant by the advent of larger and more promising projects.
Often the person who started them just did it to prove to himself that he could, or to reimplement an idea from scratch to gain an understanding of a particular problem. Once the problem is understood, often it is discarded. Enthusiasm is left by the wayside as the coder goes on to new projects and new challenges.
This is, however, a phenomenon not limited to free software. There exist a similar proportion of "shareware" and "freeware" projects that also similarly fall by the wayside. The difference between true free software projects and the private-code shareware projects so common elsewhere, however, is the simple fact that to anyone who finds those software packages useful, the source code is readily available to learn from, modify, and adapt to your own purposes.
Unlike shareware projects, in which people at least nominally hope to make a few measly dollars by nagging and harassing the end user, trivially small free software projects give you the source code and allow you far more freedom. To the typical Windows user, Linux can seem like nothing more than a huge bundle of shareware programs clustered around a central kernel -- but the fundamental difference, that of having source code available, is what makes the system so enormously useful.
Often, however, seriously large, important projects lose the interests of their maintainers and stagnate for a while in search of new maintainers and interested parties willing to give time to keep the thing updated. The GNU AIM, for instance, spent a fairly large amount of time in this limbo before the current team of people got fed up with waiting for the maintainer to get off his duff and make changes to the program.
Drivers often get into this state. Hardware companies will often release specifications for one version of their cards, or source code for their drivers, but then curiously not publicly release revisions to this code or the new specifications to updates of their hardware.
These are serious problems; however, the availability of source and the right to freely modify this code assures that if someone needs or wants this code to work badly enough, they will simply modify it themselves. The skills required for this sort of thing are rare, but it only has to be done once.
The beauty of this system is that no one has any real reason to complain incessantly about the development speed of free software; if you're not part of the solution, you're part of the problem. You aren't allowed to complain, so goes the custom, about how late a package revision or an update or a feature addition or a security feature doesn't quite meet your needs, unless you are actively coding in that feature yourself. Free software gives the end user the ability, the opportunity, and the encouragement they need to go in and make the changes they so desperately want themselves, with a little bit of learning -- or more realistically, to pay someone to do it. The source code is freely available; this means that if you want something changed, you can simply do it yourself. That change may not make it into the official versions of the software, but it will be there.
If projects get back on track, it is because they are useful to someone. If a project dies, it is because it is useful to no one. Furthermore, when free software projects dissipate, the expertise that created them necessarily moves on to other things. Often, it is a different software project, or a job that requires more spare time. Importantly, if that expertise moves on to a similar project and reinforces it with the skills that they acquired during their work on the original, failed project, the free software community is strengthened in an important respect as deadwood is trimmed off. If a free software project has no fundamental usefulness to anyone, it dies and its writers dissipate and tend to be absorbed in to similar projects, where their skills can be put immediately to use in new and interesting problems.
It isn't hard to argue that some free software projects simply don't accomplish anything useful -- that they are simply dead weight and no one uses them anyway. This could not be farther from the truth; those small, simple projects are microcosms, training grounds for huge numbers of future developers. The skills that are learned in these so-called "failures" are actually enormously successful to the free software community in the long run.
Some elitists would have you call these projects deadwood; all these empty, ultimately useless projects clutter up the landscape and make no significant contribution. Why don't we get rid of the new people, and their stupid projects, and just concentrate on producing real, good software for the here and now, goes the argument.
People who do this fall prey to a very easy assumption; the assumption that Linux can survive without new users, and that it will not stagnate without fresh blood and innovative ideas flowing in from all the newcomers. Many net-based communities have to face up to this question sooner or later -- there is a strong temptation to create and sustain a relatively small, closed community hostile to outsiders. Linux can not afford this luxury by its very nature; we must welcome newbies, welcome change and dynamic flux. We must welcome and revel in politics, enjoy conflict, enjoy the interplay of ideas and concepts engendered by new and fresh people with new, if unpopular or even stupid ideas. It is dealing with the new people, the unlooked-for viewpoint, the audacious or ridiculous or even stupid idea that gives communities vibrancy and long life.
Turning the Linux community into an elite would kill Linux by creating an atmosphere hostile to new people.
As such, every small project, every "trivial" ambition on the part of burgeoning free software developers should be encouraged; new people should be welcomed, and taught, and given the tools to build better tools. Challenge them, encourage them. Let them build what may be essentially useless, because in the future they will go on to build what is not useless. Learning is never pointless.
Rob Bos, firstname.lastname@example.org