Rich Sharples gives a pretty good overview of our product lifecycle in response to some FUD from Snorcale. As a slight aside, I love it when certain Closed Source companies preach to us and the communities about open source: the words "grandmother" and "sucking eggs" spring immediately to mind! Anyhow, FUD is something that we've seen rather a lot of in recent times; I suppose it's easier to do than actually provide significant technical differentiation, and it's nice for us to keep disproving it!

As I said, Rich's post is a good overview. But some of the things that are implicit in it need a bit more explicit discussions. For a start, the open source communities are extremely important to us and we try not to do anything that would affect them adversely. Everything that we do during the productisation process in terms of bug fixes, feature improvements etc. goes back into the community releases. We are not a closed source company that periodically dumps our code into a public repository.

The communities, whether they are comprised of people who contribute code, let us know about bugs, or give us use cases and requirements, are critical to the success of our projects and hence our products. Of course we recognise that not everyone will want to purchase a support agreement from us and will be confident enough to self-support. Those individuals and companies are still important to us; they're still a mark of success, both for us and for the community at large! If you listened to some of the FUD you'd think that we walk all over the communities once we get what we want, i.e., the code. Nothing could be further from the truth; just take a look at JUDCon for example. Of course you can't please all of the people all of the time, but to think that an open source company such as Red Hat would do anything to mess with its communities is crazy. I think it shows that companies such as Snorcale are having to resort to the Chewbacca Defence in order to try to confuse everyone and distract them from their own issues around open source.

Another thing that is implicit in Rich's description, is what we like to term "baking in the community": this is where the community (including our employees) works to ensure that each release of a project (and hence a subsequent product) is fit for purpose. Our communities feed requirements into each project release via forums, JIRA, emails etc. The development teams, which may well include community developers as well as our employees, then work on any associated new capabilities, or bug fixes, and turn those into new project releases. The communities then take those releases and kick the tyres, providing feedback on what's good and what's bad, what works and what doesn't. As a result, it may be many months, or several project releases, before the project teams and their communities are happy with a particular feature. This is baking in the community, and only something that's been suitably baked makes it into a product.

All of the above should help to illustrate some of the trade-offs that are inherent in our approach. The communities are always getting the cutting-edge features and capabilities, some of which may well have been added by our developers on behalf of customers, as well as all bug fixes that we may find during productization. The community releases move forward relatively quickly compared to the products, because we spend a lot of time in the productization process, which might include removing some things from the project releases that aren't quite ready yet, e.g., they haven't had enough bake-time. Those who purchase support for our products (platforms) get a slower moving beast, that offers guaranteed stability over a much longer period of time; it may be months or years before they gain access to the feature set that's available in a project.

So in conclusion, we believe the model we use is able to walk that line between project needs and platform needs. It's something that we have been working on for a few years, but which we do evaluate based on feedback from all of our community members, including product customers. It has allowed us to grow our offerings substantially over the past 4 years and retain our leadership position. So let's see how the next 4 years plays out.