Every now and then I get asked to explain the differences between our projects and platforms. It's getting less and less these days, as most people now understand it. However, it does come up and it's worth repeating here. I was going to launch into my explanation, which is well rehearsed by now, but then someone reminded me that Rich Sharples did a great job of this last year on his own blog. If you're at all unsure about the differences between our projects and our platforms, then take a look.
However, there is one thing that I want to emphasise about this "split": everything we do in our platform work goes into the "upstream" open source projects. We don't keep anything back from the communities that help to create the projects. As Rich explains, our productisation processes push the project code through a set of very stringent processes, e.g., qualifying against a range of database drives, hardware platforms and operating systems, to which the communities may not have access or the time. Yes, it can take weeks or months for us to iterate through our processes to create the necessary quality, fixing code, applying updates that we, or the community, didn't realise were necessary originally, etc.
But once we're done and we are sure that the resultant product can be released, we make sure that the changes go back into the project source repositories. Of course it may not make sense for us to put them back into the trunk of the project, e.g., the project may have moved on to a new major release. And code changes the productisation engineers make often go back into the code for the community projects as soon as they happen, especially if they are major functionality bugs or security issues. Disenfranchising our open source communities is not something we've ever done, or considered and it's not something that we're going to start now!
Our platforms benefit from our community work. Our communities benefit from the platforms too. So what is the benefit of the support contract that Rich mentioned? Well, as he says, using EAP as an example:
"JBoss EAP is supported for 7 years and with every additional minor or micro release we further improve the performance, security and stability of the Enterprise Platform. We’ve now released 2 micro and one minor release of JBoss EAP – that’s about 150 top-level issues in total. While the issue rate will slow over time – we’ll still be in a position to fix issues and respond to new security threats in 2016.
All those fixes are made available upstream and will ultimately make there way in to upstream binary releases but what the upstream project can’t guarantee is that those fixes will be isolated from more substantial changes and improvements – community releases typically don’t distinguish compatible bug fixes from more intrusive changes that provide the innovation."
So if you're wondering whether or not we're still the home of open source, as I said last year, the answer is yes. We do everything in the open and we keep nothing back from our communities. I'm fairly sure many of our competitors cannot say the same thing!