In our shop, we deliberately chose to write our own cookbooks - most of the time. Even though NIH - Not Invented Here - is at the top of what software engineers try to stay away from. If we can help others with what we have learned about NIH vs ReInventing Chef recipes - here goes:

Community Cookbooks Are A Completely Different Animal

Noah Kantrowitz was the pivotal decision key for us on this important issue. He did a great talk at last year's Chef Conf, where he explains that a good community cookbook might take 10 times or more work  than a good company specific cookbook. We think this might even be an understatement.

The reasons are mathematical. Each of these factors almost mulitplies the amount of code in a cookbook, times the other factors.

  • Each platform (Centos, Ubuntu, Windoze, etc)
  • Idempotent code for each feature
  • Each favorite feature's configuration context
  • Other...

By the time you account for each of the above group of factors, you have walked so far astray of your own company's needs, the entire idea of a community cookbook can be overwhelming. Yet this is all quite necessary, if you wish to be a solid community cookbook.

EXAMPLE: We don't deploy to Windoze, only Centos. A good community cookbook must, of course, do that. But that's just one of many examples.

Simple Recipes Are NOT That Hard

Our own needs are for simplicity - for it's own sake. Jeff can write a fully tested cookbook in a couple hours or less if it's simple - and most are. If it isn't simple, that kind of defeats our objectives anyway. We want to be able to get stuff working for our shop, and then quickly cherry-pick recipes to assemble servers quickly.

When I need a server I might wish to just grab - for example - these quick recipes and presto change-o, I'm ready to go:

  • java
  • maven
  • NTP
  • tomcat
  • nginx

We Cut Corners - Proudly!

There is more. We also accept some small amount of manual configuration in our servers that would be inappropriate for a community recipe.

As a contrast, Facebook might push just one server configuration idempotently to 17,000+ servers every 36 hours. Absolutely NO manual configuration is OK in that situation. Period. The end.

We're a small shop. Chef makes what we do possible and still stay small. If we had to build servers by hand we would go broke doing the experimentation that we do. Lots of shops fit that paradigm. 

But small shops work well with a microscopic degree of manual server set-up after the first Chef run. We do so unapologetically, when it's the practical thing to do. That extra degree of automation might make it take 10 hours, rather than 2 hours, to write the cookbook. No point, for us. 

EXAMPLE: A Jenkins server for one of our project workspaces requires some small amount of manual setup. This could probably be automated to some degree. No, we won't try, payback is too small. And it only affects the initial setup, not the idempotent aspect.

Commentary: Community Cookbooks

Much is written about the sorry state of Chef community cookbooks from early Chef years. Things are better in the land of Community Cookbooks this year, than they were last year. Noah Kantrowitz has also been a radical force for good in this area.

Without explaining all the many reasons why, we always advise our friends to simply stay away - except for those few cookbooks which are known to be superstars. These few do exist.


It doesn't take very long to write your own cookbooks. Writing your own is a good default rule.

Here's our own github recipe listing - from about a year ago. Some may thus be out of date.