What do you have: time, resources or features?

As open source software becomes more popular and is included in more commercial products, the open source software projects face more pressure to produce a “roadmap”. Projects like GNOME have successfully moved to a six month release model which has greatly aided the companies that depend on GNOME technologies. They know when the next release that includes their patch will come out. They can now plan for when patches need to be submitted to make a release, when that release will come out and roughly what it will come out.

With plans for GTK+ 3.0 and GNOME 3.0 being discussed, the pressure to generate a “roadmap” has once again appeared. When will 3.0 versions be released and what will be in them?

The rest of this post is generalizing about open source software projects in general, not GNOME or GTK+ in particular. It’s just that working with them has made me think of these things.

One of the factors that is becoming clear to me is that open source software has a fundamentally different “project triangle” than proprietary software. Every project has three constraining resources: time, resources, and scope. (Resources is often called “money” because in the proprietary world it’s assumed you can buy more developer resources.) Some of these constraints are always more flexible than others – the question is which one is most flexible and which one is least flexible for your project. Typically in a proprietary product, it’s scope that’s most flexible. The project has a fixed amount of money and people and marketing’s committed to a release date, so it’s the list of features that’s most flexible. Occasionally the most flexible item will be resources and a company can throw more money at the problem.

In contrast, in the open source world, the most flexible resource is not scope but time. While resources are not fixed, you can’t easily find more volunteer developers to throw at the problem. So for planning purposes, resources are not flexible. While scope is flexible, time is even more flexible.

Typically open source software projects define a release by saying which features they would like to have in a release (which can change if external circumstances change), put all of the volunteer resources they have at the problem and then remain most flexible with regards to time. They release when they’re ready.

Time is sometimes important in open source but not because a marketing team committed to a date but because you want to keep your project active in order to keep people interested in working on it. New features and new releases are exciting.

While each open source software project is different, I believe that community driven open source software projects are probably closer in priorities to each other than they would be to traditional proprietary softwaree.

For proprietary companies used to a fixed schedule and flexible scope, having a flexible schedule is frustrating. It’s not wrong, it’s just very different than the world they work in, and so makes planning very hard for them.

Companies look to open source software projects for a roadmap that’s fixed in time and flexible in scope. While the open source software projects are saying there’s no way they want to commit to a time because they can’t commit to more resources and they know they have to have the following features to say it’s a “major release.” The projects commit to scope (a set of features) and resources (the project members they have and anybody who wants to join us), and releases when they can.

This isn’t to say open source software projects don’t care about time, it’s just the most flexible of their three constraints by the nature of how they work.