Skip to main content

Mozilla Modules and Module Ownership

Distributed Decision-Making

The Mozilla project is far too big for any one person -- or even a small set of people -- to make ongoing decisions regarding code appropriateness, quality or readiness to be checked into the CVS source repository. The project includes both a set of core technologies (layout engine, networking libraries, cross-platform component model, etc.) and a set of applications built with those technologies (browsers, mail/news readers, calendar, Internet Relay Chat client). The code is large and complex; the number of daily decisions to be made is enormous. The project would slow to a crawl if a small set of people tried to make the majority of decisions regarding particular pieces of code.

Instead, decision-making is distributed to a range of participants through its "modules" and module ownership. A module is a set of files that implement a piece of functionality with reasonably defined boundaries. A module may be the set of files in a directory, such as the directory "accessible" for the "Accessibility" module, or a module may be more conceptual, such as "Stylesheets.” In the latter case the module might include a number of files in different areas of the source tree. A module could contain just two files (if written in C or C++): a .h file and a .c or .cpp file.

Of course, "reasonably defined boundaries" doesn't provide absolute clarity. We use this definition because it reflects the code itself, where there may be overlap and ambiguity as to where a particular functionality ends and a different one begins. Trying to create absolute definitions would require elaborate rules and exceptions that aren't needed in most cases. Rather than spend energy devising such definitions, we prefer to let module owners manage any overlap or shared ownership if possible, with mediation when necessary.

Oversight of the Module Ownership System

The work of the module owners and the health of the system are overseen by an identified group. Although it doesn't necessarily involve writing code, that task of module ownership oversight can itself be thought of as a module -- the "Module Ownership" module -- subject to the same processes and policies as all other modules.

The Module Owner Role

A "module owner" is the person to whom leadership of a module's development has been delegated. Historically delegation was done by a group known as "mozilla.org staff." Going forward this will be done by the owner and peers of the Module Ownership module. This gives us a clearly understood framework for addressing questions about modules and module ownership. Module ownership includes a range of responsibilities, such as: improving code quality, implementing revisions and innovations as appropriate, coordinating development with that of the rest of the codebase, developing and maintaining a shared understanding of where the module is headed, developing APIs where appropriate, documenting as much as possible, responding appropriately to code contributions, design suggestions and stated needs of the community; and creating an environment where competent newcomers are welcomed and included.

A module owner's OK is required to check code into that module. In exchange, we expect the module owner to care about what goes in, respond to patches submitted by others, and be able to appreciate code developed by other people. Module owners have a fair amount of flexibility in how they do this. We do not have an elaborate set of rules or procedures for how module owners manage their modules. If it works and the community is generally happy, great. If it doesn't, let's fix it and learn.

Module Owners need not do all the work of managing the module themselves. Module owners may identify others who can also approve code for check-in into a module. These developers are known as "peers" and ought to possess many of the qualities of a good module owner. Module owners must designate to a peer the evaluation of their own code; module owners are not permitted to review their own code. If there is no module owner, the OK of a peer is sufficient to check code into that module.

Module owners are not tyrants. They are chartered to make decisions with input from the community and in the best interests of the community. Module owners are not required to make code changes or additions solely because the community wants them to do so. (Like anyone else, the module owners may write code because they want to, because their employers want them to, because the community wants them to, or for some other reason.) Module owners do need to pay attention to patches submitted to that module. However "pay attention" does not mean agreeing to every patch. Some patches may not make sense for Mozilla; some may be poorly implemented. Module owners have the authority to decline a patch; this is a necessary part of the role. We ask the module owners to describe in the relevant bug their reasons for wanting changes to a patch, for declining it altogether, or for postponing review for some period. We don't ask or expect them to rewrite patches to make them acceptable. Similarly, module owners may need to delay review of a promising patch due to an upcoming deadline. For example, a patch may be of interest, but not for the next milestone. In such a case it may make sense for the module owner to postpone review of a patch until after matters needed for a milestone have been finalized. Again, we expect this to be described in the relevant bug. And of course, it shouldn't go on very often or for very long or escalation and review is likely.

Escalation and Review

The owner and peers of the Module Ownership module will get involved if controversy develops and cannot be resolved otherwise. A module owner may ask for a public statement of agreement with a particular action. Sometimes other contributors suggest ways in which a module owner might improve. Sometimes there is ongoing controversy. We prefer that the community resolve these issues when possible, but acknowledge that this can't happen all the time. We try to avoid making absolute decisions like "this must happen" but will do so if required.

Criteria for Module Ownership

There are a number of important elements of good module ownership. First is the person's expertise with the code in question. But over time we've learned that a set of additional criteria is also important, and that a great hacker can be a poor module owner. The criteria that go into the mix for a good module owner include:

  1. Expertise with the code in the module
  2. Current level of involvement with the module
  3. Understanding/vision of where the module ought to be headed
  4. Appropriate understanding of Mozilla codebase as a whole and the module's relationship to it
  5. Ability to evaluate code for that module, including contributions of patches and new features
  6. Ability to evaluate impact of code on other parts of the codebase
  7. Ability to communicate with a diverse, geographically distributed community
  8. Willingness to evaluate contributions on their merits, regardless of their source (i.e., no 'not invented here' syndrome)
  9. Ability to consider varying perspectives and needs of different consumers of that module
  10. Ability to resolve different needs through factoring or other abstraction techniques when appropriate

Designating a Module Owner

We prefer that an individual work with a module for some time and demonstrate the ability to fulfill most of the criteria most of the time (we're not naive enough to require perfection), and that a consensus form about designating this person as the module owner. This way the designation is more of a confirmation than an appointment. We haven't always done this, and we haven't always done it well.

This means that there will be times when there is no module owner. In particular, in some cases modules have received little attention, have started to rot, and some brave soul steps up to figure things out and get us back on track. We'll shower these folks with thanks for tackling the job, however we may not immediately designate them as module owners. Almost by definition, it will be difficult for this person to have demonstrated some of the criteria, particularly 1-5 until some time is spent working with the module. It's possible that someone's expertise is broad and so deep enough to do this, but we would expect this to be the exception rather than the rule.

In determining a module owner, the criteria above are not necessarily accorded the same weight for each module. The importance of a particular element depends on the module. For example, criteria 4 (appropriate understanding of the Mozilla codebase as a whole and the module's relationship to it) and 6 (ability to evaluate impact of code on other parts of the codebase) will be of less importance for modules that are self-contained, and of great importance for modules containing core technologies which affect other parts of the code significantly. Similarly, criteria 9 (ability to consider varying perspectives and needs of different consumers of that module) and 10 (ability to resolve different needs through factoring or other abstraction techniques when appropriate) will be less important to a module which serves a specific, clearly defined function for a small number of contributors, and critical to a module which supports a variety of uses and a broad contributor group.

Tracking Module Owner and Peer Data through Despot

Mozilla uses a access-controlled database known as "Despot" (despot.mozilla.org) to track code modules, module owners and peers. The data from that database, including an indication of what code makes up each module, can be publicly viewed at www.mozilla.org/owners.html. Modules, module owners and peers for modules relating to other, non-coding activities, including the Module Ownership module itself, can be found at http://wiki.mozilla.org/Module_Owners_Activities_Modules.

Transfer of Module Ownership

Module ownership is transferred through the owner and peers of the Module Ownership module. A module owner resigns by sending mail to this group. The module owner should feel free to include recommendations for a new module owner. In some cases, the module will have a peer who has demonstrated the criteria for module ownership, is interested in being the module owner, and is generally accepted as being a logical successor. In such cases, the Module Ownership owner or peers will commit the change of ownership to Despot. In other cases there may not be anyone who has demonstrated the ownership criteria with respect to that module. In these cases, the module may go without an owner until an owner develops, with the peers of the module providing the review and OK necessary to check into that module.

Relationship to Bugzilla Component Owners

Occasionally there is some confusion between the role of module owner/peer and that of default owner of a Bugzilla component. The roles are quite different. A component owner is the person best suited to receive incoming bug reports for a particular component, not necessarily the person best suited to make decisions about the direction of the module and the review of its code. There are several reasons for this. First, Bugzilla components do not map exactly to modules. That's because components reflect the way bugs are perceived and experienced, not necessarily the structure of the code. Second, managing bugs is a different task than managing the code of a module, and the skills required are different. Some great hackers are not so good at reviewing bug reports regularly, tracking progress, reassigning bugs to correct owners, making sure test cases exist, etc. Some contributors are excellent at these skills but not necessarily at directing code development. So in some cases the Bugzilla component owner and the module owner may be the same person, but in many cases they will be different.

Poorly Maintained Modules

Periodically a module is not well maintained and no longer interacts well with the rest of the codebase. This can happen where there is no module owner, or when a designated module owner is too busy with other things to tend to the module. Conceivably it could happen when a module owner is active, but has an approach to a module that the community in general believes is inappropriate. We prefer that the development community identify such modules, propose a solution, and implement improvement. If this can't happen for some reason then the Module Ownership Peers will get involved to find the best possible resolution.