Posts Tagged with “community”

Chris Beard’s recent post on being “knowable” helped crystallize some thoughts that have been running through my head, trying to find some form for expression.

These thoughts have been on the nature of “community” and its role in Mozilla. Sometimes I hear people talk about the Mozilla Foundation and/or the Mozilla Corporation as somehow distinct from the Mozilla community. I see things like “the Foundation and the community” or the “corporation and the community.” Even more pronounced, sometimes people tie the product — say Firefox, to either the foundation or the corporation, and then talk about the community as something different. Or they tie Firefox to the Corporation and view the Foundation and community as different, or separate, or outside of Firefox.

I think this overstates the role of legal structure and underestimates the fundamental role of community in all we do. The Mozilla community is not separate from Firefox or from any of the other activities in which Mozilla engages. The Mozilla organizations — Mozilla Foundation, Mozilla Corporation, Mozilla Europe, Mozilla Japan, Mozilla China — have special responsibilities related to the resources they manage (Mozilla name and goodwill, infrastructure, revenue). These assets need to be managed for community benefit; the responsibilities need to be fulfilled as a member of the community, with two-way input and communication. None of these organizations can be successful by operating in a traditional sense.

This brings me back to Chris Beard’s blog. (Yes, there is a tie 🙂 ) Chris mentioned the problem that the word “corporation” has history and meaning that get in the way of people understanding Mozilla. People hear the word “Corporation” and then associate the Mozilla Corporation with other taxable corporations rather than thinking of the Mozilla Corporation as one of many tools for accomplishing the Mozilla vision.

This is unfortunate. We formed the Mozilla Corporation as a tool for accomplishing the Mozilla mission of an open and innovative Internet. It operates to promote the public benefit. It does not operate on standard for-profit principles. The Mozilla community (including those community members who are employees of the foundation and/or corporation) would not allow it to do so.

Our best estimates are that between 30 and 40% of the code in Firefox 2 was created by people who are not employees of any Mozilla organization. That’s a giant amount, particularly because we’ve hired a bunch of long time Mozilla contributors recently, and still the amount of code from non-employees is around a third of the product. Then there are the thousands of people who participate in related activities — testing, localizing, evangelizing — that develop and promote Firefox. There are also vibrant communities focused around other Mozilla activities, from Seamonkey to the Mozilla platform.

This set of people — volunteers and employees alike — is the heart of Mozilla, the life that makes us real and gives us impact. This community does not form to support a standard corporate endeavor. It forms to support the Mozilla mission. The legal organizations of the Mozilla world exist for the same reason. They are organizational centers to help the greater Mozilla community be more effective.

Carl Malamud has started a new organization, Public.Resource.Org, that is “dedicated to the creation of public works projects on the Internet” with an initial focus of “increasing the flow of information in both directions between the U.S. government and people.”

Carl is leaving the Mozilla Foundation Board of Directors and will be focusing his time on Public.Resource.Org. During his tenure, Carl has brought his fierce determination to benefit public access to information to the Mozilla Foundation. We are a stronger organization as a result of Carl’s involvement.

Please join me in thanking Carl for his contributions to the Mozilla world, and in wishing Carl the best with Public.Resource.Org.

The Mozilla community is unbelievably vibrant and active. There is a long history of people interested in Mozilla clumping together to make things happen — this started way back in 1999 or so and continues today. Our QA effort is one example, Firefox is another, mozdev.org is another, Spread Firefox is another. In each of these settings groups of people decided something should be done to expand the reach of Mozilla, they made something good happen, and now they are integral parts of Mozilla.

The activities underway to inaugurate Mozpad are a contemporary example of the Mozilla community. There are a group of application developers using the Mozilla platform to build applications other than the browser. These developers start with Mozilla code, add other elements, and build applications and businesses. The developers get enormous value from Mozilla code, but it often does not meet all of their needs. The unmet needs might be changes to the core Mozilla platform, packaging and installation changes, or any number of other things.

A user’s group for these developers such as Mozpad is a great idea. And not only is it a great idea, but it is happening. And it’s happening through a classic Mozilla process — people see a need, self-organize, and improve the Mozilla world. Matt has come up with a name (always helpful), and is organizing an initial meeting. All those interested are welcome to attend.

Self-organizing, “doing,” and expanding the Mozilla world is a long-standing and fundamental aspect of the Mozilla community. It’s how many new things gain traction, often leading to more effective results than would come from a centralized planning effort.

As self-organizing activities gain scale and provide new benefits to the Mozilla world, Mozilla works to provide infrastructure and supporting resources. If there are ongoing activities coming out of Mozpad, Mozilla is more than happy to provide infrastructure — newsgroups, mailing lists, discussion sites, etc. — and to help get appropriate platform development requests incorporated into the general development process.

The vitality of the Mozilla community produces an astonishing range of self-organizing groups of people who move the Mozilla vision closer to reality. It’s unbelievably energizing to be part of such a community.

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.

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.

A while back I wrote a bit about search. One of the comments to that post was a suggestion / request that it would be helpful if the “Mozilla Foundation published some sort of guidelines about the processes they go through when considering and entering into these relationships.” Rather than wait until we have a full set of guidelines I think I’ll just plunge in with the first and most obvious and then keep adding.

The first and most basic guideline concerns the source code development itself: The Mozilla Foundation does not enter into agreements that try to affect what goes into our shared source repository.

The source code is a community resource. A relationship between the Mozilla Foundation and another organization cannot try to control the source tree for the benefit of that relationship. The source code is developed by a set of people far broader than the Mozilla Foundation. The Mozilla project has a long history of distributing authority to module owners, reviewers and other respected people. The job of the Mozilla Foundation is to provide coordination, guidance and leadership to these groups to produce the best possible shared resource.

The Mozilla Foundation does make decisions about the branded versions that the Mozilla Foundation distributes and might enter into agreements regarding the branded version. We would do this sparingly with a focus on user experience and user choice, but we might make some agreements about our branded versions. Future posts and resulting discussions will work through the guidelines for how we think, and should think, about this.

But the basic principle is that any such agreement do *not* bleed over into the unbranded source repository. What goes into the source tree is a community-based decision. I’ve had a number of conversations with various businesses interested in Mozilla technology, the Mozilla project and how the Mozilla Foundation operates. One thing comes through loud and clear: the Mozilla community generates respect. People often don’t understand the details of how we operate, or how leadership and distributed authority work in practice. But they do understand that the Mozilla community is greater than the Mozilla Foundation, and that working with this community is critical.

This is a big change from when I started having these discussions years ago (before the Mozilla Foundation). It reflects the growing awareness of our development methodology, and the respect for what the Mozilla project has accomplished.

Firefox represents something new for us — a release that is squarely aimed at the end-user. A great browser where power features don’t get in the way of the general user. It’s sleek, innovative, accessible to mere mortals and also packs enough punch for the most sophisticated power user. If you’ve been waiting to try Firefox or to recommend it to others until it has the official stamp of approval, now’s the time.

This release also marks a new era in our international focus. I’m not sure one can imagine how much work is involved in the localization effort until one has tried it. In addition, our localization teams are all volunteers. That’s right, volunteers. People volunteer in order to have Firefox available in the language they care about. This involves not only the actual localization, but reviewing and verifying all aspects of the localizations, waiting for our build cycles to complete, working at odd times to hook up with everyone else and helping the Mozilla Foundation figure out how best to manage such a massive task. And of course, all this needs to be done on a very tight timeframe. I am regularly astonished by the outpouring of support for the Mozilla project, and the localization effort is a perfect example.

In addition to improved localization, Firefox 1.0 also has integrated search capabilities, both in the Search Box and in the startpage. We know that search is a critically important feature of the web, and we’ve worked to make Firefox’s search functionality as useful as possible. Firefox ships with a set of search plug-ins, allowing the user to select the search engine which works best for his or her needs. In addition, one can choose to add a broad range of additional search engines quite simply.

In keeping with our emphasis on the end-user, we have redesigned the Firefox startpage. We wanted a startpage that reflected the Mozilla project and provided a good access point to the web. Given the importance of search, we decided to add search functionality to the start page itself. Google has long been recognized as a leader in search experience and so we chose Google.

We provide access to search services from a range of sources including Google, Yahoo, Amazon, eBay and others you can see in Firefox. We expect to see some funds come to the Foundation as a result of our integrated search. We’ll use any funds that result to help support the Mozilla Foundation’s non-profit operations. When finances are involved questions often arise about their influence on an organization and we’ll spend some time talking about this as we go forward.

For now, I want to express my admiration for the vitality and commitment of the Mozilla community. The Firefox 1.0 release builds on the work of hundreds of programmers and QA contributors and thousands of participants. It also highlights the efforts of new groups of participants, including:

• the Visual Identity team — a new group of volunteers that has brought great polish to Firefox, our new mail client Thunderbird, and our website;
• Spread Firefox — the admins who spearhead community marketing campaigns, and the thousands using their creative energy to let others know about Firefox;
• Mozilla Europe and Mozilla Japan — our international affiliates who assist with all manner of activities for users outside of the United States;
• an increasing number of people employed to work on Mozilla technology, some within the Mozilla Foundation and many funded by other entities; and
• the millions of people who have downloaded the Firefox preview releases.

The breadth and depth and innovation of the Mozilla community continues to bring unprecedented results. Mozilla Firefox is a great browser, and a testament to the thousands of people who have contributed their energies to bring innovation, creativity and choice to the web.

Rediscover the Web — Get Firefox

“Community” in the open source world is one of those words that seems obvious at first, but is actually pretty elusive. For those folks who saw r0ml’s talk at OSCON, community doesn’t mean what you think it does. “Building” and “managing” communities are even more elusive concepts. What is it? Who does it? Does it have value? If so, who does it benefit? Is it simply overhead?

I’ve been thinking about community building and management for a while now, and have had periodic and unstructured talks with folks such as Danese Cooper at Sun, Louis Suarez-Potts of OpenOffice, Brian Behlendorf and Ted Leung of Apache, David Axmark of MySQL, Chao Lam of OSAF, and of course mozilla.org staff. Lots of talk, but nothing organized. And to date, there hasn’t been a good way for discussing issues of interest to all of us. We’ve talked about organizing something related to community building, but never gotten to it.

Then this year at OSCON, something surprising happened. Two separate activities related to understanding “community” occurred. First, Zak Grant of MySQL came to talk to me as part of a survey MySQL is conducting about community-building. I’m always glad when I see the MySQL folks get involved in something I care about. To date, they’ve been organized, gracious, diligent and effective in the areas where I see them in action. It was late when Zak and I found a chance to talk so I can’t recall the specific questions, but I do recall an interest in both learning and communicating what other projects have tried, what works and what doesn’t.

Then on Thursday evening there was a Birds of a Feather session on “Managing Community.” It was quite astonishing to see this on the agenda. I was late so didn’t hear exactly how it came to be, but I know that Karim Lakhami, a graduate student at MIT’s Sloan school, was instrumental in getting this set up. Karim’s listing of academic studies relating to open source is a great resource. I think some combination of Chris DeBono, Michael Tiemann and Stefano Mazzocchi may also have been involved in organizing this. There were probably about 25 people for the 2 hour BOF, and we covered a lot of ground.

We started out comparing projects which are driven by individual developers doing what is of interest to them with projects like the Mozilla project where there is an overall roadmap and some degree of project-wide planning and prioritization which affects (or at least informs) what developers work on. The choice of the Mozilla project was not mine; I believe it was Michael Tiemann who suggested it. As a sidenote, I would say that the response to the Mozilla project was very different this year. In the past, we’ve been accepted as important, but not the focus of much real excitement as OSCON. This year was different. Mozilla Firefox and Mozilla Thunderbird are changing the way people think about the Mozilla project, and that change was palpable. Perhaps some of the change may be that we are no longer in the shadow of a corporate sponsor. Stefano may this case clearly when he noted that now he sees some reason to think about fixing the bugs that bother him rather than wait for someone else to do it.

There was a discussion about corporate involvement, and the difference between companies paying employees who work on open source projects as individual contributors (think IBM and Apache) and companies who have corporate teams chartered to work on open source project through the management structure (think Sun and IBM with the Mozilla project). This in turn lead to an eloquent description from Stefano of the Apache view of collaborative development, and how the need for working together trumps hot-shot hackers. The more people I meet at Apache the more I am struck by the degree of focus on work-style, community building and management. Someone, I believe Sam Ruby noted that sometimes an active community does not develop until the original developer steps back, citing Gump and Cocoon as examples.

We also talked about how important a name can be for a project. Sam Ruby noted this, the Jabber folks agreed, and I had to grimace and note how the Mozilla project learned the same thing through our iterative renaming process that finally resulted in Firefox.

One topic we didn’t discuss much is a sort of historical record. I would love to hear people describe the early phases of their projects, who the first people were to get involved, what the early community looked like, how it grow, what made it grow and so on. Maybe next time.