Rapid Release

My recent post on the rapid release cycle generated a lot of response, some very thoughtful and some also very frustrated.   Many of the comments focus on a few key issues listed below.   We’ve been working on how to address these issues; I’ll outline our progress and plans here.

1. large deployments that certify software before permitting use can’t manage a 6 week cycle
2. add-on compability issues
3. update notices and fatigue
4. frustration that we didn’t get these things addressed better before making the change.

1.  Large Deployments. We’ve made a proposal for extended support for large deployments.This proposal is under discussion now in the relevant newsgroup and in our Enterprise Working Group.  We are incorporating feedback and expect to come to closure on this proposal shortly.

2.  Add-On Compatibility.  There are a couple of related issues that have made add-on compatibility difficult.  First, we have historically assumed that add-ons are incompatible until proven to be compatible.    This is a very conservative assumption which creates work for all add-on developers and notifications to all add-on users.    We’ve corrected this for the add-ons hosted by Mozilla.  Work is underway to correct this for the remaining add-ons.  Here is a  more detailed explanation of the topic; feature planning details are also available.

3.  Update Fatigue.  In the past we have been very careful to make sure people know something is changing with their web browser before it changes.  We did this to make sure people are aware and in control of what’s happening to their environment.   Our position was to err on the side of user notification.   Today people are telling us — loudly — that the notifications are irritating and that a silent update process is important.  This work is underway.    The first set of improvements should appear in the next Firefox release, with more improvements appearing in the next few months.   Also, one main reason people are notified of updates is due to incompatible add-ons which will be addressed by the work on add-on compatibility.  More details can be found in this blog post:  http://www.brianbondy.com/blog/id/125/mozilla-firefox-and-silent-updates

4.  Frustration.  The comments also registered frustration that we didn’t get these issues better addressed before making the shift.  The change was abrupt and we should do better in the future.  We focused very effectively on making sure we could make the core engineering aspects of a rapid release process work.  We focused well on being able to deliver user and developer benefits on a much faster pace — we’ve already brought major memory improvements to make browsing faster, Do Not Track to Firefox for Android, developer tools and HTML5 support.  But we didn’t focus so effectively on making sure all aspects of the product and ecosystem were ready.  We believe we have plans in place to alleviate the issues that resulted, with improvements rolling out in in the coming weeks.

At a recent gathering of Mozilla folks I gave an informal talk on the early history of Mozilla. It’s unpolished, it’s low production value (one mike in a big room) and it’s clearly a talk to a live audience that was filmed. Ideally we’d do some editing, add some text for the questions that can’t be heard and maybe try to improve the oddly abrupt ending. But it’s the early part of Mozilla history that isn’t written down and people enjoyed it. So rather than wait I’ll point to what’s available now. It’s about 40 minutes long.

Recently Mozilla implemented a rapid release process, where we release a version of Firefox every 6 weeks. This has involved changing a number of our processes.  It’s also raised some new issues. For example, some enterprises find the idea of rapid browser change to be disconcerting at best and potentially unmanageable at worst.  Add-on compatibility is another.  I acknowledge these issues are complex and difficult.   There is work to be done to make the rapid release process smoother and hopefully more useful to more of our userbase.   I’d like to describe why I believe the rapid release process is important enough to pursue despite these difficulties.

Before Mozilla instituted the rapid release process, we would sometimes have new capabilities ready for nearly a year before we could deliver them to people.  Web developers would have to wait that year to be able to make their applications better.

A browser is the delivery vehicle for the Internet.   And the Internet moves very, very  quickly.    Philosophically, I do not believe a product that moves at the speed of  traditional desktop software can be effective at enabling an Internet where things happen in real time.    If we want the browser to be the interface for the Internet, we need to make it more like the Internet.  That means delivering capabilities when they are ready.  That means a rapid release process. If we don’t do something like this the browser becomes a limiting factor in what the Internet can do.

Sometimes we can address this problem without a new release of code.   For example,  if one goes to the Firefox Menu Item for “Add-ons” the content one sees is a web page.  This part of the browser enjoys all the benefits of the web.  It can be managed in the ways people have come to expect of a web experience.  The rapid release process is another technique we’ve adopted to allow the browser to deliver new capabilities quickly.

As my colleague Brendan is fond of saying, “There is no free lunch.”    This means we need to listen carefully to those who are experiencing difficulties.  We need to be creative and try to find practical ways of alleviating these difficulties if we can.   This is true for the enterprise use case, and it’s true for the add-on experience.  I know that’s not a perfect answer, and it’s not a promise that we can meet everyone’s needs perfectly.  Despite this, I believe the rapid release process is the right direction.

Recently I’ve been writing a series of blog posts about what I think Mozilla needs to do to remain relevant as Internet life changes. Testing the ideas in these posts through a community – wide discussion is critical.    This is because Mozilla doesn’t succeed based on the ideas of any one person. We succeed when an idea gains traction among a critical mass of Mozilla leaders. We succeed when those leaders take an idea and make things happen; when Mozilla contributors become a powerful force for bringing the Mozilla mission to life in new ways.

My post on Mozilla’s future are intended to start a discussion and chart a path for Mozilla.   Over the next few months, with Mary Colvig’s help I plan to  encourage this discussion by doing the following:

• Start with a series of online conversations with groups of key Mozilla contributors.    The current plan is to start with groups based on time-zone, then move to more diverse groups.
• Ask those contributors to take the ideas to their communities, giving more people the background to participate in subsequent discussions
• Continue the discussion at Mozilla meetups
• Have public online discussions
• Come to a shared understanding of where we agree and disagree
• Come to a shared understanding of Mozilla’s direction and goals for this era.

If you’ve got thoughts, questions, or suggestions, please feel free to leave comments here or drop into #mozillians.

We won’t reach perfect agreement. There will always be cases where some of us will disagree with some of the activities we undertake. Requiring perfect agreement will lead to paralysis. We need excitement, creativity, mutual respect, and shared goals for the nature of the Internet we’re building.

My hope is that we develop a path that is wildly energizing for the vast majority of us. This will be a path that builds the Internet we want to live in, and brings the Mozilla mission to life.

The Mozilla project uses the Mozilla Public License for much of its code, including that of Firefox and Thunderbird.   In 2010 we started the work of updating the MPL (The current version was written in over a decade ago.)    The process incorporates a number of  techniques we use for code:  we’ve released alpha and beta versions; we have a public comment tool, newsgroups for discussions, plus detailed feedback from a number of contributors, including both lawyers and developers.

Release Candidate 1 is now available, together with explanatory material.  I expect that the Mozilla project will adopt the MPL 2.0 for all our code that currently uses the  MPL 1.1.  The discussion about adoption and migration is also underway.

As the module owner for the MPL I am extremely fortunate to work with a group of interested and committed experts on this project.  The revision would not have occurred without this group, and the results would not be anywhere near as good without their leadership.   Therefore, I’m making the four people listed below peers of the MPL module.  Each of this group has deep knowledge about the goals of the license and the update process, the rationale for the changes we made, and our approach to thinking through the complexities.

• Luis Villa.   Luis holds the drafting pen for this version, and is intimately familiar with every word, every piece of punctuation, and  every decision.  Luis  spent a year as a Mozilla employee while starting this, and continues to contribute as a volunteer now that he’s moved to law firm life.
• Heather Meeker.  Heather is an attorney who has been a Mozilla contributor for over a decade.  She is a key part of the revision process.  She brings deep expertise in how licenses are used and what problems arise, along with a keen sense of balancing priorities and risk analysis.
• Harvey Anderson.  Harvey is the General Counsel for Mozilla’s product group.  Harvey launched the MPL revision project, created a setting where Luis could devote himself primarily to the MPL for the starting phase, and has been intimately involved in the drafting.  Harvey was a key sounding board for me when I wrote the initial version of the MPL.  He is also the person who suggested the idea of a  patent defense clause in the MPL 1.1.  To my knowledge that is the first patent defense clause in a FLOSS license.  (If you know of an earlier  one, I’d love to hear about it.)
• Gervase Markham.  Gerv is the non-laywer among the group.  Gerv has been deeply involved in Mozilla licensing discussions for at least a decade.  Gerv is leading the discussion about the migration of Mozilla code from 1.1 to 2.0  Gerv is also the key person in implementing changes such as the migration.