Posts Tagged with “governance”

Periodically I hear people say things like “the community will decide.” Or “let the community handle it.” This has always sounded amorphous to me and I’ve finally realized why. This way of looking at things assumes there is little clear leadership and no actual decision-maker. This is a misunderstanding of many open source projects, which have real leadership and ultimate decision makers. For example, Linus Torvalds makes decisions for the kernel, Apache has a committee system, Brendan is responsible for technical decisions in the Mozilla project. In the Mozilla project we try to delegate authority so that:

• many decision-makers are involved in their areas of expertise;
• an ultimate decision-maker exists but is involved only when necessary; and
• decision-makers are chosen and evaluated by their ability to provide leadership that draws in other contributors.

This last point is extremely important. Decision-makers who don’t provide leadership make it hard to build a good project. Decision-makers who people don’t want to follow will struggle. Open source software always gives people a choice. Participants are always free to try something different using the same underlying code. So the decision-maker’s role has many facets. Basically it boils down to making enough decisions correctly enough that people continue to choose to participate. In other words, leadership.

Other projects may invoke the authority of the ultimate decision maker more or less often. The important point is that many open source projects incorporate clear decision-making into their processes.

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 has always been a pioneer in bringing new functions and roles into an open source project. In the early days, this was integrating open source DNA with commercial organizations. A number of people are doing this day, and we’re still learning new things ourselves. Another topic in our world today is the additional of people in non-engineering roles. We’ve generally had a small amount of non-engineering personnel — though for many years this meant me. When the Foundation was formed Bart Decrem joined as our second non-technical person. About the time Bart left Chris Beard joined and picked up a range of non-technical topics. Today we have more such people. This includes roles such as:

• product-wide coordination (this role is often known as “product management” but I’m wary of this label because anything with the word “management” in it generates all sorts of reactions),
• communications and outreach (some of which is generally known as “marketing”, some of which is quite new like the Spread Firefox work),
• working with other organizations in the industry who want to build on our work (classic “Business Development” and “Partner Relations”).

This raises many interesting questions. One is that the open source community is not nearly as rich in home grown expertise in non-engineering areas as it is in developers. So filling these roles often means bringing in people who haven’t “come up through the project.” These folks who are new to the Mozilla project need to be accepted by the development community in order to be effective. Status as a Mozilla Corporation employee isn’t enough.

Another issue is that we don’t have an established path to meritocracy for non-technical roles. For potential developers, we know about several paths for getting involved and developing legitimacy — we know about the Quality Assurance path, we know about fixing bugs, we know something about hacking on the code, we know about writing a great extension and so on. We also have clear ways of identifying a person’s known expertise — they may be a peer for code, a “module owner” for code, etc. All of these are reasonably well understood roles within the project that convey a person’s expertise.

We don’t have analogous paths for non-engineering roles. We don’t yet have ways for the non-engineering staff to indicate the scope of expertise of their colleagues. And we are just building a core group of product coordination, community and partner relations (aka product management, product marketing, marketing, business development) contributors whose judgment and commitment to the project are understood by the technical teams to equal their own.

Itegrating non-engineering contributors takes a lot of trust and feeling our way gently. Those people joining us in non-engineering roles must trust that the technical contributors will give them a fair chance to participate, add value, become respected and gain influence and leadership. The engineering community must trust that these people who may be new to the Mozilla community and don’t have deep technical expertise are worth listening to and giving a fair shake.

Periodically I say or write something like “Please give this person the benefit of the doubt. If they seem off on a path that feels really wrong to you, please say so gently. Assume they are unaware of some relevant fact. Assume they are trying to do the right thing. Don’t assume they are evil, or out to change the project or claim control.” It’s generally worked so far, but it reflects the newness of these sorts of positions to our project (and I think, open source projects in general).

Relying on trust is a funny thing. One absolutely needs it. A well-known system for gaining respect and influence doesn’t mean much if participants don’t trust each other. And, who wants to work in a world that’s full of mistrust? But relying on trust alone without any guidelines is difficult in the long run, is intensely personal and leads to people needing to “reinvent the wheel.”

I’m interested to hear what other projects do, and if there is any general learning on this subject. In any case, we’re working through these issues now. No doubt both our successes and our missteps will be apparent 🙂

I was just reading Blake Ross’s comments about his discussions with various student newspapers and their participation in link farms. In a couple of places Blake makes the point that “the ends don’t justify the means.” I agree completely, but have long felt that this is an inadequate analysis. The means are important because the means become a part of the end result. They are not separable. There’s no magic line where suddenly the methods used fade away and the pure, untarnished goal spontaneously appears. The path one takes affects the location one reaches.

There may be cases where one needs to use unpleasant means to get a desired result. I don’t disagree — there are some cases where the methods we prefer will not get a necessary or critically needed result. But unpleasant means affect people, and that result doesn’t simply vanish one day and leave everyone with a pure, shiny and perfect thing. Violent methods will leave a mark on the result.

In the particular case Blake cites, maybe link farms are necessary to sustain student journalism. (I’m not agreeing with this statement, only noting the possibility that it is correct.) Blake notes the end doesn’t justify the means. I’d go further and say that the use of link farms, which aren’t about journalism, will affect the sort of journalism that they sustain.