by Matt Slot
The appeal of OSS is that it opens the software for portability and bug fixes by encouraging other people to roll up their sleeves and pitch in. This is a noble and optimistic goal, but sometimes it just doesn't play out that way. The biggest problem is that the Internet is an rather uneven talent pool. While there may be thousands of eyes reviewing software, there may be few people competent enough to contribute anything of value. Someone qualified to write or fix a highly technical piece of code is probably already doing so for plenty of money during the day. Instead, you often get email from someone who just started taking a class or picked up a book on the topic.
An OSS project, like any other project, is defined by the quality of its leadership. Simply making source code available isn't enough, because there may be no one ready to step in and spearhead development. A strong project takes strong leadership, someone to nurse the project through the hard times and make the tough decisions as the need arises. Linux didn't happen overnight or by accident.
Next, establish the coding standards to adhere to: naming conventions, calling conventions, utility libraries, and yes, even which programming language. One or a few programmers can quickly make these decisions and move on -- but so many new OSS projects suffer from "indecision by committee," where infighting over C vs. C++ takes days or weeks stall the project before it even starts. You should avoid new projects where every nitpick has to be hashed and rehashed on a public mailing list -- find or start a project with firm direction.
The framework for an OSS project should be written by one person, perhaps with support from a small group of insiders who are aware of the issues. The first 10,000 lines of code are generally these easiest and fastest, but are also the most critical. They must be consistent and well-organized. Only after the core features are ready should the project be divided into parts and outsourced for public participation.
The biggest bottleneck at this stage are the limited number of people who are familiar with the engine. While new programmers can work in relative isolation on pretty user interfaces or additional file formats, serious tasks like adding drivers or optimizations usually require the experienced hand of the original author. Even when these tasks can be handed off to a non-essential programmer, they often impact parts of the framework under active development, which need to be updated and can cause ripples of work for many people.
As the project grows, it will become layered like a pyramid. There may be hundreds of people at the bottom, contributing minor bug fixes and tweaking the build for portability. In the middle, you have the programmers with enough experience to take on signficant tasks that require technical savvy and some hands on experience. At the top, you have those few people responsible for the project's success. They dictate the overall direction, using their experience to administer and implement new features to the project as a whole.
Once software does what it was designed to do, its author may no longer be driven by the same needs that spurred the project in the first place. Minor changes and bug fixes are enough to satisfy the demands, or he simply has moved on to other projects. On the other hand, he may take the opportunity to "take the next step" -- aggressively pursuing new features or finding other projects to assimilate into the code base.
New technologies can challenge the status quo, starting with grass roots support and building to revolutionary status. Large leaps in progress usually sidestep accepted practice, and take an entirely new path. An OSS project may continue to make incremental improvements or it can make the leap and catch up to the competition. Even better, support for new features may be rolled in without compromising the old model, letting the user choose between them -- or using compatibility glue so that he can use both.
OSS projects, unlike commercial software projects, may suffer another fate. A programmer with a vision may add a new but controversial feature, which doesn't receive the blessing of the primary caretakers and isn't merged with the full code base. By its very nature open software encourages radical approaches, but it also allows these changes to be freely distributed -- diluting or even fracturing the market. This sort of division in the ranks may be interesting, useful, or harmful to the project as a whole -- and sometimes leads to heated debates or stark disagreement.
It seems that open source (sometimes called free) software, just like free speech, is both a blessing and a curse. OSS is a powerful ideal that carries the seeds of its own destruction. And its resurrection.
Matt Slot, Bitwise Operator