Archive for August, 2005

One of the sessions at the Open Source Convention was a discussion about women in open source — why there are so few, are there hidden barriers, etc. Some research suggests that the percentage of women participants in the open source world is as low as 1 or 2%. The session was very well attended, by both women and men, and the questions went well over the allotted period.

The panel had six participants. Two of us — Allison Randal, president of the Perl Foundation, and I — have visible outward-facing roles in our projects. Someone asked if we thought this made a difference to the number of women programmers in our projects. I had to answer “no” because the Mozilla project does not seem to have a lot of women programmers in the core. There are a number of women in the project who I respect highly, but we’ve found or created roles for ourselves other than programming.

So I wonder why this is. And I wonder if this reflects general difficulties in finding a foothold in the project. Are we missing good contributors because of some approach or style that we’re not even conscious of? Is there something that affects women more than men?

A couple of open source projects have started mailing lists to discuss issues that might affect involvement by women. Perhaps the Mozilla project should as well. Or perhaps a combined discussion covering open source projects in general is more helpful; I think such a list may be in the works. In the meantime, if you’ve thought about getting involved in the Mozilla project but found that something in our approach or attitude or style prevents you from doing so, I would be very interested in hearing your story.

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.

The Mozilla Foundation has created a wholly owned subsidiary known as the Mozilla Corporation to help achieve the Mozilla Foundation’s goals of promoting choice and innovation on the Internet. We’ve done this to respond to the success and growing market-share of Mozilla Firefox and the new opportunities this makes possible. Mozilla Firefox is approaching 10% market share, with figures showing usage several times higher in selected groups and countries. We’re reaching the point where Mozilla Firefox is becoming a significant element of the Internet experience and has growing influence within the Internet and software industries.

This presence brings a range of opportunities. Many of these opportunities involve working with other commercial entities. Some involve generating revenue. This is an exciting time, both because our products are so well received and because the opportunity for the Mozilla Foundation to become self-sustaining in terms of revenue makes the long term vitality of the project much greater.

The Mozilla Corporation is created to respond to these opportunities. Non-profit law is reasonably well understood for traditional non-profit organizations like museums, universities and the traditional style of charities. But organizations like the Mozilla Foundation, which develops and distributes consumer software, are new in the non-profit world and the application of nonprofit laws to their activities is a developing area. We’ve found that this uncertainty makes responding to Mozilla Firefox’s success very complex. It is difficult to know what relationships with commercial organizations make sense for a non-profit or how to structure them. It is difficult to know what activities the non-profit should and shouldn’t engage in. It is difficult to determine what ways of generating revenue make sense for a non-profit and which ways of generating revenue are not appropriate.

The Mozilla Corporation has been created to address this. The Mozilla Corporation is a taxable entity and so is legally permitted greater freedom of action that is the Mozilla Foundation. The Mozilla Foundation will use this ability to interact with commercial entities and to generate revenue only in those cases where doing so meets the goals of the parent. In other words, its goals and mission are the same of the Mozilla Foundation, only it has greater flexibility in how to meet them. If it makes sense to generate revenue (as we currently do through search relationships) the Mozilla Corporation will look at doing so.

The Mozilla Corporation is legally a taxable, or in general terms, a “for-profit” entity. However, it is not a typical commercial entity. Its purpose is not to generate a return on investment in the financial sense. It is not an investment vehicle or an IPO candidate. It is completely owned by the Mozilla Foundation to promote an open Internet, where consumers have choice and innovation thrives.

More information about the Mozilla Foundation and the Mozilla Corporation and the relationship between them can be found at: www.mozilla.com or www.mozilla.org/reorganization.

The health of the Mozilla project, its long-term sustainability, and its role in maintaining diversity to the web is critical for the web. The Mozilla Foundation is extremely important in this goal, and extremely important to me personally. Many people, myself included, have worked for years to see the Mozilla Foundation come to life, the Mozilla project grow and tens of millions of people choose Mozilla products. The Mozilla Corporation is another organizational tool to bring these goals about.