Community Cookbooks

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

On Nov 26, 2013, at 11:01 AM, Sean OMeara someara@opscode.com wrote:

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.

Just wanted to chime in and thank Sean, Bryan, and Opscode in general for offering me maintainership of the Python-related and application* cookbooks. With Bryan's help we've moved the repositories over to the Poise · GitHub organization, and I'm currently plotting out how to setup the contribution process (moving away from Opscode Jira and towards Github Issues unless that doesn't work out for some reason). All github "watches" and "stars" should have moved over, and redirects are in place, but if you have any bookmarks for the following cookbooks, now might be a good time to update them: python, supervisor, mercurial, application, application_python, application_ruby, application_nginx, application_php, and application_java.

--Noah

Thanks for taking these over, Noah - they are in great hands.

Best,
Adam

On Wed, Nov 27, 2013 at 9:12 AM, Noah Kantrowitz noah@coderanger.netwrote:

On Nov 26, 2013, at 11:01 AM, Sean OMeara someara@opscode.com wrote:

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.

Just wanted to chime in and thank Sean, Bryan, and Opscode in general for
offering me maintainership of the Python-related and application*
cookbooks. With Bryan's help we've moved the repositories over to the
Poise · GitHub organization, and I'm currently plotting out how
to setup the contribution process (moving away from Opscode Jira and
towards Github Issues unless that doesn't work out for some reason). All
github "watches" and "stars" should have moved over, and redirects are in
place, but if you have any bookmarks for the following cookbooks, now might
be a good time to update them: python, supervisor, mercurial, application,
application_python, application_ruby, application_nginx, application_php,
and application_java.

--Noah

--
Opscode, Inc.
Adam Jacob, Chief Dev Officer
T: (206) 619-7151 E: adam@opscode.com