Evaluating Commercial Open Source Projects
I start by quoting a very strong, but also very incorrect statement by the article's author Josh McHugh:
"The Netscape effort, which it calls Mozilla, has been a commercial flop so far."
I think we should start by clarifying what Mozilla isn't. Mozilla is not Linux, and it's not Apache, and it's not The GIMP, and simply put, it is in a class by itself at the moment (some new commercial "openings" have occurred, but an assessment of their success at this time is premature). Mozilla is the first of its kind: a release of commercial, once-proprietary code into the Open Source realm. Because of this, an assessment based on previous open source efforts is misleading and ultimately nonproductive. To go so far as to call Mozilla a "flop" calls into question the bias of the writer, or his unwillingness to objectively and thoroughly approach the subject.
To judge the success of a commercial Open Source project, I believe an initial "needs" assessment is required.. And I think the best way to start a needs assessment is to detail what you already have.
Mozilla already has a strong infrastructure in place. There is a centralized authority that oversees the progress of the application. There is strong bug-reporting technology in place, along with an in-house QA group and a User Interface group. All of these things create a coherent project that is not only strongly goal oriented, but also better able to deal with curve-balls thrown into the development process. These elements are also found in every commercial software project on the market today, so the needs assessment below applies not only to Mozilla, but to any company considering Open Source moves.
Mozilla has the coders, designers, and testers needed to create a browser. But, if this is the case, where do outside developers come in?
There are three ways in which outside developers fit into the Mozilla project. All three ways address distinct needs that all commercial projects share. These needs are not the same needs of a completely volunteer Open Source project, and this is precisely why a comparison with other Open Source projects is misplaced. But these needs are shared to some extent with the company's customers, as well, which is why Open Source development of commercial software is feasible at all.
The first need is one felt by developer and customer alike: cross-platform support. Nothing has vexed commercial software development over the past decade more than the balkanization of software along Operating System lines. People are willing to go out of their way to obtain some cross-platform operability. From learning Java, to porting tools like Perl and applications like Apache, the community has spoken loud and clear that they want to be able to pick the appropriate platform for their needs but still retain the ability to run the applications they prefer. Netscape has recognized this need from its inception, and it is safe to say that cross-platform operability is the driving force behind the Mozilla project. But cross-platform support takes manpower, and that manpower is hard to justify when your product generates zero revenue (even for a company as large as Netscape, and now AOL). Even with that "zero-revenue" handicap, Mozilla already supports an impressive array of platforms. But they can't support all platforms, and that's how outside developers address this first need. Coders have stepped up to the plate to port Mozilla to the BeOS, to the Amiga OS, and to OS/2. Be, Inc. has gone so far as to hire a full time coder to aid the third-party development of "BeZilla". These coders have done impressive work and although they work on the periphery (and thus are excluded from the "30 outsiders" number that appeared in the Forbes article) their support guarantees that Mozilla will make it onto the platform of choice of many developers. One thing that should be noted is that porting has tangible benefits for the third-party coders as well as the commercial vendor, and they wouldn't be tirelessly coding if they did not have a distinct need themselves. I think it's safe to say that other commercial software developers who "Open Source" their software will have to allow for the porting of their technology to other platforms in order to gain substantial outside support for their projects.
The second need that third-party contributions can address is "gap filling". Commercial software development revolves around time constraints, and these time constraints limit the breadth of work that can be attempted during one revision of a product. Opening the source to software can help by allowing third-party developers to help bring about features that they themselves want/need from a particular application. For example, the Mozilla Internationalization effort is supported by many developers who have a clear interest in making sure Mozilla is available in their native language. The addition of the Expat XML parser filled a gap, providing functionality that would not have made it into Mozilla's own XML parser until a later time.
So where did this "30 outsiders" number come from? In fact, that number refers to the outside coders that have direct access to submit changes ("commit privileges") to the Mozilla tree. It is not known how many patch and code submissions came from other people who did not have direct access to the tree. Netscape themselves have only 100 coders with "commit privileges", so the fact that 30 others are allowed to submit changes to the tree is noteworthy. But the number is misleading when it used as the only measure of community involvement.
Gaps are filled by testers as well, and opening up their bug-reporting process and inviting everyone to participate in the bug hunt has in itself aided in freeing up developers' time. And the bug reporting process of Mozilla is not a "send-and-forget" deal for bug submitters. They are notified via email at every step of the process. They receive a notification when the bug is assigned, they receive a notification if clarification is necessary, and they receive notification when the bug is dealt with. This kind of interactivity not only involves outsiders, but it keeps them involved as well. People who have never coded a line of C++, who have never submitted bugs for any software, are now intimately involved in the development of a piece of software.
The final way that third-party coders can aid in a commercial Open Source endeavor is by developing new tools and applications from the existing code, which directly aid in the application's market penetration. Again, this is occurring with the Mozilla code, and one begins to wonder if the author of the Forbes article did any research on Mozilla at all. Some examples:
The last three examples are truly made possible by the contributions of one developer, Adam Lock, who contributed the ActiveX wrapper for the Mozilla layout engine which allows these consumer-oriented Windows applications to easily integrate Mozilla code.
All three of these needs, cross-platform development, "gap-filling", and market penetration are currently being met by the contributions of third-party coders to Mozilla. The expectations of some haven't been met, but these people are expecting Mozilla's third-party effort to behave like previous Open Source projects. A rational assessment would come to the conclusion that Mozilla's Open Source effort has been successful and innovative in its first year. It has brought into focus what can be expected from a "commercial" Open Source release. Of course help is always gratefully accepted (two new projects, a revised networking library and a messaging/chat API would both benefit from third-party contributions).
While Microsoft recently released a new version of its Web browser, Internet Explorer, Netscape has gone more than a year without a major release for Navigator. It's still waiting for Mozilla to give birth.
The author seems to be trying his best to turn Mozilla's delays into a horrible omen. However, his argument is a red-herring. It is well known that the decision to move to a new layout engine and new cross-platform user interface (essentially rewriting the browser from scratch) has led to delays. But the Mozilla team has met every milestone since the decision was made. Also, Internet Explorer was essentially "released early". Their code is buggy and bloated, and their standards support sorely lacking. IE gets a slight advantage when compared head-to-head with Mozilla by people who judge software releases by their speed to market, but it has been almost universally panned in reviews by site designers/developers.
Moral: It may be that programmers will happily craft code for open software that doesn't belong to any one company--the Linux operating system or free Apache for Web servers--but they balk at helping the Netscapes of the world get richer.
This argument has popped up in Slashdot forums recently, as well, but it glosses over the fact that Mozilla doesn't make money for Netscape (or AOL) anymore. It also misses the fact that AOL has, for years, developed software (the core product of their service) that generates no direct revenue. The argument also fails because any developer, at any time, can fork the tree and create a competing product.
In a postmortem he published on the Web, Zawinski, who wrote much of Netscape's original browser, says that one of his biggest disappointments was the failure to inspire a large community of developers to join up, and that having so many Netscape full-timers on the project may have violated the dynamics of a culture that thrives on volunteer programming.
This may very well be, but we're moving into a new era in Open Source development -- an era where Open Source projects can no longer be judged solely by the "Army of Developers" that gallops in to save the day. If the Open Source community is unwilling to allow for the possibility of commercial Open Source success, and refuses to encourage the opening of code, they disadvantage everyone. Why? Because the greatest benefit of commercial Open Source software is accountability. The developers are accountable for buggy code and for missing features. In the case of Mozilla, since much of the process of spec creation occurs in the development forums, the developers are also "in the spotlight" and are forced to make proper decisions from the beginning.
Also, "postmortem" seems a little premature, no?
Unfortunately for Netscape and other companies hoping to get top-notch software development on the cheap, it seems no corporation can muscle an undisciplined open-source project into the framework of a long-range corporate strategic plan.
The writer again seems to be going out of his way to pronounce the Mozilla project a failure. Mozilla is without a doubt one of the most disciplined Open Source project out there. They have strict coding guidelines, and a strong milestone-centered development timetable. Also, with AOL backing it, they will continue to produce free software for the Internet community. It is also clear that AOL understands the logic behind free software. As I stated above, they've been creating it for years. Finally, I'll end with a reaction to comments by Timothy O'Reilly:
"Open-source software morphs in unexpected ways," says Timothy O'Reilly, a publisher of open-source software guides. The red-hot Linux grew spontaneously, with programmers adding new features they found interesting and fixing problems as needed. Netscape needed a specific product and a more structured set of tasks, done in a particular order, fun or not.
And here I think Tim O'Reilly has hit precisely the wrong note, implying that Netscape "Open-Sourced" Communicator "just to get an advantage", and they "only [did] it to get something". The implication in his words is that Netscape was only considering its own good when they released the code, when it is clear from accounts at the time that the people pushing for the code release, people like Jamie Zawinski, had much different motives. And since the release, Mozilla.org has gone out of their way to open up the decision making process to the community at large, and promoted open critique of specifications. They also recommitted Mozilla to standards compliance (some would say without regard to the opinions of Netscape management). The fact that Mozilla is being actively ported to other platforms implies that this Open Source gift has benefits for the receivers as well as the giver.
Just because Mozilla isn't "playing the game the way it's [supposed to be] played" doesn't mean that their efforts are a failure. It's way too early in the process to make that sort of determination. Even then, Mozilla is rewriting the rules, and failure on their part can only be judged when we can gauge the success of other commercial Open Source projects. Until that time, support and patience are needed. After all, the result is a gift to you.
Got a response? TalkBack!