Approaches to Release Management

I'm all for stealing borrowing good ideas (not code) from other projects where it can be applicable. And since one of the major areas of complaints in Open Source is installation and upgrades, a recent article titled “One big thing Ubuntu can teach Microsoft, Apple, and all CTOs” from Tech Republic really struck me:

What Canonical does really well is to methodically produce incremental upgrades to its OS. It is transparent about its goals and plans, and it releases its software on schedule. In fact, this incremental approach is Ubuntu’s most potent competitive weapon against rivals Microsoft Windows and Mac OS X.

I've been an Ubuntu user on the desktop almost exclusively for three years now. And honestly, beyond a few issues with Major upgrades, the incremental Minor updates have been quick and painless. I still don't do them in the week before a major presentation or conference, but that's my own timidity. ;)

But anyway, I believe this can happen for a trio of reasons:

First, proper labeling of Major and Minor releases sets expectations. I've talked about “The Point of Point Releases” before, but the value of setting expectations properly can't be understated. I've been very happy with products like Firefox and Drupal that behave themselves within Minor releases. I know that once I've installed a module on 1.0, I can use it through to 1.25 with minimal adjustment. When you're working with a core piece of your infrastructure, this is a good thing.

Alternatively, there are some projects that don't get it. Refactoring the core of your system or changing default behaviors from version 1.5 to 1.6 is a bad idea. The obvious problem is that it can greatly increase the support load of your project as expected things break. Even worse but more subtle, it creates uncertainty for your module builders and community. Everyone has heard the story of “I tried the small upgrade, it broke and so I switched to X.”

Of course, none of that is unique to Open Source..

Next, regular releases give a product the chance to adjust, adapt, and respond to its customers. Windows Vista, Netscape 5, and quite a few other things are examples of products that simply missed their markets. For each, their releases came after years of internal development without much insight and interaction with the outside world. Even worse for those companies, each of these products had major competitors – namely Firefox and Ubuntu – doing the extreme opposite.

Alternatively, there are some projects that just don't get it.

Finally, they set expections for the future. Ubuntu specifically has a standing policy for how long between major releases, how long between regular releases, and how long they're supported. No user – whether personal or corporate – has to worry about how long updates might be available. System admins love it. They know exactly when updates will be available and can even schedule them. The general public will never care about updates.. most of them don't apply updates unless their system screams it via a dozen pop ups.

The more importantly, when system administrators look at platforms to build upon and support, they want stability and simple, quick updates when there are problems. They hate investing their time, effort, and money into an infrastructure that will have to be completely replaced soon. And “soon” is defined as “as long as I still work for the company”.

The point of all this is that project and product teams need to figure out how to communicate better with and respond to their users. Even better, we need to create plans for our projects and communicate them to our communities. We not only need to get our users personally invested by taking their feedback and suggestions, but we also need to give them a peace of mind that we'll be around as a project long term and their time and money investment is worthwhile.

Towards that goal, between now and the v2.0 Release of web2project, we plan to release our full roadmap for public comment and review. It captures all the priorities and efforts on our agenda whether they're currently scheduled or not. It's an effort at both transparency and a way to show people how/where to get involved.

Are you interested in API Design? Check out our new book "A Pragmatic Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available soon from LeanPub