Archive for July, 2006

One of the issues I see regarding our products is the tension between being cautious about changing our products on the one hand and trying to innovate on the other. There are good reasons for this tension, since each perspectives represents part of our current reality.

There are a number of reasons to be cautious about changing the product. We have a great product that people love. We also have a userbase of many tens of millions of people; a good portion of whom prize familiarity. Many people struggle to understand the difference between browser windows, search engines, software, data and the Internet. Constantly changing software can be disconcerting. And all of us are determined to avoid “software bloat” – the practice of adding new features simply for the sake of adding new features.

On the other hand, continued innovation is critical. People are using the Internet in new and ever-changing ways. People continue to look for information but they also communicate with each other in a growing variety of ways. Some of these ways are already browser-based, such as the creation of identities in social networking sites and the sharing of information about oneself. Others are not currently browser-based, such as instant messaging, but provide data about what people want to do online.

User activities are expanding. The integration between software and web services is young. Firefox cannot stand still and remain equally useful as people do more things through their browser. There are plenty of ways to improve user experience left to explore.

It’s also expremely important to have some key actors in the developing Internet ecology focused on public good rather than private gain. The Mozilla project has a unique ability to do so. Our public benefit mission, our central focus on user experience and our vibrant, engaged community make us a unique and important element in the changing Internet landscape. This is true of the Mozilla project and our technology as a whole, and it is true of Mozilla Firefox as well.

We need to try new things to see what the Internet and browsing experience can be, could be, should be. We need to try things that may fail. We need to experiment with new ideas before we know if they should be included in a general product release. Trying to do this in the main development process is extremely difficult. This main development process is highly optimized toward building stable, shipping releases. The code in this world is verified every night to make sure that new code added in the previous 24 hours meets a set of requirements and doesn’t make it too difficult for other developers to work. This is an excellent process for its stated goal. But it is a very difficult system for trying out new paradigms. It’s hard enough to be creative about how to help people use the Internet. It’s many times harder to do so within our existing product constraints.

So we need a mechanism to work on new ideas that is separate from our main development process. This is important enough to devote some resources to this, and I’m setting that in motion now. Its ultimate success will depend on the community reception, participation and leadership, like everything we do.

The basic idea is to provide a development forum to explore a small number of ideas that could provide new classes of functionality or other significant changes for our products. Our initial focus will be heavily in browser-based activities, though that isn’t set in stone and may expand with time. By “new classes of functionality” I mean things like improving browser interaction with social networking activities; more integration with web services; what could one do if one could had local storage of data from browsing activities? A fuller list of potential projects can be found at: http://wiki.mozilla.org/Mozilla_Prototypes#Process

We will start with a small number of projects because part of the initial goal is to focus attention on promising categories. The goal is to have this be a broadly-based effort where a range of people / organizations can explore ideas with the Mozilla community. We hope many of these projects will be led be people with no formal relationship to the Mozilla Foundation or Corporation.

The general goals are:

• Identify areas where exploration is important
• Determine if and who has expertise and interest in leading this exploration in our world
• Select a handful of projects
• Provide development tools, forums, etc.
• Direct attention of appropriate parts of Mozilla community to Mozilla Prototype projects.
• Be aggressively innovative;
• Eliminate Stop Energy
• Expect many ideas will morph to become useful
• Recognize some ideas will be dead-ends
• Harvest useful ideas into core development

For now, we’ve been calling this initiative “Mozilla Prototypes.” I picked this word as a starting point because I wanted something that doesn’t have as much acquired meaning as “Labs” or “Research.” It turns out that “prototypes” has been a useful starting point in that its use revealed a real interest in creating prototypes. But the initiative should be broader than that; going far enough into implementation to learn if something makes sense in the core of Firefox.

Mozilla “Prototypes” needs someone to guide its development and get it off to a healthy start. There’s a lot to be figured out -– who and how do we decide on a project, when is a project over, what other related activities make sense. Basil Hashem of the Mozilla Corporation has offered to take on this role and get Mozilla “Prototypes” started. Basil has a product management background, and has a great set of skills to get Mozilla “Prototypes” off to a good start and develop a framework where exciting things can prosper.

Basil led an initial discussion of Mozilla “Prototypes” at the brainstorming discussions in Mountain View the last week of June. (Those discussions were open to the Mozilla community, but of course there are only a few people close enough to drop in, and telephone conference calls are difficult for many.) There were a number of logistical questions, particularly about how we’ll decide on the first projects and get things going. These first set of decisions will probably be made by people very closely involved with Firefox. If it turns out we need an individual final-decision maker then I’ll identify one. I’d like to start with very low process requirements and add formality as we go along. That way any formal rules we come up with will be based on experience and actual data.

Basil has an initial description on the Mozilla wiki at: http://wiki.mozilla.org/Mozilla_Prototypes. Please take a look and add your thoughts. If you feel a wave of Stop Energy, please take a deep breath and see if it diffuses. If it’s still there, please address it to me rather than Basil. On the other hand, if you’ve got ideas and can help us make Mozilla “Prototypes” more successful, then please by all means get in touch with Basil, or both of us.

In early June I noted that we had found a great person to lead development of a grants and donations program and that we would turn to this topic in mid-July. That person is Seth Bindernagel, we’re coming up on mid-July, and Seth joins us at the Mozilla Corporation today.

The goals of the program are to help strengthen the Mozilla community. They are not to turn volunteers into employees or to reduce the number of employees. We’re not looking to be an all-purpose grant–making organization, or to be gigantic. The point is to use all the different kinds of resources available to strengthen our community, and that currently includes some financial resources.

Seth will join us for an initial 6 months to flesh out how this might be done, to try an initial set of programs and develop a clearer view of our path before joining us permanently. The focus is not on making a big bang, but on doing useful things. Seth and I spent some time articulating this work more clearly. I’ll post this separately, since this welcome is long enough already.

This is an unusual role. We are lucky to have found Seth, whose background in business and social entrepreneurship matches remarkably well. Seth comes to us from the Haas School of Business at the University of California. While there, he focused on socially responsible business, co-leading the school’s Net Impact Club and serving as co-chair of Judging for the Global Social Venture Competition. He was also a member of the winning team for the Global Ethics Challenge. Before business school Seth spent three years working with Ashoka, a global nonprofit organization focusing on advancing the profession of social entrepreneurship.

At Ashoka Seth served as the Program Manager for the U.S. and Canada programs. With the team, Seth helped search for and select leading entrepreneurs in the U.S. and Canada who were creating new ideas to solve critical social problems. He helped launch Ashoka’s Accelerator for Social Entrepreneurship, which brought together Ashoka’s corporate partners Hill & Knowlton, McKinsey & Co., and the International Senior Lawyers Project with Ashoka Fellows in need of pro bono professional support. These partners donated their time and industry expertise to Fellows who were starting new organizations with strategic development needs. Seth helped organize all orientation and induction programs for the new social entrepreneurs entering the Ashoka Fellowship. Seth has consulted many different social ventures during his time at Berkeley, including the Omidyar Network, Ashoka, World of Good, and the San Francisco Giants Community Fund.

Please help make Seth feel at home. Feel free to ask him about his experiences, about why he switched his undergraduate degree from engineering to “Agriculture, Resource, and Managerial Economics,” about sports in general and baseball in particular. Please make some time to help Seth get to understand the Mozilla project so he can do more sooner. Seth will have a Mozilla related blog up and running shortly, I’ll point to it.

A few days ago I mentioned the need for positive reinforcement to encourage creativity; Ben Goodger noted the prevalence of Stop Energy (a Dave Winer term) and the need to do something about it.

Two obvious responses are: Stop Energy wins, and the status quo resists attempts at change. During his visit to the Mozilla Corporation Bob Sutton has noted how disastrous this is for most organizations. We’re no exception. Another possibility is a determined individual who ignores all comments and plunges ahead, “knowing” that s/he is correct and change is better. I’ll call this the “Loner” approach for now.

The Loner approach addresses the Stop Energy problem but has many problems of its own. For one thing, the Loner approach is hard on the Loner. He or she must have a very thick skin, must proceed based on s/he thinks without listening to others (including possible improvements), and then must somehow be demanding or threatening or otherwise forceful enough to pull the project along. This is exhausting. The Loner approach is hard on everyone else as well. Bull-headed, demanding people who don’t listen to others are usually difficult people to work with. The Loner has to be really, really, really good to make it worthwhile for others to stomach the trauma. Our strength is the caliber and dedication of people who choose to work with the Mozilla project; encouraging difficult behavior to avoid Stop Energy is an unhealthy setting.

Also, if people get into the habit of believing they are always right and don’t need to listen to anyone else, then all sorts of unpleasant things generally follow. Few people are always completely right. It becomes hard to work together. People become zealots. Moderating influences are lost. Our experience has been that the group intelligence within the Mozilla project is very high; far greater than the intelligence of any one person.

So, how to encourage positive feedback for creative ideas, make use of our group intelligence and avoid Stop Energy? I think many of us use an approach I think of as “Layers of the Onion.” It’s a pretty simple idea. When someone has a new idea, s/he thinks it through a bit, then goes to a group of people he or she thinks of as likely to have the expertise to be helpful and the sense of possibilities to be encouraging and make good suggestions. At some point w/he includes people with a sense of the constraints as well to get a reality check. Feedback (positive and negative) is received and incorporated into the original thinking; maybe some implementation work is done.

Then the idea is discussed with a larger group of people. More feedback is received and incorporated. The idea appears in a public forum for public discussion and review. Maybe the idea never gains traction, maybe it needs more work to be generally acceptable, or maybe it’s time for implementation.

There’s nothing too complex or original about this process, I suspect it happens all the time. I’ve called it out explicitly because I believe that –- properly implemented of course — it’s an approach that meets our criteria of openness and transparency while simultaneously helping to minimize Stop Energy. I’m very focused on doing both of these things well, both for the project as a whole and for the work I need to lead on issues of Mozilla identity and governance.

Here is the last part of Mike Shaver’s summary of the Categories: Mozilla | Tags: All Hands, communication, discussion, openness | Comments off