Posts Tagged with “development”

In my last post I described the profound difference in impact between the Thunderbird and Firefox projects. This goes beyond the 10 or 20 to 1 difference in size of userbase. It also includes Firefox’s effect on openness and innovation in general. I described how this causes the relative prioritization between Thunderbird and Firefox to be severely skewed towards Firefox and why I believe it will remain that way.

This could perhaps be OK if the two products were very similar, so that work on one was intimately related to the other. We have found this not to be the case.

The two are complementary products for a set of users, but much less so in development. There are a number of reasons. The products are different, the userbase is different, the international aspects are different. Tristan described this nicely already, so I’ll be brief.

The products have large areas that are not as similar as one might think. Thunderbird uses the underlying Mozilla platform of course. So do many other products. But Thunderbird is intimately tied to IMAP and POP, specialized areas fundamentally different from the core of the web. So the technical relationship between Thunderbird and browsing is actually less obvious than the overlap between Firefox and all sorts of other products that are fundamentally about the web — video viewers, web based music programs, to name a few. Testing and QA are also different.

Perhaps even more fundamental, the world is still moving new things into the browser platform, but many consumers are moving away, have already moved away or may never use stand-alone desktop email.

• Web mail usage grows. Younger generations in particular use other techniques.
• There are many parts of the world where email is less common than in the US, Western Europe or Japan. For example, in parts of the world where Internet cafés are a major way of accessing the Internet desktop email is not the norm. There is a serious question of whether these folks will ever move to mail, or if other options, either web and / or mobile based will always supplant email as we know it.
• Thunderbird is much closer to an enterprise product. Development may still focus on what’s useful to an individual. But given the consumer adoption of webmail, enterprises are a significant source of interest in desktop email. Yet there remains debate about the Thunderbird roadmap, which does not include calendar as the key feature. I’d like to see a structure that promotes maximal feedback between the Thunderbird team and the userbase, and believe a focused organization focused is a better place.

This doesn’t make mail unimportant. It does reduce the degree to which the same development organization can excel at both products.

One large them of responses to the Thunderbird post is the question: Why can’t Thunderbird and Firefox both prosper in the same development organization? Since there is money, what’s the problem?

The problem is trying to do two different types of things exceptionally well at the same time. This is extraordinarily difficult. (I’ll describe why we’ve found Thunderbird and Firefox are different enough to make this so in a separate post.) Trying to do two different things requires a constant balancing of the needs of each. In many cases it results in an inability to optimize for either one and both projects suffering. In our case it also results in a constant need to prioritize between the two. And in this prioritization Firefox is getting and will continue to get the vast bulk of resources.

This is because the impact of the two products is wildly different. Thunderbird is a solid product that provides an open source alternative in an important area for a set of users. That’s important and worthy of attention.

Firefox is important in moving an entire segment of the Internet industry towards a more open, more innovative place. We’re not the only factor of course, there are lots of other critical people and organizations involved. But modern, innovative browsing and web development as displayed through Firefox is part of what moves the Web landscape now.

Firefox effects are felt by people who use other products. Its effects are felt by people using other browsers (even IE has a development team again!). Its effects are felt in the standards world, where Firefox’s footprint strengthens our efforts to move web standards forward. Its effects are felt by web developers who have made Firefox their development tool of choice. The effects of Firefox go far beyond the daily user experience of its userbase.

This difference between Thunderbird and Firefox is profound. Each day the development team can work on Thunderbird, which serves its users well. Or they can work on Firefox, which affects a giant swath of the web industry, and serves a userbase that is at least an order of magnitude larger.

In this setting it does not make sense for a development group to give Thunderbird equal focus. Counting just the userbase, Firefox is 10 or 20 times bigger, so maybe one would say it should get 10 or 20 times the attention. If one adds in Firefox’s effect on the web industry the focus on browsing related activities goes way, way up until it dwarfs Thunderbird even more completely. One might then adjust these numbers in favor of Thunderbird because of a desire for diversity, a desire to continue to serve Thunderbird users, because we’ve always had mail, or for any number of other reasons.

But the point is that this is not a good setting for Thunderbird to get sustained attention and focus. Hiring more people doesn’t solve the problem. It doesn’t change the equation for determining relative attention.

This is our setting. This is why I say that I do not see the existing Mozilla development organization increasing its focus on Thunderbird in the forseeable future. Every time we look at it we are convinced that the current prioritization is correct.

We want Thunderbird to thrive as an open alternative for email. Thus the current effort to find a structure where Thunderbird and email can be the focus. We can imagine this happening within the Mozilla umbrella if there are separate development organizations — thus Option 2. We can imagine other possibilities — thus the other options. But the current setting needs change.

Many of the comments to the Thunderbird / mail post include suggestions about features for Thunderbird. These range from topics like adding visualization to adding calendaring functionality.

I encourage people to take these topic to the Thunderbird development and discussion areas. I would say the same thing if the topic was Firefox. Feature and product planning happens within the project group. For example, there are many comments about calendar functionality, and there is an active calendar project underway. The Thunderbird discussion areas are the right place to ask about the roadmap for integrating Lightning into Thunderbird, to note the degree of need and to look for a timeframe. Better yet, that’s the place to get involved in making things happen. Mozilla is successful when we are rooted in active, distributed involvement and contribution.

If it turns out that there is some barrier to getting involved, or if there is some other problem for contributors, then we’re in a different place and I definitely want to know about that.

I suspect most of us agree there is a lot of exciting potential improvements for Thunderbird and for mail in general. The point is how best to get sustained, focused attention and real movement to addressing these.

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.