Posts Tagged with “participation”

There’s a lot of info about Mozilla Drumbeat available, and I felt the need for an overview. Here is mine. Mark also posted a summary over the weekend.

Drumbeat is Mozilla’s nascent effort to find, energize and build a Mozilla community of people who are — or want to be — working with technology to build participation, understanding and control into Internet life. This is a complementary effort to building the core technologies themselves, as we do with the Firefox and Thunderbird.

Drumbeat will have tools for interested people to try ideas out — much as Spread Firefox, our product extension framework, and the Mozilla Labs efforts provides ways for interested people to try out ideas closely related to our products.

With Drumbeat we also expect to identify a few projects as an initial focus of the Drumbeat effort, much as we have identified a browser and communications client as the focus of our technology efforts. These Drumbeat projects are areas where the Mozilla Foundation will actively be working to build communities and create impact. Drumbeat projects may vary in their life-span; some may be quick and sprint-like, some may be longer projects.

Drumbeat will use many of the components we’re familiar with at Mozilla — a massive online presence, with work done in the open; lots of local and regional communities and gatherings. One difference is we’re thinking of an annual event as a very significant aspect. We’re thinking that this may be more important since the efforts aren’t likely to be as tightly coordinated as a product team, which becomes very tightly bound during the latter part of a product release.

More detailed thinking on Drumbeat can be found at the wiki, and of course there is an open invitation to get involved.

So far we’ve used the word “participate” as in: “Mozilla promotes choice, innovation and participation on the Internet.” That’s good, but it’s not enough. Many of us participate in closed systems where the rules are set for us and we don’t see them, certainly can’t change them, and aren’t permitted to “participate” in building the rules. This is true of very popular web services. For example, I “participate” in Flickr and Facebook, but within the system and rules that those organizations set up to meet their own goals. That’s fine; there’s no reason for those sites to change.

Mozilla is trying to build a layer of the Internet that’s different, where “participation” extends to the very core of what we build. I’m still struggling to find a crisp way to describe this. If you’ve got thoughts about how to do this — in any language — I would love to hear them.

One of the proposed 2010 goals is “Deepen Mozilla’s role as a centerpiece of the Internet.” I received feedback that this goal feels wrong: it seems to be about promoting Mozilla rather than a healthy Internet. Once this was pointed out, it’s obvious. I’ve edited the proposed goal to reflect this and capture ideas raised during the various discussions.

Goal: Make openness, participation and distributed decision-making more real in Internet life.

More and stronger communities practicing these values

Scope expands to include things such as the open web, hybrid social enterprises, organizational sustainability, shared decision-making, individual control, and portability in Internet life

Innovations emerge from varied sources

Projects and products based on these values become increasingly vibrant

One of the great things about Mozilla is that periodically I’ll be thinking about how to get something done and then I’ll look up and find someone else has already done it, and often gone further with the idea than I would have. Dave Eaves’ post today about “The challenge of Mozilla’s magnetism” is an example. I’ve been thinking about this all weekend, writing a post in my head. But now I don’t need to, Dave’s got just about everything I was thinking about already pulled into something coherent. The first three-quarters of the post are almost exactly what I was thinking — particularly the reasons for the pull of Mozilla to so many people and the need to balance that with what strengthens our current communities.

Personally, it’s much better to hear this from Dave than to see it written by me. That’s because once it’s clear that a set of people wanting Mozilla to do more also understand the precious nature of our current communities and how strengthening them must be central, then it’s much easier to be open and responsive to ideas for expanding.

The last paragraph — a suggestion about the minimum plan Mozilla should build and execute to work with others who care about the open Internet — is really helpful. It seems so obvious when written this way — of course Mozilla should do this. We may in fact be able to do more, but we don’t need to wait to figure out how much more to get started.

In a post last week I talked about concentric circles of community, noting that I actually think of Mozilla as concentric spheres of community. That’s because each community (practice, action, interest, user) is made up of many different sub-groups.

For example, the Community of Practice is that set of people who are sharing resources and using a bunch of Mozilla practices together to achieve a result. Within this group we can find many different kinds of activities. We might think of subsets based on the project, such as the Firefox, SeaMonkey, Thunderbird, Camino, Bugzilla, or Calendar communities of practice. We might think of subsets based on activity — the localization, quality assurance, coding, website, design, UI, support, infrastructure communities or practice. We might think of subsets based on language or locale.

There are so many dimensions to Mozilla communities that I think we need (at least!) three dimensions to have a working model. To help with this, there is now a wiki page for discussion of the Mozilla community to see if something other than blog comments is better for a long term discussion.

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 mozilla.org 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:

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

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.

Make sure the creation of the Incubator Repository to which you wish access has been approved.

File a bug. Product: mozilla.org; 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 <jdoe@example.com> “). 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.

Each of the two sponsors should comment in the bug saying s/he’s sponsoring the Incubator Repository and your participation in it.

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.

Complete the Contribution Form and fax it to the location specified on the Form.

Update the bug to note that you’ve faxed in the Form.

An appropriate Mozilla representative will update the bug to say whether s/he has received the faxed Form.

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.

The Mozilla representative will double-check that the needed info is recorded and, if so, create an account.

The Mozilla representative will then reassign the bug to IT to have your SSH public key added.

A Mozilla IT representative will update the bug with account creation information and close the bug.

A couple of days ago a colleague referred to the Open Science post a while back, and I realized I had meant to follow up. So here goes.

Given the issues with “open science” how might progress towards openness be made?

It’s unlikely that those with a big financial stake in the current arrangements will change. This obviously includes the commercial ventures aiming for large returns on their investment. It probably also includes the major research and development institutions who may not be public companies but who are deeply involved in the current system. If you’re an academic institution and you’ve spent millions of dollars outfitting labs and have a set of people working and studying at your institution assuming the research and its results will be treated a certain way, it’s hard to make big changes. So even if one takes the position that these organizations should change (which I’m not necessarily advocating) I think it’s unlikely that leadership toward Open Science will come from here.

It’s more realistic to expect change around the edges than at the very center of the system. Periodically I read about diseases that could probably be treated, but exist mostly in impoverished areas. So there’s very little economic reward for the necessary research, development and deployment. I could imagine organizations concerned with alleviating these diseases to be more inclined to find ways to collaborate, particularly if relevant patents have expired.

There is usually a hierarchy of research organizations and universities; the “top tier” schools are more able to get research funds and to capitalize on the results of their work. But, there are massive numbers of very smart and very motivated people at other organizations. It may be that collaborative scientific techniques will develop at unanticipated places that aren’t well positioned in the current system.

It may be that successful Open Science doesn’t start at the central, biggest problems. It may grow by solving pieces of problems. Free compilers existed before the complete GNU Linux operating system; the same incremental change may occur with Open Science. Sadly, many of the big problems are the health topics where people’s lives are at stake.

The realm known as “Citizen Science” may well lead the way. Citizen Science is based on large numbers of people working together. Since those participants aren’t expected to have scientific training, there are a whole set of problems that can’t even be approached through this method. But we may be surprised at the areas where Citizen Science can move our understanding forward.

We’ve long described the mission of the Mozilla Foundation as “promoting choice and innovation on the Internet.” I’ve been thinking about how to make this more concrete. How to answer questions like:

Is all choice equally useful? How do we figure out which choices we actively try to accomplish?

Is all innovation good? Or are some types of innovation more likely to promote the goals of an open Internet?

I’ve found these questions harder to answer than it might seem.

More and more I come back to the concept of participation. One of the things that makes the Internet so exciting is the ability for many people to participate in the development, use and direction of the Internet. People can participate in many ways, in many languages, on many machines, in many different activities. Also, people can participate in a highly decentralized way, making their own choices about if, when and how to participate. Some participate by creating content, some by creating software, some by building communities, some by creating websites. Those who participate help determine the direction in which the Internet develops.

So, what kinds of choice matters to the Mozilla project? What kinds of innovations should the Mozilla project focus on? My current thinking is that we should focus on:

Innovations which promote widespread, decentralized participation in online activities; and

Choices — in technologies, products, community projects — that make it easier for people to participate in building the online experience that works for them.

Does this resonate with you? Is this a helpful way to think about our goals? Please let me know.

Tristan has a great new post about purpose-driven organizations. I’d like to pick up where his post ends. This is the question about why people participate in efforts that aren’t all about making money for themselves. I’ll speak about the Mozilla project; I’m interested in the degree to which similar motivations apply to other projects.

When I first started working in open source there was one obvious answer to me, and it was specifically tied to software programmers. This answer came to me from familiarity with two groups of people: software programmers on the one hand and artists on the other. I’m not a programmer myself, but living in Silicon Valley I know a gazillion software programmers, have worked with and watched them closely, and married one. In a previous era I knew a bunch of dancers and fabric artists (check this out for amazing work with thread). There is something in common. Many artists practice their art because the drive is in them and needs to get out. A set of programmers have the same internal drive. My husband is one — he will happily spend hours — days if he could — programming on his own, unrelated to any job or money. A lot of the great programmers are this way.

As I worked with the Mozilla project I’ve come to understand there are other, equally powerful forces that drive people to participate and which generate all sorts of non-monetary rewards for doing so. Here are a few that came to mind immediately.

Participating in a group effort to create something useful is rewarding. Having the flexibility to participate in the way one wants is a great motivator. Rewarding people through respect, reciprocal-effort, leadership and appreciation provides a level of gratification that a paycheck may not. This is not to diminish the need to earn a salary; most of us need this. But many people earn their salaries in ways that don’t engage them, or motivate them, or leave them feeling unappreciated or boxed-in or undervalued or mistreated. How often have we heard people say that their work could be interesting, but the social dynamics ruin it — the boss is bad, the colleagues are bad, the people are good but the product goal is predetermined and bad, their role is limited, etc. The Mozilla project offers people the chance to participate in a group effort of their choice, in the way they choose to participate.

Doing something for the “public benefit” or “general good” is rewarding. This is a great blessing, let’s all hope this continues. I have found many, many people who want at least some of their life efforts to benefit the greater good. I know this sounds naïve. It also goes against the idea that greed and personal gain are the only things that drive people. Nevertheless, I hear this from contributors to the Mozilla project regularly and I see it in their actions. I find it incredibly rewarding to work among such people. There’s a lot of distressing news today. Living and working among a community of people who care about more than themselves gives me hope.

Involvement in a healthy, productive community is rewarding. Being able to help create that community, having the ability to influence how it grows and what it does is a great motivator. The Mozilla project provides enormous opportunities to both participate in a healthy community and to help shape our direction.

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.