Posts Tagged with “open source”

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

While at the Open Source convention I spent a bit of time introducing Joi Ito to a set of Mozilla and non-Mozilla open source people. Joi joined the board of the Mozilla Foundation recently, and OSCON was a great chance to introduce him to as many people as possible. One discussion was Joi, Allison Randal, Zak Greant, Cliff Schmidt and me. Allision, Cliff and Zak described their roles in the open source world, a focus on working towards consensus, on taking the pulse of the community, of keeping it healthy and an approach to problem solving. Zak outdoes us all with his organization, having found ways to track all sorts of non-coding issues in bug-tracking systems. But aside from this, we found a remarkable similarity in what the four of us think about.

For a moment it was odd, each person saying something like “I do a lot of what Allison does” or “My work sounds a lot like Zak’s.” At first it made it seem like there was nothing very special about the work. Then we realized that the O’Reilly gatherings are one of the few places where one could find enough people with this experience to make it seem mundane rather than highly unusual. Then we had a blast. It is actually a relief to find out that other people are doing similar things, finding the same problems, and trying out new things. There is a sense of adventure in having a role that is new enough that we figure it out as we go along. It’s also very helpful to have a few other people out there solving similar problems. It helps me know that I while I’m figuring things out (or “making them up”) I’m at least heading in the same direction as those I respect.

So, for example, what does it take to guide a foundation, as Allison does? Well, it takes a sense of people, and good intuition for what sorts of seemingly simple topics are likely to generate giant tensions if not handled delicately. It takes knowing when to let an issue fade away and when to make sure it is completely resolved. It takes an ability to find a common ground, and enough presence (or trust, or reputation, or *something*) to get people to consider that common ground. It turns out the rest of us either have, or wish we had, the set of skills to do exactly these things. I don’t see these as the main requirements in job descriptions or the main skillset on resumes, but each of us finds them to be fundamental to what we do. This isn’t unique to open source of course, but the use of these skills in an open source setting is pretty specialized.

I think it’s fair to say that none of us set out with this role in mind. Zak started coding (and is still the maintainer for part of that work), Allison started as a programmer (and is still the project manager for the Perl 6 project), and Cliff and I also have rather eclectic paths to our current roles. Maybe we’re self-selected to stepping in, thinking about organization and making things up when the need arises. Maybe none of us cares if others think what we’re doing is a dead-end path. Certainly moving to mozilla.org in 1999 did not look promising as a “career path.” (For those that don’t remember, 1999 and 2000 were the years when everyone proclaimed the Mozilla project a failure.) In any case, I’m interested in the questions of how open source projects self-organize and how they relate to other groups. Increasingly other creative people are thinking about this too. It’s a great time to be part of open source.

Here’s another aspect of the “organizational interface” I’d love to see enter the discussion: “What is different about working in open source projects? How much of what is different is attributable simply to the fact that bad management practices aren’t tolerated by volunteers?” Over and over again I hear people say “That’s because it’s an open source project” or “we can’t do that because it’s open source.” Sometimes these comments make sense to me.

But often when I hear this type of comment I think something like: “The course of action you are proposing won’t be liked by anyone, either volunteers or employees. If getting and keeping people motivated and producing above the call of duty is important to success, then you won’t do this sort of thing. Or at least not very often. Or if it’s really necessary, you’ll do a lot of explaining and trying to build consensus, and perhaps change some of your goals.”

Many of things that drive away volunteers (bad practices, lack of focus, bad organization) also drive employees away. It may take longer with employees, for a variety of reasons. Maybe the employees need time to find another way to support themselves before they leave. Maybe employment status has enough other benefits that on balance it’s worth it. But even if they stay, management practices that would drive volunteers away often result in dysfunctional organizations. The employees stay, but are at odds with their employer, and /or lose their commitment to the project.

On the other hand, there certainly are real differences, and open source practices such as transparency, peer review, and leadership based on reputation with one’s peers create a different dynamic. I’d like to see they dynamic better understood and adopted. I’d also like to learn its limitations through a more rigorous analysis than the current “Oh, that’s open source” meme.

Some time ago I wrote about being the “odd one out” at O’Reilly open source gatherings. Reading this makes me think of the saying “the more things change, the more they stay the same.” It’s obvious what’s changed. Mozilla Firefox has accomplished what no one thought was possible, and is the browser of choice for tens of millions of people worldwide. Mozilla Thunderbird provides an award-winning cross platform email client. I personally am known by a bunch of people in the Open Source world, and have been around longer than many (though certainly not all). The value of non-coding contributions is much more generally acknowledged, and I no longer wonder if people wonder if I’m making a contribution.

What hasn’t changed is a feeling of being on the fringes of the actual content of OSCON. This was a bit surprising, as OSCON now typically has “business” or “other” tracks besides the purely technical. So I was surprised to realize that few of them address the big topics on my mind. (I was however fascinated by the talks that Nat finds that are outside the core of open source — the Howtoons talk, the Origami talk, the BioBricks talk. These are all exciting and I’m grateful that the O’Reilly folks work to find them and introduce us to these new ideas. )

It’s not surprising that the programming part of the program isn’t my focus since I’m not doing any programming. But the open source gatherings now include an array of people who aren’t programmers and are thinking about other aspects of open source. A lot of this relates to open source adoption in the enterprise, a lot to commercial entities building on top of open source. Some relates to open source business models. Some always relates to licensing and IP issues; some addresses community building. This time I realized that none of these discussions address the core of what I’m thinking about. So that lead me to wonder: how would I describe the substantive discussions that would be fo most interest to me?

I’d like a series of discussions on the interface between open source projects and commercial organizations. There are many aspects to this interface. These include:

• Scope of people paid by the project: Apache small to zero; Mozilla significant
• Distribution of open source offerings by commercial entities: Positive effects; side effects.
• Companies paying people to contribute: Work directed by employer; by employee
• Working with commercial project and product management
• Generating funds: Necessary to support employees; risk that funds compromise decision-making or otherwise alienate the community
• Enterprise focused offerings build on / with open source: SpikeSource and SourceLabs
• Enterprise adoption: what it means from the project point of view
• Consumer adoption: what it means from the project point of view
• Inclusion of non-open source elements in a project distribution: always bad, or sometimes justifiable? (Mozilla has shipped the talkback module for many years)
• Commercial interests and multi-project interaction: OSDL, SpikeSource, SourceLabs, OSI license proliferation efforts
• Trademark considerations

These strike me as new discussion areas. We’re getting an increasing amount of information from enterprises about what’s involved in adopting open source software, and various compendiums of best practices are being developed. This is important information to understand.