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.
-s