Earlier this month we held the third annual Opscode Community Summit. There, we shared some lessons we’ve learned about publishing and maintaining community cookbooks. For those that could not be there, we’d like to share them with you as well.
Over the years, thoughts and attitudes about what cookbooks are and how they should be treated have evolved. In the beginning, everyone wrote their cookbooks from scratch to manage their infrastructure. This is the simplest use case for Chef users, and remains the most popular. Every organization is different, and comes with unique requirements, culture, history and challenges.
Early on, we introduced the Opscode Community site and encouraged our community to share. This was a huge success, and changed the way people thought about cookbooks. The community site has turned into a public artifact repository, and currently serves 1198 cookbooks from thousands of contributors all over the world.
Opscode has been maintaining a number of these cookbooks. One thing we’ve discovered is that when they’re awesome, its usually because they fall into one of three categories. First, they do the easy thing and behave the way one would expect on a particular platform. Second, they’ve grown to encompass many possible configuration scenarios across many different platforms, usually bending some idioms along the way. Third, they provide robust, easy to use libraries that expose custom resources and providers that users can consume as primitives in their own recipes.
Most of the cookbooks that Opscode maintains have drifted towards the category two. That’s great for a user that’s both an expert in Chef, as well as the technology represented in a given cookbook. However, most users do not fit that profile. The third scenario is more ideal.
As it turns out, we are not domain experts in all the technologies many of our cookbooks represent. This means we’ve become a roadblock in the development of many of these projects. Nobody likes roadblocks.
After careful consideration, we’ve decided that the best thing to do for the cookbook ecosystem is to seek out trusted maintainers with domain expertise in the technologies embodied in the various projects. This will allow us to focus on building primitives; libraries, resources, providers, and well engineered content for new Chef users.
We are still very much in the cookbook game. We’re just making the game better. As we set many our cookbooks free, we’ll maintain contributor status, but no longer play the role of primary maintainer. This decentralization will ease the friction associated with contributing patches, and allow each cookbook to reach its full potential.
We will be holding onto cookbooks that represent the core building blocks that we use at our customer sites every day. These will serve as reference cookbooks for others to use as examples. Sharpening our focus will help us to make each one the best it can be.
2014 is going to be an exciting year for Chef.
May the Source be with you.
