The 2016 Chef Community Summit in Seattle brought to light a particular set of concern and confusion in our community around the future of three Chef ecosystem tools: Policyfiles, Push Jobs, and Chef Provisioning. In order to address that, we’re posting a four-part series to make Chef’s stance on these tools clear: where we see the use case for these tools, our view on the future of the problem spaces they address, and what to expect moving forward.
First, we’ll set some context around the development process and how tooling evolves in the Chef ecosystem. Then, we’ll look at the nuances of the individual tools in question and explore each of them in-depth. Part two of this series will cover Policyfiles. In part three, we’ll cover Push Jobs. Finally, in part four we’ll cover Chef Provisioning. The goal of this series is to clarify the state of these three tools and provide sufficient guidance to help you determine if using them is right for you.
Chef Software is fundamentally an open-source company. Because the majority of our products are open-source and available for anyone to use or modify freely, it’s a regular occurrence to see new experimental tools appear to solve common problems. Those tools may come from within Chef Software or they may originate from our vibrant community.
Some of those experiments are a smashing success. Test Kitchen, Berkshelf, Chef Vault, Foodcritic, and Chefspec have all become vital to solving problems for our customers and our ecosystem. All of those tools started outside of Chef Software, but are now incorporated into standard workflows and are even included in Chef DK. There are also thousands of community-created Chef cookbooks, Habitat plans, and InSpec profiles that solve real problems and help people perform important jobs every day.
What’s tricky is when certain experiments only work for particular niche situations or they fail to resonate broadly across our ecosystem. Sometimes, those types of experiments live a short life or only gain exposure in esoteric circles. Other times, they’ll fall somewhere in between that esoteric existence and the critical mass of broad ecosystem adoption like some of the examples above. That’s when figuring out if some of these tools are right for you can become confusing.
Let’s briefly cover how Chef makes determinations about what ends up on our roadmap.
Feedback is the number one way to influence our roadmap inputs. We combine that with other factors (e.g. market research, product performance, etc). We then prioritize those inputs by examining the value they create for the community, our customers, and our company, along with some additional factors (feasibility, broad reach, etc) to get our outputs. Chef is in a state of continuous improvement. We believe in iteratively improving our software by introducing features in places that have the largest impact for the people who rely on Chef. In each planning cycle, we focus on the highest priorities where we can deliver the biggest wins.
We’re always developing our core product set. But there’s a lot more to the Chef ecosystem than our core products. Chef Software (as an entity) supports a number of ancillary open-source tools in our ecosystem. Sometimes, that support from us comes in the form of committed engineering time to develop ecosystem tools. Sometimes, engineers that work for Chef devote their own time to develop ecosystem tools (because: open-source and community!).
That level of flexibility and continuous improvement allows us to respond to shifting needs quickly. But each quarter, there’s always more we want to do. We make tough choices when prioritizing what we’re going to address. Sometimes, that means choosing not to invest our engineering time to develop features for some tools while we instead focus on others. At times, users feel that flexibility as ambiguity around the future of certain projects.
If you’ve built solutions developed with Policyfiles, Push Jobs, or Chef Provisioning, those investments are safe. We are actively supporting these tools. If we find high-severity bugs or material security vulnerabilities, we will test and fix them with new releases.
These tools are all open-source and available to the community. In some cases, the Chef community is actively adding features to these tools. But, at present, Chef Software is not investing time developing new features for these three tools. For now, the only new features for these tools will be ones the community develops and introduces (because: open-source and community). That doesn’t necessarily mean that these tools won’t ever get any new sponsored development from Chef Software. It means that right now, at this moment, that’s not where we’re focusing.
What we hear from customers who use these tools to build solutions is that they’re effective for particular use cases. In those settings, they’re also considered feature complete for the problems they were intended to solve. For now, that signals to us that a majority of our customers and community gain greater benefit when we prioritize our development focus elsewhere.
If these tools are useful to you and to the greater Chef community, then they should continue to see activity. As with all features of Chef, organic growth and community feedback are ultimately the main guide for development priority.
Because these tools have particular considerations you should know about, the follow up posts in this series will provide an in-depth explanation of each: what it does, where it fits, what problems it solves, guidance on when you should use it, and guidance on where the community could take additional steps with them. Stay tuned.