Community Articles: Opinions, Interviews, Analyses
1 May 2001
Interview: Frank Hecker
Frank Hecker is perhaps most well-known in Open Source circles for his role in open-sourcing Netscape's code. A theorist and analyst of Open Source, Frank has continued to write on the evolving Open Source environment. At present, he is a systems engineering manager for CollabNet, which is hosting OpenOffice.org for Sun Microsystems.
The interview below was conducted two weeks ago over the span of a couple of days via email.
Your biography, which can be found on your home page, is fascinating. Perhaps most interesting for our purposes is the role you played in open-sourcing Netscape's browser code. Would you want to discuss what went into your decision?
I was only one of a number of people involved in Netscape's decision to release Mozilla source code. If you're looking for a comprehensive and accurate discussion of Netscape's decision, you can find what I consider to be the best one in chapter 11 of Glyn Moody's book "Rebel Code." It's quite a tangled tale, and very different from how it's usually portrayed.
Before I continue, I should note that my comments below are my own opinions only; I certainly can't speak for Netscape, and even though I still participate in mozilla.org activities I'm not speaking here for mozilla.org either, but only for myself.
However, to answer your question concerning my involvement in the Mozilla decision: I was the technical director of the Netscape government sales group in the Washington, DC, area. The US government is an unusual market for information technology, in that government customers often require special product features that are not of interest to commercial customers. I spent a major part of my job working with the Netscape marketing and engineering groups in California to try and get them to include in Netscape products the added features we needed for the government market; in some cases we even had custom engineering projects to develop government-specific product features in the area of security, cryptography, and public key infrastructure (PKI).
Over time I became very frustrated with the traditional proprietary software development model, where all development had to be done inside the company and the only developers who had access to source code were members of the internal engineering groups. Thus when I read internal newsgroup postings from Jamie Zawinski and others proposing that Netscape release source code, I was very interested in the idea. However at the same time I knew that, regardless of how enthusiastic developers were about releasing source code, nothing would happen unless Netscape's senior managers also came to believe that it was a good idea.
As the lead technical person for our sales group I participated directly in our sales efforts to high-level civilian and military officials in the US government, as well as in our internal lobbying efforts to Netscape executives from Jim Barksdale on down; as a result I had a fair amount of personal experience in how and why senior managers made decisions. I therefore took it upon myself to write a formal business case for releasing source code, one directed at Netscape senior management and not at developers.
The key point I tried to make in the document was that in order to compete effectively Netscape needed more people and companies working with Netscape and invested in Netscape's success--a success in which those others could potentially share. I believed that by both releasing source code and engaging in collaborative development of that code, Netscape could build closer and deeper relationships with its customers and partners. I also believed that increased availability of source code and a more open development effort would help attract others who could help address particular market requirements that Netscape could not always address by itself. (As I've noted, this was of particular interest to me.)
Working in a sales group I was also familiar with the need to address objections that might arise in the course of selling something to someone. Thus I spent a lot of time writing responses to various objections that I thought people might have to the idea of releasing source code. The end result was a 30-page internal white paper that got circulated to Marc Andreessen and other Netscape senior managers. It went into the mix along with comments from Netscape engineers like Jamie Zawinski and especially lobbying by Eric Hahn, who was Netscape's CTO at the time and had proposed similar ideas; Eric Hahn was probably the single person most responsible for getting Netscape's executive management to make the ultimate decision to release the Mozilla code.
(Since it always gets mentioned in relation to Netscape's Mozilla decision, I should also note that Eric Raymond's paper "The Cathedral and the Bazaar" was referenced by me and others who were lobbying Netscape's management. In my opinion the paper's importance in the context of Netscape's decision was mainly that it provided some independent validation of ideas that were already being actively discussed and promoted within Netscape. If you've ever tried to promote a proposal within your organization, then you may have discovered that it's somewhat easier to do this if you can point to someone outside the organization who's saying the same thing.)
In particular, if you haven't already addressed the issue above, in what ways did having corporate sponsorship alter the logic and practice of open-sourcing the code? That is, how were (and are) Netscape's desires affecting the course of the project? And does the corporate presence alter the way in which the project is regarded by the Open Source community?
Clearly a corporate-initiated open source project can be perceived differently than a project created by independent developers; that was certainly the case with Netscape and Mozilla. I've noted three problems in particular.
First, people tended to think of Netscape (and later, AOL) as a monolithic entity, and all the Netscape developers as marching in lockstep in accordance with some Netscape "party line"; they forgot that the Netscape developers are still developers, and will have ideas and opinions that may differ amongst themselves and even with their corporate management. (This may be obvious to anyone who's worked in a large corporation, but not everyone's had that experience.) I discuss the implications of this in my answer to the next question.
It's true that Netscape exerted significant influence over the technical direction of the project; for example, it was important to Netscape that Mozilla include a mail/news client and not just a browser, because Netscape wanted to use Mozilla to build a replacement for Netscape Communicator 4.x. However as far as I'm concerned this is just an example of Netscape "scratching its own itch": to the extent that Netscape developers are the ones writing the code, all other things being equal they're going to write code to implement features of interest to Netscape. However the project is open to other companies or independent developers who want to get their own code into Mozilla, whether it's of interest to Netscape or not. For example, IBM developers have contributed support for bi-directional languages like Arabic and Hebrew, Sun developers have contributed in a number of areas (many Java-related), and other companies and independent developers have contributed code to support embedding the Mozilla layout engine in other applications.
Second, the Netscape developers were all located in one location (almost all of them in one building) and they were very used to working face-to-face; Netscape had internal project newsgroups and project web sites, but the information on them was not always accurate and complete, simply because people were busy and could rely on personal communication to fill in any information gaps. When the Mozilla project first started it was a struggle to get the Netscape developers to move all (or almost all) of their discussions to the public Mozilla newsgroups and mailing lists, and to have them write down and post on the Mozilla site important information that traditionally may have existed only on whiteboards and in people's heads.
Fortunately over time people were able to change their habits, to the point where I think that the Mozilla project does a pretty good job of being a "transparent" project, in the sense that almost all the relevant information about the project activities is publicly available in some form or other. (It's not always well organized and easy to find, but that's another problem....)
Finally, at least in the early days, a lot of people were uncomfortable with the commercial aspect of Mozilla, [and worried] that it was not a traditional project started by volunteers, but rather a project initiated by a for-profit corporation to try and achieve specific business goals. I believe that's much less of a problem today, both because independent developers have gotten used to working with Netscape developers as developers and not as corporate representatives, and also because in the broader world there's been such a great amount of commercial activity around Open Source and free software--it's no longer unusual for companies to sponsor Open Source projects, or for free software developers to be hired by companies specifically to take advantage of their expertise and positions within existing projects.
There will always be a certain amount of tension between companies trying to build profitable businesses and developers trying to create the very best software they can, but I think that for the most part Netscape, other companies involved with Mozilla, and the developers themselves have managed to find ways of working together that allow all parties to get something of value out of the project.
mozilla.org, has a respected governance board and a detailed roadmap. Would you want to discuss the role a governance board plays in an OS project? And, if the project is corporate sponsored, is the board as crucial?
mozilla.org (the organization, not the site) fulfills several roles. Probably the most important ones are serving as a neutral party that can mediate among the various parties involved in Mozilla development and promoting Mozilla as an open-source project, independent of Netscape 6 and all the other products that use Mozilla code.
The members of mozilla.org don't actually make that many decisions about Mozilla development; what they do instead is set overall policies and directions, and intervene to make decisions when developers can't reach agreement on their own. (Such disagreements are not necessarily always between Netscape developers on one side and non-Netscape people on the other; often the disagreements are between different non-Netscape developers or even between Netscape developers in different groups.)
I believe that having an autonomous (or at least partly autonomous) "governance board" like mozilla.org is important even in corporate-sponsored projects; in some senses it's even more important than in projects created and run by volunteers. As I mentioned above, some people believe that the actions of Netscape developers are based solely on Netscape corporate policies and strategy--that Netscape developers are under orders to make sure that Mozilla is developed in the way that Netscape wants, with no larger purpose. I think this is an unfair characterization: While Netscape developers do have an obligation to their employer (as any employee would), they also want to help make Mozilla a great product for everyone, not just for Netscape. (In fact, increasingly Netscape developers are being hired from the ranks of Mozilla volunteer contributors.)
Having mozilla.org people involved helps keep project decision making focused on what's right for Mozilla overall, and helps prevent disagreements over technical and other issues from degenerating into arguments about "what Netscape wants". If developers employed by Netscape happen to propose a reasonable approach to a contentious issue and mozilla.org agrees with them, mozilla.org can justify its decision and respond to criticism instead of leaving the Netscape developers to defend themselves against the charge of doing Netscape's bidding. Similarly, if independent developers have a good idea and are having trouble getting attention for it, mozilla.org can press the case for it with the Netscape developers and development managers working in that area.
As well, as a follow-up, what function does the roadmap play in the structure of the project?
I think the Mozilla roadmap provides a needed structure and rhythm to development activities from week to week and month to month. It helps people understand why during certain periods patches can't be taken or require increased review, it prepares them for experiencing temporary instability due to major landings of code changes, and it gives them something to look forward to, in the form of upcoming milestone releases.
The roadmap is especially important now that Mozilla has advanced to a point where multiple companies or groups want to ship projects based on it. Last year Netscape was the only company planning to ship a Mozilla-based product and really needing a detailed and complete development schedule. Now there are enough people with a stake in Mozilla's progress that it's necessary to plan for periodic Mozilla releases that they can use to create beta or production releases of their own products, according to whatever schedule they're working to.
I have elsewhere described the relationship between the sponsoring corporation and the community as a dialectic: the desires of each are not identical but can only be realized together. But organizing the developer community so that it even sees itself as a community is itself a challenge. What strategies does Mozilla.org use to create the community as such, and to sustain interest in developing Mozilla.org's next software?
First, in my opinion a number of people at Netscape were instrumental in setting the Mozilla project on the right path when it initially started back in 1998. I want to mention especially Jamie Zawinski and Mitchell Baker. (Jamie was the most active and prominent member of mozilla.org early on, though he was never actually its official "leader." Mitchell was formerly a Netscape lawyer; she's now the Netscape manager responsible for mozilla.org.)
Jamie Zawinski did a great job of establishing an independent identity for the Mozilla project at its outset; he lobbied for creation of the mozilla.org web site independent of Netscape's site, lobbied for creation of mozilla.org as a separate group dedicated to making the Mozilla project successful, and commissioned and directed the creation of the Mozilla logo and "brand image" (to use marketing-speak for a moment). Most important, Jamie articulated a clear vision for the Mozilla project and for mozilla.org; his "mission statement" Mitchell Baker and others were originally responsible for Netscape's efforts to create an open source license for the Mozilla code; this eventually resulted in the creation of the Netscape Public License and then the Mozilla Public License. The details of the licenses are not as important in my opinion as the process by which the licenses were created; Netscape was willing to involve in the process not just a select few "experts" but anyone who had an interest and wanted to contribute comments. As a result of that process Netscape made several significant changes to the licensing arrangements, and I believe that was an initial factor in assuring people that Netscape was in fact willing to "listen to the community" as opposed to simply dictating to it.
I do not believe in "instant community." I believe that a true community evolves only as people work together more closely and are able to cooperate to help solve non-trivial problems. And certainly the Mozilla project had a lot of real problems to overcome, starting with the need to make a hard decision about whether to continue with the original code base or to go for a bottom-up rewrite of the software. In the end the rewrite went forward, which ended up imposing the major schedule delay we've seen in getting Mozilla 1.0 shipped. However, as with the original discussions about licensing, I think that because the various people working in the project were able to successfully reach consensus on "the right thing to do", that helped enhance and preserve the sense of community through the subsequent events like Jamie leaving the project and people criticizing Mozilla as a "failed project."
I should also mention here two other factors. First, besides the main Mozilla project we saw the establishment of independent Mozilla sites, most notably MozillaZine (founded by Chris Nelson). MozillaZine and other sites provided a focus for Mozilla evangelism and other activities beyond the core project.
Second, Netscape QA staff and various QA volunteers worked together to organize the efforts of people who were not developers but who were willing to put in a lot of time testing Mozilla, filing bugs, and evaluating and verifying bugs submitted by others. In my opinion the Mozilla QA team has done a great job of making people new to the project feel welcome, helping them learn about the project (which is quite large and complex), and giving them a chance to contribute in ways that were personally satisfying to them.
