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.
- large deployments that certify software before permitting use can’t manage a 6 week cycle
- add-on compability issues
- update notices and fatigue
- 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.