CloudBees has announced that it has released a version of Jenkins, the DevOps tools for the enterprise. Called CloudBees Jenkins Enterprise (CJE) the product will be a curated version of the open source Jenkins tool. All of the components and plugins that ship as part of CJE was tested and verified to make sure that they are enterprise ready. This is a good move as it will assure enterprises that the product can be used and trusted in their environment.
Sacha Labourey, CEO, CloudBees announced the product at the Jenkins World conference in San Jose this week. Labourey said: “Jenkins Enterprise is to CloudBees what RHEL [Red Hat Enterprise Linux] is to Fedora. We have made it easier to consume Jenkins in the enterprise and easier for customers to evolve their DevOps. We’ve created this version based on feedback that we’ve had for a long time from customers. We are now able to step up and deliver. We couldn’t do it previously because of the investment required in resources and engineering processes.
“We have created this project based on the open source Jenkins product. As part of this project we will only keep those things that are enterprise mature. We are subjecting them to heavy testing and across multiple use cases. We will also synchronise them to ensure stability. Our goal is to make the adoption of Jenkins in the enterprise very boring.”
CloudBees Jenkins Enterprise is following a well trodden path
Labourey’s last comment drew laughter but the point is a serious one. While use of open source is on the rise inside enterprises it has to meet enterprise requirements. CloudBees is following a well trodden path of taking a mature and stable open source project and creating an enterprise. Labourey cited Red Hat, RHEL and Fedora as an example. He could just as easily have cited Enterprise DB and Postgres or any of the MySQL derivative databases.
What makes these attractive to enterprise customers is that they are not the bleeding edge of open source code. They get stability, a roadmap and some input into the future direction of the product. The vendor gets to charge for support, consultancy and work with the open source community to create an ecosystem around the enterprise product. Done properly this is a win-win situation.
However, if done badly it can come back and haunt the vendor concerned. The open source community takes great exception to the suggestion that the vendor owns the product and not them. They also expect to see all improvements filter their way back into the community build. Labourey has been very clear about who owns what. His experience of working with the open source community has given him respect for what they do.
A select set of curated plugins
One of the big differences between the CJE and the standard community version will be the number of plugins. To ensure stability there are just 20 plugins in CJE. Labourey says that more will be added over time but they need to meet the right quality, security and stability thresholds before that happens.
This is a good thing for everyone. It helps the plugin creators understand what is required of them to earn money from their code. But to do that CloudBees needs to publish the criteria and even the test scripts. By doing so they will be helping themselves as well as their customers and developers.
Conclusion
CloudBees has done a lot since it took on the role of stewards of Jenkins. They have allowed Kohsuke Kawaguchi (KK), the creator of Jenkins to expand and drive the product forward. This is something that other open source projects have lost and it impacts the way the projects develop. In the last year we have seen announcements from MariaDB and others who have attracted founders back to the open source projects they created. In the case of CloudBees and Jenkins it has created stability and that has led to the opportunity to launch an enterprise product.
After a long conversation with the CJE sales team, they said that CloudBees doesn’t actually fix bugs in Jenkins or its plugins, they rely on the open source community for that. Ultimately, they are just selling free software with a few extra plugins thrown in. This is nothing like RedHat who is a major contributor to the Linux code base.
Michael, that’s interesting and it shows the difference between sales teams and developer teams. A lot of my time at Jenkins World was spent with the developer teams who tell a different story. Remember that Kohsuke Kawaguchi works at Cloudbees and is driving the project from there. They have spent a lot of time on the new UI which is almost all an internal development and they are doing a lot to sort out the mess around many of the abandoned plug-ins. All of the code they generate goes back to the community as you would expect from this type of relationship.
Ian is correct. I am the Senior Director of Support at CloudBees. For CloudBees customers, my team definitely fixes issues in the Jenkins core and also in the open source plugins. Issues that we fix are sent upstream to the Jenkins project to ensure we do our part to contribute to ongoing improvements in the quality of Jenkins.
What sales may have been referencing in their conversation with Michael is that we don’t fix issues in the Jenkins core or open source downloads for open source users. You have to be a CloudBees subscription customer to get access to our technical support. Open source users must rely on the community for fixes – that is true. However, to be clear, when we fix issues for our customers in the open source code, the fixes are committed back to the Jenkins core – which ultimately does benefit the open source users, too.
Hope this helps to clarify.
If “CJE is to CloudBees what RHEL [Red Hat Enterprise Linux] is to Fedora”, I am wondering where is CentOS equivalent?