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.