Mozilla

Module Ownership – Part 1

March 26th, 2008

The Module Owner System

The module owner system is at the heart of how we manage ourselves. We’ve used this system for coding activities for many years, and I’ve got an open bug for extending this to cover non-coding activities as well. We have an identified set of modules, module owners and a policy document describing the responsibilities and authority of a module owner. (In brief, we divide our code into logical chunks called modules. A person with a good reputation for the area covered by a module is tapped to become the module owner, and he or she is responsible for that module.)

We also have a final decision-maker for conflicts among module owners or issues with a particular module owner; that decision maker is Brendan Eich. Brendan has been doing this since 1998. For those not familiar with Mozilla, our basic rule has been that Brendan is the ultimate decision-maker for technical matters within the Mozilla project, and I am the ultimate decision-maker for other issues. We each try to use that authority only when necessary– when the people involved in the daily activities get stuck, or there is disagreement or some other problem that requires a decision. This is not weakness. It stems from the realization that Mozilla succeeds because many people make decisions, find ways to solve problems, and provide leadership. It is more effective in the long run for us when a group of peers solves a problem together. Distributed authority is the norm. Overuse of a central, final decision-making power will not make Mozilla healthy.

So we have a system that works well for us on a daily basis and we have an ultimate decision-maker for settings where we need one. But what we don’t have today is a group of people with responsibility for the health of the module ownership system. These topics include:

  • Filling vacant roles where appropriate;
  • Ensuring module owners are fulfilling their responsibilities, and replacing those who are not;
  • Creating and staffing new modules as new parts of the project evolve;
  • Figuring out what to do if a module isn’t getting enough attention;
  • Resolving conflicts among module owners.

I propose we create such a group. More precisely, I propose that we create this group as a module within the module owner system. I’ve put the details of how I think this module would be organized and operate in a subsequent post. First I want to address the functions of the group and why I believe it’s important. Then we can turn to whether the precise structure I’m proposing makes sense.

Responsibilities of the Proposed Group

There should not be a giant amount of work to do on a daily basis. Over the years David Baron and Brendan have periodically updated the list of module owners. Last year Stuart took on and completed a review and updating of our modules, which was overdue. These things should happen periodically. Occasionally there is a question of whether a particular module owner is still active enough to be a module owner, or we need to identify new module owners. Every so often there are questions about a module owner’s work. We should look at whether the policy document governing modules and module owners should be updated. We might want to think about better ways to handle modules that are under-owned, or where someone is module owner out of a sense of civic duty rather than an inherent interest in the module. One part of the role will probably be providing advice as we extend the module owners system to non-coding activities. So I don’t envision this group having a giant amount of work on a daily basis. There will be some periods of focused activity.

If there isn’t a huge amount of work, why do I think it is worth formalizing a group of people to do it? Several reasons.

  • The work is really important. Module owners have a high degree of authority. This is part of ensuring our vitality as a project, and ensuring we have clear roles based on merit, reputation and general acclaim. We will be stronger when we have a group of people proactively thinking about the module system and working though some of the issues listed above.
  • It’s important to build a group of people who are knowledgeable and experienced in governing important areas of our project such as the module ownership system. Even if Brendan and I were quick and perfect in all our decisions (which we most certainly are not) having only one or two people involved in making decisions is a weakness in our system. More people with experience is better.
  • We’re bound to have some conflicts, that’s how life is. Having a group of people who have been working through issues in calm times is very helpful when something comes up and tensions rise.
  • The clearer the system is the easier it will be to extend it to new, non-coding activities.

Criteria

Members of this group should be module owners (of either coding or non-coding activities). In addition they should have:

  • Interest in how we govern ourselves. Ideally, a person has previously demonstrated this interest by some set of activities. Someone could be a great module owner but still poorly suited for this role;
  • Appropriate understanding of Mozilla activities as a whole and the “pulse” of a good chunk of the project;
  • A good feel for whether suggestions, comments, and complaints are broadly applicable or represent an unusual viewpoint;
  • Interest and ability to help others accomplish things. This is probably more important than what one can accomplish oneself for this role;
  • Ability to balance varying perspectives and needs;
  • Internal understanding of the value of non-coding activities to the Mozilla project.

Structure of the Group

I propose we create this group as a module and use the module ownership system as the basic governance. That way we’ll have a module owner, peers and a way of interacting that we understand. I will put a more precise description of how I think this will work in the module owner system in a follow up post, mostly because I think it will be helpful to separate the mechanics of how this might work from the discussion of whether such a group is valuable in the first place.

Comments welcome here. If you’re interested in the full discussion, head over to the mozilla.org Governance newsgroup. You can also read a set of past comments and participate through the mozilla.governance Google Group.

One comment for “Module Ownership – Part 1”

  1. 1

    Pingback from Mitchell’s Blog » Blog Archive » Module Ownership - Part 2

    […] Home « Module Ownership – Part 1 […]

Skip past the sidebar