☆ Is Mozilla Open-By-Rule?



Host to the Firefox browser and the Thunderbird mail client among many other projects, the Mozilla Foundation is one of the largest and most significant open source projects. Long-term contributor and employee Gervase Markham has kindly provided the data for an open-by-rule scorecard for Mozilla.

The goal of the open-by-rule benchmark is not to judge the effectiveness or otherwise of any particular project. It is to examine the project governance and establish whether it is an example of good governance. A project may succeed despite flawed governance, with the good judgement and goodwill of participants overcoming possible opportunities for closed behaviour.

As usual, the data and draft text is contributed by a community insider who has made suggestions about scoring, but the score is mine and text that’s not in quote marks should be assumed to be mine too. Mozilla scores +6 on the scale -10 to +10 and is an open-by-rule community (as well as a functionally open community) despite some issues with closed overall leadership rules.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy About Mozilla

Module Owners

Mozilla’s ultimate authority is a board of 5 people. This board is not elected, but was chosen by the senior group who set up the Foundation. They do not exercise day-to-day governance over the project but approve direction, big new initiatives, and budgets. Because they are not elected or subject to challenge, this is clearly not an open organisation. Score -1.

Mozilla’s day-to-day heads are Mitchell Baker on the organizational side, and Brendan Eich on the technical side (both are also on the board), and Mark Surman for the Foundation itself. Even when Netscape dominated the project and sacked Mitchell, she remained head of the project (rather to their consternation). People rise and fall in the organization based on merit, not employment – although the two are hard to separate, as meritorious people often get hired, and Mozilla hires already-meritorious people from other fields! Despite the big hiring budget leading to a preponderance of employees of Mozilla, it is still a meritocracy and there are plenty examples of leadership from outside the ranks of those employed by the Foundation, so this scrapes a +1.

Mozilla has strong leadership, with an appointed set of leaders (known as ‘module owners’) who have control in their areas, with the (very rarely exercised) right of appeal to Mitchell or Brendan. The clearest example of this is in the user interface, where the team spends a lot of its time saying “No” to other people. This is an oligarchy – leadership is exercised rather deferred to chatter or “democracy” by the masses – and scores +1 as a result.

The overall score of +1 reflects a somewhat closed leadership strategy for an organisation that’s otherwise so committed to inclusivity and transparency. It works, but it is in some part due to great people filling the leading roles and overcoming the challenge of the closed top-level leadership rules.

Modern license The Mozilla License MPL 1.1+/GPL 2.0+/LGPL 2.1+, with the possibility in the future of switching to the MPL 2.0+ when it is released. (The MPL 2 is a modern license with inbuilt compatibility with the other two currently used.) All of these licenses have patent protection. Mozilla takes a lead role in writing and advising upon the writing of open source licenses. +1
Copyright accumulation Mozilla Committer Agreement Mozilla does not require copyright assignment. There is a Committers’ Agreement which requires people committing code to have the rights necessary to contribute it, or to investigate its provenance if they did not write it. But the copyright on all our code remains with the authors (or the Foundation for Mozilla employees). +1
Trademark policy Trademark Policy The Firefox and Mozilla trademarks are owned by the Mozilla Foundation, and carefully controlled to make sure that good uses are promoted and bad uses are not. However, what is “good” or “bad” is ultimately the Foundation’s decision, and other community members do not have trademark rights equal with the Foundation.

Gervase says: “I have publicly disagreed with Simon’s points here, but this is his set of criteria, not mine. I am scoring us as 0 because I think the trademark policy is not actively detrimental to the project, but Simon may wish to score it differently.”

Simon says: “Mozilla was a pioneer here and the policy does not actually privilege a community member above all others so actually I’m tempted to score it as +1, but there’s enough controversy around the subject to just about make me agree with Gervase’s score here. “

Roadmap Firefox Roadmap

Thunderbird Roadmap

Bugzilla Roadmap

Gervase says: “The Mozilla project is very open about its day-to-day procedures and planning, but the fast-moving nature of the field means that roadmaps which look even 6 months ahead tend to be very vague and aspirational. We also release “when it’s done” and so you won’t find a date-based release schedule either.”

Simon says: “The lack of a date-based release schedule is a concern. When releases are determined based on someone’s judgement that “they are ready” there is too much scope for abuse. It’s far better to have firm release dates and include or exclude features based on their owners’ public assessment of readiness (the “release train” pattern) as this is far harder for any individual to “game”.  However, the results are good so I’m scoring this as 0 and I gather there are moves afoot to start naming the next release date in advance which would roll the score over to +1.”

Multiple co-developers Developer Credits
(Not a comprehensive list, and not everyone on the list is still active.)
Gervase says: “Mozilla is one of the largest open source projects in the world. We employ (I think) over 400 people, and have several thousand more active volunteers. (Good community metrics are hard to come by, something we are working to change.)”

Simon says: “I’m actually concerned by the number of key contributors who are employed by the Foundation; an open-by-rule community should have greater diversity. All the same, my experience at Sun was that Mozilla was very happy for Sun staff to take key roles in Mozilla projects and as such I’d score it +1 for diversity based on that experience.”

Forking feasible GNU IceCat


Mozilla code is regularly forked to produce other browsers or related software, from the minor changes of GNU IceCat to the much larger changes of the Songbird media player. Some of these organizations or companies send back patches, some do not. There is even Mozilla code in competing browsers, e.g. Chrome on Linux uses NSS, the Network Security Services module. +1
Transparency Forums




All project communication is done in the open, and all meetings are open for dial-in or to be viewed as streaming video on Air Mozilla. There are a wide range of forums, available via multiple access methods – email, news and web. There is a forum specifically for governance discussions.You can, of course, track all bugs and commits (with the exception of some information about security bugs, for a limited time) in Bugzilla and via our the SCM systems. +1
Summary (scale -10 to +10) +6

The full series of articles is summarised on the Essays page.


4 Responses

  1. I’m not a believer in roadmaps, fwiw. I do understand the craving of contributors for guidance and structure, but I prefer the openess to “there’s no plan beyond ABC” to “this is the plan, and we’re not going to stick to it”.

    I guess this applies differently to different organizations. Smaller projects in a more static landscape might actually be able to plan ahead, whereas for the browser landscape and a project as big as mozilla, you just have to be more open to what the community brings up, or just what the competition does.

    • I agree, but that’s not the point of “roadmap” here. Rather, it is a device to ensure transparency in the release process. When there is a firm release date, where each contributor is the one who determines whether their contributions “catch the train” or not, when interference from outside would stand out like a beacon, the community is able to build trust and function effectively.

      For me, “roadmap” refers much more to a practical release schedule built from the commitments of contributors than it does to an architectural document from a godlike architect…

      • In that case, GNOME should already be a +1 I think 😉


  2. Roadmap per sé maybe not so relevant, I agree. Actually when roadmap comes with a transparent and accessible way to propose change requests, that’s different.

    Adding rules’ marks may lead to conclusions that actually don’t take into account how some metrics are interrelated.

Comments are closed.

%d bloggers like this: