Over the last few weeks, we have announced some exciting new improvements to the way Chef Software operates in the open source world. We announced the improved Contributor License Agreement process, the soft opening of Supermarket, and updates to the way we triage Chef products. Throughout this entire process, we have neglected to discuss one of our most critical open source projects – omnibus.
First and foremost, I want to apologize for letting omnibus slip through the cracks of these discussions around open source maintainence process updates. I could provide some carefully crafted excuses, but ultimately we screwed up. I am sorry that happened, and I will try my best to make sure that it does not happen again.
I wanted to take a few minutes to clarify Chef Software’s use, purpose, and stance on omnibus and omnibus-software moving forward.
For those that are not familiar, omnibus is the process by which we package and ship the majority of our products. Omnibus is an open-source project that is currently used by a variety of companies and individuals for packaging and shipping full-stack installers. Here are just a few examples:
Omnibus itself is composed of two pieces:
I am excited to announce that the omnibus project is currently running against the Supermarket CLA checker. The Release Engineering team at Chef Software has taken stewardship over the project with collaboration from the Chef Client/Server teams, and we continue to welcome patches and bug reports from the community. No JIRA. Yay!
I am also annoucing changes to the management of omnibus-software. Moving forward, Chef Software will only support software definitions that are a required part of our product pipelines. I realize this may come as a shock, so please allow me to explain.
We do not have the knowledge or resources to support every possible software definition in the known universe. At some point in the past, there was a dream that omnibus-software would turn into a cross-platform distro service with matching software that developers could create debs, rpms, packages, and more. While that sounds awesome on the surface, it would require an entire team working full time to support those software definitions. We would need to staff experts in the deepest edges of the most obscure software. It would carry with it all the problems of distro bloat, but would be increased by several factors of magnitude.
Just as discussed at the 2013 Chef Community Summit, we getting out of the business of maintaining software we do not use. We no longer want to be the single point of failure for your business. While many have gained utility from the various definitions inside of omnibus-software, they are ultimately used to build and manage the Chef product pipeline. This mission and goal has existed from the start, but it was clearly called out in the omnibus-software README on February 28, 2014.
Over the next few months, we will gradually deprecate and remove software definitions that are unused. Omnibus has had the ability to use external software definitions for some time now, and there are great examples of writing your own software definitions from some of our awesome community members:
Shortly, the Chef Software Engineering teams will triage omnibus-software and get the project back into a maintanable state. Just like the Chef Community Cookbooks, we will continue to welcome contributions, but only for the software definitions we maintain.
We hope this new policy clarifies the use and purpose of omnibus-software for our community. As always, we welcome your feedback in the comments section below, on Twitter, GitHub, and the Chef mailing list. Thank you for bearing with us during this difficult transition time.
Per Adam’s comment below, you can continue to use the definitions in omnibus-software and expect them to work reliably. We simply are not going to add unused software definitions to the project.