In the days before the Mozilla Foundation existed, the Mozilla project was originally managed by a group known as “mozilla.org staff.” Mozilla.org staff was a virtual organization which governed the Mozilla project in general, and did so increasingly unrelated to any employment relationship. Mozilla.org staff managed the project’s day to day activities, and held responsibility for basic technology and policy decisions. Today, some of these functions live in the Foundation — stewardship of the assets, and release of products using the Mozilla name, as examples. So the old model of mozilla.org staff cannot continue unchanged in the world of the Foundation.
Nevertheless, we need a mechanism to address governance issues that are broader than any particular product or project issue. More specifically, we should identify the key activities of the Mozilla project, identify the decision-makers, define the scope of their authority and the criteria by which they are designated.
In the past I’ve thought of trying to modernize or reconstruct a group like mozilla.org staff — a group that would have a set of project-wide responsibilities and obligations. I’ve made several attempts at this. It sounds good in theory, but in reality turned out to be very messy. In the days of mozilla.org staff, there was no Foundation. Trying to create another group in the Mozilla world with another set of responsibilities that would overlap with, or maybe be governed by the Foundation’s Board where required by law, or maybe govern or direct the Board is very complex. And the idea of doing this in a way that people can understand and remember is even more difficult. I’ve stumbled at the effort a couple of times now and find the task pretty daunting.
So I have a new idea that is much more simple. I’m indebted to Mike Connor, who suggested something like it in a newsgroup posting a while back. (Needless to say, if you hate the idea, please leave mconnor out of it 🙂 )
My new idea is to identify the roles that mozilla.org staff used to play and make modules for these roles. We might have a “governance” set of modules, or a governance module with sub-modules. We’re in the process of creating modules for non-code topics anyway and so we could use a single type of mechanism for code, non-code and governance activities. We would determine governance related activities as well as activities the Mozilla Foundation now handles directly, like management of trademarks. We’d identify a module owner. We would also identify someone (a Peer, or a member) with an acknowledged voice in the Mozilla Foundation. We could do something like arranging for owners, peers or members for these modules to meet periodically with a Foundation representative. In any case, we would develop a mechanism for notifying the Foundation when an important issue has become contentious enough that escalation beyond the module owner is warranted. I’m not sure about the right mechanism here, but am pretty confident we can figure out something workable.
This path means the activities for which mozilla.org staff used to have authority are identified, we are clear about which have become Foundation / Corporation activities and which, if any, are related to employment. We have owners and a way for differing opinions to be expressed.
I like this approach because it allows us to address these issues within a structure and process that is already understood. It requires giving up some of the emotional attachment of a separate mozilla.org staff. I think this is manageable; keeping everything from our past intact will drag us into paralysis. And this offers a good chance of having a working process.
Thoughts more than welcome. Once again, I’m posting this in the governance newsgroup (available via newsreader or mailing list, or via the browser).