The Mozilla Project is routinely cited as one of the great success stories in open source software development. It's easy to forget that six years ago the project nearly became the greatest failure of the open source development process, and it's instructive to remember how and why the project nearly failed.
The question and answer session after their announcement went quickly from efusive enthusiasm to akward silence. Questions such as:
Now, you have to understand the makeup of the SVLUG audience. Typical meetings had 200-300 people in attendance, and on this night there were over 500. Amongst the audience were creators of or contributors to such noteworthy open source projects as Sendmail, Bind, Berkeley DB, Tcl/Tk, XFree86, and numerous Linux kernel modules. This was an audience that knew something about managing and running an open source project. And the complete lack of direction we were hearing from Netscape astonished us.
The reason for this stagnation was readily apparent to anyone who examined the source code. The Netscape browser had been built in a fashion all too typical of software development in Silicon Valley. A core functioning code base had suddenly had to scale far beyond its original design, and additional features were added in a hurry by Netscape's engineers or simply licensed wholesale from third parties, all to meet release schedules that had no basis in engineering reality. The result was the sort of code that developers refer to variously as "crufty", "kludgy", or "an ugly hack".
The open source version was made worse by the need to rip out all the code licensed from third parties who were unwilling to open source their technology. In some cases, such as SSL, the initial open source release simply lacked the functionality of the commercial version. In other cases hastily written patches has been applied to create a jury-rigged substitute for proven commercial code.
To make matters worse, the code base was huge -- over 1 million lines of source code. The code base was also monolithic, rather than modular. It was very difficult to change anything substantial and be sure that the change would not have unintended side effects elsewhere in the code base.
Finally, documentation was almost completely lacking. Most of the code had not been written in a self-documenting style, as that extra effort is one of the first things to fall by the wayside when developers are under a time crunch. Nor was there any substantial external documentation to help developers out.
In short, the Mozilla code base was pretty much the antithesis of what an open source project should be. The code was:
Senior programmer Jamie Zawinski, who had been with Netscape since pretty much the very beginning, was so despondent over the state of Mozilla that he resigned.
Several lessons could be drawn from the experience, none of them very encouraging.
The company line seemed to be that if something good happened, fine, but no serious effort would be expended trying to get positive results. That simply isn't a recipe for success. As Jamie said, open source is not "magic pixie dust" to be sprinkled on a project to make it grow.
This is perhaps the least understood aspect of open source. What open source developers are doing is not fundamentally different from what commercial developers are doing. Given that many of these developers operate outside the usual corporate communication and management structures, it can actually be more expensive and more time consuming to manage them.
What open source does allow is significant code reuse and, more importantly, knowledge reuse. These time- and money-saving benefits only apply, however, when leveraging an already well understood and well developed technology. Netscape was doing neither of these with the original Mozilla release.
The reason is simple, and eloquently explained by Fred Brooks in his seminal work, The Mythical Man-Month. Brooks' work is essentially a post mortem on the IBM 360 project, at the time the largest, most over budget and most delayed software development project ever. Brooks wrote the book in an effort to answer the question, "What went wrong?"
One of the key problems was a mismatch between scaling manpower and scaling complexity. Adding additional programmers to the project added manpower, but also added to the complexity of the project by creating additional communication interfaces needed to coordinate those added programmers. Physicists will recognize a parallel here with the problem of inertia: getting a rocket out of Earth orbit takes fuel, but adding fuel also adds to the payload, meaning you need even more fuel.... For software development projects, the "inertia" problem is even worse: adding programmers increases the amount of work done linearly, but increases the complexity geometrically. In other words, having any more than a small number of programmers working on a single body of code increases, rather than decreases, the time to completion for the project.
In a nutshell, that is Brooks' Law, and it stands today, even in open source projects, as a fundamental limit on the scalability of manpower in software development.
Entirely volunteer projects, which is the norm on SourceForge, tend to grow organically, adding only the volunteers that it makes sense to add, and losing volunteers when their efforts are squandered or unhelpful. Thus SourceForge tends to converge towards the ideal number of developers per project; that's why it has maintained the 10-1 ratio so consistently over time (the ideal ratio is probably in the range of 6-1 or 8-1, with the additional developers representing inactive developers or "project churn").
If you find more than 10 people collaborating successfully on a project, then that project, almost by definition, must be modular in design, enabling smaller teams to work independently of each other.
To make that transition, however, Netscape had to essentially throw away the first year. Many of the people changed. Marc Andreessen and Tom Paquin left, as did Jamie Zawinski. Mitchell Baker stepped in as "Chief Lizard Wrangler", a position she still holds and succeeds at today. Some of the engineering staff remained the same. Though less flamboyant and less visible than Jamie Zawinski, Brendan Eich has arguably been the most important developer to work on Mozilla, and has been part of the team from the beginning.
The code base from that initial Mozilla release was essentially thrown out. In its place the Mozilla team started with Gecko, a smaller, faster and more managable code base, and then added functionality in a highly modular fashion around Gecko.
Eventually Mozilla was split off organizationally from Netscape and AOL, with the Mozilla Foundation steering the project to provide clear focus and strategic direction.
All of these changes represented an enormous loss of time, but they were essential growing pains if the project was to survive. Anyone contemplating open source as a software development strategy would do well to study those growing pains, and know before launching a project how to learn from and how to avoid those same growing pains.
For contrasting perspectives on Mozilla's first year, it's interesting to look at opinions from two insiders. Frank Hecker wrote the internal Netscape white paper that advocated opening the browser source code in the first place. His reflections, as well as Jamie Zawinski's resignation letter make for interesting reading: