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.

10 Replies to “What do you have: time, resources or features?”

  1. What you say about time being the most flexible is true for projects like Debian, still, but it doesn’t seem to be so for GNOME. By setting a fixed release date for each release, most of the time, I’ve seen expected features be changed. For instance, Epiphany 2.24 was supposed to have WebKit as its only backend, but early in the cycle developers decided that wouldn’t be possible, and simply focused on the Gecko branch.
    I don’t think you intended to say GNOME had time as a flexible resource, but it did get confusing to me while reading if you were refering to what GNOME is, or what you think GNOME should be doing for 3.0, for instance.

  2. Interesting, I hadn’t really thought about it in this way yet.
    So I guess Gnome with it’s 6-month cycle resembles proprietary software – probably not a bad thing in this case.
    @Gustavo Noronha:
    I do wonder where the trade-off lies: is development of new features (per your example epiphany+webkit) delayed on the long term (multiple years)? Does the release-regular system benefit stability/polish?

  3. Being more flexible with time than with scope is neither “necessarily” nor “naturally” the way open source and free software projects work.
    There are, of course, many FOSS projects that are happy to postpone releases until the intended work is done. But other projects, like GNOME or Ubuntu, stick to their release cycle, and are bold enough to cut back on intended features if these don’t mature fast enough. There’s no reason why this approach should feel unnatural for FOSS projects.
    When you speak of GNOME 3.0, are you talking about a release, a version, or about a specific vision, or a vision yet to be further defined, or a scope of features yet to be defined?

  4. Over time, I’ve seen a number of big open source projects shifting towards more predictable release times, meaning that they used to be least flexible about features, but now they are more willing to let features slip to a future release so they can get the release out when promised. This has become more important because a GNU/Linux distribution has to pull together features from many upstream projects, and it has to be able to plan. The result has been that from the Linux kernel to GCC to Gnome to KDE, you’re seeing more and more projects plan releases based on times, which might slip a bit but don’t slip a huge amount.

  5. Congrats for deciding to start on GTK+ v3.
    So in about 7 years we’ll have Gnome 3. Horay.
    Just listen to Mark Shuttleworth and use QT for the next Gnome version; Consider Kde4: Alive and kicking! No need to waste time and effort on another framework if you want Linux to succeed as an “operating system”.
    Give KDE4 a try. It’s great! But of course, it can be way better! Stop daydreaming and forget about gtk+. Please!
    P.S.: It seems than in many people’s vision, Gnome3 is KDE4 anyways…

  6. First, it seems Dread Knight is trolling; second, I agree with him.
    The KDE folks are good at tech, the gnome folks are good at UIs and simplicity.. so take KDE tech and make it simple! You can always rewrite Qt in C anyways, right?

  7. @Gustavo: GNOME has, in some sense, sacrificed its flexibility in time – we’ve committed to 6 monthly releases, which allow us to be well positioned for proprietary vendors who need that commitment (see Stormy’s article), at a cost of setting a scope for each release. Some projects which are part of the GNOME release (GTK+ and Ekiga come to mind) have chosen to put stable releases in the GNOME release set, while embarking on long development cycles, essentially skipping a couple of GNOME releases to get their flexibility in time back. The counter-side for GNOME has been the now common impression that GNOME doesn’t change much between releases, even if it changes a lot if you look at the way things are compared to 2 years before.
    I think it’s possible to mix the two – having a list of priorities for the project with an over-riding vision, while keeping things in a sane state, releasing regularly, and getting new features into the hands of our users.

  8. I wonder if “recruitment” should be added to the model. Companies that decide to embark on a big new release typically have a team of people working on it. In open source software, by the time you embark on a “new big release” most of your dedicated people are doing lots of maintenance with some feature creation. It’s almost like you need to entice or recruit your staff.

  9. Very interesting read to understand open source development timeline. I have been involved with Fennec development for around a year now and I completely agree with Stormy.

Comments are closed.