On Nov 26, 2013, at 11:01 AM, Sean OMeara < "> > wrote: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 https://github.com/poise 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.
> 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.
--Noah
Archive powered by MHonArc 2.6.16.