Posts Tagged with “community”

Concentric Circles of Community

July 7th, 2008

I’ve come to think of Mozilla, or “the Mozilla community” as a set of concentric circles of communities. Actually, I’m thinking of Mozilla as concentric spheres of community, but I’m going to stick to circles for this post.

For me the ability to be more precise about “community” is important in thinking about what Mozilla is, what more we might do, what the Mozilla Foundation might do, what the essence of Mozilla is that we want to be very careful about changing, and which areas we should try to go wild in and try lots and lots of new things.

I’m going to borrow a set of terms from the Wikipedia discussion of “community.” There’s some risk in this because these terms may have academic background and meanings associated with them. But I need some set of terms and this seems a better start than just making them up.

Specifically, I’m thinking of 4 concentric groups: a Community of Practice, a Community of Action, a Community of Interest and our User Community.

I’m very interested in whether people living and working Mozilla feel these distinctions describe the different communities in which you participate and with which you interact. Let me know!



According to Wikipedia, the word “community” is “derived from the Latin communitas (meaning the same), which is in turn derived from communis, which means “common, public, shared by all or many.”

Community of Practice

At the heart of the Mozilla world is a set of people who share many things. We share code. We share goals. We share a set of values (the Mozilla Manifesto). We share specific means of collaboration (from Bugzilla to IRC to wikis), information repositories (source, documentation, website), a decision-making structure (module ownership), and a clear set of basic rights (the Mozilla Public License). We share activities — distributed creation and adoption of specific products that promote choice, innovation, transparency and participation in Internet life.

That’s a fair amount to share. So on my own I’d add some adjectives and describe this as a dense or cohesive community. But rather than make up adjectives I’m going to borrow the term “Community of Practice.” Wikipedia describes this as “social learning that occurs and shared sociocultural practices that emerge and evolve when people who have common goals interact as they strive towards those goals.”  I like this definition because it is not focused on a particular group or activity. We have many different types of activities that are part of this Community of Practice.

Community of Action

The next concentric circle is a set of people who take action to move the Mozilla mission forward but do so in more open-ended ways. For this set I’m adopting the term Community of Action. The people in this group may share our values, our goals, our decision-making processes for example, but develop their own ways of collaborating and their own sets of activities.

Wikipedia describes these as “structurally more open” and possessing both “some of the characteristics of communities, such as the development of a common language and mutual learning in the course of action . . .  [and] characteristics typical of more associative social relationships, such as the “voluntary” nature of association and the importance of “common goals” in directing collective activity.”

I see the boundary between this and our Communities of Practice as fluid. Sometimes these activities become so important and scale to such a size that they become more formalized. In this case some of the spontaneity may be exchanged for additional resources, scale and better integration into the core.  The long term history of localization is an example. In the early 2000’s localization of Mozilla products was extremely distributed, with many different groups working on their own. Today internationalization and localization are a fundamental aspect of the core of what we do; deep into our Community of Practice.

Community of Interest

Beyond this there’s a set of people who aren’t actively involved in creating Mozilla artifacts but are very supportive of our product or our mission. This group my not share our means of collaboration, our decision-making structure or our basic statement of rights. But they share in goals (sometimes general goals; sometimes  specific goals), in the use of the code, and they may share the activities of finding and helping others use our code.

Loosely borrowing from Wikipedia again, I’d call this the Mozilla’s Community of Interest: “A Community of interest is a community of people who share a common interest or passion. These people exchange ideas and thoughts about the given passion, but may know (or care) little about each other outside of this area.”

User Community

An ever larger circle is the set of people who use our products. Some of these people are also in earlier concentric circles. But a number are not. They use Firefox because it’s a great product that meets their needs. Maybe do not know that Firefox is created as a public benefit asset; many know little to nothing about the way Mozilla operates or the goals that motivate the Communities of Practice, Action and Interest. I’m calling this our User Community. This is not a Wikipedia term; I’ve added it because it’s important to us. This group of people gives our efforts weight and effect, helping us move the Internet towards greater openness.

All of Mozilla exists within broader contexts, such as the open source world or the Internet space, etc. That’s a lot to say there. But for now I’d like to get some shared terms for the Mozilla communities. This will help us figure out what parts of the Mozilla community we’re talking about or trying to address in different circumstances.

I’m very interested in whether these circles and the labels is useful in thinking about the Mozilla community. Any form of feedback welcome — here, email, talkback, twitter, you name it.

Figuring out the meaning of “community”

July 3rd, 2008

I’d like to keep improving the ways we describe Mozilla in general. It would be helpful to have some greater specificity around some key concepts we use regularly. “Community” is one such concept.

We talk about “community” at Mozilla all the time. A lot of other people talk about “community” as well. People use the word “community” to mean many different things. Sometimes “community” is used to describe a coherent, structured group and sometimes a diffuse, permeable set of people.

To get greater specificity I started with dictionaries and encyclopedias. The Wikipedia discussion of “community” is very long, and has many sub-parts to it. At first I thought it was too complex to be helpful. But as I’ve started talking more with people about the Mozilla identity and goals, I’ve come to think that some of the Wikipedia characterizations of  different types of communities might actually be really useful. I’m about halfway through describing Mozilla communities and will post that as soon as it’s coherent.

If anyone has definitions of “community” they think are helpful to understanding Mozilla, please leave a pointer.

Incubator Repositories Proposal

June 6th, 2008

Stuart recently described the need to allow improved collaboration with groups of people in specific circumstances: changes to Mozilla code that are larger (and possibly more experimental) than individual patches and where the new contributors don’t yet have commit access to the source tree and where existing Mozilla contributors want that collaboration to occur within a Mozilla-hosted source repository.

At the same time, our policies for determining who has commit access are critical to maintaining the quality of our work; we certainly don’t want to change that.

We (Brendan, Stuart and I) have come up with a proposal that we think gives us some flexibility without changing the rules for obtaining commit access to mozilla-central. It includes a mechanism for allowing such collaboration plus a description of the logistics such as how to file a bug for individual access and get it closed. Comments are welcome here or in the Governance newsgroup. (You can also participate through the mozilla.governance Google Group. )

Incubator Repositories

Incubator Repositories are a tool available to module owners in the following circumstances:

  1. the module owners are engaged in significant cooperative development with contributors who are not yet experienced enough with Mozilla to have commit access to the Mozilla source tree; and
  2. it is impractical to break contributions into bug-sized patches and follow the standard review and check-in process, either because the scope of work makes this difficult, or the work is experimental and a precursor to patches that will eventually end up in Mozilla-central or another reason the module owners can describe persuasively.

In other words, an Incubator Repository is a temporary repository hosted by Mozilla where we allow people to check code in before they have official source code write access for our production code base. An Incubator Repository is not needed for repositories where all contributors have full source code commit access.

An Incubator Repository should meet the following conditions:

  • An incubator repository requires 2 module owners to be committed as sponsors.
  • The work is important to Mozilla’s stated development roadmap; Incubator Repositories are not a hosting site for potentially-related work.
  • The work is not duplicative of work in mozilla-central. There is some possibility that duplicative incubator repositories are possible, we can look at that if the setting arises.
  • Incubator branches are temporary. In general, an incubator branch probably shouldn’t last longer than six months. By that time it should be clear whether the work has potential. And if it is an effective branch, there should be enough activity from the contributors to determine which if any of them are ready for commit access. However, setting a one-size-fits-all date for all which must be tracked for its own sake requires a bureaucracy to track and manage that. Instead, we’ll say that six months is the general timeframe. For a branch to last longer, the sponsors should have a good rationale why this is the case, they should ideally make that rationale to the Incubator Repositories module owner, and they must make that case effectively if the Incubator Repositories module owner or peers ask.
  • Incubator Repositories are publicly available repositories just like mozilla-central.
  • Incubator Repositories incubate both code and people. They are not training branches where the code doesn’t matter. They are not intended to provide examples of coding to evaluate someone’s readiness for commit access; we have policies for that. They are intended to help the sponsors make progress that otherwise wouldn’t be possible while new contributors learn about Mozilla and become known to Mozilla.
  • Participants in an Incubator Repository may also develop patches that relate to the work in mozilla-central, for example a patch relating to start-up performance. When this happens, the patch or patches in question should be submitted through the standard process. This not only improves our code, but it provides a chance for the author’s work to become known, which is necessary for commit-access outside the Incubator Repository. The sponsors are responsible for encouraging this process.
  • There is no right of potential contributors to have an incubator repository because it is easier for them. There is the ability of existing module owners to sponsor one.
  • The sponsors are responsible for the operation of the Incubator Repository.

Logistics and Operational Parameters

  • The creation of an Incubator Repository must be approved by the owner (or a designated peer) of the Incubator Repository module. (This is a new module which we will create as part of the implementation of this policy assuming it is approved.)
  • The proposal should describe why the Incubator Repository meets the required conditions, who the sponsors are, hoped-for results of the Incubator Repository, the approximate number of people likely to be given check-in access through this process, and any possible effects on other parts of Mozilla.
  • The proposal should also be filed as a bug and also posted in the relevant newsgroup.
  • The sponsors are responsible for figuring out a reasonable system for getting code from the Incubator Repository into mozilla-central. “Reasonable” generally does not mean dropping six months of work on reviewers and asking for code review. Sponsors may meet this responsibility by using Mozilla code-review techniques in the Incubator Repository or by other means, but they are responsible for getting code review in reasonable increments.
  • Anyone checking into an Incubator Repository must have signed a CVS Contributor Form on file with the Mozilla Foundation.
  • Once approval for an Incubator Repository has been granted and recorded in the appropriate bug, the sponsor or Incubator participants should file a bug asking for commit access for that person for the Incubator Repository. Details on filing the bug and getting it closed are below.

Incubator Commit Access

Here’s a list of the steps that need to happen to get Incubator Commit Access.

  1. Make sure the creation of the Incubator Repository to which you wish access has been approved.
  2. File a bug. Product:; Component: CVS AccountRequest. Don’t change the Default Assignee or the Default QA Contact. Your summary should say something about creating an Incubator Account (“Incubator Account Request – John Doe <> “). You should also include in the bug a pointer to the earlier bug in which the creation of the Incubator Repository in question was approved.
  3. Each of the two sponsors should comment in the bug saying s/he’s sponsoring the Incubator Repository and your participation in it.
  4. Make sure to include your CVS SSH public key as an attachment to the bug. (Please mark it as text/plain when attaching it!) Note that you will need to attach an SSH key for all types of access.
  5. Complete the Contribution Form and fax it to the location specified on the Form.
  6. Update the bug to note that you’ve faxed in the Form.
  7. An appropriate Mozilla representative will update the bug to say whether s/he has received the faxed Form.
  8. Update the bug when all the needed info is in the bug. This way, Bugzilla can send off mail to the Mozilla representative tending to accounts.
  9. The Mozilla representative will double-check that the needed info is recorded and, if so, create an account.
  10. The Mozilla representative will then reassign the bug to IT to have your SSH public key added.
  11. A Mozilla IT representative will update the bug with account creation information and close the bug.

Upcoming “Firefox Plus” Summit

May 13th, 2008

For the last couple of years the Mozilla Corporation has organized and hosted an event known as the “Firefox Summit.” We’ve done this twice so far; once after the release of Firefox 1.5 and once after the release of Firefox 2. The Summits have been a gathering of the people most deeply involved in creating the just-released product, and likely to be deeply involved in the design and creation of the next version. The summits are part celebration, partly closure, and mostly planning and consensus building for the future efforts.

The Summits bring together a range of contributors, both volunteers and those employed by Mozilla and other organizations. The fundamental goals are to build closer bonds between contributors who rarely meet face to face, and to do serious planning and focusing for the future Firefox work (including the underlying platform). We also try to have some fun, of course. 🙂 Mozilla funds participation — travel, lodging, food, etc — for our volunteers. Mozilla Corporation employees are expected to attend, others attend by invitation.

We’ll be having another Summit this July. This time we plan to expand the focus a bit to move beyond Firefox and the platform technologies that make work. The main focus will still be Firefox and the technology that underlies it — that’s still the key that so much of our vitality. This includes discussions about how our products and technologies can and should move the Mozilla vision forward. And we’ll undoubtedly have discussions about building strong communities, this is an element that runs through every Mozilla activity.

Eventually it would be great to have a broader Mozilla Summit, discussing not only our technology and products but also the range of other activities that the Mozilla project is, or should think about, undertaking. We’re not ready to plan and take that one quite yet, but it’s time to see if we can broaden the focus somewhat.

We’ll clearly broaden this to include Thunderbird, email, and Internet communications. That’s an official Mozilla product that shares our technology and the Mozilla mission. We’ll undoubtedly broaden this in other ways; mobile, Weave, data, and Prism are obvious candidates.

So while we’ll probably refer to this as the “Summit” or the “Firefox Summit,” its official, somewhat-awkward name is the Firefox Plus Summit. If we knew exactly the scope we could figure out a more precise name. I came up with this name to be clear about what we do know: most discussions in the context of Firefox, not completely Firefox, not aiming to cover the entire possible scope of the Mozilla project.

We’re just starting to plan for the Summit. This includes invitees, content, how to get the most input into the discussions and how to get the results dispersed to greater audiences. We hope to make progress in the next couple of weeks, and the bulk of the content development will happen as more and more people finish up their work on Firefox 3.

Mozilla: Celebrating the First Ten Years

January 22nd, 2008

2008 is a year to celebrate — Mozilla turns 10 this year. 10 years of open source history, commitment, product development, community building and accomplishments. An open source project of astonishing scope and diversity. A portion of the Internet that is more open and participatory than almost anyone imagined. A strong voice for what the Internet can be. That’s 10 amazing years.

2008 is a year to celebrate our history, our accomplishments, our community and our future. We have laid the groundwork for another great 10 years — years where we can influence the web for the better, demonstrate what openness, transparency and broad participation look like, marvel at the distributed excitement and fierce dedication to the Mozilla vision for the Internet, and do things we haven’t even dreamed up yet.

I really do mean a year to celebrate. Not one day, not even the actual date the code was released. That’s an important date and we’ll certainly celebrate it. But the code release was one part of what was a much larger effort 10 years ago, and is a much larger story today. 1998 saw some great accomplishments, and we’ll celebrate them this year. The project has seen great accomplishments all through this first decade, and we should celebrate these as well.

I don’t have precisely formed ideas yet for how we ought to mark our anniversary events. In general though, I’m intent on making sure that our activities are:

a) International in scope: notable events that take place around the globe.

b) Participatory. We’ve had crate-your-own parties in the past; that’s a good start. ‘d like to see us do some other things as well this year. Perhaps we might have a way for people to record their experiences with some event in Mozilla’s history. Perhaps we will create a timeline where people can note the various events they feel have been critical to the Mozilla project (this is not my idea). These are only early ideas; there’s lots of room for creativity here.

c) Varied.

d) Fun.

If you’ve got ideas, let me know (or Mary Colvig — mary at mozilla dot com). We may come up with some other tools for making planning easier, but comments here are a good start.


September 19th, 2007

As those of you who read know, last weekend was the Mozilla24 event. A lot of people have written about Mozilla 24 and I won’t repeat a general description. The thing that struck me was the power that the infrastructure can bring, and how the infrastructure really can bring people closer. Typically in the Mozilla world we’re focused on software (obviously!). We recognize the critical nature of the underlying infrastructure that we live on but don’t spend our days building it as we do the software layer. And so the proposal for Mozilla 24 seemed daunting to me, given the massive amounts of infrastructure needed to provide real-time video conferencing across multiple continents. But Mozilla 24 was spear-headed by Mozilla Japan with the significant assistance Dr. Jun Morai. Dr. Morai is known as the “father of the Internet” of Japan, is a VP of Keio University, a member of ICANN and the Internet Society, and a long time friend of Mozilla Japan.

Dr. Morai is also the chairperson of the WIDE project which seeks to put this infrastructure to use for social benefit. I found Mozilla24 to be an eye-opening example of how powerful an idea this is. I attended the Mozilla24 event at Stanford University. It was a very nice facility — thank you Stanford! The room had 3 large screens. Generally one showed the presentation, another showed the audiences in other areas and the third often showed the Mozilla 24 photo stream. What surprised me was how strong the feeling was of “touching” and “seeing” the people in other locations. The images were good enough, the audio was good, and the transmission lag was so small as to be unnoticeable for much of the time. I participated in the last segment, which was the Kids” Summit, followed by a discussion with Dr. Morai and Dr. Cerf. It really was possible to have a discussion, to watch Dr. Morai, the discussion leader and feel as if he was “right there.” At one point Dr. Moral was speaking to the Kids’ Summit participants, suggesting we’d kept them long enough and it was fine for them to go home. After the children from Japan left he turned to the children from Thailand and suggested they were free to go as well. I thought to myself “Wow, I didn’t know the participants from Thailand had gone to Japan; I thought they were all at the University in Thailand.” But of course, they *were* in Thailand. Dr. Morai is simply so comfortable with this technology that it’s impossible to tell from watching him whether he’s talking to people in the same room or someone thousands of miles away.

Of course, Mozilla24 was an enormous amount of work. The Mozilla Japan team showed once again that they are masters of organization, and of bringing Mozilla DNA to well-organized, professional quality events. And the rest of the Mozilla world jumped in to make a rich program.

Mozilla24 has made it clear to me once again how Mozilla is part of a much larger effort to bring openness and participation to *all* levels of the Internet stack. It made me realize once again all the different things that the Mozilla community is and does.

Open Tools for a Better Web

September 5th, 2007

Good tools are a developer’s dream. I’ve been hearing the lament for better open source tools for open technology stacks ever since I started working with Mozilla. Today ActiveState is announcing the Open Komodo Project, bringing new open source tools for web developers into the Mozilla world.

ActiveState has been a participant in the Mozilla project for many years. Its award-winning Komodo IDE is build on Mozilla technology. ActiveState has been continuously building non-browser applications based on the Mozilla platform longer than almost anyone.

One of the goals of the Mozilla project is to create a world in which commercial organizations can and do make rational business decisions to promote open software and the open web. Today ActiveState takes another step on that path. And web developers have the promise of better open source tools to make their work easier. That makes today a good day indeed.

Thunderbird and the Mozilla Mission

July 27th, 2007

There has been some interpretation of my Thunderbird /mail post as saying that Thunderbird doesn’t fit into the mission of the Mozilla Foundation. This is not my view at all. If Thunderbird didn’t fit into the mission, then we would be having a very different discussion. For example, Option 2 of my original post — a separate organization inside the Mozilla Foundation — would not be possible if Thunderbird didn’t fit within the mission.

The Mozilla mission is very broad; broad enough to encompass many aspects of human interaction with the Internet. This includes the work we’ve always done and the long-time Mozilla projects and products. It also includes a range of new activities that could be undertaken.

The question is: How does the Mozilla Foundation best serve its mission? Where does it focus? How do we develop maximum participation in our software development and in improving the quality of Internet life?

Until now the guidance of both browsing and desktop email related work has been in a single organization which today is the Mozilla Corporation. Most of those closely involved in the daily development believe this is not the best solution. (The question of why we believe this is another broad theme, which I’ll address in a separate post.)

The “Call to Action” is a public call to help figure out a good solution. It might well be that we end up with Option 2, in which Thunderbird efforts remain completely within the Mozilla world. Currently the two lead developers are currently leaning toward Option 3 which I believe is due to the desire for simplicity in getting started. The other options are on the table precisely because Thunderbird is indeed within the Mozilla mission and none of us wants to see it decline.

The Call to Action is also a request that those people interested in committing time and energy to developing Thunderbird step forward. The Thunderbird community is currently small. We’re trying to find out who is ready and able to contribute. Community vitality is a fundamental part of Mozilla’s mission. So please do speak up if you are interested and able to be a part of Thunderbird development going forward.

Similarly, the Call to Action for a broader mail initiative is to see if there are people interested, competent and ready to get involved in a serious way. This is not walking away from mail, it is an invitation for those interested in such a project to step forward so we can evaluate what is possible.

Mozilla has resources to apply to these efforts, including funds. We are trying to figure out the best way to use resources effectively. This includes Thunderbird, this includes a potential new approach to mail, and it includes new ideas that may emerge over time.

The Voice of Mozilla

July 18th, 2007

Who is the voice of Mozilla? Each and every contributor, that’s who. Every contributor has a reason for contributing, a story about how and why we contribute and why we care about Mozilla.

It’s important that many of these voices be heard. It’s important that Mozilla contributors feel comfortable publicly describing our involvement with Mozilla.

We have some formal mechanisms for public speaking. Mozilla sends speakers to a number of conferences; we have the Mozilla websites to describe Mozilla, we occasionally have a press release.

The formal mechanisms are important. But they are not enough. They are not enough to convey the richness of the Mozilla project. They are not enough to respond to all the requests for speakers we receive. And they are not enough to convey the Mozilla message of participation, openness and public benefit.

To convey the Mozilla message properly, we need many people to speak about Mozilla, to speak frequently, to speak to local users groups, local community groups, schools and local technology conferences about Mozilla. We should be clear about the scope and power of the community that make up Mozilla.

We should also help contributors feel comfortable speaking. A good framework should do a few key things:

  • help contributors feel comfortable and empowered to speak publicly about our roles and involvement;
  • provide some basic answers for common questions; and
  • help people send questions outside their particular areas of expertise to the right people.

Our contact person for developing a Speakers framework is Mary Colvig. The beginnings of this work can be found at the Events section of the Mozilla wiki.

If you’re a Mozilla contributor who currently speaks about Mozilla, or who might want to speak about your involvement with Mozilla, or if you want to help develop the framework, head on over to the website and add your voice.

Search Committee Nominations Open

June 18th, 2007

It’s time to create the full search committee for the Foundation Executive Director position. I previously posted key requirements. I’ve included them again below, along with some criteria our executive recruiter has found to be important in the past.

If you are interested in being part of the search committee and believe you meet (at least most of) the criteria, please contact me. If you know of someone you would like to see be part of the search committee other than yourself, please let me know. In other words, nominations and self-nominations are welcome.

I thought about creating a clear process for nomination and selection, but decided we can (hopefully) start informally and create process as we go. The one process point that I will start with is that if you contact me privately, or nominate someone else privately, I won’t make those names public until the named person is OK with this. If you have strong thoughts regarding the process, you can post them here as comments or in the governance newsgroup (available via newsreader or mailing list, or via the browser).

So please don’t self censor based on shyness, or on your employer.

Everyone should have:

  • Deep understanding of the project and our culture.
  • Ability to communicate the needs of the organization.
  • History of “doing” things within Mozilla.
  • Broad respect from chunks of the Mozilla community.
  • Ability to internalize different perspectives.
  • Ability to work collaboratively, incorporating other perspectives.
  • High discretion, including perhaps willingness to agree to confidentiality obligations (we need to figure out how to treat candidates properly). However this is handled, we need a complete commitment to confidentiality.
  • Commitment to speaking with one voice as a committee.
  • Ability to be a liaison between the search committee and the Mozilla community.
  • High degree of flexibility.
  • Commitment of 15-20 hours for meetings and interviews.
  • Good people assessment skills.
  • Comfortable / excited about the focus of the job.

The group as a whole should have:

  • At least one very good scribe.
  • People with different background and focus areas for the project, (not everyone can be a Firefox only person; there should be one or more people who can articulate what it’s like to be on a non-Fx project) and views about staying broad.

Skip past the sidebar