Mike Shaver's Response to Computerworld Article
While Mozilla is by no means a perfect project -- there are certainly things I'd want to do differently if we were to start over from March 31, 1998 -- I think your article misrepresents the current state of the project, and does a disservice to the many people contributing to it. I'd like to share my opinions of those issues with you, and correct what I believe to be factual errors as well.
First, in the interests of full disclosure: I am employed by Netscape Communications Canada, and my job is to work on Mozilla-the-project. I write some code, but my primary responsibilities are developer relations (helping developers find the information, tools and people they need to get their jobs done) and evangelism/community relations (speaking at conferences, explaining Mozilla and open source development to potential corporate contributors, giving away T-shirts). You can take my source of income as a sign of bias, if you wish, but I believe that my track record on issues of ``Mozilla vs. Netscape'' speaks for itself.
Some issues of fact:
- ``because Netscape remains the corporate owner of the source code, what Netscape does is not really "open".'' Mozilla code is mostly covered by the NPL and MPL (though there are some parts which are under other, compatible licenses), both of which have been accepted by the Open Source community as open licenses. During the development of these licenses, we took great pains to consult with -- and incorporate feedback from -- the open source community, I think to great effect. We were so successful, in fact, that some non-Mozilla projects have adopted the MPL for their own use. (I can dig up a list if you want, though I don't have it at hand.) I suspect that some of your confusion arises from the ``special rights'' that Netscape has to code derived from NPL'd code: the ability to redistribute those derived works under other licensing terms, which is required for Netscape to meet some pre-existing contractual requirements. Anyone who wishes to contribute their own code is more than welcome to do so under the MPL, and we at mozilla.org strongly encourage them to do so; it is the position of both mozilla.org that the NPL's special rights are a legacy from before The Enlightenment. One of those special rights lapses in March, and I doubt that such special rights are even useful today, in the general case. The reason for this is something that I take as a sign of our success: there is too much code in Mozilla that's been contributed by non-Netscape developers for the NPL'd code alone to be of use.
- ``few outside developers [contribute to Mozilla] because they can't control its distribution or usage''. The licensing of Mozilla provides such control in approximately the same way as other open licenses: modifications to MPL'd/NPL'd code must be made available. Some open licenses (X11, BSD) provide less control than that: anyone can take the FreeBSD kernel, slap some proprietary changes in it and never contribute those back. Others, like the GPL, provide more control: any code that is combined with GPL'd code -- not just derived from it -- must also be licensed under the GPL, with the source-availability and other requirements that come with it.
- ``more than 3 million lines by Version 4. [...] tough for anyone to unravel.'' This made me smile and frown, because the convoluted (I sometimes prefer the term ``organic'' =) ) nature of the original codebase was in fact one of the driving forces behind the switch to the new architecture, and subsequent ground-up reconstruction. There were features demanded by our users and developers that were simply too hard to provide in the context of ``Mozilla Classic'', and the complexity and quirkiness of that codebase was, indeed, a deterrent to developers. Because of that, the Mozilla architecture was revamped in late October of 1998, as outlined in http://www.mozilla.org/roadmap.html. (That document has, ironically, been left mostly to languish as people work heads-down on the 5.0 release. An update is long overdue.) It appears to have been successful: there have been contributions of new layout technologies (MathML), networking enhancements, user interface additions and the like from non-Netscape developers. And those developers didn't need to understand the entire codebase to make such contributions, which they certainly would have in the ``Classic'' days.
- ``Netscape can't control [non-employees]''. That's certainly true, but it doesn't seem a very strong argument against the Mozilla process, when contrasted against traditional proprietary _or_ open-source development. In the case of proprietary development, no development at _all_ comes from people outside the financial reach of the company: there is simply no mechanism. And what does Red Hat do when it needs a feature in the Linux kernel or a userland utility? It might well have to develop that feature itself. Similarly with Apache: if IBM needs some enhancement or bug fix, they can't ``control'' non-IBM contributors. In many cases, Netscape engineers have been able to convince non-Netscape developers, based on sound technical arguments, to assist in their plans. (The converse is true as well, which I will discuss in more detail below.) And some critical-to-Netscape features (indeed, critical to all of Mozilla) have come from non-Netscape developers: the Unix build system, the Unix/GTK display code, network cache (still under development by Intel engineers), XML parser, large portions of the user interface and innumerable bug fixes, minor enhancements and useful suggestions. It's this lack of ``control'' that provides much of the value of open source: nobody has to ask Netscape (or even mozilla.org!) for permission to make changes to the codebase, though different groups will have criteria for inclusion in their final product.
- ``[Mozilla] had to throw out tentative schedules whenever it decided to accomodate suggestions from the outside''. I presume that you use ``outside'' here to refer to non-Netscape developers or users, but I don't think this point makes any sense at all. When a proprietary software company makes a change to accomodate a request from a customer or the marketing department, there is obviously cost. But in the case of, say, Oracle having to make changes at the request of Morgan Stanley, you don't get to see the process. I don't see that as a significant difference in terms of effect, except that a more open process gives Morgan Stanley a recourse if Netscape and other Mozilla developers _don't_ do their feature. (The additional transparency certainly gets us a lot of bad press, though.) There is a cheap shot here about how it would certainly be easier to develop software if you didn't take the customer's wishes into account, but who needs cheap shots? =) As a final point on this issue, it's important to note that the most significant suggestions (scrap Classic in favour of the new codebase, for example) came from _within_ the Mozilla community, including Netscape-paid developers.
As for more subjective issues, I'm disappointed but not terribly surprised to see mention of key Mozilla team members being driven away by AOL's purchase. I can only assume that you're referring to Jamie Zawinski's rather vocal departure, from some months back. It's certainly true that he's a very bright individual, and I think he could have helped us if he'd stayed on, but it was by no means a fatal blow. I think the largest cost might have been the time spent answering calls from reporters wanting to know if we were dead yet. But all projects, open source or proprietary, have members come and go. Jamie is obviously not the first person to leave Netscape, and I'm sure he won't be the last. Similarly, it's a rare open source project indeed that never has people leave; I can't think of any, and I've been living in this community for quite some time.
Whether Mozilla will let Netscape Communicator triumph over IE in the final standings is currently unknowable, and to me somewhat uninteresting: if IE were taken off the market tomorrow, our work on Mozilla would become no less important, and our developers would be no less motivated to contribute. It is a source of some considerable pride that Mozilla -- and Netscape along with it, make no mistake -- is taking the time to Do It Right (we hope!). We could surely have released a Mozilla 5.0 based on the Classic code by now, but it wouldn't have met our users' needs, and wouldn't have satisfied our developers' goals for a modular, standards-compliant, performant and portable browser and ``application platform''.
As I mentioned above, though, there are certainly imperfections in the system, and things that many would like to do differently. I've taken enough of your time already, so I will finish this note shortly, but if you want to discuss that -- or any other aspect of the project -- please don't hesitate to mail me. And I invite you to download the M10 release and play around with it: it's not yet done, but I think you'll be impressed by what you see.
Thanks for your time,
Got a response? TalkBack!