Archive for May, 2006

In a recent post I wrote about the role of non-engineers in our project. A couple of people responded along the lines of “why can’t we just use our standard techniques, where people come up through bug triage, or our online communities, etc?” I’m glad people asked this because this is a critical point, and at the heart of the topic I want to address.

I whole-heartedly agree with the spirit of this response — people are effective when they are known and respected. This is the basis of shared values, community cohesiveness and continuity. It’s one of the tenants of open source software development that I believe must permeate everything we do. Our challenge is to use this approach in places where engineering “chops” aren’t a sufficient and may not be a particularly necessary criteria.

When we apply this approach of legitimacy-through-reputation to the Mozilla project, it’s clear how engineers “come up through the ranks” and move into broader roles. The combination of “coming up through the ranks” and an organization that is historically mostly engineers means that one “comes up” through an engineering process — bug triage, patches, etc. And we have gotten some great product and project management through our phenomenal collection of lead engineers.

But if one’s skillset is something other than code, then proving oneself through understanding the intricacies of our code is at best inefficient and probably a blocker for many people. So the challenges are to find mechanisms for people in non-code roles to demonstrate they share the values of the Mozilla project and can make contributions that people want to support.

Right now, we’re in the early phases of both building communities focused on product management or marketing and of building those functions into our product development. We’re further along with marketing, since the spread firefox has been active since Fx 1.0 and volunteer marketing began even before that. But even so, a few years isn’t a long time. Open source has been around for decades, and there is a significant group of engineers who participate as volunteers, and a significant group whose work involves open source projects. We know what the set of activities are that lead to acceptance and leadership. That’s no so clearly the case for the set of other activities.

The heritage of open source is primarily about code; only recently about product. And even more recently still about consumer products — I often hear Firefox described as the first genuine open source product for the “mass market.” So it’s not surprising that the Mozilla project is looking at a lot of activities that are new (or new-ish) to the open source world.

We certainly don’t want to exclude people from influencing the project because they aren’t writing or testing code — this would limit the project drastically. At the same time, we maintain our technical excellence through openness, peer review, and the open source process. We need to find ways to continue to build these strengths into all of our activities.

The Mozilla project is an enormous worldwide community of people who choose to work together to produce and share technology, products and a passion for the web. The Mozilla Foundation is the official home of the Mozilla project. It has certain special abilities and responsibilities with regard to leadership of the Mozilla project and stewardship of the project’s assets.

In some ways the Mozilla Foundation is like the proverbial “tip of the iceberg.” It’s the easiest part to see, it has a size and structure that is easy to understand. But the heart of the Mozilla project is the enormous, highly motivated, loosely structured set of communities that make the project vibrant. Like the tip of an iceberg the Mozilla Foundation is a good marker for the larger reality and a good place to start an understanding of the project. And like an iceberg, one needs to go far beyond the surface of the Mozilla Foundation to understand the breadth and depth of the Mozilla project.

In other words, the Mozilla project is larger than the Mozilla Foundation and its employees. This fact should be reflected in the way the Mozilla Foundation organizes itself. Employment with the Mozilla Foundation is not and must not become the source of all authority within the Mozilla project. Contributors must have a voice within the Mozilla project unrelated to employment.

In the days before the Mozilla Foundation existed a group of people known as “mozilla.org staff” provided this voice. Mozilla.org staff was a virtual organization which governed the Mozilla project in general, and did so increasingly unrelated to any employment relationship. Some of the functions that mozilla.org staff used to fulfill now live in the Foundation — stewardship of the assets, 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 recognize, organize and legitimate the leadership of key contributors and community members unrelated to employment status. This mechanism should both (a) organize and amplify this contributor voice and (b) give this voice input and participation into the Mozilla Foundation’s activities.

We have proven policies for ensuring authority unrelated to employment in the development of code itself. We need a way to maintain and update these policies that doesn’t put all leadership in the hands of Mozilla Foundation employees. We also need to ensure contributors can provide leadership in Mozilla project activities other than writing code.

Some may ask “why?” “Why doesn’t the Mozilla Foundation simply take on the leadership and governance role through its employees?” there are many answers to this. First, the Mozilla project is an open source project. We build software through distributed authority based on reputation, peer review, proven results and ability to lead others through results rather than title. This system produces great results, allows new contributors to appear from unexpected places and join us, drives technical excellence and prevents group-think from making us complacent. The operating style of the Mozilla Foundation must reflect this DNA.

Secondly, the Mozilla Foundation does not and will not employ all the great contributors to the Mozilla project. There are far too many contributors for this to be the case. And it is an explicit goal to have volunteers and people employed by different organizations contributing to get broader perspectives into the heart of the project. Expertise and dedication will exist outside of the Mozilla Foundation’s employee base. It is critical that these contributors have an understood, identified, accepted way to participate in the Mozilla Foundation’s activities.

Those people who have been involved in the project for along time have a short hand phrase for this — we say that “mozilla.org staff needs to be revitalized to provide this role.” Framed more generally the question is: We need a way for participants to exercise leadership and moral authority in the governance and activities of the Mozilla project that is unrelated to one’s employment status. We need to articulate the scope of that leadership and authority and create a mechanism by which that voice is involved in Mozilla Foundation activities.

So far, 2006 has been a year of intense arm pain. Last December the pain in my shoulders and neck shifted from the chronic, tense shoulder computer hunch so many of us experience to something different. To pain so sharp I would wake up gasping if I tried to role over in my sleep. I’ve moved the trackball to my left hand and that, combined with a lot of acupuncture and physical therapy, has improved things significantly. Now I’m back to a chronic problem, though in my arm rather than neck. I have a suspicion that I should stop typing altogether for a few weeks and see if that helps. Until then I’ll try to get more written about what I’m working on.

Monday night I went to the Time 100 2006 dinner, invited as a 2005 honoree. There were some changes from last year, and the one that interested me the most was the response to Firefox. The event starts with a cocktail and mingle period, then moves to dinner and a dinner program and finishes up with more mingling afterwards for those who choose to stay. So one gets to talk with whoever is at one’s table and whoever one meets at the pre-dinner or post-dinner mingling.

Before I went, I wondered whether I would end up introducing myself to someone I really should know, and whether it would be awkward. The moment did come, but it turned out to be funny rather than awkward. I was talking with a few folks when another group came by. One person spoke up and said “Hi, I’m Jimmy Wales of Wikipedia.” “Hi, Mitchell Baker, Mozilla.” Lots of laughter. You’d think we would have meet before but we never had.

This year I felt much more comfortable wandering around, introducing myself and asking people their name and how they came at be at this event. In doing this I found that the number of people who recognized Firefox was much higher than last year. Last year I found that the younger crowd recognized Firefox. This time the recognition level across all groups was much higher. Not everyone recognized Firefox. But often I didn’t need to explain it; often someone else in the group would speak up first. It’s a good change.