# Community cookbook maintenance (was: Re: Reprepro cookbook)

**URL:** <https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691>\
**Category:** Chef Infra (archive)\
**Created:** [June 22, 2015, 8:52pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691 "2015-06-22T20:52:23Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![jdunn](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jdunn/32/1800_2.png) [@jdunn](https://discourse.chef.io/u/jdunn)\
**Post date:** [June 22, 2015, 8:52pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/1 "2015-06-22T20:52:23Z")

</div>

On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:

> To speak for Chef Software directly, we have always had people on staff  
> whose role was assisting the creation and maintenance of cookbooks. That  
> number has fluctuated up and down over time, with the skill sets of people  
> we hire, and the normal day-to-day ebb and flow of trying to figure out how  
> to build a business that is successful. We have people on staff today who do  
> the same. What is clear is that the energy around cookbooks in the community  
> is far greater than the energy we can muster as an organization (regardless  
> of how much capital we do or do not have - y'all outnumber us) - and so our  
> focus today is on trying to build and support the best community we can,  
> through development of the supermarket, better tooling, and providing a few  
> key examples of how best to build a community cookbook (see Sean's work on  
> the httpd cookbook.)
> 
> Perhaps we need to organize a PR/merge festival brigade?

Hey Adam,

Would we consider transferring some of those cookbooks our of  
{opscode,chef}-cookbooks to a community-organized org like  
chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
the preconditions to doing that?

Personally I would like the chef-brigade and redguide to be merged,  
but I do not remember all the players involved -- if they are on this  
list perhaps they can speak up.

- Julian

---

<div class="post-metadata">

**Author:** ![Roland\_Moriz1](https://avatars.discourse-cdn.com/v4/letter/r/9fc29f/32.png) [@Roland\_Moriz1](https://discourse.chef.io/u/Roland_Moriz1)\
**Post date:** [June 22, 2015, 9:27pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/2 "2015-06-22T21:27:42Z")

</div>

> Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> 
> On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> 
> > To speak for Chef Software directly, we have always had people on staff  
> > whose role was assisting the creation and maintenance of cookbooks. That  
> > number has fluctuated up and down over time, with the skill sets of people  
> > we hire, and the normal day-to-day ebb and flow of trying to figure out how  
> > to build a business that is successful. We have people on staff today who do  
> > the same. What is clear is that the energy around cookbooks in the community  
> > is far greater than the energy we can muster as an organization (regardless  
> > of how much capital we do or do not have - y'all outnumber us) - and so our  
> > focus today is on trying to build and support the best community we can,  
> > through development of the supermarket, better tooling, and providing a few  
> > key examples of how best to build a community cookbook (see Sean's work on  
> > the httpd cookbook.)
> > 
> > Perhaps we need to organize a PR/merge festival brigade?
> 
> Hey Adam,
> 
> Would we consider transferring some of those cookbooks our of  
> {opscode,chef}-cookbooks to a community-organized org like  
> chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> the preconditions to doing that?
> 
> Personally I would like the chef-brigade and redguide to be merged,  
> but I do not remember all the players involved -- if they are on this  
> list perhaps they can speak up.

How would this prevent the problems that happend with the last migration of former opscode-cookbooks to community maintainers?

Why should community maintainers care about the cookbooks in the future?  
It can be a time consuming burden and people need to pay their rent and do their regular jobs…

I know, this will be very provoking, but:

If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is there still a valid reason for running a public Supermarket site?  
If you go the "libertarian way" there is no reason for a supermarket site to protect/block names of cookbooks anymore that prevents users to pick other, maybe better community resources over legacy-cookbooks that are mentioned in guides and examples.

Either you (Chef, Inc.) control the market (e.g. maintain critical things yourself) or you should allow the free market (=community) to compete against each other based on equal opportunity (= namespaces or no supermarket). Everything else/in between will just end in chaos and anarchy.

regards  
Roland

---

<div class="post-metadata">

**Author:** ![Drew\_Blessing1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/drew_blessing1/32/51_2.png) [@Drew\_Blessing1](https://discourse.chef.io/u/Drew_Blessing1)\
**Post date:** [June 22, 2015, 10:09pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/3 "2015-06-22T22:09:20Z")

</div>

Roland,

A discussion about whether Chef Software continues to maintain cookbooks  
has little to do with whether Supermarket is valuable. Even if Chef  
Software maintains zero cookbooks the Supermarket is a huge community asset  
(consider RubyGems). Let's not muddy the waters here.

On Mon, Jun 22, 2015 at 4:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:

> > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > 
> > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > 
> > > To speak for Chef Software directly, we have always had people on staff  
> > > whose role was assisting the creation and maintenance of cookbooks. That  
> > > number has fluctuated up and down over time, with the skill sets of  
> > > people  
> > > we hire, and the normal day-to-day ebb and flow of trying to figure out  
> > > how  
> > > to build a business that is successful. We have people on staff today  
> > > who do  
> > > the same. What is clear is that the energy around cookbooks in the  
> > > community  
> > > is far greater than the energy we can muster as an organization  
> > > (regardless  
> > > of how much capital we do or do not have - y'all outnumber us) - and so  
> > > our  
> > > focus today is on trying to build and support the best community we can,  
> > > through development of the supermarket, better tooling, and providing a  
> > > few  
> > > key examples of how best to build a community cookbook (see Sean's work  
> > > on  
> > > the httpd cookbook.)
> > > 
> > > Perhaps we need to organize a PR/merge festival brigade?
> > 
> > Hey Adam,
> > 
> > Would we consider transferring some of those cookbooks our of  
> > {opscode,chef}-cookbooks to a community-organized org like  
> > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > the preconditions to doing that?
> > 
> > Personally I would like the chef-brigade and redguide to be merged,  
> > but I do not remember all the players involved -- if they are on this  
> > list perhaps they can speak up.
> 
> How would this prevent the problems that happend with the last migration  
> of former opscode-cookbooks to community maintainers?
> 
> Why should community maintainers care about the cookbooks in the future?  
> It can be a time consuming burden and people need to pay their rent and do  
> their regular jobs…
> 
> I know, this will be very provoking, but:
> 
> If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is  
> there still a valid reason for running a public Supermarket site?  
> If you go the "libertarian way" there is no reason for a supermarket site  
> to protect/block names of cookbooks anymore that prevents users to pick  
> other, maybe better community resources over legacy-cookbooks that are  
> mentioned in guides and examples.
> 
> Either you (Chef, Inc.) control the market (e.g. maintain critical things  
> yourself) or you should allow the free market (=community) to compete  
> against each other based on equal opportunity (= namespaces or no  
> supermarket). Everything else/in between will just end in chaos and anarchy.
> 
> regards  
> Roland

--  
Drew

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [June 22, 2015, 10:23pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/4 "2015-06-22T22:23:47Z")

</div>

yes there is a lot of value with Chef inc, providing a public supermarket  
instance, it seeds community effort. You dont need it if you consume  
cookbooks from github or other sources (can be public, can be private/org  
specific).

why should community maintainers maintain a cookbook? - many. and i dont  
see the different of this with ruby gem, or any userspace tool (pyhton egg,  
or a debian in ppa). But the common reasons are: 1) you dont want to  
reinvent wheel,. if theres no opensource cookbook on ossec, every time i  
join a place it allows me rapidly roll out ossec cookboook. 2) my job  
depends on my skills/knowledge, to get a better job, i need to improve my  
skill. but that not possible if theres no one to mentor inside my own org.  
opensource brings that possibility. again this is not specific to chef, its  
very opensource thing, if you dont understand it, or dont know what value  
you get, dont do it. but for those of us, who are outside chef, uses it,  
and loves it. exposure is a huge thing, i cant become oracle reporting  
expert, but i can become chef expert even if dont have much money.

the last statement you made regarding namespace, is a technical problem.  
again its no different here than any other place. for example redhat has  
libvirt-lxc which everyone confuses with standard LXC but the project  
itself has little code/feature compatibility with main LXC. The point is  
like namespace is perceived, if you want you can publish a cookbook with  
samename and if its really good (and assuming theres enough people who  
wants it) you can definitely outweigh the other cookbook. if thats not  
happening, lets address that.

the definition of critical is very diverse, theres no common critical  
component/cookbook. nothing. 0. as far as the whole community is concerned.  
if you freeze platform (since chef run from windows machine to raspberry  
pi to AIX to solaris) you might get a list of critical cookbooks (like sudo  
will be for linux), you might get another layer on family (like sysdtemd on  
ubuntu 15.04) .. we are in process of establishing the family specific  
maintainers, a similar effort can be made for cookbooks as well.. but will  
be mostly community and few core contributors .. similar to kernel and  
userspace.. linus and linux foundation or redhat does not maintain ruby  
specific rpm etc..

i am very interested in addressing this.. please keep your thoughts pouring  
🙂 , but understand we cant solve it in a click, its gonna take some time,  
we have to keep talking, and out collaborative efforts on the next blockers  
toward this direction.

fwiw i am the LT of chef on ubuntu, and i am working on a CD system that  
will test actual community cookbooks on every master merge of chef. Which  
will greatly reduce the maintenance burden, cause now core devs can also  
see what affect the changeset has. Next step will be do a survey and get a  
list of cookbooks and interested folks (brigade as we calling it) for  
ubuntu. What i wonder is a common pool might not make sense, though Chef is  
cross platform, majority of cookbook is not.

hth  
ranjib

On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:

> > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > 
> > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > 
> > > To speak for Chef Software directly, we have always had people on staff  
> > > whose role was assisting the creation and maintenance of cookbooks. That  
> > > number has fluctuated up and down over time, with the skill sets of  
> > > people  
> > > we hire, and the normal day-to-day ebb and flow of trying to figure out  
> > > how  
> > > to build a business that is successful. We have people on staff today  
> > > who do  
> > > the same. What is clear is that the energy around cookbooks in the  
> > > community  
> > > is far greater than the energy we can muster as an organization  
> > > (regardless  
> > > of how much capital we do or do not have - y'all outnumber us) - and so  
> > > our  
> > > focus today is on trying to build and support the best community we can,  
> > > through development of the supermarket, better tooling, and providing a  
> > > few  
> > > key examples of how best to build a community cookbook (see Sean's work  
> > > on  
> > > the httpd cookbook.)
> > > 
> > > Perhaps we need to organize a PR/merge festival brigade?
> > 
> > Hey Adam,
> > 
> > Would we consider transferring some of those cookbooks our of  
> > {opscode,chef}-cookbooks to a community-organized org like  
> > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > the preconditions to doing that?
> > 
> > Personally I would like the chef-brigade and redguide to be merged,  
> > but I do not remember all the players involved -- if they are on this  
> > list perhaps they can speak up.
> 
> How would this prevent the problems that happend with the last migration  
> of former opscode-cookbooks to community maintainers?
> 
> Why should community maintainers care about the cookbooks in the future?  
> It can be a time consuming burden and people need to pay their rent and do  
> their regular jobs…
> 
> I know, this will be very provoking, but:
> 
> If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is  
> there still a valid reason for running a public Supermarket site?  
> If you go the "libertarian way" there is no reason for a supermarket site  
> to protect/block names of cookbooks anymore that prevents users to pick  
> other, maybe better community resources over legacy-cookbooks that are  
> mentioned in guides and examples.
> 
> Either you (Chef, Inc.) control the market (e.g. maintain critical things  
> yourself) or you should allow the free market (=community) to compete  
> against each other based on equal opportunity (= namespaces or no  
> supermarket). Everything else/in between will just end in chaos and anarchy.
> 
> regards  
> Roland

---

<div class="post-metadata">

**Author:** ![Roland\_Moriz1](https://avatars.discourse-cdn.com/v4/letter/r/9fc29f/32.png) [@Roland\_Moriz1](https://discourse.chef.io/u/Roland_Moriz1)\
**Post date:** [June 24, 2015, 11:36am UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/5 "2015-06-24T11:36:23Z")

</div>

Hi,

> Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> 
> yes there is a lot of value with Chef inc, providing a public supermarket instance, it seeds community effort. You dont need it if you consume cookbooks from github or other sources (can be public, can be private/org specific).

I don’t think that it seeds community effort, because it’s often a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken, outdated or just be a no-op cookbook that reserves the name:

[https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=) [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)

- number of downloads is irrelevant, as we all know
- follower number is also not a good indication, because even after a year, supermarket did not get the traction of e.g. github
- last release date is probably the best indicator. In my experience most cookbooks that are not updated within the last 12 months are outdated, e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How should starters „know“ this?

Imagine a rather new chef user that needs to deal with systemd unit files. Just with that single „trap" he/she will probably lose a couple of hours or days or give up and pick something else with batteries included.

I’m sure this is not intentional and everyone had the best intentions doing it the current way - but IMHO it’s broken :-/  
IMHO it’s all about hitting the right spot in between of „too much“ and „too little“ and the original opscode-cookbooks concept was probably a „too much“-problem and today it looks like we’re in a „too little“ situation.

> why should community maintainers maintain a cookbook? - many. and i dont see the different of this with ruby gem, or any userspace tool (pyhton egg, or a debian in ppa). But the common reasons are: 1) you dont want to reinvent wheel,. if theres no opensource cookbook on ossec, every time i join a place it allows me rapidly roll out ossec cookboook. 2) my job depends on my skills/knowledge, to get a better job, i need to improve my skill. but that not possible if theres no one to mentor inside my own org. opensource brings that possibility. again this is not specific to chef, its very opensource thing, if you dont understand it, or dont know what value you get, dont do it. but for those of us, who are outside chef, uses it, and loves it. exposure is a huge thing, i cant become oracle reporting expert, but i can become chef expert even if dont have much money.

Sorry, but that doesn’t answer my question. Many open source projects start, when something (technology, framework) becomes „hot“. Everyone is trying to learn and get a spot in the eco system. Popularity usually also means a rising number of jobs, e.g. people can get their OSS contribution funded and/or get an interesting job. However this strategy starts to collapse when the crowd moves on to „even hotter“ things (typical hype lifecycle).

Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now outdated npm modules -\> maintainer moved to Go.  
Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker

This brain-drain affects not only the quantity but also the quality of projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to use it. Experience for new users will suffer.  
Why should people contribute to $not\_hot\_anymore projects? I don’t see that many unique chef-jobs, so having something in the GitHub repo/CV doesn’t bring you new opportunities by itself.  
Even a popular (\>200 stars on GH) knife plugin for some trending and cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).

possible options:

- provide minimal services that work out of the box by yourself (Chef, Inc)
- subsidize community to maintain it (you pay, you decide how)
- offer opportunities so people can benefit from supporting the community (e.g. job site, contract projects, sales-partnerships with indies)  
otoh: As far as I can see, most „Chef certified partners“ listed on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) [https://www.chef.io/partners/#find-a-partner](https://www.chef.io/partners/#find-a-partner) are not part of the community and some companies that provide value to the community are not listed there at all…

> the last statement you made regarding namespace, is a technical problem. again its no different here than any other place. for example redhat has libvirt-lxc which everyone confuses with standard LXC but the project itself has little code/feature compatibility with main LXC. The point is like namespace is perceived, if you want you can publish a cookbook with samename and if its really good (and assuming theres enough people who wants it) you can definitely outweigh the other cookbook. if thats not happening, lets address that.

Your libvirt-example is great, as it shows why nearly nobody used it and why Docker has such a huge impact by just providing a fancy way to distribute tar archives and wrap some syscalls 😉 (oversimplification intentional)  
Redhat isn’t very good in community/relationship outside of their own Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and admins. I think better tutorials and community-relations would have prevented that hatery/shitstorm against it.  
When I talk to systemd-"haters", I ask them to write me a sysv-init script for a service, then I show them the systemd unit representation.  
When ansible users talk to me (chef user), they ask me to write a solution that… whops. damn. You understand what I mean?

> the definition of critical is very diverse, theres no common critical component/cookbook. nothing. 0. as far as the whole community is concerned. if you freeze platform (since chef run from windows machine to raspberry pi to AIX to solaris) you might get a list of critical cookbooks (like sudo will be for linux), you might get another layer on family (like sysdtemd on ubuntu 15.04) .. we are in process of establishing the family specific maintainers, a similar effort can be made for cookbooks as well.. but will be mostly community and few core contributors .. similar to kernel and userspace.. linus and linux foundation or redhat does not maintain ruby specific rpm etc..

Why do people need DevOps? To have a reliable infrastructure to provide services that make money and to stay competitive. Usually that involves more or less custom applications based on common frameworks/stacks that need to be deployed. So at least a couple of application deployment stacks are critical to show the benefits of a DevOps solution. Even the [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest releases of cookbooks used in the tutorial, so this is also a good definition of critical.

> i am very interested in addressing this.. please keep your thoughts pouring 🙂 , but understand we cant solve it in a click, its gonna take some time, we have to keep talking, and out collaborative efforts on the next blockers toward this direction.

> fwiw i am the LT of chef on ubuntu, and i am working on a CD system that will test actual community cookbooks on every master merge of chef. Which will greatly reduce the maintenance burden, cause now core devs can also see what affect the changeset has. Next step will be do a survey and get a list of cookbooks and interested folks (brigade as we calling it) for ubuntu. What i wonder is a common pool might not make sense, though Chef is cross platform, majority of cookbook is not.

You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something like „it installs runit triggered by sysv-init — and it still works…“ on a systemd distro 😉

regards  
Roland

PS: Despite all my examples I’m not a systemd zealot. I was okay with upstart… But a common base of various distros is a good thing for everyone in the long run. And it’s also a good example for a game-changer and about the agility/adoption capabilities of such things.

> hth  
> ranjib
> 
> On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz \<[rmoriz@gmail.com](mailto:rmoriz@gmail.com) [mailto:rmoriz@gmail.com](mailto:rmoriz@gmail.com)\> wrote:
> 
> > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn \<[jdunn@aquezada.com](mailto:jdunn@aquezada.com) [mailto:jdunn@aquezada.com](mailto:jdunn@aquezada.com)\>:
> > 
> > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob \<[adam@chef.io](mailto:adam@chef.io) [mailto:adam@chef.io](mailto:adam@chef.io)\> wrote:
> > 
> > > To speak for Chef Software directly, we have always had people on staff  
> > > whose role was assisting the creation and maintenance of cookbooks. That  
> > > number has fluctuated up and down over time, with the skill sets of people  
> > > we hire, and the normal day-to-day ebb and flow of trying to figure out how  
> > > to build a business that is successful. We have people on staff today who do  
> > > the same. What is clear is that the energy around cookbooks in the community  
> > > is far greater than the energy we can muster as an organization (regardless  
> > > of how much capital we do or do not have - y'all outnumber us) - and so our  
> > > focus today is on trying to build and support the best community we can,  
> > > through development of the supermarket, better tooling, and providing a few  
> > > key examples of how best to build a community cookbook (see Sean's work on  
> > > the httpd cookbook.)
> > > 
> > > Perhaps we need to organize a PR/merge festival brigade?
> > 
> > Hey Adam,
> > 
> > Would we consider transferring some of those cookbooks our of  
> > {opscode,chef}-cookbooks to a community-organized org like  
> > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade) [https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > ([redguide · GitHub](https://github.com/redguide) [https://github.com/redguide](https://github.com/redguide)) for better maintenance? What would be  
> > the preconditions to doing that?
> > 
> > Personally I would like the chef-brigade and redguide to be merged,  
> > but I do not remember all the players involved -- if they are on this  
> > list perhaps they can speak up.
> 
> How would this prevent the problems that happend with the last migration of former opscode-cookbooks to community maintainers?
> 
> Why should community maintainers care about the cookbooks in the future?  
> It can be a time consuming burden and people need to pay their rent and do their regular jobs…
> 
> I know, this will be very provoking, but:
> 
> If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is there still a valid reason for running a public Supermarket site?  
> If you go the "libertarian way" there is no reason for a supermarket site to protect/block names of cookbooks anymore that prevents users to pick other, maybe better community resources over legacy-cookbooks that are mentioned in guides and examples.
> 
> Either you (Chef, Inc.) control the market (e.g. maintain critical things yourself) or you should allow the free market (=community) to compete against each other based on equal opportunity (= namespaces or no supermarket). Everything else/in between will just end in chaos and anarchy.
> 
> regards  
> Roland

---

<div class="post-metadata">

**Author:** ![nathwill](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/nathwill/32/25_2.png) [@nathwill](https://discourse.chef.io/u/nathwill)\
**Post date:** [June 24, 2015, 3:33pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/6 "2015-06-24T15:33:49Z")

</div>

interesting topic. pretty recently, my "one word description" for community  
cookbooks was "cesspool", though i think that's getting a little better  
lately, and now i'd have to choose a nicer word :). even so, cookbook  
quality is definitely an area where we, as a community could benefit from  
ongoing effort.

obviously, Chef Inc can't do all the heavy lifting, nor would they be the  
most qualified in many cases. the old "official" cookbook thing was a nice  
bootstrap technique, but even those weren't always the best available  
cookbook, though they at least usually had a healthy number of eyes on them.

i'd be really bummed to see us going back to a model where Chef Inc is  
directly, or through contractors, propping up the cookbook ecosystem, but i  
do think more could be done than is happening now.

i'd really like to see some official (maybe a BCP Chef RFC?) guidelines for  
quality based around the BCP guidelines... For example: evaluated with  
foodcritic and rubocop, integration tested with test-kitchen suites that  
cover the majority of recipe code-paths (e.g. source vs package install,  
etc.), unit tested with chefspec, and support for the relevant  
Chef-supported platforms (

> <https://github.com/chef-boneyard/chef-rfc/blob/master/rfc021-platform-support-policy.md>

).

if we then had some application process for Chef Inc to certify a cookbook  
as complying with the BCP, and we surfaced BCP-compliant cookbooks through  
Supermarket (with periodic review/recertification), I think we'd be most of  
the way to victory. This kind of surfacing would help deal with the naming  
conflict and abandoned cookbook issues we currently have to deal with (the  
systemd cookbook is a particularly egregious example of name-squatting),  
and would hopefully encourage community cookbook developers to put in extra  
effort, knowing that BCP compliance meant better visibility and more  
adoption.

anyways, that's my two cents.

regards,

nathan w

On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:

> Hi,
> 
> Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> 
> yes there is a lot of value with Chef inc, providing a public supermarket  
> instance, it seeds community effort. You dont need it if you consume  
> cookbooks from github or other sources (can be public, can be private/org  
> specific).
> 
> I don’t think that it seeds community effort, because it’s often a „trap“.  
> A cookbook, e.g. named `systemd`, looks legit but it may be broken,  
> outdated or just be a no-op cookbook that reserves the name:
> 
> [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)  
> [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> 
> - number of downloads is irrelevant, as we all know
> - follower number is also not a good indication, because even after a  
> year, supermarket did not get the traction of e.g. github
> - last release date is probably the best indicator. In my experience most  
> cookbooks that are not updated within the last 12 months are outdated, e.g.  
> won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How  
> should starters „know“ this?
> 
> Imagine a rather new chef user that needs to deal with systemd unit files.  
> Just with that single „trap" he/she will probably lose a couple of hours or  
> days or give up and pick something else with batteries included.
> 
> I’m sure this is not intentional and everyone had the best intentions  
> doing it the current way - but IMHO it’s broken :-/  
> IMHO it’s all about hitting the right spot in between of „too much“ and  
> „too little“ and the original opscode-cookbooks concept was probably a „too  
> much“-problem and today it looks like we’re in a „too little“ situation.
> 
> why should community maintainers maintain a cookbook? - many. and i dont  
> see the different of this with ruby gem, or any userspace tool (pyhton egg,  
> or a debian in ppa). But the common reasons are: 1) you dont want to  
> reinvent wheel,. if theres no opensource cookbook on ossec, every time i  
> join a place it allows me rapidly roll out ossec cookboook. 2) my job  
> depends on my skills/knowledge, to get a better job, i need to improve my  
> skill. but that not possible if theres no one to mentor inside my own org.  
> opensource brings that possibility. again this is not specific to chef, its  
> very opensource thing, if you dont understand it, or dont know what value  
> you get, dont do it. but for those of us, who are outside chef, uses it,  
> and loves it. exposure is a huge thing, i cant become oracle reporting  
> expert, but i can become chef expert even if dont have much money.
> 
> Sorry, but that doesn’t answer my question. Many open source projects  
> start, when something (technology, framework) becomes „hot“. Everyone is  
> trying to learn and get a spot in the eco system. Popularity usually also  
> means a rising number of jobs, e.g. people can get their OSS contribution  
> funded and/or get an interesting job. However this strategy starts to  
> collapse when the crowd moves on to „even hotter“ things (typical hype  
> lifecycle).
> 
> Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now  
> outdated npm modules -\> maintainer moved to Go.  
> Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> 
> This brain-drain affects not only the quantity but also the quality of  
> projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to  
> use it. Experience for new users will suffer.  
> Why should people contribute to $not\_hot\_anymore projects? I don’t see  
> that many unique chef-jobs, so having something in the GitHub repo/CV  
> doesn’t bring you new opportunities by itself.  
> Even a popular (\>200 stars on GH) knife plugin for some trending and cheap  
> cloud hosting provider brings you exactly 0 job/project offers (btdt).
> 
> possible options:
> 
> - provide minimal services that work out of the box by yourself (Chef, Inc)
> - subsidize community to maintain it (you pay, you decide how)
> - offer opportunities so people can benefit from supporting the community  
> (e.g. job site, contract projects, sales-partnerships with indies)  
> otoh: As far as I can see, most „Chef certified partners“ listed on  
> [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the  
> community and some companies that provide value to the community are not  
> listed there at all…
> 
> the last statement you made regarding namespace, is a technical problem.  
> again its no different here than any other place. for example redhat has  
> libvirt-lxc which everyone confuses with standard LXC but the project  
> itself has little code/feature compatibility with main LXC. The point is  
> like namespace is perceived, if you want you can publish a cookbook with  
> samename and if its really good (and assuming theres enough people who  
> wants it) you can definitely outweigh the other cookbook. if thats not  
> happening, lets address that.
> 
> Your libvirt-example is great, as it shows why nearly nobody used it and  
> why Docker has such a huge impact by just providing a fancy way to  
> distribute tar archives and wrap some syscalls 😉 (oversimplification  
> intentional)  
> Redhat isn’t very good in community/relationship outside of their own  
> Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and  
> admins. I think better tutorials and community-relations would have  
> prevented that hatery/shitstorm against it.  
> When I talk to systemd-"haters", I ask them to write me a sysv-init script  
> for a service, then I show them the systemd unit representation.  
> When ansible users talk to me (chef user), they ask me to write a solution  
> that… whops. damn. You understand what I mean?
> 
> the definition of critical is very diverse, theres no common critical  
> component/cookbook. nothing. 0. as far as the whole community is concerned.  
> if you freeze platform (since chef run from windows machine to raspberry  
> pi to AIX to solaris) you might get a list of critical cookbooks (like sudo  
> will be for linux), you might get another layer on family (like sysdtemd on  
> ubuntu 15.04) .. we are in process of establishing the family specific  
> maintainers, a similar effort can be made for cookbooks as well.. but will  
> be mostly community and few core contributors .. similar to kernel and  
> userspace.. linus and linux foundation or redhat does not maintain ruby  
> specific rpm etc..
> 
> Why do people need DevOps? To have a reliable infrastructure to provide  
> services that make money and to stay competitive. Usually that involves  
> more or less custom applications based on common frameworks/stacks that  
> need to be deployed. So at least a couple of application deployment stacks  
> are critical to show the benefits of a DevOps solution. Even the  
> [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest releases  
> of cookbooks used in the tutorial, so this is also a good definition of  
> critical.
> 
> i am very interested in addressing this.. please keep your thoughts  
> pouring 🙂 , but understand we cant solve it in a click, its gonna take  
> some time, we have to keep talking, and out collaborative efforts on the  
> next blockers toward this direction.
> 
> fwiw i am the LT of chef on ubuntu, and i am working on a CD system that  
> will test actual community cookbooks on every master merge of chef. Which  
> will greatly reduce the maintenance burden, cause now core devs can also  
> see what affect the changeset has. Next step will be do a survey and get a  
> list of cookbooks and interested folks (brigade as we calling it) for  
> ubuntu. What i wonder is a common pool might not make sense, though Chef is  
> cross platform, majority of cookbook is not.
> 
> You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL 7,  
> Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something  
> like „it installs runit triggered by sysv-init — and it still works…“ on a  
> systemd distro 😉
> 
> regards  
> Roland
> 
> PS: Despite all my examples I’m not a systemd zealot. I was okay with  
> upstart… But a common base of various distros is a good thing for everyone  
> in the long run. And it’s also a good example for a game-changer and about  
> the agility/adoption capabilities of such things.
> 
> hth  
> ranjib
> 
> On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> 
> > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > 
> > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > 
> > > > To speak for Chef Software directly, we have always had people on staff  
> > > > whose role was assisting the creation and maintenance of cookbooks.  
> > > > That  
> > > > number has fluctuated up and down over time, with the skill sets of  
> > > > people  
> > > > we hire, and the normal day-to-day ebb and flow of trying to figure  
> > > > out how  
> > > > to build a business that is successful. We have people on staff today  
> > > > who do  
> > > > the same. What is clear is that the energy around cookbooks in the  
> > > > community  
> > > > is far greater than the energy we can muster as an organization  
> > > > (regardless  
> > > > of how much capital we do or do not have - y'all outnumber us) - and  
> > > > so our  
> > > > focus today is on trying to build and support the best community we  
> > > > can,  
> > > > through development of the supermarket, better tooling, and providing  
> > > > a few  
> > > > key examples of how best to build a community cookbook (see Sean's  
> > > > work on  
> > > > the httpd cookbook.)
> > > > 
> > > > Perhaps we need to organize a PR/merge festival brigade?
> > > 
> > > Hey Adam,
> > > 
> > > Would we consider transferring some of those cookbooks our of  
> > > {opscode,chef}-cookbooks to a community-organized org like  
> > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > > the preconditions to doing that?
> > > 
> > > Personally I would like the chef-brigade and redguide to be merged,  
> > > but I do not remember all the players involved -- if they are on this  
> > > list perhaps they can speak up.
> > 
> > How would this prevent the problems that happend with the last migration  
> > of former opscode-cookbooks to community maintainers?
> > 
> > Why should community maintainers care about the cookbooks in the future?  
> > It can be a time consuming burden and people need to pay their rent and  
> > do their regular jobs…
> > 
> > I know, this will be very provoking, but:
> > 
> > If Chef, inc. doesn't want to maintain even critical cookbooks anymore,  
> > is there still a valid reason for running a public Supermarket site?  
> > If you go the "libertarian way" there is no reason for a supermarket site  
> > to protect/block names of cookbooks anymore that prevents users to pick  
> > other, maybe better community resources over legacy-cookbooks that are  
> > mentioned in guides and examples.
> > 
> > Either you (Chef, Inc.) control the market (e.g. maintain critical things  
> > yourself) or you should allow the free market (=community) to compete  
> > against each other based on equal opportunity (= namespaces or no  
> > supermarket). Everything else/in between will just end in chaos and anarchy.
> > 
> > regards  
> > Roland

---

<div class="post-metadata">

**Author:** ![ssd](https://avatars.discourse-cdn.com/v4/letter/s/7993a0/32.png) [@ssd](https://discourse.chef.io/u/ssd)\
**Post date:** [June 25, 2015, 5:14am UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/7 "2015-06-25T05:14:11Z")

</div>

> I don’t think that it seeds community effort, because it’s often a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken, outdated or just be a no-op cookbook that reserves the name:

FWIW, I acquired this cookbook mostly by accident. If anyone would  
like to do something with it, please let me know.

On Wed, Jun 24, 2015 at 1:36 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:

> Hi,
> 
> Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> 
> yes there is a lot of value with Chef inc, providing a public supermarket  
> instance, it seeds community effort. You dont need it if you consume  
> cookbooks from github or other sources (can be public, can be private/org  
> specific).
> 
> I don’t think that it seeds community effort, because it’s often a „trap“. A  
> cookbook, e.g. named `systemd`, looks legit but it may be broken, outdated  
> or just be a no-op cookbook that reserves the name:
> 
> [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> 
> - number of downloads is irrelevant, as we all know
> - follower number is also not a good indication, because even after a year,  
> supermarket did not get the traction of e.g. github
> - last release date is probably the best indicator. In my experience most  
> cookbooks that are not updated within the last 12 months are outdated, e.g.  
> won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How  
> should starters „know“ this?
> 
> Imagine a rather new chef user that needs to deal with systemd unit files.  
> Just with that single „trap" he/she will probably lose a couple of hours or  
> days or give up and pick something else with batteries included.
> 
> I’m sure this is not intentional and everyone had the best intentions doing  
> it the current way - but IMHO it’s broken :-/  
> IMHO it’s all about hitting the right spot in between of „too much“ and „too  
> little“ and the original opscode-cookbooks concept was probably a „too  
> much“-problem and today it looks like we’re in a „too little“ situation.
> 
> why should community maintainers maintain a cookbook? - many. and i dont see  
> the different of this with ruby gem, or any userspace tool (pyhton egg, or a  
> debian in ppa). But the common reasons are: 1) you dont want to reinvent  
> wheel,. if theres no opensource cookbook on ossec, every time i join a place  
> it allows me rapidly roll out ossec cookboook. 2) my job depends on my  
> skills/knowledge, to get a better job, i need to improve my skill. but that  
> not possible if theres no one to mentor inside my own org. opensource brings  
> that possibility. again this is not specific to chef, its very opensource  
> thing, if you dont understand it, or dont know what value you get, dont do  
> it. but for those of us, who are outside chef, uses it, and loves it.  
> exposure is a huge thing, i cant become oracle reporting expert, but i can  
> become chef expert even if dont have much money.
> 
> Sorry, but that doesn’t answer my question. Many open source projects start,  
> when something (technology, framework) becomes „hot“. Everyone is trying to  
> learn and get a spot in the eco system. Popularity usually also means a  
> rising number of jobs, e.g. people can get their OSS contribution funded  
> and/or get an interesting job. However this strategy starts to collapse when  
> the crowd moves on to „even hotter“ things (typical hype lifecycle).
> 
> Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now  
> outdated npm modules -\> maintainer moved to Go.  
> Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> 
> This brain-drain affects not only the quantity but also the quality of  
> projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to  
> use it. Experience for new users will suffer.  
> Why should people contribute to $not\_hot\_anymore projects? I don’t see that  
> many unique chef-jobs, so having something in the GitHub repo/CV doesn’t  
> bring you new opportunities by itself.  
> Even a popular (\>200 stars on GH) knife plugin for some trending and cheap  
> cloud hosting provider brings you exactly 0 job/project offers (btdt).
> 
> possible options:
> 
> - provide minimal services that work out of the box by yourself (Chef, Inc)
> - subsidize community to maintain it (you pay, you decide how)
> - offer opportunities so people can benefit from supporting the community  
> (e.g. job site, contract projects, sales-partnerships with indies)  
> otoh: As far as I can see, most „Chef certified partners“ listed on  
> [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the community  
> and some companies that provide value to the community are not listed there  
> at all…
> 
> the last statement you made regarding namespace, is a technical problem.  
> again its no different here than any other place. for example redhat has  
> libvirt-lxc which everyone confuses with standard LXC but the project itself  
> has little code/feature compatibility with main LXC. The point is like  
> namespace is perceived, if you want you can publish a cookbook with samename  
> and if its really good (and assuming theres enough people who wants it) you  
> can definitely outweigh the other cookbook. if thats not happening, lets  
> address that.
> 
> Your libvirt-example is great, as it shows why nearly nobody used it and why  
> Docker has such a huge impact by just providing a fancy way to distribute  
> tar archives and wrap some syscalls 😉 (oversimplification intentional)  
> Redhat isn’t very good in community/relationship outside of their own  
> Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and  
> admins. I think better tutorials and community-relations would have  
> prevented that hatery/shitstorm against it.  
> When I talk to systemd-"haters", I ask them to write me a sysv-init script  
> for a service, then I show them the systemd unit representation.  
> When ansible users talk to me (chef user), they ask me to write a solution  
> that… whops. damn. You understand what I mean?
> 
> the definition of critical is very diverse, theres no common critical  
> component/cookbook. nothing. 0. as far as the whole community is concerned.  
> if you freeze platform (since chef run from windows machine to raspberry pi  
> to AIX to solaris) you might get a list of critical cookbooks (like sudo  
> will be for linux), you might get another layer on family (like sysdtemd on  
> ubuntu 15.04) .. we are in process of establishing the family specific  
> maintainers, a similar effort can be made for cookbooks as well.. but will  
> be mostly community and few core contributors .. similar to kernel and  
> userspace.. linus and linux foundation or redhat does not maintain ruby  
> specific rpm etc..
> 
> Why do people need DevOps? To have a reliable infrastructure to provide  
> services that make money and to stay competitive. Usually that involves more  
> or less custom applications based on common frameworks/stacks that need to  
> be deployed. So at least a couple of application deployment stacks are  
> critical to show the benefits of a DevOps solution. Even the [learn.chef.io](http://learn.chef.io)  
> tutorial falls apart, when you’re using the latest releases of cookbooks  
> used in the tutorial, so this is also a good definition of critical.
> 
> i am very interested in addressing this.. please keep your thoughts pouring  
> 🙂 , but understand we cant solve it in a click, its gonna take some time,  
> we have to keep talking, and out collaborative efforts on the next blockers  
> toward this direction.
> 
> fwiw i am the LT of chef on ubuntu, and i am working on a CD system that  
> will test actual community cookbooks on every master merge of chef. Which  
> will greatly reduce the maintenance burden, cause now core devs can also see  
> what affect the changeset has. Next step will be do a survey and get a list  
> of cookbooks and interested folks (brigade as we calling it) for ubuntu.  
> What i wonder is a common pool might not make sense, though Chef is cross  
> platform, majority of cookbook is not.
> 
> You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL 7,  
> Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something  
> like „it installs runit triggered by sysv-init — and it still works…“ on a  
> systemd distro 😉
> 
> regards  
> Roland
> 
> PS: Despite all my examples I’m not a systemd zealot. I was okay with  
> upstart… But a common base of various distros is a good thing for everyone  
> in the long run. And it’s also a good example for a game-changer and about  
> the agility/adoption capabilities of such things.
> 
> hth  
> ranjib
> 
> On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> 
> > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > 
> > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > 
> > > > To speak for Chef Software directly, we have always had people on staff  
> > > > whose role was assisting the creation and maintenance of cookbooks.  
> > > > That  
> > > > number has fluctuated up and down over time, with the skill sets of  
> > > > people  
> > > > we hire, and the normal day-to-day ebb and flow of trying to figure out  
> > > > how  
> > > > to build a business that is successful. We have people on staff today  
> > > > who do  
> > > > the same. What is clear is that the energy around cookbooks in the  
> > > > community  
> > > > is far greater than the energy we can muster as an organization  
> > > > (regardless  
> > > > of how much capital we do or do not have - y'all outnumber us) - and so  
> > > > our  
> > > > focus today is on trying to build and support the best community we  
> > > > can,  
> > > > through development of the supermarket, better tooling, and providing a  
> > > > few  
> > > > key examples of how best to build a community cookbook (see Sean's work  
> > > > on  
> > > > the httpd cookbook.)
> > > > 
> > > > Perhaps we need to organize a PR/merge festival brigade?
> > > 
> > > Hey Adam,
> > > 
> > > Would we consider transferring some of those cookbooks our of  
> > > {opscode,chef}-cookbooks to a community-organized org like  
> > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > > the preconditions to doing that?
> > > 
> > > Personally I would like the chef-brigade and redguide to be merged,  
> > > but I do not remember all the players involved -- if they are on this  
> > > list perhaps they can speak up.
> > 
> > How would this prevent the problems that happend with the last migration  
> > of former opscode-cookbooks to community maintainers?
> > 
> > Why should community maintainers care about the cookbooks in the future?  
> > It can be a time consuming burden and people need to pay their rent and do  
> > their regular jobs…
> > 
> > I know, this will be very provoking, but:
> > 
> > If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is  
> > there still a valid reason for running a public Supermarket site?  
> > If you go the "libertarian way" there is no reason for a supermarket site  
> > to protect/block names of cookbooks anymore that prevents users to pick  
> > other, maybe better community resources over legacy-cookbooks that are  
> > mentioned in guides and examples.
> > 
> > Either you (Chef, Inc.) control the market (e.g. maintain critical things  
> > yourself) or you should allow the free market (=community) to compete  
> > against each other based on equal opportunity (= namespaces or no  
> > supermarket). Everything else/in between will just end in chaos and anarchy.
> > 
> > regards  
> > Roland

---

<div class="post-metadata">

**Author:** ![Roland\_Moriz1](https://avatars.discourse-cdn.com/v4/letter/r/9fc29f/32.png) [@Roland\_Moriz1](https://discourse.chef.io/u/Roland_Moriz1)\
**Post date:** [June 25, 2015, 10:57am UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/8 "2015-06-25T10:57:40Z")

</div>

> Am 24.06.2015 um 17:33 schrieb Nathan Williams [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com):  
> i'd really like to see some official (maybe a BCP Chef RFC?) guidelines for quality based around the BCP guidelines... For example: evaluated with foodcritic and rubocop, integration tested with test-kitchen suites that cover the majority of recipe code-paths (e.g. source vs package install, etc.), unit tested with chefspec, and support for the relevant Chef-supported platforms ([https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md](https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md)).
> 
> if we then had some application process for Chef Inc to certify a cookbook as complying with the BCP, and we surfaced BCP-compliant cookbooks through Supermarket (with periodic review/recertification), I think we'd be most of the way to victory. This kind of surfacing would help deal with the naming conflict and abandoned cookbook issues we currently have to deal with (the systemd cookbook is a particularly egregious example of name-squatting), and would hopefully encourage community cookbook developers to put in extra effort, knowing that BCP compliance meant better visibility and more adoption.

Let's assume there would be a strong quality regime in place for community cookbooks. Chef, Inc. would actively need to code review and monitor everything except "write the code". I'm not sure if this can work and even make sense. It's like taking over the responsibility ("certified cookbook") without beeing able/willing to intervene when things get bad ("not certified anymore, but out of our scope to fix").

It's also not useful to just increase the pressure for open source developers if you want to keep and even increase the level of community contribution.

This, again, brings up my other concern: Why, at all, maintain a community cookbook?

The vast majority - as far as I can see - is maintained by single developers and/or a single company. The GH issues to PR ration is like 10:1, e.g. it's very time consuming to support, if you take issue reports seriously and also less useful because PR aren't happening frequently and are probably not that useful (If your shop uses Debian X, you just don't care about some PR for CentOS Y that much - and vice versa).

I can fully understand that most OSS cookbook developers don't have time for this, become inactive or just give up. They are getting paid for keeping their employer's (or their own) business up and scaling or don't get paid at all and do this entirely in their spare time.

Nobody can blame them!

Most business are too critical to entirely rely on voluntary time allocation by open source maintainers. If your business is serious, you'll compulsorily have to start in-house maintaining most of the cookbooks over time. Usually this also implies no further contribution back to the ecosystem/upstream/supermarket. [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks) (and OpsWorks in general) is a very good/bad example.

Best case is, that those "hidden" deployments will just stick with the chef patterns of 2010+, worst case they build things that should never ever be done in Chef and Ruby +that+ way… In almost every case, Chef (product) will then be blamed for the eventual desaster, not the team that was not able to adopt the best practices provided by the community and/or Chef, Inc..

best regards  
Roland

> anyways, that's my two cents.
> 
> regards,
> 
> nathan w
> 
> On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:  
> Hi,
> 
> > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > 
> > yes there is a lot of value with Chef inc, providing a public supermarket instance, it seeds community effort. You dont need it if you consume cookbooks from github or other sources (can be public, can be private/org specific).
> 
> I don’t think that it seeds community effort, because it’s often a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken, outdated or just be a no-op cookbook that reserves the name:
> 
> [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> 
> - number of downloads is irrelevant, as we all know
> - follower number is also not a good indication, because even after a year, supermarket did not get the traction of e.g. github
> - last release date is probably the best indicator. In my experience most cookbooks that are not updated within the last 12 months are outdated, e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> 
> Imagine a rather new chef user that needs to deal with systemd unit files. Just with that single „trap" he/she will probably lose a couple of hours or days or give up and pick something else with batteries included.
> 
> I’m sure this is not intentional and everyone had the best intentions doing it the current way - but IMHO it’s broken :-/  
> IMHO it’s all about hitting the right spot in between of „too much“ and „too little“ and the original opscode-cookbooks concept was probably a „too much“-problem and today it looks like we’re in a „too little“ situation.
> 
> > why should community maintainers maintain a cookbook? - many. and i dont see the different of this with ruby gem, or any userspace tool (pyhton egg, or a debian in ppa). But the common reasons are: 1) you dont want to reinvent wheel,. if theres no opensource cookbook on ossec, every time i join a place it allows me rapidly roll out ossec cookboook. 2) my job depends on my skills/knowledge, to get a better job, i need to improve my skill. but that not possible if theres no one to mentor inside my own org. opensource brings that possibility. again this is not specific to chef, its very opensource thing, if you dont understand it, or dont know what value you get, dont do it. but for those of us, who are outside chef, uses it, and loves it. exposure is a huge thing, i cant become oracle reporting expert, but i can become chef expert even if dont have much money.
> 
> Sorry, but that doesn’t answer my question. Many open source projects start, when something (technology, framework) becomes „hot“. Everyone is trying to learn and get a spot in the eco system. Popularity usually also means a rising number of jobs, e.g. people can get their OSS contribution funded and/or get an interesting job. However this strategy starts to collapse when the crowd moves on to „even hotter“ things (typical hype lifecycle).
> 
> Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now outdated npm modules -\> maintainer moved to Go.  
> Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> 
> This brain-drain affects not only the quantity but also the quality of projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to use it. Experience for new users will suffer.  
> Why should people contribute to $not\_hot\_anymore projects? I don’t see that many unique chef-jobs, so having something in the GitHub repo/CV doesn’t bring you new opportunities by itself.  
> Even a popular (\>200 stars on GH) knife plugin for some trending and cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).
> 
> possible options:
> 
> - provide minimal services that work out of the box by yourself (Chef, Inc)
> - subsidize community to maintain it (you pay, you decide how)
> - offer opportunities so people can benefit from supporting the community (e.g. job site, contract projects, sales-partnerships with indies)  
> otoh: As far as I can see, most „Chef certified partners“ listed on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the community and some companies that provide value to the community are not listed there at all…
> 
> > the last statement you made regarding namespace, is a technical problem. again its no different here than any other place. for example redhat has libvirt-lxc which everyone confuses with standard LXC but the project itself has little code/feature compatibility with main LXC. The point is like namespace is perceived, if you want you can publish a cookbook with samename and if its really good (and assuming theres enough people who wants it) you can definitely outweigh the other cookbook. if thats not happening, lets address that.
> 
> Your libvirt-example is great, as it shows why nearly nobody used it and why Docker has such a huge impact by just providing a fancy way to distribute tar archives and wrap some syscalls 😉 (oversimplification intentional)  
> Redhat isn’t very good in community/relationship outside of their own Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and admins. I think better tutorials and community-relations would have prevented that hatery/shitstorm against it.  
> When I talk to systemd-"haters", I ask them to write me a sysv-init script for a service, then I show them the systemd unit representation.  
> When ansible users talk to me (chef user), they ask me to write a solution that… whops. damn. You understand what I mean?
> 
> > the definition of critical is very diverse, theres no common critical component/cookbook. nothing. 0. as far as the whole community is concerned. if you freeze platform (since chef run from windows machine to raspberry pi to AIX to solaris) you might get a list of critical cookbooks (like sudo will be for linux), you might get another layer on family (like sysdtemd on ubuntu 15.04) .. we are in process of establishing the family specific maintainers, a similar effort can be made for cookbooks as well.. but will be mostly community and few core contributors .. similar to kernel and userspace.. linus and linux foundation or redhat does not maintain ruby specific rpm etc..
> 
> Why do people need DevOps? To have a reliable infrastructure to provide services that make money and to stay competitive. Usually that involves more or less custom applications based on common frameworks/stacks that need to be deployed. So at least a couple of application deployment stacks are critical to show the benefits of a DevOps solution. Even the [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest releases of cookbooks used in the tutorial, so this is also a good definition of critical.
> 
> > i am very interested in addressing this.. please keep your thoughts pouring 🙂 , but understand we cant solve it in a click, its gonna take some time, we have to keep talking, and out collaborative efforts on the next blockers toward this direction.
> 
> > fwiw i am the LT of chef on ubuntu, and i am working on a CD system that will test actual community cookbooks on every master merge of chef. Which will greatly reduce the maintenance burden, cause now core devs can also see what affect the changeset has. Next step will be do a survey and get a list of cookbooks and interested folks (brigade as we calling it) for ubuntu. What i wonder is a common pool might not make sense, though Chef is cross platform, majority of cookbook is not.
> 
> You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something like „it installs runit triggered by sysv-init — and it still works…“ on a systemd distro 😉
> 
> regards  
> Roland
> 
> PS: Despite all my examples I’m not a systemd zealot. I was okay with upstart… But a common base of various distros is a good thing for everyone in the long run. And it’s also a good example for a game-changer and about the agility/adoption capabilities of such things.
> 
> > hth  
> > ranjib
> > 
> > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> > 
> > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > 
> > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > 
> > > > To speak for Chef Software directly, we have always had people on staff  
> > > > whose role was assisting the creation and maintenance of cookbooks. That  
> > > > number has fluctuated up and down over time, with the skill sets of people  
> > > > we hire, and the normal day-to-day ebb and flow of trying to figure out how  
> > > > to build a business that is successful. We have people on staff today who do  
> > > > the same. What is clear is that the energy around cookbooks in the community  
> > > > is far greater than the energy we can muster as an organization (regardless  
> > > > of how much capital we do or do not have - y'all outnumber us) - and so our  
> > > > focus today is on trying to build and support the best community we can,  
> > > > through development of the supermarket, better tooling, and providing a few  
> > > > key examples of how best to build a community cookbook (see Sean's work on  
> > > > the httpd cookbook.)
> > > > 
> > > > Perhaps we need to organize a PR/merge festival brigade?
> > > 
> > > Hey Adam,
> > > 
> > > Would we consider transferring some of those cookbooks our of  
> > > {opscode,chef}-cookbooks to a community-organized org like  
> > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > > the preconditions to doing that?
> > > 
> > > Personally I would like the chef-brigade and redguide to be merged,  
> > > but I do not remember all the players involved -- if they are on this  
> > > list perhaps they can speak up.
> > 
> > How would this prevent the problems that happend with the last migration of former opscode-cookbooks to community maintainers?
> > 
> > Why should community maintainers care about the cookbooks in the future?  
> > It can be a time consuming burden and people need to pay their rent and do their regular jobs…
> > 
> > I know, this will be very provoking, but:
> > 
> > If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is there still a valid reason for running a public Supermarket site?  
> > If you go the "libertarian way" there is no reason for a supermarket site to protect/block names of cookbooks anymore that prevents users to pick other, maybe better community resources over legacy-cookbooks that are mentioned in guides and examples.
> > 
> > Either you (Chef, Inc.) control the market (e.g. maintain critical things yourself) or you should allow the free market (=community) to compete against each other based on equal opportunity (= namespaces or no supermarket). Everything else/in between will just end in chaos and anarchy.
> > 
> > regards  
> > Roland

---

<div class="post-metadata">

**Author:** ![nathwill](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/nathwill/32/25_2.png) [@nathwill](https://discourse.chef.io/u/nathwill)\
**Post date:** [June 25, 2015, 4:05pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/9 "2015-06-25T16:05:13Z")

</div>

On Thu, 2015-06-25 at 12:57 +0200, Roland Moriz wrote:

> > Am 24.06.2015 um 17:33 schrieb Nathan Williams \<  
> > [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com)\>:  
> > i'd really like to see some official (maybe a BCP Chef RFC?)  
> > guidelines for quality based around the BCP guidelines... For  
> > example: evaluated with foodcritic and rubocop, integration tested  
> > with test-kitchen suites that cover the majority of recipe code  
> > -paths (e.g. source vs package install, etc.), unit tested with  
> > chefspec, and support for the relevant Chef-supported platforms (ht  
> > tps://github.com/chef/chef-rfc/blob/master/rfc021-platform-support  
> > -policy.md).
> > 
> > if we then had some application process for Chef Inc to certify a  
> > cookbook as complying with the BCP, and we surfaced BCP-compliant  
> > cookbooks through Supermarket (with periodic  
> > review/recertification), I think we'd be most of the way to  
> > victory. This kind of surfacing would help deal with the naming  
> > conflict and abandoned cookbook issues we currently have to deal  
> > with (the systemd cookbook is a particularly egregious example of  
> > name-squatting), and would hopefully encourage community cookbook  
> > developers to put in extra effort, knowing that BCP compliance  
> > meant better visibility and more adoption.
> 
> Let's assume there would be a strong quality regime in place for  
> community cookbooks. Chef, Inc. would actively need to code review  
> and monitor everything except "write the code". I'm not sure if this  
> can work and even make sense. It's like taking over the  
> responsibility ("certified cookbook") without beeing able/willing to  
> intervene when things get bad ("not certified anymore, but out of our  
> scope to fix").

Yeah, definitely some potential pitfalls, but cookbooks are already  
linted with foodcritic on upload to the supermarket, and I'm sure there  
exist lots of other ways to pre-screen or delegate to community efforts  
like chef-brigade/redguide to lower the review burden. And yeah,  
denying/revoking certification would be where the scope ends; I don't  
see that as a bad thing, the sole objective of certification would be  
to make it easier to find the high-quality cookbooks in a world where  
the one with the simplest/most obvious name may've just been first out  
of the gate.

> It's also not useful to just increase the pressure for open source  
> developers if you want to keep and even increase the level of  
> community contribution.

i don't think that's pressure, just incentive, though i can see how  
some might view it that way.

> This, again, brings up my other concern: Why, at all, maintain a  
> community cookbook?
> 
> The vast majority - as far as I can see - is maintained by single  
> developers and/or a single company. The GH issues to PR ration is  
> like 10:1, e.g. it's very time consuming to support, if you take  
> issue reports seriously and also less useful because PR aren't  
> happening frequently and are probably not that useful (If your shop  
> uses Debian X, you just don't care about some PR for CentOS Y that  
> much - and vice versa).
> 
> I can fully understand that most OSS cookbook developers don't have  
> time for this, become inactive or just give up. They are getting paid  
> for keeping their employer's (or their own) business up and scaling  
> or don't get paid at all and do this entirely in their spare time.
> 
> Nobody can blame them!
> 
> Most business are too critical to entirely rely on voluntary time  
> allocation by open source maintainers. If your business is serious,  
> you'll compulsorily have to start in-house maintaining most of the  
> cookbooks over time. Usually this also implies no further  
> contribution back to the ecosystem/upstream/supermarket.  
> [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks) (and OpsWorks in general)  
> is a very good/bad example.

None of this is chef specific; it seems more like you're questioning  
the open-source development model, which IMO is doing just fine.

just to speak for myself, there's no way we, at $current\_job would have  
been able to accomplish as much as we have over the last year without  
community cookbooks to help us get up and running. there've been a few  
instances where the available community cookbooks didn't fit our needs,  
and the differences were vast enough that a PR wasn't a reasonable  
solution, but we're not that special, so those new cookbooks got open  
-sourced too. for the majority, especially the more common components,  
we've been able to benefit from steady, sustained improvement without  
any investment aside from the time it takes to update our version  
pinning and fix (mostly) minor breakages in our wrappers.

as for the cookbooks i've released, it's been well worth the time spent  
maintaining to get the benefit of other people's opinions in the form  
of issues and PRs, which help to improve things with pretty minimal  
effort on my part. plus, people in this community are awesome, and it's  
fun to engage with folks and find out how they're using something.

> Best case is, that those "hidden" deployments will just stick with  
> the chef patterns of 2010+, worst case they build things that should  
> never ever be done in Chef and Ruby +that+ way… In almost every  
> case, Chef (product) will then be blamed for the eventual desaster,  
> not the team that was not able to adopt the best practices provided  
> by the community and/or Chef, Inc..

i don't think this is true at all. one would have to be pretty out of  
touch to fail to distinguish between core product and product  
extensions, or company & community. if someone makes that mistake and  
either leaves without seeking help (and having said misconception  
subsequently corrected), or has enough sense of entitlement to be so  
demanding, good riddance.

regards,

nathan w

> best regards  
> Roland
> 
> > anyways, that's my two cents.
> > 
> > regards,
> > 
> > nathan w
> > 
> > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > wrote:  
> > Hi,
> > 
> > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > > 
> > > yes there is a lot of value with Chef inc, providing a public  
> > > supermarket instance, it seeds community effort. You dont need it  
> > > if you consume cookbooks from github or other sources (can be  
> > > public, can be private/org specific).
> > 
> > I don’t think that it seeds community effort, because it’s often a  
> > „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be  
> > broken, outdated or just be a no-op cookbook that reserves the  
> > name:
> > 
> > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&plat](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&plat)  
> > forms%5B%5D=
> > 
> > - number of downloads is irrelevant, as we all know
> > - follower number is also not a good indication, because even after  
> > a year, supermarket did not get the traction of e.g. github
> > - last release date is probably the best indicator. In my  
> > experience most cookbooks that are not updated within the last 12  
> > months are outdated, e.g. won’t work with the recent distros like  
> > Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> > 
> > Imagine a rather new chef user that needs to deal with systemd unit  
> > files. Just with that single „trap" he/she will probably lose a  
> > couple of hours or days or give up and pick something else with  
> > batteries included.
> > 
> > I’m sure this is not intentional and everyone had the best  
> > intentions doing it the current way - but IMHO it’s broken :-/  
> > IMHO it’s all about hitting the right spot in between of „too much“  
> > and „too little“ and the original opscode-cookbooks concept was  
> > probably a „too much“-problem and today it looks like we’re in a  
> > „too little“ situation.
> > 
> > > why should community maintainers maintain a cookbook? - many. and  
> > > i dont see the different of this with ruby gem, or any userspace  
> > > tool (pyhton egg, or a debian in ppa). But the common reasons  
> > > are: 1) you dont want to reinvent wheel,. if theres no opensource  
> > > cookbook on ossec, every time i join a place it allows me rapidly  
> > > roll out ossec cookboook. 2) my job depends on my  
> > > skills/knowledge, to get a better job, i need to improve my  
> > > skill. but that not possible if theres no one to mentor inside my  
> > > own org. opensource brings that possibility. again this is not  
> > > specific to chef, its very opensource thing, if you dont  
> > > understand it, or dont know what value you get, dont do it. but  
> > > for those of us, who are outside chef, uses it, and loves it.  
> > > exposure is a huge thing, i cant become oracle reporting expert,  
> > > but i can become chef expert even if dont have much money.
> > 
> > Sorry, but that doesn’t answer my question. Many open source  
> > projects start, when something (technology, framework) becomes  
> > „hot“. Everyone is trying to learn and get a spot in the eco  
> > system. Popularity usually also means a rising number of jobs, e.g.  
> > people can get their OSS contribution funded and/or get an  
> > interesting job. However this strategy starts to collapse when the  
> > crowd moves on to „even hotter“ things (typical hype lifecycle).
> > 
> > Example 1: now outdated Ruby gems -\> maintainer moved to node -\>  
> > now outdated npm modules -\> maintainer moved to Go.  
> > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > 
> > This brain-drain affects not only the quantity but also the quality  
> > of projects. Less „eyes“ to find bugs, less „hands“ to fix them,  
> > less users to use it. Experience for new users will suffer.  
> > Why should people contribute to $not\_hot\_anymore projects? I don’t  
> > see that many unique chef-jobs, so having something in the GitHub  
> > repo/CV doesn’t bring you new opportunities by itself.  
> > Even a popular (\>200 stars on GH) knife plugin for some trending  
> > and cheap cloud hosting provider brings you exactly 0 job/project  
> > offers (btdt).
> > 
> > possible options:
> > 
> > - provide minimal services that work out of the box by yourself  
> > (Chef, Inc)
> > - subsidize community to maintain it (you pay, you decide how)
> > - offer opportunities so people can benefit from supporting the  
> > community (e.g. job site, contract projects, sales-partnerships  
> > with indies)  
> > otoh: As far as I can see, most „Chef certified partners“ listed  
> > on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of  
> > the community and some companies that provide value to the  
> > community are not listed there at all…
> > 
> > > the last statement you made regarding namespace, is a technical  
> > > problem. again its no different here than any other place. for  
> > > example redhat has libvirt-lxc which everyone confuses with  
> > > standard LXC but the project itself has little code/feature  
> > > compatibility with main LXC. The point is like namespace is  
> > > perceived, if you want you can publish a cookbook with samename  
> > > and if its really good (and assuming theres enough people who  
> > > wants it) you can definitely outweigh the other cookbook. if  
> > > thats not happening, lets address that.
> > 
> > Your libvirt-example is great, as it shows why nearly nobody used  
> > it and why Docker has such a huge impact by just providing a fancy  
> > way to distribute tar archives and wrap some syscalls 😉  
> > (oversimplification intentional)  
> > Redhat isn’t very good in community/relationship outside of their  
> > own Fedora/RHEL area. Just see how they „sell“ systemd to users,  
> > developers and admins. I think better tutorials and community  
> > -relations would have prevented that hatery/shitstorm against it.  
> > When I talk to systemd-"haters", I ask them to write me a sysv-init  
> > script for a service, then I show them the systemd unit  
> > representation.  
> > When ansible users talk to me (chef user), they ask me to write a  
> > solution that… whops. damn. You understand what I mean?
> > 
> > > the definition of critical is very diverse, theres no common  
> > > critical component/cookbook. nothing. 0. as far as the whole  
> > > community is concerned. if you freeze platform (since chef run  
> > > from windows machine to raspberry pi to AIX to solaris) you might  
> > > get a list of critical cookbooks (like sudo will be for linux),  
> > > you might get another layer on family (like sysdtemd on ubuntu  
> > > 15.04) .. we are in process of establishing the family specific  
> > > maintainers, a similar effort can be made for cookbooks as well..  
> > > but will be mostly community and few core contributors .. similar  
> > > to kernel and userspace.. linus and linux foundation or redhat  
> > > does not maintain ruby specific rpm etc..
> > 
> > Why do people need DevOps? To have a reliable infrastructure to  
> > provide services that make money and to stay competitive. Usually  
> > that involves more or less custom applications based on common  
> > frameworks/stacks that need to be deployed. So at least a couple of  
> > application deployment stacks are critical to show the benefits of  
> > a DevOps solution. Even the [learn.chef.io](http://learn.chef.io) tutorial falls apart,  
> > when you’re using the latest releases of cookbooks used in the  
> > tutorial, so this is also a good definition of critical.
> > 
> > > i am very interested in addressing this.. please keep your  
> > > thoughts pouring 🙂 , but understand we cant solve it in a  
> > > click, its gonna take some time, we have to keep talking, and out  
> > > collaborative efforts on the next blockers toward this direction.
> > 
> > > fwiw i am the LT of chef on ubuntu, and i am working on a CD  
> > > system that will test actual community cookbooks on every master  
> > > merge of chef. Which will greatly reduce the maintenance burden,  
> > > cause now core devs can also see what affect the changeset has.  
> > > Next step will be do a survey and get a list of cookbooks and  
> > > interested folks (brigade as we calling it) for ubuntu. What i  
> > > wonder is a common pool might not make sense, though Chef is  
> > > cross platform, majority of cookbook is not.
> > 
> > You don’t need a fancy distro/edge-case. Just make sure Debian 8,  
> > RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t  
> > mean something like „it installs runit triggered by sysv-init — and  
> > it still works…“ on a systemd distro 😉
> > 
> > regards  
> > Roland
> > 
> > PS: Despite all my examples I’m not a systemd zealot. I was okay  
> > with upstart… But a common base of various distros is a good thing  
> > for everyone in the long run. And it’s also a good example for a  
> > game-changer and about the agility/adoption capabilities of such  
> > things.
> > 
> > > hth  
> > > ranjib
> > > 
> > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > wrote:
> > > 
> > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn \<  
> > > > [jdunn@aquezada.com](mailto:jdunn@aquezada.com)\>:
> > > > 
> > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io)  
> > > > wrote:
> > > > 
> > > > > To speak for Chef Software directly, we have always had  
> > > > > people on staff  
> > > > > whose role was assisting the creation and maintenance of  
> > > > > cookbooks. That  
> > > > > number has fluctuated up and down over time, with the skill  
> > > > > sets of people  
> > > > > we hire, and the normal day-to-day ebb and flow of trying to  
> > > > > figure out how  
> > > > > to build a business that is successful. We have people on  
> > > > > staff today who do  
> > > > > the same. What is clear is that the energy around cookbooks  
> > > > > in the community  
> > > > > is far greater than the energy we can muster as an  
> > > > > organization (regardless  
> > > > > of how much capital we do or do not have - y'all outnumber  
> > > > > us) - and so our  
> > > > > focus today is on trying to build and support the best  
> > > > > community we can,  
> > > > > through development of the supermarket, better tooling, and  
> > > > > providing a few  
> > > > > key examples of how best to build a community cookbook (see  
> > > > > Sean's work on  
> > > > > the httpd cookbook.)
> > > > > 
> > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > 
> > > > Hey Adam,
> > > > 
> > > > Would we consider transferring some of those cookbooks our of  
> > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What  
> > > > would be  
> > > > the preconditions to doing that?
> > > > 
> > > > Personally I would like the chef-brigade and redguide to be  
> > > > merged,  
> > > > but I do not remember all the players involved -- if they are  
> > > > on this  
> > > > list perhaps they can speak up.
> > > 
> > > How would this prevent the problems that happend with the last  
> > > migration of former opscode-cookbooks to community maintainers?
> > > 
> > > Why should community maintainers care about the cookbooks in the  
> > > future?  
> > > It can be a time consuming burden and people need to pay their  
> > > rent and do their regular jobs…
> > > 
> > > I know, this will be very provoking, but:
> > > 
> > > If Chef, inc. doesn't want to maintain even critical cookbooks  
> > > anymore, is there still a valid reason for running a public  
> > > Supermarket site?  
> > > If you go the "libertarian way" there is no reason for a  
> > > supermarket site to protect/block names of cookbooks anymore that  
> > > prevents users to pick other, maybe better community resources  
> > > over legacy-cookbooks that are mentioned in guides and examples.
> > > 
> > > Either you (Chef, Inc.) control the market (e.g. maintain  
> > > critical things yourself) or you should allow the free market  
> > > (=community) to compete against each other based on equal  
> > > opportunity (= namespaces or no supermarket). Everything else/in  
> > > between will just end in chaos and anarchy.
> > > 
> > > regards  
> > > Roland

---

<div class="post-metadata">

**Author:** ![Yoshi\_Spendiff](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/yoshi_spendiff/32/13_2.png) [@Yoshi\_Spendiff](https://discourse.chef.io/u/Yoshi_Spendiff)\
**Post date:** [June 25, 2015, 4:11pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/10 "2015-06-25T16:11:23Z")

</div>

An official certification is probably too much to handle but there could be  
value in stating guidelines that demonstrate how a reliable cookbook is  
designed and tested. I know Chef doesn't like to prescribe but for the sake  
of quality a recommended path for some things might be a good idea.

The reason to maintain a community cookbook is usually because it's  
relevant to your business/job, which is obviously why cookbooks fall out of  
repair and only have certain coverage.

If business 1 makes a cookbook for platform X only and business 2 wants to  
do the same for platform Y then their options are:

1. Make a new cookbook for platform X
2. Fork
3. Work on a pull request  
Having good methods for business 2 to contact business 1 and state their  
intention could lead to productive collaboration and implementing better  
ways to find contributors and reviewers of cookbooks could be a good way to  
help out with this, whether it's business to business or just individual  
contributors.

It would also be useful for there to be a mechanism where ownership of  
stale cookbooks can be transferred, especially now there are groups that  
are willing to maintain them.

Finally, better sorting and maybe a rating system on the supermarket for  
cookbooks would be good. If a cookbook starts out excellent but isn't  
maintained then many lower reviews will start to drag down the rating.

On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:

> > Am 24.06.2015 um 17:33 schrieb Nathan Williams [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com):  
> > i'd really like to see some official (maybe a BCP Chef RFC?) guidelines  
> > for quality based around the BCP guidelines... For example: evaluated with  
> > foodcritic and rubocop, integration tested with test-kitchen suites that  
> > cover the majority of recipe code-paths (e.g. source vs package install,  
> > etc.), unit tested with chefspec, and support for the relevant  
> > Chef-supported platforms (  
> > [https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md](https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md)  
> > ).
> > 
> > if we then had some application process for Chef Inc to certify a  
> > cookbook as complying with the BCP, and we surfaced BCP-compliant cookbooks  
> > through Supermarket (with periodic review/recertification), I think we'd be  
> > most of the way to victory. This kind of surfacing would help deal with the  
> > naming conflict and abandoned cookbook issues we currently have to deal  
> > with (the systemd cookbook is a particularly egregious example of  
> > name-squatting), and would hopefully encourage community cookbook  
> > developers to put in extra effort, knowing that BCP compliance meant better  
> > visibility and more adoption.
> 
> Let's assume there would be a strong quality regime in place for community  
> cookbooks. Chef, Inc. would actively need to code review and monitor  
> everything except "write the code". I'm not sure if this can work and even  
> make sense. It's like taking over the responsibility ("certified cookbook")  
> without beeing able/willing to intervene when things get bad ("not  
> certified anymore, but out of our scope to fix").
> 
> It's also not useful to just increase the pressure for open source  
> developers if you want to keep and even increase the level of community  
> contribution.
> 
> This, again, brings up my other concern: Why, at all, maintain a community  
> cookbook?
> 
> The vast majority - as far as I can see - is maintained by single  
> developers and/or a single company. The GH issues to PR ration is like  
> 10:1, e.g. it's very time consuming to support, if you take issue reports  
> seriously and also less useful because PR aren't happening frequently and  
> are probably not that useful (If your shop uses Debian X, you just don't  
> care about some PR for CentOS Y that much - and vice versa).
> 
> I can fully understand that most OSS cookbook developers don't have time  
> for this, become inactive or just give up. They are getting paid for  
> keeping their employer's (or their own) business up and scaling or don't  
> get paid at all and do this entirely in their spare time.
> 
> Nobody can blame them!
> 
> Most business are too critical to entirely rely on voluntary time  
> allocation by open source maintainers. If your business is serious, you'll  
> compulsorily have to start in-house maintaining most of the cookbooks over  
> time. Usually this also implies no further contribution back to the  
> ecosystem/upstream/supermarket. [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks)  
> (and OpsWorks in general) is a very good/bad example.
> 
> Best case is, that those "hidden" deployments will just stick with the  
> chef patterns of 2010+, worst case they build things that should never ever  
> be done in Chef and Ruby +that+ way… In almost every case, Chef (product)  
> will then be blamed for the eventual desaster, not the team that was not  
> able to adopt the best practices provided by the community and/or Chef,  
> Inc..
> 
> best regards  
> Roland
> 
> > anyways, that's my two cents.
> > 
> > regards,
> > 
> > nathan w
> > 
> > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:  
> > Hi,
> > 
> > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > > 
> > > yes there is a lot of value with Chef inc, providing a public  
> > > supermarket instance, it seeds community effort. You dont need it if you  
> > > consume cookbooks from github or other sources (can be public, can be  
> > > private/org specific).
> > 
> > I don’t think that it seeds community effort, because it’s often a  
> > „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken,  
> > outdated or just be a no-op cookbook that reserves the name:
> 
> [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> 
> > - number of downloads is irrelevant, as we all know
> > - follower number is also not a good indication, because even after a  
> > year, supermarket did not get the traction of e.g. github
> > - last release date is probably the best indicator. In my experience  
> > most cookbooks that are not updated within the last 12 months are outdated,  
> > e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How  
> > should starters „know“ this?
> > 
> > Imagine a rather new chef user that needs to deal with systemd unit  
> > files. Just with that single „trap" he/she will probably lose a couple of  
> > hours or days or give up and pick something else with batteries included.
> > 
> > I’m sure this is not intentional and everyone had the best intentions  
> > doing it the current way - but IMHO it’s broken :-/  
> > IMHO it’s all about hitting the right spot in between of „too much“ and  
> > „too little“ and the original opscode-cookbooks concept was probably a „too  
> > much“-problem and today it looks like we’re in a „too little“ situation.
> > 
> > > why should community maintainers maintain a cookbook? - many. and i  
> > > dont see the different of this with ruby gem, or any userspace tool (pyhton  
> > > egg, or a debian in ppa). But the common reasons are: 1) you dont want to  
> > > reinvent wheel,. if theres no opensource cookbook on ossec, every time i  
> > > join a place it allows me rapidly roll out ossec cookboook. 2) my job  
> > > depends on my skills/knowledge, to get a better job, i need to improve my  
> > > skill. but that not possible if theres no one to mentor inside my own org.  
> > > opensource brings that possibility. again this is not specific to chef, its  
> > > very opensource thing, if you dont understand it, or dont know what value  
> > > you get, dont do it. but for those of us, who are outside chef, uses it,  
> > > and loves it. exposure is a huge thing, i cant become oracle reporting  
> > > expert, but i can become chef expert even if dont have much money.
> > 
> > Sorry, but that doesn’t answer my question. Many open source projects  
> > start, when something (technology, framework) becomes „hot“. Everyone is  
> > trying to learn and get a spot in the eco system. Popularity usually also  
> > means a rising number of jobs, e.g. people can get their OSS contribution  
> > funded and/or get an interesting job. However this strategy starts to  
> > collapse when the crowd moves on to „even hotter“ things (typical hype  
> > lifecycle).
> > 
> > Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now  
> > outdated npm modules -\> maintainer moved to Go.  
> > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > 
> > This brain-drain affects not only the quantity but also the quality of  
> > projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to  
> > use it. Experience for new users will suffer.  
> > Why should people contribute to $not\_hot\_anymore projects? I don’t see  
> > that many unique chef-jobs, so having something in the GitHub repo/CV  
> > doesn’t bring you new opportunities by itself.  
> > Even a popular (\>200 stars on GH) knife plugin for some trending and  
> > cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).
> > 
> > possible options:
> > 
> > - provide minimal services that work out of the box by yourself (Chef,  
> > Inc)
> > - subsidize community to maintain it (you pay, you decide how)
> > - offer opportunities so people can benefit from supporting the  
> > community (e.g. job site, contract projects, sales-partnerships with indies)  
> > otoh: As far as I can see, most „Chef certified partners“ listed on  
> > [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the  
> > community and some companies that provide value to the community are not  
> > listed there at all…
> > 
> > > the last statement you made regarding namespace, is a technical  
> > > problem. again its no different here than any other place. for example  
> > > redhat has libvirt-lxc which everyone confuses with standard LXC but the  
> > > project itself has little code/feature compatibility with main LXC. The  
> > > point is like namespace is perceived, if you want you can publish a  
> > > cookbook with samename and if its really good (and assuming theres enough  
> > > people who wants it) you can definitely outweigh the other cookbook. if  
> > > thats not happening, lets address that.
> > 
> > Your libvirt-example is great, as it shows why nearly nobody used it and  
> > why Docker has such a huge impact by just providing a fancy way to  
> > distribute tar archives and wrap some syscalls 😉 (oversimplification  
> > intentional)  
> > Redhat isn’t very good in community/relationship outside of their own  
> > Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and  
> > admins. I think better tutorials and community-relations would have  
> > prevented that hatery/shitstorm against it.  
> > When I talk to systemd-"haters", I ask them to write me a sysv-init  
> > script for a service, then I show them the systemd unit representation.  
> > When ansible users talk to me (chef user), they ask me to write a  
> > solution that… whops. damn. You understand what I mean?
> > 
> > > the definition of critical is very diverse, theres no common critical  
> > > component/cookbook. nothing. 0. as far as the whole community is concerned.  
> > > if you freeze platform (since chef run from windows machine to raspberry  
> > > pi to AIX to solaris) you might get a list of critical cookbooks (like sudo  
> > > will be for linux), you might get another layer on family (like sysdtemd on  
> > > ubuntu 15.04) .. we are in process of establishing the family specific  
> > > maintainers, a similar effort can be made for cookbooks as well.. but will  
> > > be mostly community and few core contributors .. similar to kernel and  
> > > userspace.. linus and linux foundation or redhat does not maintain ruby  
> > > specific rpm etc..
> > 
> > Why do people need DevOps? To have a reliable infrastructure to provide  
> > services that make money and to stay competitive. Usually that involves  
> > more or less custom applications based on common frameworks/stacks that  
> > need to be deployed. So at least a couple of application deployment stacks  
> > are critical to show the benefits of a DevOps solution. Even the  
> > [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest releases  
> > of cookbooks used in the tutorial, so this is also a good definition of  
> > critical.
> > 
> > > i am very interested in addressing this.. please keep your thoughts  
> > > pouring 🙂 , but understand we cant solve it in a click, its gonna take  
> > > some time, we have to keep talking, and out collaborative efforts on the  
> > > next blockers toward this direction.
> > 
> > > fwiw i am the LT of chef on ubuntu, and i am working on a CD system  
> > > that will test actual community cookbooks on every master merge of chef.  
> > > Which will greatly reduce the maintenance burden, cause now core devs can  
> > > also see what affect the changeset has. Next step will be do a survey and  
> > > get a list of cookbooks and interested folks (brigade as we calling it) for  
> > > ubuntu. What i wonder is a common pool might not make sense, though Chef is  
> > > cross platform, majority of cookbook is not.
> > 
> > You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL  
> > 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something  
> > like „it installs runit triggered by sysv-init — and it still works…“ on a  
> > systemd distro 😉
> > 
> > regards  
> > Roland
> > 
> > PS: Despite all my examples I’m not a systemd zealot. I was okay with  
> > upstart… But a common base of various distros is a good thing for everyone  
> > in the long run. And it’s also a good example for a game-changer and about  
> > the agility/adoption capabilities of such things.
> > 
> > > hth  
> > > ranjib
> > > 
> > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> > > 
> > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > > 
> > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > > 
> > > > > To speak for Chef Software directly, we have always had people on  
> > > > > staff  
> > > > > whose role was assisting the creation and maintenance of cookbooks.  
> > > > > That  
> > > > > number has fluctuated up and down over time, with the skill sets of  
> > > > > people  
> > > > > we hire, and the normal day-to-day ebb and flow of trying to figure  
> > > > > out how  
> > > > > to build a business that is successful. We have people on staff  
> > > > > today who do  
> > > > > the same. What is clear is that the energy around cookbooks in the  
> > > > > community  
> > > > > is far greater than the energy we can muster as an organization  
> > > > > (regardless  
> > > > > of how much capital we do or do not have - y'all outnumber us) - and  
> > > > > so our  
> > > > > focus today is on trying to build and support the best community we  
> > > > > can,  
> > > > > through development of the supermarket, better tooling, and  
> > > > > providing a few  
> > > > > key examples of how best to build a community cookbook (see Sean's  
> > > > > work on  
> > > > > the httpd cookbook.)
> > > > > 
> > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > 
> > > > Hey Adam,
> > > > 
> > > > Would we consider transferring some of those cookbooks our of  
> > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > > > the preconditions to doing that?
> > > > 
> > > > Personally I would like the chef-brigade and redguide to be merged,  
> > > > but I do not remember all the players involved -- if they are on this  
> > > > list perhaps they can speak up.
> > > 
> > > How would this prevent the problems that happend with the last  
> > > migration of former opscode-cookbooks to community maintainers?
> > > 
> > > Why should community maintainers care about the cookbooks in the future?  
> > > It can be a time consuming burden and people need to pay their rent and  
> > > do their regular jobs…
> > > 
> > > I know, this will be very provoking, but:
> > > 
> > > If Chef, inc. doesn't want to maintain even critical cookbooks anymore,  
> > > is there still a valid reason for running a public Supermarket site?  
> > > If you go the "libertarian way" there is no reason for a supermarket  
> > > site to protect/block names of cookbooks anymore that prevents users to  
> > > pick other, maybe better community resources over legacy-cookbooks that are  
> > > mentioned in guides and examples.
> > > 
> > > Either you (Chef, Inc.) control the market (e.g. maintain critical  
> > > things yourself) or you should allow the free market (=community) to  
> > > compete against each other based on equal opportunity (= namespaces or no  
> > > supermarket). Everything else/in between will just end in chaos and anarchy.
> > > 
> > > regards  
> > > Roland

--  
Yoshi Spendiff  
Ops Engineer  
Indochino  
Mobile: +1 778 952 2025  
Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [June 25, 2015, 4:24pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/11 "2015-06-25T16:24:34Z")

</div>

I like the suggestion Nathan proposed, i.e. that we have some kind of  
objective measure of quality for cookbooks.

Probably repeating, but that's what I'm thinking might possibly go into  
such a "quality score" and should be prominently exposed in the supermarket:

- having foodcritic, chefspec and kitchenci in place at all  
​

- number of supported platform as in metadata vs kitchen tested platforms  
​- build information (including kitchenci!) publicly available​

- 

​​  
number of tests run and code coverage per platform

- ratio of open vs. closed github issues
- mean time to response for github issues / pull requests (that might be a  
hard one ;-))

Having that visibility / transparency in supermarket would probably make  
the judgment about quality easi  
​er ​  
and be only the first step.​

​The harder part is getting quality in. Sean did a great example with the  
httpd cookbook, but as Roland said, for most community maintainers the  
reality is probably "  
If your shop uses Debian X, you just don't care about some PR for CentOS Y  
that much  
​".

I don't​ really know how to solve this, just these two ideas (also already  
mentioned, probably):  
​

1. I could imagine that b  
ounty programs  
​ could be effective ​  
​, especially if  
they offer some kind of monetary rewards (or free confernece tickets etc)  
for working on community cookbooks  
​ (which is a free time / spare time affair for quite a few of us, I guess)

2. a sponsored build system for community cookbooks would probably help,  
too. Most commity cookbooks have their kitchenci builds not running /  
publicly visible, but this is essential from a maintainer's perspective  
(think of kitchenci builds for pull requests). Personally I'm using  
CircleCI free tier, which lets you run kitchenci suites with the docker  
provider and up to 4x parallelism, but eventually that's not enough if you  
support a whole number of platforms \* test suites​

​Cheers,  
Torben​​

Am 25.06.2015 12:57 schrieb "Roland Moriz" [rmoriz@gmail.com](mailto:rmoriz@gmail.com):

> > Am 24.06.2015 um 17:33 schrieb Nathan Williams [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com):  
> > i'd really like to see some official (maybe a BCP Chef RFC?) guidelines  
> > for quality based around the BCP guidelines... For example: evaluated with  
> > foodcritic and rubocop, integration tested with test-kitchen suites that  
> > cover the majority of recipe code-paths (e.g. source vs package install,  
> > etc.), unit tested with chefspec, and support for the relevant  
> > Chef-supported platforms (  
> > [https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md](https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md)  
> > ).
> > 
> > if we then had some application process for Chef Inc to certify a  
> > cookbook as complying with the BCP, and we surfaced BCP-compliant cookbooks  
> > through Supermarket (with periodic review/recertification), I think we'd be  
> > most of the way to victory. This kind of surfacing would help deal with the  
> > naming conflict and abandoned cookbook issues we currently have to deal  
> > with (the systemd cookbook is a particularly egregious example of  
> > name-squatting), and would hopefully encourage community cookbook  
> > developers to put in extra effort, knowing that BCP compliance meant better  
> > visibility and more adoption.
> 
> Let's assume there would be a strong quality regime in place for community  
> cookbooks. Chef, Inc. would actively need to code review and monitor  
> everything except "write the code". I'm not sure if this can work and even  
> make sense. It's like taking over the responsibility ("certified cookbook")  
> without beeing able/willing to intervene when things get bad ("not  
> certified anymore, but out of our scope to fix").
> 
> It's also not useful to just increase the pressure for open source  
> developers if you want to keep and even increase the level of community  
> contribution.
> 
> This, again, brings up my other concern: Why, at all, maintain a community  
> cookbook?
> 
> The vast majority - as far as I can see - is maintained by single  
> developers and/or a single company. The GH issues to PR ration is like  
> 10:1, e.g. it's very time consuming to support, if you take issue reports  
> seriously and also less useful because PR aren't happening frequently and  
> are probably not that useful (  
> ​​  
> If your shop uses Debian X, you just don't care about some PR for CentOS Y  
> that much - and vice versa).
> 
> I can fully understand that most OSS cookbook developers don't have time  
> for this, become inactive or just give up. They are getting paid for  
> keeping their employer's (or their own) business up and scaling or don't  
> get paid at all and do this entirely in their spare time.
> 
> Nobody can blame them!
> 
> Most business are too critical to entirely rely on voluntary time  
> allocation by open source maintainers. If your business is serious, you'll  
> compulsorily have to start in-house maintaining most of the cookbooks over  
> time. Usually this also implies no further contribution back to the  
> ecosystem/upstream/supermarket. [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks)  
> (and OpsWorks in general) is a very good/bad example.
> 
> Best case is, that those "hidden" deployments will just stick with the  
> chef patterns of 2010+, worst case they build things that should never ever  
> be done in Chef and Ruby +that+ way… In almost every case, Chef (product)  
> will then be blamed for the eventual desaster, not the team that was not  
> able to adopt the best practices provided by the community and/or Chef,  
> Inc..
> 
> best regards  
> Roland
> 
> > anyways, that's my two cents.
> > 
> > regards,
> > 
> > nathan w
> > 
> > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:  
> > Hi,
> > 
> > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > > 
> > > yes there is a lot of value with Chef inc, providing a public  
> > > supermarket instance, it seeds community effort. You dont need it if you  
> > > consume cookbooks from github or other sources (can be public, can be  
> > > private/org specific).
> > 
> > I don’t think that it seeds community effort, because it’s often a  
> > „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken,  
> > outdated or just be a no-op cookbook that reserves the name:
> 
> [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> 
> > - number of downloads is irrelevant, as we all know
> > - follower number is also not a good indication, because even after a  
> > year, supermarket did not get the traction of e.g. github
> > - last release date is probably the best indicator. In my experience  
> > most cookbooks that are not updated within the last 12 months are outdated,  
> > e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How  
> > should starters „know“ this?
> > 
> > Imagine a rather new chef user that needs to deal with systemd unit  
> > files. Just with that single „trap" he/she will probably lose a couple of  
> > hours or days or give up and pick something else with batteries included.
> > 
> > I’m sure this is not intentional and everyone had the best intentions  
> > doing it the current way - but IMHO it’s broken :-/  
> > IMHO it’s all about hitting the right spot in between of „too much“ and  
> > „too little“ and the original opscode-cookbooks concept was probably a „too  
> > much“-problem and today it looks like we’re in a „too little“ situation.
> > 
> > > why should community maintainers maintain a cookbook? - many. and i  
> > > dont see the different of this with ruby gem, or any userspace tool (pyhton  
> > > egg, or a debian in ppa). But the common reasons are: 1) you dont want to  
> > > reinvent wheel,. if theres no opensource cookbook on ossec, every time i  
> > > join a place it allows me rapidly roll out ossec cookboook. 2) my job  
> > > depends on my skills/knowledge, to get a better job, i need to improve my  
> > > skill. but that not possible if theres no one to mentor inside my own org.  
> > > opensource brings that possibility. again this is not specific to chef, its  
> > > very opensource thing, if you dont understand it, or dont know what value  
> > > you get, dont do it. but for those of us, who are outside chef, uses it,  
> > > and loves it. exposure is a huge thing, i cant become oracle reporting  
> > > expert, but i can become chef expert even if dont have much money.
> > 
> > Sorry, but that doesn’t answer my question. Many open source projects  
> > start, when something (technology, framework) becomes „hot“. Everyone is  
> > trying to learn and get a spot in the eco system. Popularity usually also  
> > means a rising number of jobs, e.g. people can get their OSS contribution  
> > funded and/or get an interesting job. However this strategy starts to  
> > collapse when the crowd moves on to „even hotter“ things (typical hype  
> > lifecycle).
> > 
> > Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now  
> > outdated npm modules -\> maintainer moved to Go.  
> > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > 
> > This brain-drain affects not only the quantity but also the quality of  
> > projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to  
> > use it. Experience for new users will suffer.  
> > Why should people contribute to $not\_hot\_anymore projects? I don’t see  
> > that many unique chef-jobs, so having something in the GitHub repo/CV  
> > doesn’t bring you new opportunities by itself.  
> > Even a popular (\>200 stars on GH) knife plugin for some trending and  
> > cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).
> > 
> > possible options:
> > 
> > - provide minimal services that work out of the box by yourself (Chef,  
> > Inc)
> > - subsidize community to maintain it (you pay, you decide how)
> > - offer opportunities so people can benefit from supporting the  
> > community (e.g. job site, contract projects, sales-partnerships with indies)  
> > otoh: As far as I can see, most „Chef certified partners“ listed on  
> > [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the  
> > community and some companies that provide value to the community are not  
> > listed there at all…
> > 
> > > the last statement you made regarding namespace, is a technical  
> > > problem. again its no different here than any other place. for example  
> > > redhat has libvirt-lxc which everyone confuses with standard LXC but the  
> > > project itself has little code/feature compatibility with main LXC. The  
> > > point is like namespace is perceived, if you want you can publish a  
> > > cookbook with samename and if its really good (and assuming theres enough  
> > > people who wants it) you can definitely outweigh the other cookbook. if  
> > > thats not happening, lets address that.
> > 
> > Your libvirt-example is great, as it shows why nearly nobody used it and  
> > why Docker has such a huge impact by just providing a fancy way to  
> > distribute tar archives and wrap some syscalls 😉 (oversimplification  
> > intentional)  
> > Redhat isn’t very good in community/relationship outside of their own  
> > Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and  
> > admins. I think better tutorials and community-relations would have  
> > prevented that hatery/shitstorm against it.  
> > When I talk to systemd-"haters", I ask them to write me a sysv-init  
> > script for a service, then I show them the systemd unit representation.  
> > When ansible users talk to me (chef user), they ask me to write a  
> > solution that… whops. damn. You understand what I mean?
> > 
> > > the definition of critical is very diverse, theres no common critical  
> > > component/cookbook. nothing. 0. as far as the whole community is concerned.  
> > > if you freeze platform (since chef run from windows machine to raspberry  
> > > pi to AIX to solaris) you might get a list of critical cookbooks (like sudo  
> > > will be for linux), you might get another layer on family (like sysdtemd on  
> > > ubuntu 15.04) .. we are in process of establishing the family specific  
> > > maintainers, a similar effort can be made for cookbooks as well.. but will  
> > > be mostly community and few core contributors .. similar to kernel and  
> > > userspace.. linus and linux foundation or redhat does not maintain ruby  
> > > specific rpm etc..
> > 
> > Why do people need DevOps? To have a reliable infrastructure to provide  
> > services that make money and to stay competitive. Usually that involves  
> > more or less custom applications based on common frameworks/stacks that  
> > need to be deployed. So at least a couple of application deployment stacks  
> > are critical to show the benefits of a DevOps solution. Even the  
> > [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest releases  
> > of cookbooks used in the tutorial, so this is also a good definition of  
> > critical.
> > 
> > > i am very interested in addressing this.. please keep your thoughts  
> > > pouring 🙂 , but understand we cant solve it in a click, its gonna take  
> > > some time, we have to keep talking, and out collaborative efforts on the  
> > > next blockers toward this direction.
> > 
> > > fwiw i am the LT of chef on ubuntu, and i am working on a CD system  
> > > that will test actual community cookbooks on every master merge of chef.  
> > > Which will greatly reduce the maintenance burden, cause now core devs can  
> > > also see what affect the changeset has. Next step will be do a survey and  
> > > get a list of cookbooks and interested folks (brigade as we calling it) for  
> > > ubuntu. What i wonder is a common pool might not make sense, though Chef is  
> > > cross platform, majority of cookbook is not.
> > 
> > You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL  
> > 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something  
> > like „it installs runit triggered by sysv-init — and it still works…“ on a  
> > systemd distro 😉
> > 
> > regards  
> > Roland
> > 
> > PS: Despite all my examples I’m not a systemd zealot. I was okay with  
> > upstart… But a common base of various distros is a good thing for everyone  
> > in the long run. And it’s also a good example for a game-changer and about  
> > the agility/adoption capabilities of such things.
> > 
> > > hth  
> > > ranjib
> > > 
> > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> > > 
> > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > > 
> > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > > 
> > > > > To speak for Chef Software directly, we have always had people on  
> > > > > staff  
> > > > > whose role was assisting the creation and maintenance of cookbooks.  
> > > > > That  
> > > > > number has fluctuated up and down over time, with the skill sets of  
> > > > > people  
> > > > > we hire, and the normal day-to-day ebb and flow of trying to figure  
> > > > > out how  
> > > > > to build a business that is successful. We have people on staff  
> > > > > today who do  
> > > > > the same. What is clear is that the energy around cookbooks in the  
> > > > > community  
> > > > > is far greater than the energy we can muster as an organization  
> > > > > (regardless  
> > > > > of how much capital we do or do not have - y'all outnumber us) - and  
> > > > > so our  
> > > > > focus today is on trying to build and support the best community we  
> > > > > can,  
> > > > > through development of the supermarket, better tooling, and  
> > > > > providing a few  
> > > > > key examples of how best to build a community cookbook (see Sean's  
> > > > > work on  
> > > > > the httpd cookbook.)
> > > > > 
> > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > 
> > > > Hey Adam,
> > > > 
> > > > Would we consider transferring some of those cookbooks our of  
> > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > > > the preconditions to doing that?
> > > > 
> > > > Personally I would like the chef-brigade and redguide to be merged,  
> > > > but I do not remember all the players involved -- if they are on this  
> > > > list perhaps they can speak up.
> > > 
> > > How would this prevent the problems that happend with the last  
> > > migration of former opscode-cookbooks to community maintainers?
> > > 
> > > Why should community maintainers care about the cookbooks in the future?  
> > > It can be a time consuming burden and people need to pay their rent and  
> > > do their regular jobs…
> > > 
> > > I know, this will be very provoking, but:
> > > 
> > > If Chef, inc. doesn't want to maintain even critical cookbooks anymore,  
> > > is there still a valid reason for running a public Supermarket site?  
> > > If you go the "libertarian way" there is no reason for a supermarket  
> > > site to protect/block names of cookbooks anymore that prevents users to  
> > > pick other, maybe better community resources over legacy-cookbooks that are  
> > > mentioned in guides and examples.
> > > 
> > > Either you (Chef, Inc.) control the market (e.g. maintain critical  
> > > things yourself) or you should allow the free market (=community) to  
> > > compete against each other based on equal opportunity (= namespaces or no  
> > > supermarket). Everything else/in between will just end in chaos and anarchy.
> > > 
> > > regards  
> > > Roland

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [June 25, 2015, 4:28pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/12 "2015-06-25T16:28:23Z")

</div>

my suggestion for this was to add badges. like foodcritics, chefspec, tk,  
etc.. quality related badges as well as platform support related badges,  
and allow consumer to filter by those badges, extend the same worlkflows to  
knife cookbook download. But that whole thing relies on a build grid that  
is capable of assigning those badges automatically... also im not sure if  
this can be applied to all the platforms /scenarios.. but none the less it  
address some of the issues.

On Thu, Jun 25, 2015 at 9:11 AM, Yoshi Spendiff \<  
[yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:

> An official certification is probably too much to handle but there could  
> be value in stating guidelines that demonstrate how a reliable cookbook is  
> designed and tested. I know Chef doesn't like to prescribe but for the sake  
> of quality a recommended path for some things might be a good idea.
> 
> The reason to maintain a community cookbook is usually because it's  
> relevant to your business/job, which is obviously why cookbooks fall out of  
> repair and only have certain coverage.
> 
> If business 1 makes a cookbook for platform X only and business 2 wants  
> to do the same for platform Y then their options are:
> 
> 1. Make a new cookbook for platform X
> 2. Fork
> 3. Work on a pull request  
> Having good methods for business 2 to contact business 1 and state their  
> intention could lead to productive collaboration and implementing better  
> ways to find contributors and reviewers of cookbooks could be a good way to  
> help out with this, whether it's business to business or just individual  
> contributors.
> 
> It would also be useful for there to be a mechanism where ownership of  
> stale cookbooks can be transferred, especially now there are groups that  
> are willing to maintain them.
> 
> Finally, better sorting and maybe a rating system on the supermarket for  
> cookbooks would be good. If a cookbook starts out excellent but isn't  
> maintained then many lower reviews will start to drag down the rating.
> 
> On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> 
> > > Am 24.06.2015 um 17:33 schrieb Nathan Williams [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com):  
> > > i'd really like to see some official (maybe a BCP Chef RFC?) guidelines  
> > > for quality based around the BCP guidelines... For example: evaluated with  
> > > foodcritic and rubocop, integration tested with test-kitchen suites that  
> > > cover the majority of recipe code-paths (e.g. source vs package install,  
> > > etc.), unit tested with chefspec, and support for the relevant  
> > > Chef-supported platforms (  
> > > [https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md](https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md)  
> > > ).
> > > 
> > > if we then had some application process for Chef Inc to certify a  
> > > cookbook as complying with the BCP, and we surfaced BCP-compliant cookbooks  
> > > through Supermarket (with periodic review/recertification), I think we'd be  
> > > most of the way to victory. This kind of surfacing would help deal with the  
> > > naming conflict and abandoned cookbook issues we currently have to deal  
> > > with (the systemd cookbook is a particularly egregious example of  
> > > name-squatting), and would hopefully encourage community cookbook  
> > > developers to put in extra effort, knowing that BCP compliance meant better  
> > > visibility and more adoption.
> > 
> > Let's assume there would be a strong quality regime in place for  
> > community cookbooks. Chef, Inc. would actively need to code review and  
> > monitor everything except "write the code". I'm not sure if this can work  
> > and even make sense. It's like taking over the responsibility ("certified  
> > cookbook") without beeing able/willing to intervene when things get bad  
> > ("not certified anymore, but out of our scope to fix").
> > 
> > It's also not useful to just increase the pressure for open source  
> > developers if you want to keep and even increase the level of community  
> > contribution.
> > 
> > This, again, brings up my other concern: Why, at all, maintain a  
> > community cookbook?
> > 
> > The vast majority - as far as I can see - is maintained by single  
> > developers and/or a single company. The GH issues to PR ration is like  
> > 10:1, e.g. it's very time consuming to support, if you take issue reports  
> > seriously and also less useful because PR aren't happening frequently and  
> > are probably not that useful (If your shop uses Debian X, you just don't  
> > care about some PR for CentOS Y that much - and vice versa).
> > 
> > I can fully understand that most OSS cookbook developers don't have time  
> > for this, become inactive or just give up. They are getting paid for  
> > keeping their employer's (or their own) business up and scaling or don't  
> > get paid at all and do this entirely in their spare time.
> > 
> > Nobody can blame them!
> > 
> > Most business are too critical to entirely rely on voluntary time  
> > allocation by open source maintainers. If your business is serious, you'll  
> > compulsorily have to start in-house maintaining most of the cookbooks over  
> > time. Usually this also implies no further contribution back to the  
> > ecosystem/upstream/supermarket. [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks)  
> > (and OpsWorks in general) is a very good/bad example.
> > 
> > Best case is, that those "hidden" deployments will just stick with the  
> > chef patterns of 2010+, worst case they build things that should never ever  
> > be done in Chef and Ruby +that+ way… In almost every case, Chef (product)  
> > will then be blamed for the eventual desaster, not the team that was not  
> > able to adopt the best practices provided by the community and/or Chef,  
> > Inc..
> > 
> > best regards  
> > Roland
> > 
> > > anyways, that's my two cents.
> > > 
> > > regards,
> > > 
> > > nathan w
> > > 
> > > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:  
> > > Hi,
> > > 
> > > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > > > 
> > > > yes there is a lot of value with Chef inc, providing a public  
> > > > supermarket instance, it seeds community effort. You dont need it if you  
> > > > consume cookbooks from github or other sources (can be public, can be  
> > > > private/org specific).
> > > 
> > > I don’t think that it seeds community effort, because it’s often a  
> > > „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken,  
> > > outdated or just be a no-op cookbook that reserves the name:
> > 
> > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> > 
> > > - number of downloads is irrelevant, as we all know
> > > - follower number is also not a good indication, because even after a  
> > > year, supermarket did not get the traction of e.g. github
> > > - last release date is probably the best indicator. In my experience  
> > > most cookbooks that are not updated within the last 12 months are outdated,  
> > > e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How  
> > > should starters „know“ this?
> > > 
> > > Imagine a rather new chef user that needs to deal with systemd unit  
> > > files. Just with that single „trap" he/she will probably lose a couple of  
> > > hours or days or give up and pick something else with batteries included.
> > > 
> > > I’m sure this is not intentional and everyone had the best intentions  
> > > doing it the current way - but IMHO it’s broken :-/  
> > > IMHO it’s all about hitting the right spot in between of „too much“ and  
> > > „too little“ and the original opscode-cookbooks concept was probably a „too  
> > > much“-problem and today it looks like we’re in a „too little“ situation.
> > > 
> > > > why should community maintainers maintain a cookbook? - many. and i  
> > > > dont see the different of this with ruby gem, or any userspace tool (pyhton  
> > > > egg, or a debian in ppa). But the common reasons are: 1) you dont want to  
> > > > reinvent wheel,. if theres no opensource cookbook on ossec, every time i  
> > > > join a place it allows me rapidly roll out ossec cookboook. 2) my job  
> > > > depends on my skills/knowledge, to get a better job, i need to improve my  
> > > > skill. but that not possible if theres no one to mentor inside my own org.  
> > > > opensource brings that possibility. again this is not specific to chef, its  
> > > > very opensource thing, if you dont understand it, or dont know what value  
> > > > you get, dont do it. but for those of us, who are outside chef, uses it,  
> > > > and loves it. exposure is a huge thing, i cant become oracle reporting  
> > > > expert, but i can become chef expert even if dont have much money.
> > > 
> > > Sorry, but that doesn’t answer my question. Many open source projects  
> > > start, when something (technology, framework) becomes „hot“. Everyone is  
> > > trying to learn and get a spot in the eco system. Popularity usually also  
> > > means a rising number of jobs, e.g. people can get their OSS contribution  
> > > funded and/or get an interesting job. However this strategy starts to  
> > > collapse when the crowd moves on to „even hotter“ things (typical hype  
> > > lifecycle).
> > > 
> > > Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now  
> > > outdated npm modules -\> maintainer moved to Go.  
> > > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > > 
> > > This brain-drain affects not only the quantity but also the quality of  
> > > projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to  
> > > use it. Experience for new users will suffer.  
> > > Why should people contribute to $not\_hot\_anymore projects? I don’t see  
> > > that many unique chef-jobs, so having something in the GitHub repo/CV  
> > > doesn’t bring you new opportunities by itself.  
> > > Even a popular (\>200 stars on GH) knife plugin for some trending and  
> > > cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).
> > > 
> > > possible options:
> > > 
> > > - provide minimal services that work out of the box by yourself (Chef,  
> > > Inc)
> > > - subsidize community to maintain it (you pay, you decide how)
> > > - offer opportunities so people can benefit from supporting the  
> > > community (e.g. job site, contract projects, sales-partnerships with indies)  
> > > otoh: As far as I can see, most „Chef certified partners“ listed on  
> > > [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the  
> > > community and some companies that provide value to the community are not  
> > > listed there at all…
> > > 
> > > > the last statement you made regarding namespace, is a technical  
> > > > problem. again its no different here than any other place. for example  
> > > > redhat has libvirt-lxc which everyone confuses with standard LXC but the  
> > > > project itself has little code/feature compatibility with main LXC. The  
> > > > point is like namespace is perceived, if you want you can publish a  
> > > > cookbook with samename and if its really good (and assuming theres enough  
> > > > people who wants it) you can definitely outweigh the other cookbook. if  
> > > > thats not happening, lets address that.
> > > 
> > > Your libvirt-example is great, as it shows why nearly nobody used it  
> > > and why Docker has such a huge impact by just providing a fancy way to  
> > > distribute tar archives and wrap some syscalls 😉 (oversimplification  
> > > intentional)  
> > > Redhat isn’t very good in community/relationship outside of their own  
> > > Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and  
> > > admins. I think better tutorials and community-relations would have  
> > > prevented that hatery/shitstorm against it.  
> > > When I talk to systemd-"haters", I ask them to write me a sysv-init  
> > > script for a service, then I show them the systemd unit representation.  
> > > When ansible users talk to me (chef user), they ask me to write a  
> > > solution that… whops. damn. You understand what I mean?
> > > 
> > > > the definition of critical is very diverse, theres no common critical  
> > > > component/cookbook. nothing. 0. as far as the whole community is concerned.  
> > > > if you freeze platform (since chef run from windows machine to raspberry  
> > > > pi to AIX to solaris) you might get a list of critical cookbooks (like sudo  
> > > > will be for linux), you might get another layer on family (like sysdtemd on  
> > > > ubuntu 15.04) .. we are in process of establishing the family specific  
> > > > maintainers, a similar effort can be made for cookbooks as well.. but will  
> > > > be mostly community and few core contributors .. similar to kernel and  
> > > > userspace.. linus and linux foundation or redhat does not maintain ruby  
> > > > specific rpm etc..
> > > 
> > > Why do people need DevOps? To have a reliable infrastructure to provide  
> > > services that make money and to stay competitive. Usually that involves  
> > > more or less custom applications based on common frameworks/stacks that  
> > > need to be deployed. So at least a couple of application deployment stacks  
> > > are critical to show the benefits of a DevOps solution. Even the  
> > > [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest  
> > > releases of cookbooks used in the tutorial, so this is also a good  
> > > definition of critical.
> > > 
> > > > i am very interested in addressing this.. please keep your thoughts  
> > > > pouring 🙂 , but understand we cant solve it in a click, its gonna take  
> > > > some time, we have to keep talking, and out collaborative efforts on the  
> > > > next blockers toward this direction.
> > > 
> > > > fwiw i am the LT of chef on ubuntu, and i am working on a CD system  
> > > > that will test actual community cookbooks on every master merge of chef.  
> > > > Which will greatly reduce the maintenance burden, cause now core devs can  
> > > > also see what affect the changeset has. Next step will be do a survey and  
> > > > get a list of cookbooks and interested folks (brigade as we calling it) for  
> > > > ubuntu. What i wonder is a common pool might not make sense, though Chef is  
> > > > cross platform, majority of cookbook is not.
> > > 
> > > You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL  
> > > 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something  
> > > like „it installs runit triggered by sysv-init — and it still works…“ on a  
> > > systemd distro 😉
> > > 
> > > regards  
> > > Roland
> > > 
> > > PS: Despite all my examples I’m not a systemd zealot. I was okay with  
> > > upstart… But a common base of various distros is a good thing for everyone  
> > > in the long run. And it’s also a good example for a game-changer and about  
> > > the agility/adoption capabilities of such things.
> > > 
> > > > hth  
> > > > ranjib
> > > > 
> > > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > > wrote:
> > > > 
> > > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > > > 
> > > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > > > 
> > > > > > To speak for Chef Software directly, we have always had people on  
> > > > > > staff  
> > > > > > whose role was assisting the creation and maintenance of cookbooks.  
> > > > > > That  
> > > > > > number has fluctuated up and down over time, with the skill sets of  
> > > > > > people  
> > > > > > we hire, and the normal day-to-day ebb and flow of trying to figure  
> > > > > > out how  
> > > > > > to build a business that is successful. We have people on staff  
> > > > > > today who do  
> > > > > > the same. What is clear is that the energy around cookbooks in the  
> > > > > > community  
> > > > > > is far greater than the energy we can muster as an organization  
> > > > > > (regardless  
> > > > > > of how much capital we do or do not have - y'all outnumber us) -  
> > > > > > and so our  
> > > > > > focus today is on trying to build and support the best community we  
> > > > > > can,  
> > > > > > through development of the supermarket, better tooling, and  
> > > > > > providing a few  
> > > > > > key examples of how best to build a community cookbook (see Sean's  
> > > > > > work on  
> > > > > > the httpd cookbook.)
> > > > > > 
> > > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > > 
> > > > > Hey Adam,
> > > > > 
> > > > > Would we consider transferring some of those cookbooks our of  
> > > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > > > > the preconditions to doing that?
> > > > > 
> > > > > Personally I would like the chef-brigade and redguide to be merged,  
> > > > > but I do not remember all the players involved -- if they are on this  
> > > > > list perhaps they can speak up.
> > > > 
> > > > How would this prevent the problems that happend with the last  
> > > > migration of former opscode-cookbooks to community maintainers?
> > > > 
> > > > Why should community maintainers care about the cookbooks in the  
> > > > future?  
> > > > It can be a time consuming burden and people need to pay their rent  
> > > > and do their regular jobs…
> > > > 
> > > > I know, this will be very provoking, but:
> > > > 
> > > > If Chef, inc. doesn't want to maintain even critical cookbooks  
> > > > anymore, is there still a valid reason for running a public Supermarket  
> > > > site?  
> > > > If you go the "libertarian way" there is no reason for a supermarket  
> > > > site to protect/block names of cookbooks anymore that prevents users to  
> > > > pick other, maybe better community resources over legacy-cookbooks that are  
> > > > mentioned in guides and examples.
> > > > 
> > > > Either you (Chef, Inc.) control the market (e.g. maintain critical  
> > > > things yourself) or you should allow the free market (=community) to  
> > > > compete against each other based on equal opportunity (= namespaces or no  
> > > > supermarket). Everything else/in between will just end in chaos and anarchy.
> > > > 
> > > > regards  
> > > > Roland
> 
> --  
> Yoshi Spendiff  
> Ops Engineer  
> Indochino  
> Mobile: +1 778 952 2025  
> Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![Torben\_Knerr](https://avatars.discourse-cdn.com/v4/letter/t/ba8739/32.png) [@Torben\_Knerr](https://discourse.chef.io/u/Torben_Knerr)\
**Post date:** [June 25, 2015, 4:36pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/13 "2015-06-25T16:36:07Z")

</div>

@Rabjib +1

P.S. on this:

> 1. I could imagine that b  
> ounty programs  
> ​ could be effective ​  
> ​, especially if  
> they offer some kind of monetary rewards (or free confernece tickets etc)  
> for working on community cookbooks  
> ​ (which is a free time / spare time affair for quite a few of us, I guess)

...or just stickers, or t-shirts, etc... it's not about the money, but  
something where you'd feel that's worth putting effort into for.  
On the other hand, building a business around improving cookbook quality  
does not sound too bad either... 😉

On Thu, Jun 25, 2015 at 6:28 PM, Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com) wrote:

> my suggestion for this was to add badges. like foodcritics, chefspec, tk,  
> etc.. quality related badges as well as platform support related badges,  
> and allow consumer to filter by those badges, extend the same worlkflows to  
> knife cookbook download. But that whole thing relies on a build grid that  
> is capable of assigning those badges automatically... also im not sure if  
> this can be applied to all the platforms /scenarios.. but none the less it  
> address some of the issues.
> 
> On Thu, Jun 25, 2015 at 9:11 AM, Yoshi Spendiff \<  
> [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:
> 
> > An official certification is probably too much to handle but there could  
> > be value in stating guidelines that demonstrate how a reliable cookbook is  
> > designed and tested. I know Chef doesn't like to prescribe but for the sake  
> > of quality a recommended path for some things might be a good idea.
> > 
> > The reason to maintain a community cookbook is usually because it's  
> > relevant to your business/job, which is obviously why cookbooks fall out of  
> > repair and only have certain coverage.
> > 
> > If business 1 makes a cookbook for platform X only and business 2 wants  
> > to do the same for platform Y then their options are:
> > 
> > 1. Make a new cookbook for platform X
> > 2. Fork
> > 3. Work on a pull request  
> > Having good methods for business 2 to contact business 1 and state their  
> > intention could lead to productive collaboration and implementing better  
> > ways to find contributors and reviewers of cookbooks could be a good way to  
> > help out with this, whether it's business to business or just individual  
> > contributors.
> > 
> > It would also be useful for there to be a mechanism where ownership of  
> > stale cookbooks can be transferred, especially now there are groups that  
> > are willing to maintain them.
> > 
> > Finally, better sorting and maybe a rating system on the supermarket for  
> > cookbooks would be good. If a cookbook starts out excellent but isn't  
> > maintained then many lower reviews will start to drag down the rating.
> > 
> > On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> > 
> > > > Am 24.06.2015 um 17:33 schrieb Nathan Williams \<[nath.e.will@gmail.com](mailto:nath.e.will@gmail.com)  
> > > > :  
> > > > i'd really like to see some official (maybe a BCP Chef RFC?)  
> > > > guidelines for quality based around the BCP guidelines... For example:  
> > > > evaluated with foodcritic and rubocop, integration tested with test-kitchen  
> > > > suites that cover the majority of recipe code-paths (e.g. source vs package  
> > > > install, etc.), unit tested with chefspec, and support for the relevant  
> > > > Chef-supported platforms (  
> > > > [https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md](https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md)  
> > > > ).
> > > > 
> > > > if we then had some application process for Chef Inc to certify a  
> > > > cookbook as complying with the BCP, and we surfaced BCP-compliant cookbooks  
> > > > through Supermarket (with periodic review/recertification), I think we'd be  
> > > > most of the way to victory. This kind of surfacing would help deal with the  
> > > > naming conflict and abandoned cookbook issues we currently have to deal  
> > > > with (the systemd cookbook is a particularly egregious example of  
> > > > name-squatting), and would hopefully encourage community cookbook  
> > > > developers to put in extra effort, knowing that BCP compliance meant better  
> > > > visibility and more adoption.
> > > 
> > > Let's assume there would be a strong quality regime in place for  
> > > community cookbooks. Chef, Inc. would actively need to code review and  
> > > monitor everything except "write the code". I'm not sure if this can work  
> > > and even make sense. It's like taking over the responsibility ("certified  
> > > cookbook") without beeing able/willing to intervene when things get bad  
> > > ("not certified anymore, but out of our scope to fix").
> > > 
> > > It's also not useful to just increase the pressure for open source  
> > > developers if you want to keep and even increase the level of community  
> > > contribution.
> > > 
> > > This, again, brings up my other concern: Why, at all, maintain a  
> > > community cookbook?
> > > 
> > > The vast majority - as far as I can see - is maintained by single  
> > > developers and/or a single company. The GH issues to PR ration is like  
> > > 10:1, e.g. it's very time consuming to support, if you take issue reports  
> > > seriously and also less useful because PR aren't happening frequently and  
> > > are probably not that useful (If your shop uses Debian X, you just don't  
> > > care about some PR for CentOS Y that much - and vice versa).
> > > 
> > > I can fully understand that most OSS cookbook developers don't have time  
> > > for this, become inactive or just give up. They are getting paid for  
> > > keeping their employer's (or their own) business up and scaling or don't  
> > > get paid at all and do this entirely in their spare time.
> > > 
> > > Nobody can blame them!
> > > 
> > > Most business are too critical to entirely rely on voluntary time  
> > > allocation by open source maintainers. If your business is serious, you'll  
> > > compulsorily have to start in-house maintaining most of the cookbooks over  
> > > time. Usually this also implies no further contribution back to the  
> > > ecosystem/upstream/supermarket.  
> > > [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks) (and OpsWorks in general) is  
> > > a very good/bad example.
> > > 
> > > Best case is, that those "hidden" deployments will just stick with the  
> > > chef patterns of 2010+, worst case they build things that should never ever  
> > > be done in Chef and Ruby +that+ way… In almost every case, Chef (product)  
> > > will then be blamed for the eventual desaster, not the team that was not  
> > > able to adopt the best practices provided by the community and/or Chef,  
> > > Inc..
> > > 
> > > best regards  
> > > Roland
> > > 
> > > > anyways, that's my two cents.
> > > > 
> > > > regards,
> > > > 
> > > > nathan w
> > > > 
> > > > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:  
> > > > Hi,
> > > > 
> > > > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > > > > 
> > > > > yes there is a lot of value with Chef inc, providing a public  
> > > > > supermarket instance, it seeds community effort. You dont need it if you  
> > > > > consume cookbooks from github or other sources (can be public, can be  
> > > > > private/org specific).
> > > > 
> > > > I don’t think that it seeds community effort, because it’s often a  
> > > > „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken,  
> > > > outdated or just be a no-op cookbook that reserves the name:
> > > 
> > > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> > > 
> > > > - number of downloads is irrelevant, as we all know
> > > > - follower number is also not a good indication, because even after a  
> > > > year, supermarket did not get the traction of e.g. github
> > > > - last release date is probably the best indicator. In my experience  
> > > > most cookbooks that are not updated within the last 12 months are outdated,  
> > > > e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How  
> > > > should starters „know“ this?
> > > > 
> > > > Imagine a rather new chef user that needs to deal with systemd unit  
> > > > files. Just with that single „trap" he/she will probably lose a couple of  
> > > > hours or days or give up and pick something else with batteries included.
> > > > 
> > > > I’m sure this is not intentional and everyone had the best intentions  
> > > > doing it the current way - but IMHO it’s broken :-/  
> > > > IMHO it’s all about hitting the right spot in between of „too much“  
> > > > and „too little“ and the original opscode-cookbooks concept was probably a  
> > > > „too much“-problem and today it looks like we’re in a „too little“  
> > > > situation.
> > > > 
> > > > > why should community maintainers maintain a cookbook? - many. and i  
> > > > > dont see the different of this with ruby gem, or any userspace tool (pyhton  
> > > > > egg, or a debian in ppa). But the common reasons are: 1) you dont want to  
> > > > > reinvent wheel,. if theres no opensource cookbook on ossec, every time i  
> > > > > join a place it allows me rapidly roll out ossec cookboook. 2) my job  
> > > > > depends on my skills/knowledge, to get a better job, i need to improve my  
> > > > > skill. but that not possible if theres no one to mentor inside my own org.  
> > > > > opensource brings that possibility. again this is not specific to chef, its  
> > > > > very opensource thing, if you dont understand it, or dont know what value  
> > > > > you get, dont do it. but for those of us, who are outside chef, uses it,  
> > > > > and loves it. exposure is a huge thing, i cant become oracle reporting  
> > > > > expert, but i can become chef expert even if dont have much money.
> > > > 
> > > > Sorry, but that doesn’t answer my question. Many open source projects  
> > > > start, when something (technology, framework) becomes „hot“. Everyone is  
> > > > trying to learn and get a spot in the eco system. Popularity usually also  
> > > > means a rising number of jobs, e.g. people can get their OSS contribution  
> > > > funded and/or get an interesting job. However this strategy starts to  
> > > > collapse when the crowd moves on to „even hotter“ things (typical hype  
> > > > lifecycle).
> > > > 
> > > > Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now  
> > > > outdated npm modules -\> maintainer moved to Go.  
> > > > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > > > 
> > > > This brain-drain affects not only the quantity but also the quality of  
> > > > projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to  
> > > > use it. Experience for new users will suffer.  
> > > > Why should people contribute to $not\_hot\_anymore projects? I don’t see  
> > > > that many unique chef-jobs, so having something in the GitHub repo/CV  
> > > > doesn’t bring you new opportunities by itself.  
> > > > Even a popular (\>200 stars on GH) knife plugin for some trending and  
> > > > cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).
> > > > 
> > > > possible options:
> > > > 
> > > > - provide minimal services that work out of the box by yourself (Chef,  
> > > > Inc)
> > > > - subsidize community to maintain it (you pay, you decide how)
> > > > - offer opportunities so people can benefit from supporting the  
> > > > community (e.g. job site, contract projects, sales-partnerships with indies)  
> > > > otoh: As far as I can see, most „Chef certified partners“ listed on  
> > > > [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the  
> > > > community and some companies that provide value to the community are not  
> > > > listed there at all…
> > > > 
> > > > > the last statement you made regarding namespace, is a technical  
> > > > > problem. again its no different here than any other place. for example  
> > > > > redhat has libvirt-lxc which everyone confuses with standard LXC but the  
> > > > > project itself has little code/feature compatibility with main LXC. The  
> > > > > point is like namespace is perceived, if you want you can publish a  
> > > > > cookbook with samename and if its really good (and assuming theres enough  
> > > > > people who wants it) you can definitely outweigh the other cookbook. if  
> > > > > thats not happening, lets address that.
> > > > 
> > > > Your libvirt-example is great, as it shows why nearly nobody used it  
> > > > and why Docker has such a huge impact by just providing a fancy way to  
> > > > distribute tar archives and wrap some syscalls 😉 (oversimplification  
> > > > intentional)  
> > > > Redhat isn’t very good in community/relationship outside of their own  
> > > > Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and  
> > > > admins. I think better tutorials and community-relations would have  
> > > > prevented that hatery/shitstorm against it.  
> > > > When I talk to systemd-"haters", I ask them to write me a sysv-init  
> > > > script for a service, then I show them the systemd unit representation.  
> > > > When ansible users talk to me (chef user), they ask me to write a  
> > > > solution that… whops. damn. You understand what I mean?
> > > > 
> > > > > the definition of critical is very diverse, theres no common critical  
> > > > > component/cookbook. nothing. 0. as far as the whole community is concerned.  
> > > > > if you freeze platform (since chef run from windows machine to raspberry  
> > > > > pi to AIX to solaris) you might get a list of critical cookbooks (like sudo  
> > > > > will be for linux), you might get another layer on family (like sysdtemd on  
> > > > > ubuntu 15.04) .. we are in process of establishing the family specific  
> > > > > maintainers, a similar effort can be made for cookbooks as well.. but will  
> > > > > be mostly community and few core contributors .. similar to kernel and  
> > > > > userspace.. linus and linux foundation or redhat does not maintain ruby  
> > > > > specific rpm etc..
> > > > 
> > > > Why do people need DevOps? To have a reliable infrastructure to  
> > > > provide services that make money and to stay competitive. Usually that  
> > > > involves more or less custom applications based on common frameworks/stacks  
> > > > that need to be deployed. So at least a couple of application deployment  
> > > > stacks are critical to show the benefits of a DevOps solution. Even the  
> > > > [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest  
> > > > releases of cookbooks used in the tutorial, so this is also a good  
> > > > definition of critical.
> > > > 
> > > > > i am very interested in addressing this.. please keep your thoughts  
> > > > > pouring 🙂 , but understand we cant solve it in a click, its gonna take  
> > > > > some time, we have to keep talking, and out collaborative efforts on the  
> > > > > next blockers toward this direction.
> > > > 
> > > > > fwiw i am the LT of chef on ubuntu, and i am working on a CD system  
> > > > > that will test actual community cookbooks on every master merge of chef.  
> > > > > Which will greatly reduce the maintenance burden, cause now core devs can  
> > > > > also see what affect the changeset has. Next step will be do a survey and  
> > > > > get a list of cookbooks and interested folks (brigade as we calling it) for  
> > > > > ubuntu. What i wonder is a common pool might not make sense, though Chef is  
> > > > > cross platform, majority of cookbook is not.
> > > > 
> > > > You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL  
> > > > 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something  
> > > > like „it installs runit triggered by sysv-init — and it still works…“ on a  
> > > > systemd distro 😉
> > > > 
> > > > regards  
> > > > Roland
> > > > 
> > > > PS: Despite all my examples I’m not a systemd zealot. I was okay with  
> > > > upstart… But a common base of various distros is a good thing for everyone  
> > > > in the long run. And it’s also a good example for a game-changer and about  
> > > > the agility/adoption capabilities of such things.
> > > > 
> > > > > hth  
> > > > > ranjib
> > > > > 
> > > > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > > > wrote:
> > > > > 
> > > > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > > > > 
> > > > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > > > > 
> > > > > > > To speak for Chef Software directly, we have always had people on  
> > > > > > > staff  
> > > > > > > whose role was assisting the creation and maintenance of  
> > > > > > > cookbooks. That  
> > > > > > > number has fluctuated up and down over time, with the skill sets  
> > > > > > > of people  
> > > > > > > we hire, and the normal day-to-day ebb and flow of trying to  
> > > > > > > figure out how  
> > > > > > > to build a business that is successful. We have people on staff  
> > > > > > > today who do  
> > > > > > > the same. What is clear is that the energy around cookbooks in the  
> > > > > > > community  
> > > > > > > is far greater than the energy we can muster as an organization  
> > > > > > > (regardless  
> > > > > > > of how much capital we do or do not have - y'all outnumber us) -  
> > > > > > > and so our  
> > > > > > > focus today is on trying to build and support the best community  
> > > > > > > we can,  
> > > > > > > through development of the supermarket, better tooling, and  
> > > > > > > providing a few  
> > > > > > > key examples of how best to build a community cookbook (see Sean's  
> > > > > > > work on  
> > > > > > > the httpd cookbook.)
> > > > > > > 
> > > > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > > > 
> > > > > > Hey Adam,
> > > > > > 
> > > > > > Would we consider transferring some of those cookbooks our of  
> > > > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > > > > > the preconditions to doing that?
> > > > > > 
> > > > > > Personally I would like the chef-brigade and redguide to be merged,  
> > > > > > but I do not remember all the players involved -- if they are on  
> > > > > > this  
> > > > > > list perhaps they can speak up.
> > > > > 
> > > > > How would this prevent the problems that happend with the last  
> > > > > migration of former opscode-cookbooks to community maintainers?
> > > > > 
> > > > > Why should community maintainers care about the cookbooks in the  
> > > > > future?  
> > > > > It can be a time consuming burden and people need to pay their rent  
> > > > > and do their regular jobs…
> > > > > 
> > > > > I know, this will be very provoking, but:
> > > > > 
> > > > > If Chef, inc. doesn't want to maintain even critical cookbooks  
> > > > > anymore, is there still a valid reason for running a public Supermarket  
> > > > > site?  
> > > > > If you go the "libertarian way" there is no reason for a supermarket  
> > > > > site to protect/block names of cookbooks anymore that prevents users to  
> > > > > pick other, maybe better community resources over legacy-cookbooks that are  
> > > > > mentioned in guides and examples.
> > > > > 
> > > > > Either you (Chef, Inc.) control the market (e.g. maintain critical  
> > > > > things yourself) or you should allow the free market (=community) to  
> > > > > compete against each other based on equal opportunity (= namespaces or no  
> > > > > supermarket). Everything else/in between will just end in chaos and anarchy.
> > > > > 
> > > > > regards  
> > > > > Roland
> > 
> > --  
> > Yoshi Spendiff  
> > Ops Engineer  
> > Indochino  
> > Mobile: +1 778 952 2025  
> > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![Roland\_Moriz1](https://avatars.discourse-cdn.com/v4/letter/r/9fc29f/32.png) [@Roland\_Moriz1](https://discourse.chef.io/u/Roland_Moriz1)\
**Post date:** [June 25, 2015, 4:53pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/14 "2015-06-25T16:53:09Z")

</div>

> Am 25.06.2015 um 18:11 schrieb Yoshi Spendiff [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com):  
> The reason to maintain a community cookbook is usually because it's relevant to your business/job, which is obviously why cookbooks fall out of repair and only have certain coverage.
> 
> If business 1 makes a cookbook for platform X only and business 2 wants to do the same for platform Y then their options are:
> 
> 1. Make a new cookbook for platform X
> 2. Fork
> 3. Work on a pull request  
> Having good methods for business 2 to contact business 1 and state their intention could lead to productive collaboration and implementing better ways to find contributors and reviewers of cookbooks could be a good way to help out with this, whether it's business to business or just individual contributors.

Actually, that's exactly what I tried with some cookbooks that are relevant to my interest. In one case I got the answer, that a rewrite is in the works and current issues/PR probably won't be handled. I was told to go through the open issues to make a triage easier.

Which I did. Problem: Still nothing happend.

Forking doesn't help, neither does Supermarket: If you use Berkshelf, at least for CI, then you would have to recursively change all Berksfiles to use your fork ("cookbook 'whatever', github: 'user/repo' "), given that you don't change the name of the cookbook.  
If you miss one, you'll gonna have a bad time.™

If you decide to do a "orgname-cookbookname" rename-fork, good luck with changing all LWRPs…

regards  
Roland

> It would also be useful for there to be a mechanism where ownership of stale cookbooks can be transferred, especially now there are groups that are willing to maintain them.
> 
> Finally, better sorting and maybe a rating system on the supermarket for cookbooks would be good. If a cookbook starts out excellent but isn't maintained then many lower reviews will start to drag down the rating.
> 
> On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> 
> > Am 24.06.2015 um 17:33 schrieb Nathan Williams [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com):  
> > i'd really like to see some official (maybe a BCP Chef RFC?) guidelines for quality based around the BCP guidelines... For example: evaluated with foodcritic and rubocop, integration tested with test-kitchen suites that cover the majority of recipe code-paths (e.g. source vs package install, etc.), unit tested with chefspec, and support for the relevant Chef-supported platforms ([https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md](https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md)).
> > 
> > if we then had some application process for Chef Inc to certify a cookbook as complying with the BCP, and we surfaced BCP-compliant cookbooks through Supermarket (with periodic review/recertification), I think we'd be most of the way to victory. This kind of surfacing would help deal with the naming conflict and abandoned cookbook issues we currently have to deal with (the systemd cookbook is a particularly egregious example of name-squatting), and would hopefully encourage community cookbook developers to put in extra effort, knowing that BCP compliance meant better visibility and more adoption.
> 
> Let's assume there would be a strong quality regime in place for community cookbooks. Chef, Inc. would actively need to code review and monitor everything except "write the code". I'm not sure if this can work and even make sense. It's like taking over the responsibility ("certified cookbook") without beeing able/willing to intervene when things get bad ("not certified anymore, but out of our scope to fix").
> 
> It's also not useful to just increase the pressure for open source developers if you want to keep and even increase the level of community contribution.
> 
> This, again, brings up my other concern: Why, at all, maintain a community cookbook?
> 
> The vast majority - as far as I can see - is maintained by single developers and/or a single company. The GH issues to PR ration is like 10:1, e.g. it's very time consuming to support, if you take issue reports seriously and also less useful because PR aren't happening frequently and are probably not that useful (If your shop uses Debian X, you just don't care about some PR for CentOS Y that much - and vice versa).
> 
> I can fully understand that most OSS cookbook developers don't have time for this, become inactive or just give up. They are getting paid for keeping their employer's (or their own) business up and scaling or don't get paid at all and do this entirely in their spare time.
> 
> Nobody can blame them!
> 
> Most business are too critical to entirely rely on voluntary time allocation by open source maintainers. If your business is serious, you'll compulsorily have to start in-house maintaining most of the cookbooks over time. Usually this also implies no further contribution back to the ecosystem/upstream/supermarket. [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks) (and OpsWorks in general) is a very good/bad example.
> 
> Best case is, that those "hidden" deployments will just stick with the chef patterns of 2010+, worst case they build things that should never ever be done in Chef and Ruby +that+ way… In almost every case, Chef (product) will then be blamed for the eventual desaster, not the team that was not able to adopt the best practices provided by the community and/or Chef, Inc..
> 
> best regards  
> Roland
> 
> > anyways, that's my two cents.
> > 
> > regards,
> > 
> > nathan w
> > 
> > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:  
> > Hi,
> > 
> > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > > 
> > > yes there is a lot of value with Chef inc, providing a public supermarket instance, it seeds community effort. You dont need it if you consume cookbooks from github or other sources (can be public, can be private/org specific).
> > 
> > I don’t think that it seeds community effort, because it’s often a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken, outdated or just be a no-op cookbook that reserves the name:
> > 
> > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> > 
> > - number of downloads is irrelevant, as we all know
> > - follower number is also not a good indication, because even after a year, supermarket did not get the traction of e.g. github
> > - last release date is probably the best indicator. In my experience most cookbooks that are not updated within the last 12 months are outdated, e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> > 
> > Imagine a rather new chef user that needs to deal with systemd unit files. Just with that single „trap" he/she will probably lose a couple of hours or days or give up and pick something else with batteries included.
> > 
> > I’m sure this is not intentional and everyone had the best intentions doing it the current way - but IMHO it’s broken :-/  
> > IMHO it’s all about hitting the right spot in between of „too much“ and „too little“ and the original opscode-cookbooks concept was probably a „too much“-problem and today it looks like we’re in a „too little“ situation.
> > 
> > > why should community maintainers maintain a cookbook? - many. and i dont see the different of this with ruby gem, or any userspace tool (pyhton egg, or a debian in ppa). But the common reasons are: 1) you dont want to reinvent wheel,. if theres no opensource cookbook on ossec, every time i join a place it allows me rapidly roll out ossec cookboook. 2) my job depends on my skills/knowledge, to get a better job, i need to improve my skill. but that not possible if theres no one to mentor inside my own org. opensource brings that possibility. again this is not specific to chef, its very opensource thing, if you dont understand it, or dont know what value you get, dont do it. but for those of us, who are outside chef, uses it, and loves it. exposure is a huge thing, i cant become oracle reporting expert, but i can become chef expert even if dont have much money.
> > 
> > Sorry, but that doesn’t answer my question. Many open source projects start, when something (technology, framework) becomes „hot“. Everyone is trying to learn and get a spot in the eco system. Popularity usually also means a rising number of jobs, e.g. people can get their OSS contribution funded and/or get an interesting job. However this strategy starts to collapse when the crowd moves on to „even hotter“ things (typical hype lifecycle).
> > 
> > Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now outdated npm modules -\> maintainer moved to Go.  
> > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > 
> > This brain-drain affects not only the quantity but also the quality of projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to use it. Experience for new users will suffer.  
> > Why should people contribute to $not\_hot\_anymore projects? I don’t see that many unique chef-jobs, so having something in the GitHub repo/CV doesn’t bring you new opportunities by itself.  
> > Even a popular (\>200 stars on GH) knife plugin for some trending and cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).
> > 
> > possible options:
> > 
> > - provide minimal services that work out of the box by yourself (Chef, Inc)
> > - subsidize community to maintain it (you pay, you decide how)
> > - offer opportunities so people can benefit from supporting the community (e.g. job site, contract projects, sales-partnerships with indies)  
> > otoh: As far as I can see, most „Chef certified partners“ listed on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the community and some companies that provide value to the community are not listed there at all…
> > 
> > > the last statement you made regarding namespace, is a technical problem. again its no different here than any other place. for example redhat has libvirt-lxc which everyone confuses with standard LXC but the project itself has little code/feature compatibility with main LXC. The point is like namespace is perceived, if you want you can publish a cookbook with samename and if its really good (and assuming theres enough people who wants it) you can definitely outweigh the other cookbook. if thats not happening, lets address that.
> > 
> > Your libvirt-example is great, as it shows why nearly nobody used it and why Docker has such a huge impact by just providing a fancy way to distribute tar archives and wrap some syscalls 😉 (oversimplification intentional)  
> > Redhat isn’t very good in community/relationship outside of their own Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and admins. I think better tutorials and community-relations would have prevented that hatery/shitstorm against it.  
> > When I talk to systemd-"haters", I ask them to write me a sysv-init script for a service, then I show them the systemd unit representation.  
> > When ansible users talk to me (chef user), they ask me to write a solution that… whops. damn. You understand what I mean?
> > 
> > > the definition of critical is very diverse, theres no common critical component/cookbook. nothing. 0. as far as the whole community is concerned. if you freeze platform (since chef run from windows machine to raspberry pi to AIX to solaris) you might get a list of critical cookbooks (like sudo will be for linux), you might get another layer on family (like sysdtemd on ubuntu 15.04) .. we are in process of establishing the family specific maintainers, a similar effort can be made for cookbooks as well.. but will be mostly community and few core contributors .. similar to kernel and userspace.. linus and linux foundation or redhat does not maintain ruby specific rpm etc..
> > 
> > Why do people need DevOps? To have a reliable infrastructure to provide services that make money and to stay competitive. Usually that involves more or less custom applications based on common frameworks/stacks that need to be deployed. So at least a couple of application deployment stacks are critical to show the benefits of a DevOps solution. Even the [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest releases of cookbooks used in the tutorial, so this is also a good definition of critical.
> > 
> > > i am very interested in addressing this.. please keep your thoughts pouring 🙂 , but understand we cant solve it in a click, its gonna take some time, we have to keep talking, and out collaborative efforts on the next blockers toward this direction.
> > 
> > > fwiw i am the LT of chef on ubuntu, and i am working on a CD system that will test actual community cookbooks on every master merge of chef. Which will greatly reduce the maintenance burden, cause now core devs can also see what affect the changeset has. Next step will be do a survey and get a list of cookbooks and interested folks (brigade as we calling it) for ubuntu. What i wonder is a common pool might not make sense, though Chef is cross platform, majority of cookbook is not.
> > 
> > You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something like „it installs runit triggered by sysv-init — and it still works…“ on a systemd distro 😉
> > 
> > regards  
> > Roland
> > 
> > PS: Despite all my examples I’m not a systemd zealot. I was okay with upstart… But a common base of various distros is a good thing for everyone in the long run. And it’s also a good example for a game-changer and about the agility/adoption capabilities of such things.
> > 
> > > hth  
> > > ranjib
> > > 
> > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> > > 
> > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > > 
> > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > > 
> > > > > To speak for Chef Software directly, we have always had people on staff  
> > > > > whose role was assisting the creation and maintenance of cookbooks. That  
> > > > > number has fluctuated up and down over time, with the skill sets of people  
> > > > > we hire, and the normal day-to-day ebb and flow of trying to figure out how  
> > > > > to build a business that is successful. We have people on staff today who do  
> > > > > the same. What is clear is that the energy around cookbooks in the community  
> > > > > is far greater than the energy we can muster as an organization (regardless  
> > > > > of how much capital we do or do not have - y'all outnumber us) - and so our  
> > > > > focus today is on trying to build and support the best community we can,  
> > > > > through development of the supermarket, better tooling, and providing a few  
> > > > > key examples of how best to build a community cookbook (see Sean's work on  
> > > > > the httpd cookbook.)
> > > > > 
> > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > 
> > > > Hey Adam,
> > > > 
> > > > Would we consider transferring some of those cookbooks our of  
> > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be  
> > > > the preconditions to doing that?
> > > > 
> > > > Personally I would like the chef-brigade and redguide to be merged,  
> > > > but I do not remember all the players involved -- if they are on this  
> > > > list perhaps they can speak up.
> > > 
> > > How would this prevent the problems that happend with the last migration of former opscode-cookbooks to community maintainers?
> > > 
> > > Why should community maintainers care about the cookbooks in the future?  
> > > It can be a time consuming burden and people need to pay their rent and do their regular jobs…
> > > 
> > > I know, this will be very provoking, but:
> > > 
> > > If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is there still a valid reason for running a public Supermarket site?  
> > > If you go the "libertarian way" there is no reason for a supermarket site to protect/block names of cookbooks anymore that prevents users to pick other, maybe better community resources over legacy-cookbooks that are mentioned in guides and examples.
> > > 
> > > Either you (Chef, Inc.) control the market (e.g. maintain critical things yourself) or you should allow the free market (=community) to compete against each other based on equal opportunity (= namespaces or no supermarket). Everything else/in between will just end in chaos and anarchy.
> > > 
> > > regards  
> > > Roland
> 
> --  
> Yoshi Spendiff  
> Ops Engineer  
> Indochino  
> Mobile: +1 778 952 2025  
> Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![nathwill](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/nathwill/32/25_2.png) [@nathwill](https://discourse.chef.io/u/nathwill)\
**Post date:** [June 25, 2015, 5:19pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/15 "2015-06-25T17:19:15Z")

</div>

On Thu, 2015-06-25 at 09:28 -0700, Ranjib Dey wrote:

> my suggestion for this was to add badges. like foodcritics, chefspec,  
> tk, etc.. quality related badges as well as platform support related  
> badges, and allow consumer to filter by those badges, extend the same  
> worlkflows to knife cookbook download. But that whole thing relies on  
> a build grid that is capable of assigning those badges  
> automatically... also im not sure if this can be applied to all the  
> platforms /scenarios.. but none the less it address some of the  
> issues.  
> i do really like the idea of badges, especially since it's not an all  
> -or-nothing proposition like "compliance", and it's not as subjective  
> as something like a rating system. +1

> On Thu, Jun 25, 2015 at 9:11 AM, Yoshi Spendiff \> [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:
> 
> > An official certification is probably too much to handle but there could be value in stating guidelines that demonstrate how a reliable cookbook is designed and tested. I know Chef doesn't like to prescribe but for the sake of quality a recommended path for some things might be a good idea.\> \>  
> > The reason to maintain a community cookbook is usually because it's relevant to your business/job, which is obviously why cookbooks fall out of repair and only have certain coverage.\> \>  
> > If business 1 makes a cookbook for platform X only and business 2 wants to do the same for platform Y then their options are:\> \> 1. Make a new cookbook for platform X\> \> 2. Fork\> \> 3. Work on a pull request  
> > Having good methods for business 2 to contact business 1 and state their intention could lead to productive collaboration and implementing better ways to find contributors and reviewers of cookbooks could be a good way to help out with this, whether it's business to business or just individual contributors.\> \>  
> > It would also be useful for there to be a mechanism where ownership of stale cookbooks can be transferred, especially now there are groups that are willing to maintain them.\> \>  
> > Finally, better sorting and maybe a rating system on the supermarket for cookbooks would be good. If a cookbook starts out excellent but isn't maintained then many lower reviews will start to drag down the rating.

> > On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz \> \> [rmoriz@gmail.com](mailto:rmoriz@gmail.com)\> \> wrote:

> > > > Am 24.06.2015 um 17:33 schrieb Nathan Williams [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com):
> > > 
> > > > i'd really like to see some official (maybe a BCP Chef RFC?) guidelines for quality based around the BCP guidelines... For example: evaluated with foodcritic and rubocop, integration tested with test-kitchen suites that cover the majority of recipe code-paths (e.g. source vs package install, etc.), unit tested with chefspec, and support for the relevant Chef-supported platforms ([https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md](https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md)).
> > > 
> > > > 
> > > 
> > > > if we then had some application process for Chef Inc to certify a cookbook as complying with the BCP, and we surfaced BCP-compliant cookbooks through Supermarket (with periodic review/recertification), I think we'd be most of the way to victory. This kind of surfacing would help deal with the naming conflict and abandoned cookbook issues we currently have to deal with (the systemd cookbook is a particularly egregious example of name-squatting), and would hopefully encourage community cookbook developers to put in extra effort, knowing that BCP compliance meant better visibility and more adoption.

> > > Let's assume there would be a strong quality regime in place for community cookbooks. Chef, Inc. would actively need to code review and monitor everything except "write the code". I'm not sure if this can work and even make sense. It's like taking over the responsibility ("certified cookbook") without beeing able/willing to intervene when things get bad ("not certified anymore, but out of our scope to fix").

> > > It's also not useful to just increase the pressure for open source developers if you want to keep and even increase the level of community contribution.

> > > This, again, brings up my other concern: Why, at all, maintain a community cookbook?

> > > The vast majority - as far as I can see - is maintained by single developers and/or a single company. The GH issues to PR ration is like 10:1, e.g. it's very time consuming to support, if you take issue reports seriously and also less useful because PR aren't happening frequently and are probably not that useful (If your shop uses Debian X, you just don't care about some PR for CentOS Y that much - and vice versa).

> > > I can fully understand that most OSS cookbook developers don't have time for this, become inactive or just give up. They are getting paid for keeping their employer's (or their own) business up and scaling or don't get paid at all and do this entirely in their spare time.

> > > Nobody can blame them!

> > > Most business are too critical to entirely rely on voluntary time allocation by open source maintainers. If your business is serious, you'll compulsorily have to start in-house maintaining most of the cookbooks over time. Usually this also implies no further contribution back to the ecosystem/upstream/supermarket. [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks) (and OpsWorks in general) is a very good/bad example.

> > > Best case is, that those "hidden" deployments will just stick with the chef patterns of 2010+, worst case they build things that should never ever be done in Chef and Ruby +that+ way… In almost every case, Chef (product) will then be blamed for the eventual desaster, not the team that was not able to adopt the best practices provided by the community and/or Chef, Inc..

> > >

> > > best regards
> > > 
> > > Roland

> > >

> > >

> > >

> > > > anyways, that's my two cents.
> > > 
> > > > 
> > > 
> > > > regards,
> > > 
> > > > 
> > > 
> > > > nathan w
> > > 
> > > > 
> > > 
> > > > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> > > 
> > > > Hi,
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > > 
> > > > >
> > > 
> > > > > yes there is a lot of value with Chef inc, providing a public supermarket instance, it seeds community effort. You dont need it if you consume cookbooks from github or other sources (can be public, can be private/org specific).
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > I don’t think that it seeds community effort, because it’s often a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken, outdated or just be a no-op cookbook that reserves the name:
> > > 
> > > > 
> > > 
> > > > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&platforms%5B%5D=)
> > > 
> > > > 
> > > 
> > > > - number of downloads is irrelevant, as we all know
> > > 
> > > > - follower number is also not a good indication, because even after a year, supermarket did not get the traction of e.g. github
> > > 
> > > > - last release date is probably the best indicator. In my experience most cookbooks that are not updated within the last 12 months are outdated, e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> > > 
> > > > 
> > > 
> > > > Imagine a rather new chef user that needs to deal with systemd unit files. Just with that single „trap" he/she will probably lose a couple of hours or days or give up and pick something else with batteries included.
> > > 
> > > > 
> > > 
> > > > I’m sure this is not intentional and everyone had the best intentions doing it the current way - but IMHO it’s broken :-/
> > > 
> > > > IMHO it’s all about hitting the right spot in between of „too much“ and „too little“ and the original opscode-cookbooks concept was probably a „too much“-problem and today it looks like we’re in a „too little“ situation.
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > > why should community maintainers maintain a cookbook? - many. and i dont see the different of this with ruby gem, or any userspace tool (pyhton egg, or a debian in ppa). But the common reasons are: 1) you dont want to reinvent wheel,. if theres no opensource cookbook on ossec, every time i join a place it allows me rapidly roll out ossec cookboook. 2) my job depends on my skills/knowledge, to get a better job, i need to improve my skill. but that not possible if theres no one to mentor inside my own org. opensource brings that possibility. again this is not specific to chef, its very opensource thing, if you dont understand it, or dont know what value you get, dont do it. but for those of us, who are outside chef, uses it, and loves it. exposure is a huge thing, i cant become oracle reporting expert, but i can become chef expert even if dont have much money.
> > > 
> > > > 
> > > 
> > > > Sorry, but that doesn’t answer my question. Many open source projects start, when something (technology, framework) becomes „hot“. Everyone is trying to learn and get a spot in the eco system. Popularity usually also means a rising number of jobs, e.g. people can get their OSS contribution funded and/or get an interesting job. However this strategy starts to collapse when the crowd moves on to „even hotter“ things (typical hype lifecycle).
> > > 
> > > > 
> > > 
> > > > Example 1: now outdated Ruby gems -\> maintainer moved to node -\> now outdated npm modules -\> maintainer moved to Go.
> > > 
> > > > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > > 
> > > > 
> > > 
> > > > This brain-drain affects not only the quantity but also the quality of projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to use it. Experience for new users will suffer.
> > > 
> > > > Why should people contribute to $not\_hot\_anymore projects? I don’t see that many unique chef-jobs, so having something in the GitHub repo/CV doesn’t bring you new opportunities by itself.
> > > 
> > > > Even a popular (\>200 stars on GH) knife plugin for some trending and cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).
> > > 
> > > > 
> > > 
> > > > possible options:
> > > 
> > > > 
> > > 
> > > > - provide minimal services that work out of the box by yourself (Chef, Inc)
> > > 
> > > > - subsidize community to maintain it (you pay, you decide how)
> > > 
> > > > - offer opportunities so people can benefit from supporting the community (e.g. job site, contract projects, sales-partnerships with indies)
> > > 
> > > > otoh: As far as I can see, most „Chef certified partners“ listed on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of the community and some companies that provide value to the community are not listed there at all…
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > > the last statement you made regarding namespace, is a technical problem. again its no different here than any other place. for example redhat has libvirt-lxc which everyone confuses with standard LXC but the project itself has little code/feature compatibility with main LXC. The point is like namespace is perceived, if you want you can publish a cookbook with samename and if its really good (and assuming theres enough people who wants it) you can definitely outweigh the other cookbook. if thats not happening, lets address that.
> > > 
> > > > 
> > > 
> > > > Your libvirt-example is great, as it shows why nearly nobody used it and why Docker has such a huge impact by just providing a fancy way to distribute tar archives and wrap some syscalls 😉 (oversimplification intentional)
> > > 
> > > > Redhat isn’t very good in community/relationship outside of their own Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and admins. I think better tutorials and community-relations would have prevented that hatery/shitstorm against it.
> > > 
> > > > When I talk to systemd-"haters", I ask them to write me a sysv-init script for a service, then I show them the systemd unit representation.
> > > 
> > > > When ansible users talk to me (chef user), they ask me to write a solution that… whops. damn. You understand what I mean?
> > > 
> > > > 
> > > 
> > > > > the definition of critical is very diverse, theres no common critical component/cookbook. nothing. 0. as far as the whole community is concerned. if you freeze platform (since chef run from windows machine to raspberry pi to AIX to solaris) you might get a list of critical cookbooks (like sudo will be for linux), you might get another layer on family (like sysdtemd on ubuntu 15.04) .. we are in process of establishing the family specific maintainers, a similar effort can be made for cookbooks as well.. but will be mostly community and few core contributors .. similar to kernel and userspace.. linus and linux foundation or redhat does not maintain ruby specific rpm etc..
> > > 
> > > > 
> > > 
> > > > Why do people need DevOps? To have a reliable infrastructure to provide services that make money and to stay competitive. Usually that involves more or less custom applications based on common frameworks/stacks that need to be deployed. So at least a couple of application deployment stacks are critical to show the benefits of a DevOps solution. Even the [learn.chef.io](http://learn.chef.io) tutorial falls apart, when you’re using the latest releases of cookbooks used in the tutorial, so this is also a good definition of critical.
> > > 
> > > > 
> > > 
> > > > > i am very interested in addressing this.. please keep your thoughts pouring 🙂 , but understand we cant solve it in a click, its gonna take some time, we have to keep talking, and out collaborative efforts on the next blockers toward this direction.
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > > fwiw i am the LT of chef on ubuntu, and i am working on a CD system that will test actual community cookbooks on every master merge of chef. Which will greatly reduce the maintenance burden, cause now core devs can also see what affect the changeset has. Next step will be do a survey and get a list of cookbooks and interested folks (brigade as we calling it) for ubuntu. What i wonder is a common pool might not make sense, though Chef is cross platform, majority of cookbook is not.
> > > 
> > > > 
> > > 
> > > > You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something like „it installs runit triggered by sysv-init — and it still works…“ on a systemd distro 😉
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > regards
> > > 
> > > > Roland
> > > 
> > > > 
> > > 
> > > > PS: Despite all my examples I’m not a systemd zealot. I was okay with upstart… But a common base of various distros is a good thing for everyone in the long run. And it’s also a good example for a game-changer and about the agility/adoption capabilities of such things.
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > 
> > > 
> > > > >
> > > 
> > > > >
> > > 
> > > > > hth
> > > 
> > > > > ranjib
> > > 
> > > > >
> > > 
> > > > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com) wrote:
> > > 
> > > > >
> > > 
> > > > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com):
> > > 
> > > > > >
> > > 
> > > > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io) wrote:
> > > 
> > > > > >
> > > 
> > > > > > > To speak for Chef Software directly, we have always had people on staff
> > > 
> > > > > > > whose role was assisting the creation and maintenance of cookbooks. That
> > > 
> > > > > > > number has fluctuated up and down over time, with the skill sets of people
> > > 
> > > > > > > we hire, and the normal day-to-day ebb and flow of trying to figure out how
> > > 
> > > > > > > to build a business that is successful. We have people on staff today who do
> > > 
> > > > > > > the same. What is clear is that the energy around cookbooks in the community
> > > 
> > > > > > > is far greater than the energy we can muster as an organization (regardless
> > > 
> > > > > > > of how much capital we do or do not have - y'all outnumber us) - and so our
> > > 
> > > > > > > focus today is on trying to build and support the best community we can,
> > > 
> > > > > > > through development of the supermarket, better tooling, and providing a few
> > > 
> > > > > > > key examples of how best to build a community cookbook (see Sean's work on
> > > 
> > > > > > > the httpd cookbook.)
> > > 
> > > > > > >
> > > 
> > > > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > 
> > > > > >
> > > 
> > > > > > Hey Adam,
> > > 
> > > > > >
> > > 
> > > > > > Would we consider transferring some of those cookbooks our of
> > > 
> > > > > > {opscode,chef}-cookbooks to a community-organized org like
> > > 
> > > > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide
> > > 
> > > > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What would be
> > > 
> > > > > > the preconditions to doing that?
> > > 
> > > > > >
> > > 
> > > > > > Personally I would like the chef-brigade and redguide to be merged,
> > > 
> > > > > > but I do not remember all the players involved -- if they are on this
> > > 
> > > > > > list perhaps they can speak up.
> > > 
> > > > >
> > > 
> > > > >
> > > 
> > > > > How would this prevent the problems that happend with the last migration of former opscode-cookbooks to community maintainers?
> > > 
> > > > >
> > > 
> > > > > Why should community maintainers care about the cookbooks in the future?
> > > 
> > > > > It can be a time consuming burden and people need to pay their rent and do their regular jobs…
> > > 
> > > > >
> > > 
> > > > > I know, this will be very provoking, but:
> > > 
> > > > >
> > > 
> > > > > If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is there still a valid reason for running a public Supermarket site?
> > > 
> > > > > If you go the "libertarian way" there is no reason for a supermarket site to protect/block names of cookbooks anymore that prevents users to pick other, maybe better community resources over legacy-cookbooks that are mentioned in guides and examples.
> > > 
> > > > >
> > > 
> > > > > Either you (Chef, Inc.) control the market (e.g. maintain critical things yourself) or you should allow the free market (=community) to compete against each other based on equal opportunity (= namespaces or no supermarket). Everything else/in between will just end in chaos and anarchy.
> > > 
> > > > >
> > > 
> > > > > regards
> > > 
> > > > > Roland
> > > 
> > > > >
> > > 
> > > > >

> > >

> >

> > --  
> > Yoshi Spendiff\> \> Ops Engineer  
> > Indochino  
> > Mobile: +1 778 952 2025  
> > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)

> >

>

---

<div class="post-metadata">

**Author:** ![nathwill](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/nathwill/32/25_2.png) [@nathwill](https://discourse.chef.io/u/nathwill)\
**Post date:** [June 25, 2015, 5:25pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/16 "2015-06-25T17:25:35Z")

</div>

On Thu, 2015-06-25 at 09:11 -0700, Yoshi Spendiff wrote:

> An official certification is probably too much to handle but there  
> could be value in stating guidelines that demonstrate how a reliable  
> cookbook is designed and tested. I know Chef doesn't like to  
> prescribe but for the sake of quality a recommended path for some  
> things might be a good idea.

that seems to be changing, though; between the tooling packaged with  
chefdk, and the bundled generators, they're effectively prescribing  
(which is great, please keep it going!) if not overtly doing so.

> The reason to maintain a community cookbook is usually because it's  
> relevant to your business/job, which is obviously why cookbooks fall  
> out of repair and only have certain coverage.
> 
> If business 1 makes a cookbook for platform X only and business 2  
> wants to do the same for platform Y then their options are:
> 
> 1. Make a new cookbook for platform X
> 2. Fork
> 3. Work on a pull request  
> Having good methods for business 2 to contact business 1 and state  
> their intention could lead to productive collaboration and  
> implementing better ways to find contributors and reviewers of  
> cookbooks could be a good way to help out with this, whether it's  
> business to business or just individual contributors.
> 
> It would also be useful for there to be a mechanism where ownership  
> of stale cookbooks can be transferred, especially now there are  
> groups that are willing to maintain them.

have you seen the "adopt me" stuff on supermarket? i think that  
addresses this situation pretty well.

> Finally, better sorting and maybe a rating system on the supermarket  
> for cookbooks would be good. If a cookbook starts out excellent but  
> isn't maintained then many lower reviews will start to drag down the  
> rating.

this'd probably be easier to implement, but it's also very subjective.  
ratings systems are great for popularity, but they often miss the mark  
for quality.

> On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> wrote:
> 
> > > Am 24.06.2015 um 17:33 schrieb Nathan Williams \<  
> > > [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com)\>:  
> > > i'd really like to see some official (maybe a BCP Chef RFC?)  
> > > guidelines for quality based around the BCP guidelines... For  
> > > example: evaluated with foodcritic and rubocop, integration tested  
> > > with test-kitchen suites that cover the majority of recipe code  
> > > -paths (e.g. source vs package install, etc.), unit tested with  
> > > chefspec, and support for the relevant Chef-supported platforms (ht  
> > > tps://github.com/chef/chef-rfc/blob/master/rfc021-platform-support  
> > > -policy.md).
> > > 
> > > if we then had some application process for Chef Inc to certify a  
> > > cookbook as complying with the BCP, and we surfaced BCP-compliant  
> > > cookbooks through Supermarket (with periodic  
> > > review/recertification), I think we'd be most of the way to  
> > > victory. This kind of surfacing would help deal with the naming  
> > > conflict and abandoned cookbook issues we currently have to deal  
> > > with (the systemd cookbook is a particularly egregious example of  
> > > name-squatting), and would hopefully encourage community cookbook  
> > > developers to put in extra effort, knowing that BCP compliance  
> > > meant better visibility and more adoption.
> > 
> > Let's assume there would be a strong quality regime in place for  
> > community cookbooks. Chef, Inc. would actively need to code review  
> > and monitor everything except "write the code". I'm not sure if  
> > this can work and even make sense. It's like taking over the  
> > responsibility ("certified cookbook") without beeing able/willing  
> > to intervene when things get bad ("not certified anymore, but out  
> > of our scope to fix").
> > 
> > It's also not useful to just increase the pressure for open source  
> > developers if you want to keep and even increase the level of  
> > community contribution.
> > 
> > This, again, brings up my other concern: Why, at all, maintain a  
> > community cookbook?
> > 
> > The vast majority - as far as I can see - is maintained by single  
> > developers and/or a single company. The GH issues to PR ration is  
> > like 10:1, e.g. it's very time consuming to support, if you take  
> > issue reports seriously and also less useful because PR aren't  
> > happening frequently and are probably not that useful (If your shop  
> > uses Debian X, you just don't care about some PR for CentOS Y that  
> > much - and vice versa).
> > 
> > I can fully understand that most OSS cookbook developers don't have  
> > time for this, become inactive or just give up. They are getting  
> > paid for keeping their employer's (or their own) business up and  
> > scaling or don't get paid at all and do this entirely in their  
> > spare time.
> > 
> > Nobody can blame them!
> > 
> > Most business are too critical to entirely rely on voluntary time  
> > allocation by open source maintainers. If your business is serious,  
> > you'll compulsorily have to start in-house maintaining most of the  
> > cookbooks over time. Usually this also implies no further  
> > contribution back to the ecosystem/upstream/supermarket.  
> > [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks) (and OpsWorks in general)  
> > is a very good/bad example.
> > 
> > Best case is, that those "hidden" deployments will just stick with  
> > the chef patterns of 2010+, worst case they build things that  
> > should never ever be done in Chef and Ruby +that+ way… In almost  
> > every case, Chef (product) will then be blamed for the eventual  
> > desaster, not the team that was not able to adopt the best  
> > practices provided by the community and/or Chef, Inc..
> > 
> > best regards  
> > Roland
> > 
> > > anyways, that's my two cents.
> > > 
> > > regards,
> > > 
> > > nathan w
> > > 
> > > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > wrote:  
> > > Hi,
> > > 
> > > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com)  
> > > > :
> > > > 
> > > > yes there is a lot of value with Chef inc, providing a public  
> > > > supermarket instance, it seeds community effort. You dont need it  
> > > > if you consume cookbooks from github or other sources (can be  
> > > > public, can be private/org specific).
> > > 
> > > I don’t think that it seeds community effort, because it’s often  
> > > a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may  
> > > be broken, outdated or just be a no-op cookbook that reserves the  
> > > name:
> > > 
> > > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&pl](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&pl)  
> > > atforms%5B%5D=
> > > 
> > > - number of downloads is irrelevant, as we all know
> > > - follower number is also not a good indication, because even  
> > > after a year, supermarket did not get the traction of e.g. github
> > > - last release date is probably the best indicator. In my  
> > > experience most cookbooks that are not updated within the last 12  
> > > months are outdated, e.g. won’t work with the recent distros like  
> > > Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> > > 
> > > Imagine a rather new chef user that needs to deal with systemd  
> > > unit files. Just with that single „trap" he/she will probably lose  
> > > a couple of hours or days or give up and pick something else with  
> > > batteries included.
> > > 
> > > I’m sure this is not intentional and everyone had the best  
> > > intentions doing it the current way - but IMHO it’s broken :-/  
> > > IMHO it’s all about hitting the right spot in between of „too  
> > > much“ and „too little“ and the original opscode-cookbooks concept  
> > > was probably a „too much“-problem and today it looks like we’re in  
> > > a „too little“ situation.
> > > 
> > > > why should community maintainers maintain a cookbook? - many.  
> > > > and i dont see the different of this with ruby gem, or any  
> > > > userspace tool (pyhton egg, or a debian in ppa). But the common  
> > > > reasons are: 1) you dont want to reinvent wheel,. if theres no  
> > > > opensource cookbook on ossec, every time i join a place it allows  
> > > > me rapidly roll out ossec cookboook. 2) my job depends on my  
> > > > skills/knowledge, to get a better job, i need to improve my skill.  
> > > > but that not possible if theres no one to mentor inside my own org.  
> > > > opensource brings that possibility. again this is not specific to  
> > > > chef, its very opensource thing, if you dont understand it, or dont  
> > > > know what value you get, dont do it. but for those of us, who are  
> > > > outside chef, uses it, and loves it. exposure is a huge thing, i  
> > > > cant become oracle reporting expert, but i can become chef expert  
> > > > even if dont have much money.
> > > 
> > > Sorry, but that doesn’t answer my question. Many open source  
> > > projects start, when something (technology, framework) becomes  
> > > „hot“. Everyone is trying to learn and get a spot in the eco  
> > > system. Popularity usually also means a rising number of jobs, e.g.  
> > > people can get their OSS contribution funded and/or get an  
> > > interesting job. However this strategy starts to collapse when the  
> > > crowd moves on to „even hotter“ things (typical hype lifecycle).
> > > 
> > > Example 1: now outdated Ruby gems -\> maintainer moved to node -\>  
> > > now outdated npm modules -\> maintainer moved to Go.  
> > > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > > 
> > > This brain-drain affects not only the quantity but also the  
> > > quality of projects. Less „eyes“ to find bugs, less „hands“ to fix  
> > > them, less users to use it. Experience for new users will suffer.  
> > > Why should people contribute to $not\_hot\_anymore projects? I  
> > > don’t see that many unique chef-jobs, so having something in the  
> > > GitHub repo/CV doesn’t bring you new opportunities by itself.  
> > > Even a popular (\>200 stars on GH) knife plugin for some trending  
> > > and cheap cloud hosting provider brings you exactly 0 job/project  
> > > offers (btdt).
> > > 
> > > possible options:
> > > 
> > > - provide minimal services that work out of the box by yourself  
> > > (Chef, Inc)
> > > - subsidize community to maintain it (you pay, you decide how)
> > > - offer opportunities so people can benefit from supporting the  
> > > community (e.g. job site, contract projects, sales-partnerships  
> > > with indies)  
> > > otoh: As far as I can see, most „Chef certified partners“  
> > > listed on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not  
> > > part of the community and some companies that provide value to the  
> > > community are not listed there at all…
> > > 
> > > > the last statement you made regarding namespace, is a technical  
> > > > problem. again its no different here than any other place. for  
> > > > example redhat has libvirt-lxc which everyone confuses with  
> > > > standard LXC but the project itself has little code/feature  
> > > > compatibility with main LXC. The point is like namespace is  
> > > > perceived, if you want you can publish a cookbook with samename and  
> > > > if its really good (and assuming theres enough people who wants it)  
> > > > you can definitely outweigh the other cookbook. if thats not  
> > > > happening, lets address that.
> > > 
> > > Your libvirt-example is great, as it shows why nearly nobody used  
> > > it and why Docker has such a huge impact by just providing a fancy  
> > > way to distribute tar archives and wrap some syscalls 😉  
> > > (oversimplification intentional)  
> > > Redhat isn’t very good in community/relationship outside of  
> > > their own Fedora/RHEL area. Just see how they „sell“ systemd to  
> > > users, developers and admins. I think better tutorials and  
> > > community-relations would have prevented that hatery/shitstorm  
> > > against it.  
> > > When I talk to systemd-"haters", I ask them to write me a sysv  
> > > -init script for a service, then I show them the systemd unit  
> > > representation.  
> > > When ansible users talk to me (chef user), they ask me to write a  
> > > solution that… whops. damn. You understand what I mean?
> > > 
> > > > the definition of critical is very diverse, theres no common  
> > > > critical component/cookbook. nothing. 0. as far as the whole  
> > > > community is concerned. if you freeze platform (since chef run  
> > > > from windows machine to raspberry pi to AIX to solaris) you might  
> > > > get a list of critical cookbooks (like sudo will be for linux), you  
> > > > might get another layer on family (like sysdtemd on ubuntu 15.04)  
> > > > .. we are in process of establishing the family specific  
> > > > maintainers, a similar effort can be made for cookbooks as well..  
> > > > but will be mostly community and few core contributors .. similar  
> > > > to kernel and userspace.. linus and linux foundation or redhat  
> > > > does not maintain ruby specific rpm etc..
> > > 
> > > Why do people need DevOps? To have a reliable infrastructure to  
> > > provide services that make money and to stay competitive. Usually  
> > > that involves more or less custom applications based on common  
> > > frameworks/stacks that need to be deployed. So at least a couple of  
> > > application deployment stacks are critical to show the benefits of  
> > > a DevOps solution. Even the [learn.chef.io](http://learn.chef.io) tutorial falls apart,  
> > > when you’re using the latest releases of cookbooks used in the  
> > > tutorial, so this is also a good definition of critical.
> > > 
> > > > i am very interested in addressing this.. please keep your  
> > > > thoughts pouring 🙂 , but understand we cant solve it in a click,  
> > > > its gonna take some time, we have to keep talking, and out  
> > > > collaborative efforts on the next blockers toward this direction.
> > > 
> > > > fwiw i am the LT of chef on ubuntu, and i am working on a CD  
> > > > system that will test actual community cookbooks on every master  
> > > > merge of chef. Which will greatly reduce the maintenance burden,  
> > > > cause now core devs can also see what affect the changeset has.  
> > > > Next step will be do a survey and get a list of cookbooks and  
> > > > interested folks (brigade as we calling it) for ubuntu. What i  
> > > > wonder is a common pool might not make sense, though Chef is cross  
> > > > platform, majority of cookbook is not.
> > > 
> > > You don’t need a fancy distro/edge-case. Just make sure Debian 8,  
> > > RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t  
> > > mean something like „it installs runit triggered by sysv-init — and  
> > > it still works…“ on a systemd distro 😉
> > > 
> > > regards  
> > > Roland
> > > 
> > > PS: Despite all my examples I’m not a systemd zealot. I was okay  
> > > with upstart… But a common base of various distros is a good thing  
> > > for everyone in the long run. And it’s also a good example for a  
> > > game-changer and about the agility/adoption capabilities of such  
> > > things.
> > > 
> > > > hth  
> > > > ranjib
> > > > 
> > > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > > wrote:
> > > > 
> > > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn \<  
> > > > > [jdunn@aquezada.com](mailto:jdunn@aquezada.com)\>:
> > > > > 
> > > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io)  
> > > > > wrote:
> > > > > 
> > > > > > To speak for Chef Software directly, we have always had  
> > > > > > people on staff  
> > > > > > whose role was assisting the creation and maintenance of  
> > > > > > cookbooks. That  
> > > > > > number has fluctuated up and down over time, with the skill  
> > > > > > sets of people  
> > > > > > we hire, and the normal day-to-day ebb and flow of trying to  
> > > > > > figure out how  
> > > > > > to build a business that is successful. We have people on  
> > > > > > staff today who do  
> > > > > > the same. What is clear is that the energy around cookbooks  
> > > > > > in the community  
> > > > > > is far greater than the energy we can muster as an  
> > > > > > organization (regardless  
> > > > > > of how much capital we do or do not have - y'all outnumber  
> > > > > > us) - and so our  
> > > > > > focus today is on trying to build and support the best  
> > > > > > community we can,  
> > > > > > through development of the supermarket, better tooling, and  
> > > > > > providing a few  
> > > > > > key examples of how best to build a community cookbook (see  
> > > > > > Sean's work on  
> > > > > > the httpd cookbook.)
> > > > > > 
> > > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > > 
> > > > > Hey Adam,
> > > > > 
> > > > > Would we consider transferring some of those cookbooks our of  
> > > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What  
> > > > > would be  
> > > > > the preconditions to doing that?
> > > > > 
> > > > > Personally I would like the chef-brigade and redguide to be  
> > > > > merged,  
> > > > > but I do not remember all the players involved -- if they are  
> > > > > on this  
> > > > > list perhaps they can speak up.
> > > > 
> > > > How would this prevent the problems that happend with the last  
> > > > migration of former opscode-cookbooks to community maintainers?
> > > > 
> > > > Why should community maintainers care about the cookbooks in the  
> > > > future?  
> > > > It can be a time consuming burden and people need to pay their  
> > > > rent and do their regular jobs…
> > > > 
> > > > I know, this will be very provoking, but:
> > > > 
> > > > If Chef, inc. doesn't want to maintain even critical cookbooks  
> > > > anymore, is there still a valid reason for running a public  
> > > > Supermarket site?  
> > > > If you go the "libertarian way" there is no reason for a  
> > > > supermarket site to protect/block names of cookbooks anymore that  
> > > > prevents users to pick other, maybe better community resources over  
> > > > legacy-cookbooks that are mentioned in guides and examples.
> > > > 
> > > > Either you (Chef, Inc.) control the market (e.g. maintain  
> > > > critical things yourself) or you should allow the free market  
> > > > (=community) to compete against each other based on equal  
> > > > opportunity (= namespaces or no supermarket). Everything else/in  
> > > > between will just end in chaos and anarchy.
> > > > 
> > > > regards  
> > > > Roland

---

<div class="post-metadata">

**Author:** ![David\_Joos](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/david_joos/32/41_2.png) [@David\_Joos](https://discourse.chef.io/u/David_Joos)\
**Post date:** [June 25, 2015, 5:32pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/17 "2015-06-25T17:32:17Z")

</div>

> this'd probably be easier to implement, but it's also very subjective.  
> ratings systems are great for popularity, but they often miss the mark  
> for quality.

Yeah, I think that is also the reason why when the transition was made from  
the old "Chef community cookbooks"-catalog to the current "Chef  
Supermarket", the option to rate cookbooks was ditched.

+1 for the idea of badges though

2015-06-25 18:25 GMT+01:00 Nathan Williams [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com):

> On Thu, 2015-06-25 at 09:11 -0700, Yoshi Spendiff wrote:
> 
> > An official certification is probably too much to handle but there  
> > could be value in stating guidelines that demonstrate how a reliable  
> > cookbook is designed and tested. I know Chef doesn't like to  
> > prescribe but for the sake of quality a recommended path for some  
> > things might be a good idea.
> 
> that seems to be changing, though; between the tooling packaged with  
> chefdk, and the bundled generators, they're effectively prescribing  
> (which is great, please keep it going!) if not overtly doing so.
> 
> > The reason to maintain a community cookbook is usually because it's  
> > relevant to your business/job, which is obviously why cookbooks fall  
> > out of repair and only have certain coverage.
> > 
> > If business 1 makes a cookbook for platform X only and business 2  
> > wants to do the same for platform Y then their options are:
> > 
> > 1. Make a new cookbook for platform X
> > 2. Fork
> > 3. Work on a pull request  
> > Having good methods for business 2 to contact business 1 and state  
> > their intention could lead to productive collaboration and  
> > implementing better ways to find contributors and reviewers of  
> > cookbooks could be a good way to help out with this, whether it's  
> > business to business or just individual contributors.
> > 
> > It would also be useful for there to be a mechanism where ownership  
> > of stale cookbooks can be transferred, especially now there are  
> > groups that are willing to maintain them.
> 
> have you seen the "adopt me" stuff on supermarket? i think that  
> addresses this situation pretty well.
> 
> > Finally, better sorting and maybe a rating system on the supermarket  
> > for cookbooks would be good. If a cookbook starts out excellent but  
> > isn't maintained then many lower reviews will start to drag down the  
> > rating.
> 
> this'd probably be easier to implement, but it's also very subjective.  
> ratings systems are great for popularity, but they often miss the mark  
> for quality.
> 
> > On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > wrote:
> > 
> > > > Am 24.06.2015 um 17:33 schrieb Nathan Williams \<  
> > > > [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com)\>:  
> > > > i'd really like to see some official (maybe a BCP Chef RFC?)  
> > > > guidelines for quality based around the BCP guidelines... For  
> > > > example: evaluated with foodcritic and rubocop, integration tested  
> > > > with test-kitchen suites that cover the majority of recipe code  
> > > > -paths (e.g. source vs package install, etc.), unit tested with  
> > > > chefspec, and support for the relevant Chef-supported platforms (ht  
> > > > tps://github.com/chef/chef-rfc/blob/master/rfc021-platform-support  
> > > > -policy.md).
> > > > 
> > > > if we then had some application process for Chef Inc to certify a  
> > > > cookbook as complying with the BCP, and we surfaced BCP-compliant  
> > > > cookbooks through Supermarket (with periodic  
> > > > review/recertification), I think we'd be most of the way to  
> > > > victory. This kind of surfacing would help deal with the naming  
> > > > conflict and abandoned cookbook issues we currently have to deal  
> > > > with (the systemd cookbook is a particularly egregious example of  
> > > > name-squatting), and would hopefully encourage community cookbook  
> > > > developers to put in extra effort, knowing that BCP compliance  
> > > > meant better visibility and more adoption.
> > > 
> > > Let's assume there would be a strong quality regime in place for  
> > > community cookbooks. Chef, Inc. would actively need to code review  
> > > and monitor everything except "write the code". I'm not sure if  
> > > this can work and even make sense. It's like taking over the  
> > > responsibility ("certified cookbook") without beeing able/willing  
> > > to intervene when things get bad ("not certified anymore, but out  
> > > of our scope to fix").
> > > 
> > > It's also not useful to just increase the pressure for open source  
> > > developers if you want to keep and even increase the level of  
> > > community contribution.
> > > 
> > > This, again, brings up my other concern: Why, at all, maintain a  
> > > community cookbook?
> > > 
> > > The vast majority - as far as I can see - is maintained by single  
> > > developers and/or a single company. The GH issues to PR ration is  
> > > like 10:1, e.g. it's very time consuming to support, if you take  
> > > issue reports seriously and also less useful because PR aren't  
> > > happening frequently and are probably not that useful (If your shop  
> > > uses Debian X, you just don't care about some PR for CentOS Y that  
> > > much - and vice versa).
> > > 
> > > I can fully understand that most OSS cookbook developers don't have  
> > > time for this, become inactive or just give up. They are getting  
> > > paid for keeping their employer's (or their own) business up and  
> > > scaling or don't get paid at all and do this entirely in their  
> > > spare time.
> > > 
> > > Nobody can blame them!
> > > 
> > > Most business are too critical to entirely rely on voluntary time  
> > > allocation by open source maintainers. If your business is serious,  
> > > you'll compulsorily have to start in-house maintaining most of the  
> > > cookbooks over time. Usually this also implies no further  
> > > contribution back to the ecosystem/upstream/supermarket.  
> > > [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks) (and OpsWorks in general)  
> > > is a very good/bad example.
> > > 
> > > Best case is, that those "hidden" deployments will just stick with  
> > > the chef patterns of 2010+, worst case they build things that  
> > > should never ever be done in Chef and Ruby +that+ way… In almost  
> > > every case, Chef (product) will then be blamed for the eventual  
> > > desaster, not the team that was not able to adopt the best  
> > > practices provided by the community and/or Chef, Inc..
> > > 
> > > best regards  
> > > Roland
> > > 
> > > > anyways, that's my two cents.
> > > > 
> > > > regards,
> > > > 
> > > > nathan w
> > > > 
> > > > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > > wrote:  
> > > > Hi,
> > > > 
> > > > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com)  
> > > > > :
> > > > > 
> > > > > yes there is a lot of value with Chef inc, providing a public  
> > > > > supermarket instance, it seeds community effort. You dont need it  
> > > > > if you consume cookbooks from github or other sources (can be  
> > > > > public, can be private/org specific).
> > > > 
> > > > I don’t think that it seeds community effort, because it’s often  
> > > > a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may  
> > > > be broken, outdated or just be a no-op cookbook that reserves the  
> > > > name:
> > > > 
> > > > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&pl](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&pl)  
> > > > atforms%5B%5D=
> > > > 
> > > > - number of downloads is irrelevant, as we all know
> > > > - follower number is also not a good indication, because even  
> > > > after a year, supermarket did not get the traction of e.g. github
> > > > - last release date is probably the best indicator. In my  
> > > > experience most cookbooks that are not updated within the last 12  
> > > > months are outdated, e.g. won’t work with the recent distros like  
> > > > Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> > > > 
> > > > Imagine a rather new chef user that needs to deal with systemd  
> > > > unit files. Just with that single „trap" he/she will probably lose  
> > > > a couple of hours or days or give up and pick something else with  
> > > > batteries included.
> > > > 
> > > > I’m sure this is not intentional and everyone had the best  
> > > > intentions doing it the current way - but IMHO it’s broken :-/  
> > > > IMHO it’s all about hitting the right spot in between of „too  
> > > > much“ and „too little“ and the original opscode-cookbooks concept  
> > > > was probably a „too much“-problem and today it looks like we’re in  
> > > > a „too little“ situation.
> > > > 
> > > > > why should community maintainers maintain a cookbook? - many.  
> > > > > and i dont see the different of this with ruby gem, or any  
> > > > > userspace tool (pyhton egg, or a debian in ppa). But the common  
> > > > > reasons are: 1) you dont want to reinvent wheel,. if theres no  
> > > > > opensource cookbook on ossec, every time i join a place it allows  
> > > > > me rapidly roll out ossec cookboook. 2) my job depends on my  
> > > > > skills/knowledge, to get a better job, i need to improve my skill.  
> > > > > but that not possible if theres no one to mentor inside my own org.  
> > > > > opensource brings that possibility. again this is not specific to  
> > > > > chef, its very opensource thing, if you dont understand it, or dont  
> > > > > know what value you get, dont do it. but for those of us, who are  
> > > > > outside chef, uses it, and loves it. exposure is a huge thing, i  
> > > > > cant become oracle reporting expert, but i can become chef expert  
> > > > > even if dont have much money.
> > > > 
> > > > Sorry, but that doesn’t answer my question. Many open source  
> > > > projects start, when something (technology, framework) becomes  
> > > > „hot“. Everyone is trying to learn and get a spot in the eco  
> > > > system. Popularity usually also means a rising number of jobs, e.g.  
> > > > people can get their OSS contribution funded and/or get an  
> > > > interesting job. However this strategy starts to collapse when the  
> > > > crowd moves on to „even hotter“ things (typical hype lifecycle).
> > > > 
> > > > Example 1: now outdated Ruby gems -\> maintainer moved to node -\>  
> > > > now outdated npm modules -\> maintainer moved to Go.  
> > > > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > > > 
> > > > This brain-drain affects not only the quantity but also the  
> > > > quality of projects. Less „eyes“ to find bugs, less „hands“ to fix  
> > > > them, less users to use it. Experience for new users will suffer.  
> > > > Why should people contribute to $not\_hot\_anymore projects? I  
> > > > don’t see that many unique chef-jobs, so having something in the  
> > > > GitHub repo/CV doesn’t bring you new opportunities by itself.  
> > > > Even a popular (\>200 stars on GH) knife plugin for some trending  
> > > > and cheap cloud hosting provider brings you exactly 0 job/project  
> > > > offers (btdt).
> > > > 
> > > > possible options:
> > > > 
> > > > - provide minimal services that work out of the box by yourself  
> > > > (Chef, Inc)
> > > > - subsidize community to maintain it (you pay, you decide how)
> > > > - offer opportunities so people can benefit from supporting the  
> > > > community (e.g. job site, contract projects, sales-partnerships  
> > > > with indies)  
> > > > otoh: As far as I can see, most „Chef certified partners“  
> > > > listed on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not  
> > > > part of the community and some companies that provide value to the  
> > > > community are not listed there at all…
> > > > 
> > > > > the last statement you made regarding namespace, is a technical  
> > > > > problem. again its no different here than any other place. for  
> > > > > example redhat has libvirt-lxc which everyone confuses with  
> > > > > standard LXC but the project itself has little code/feature  
> > > > > compatibility with main LXC. The point is like namespace is  
> > > > > perceived, if you want you can publish a cookbook with samename and  
> > > > > if its really good (and assuming theres enough people who wants it)  
> > > > > you can definitely outweigh the other cookbook. if thats not  
> > > > > happening, lets address that.
> > > > 
> > > > Your libvirt-example is great, as it shows why nearly nobody used  
> > > > it and why Docker has such a huge impact by just providing a fancy  
> > > > way to distribute tar archives and wrap some syscalls 😉  
> > > > (oversimplification intentional)  
> > > > Redhat isn’t very good in community/relationship outside of  
> > > > their own Fedora/RHEL area. Just see how they „sell“ systemd to  
> > > > users, developers and admins. I think better tutorials and  
> > > > community-relations would have prevented that hatery/shitstorm  
> > > > against it.  
> > > > When I talk to systemd-"haters", I ask them to write me a sysv  
> > > > -init script for a service, then I show them the systemd unit  
> > > > representation.  
> > > > When ansible users talk to me (chef user), they ask me to write a  
> > > > solution that… whops. damn. You understand what I mean?
> > > > 
> > > > > the definition of critical is very diverse, theres no common  
> > > > > critical component/cookbook. nothing. 0. as far as the whole  
> > > > > community is concerned. if you freeze platform (since chef run  
> > > > > from windows machine to raspberry pi to AIX to solaris) you might  
> > > > > get a list of critical cookbooks (like sudo will be for linux), you  
> > > > > might get another layer on family (like sysdtemd on ubuntu 15.04)  
> > > > > .. we are in process of establishing the family specific  
> > > > > maintainers, a similar effort can be made for cookbooks as well..  
> > > > > but will be mostly community and few core contributors .. similar  
> > > > > to kernel and userspace.. linus and linux foundation or redhat  
> > > > > does not maintain ruby specific rpm etc..
> > > > 
> > > > Why do people need DevOps? To have a reliable infrastructure to  
> > > > provide services that make money and to stay competitive. Usually  
> > > > that involves more or less custom applications based on common  
> > > > frameworks/stacks that need to be deployed. So at least a couple of  
> > > > application deployment stacks are critical to show the benefits of  
> > > > a DevOps solution. Even the [learn.chef.io](http://learn.chef.io) tutorial falls apart,  
> > > > when you’re using the latest releases of cookbooks used in the  
> > > > tutorial, so this is also a good definition of critical.
> > > > 
> > > > > i am very interested in addressing this.. please keep your  
> > > > > thoughts pouring 🙂 , but understand we cant solve it in a click,  
> > > > > its gonna take some time, we have to keep talking, and out  
> > > > > collaborative efforts on the next blockers toward this direction.
> > > > 
> > > > > fwiw i am the LT of chef on ubuntu, and i am working on a CD  
> > > > > system that will test actual community cookbooks on every master  
> > > > > merge of chef. Which will greatly reduce the maintenance burden,  
> > > > > cause now core devs can also see what affect the changeset has.  
> > > > > Next step will be do a survey and get a list of cookbooks and  
> > > > > interested folks (brigade as we calling it) for ubuntu. What i  
> > > > > wonder is a common pool might not make sense, though Chef is cross  
> > > > > platform, majority of cookbook is not.
> > > > 
> > > > You don’t need a fancy distro/edge-case. Just make sure Debian 8,  
> > > > RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t  
> > > > mean something like „it installs runit triggered by sysv-init — and  
> > > > it still works…“ on a systemd distro 😉
> > > > 
> > > > regards  
> > > > Roland
> > > > 
> > > > PS: Despite all my examples I’m not a systemd zealot. I was okay  
> > > > with upstart… But a common base of various distros is a good thing  
> > > > for everyone in the long run. And it’s also a good example for a  
> > > > game-changer and about the agility/adoption capabilities of such  
> > > > things.
> > > > 
> > > > > hth  
> > > > > ranjib
> > > > > 
> > > > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > > > wrote:
> > > > > 
> > > > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn \<  
> > > > > > [jdunn@aquezada.com](mailto:jdunn@aquezada.com)\>:
> > > > > > 
> > > > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io)  
> > > > > > wrote:
> > > > > > 
> > > > > > > To speak for Chef Software directly, we have always had  
> > > > > > > people on staff  
> > > > > > > whose role was assisting the creation and maintenance of  
> > > > > > > cookbooks. That  
> > > > > > > number has fluctuated up and down over time, with the skill  
> > > > > > > sets of people  
> > > > > > > we hire, and the normal day-to-day ebb and flow of trying to  
> > > > > > > figure out how  
> > > > > > > to build a business that is successful. We have people on  
> > > > > > > staff today who do  
> > > > > > > the same. What is clear is that the energy around cookbooks  
> > > > > > > in the community  
> > > > > > > is far greater than the energy we can muster as an  
> > > > > > > organization (regardless  
> > > > > > > of how much capital we do or do not have - y'all outnumber  
> > > > > > > us) - and so our  
> > > > > > > focus today is on trying to build and support the best  
> > > > > > > community we can,  
> > > > > > > through development of the supermarket, better tooling, and  
> > > > > > > providing a few  
> > > > > > > key examples of how best to build a community cookbook (see  
> > > > > > > Sean's work on  
> > > > > > > the httpd cookbook.)
> > > > > > > 
> > > > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > > > 
> > > > > > Hey Adam,
> > > > > > 
> > > > > > Would we consider transferring some of those cookbooks our of  
> > > > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What  
> > > > > > would be  
> > > > > > the preconditions to doing that?
> > > > > > 
> > > > > > Personally I would like the chef-brigade and redguide to be  
> > > > > > merged,  
> > > > > > but I do not remember all the players involved -- if they are  
> > > > > > on this  
> > > > > > list perhaps they can speak up.
> > > > > 
> > > > > How would this prevent the problems that happend with the last  
> > > > > migration of former opscode-cookbooks to community maintainers?
> > > > > 
> > > > > Why should community maintainers care about the cookbooks in the  
> > > > > future?  
> > > > > It can be a time consuming burden and people need to pay their  
> > > > > rent and do their regular jobs…
> > > > > 
> > > > > I know, this will be very provoking, but:
> > > > > 
> > > > > If Chef, inc. doesn't want to maintain even critical cookbooks  
> > > > > anymore, is there still a valid reason for running a public  
> > > > > Supermarket site?  
> > > > > If you go the "libertarian way" there is no reason for a  
> > > > > supermarket site to protect/block names of cookbooks anymore that  
> > > > > prevents users to pick other, maybe better community resources over  
> > > > > legacy-cookbooks that are mentioned in guides and examples.
> > > > > 
> > > > > Either you (Chef, Inc.) control the market (e.g. maintain  
> > > > > critical things yourself) or you should allow the free market  
> > > > > (=community) to compete against each other based on equal  
> > > > > opportunity (= namespaces or no supermarket). Everything else/in  
> > > > > between will just end in chaos and anarchy.
> > > > > 
> > > > > regards  
> > > > > Roland

---

<div class="post-metadata">

**Author:** ![Fitzwater\_Brian\_K\_CT](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/fitzwater_brian_k_ct/32/45_2.png) [@Fitzwater\_Brian\_K\_CT](https://discourse.chef.io/u/Fitzwater_Brian_K_CT)\
**Post date:** [June 25, 2015, 5:34pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/18 "2015-06-25T17:34:14Z")

</div>

On Thu, 2015-06-25 at 13:26 -0400, Nathan Williams wrote:

> ratings systems are great for popularity, but they often miss the mark for quality.

> **[TornadoGuard](https://xkcd.com/937/)**
>
> The bug report was marked 'could not reproduce'.

---

<div class="post-metadata">

**Author:** ![Trevor\_Hess](https://avatars.discourse-cdn.com/v4/letter/t/d2c977/32.png) [@Trevor\_Hess](https://discourse.chef.io/u/Trevor_Hess)\
**Post date:** [June 25, 2015, 5:41pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/19 "2015-06-25T17:41:21Z")

</div>

What about an upvote/downvote system? It can be abused too, but what if a downvote required a linked issue on the repository?  
Then badges could be related to the way a maintainer responds to issues?

--  
T

From: David Joos [[mailto:david.joos@gmail.com](mailto:david.joos@gmail.com)]  
Sent: Thursday, June 25, 2015 12:32 PM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Subject: [chef] Re: Re: Re: Re: Community cookbook maintenance (was: Re: Reprepro cookbook)

> this'd probably be easier to implement, but it's also very subjective.  
> ratings systems are great for popularity, but they often miss the mark  
> for quality.

Yeah, I think that is also the reason why when the transition was made from the old "Chef community cookbooks"-catalog to the current "Chef Supermarket", the option to rate cookbooks was ditched.

+1 for the idea of badges though

2015-06-25 18:25 GMT+01:00 Nathan Williams \<[nath.e.will@gmail.com](mailto:nath.e.will@gmail.com)[mailto:nath.e.will@gmail.com](mailto:nath.e.will@gmail.com)\>:  
On Thu, 2015-06-25 at 09:11 -0700, Yoshi Spendiff wrote:

> An official certification is probably too much to handle but there  
> could be value in stating guidelines that demonstrate how a reliable  
> cookbook is designed and tested. I know Chef doesn't like to  
> prescribe but for the sake of quality a recommended path for some  
> things might be a good idea.

that seems to be changing, though; between the tooling packaged with  
chefdk, and the bundled generators, they're effectively prescribing  
(which is great, please keep it going!) if not overtly doing so.

> The reason to maintain a community cookbook is usually because it's  
> relevant to your business/job, which is obviously why cookbooks fall  
> out of repair and only have certain coverage.
> 
> If business 1 makes a cookbook for platform X only and business 2  
> wants to do the same for platform Y then their options are:
> 
> 1. Make a new cookbook for platform X
> 2. Fork
> 3. Work on a pull request  
> Having good methods for business 2 to contact business 1 and state  
> their intention could lead to productive collaboration and  
> implementing better ways to find contributors and reviewers of  
> cookbooks could be a good way to help out with this, whether it's  
> business to business or just individual contributors.
> 
> It would also be useful for there to be a mechanism where ownership  
> of stale cookbooks can be transferred, especially now there are  
> groups that are willing to maintain them.

have you seen the "adopt me" stuff on supermarket? i think that  
addresses this situation pretty well.

> Finally, better sorting and maybe a rating system on the supermarket  
> for cookbooks would be good. If a cookbook starts out excellent but  
> isn't maintained then many lower reviews will start to drag down the  
> rating.

this'd probably be easier to implement, but it's also very subjective.  
ratings systems are great for popularity, but they often miss the mark  
for quality.

> On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz \<[rmoriz@gmail.com](mailto:rmoriz@gmail.com)[mailto:rmoriz@gmail.com](mailto:rmoriz@gmail.com)\>  
> wrote:
> 
> > > Am 24.06.2015 um 17:33 schrieb Nathan Williams \<  
> > > [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com)[mailto:nath.e.will@gmail.com](mailto:nath.e.will@gmail.com)\>:  
> > > i'd really like to see some official (maybe a BCP Chef RFC?)  
> > > guidelines for quality based around the BCP guidelines... For  
> > > example: evaluated with foodcritic and rubocop, integration tested  
> > > with test-kitchen suites that cover the majority of recipe code  
> > > -paths (e.g. source vs package install, etc.), unit tested with  
> > > chefspec, and support for the relevant Chef-supported platforms (ht  
> > > tps://github.com/chef/chef-rfc/blob/master/rfc021-platform-support[http://github.com/chef/chef-rfc/blob/master/rfc021-platform-support](http://github.com/chef/chef-rfc/blob/master/rfc021-platform-support)  
> > > -policy.md[http://policy.md](http://policy.md)).
> > > 
> > > if we then had some application process for Chef Inc to certify a  
> > > cookbook as complying with the BCP, and we surfaced BCP-compliant  
> > > cookbooks through Supermarket (with periodic  
> > > review/recertification), I think we'd be most of the way to  
> > > victory. This kind of surfacing would help deal with the naming  
> > > conflict and abandoned cookbook issues we currently have to deal  
> > > with (the systemd cookbook is a particularly egregious example of  
> > > name-squatting), and would hopefully encourage community cookbook  
> > > developers to put in extra effort, knowing that BCP compliance  
> > > meant better visibility and more adoption.
> > 
> > Let's assume there would be a strong quality regime in place for  
> > community cookbooks. Chef, Inc. would actively need to code review  
> > and monitor everything except "write the code". I'm not sure if  
> > this can work and even make sense. It's like taking over the  
> > responsibility ("certified cookbook") without beeing able/willing  
> > to intervene when things get bad ("not certified anymore, but out  
> > of our scope to fix").
> > 
> > It's also not useful to just increase the pressure for open source  
> > developers if you want to keep and even increase the level of  
> > community contribution.
> > 
> > This, again, brings up my other concern: Why, at all, maintain a  
> > community cookbook?
> > 
> > The vast majority - as far as I can see - is maintained by single  
> > developers and/or a single company. The GH issues to PR ration is  
> > like 10:1, e.g. it's very time consuming to support, if you take  
> > issue reports seriously and also less useful because PR aren't  
> > happening frequently and are probably not that useful (If your shop  
> > uses Debian X, you just don't care about some PR for CentOS Y that  
> > much - and vice versa).
> > 
> > I can fully understand that most OSS cookbook developers don't have  
> > time for this, become inactive or just give up. They are getting  
> > paid for keeping their employer's (or their own) business up and  
> > scaling or don't get paid at all and do this entirely in their  
> > spare time.
> > 
> > Nobody can blame them!
> > 
> > Most business are too critical to entirely rely on voluntary time  
> > allocation by open source maintainers. If your business is serious,  
> > you'll compulsorily have to start in-house maintaining most of the  
> > cookbooks over time. Usually this also implies no further  
> > contribution back to the ecosystem/upstream/supermarket.  
> > [GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service](https://github.com/aws/opsworks-cookbooks) (and OpsWorks in general)  
> > is a very good/bad example.
> > 
> > Best case is, that those "hidden" deployments will just stick with  
> > the chef patterns of 2010+, worst case they build things that  
> > should never ever be done in Chef and Ruby +that+ way… In almost  
> > every case, Chef (product) will then be blamed for the eventual  
> > desaster, not the team that was not able to adopt the best  
> > practices provided by the community and/or Chef, Inc..
> > 
> > best regards  
> > Roland
> > 
> > > anyways, that's my two cents.
> > > 
> > > regards,
> > > 
> > > nathan w
> > > 
> > > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz \<[rmoriz@gmail.com](mailto:rmoriz@gmail.com)[mailto:rmoriz@gmail.com](mailto:rmoriz@gmail.com)\>  
> > > wrote:  
> > > Hi,
> > > 
> > > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey \<[dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com)[mailto:dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com)\>  
> > > > :
> > > > 
> > > > yes there is a lot of value with Chef inc, providing a public  
> > > > supermarket instance, it seeds community effort. You dont need it  
> > > > if you consume cookbooks from github or other sources (can be  
> > > > public, can be private/org specific).
> > > 
> > > I don’t think that it seeds community effort, because it’s often  
> > > a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may  
> > > be broken, outdated or just be a no-op cookbook that reserves the  
> > > name:
> > > 
> > > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&pl](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&pl)  
> > > atforms%5B%5D=
> > > 
> > > - number of downloads is irrelevant, as we all know
> > > - follower number is also not a good indication, because even  
> > > after a year, supermarket did not get the traction of e.g. github
> > > - last release date is probably the best indicator. In my  
> > > experience most cookbooks that are not updated within the last 12  
> > > months are outdated, e.g. won’t work with the recent distros like  
> > > Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> > > 
> > > Imagine a rather new chef user that needs to deal with systemd  
> > > unit files. Just with that single „trap" he/she will probably lose  
> > > a couple of hours or days or give up and pick something else with  
> > > batteries included.
> > > 
> > > I’m sure this is not intentional and everyone had the best  
> > > intentions doing it the current way - but IMHO it’s broken :-/  
> > > IMHO it’s all about hitting the right spot in between of „too  
> > > much“ and „too little“ and the original opscode-cookbooks concept  
> > > was probably a „too much“-problem and today it looks like we’re in  
> > > a „too little“ situation.
> > > 
> > > > why should community maintainers maintain a cookbook? - many.  
> > > > and i dont see the different of this with ruby gem, or any  
> > > > userspace tool (pyhton egg, or a debian in ppa). But the common  
> > > > reasons are: 1) you dont want to reinvent wheel,. if theres no  
> > > > opensource cookbook on ossec, every time i join a place it allows  
> > > > me rapidly roll out ossec cookboook. 2) my job depends on my  
> > > > skills/knowledge, to get a better job, i need to improve my skill.  
> > > > but that not possible if theres no one to mentor inside my own org.  
> > > > opensource brings that possibility. again this is not specific to  
> > > > chef, its very opensource thing, if you dont understand it, or dont  
> > > > know what value you get, dont do it. but for those of us, who are  
> > > > outside chef, uses it, and loves it. exposure is a huge thing, i  
> > > > cant become oracle reporting expert, but i can become chef expert  
> > > > even if dont have much money.
> > > 
> > > Sorry, but that doesn’t answer my question. Many open source  
> > > projects start, when something (technology, framework) becomes  
> > > „hot“. Everyone is trying to learn and get a spot in the eco  
> > > system. Popularity usually also means a rising number of jobs, e.g.  
> > > people can get their OSS contribution funded and/or get an  
> > > interesting job. However this strategy starts to collapse when the  
> > > crowd moves on to „even hotter“ things (typical hype lifecycle).
> > > 
> > > Example 1: now outdated Ruby gems -\> maintainer moved to node -\>  
> > > now outdated npm modules -\> maintainer moved to Go.  
> > > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > > 
> > > This brain-drain affects not only the quantity but also the  
> > > quality of projects. Less „eyes“ to find bugs, less „hands“ to fix  
> > > them, less users to use it. Experience for new users will suffer.  
> > > Why should people contribute to $not\_hot\_anymore projects? I  
> > > don’t see that many unique chef-jobs, so having something in the  
> > > GitHub repo/CV doesn’t bring you new opportunities by itself.  
> > > Even a popular (\>200 stars on GH) knife plugin for some trending  
> > > and cheap cloud hosting provider brings you exactly 0 job/project  
> > > offers (btdt).
> > > 
> > > possible options:
> > > 
> > > - provide minimal services that work out of the box by yourself  
> > > (Chef, Inc)
> > > - subsidize community to maintain it (you pay, you decide how)
> > > - offer opportunities so people can benefit from supporting the  
> > > community (e.g. job site, contract projects, sales-partnerships  
> > > with indies)  
> > > otoh: As far as I can see, most „Chef certified partners“  
> > > listed on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not  
> > > part of the community and some companies that provide value to the  
> > > community are not listed there at all…
> > > 
> > > > the last statement you made regarding namespace, is a technical  
> > > > problem. again its no different here than any other place. for  
> > > > example redhat has libvirt-lxc which everyone confuses with  
> > > > standard LXC but the project itself has little code/feature  
> > > > compatibility with main LXC. The point is like namespace is  
> > > > perceived, if you want you can publish a cookbook with samename and  
> > > > if its really good (and assuming theres enough people who wants it)  
> > > > you can definitely outweigh the other cookbook. if thats not  
> > > > happening, lets address that.
> > > 
> > > Your libvirt-example is great, as it shows why nearly nobody used  
> > > it and why Docker has such a huge impact by just providing a fancy  
> > > way to distribute tar archives and wrap some syscalls 😉  
> > > (oversimplification intentional)  
> > > Redhat isn’t very good in community/relationship outside of  
> > > their own Fedora/RHEL area. Just see how they „sell“ systemd to  
> > > users, developers and admins. I think better tutorials and  
> > > community-relations would have prevented that hatery/shitstorm  
> > > against it.  
> > > When I talk to systemd-"haters", I ask them to write me a sysv  
> > > -init script for a service, then I show them the systemd unit  
> > > representation.  
> > > When ansible users talk to me (chef user), they ask me to write a  
> > > solution that… whops. damn. You understand what I mean?
> > > 
> > > > the definition of critical is very diverse, theres no common  
> > > > critical component/cookbook. nothing. 0. as far as the whole  
> > > > community is concerned. if you freeze platform (since chef run  
> > > > from windows machine to raspberry pi to AIX to solaris) you might  
> > > > get a list of critical cookbooks (like sudo will be for linux), you  
> > > > might get another layer on family (like sysdtemd on ubuntu 15.04)  
> > > > .. we are in process of establishing the family specific  
> > > > maintainers, a similar effort can be made for cookbooks as well..  
> > > > but will be mostly community and few core contributors .. similar  
> > > > to kernel and userspace.. linus and linux foundation or redhat  
> > > > does not maintain ruby specific rpm etc..
> > > 
> > > Why do people need DevOps? To have a reliable infrastructure to  
> > > provide services that make money and to stay competitive. Usually  
> > > that involves more or less custom applications based on common  
> > > frameworks/stacks that need to be deployed. So at least a couple of  
> > > application deployment stacks are critical to show the benefits of  
> > > a DevOps solution. Even the [learn.chef.io](http://learn.chef.io)[http://learn.chef.io](http://learn.chef.io) tutorial falls apart,  
> > > when you’re using the latest releases of cookbooks used in the  
> > > tutorial, so this is also a good definition of critical.
> > > 
> > > > i am very interested in addressing this.. please keep your  
> > > > thoughts pouring 🙂 , but understand we cant solve it in a click,  
> > > > its gonna take some time, we have to keep talking, and out  
> > > > collaborative efforts on the next blockers toward this direction.
> > > 
> > > > fwiw i am the LT of chef on ubuntu, and i am working on a CD  
> > > > system that will test actual community cookbooks on every master  
> > > > merge of chef. Which will greatly reduce the maintenance burden,  
> > > > cause now core devs can also see what affect the changeset has.  
> > > > Next step will be do a survey and get a list of cookbooks and  
> > > > interested folks (brigade as we calling it) for ubuntu. What i  
> > > > wonder is a common pool might not make sense, though Chef is cross  
> > > > platform, majority of cookbook is not.
> > > 
> > > You don’t need a fancy distro/edge-case. Just make sure Debian 8,  
> > > RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t  
> > > mean something like „it installs runit triggered by sysv-init — and  
> > > it still works…“ on a systemd distro 😉
> > > 
> > > regards  
> > > Roland
> > > 
> > > PS: Despite all my examples I’m not a systemd zealot. I was okay  
> > > with upstart… But a common base of various distros is a good thing  
> > > for everyone in the long run. And it’s also a good example for a  
> > > game-changer and about the agility/adoption capabilities of such  
> > > things.
> > > 
> > > > hth  
> > > > ranjib
> > > > 
> > > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz \<[rmoriz@gmail.com](mailto:rmoriz@gmail.com)[mailto:rmoriz@gmail.com](mailto:rmoriz@gmail.com)\>  
> > > > wrote:
> > > > 
> > > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn \<  
> > > > > [jdunn@aquezada.com](mailto:jdunn@aquezada.com)[mailto:jdunn@aquezada.com](mailto:jdunn@aquezada.com)\>:
> > > > > 
> > > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob \<[adam@chef.io](mailto:adam@chef.io)[mailto:adam@chef.io](mailto:adam@chef.io)\>  
> > > > > wrote:
> > > > > 
> > > > > > To speak for Chef Software directly, we have always had  
> > > > > > people on staff  
> > > > > > whose role was assisting the creation and maintenance of  
> > > > > > cookbooks. That  
> > > > > > number has fluctuated up and down over time, with the skill  
> > > > > > sets of people  
> > > > > > we hire, and the normal day-to-day ebb and flow of trying to  
> > > > > > figure out how  
> > > > > > to build a business that is successful. We have people on  
> > > > > > staff today who do  
> > > > > > the same. What is clear is that the energy around cookbooks  
> > > > > > in the community  
> > > > > > is far greater than the energy we can muster as an  
> > > > > > organization (regardless  
> > > > > > of how much capital we do or do not have - y'all outnumber  
> > > > > > us) - and so our  
> > > > > > focus today is on trying to build and support the best  
> > > > > > community we can,  
> > > > > > through development of the supermarket, better tooling, and  
> > > > > > providing a few  
> > > > > > key examples of how best to build a community cookbook (see  
> > > > > > Sean's work on  
> > > > > > the httpd cookbook.)
> > > > > > 
> > > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > > 
> > > > > Hey Adam,
> > > > > 
> > > > > Would we consider transferring some of those cookbooks our of  
> > > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What  
> > > > > would be  
> > > > > the preconditions to doing that?
> > > > > 
> > > > > Personally I would like the chef-brigade and redguide to be  
> > > > > merged,  
> > > > > but I do not remember all the players involved -- if they are  
> > > > > on this  
> > > > > list perhaps they can speak up.
> > > > 
> > > > How would this prevent the problems that happend with the last  
> > > > migration of former opscode-cookbooks to community maintainers?
> > > > 
> > > > Why should community maintainers care about the cookbooks in the  
> > > > future?  
> > > > It can be a time consuming burden and people need to pay their  
> > > > rent and do their regular jobs…
> > > > 
> > > > I know, this will be very provoking, but:
> > > > 
> > > > If Chef, inc. doesn't want to maintain even critical cookbooks  
> > > > anymore, is there still a valid reason for running a public  
> > > > Supermarket site?  
> > > > If you go the "libertarian way" there is no reason for a  
> > > > supermarket site to protect/block names of cookbooks anymore that  
> > > > prevents users to pick other, maybe better community resources over  
> > > > legacy-cookbooks that are mentioned in guides and examples.
> > > > 
> > > > Either you (Chef, Inc.) control the market (e.g. maintain  
> > > > critical things yourself) or you should allow the free market  
> > > > (=community) to compete against each other based on equal  
> > > > opportunity (= namespaces or no supermarket). Everything else/in  
> > > > between will just end in chaos and anarchy.
> > > > 
> > > > regards  
> > > > Roland

---

<div class="post-metadata">

**Author:** ![Roland\_Moriz1](https://avatars.discourse-cdn.com/v4/letter/r/9fc29f/32.png) [@Roland\_Moriz1](https://discourse.chef.io/u/Roland_Moriz1)\
**Post date:** [June 25, 2015, 5:41pm UTC](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691/20 "2015-06-25T17:41:57Z")

</div>

> Am 25.06.2015 um 18:05 schrieb Nathan Williams [nath.e.will@gmail.com](mailto:nath.e.will@gmail.com):
> 
> > Best case is, that those "hidden" deployments will just stick with  
> > the chef patterns of 2010+, worst case they build things that should  
> > never ever be done in Chef and Ruby +that+ way… In almost every  
> > case, Chef (product) will then be blamed for the eventual desaster,  
> > not the team that was not able to adopt the best practices provided  
> > by the community and/or Chef, Inc..
> 
> i don't think this is true at all. one would have to be pretty out of  
> touch to fail to distinguish between core product and product  
> extensions, or company & community. if someone makes that mistake and  
> either leaves without seeking help (and having said misconception  
> subsequently corrected), or has enough sense of entitlement to be so  
> demanding, good riddance.

Here is a RL example of a large, profitable, well-known web-company (2014) with a few hundred nodes:

Team lead told me that they "trust their employees", not a single tool (or me as beeing just a contractor). If something doesn't work, they will question the tool, especially when the team could not make it work (anymore), everyone complained about the tool and the single guy that originally started using Chef left some time ago, anyways.

So nobody there gets fired for blaming Chef (tool).

Truth behind is: It's cheaper for them to start over with like $something\_else\_that\_may\_work\_with\_the\_team than to start over with a new team. Experts are rare and too expensive. Failing tools/frameworks/workflows are accepted, because "this is true innovation"…

So IMHO they best way to persuade devops and management people, is to show the benefits of a solution in action. No marketing slides, no "Facebook uses it, too, they always use good stuff!". Just a typical use case of the company to shows that Chef works great, if used the right way.

And here we are: Examples, Cookbooks, things that work out of the box and are up to date.  
Things, people can imitate to build experience and trust — to expand their knowledge and finaly build something their own upon it.

People don't want to ask a single expert about every problem because it makes them feel dumb. So they try Google, StackOverflow or GH issues instead. When questioners show very little undestanding of chef (tool), they are not everytime "trolls" or lazy, it might be a documentation and eco-system problem.

"You've a solution for every chef-related problem I have" may first sound flattering, but it also shows that you're SPOF, so this is a backhanded compliment.

regards  
Roland

> regards,
> 
> nathan w
> 
> > best regards  
> > Roland
> > 
> > > anyways, that's my two cents.
> > > 
> > > regards,
> > > 
> > > nathan w
> > > 
> > > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > wrote:  
> > > Hi,
> > > 
> > > > Am 23.06.2015 um 00:23 schrieb Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com):
> > > > 
> > > > yes there is a lot of value with Chef inc, providing a public  
> > > > supermarket instance, it seeds community effort. You dont need it  
> > > > if you consume cookbooks from github or other sources (can be  
> > > > public, can be private/org specific).
> > > 
> > > I don’t think that it seeds community effort, because it’s often a  
> > > „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be  
> > > broken, outdated or just be a no-op cookbook that reserves the  
> > > name:
> > > 
> > > [https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&plat](https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&plat)  
> > > forms%5B%5D=
> > > 
> > > - number of downloads is irrelevant, as we all know
> > > - follower number is also not a good indication, because even after  
> > > a year, supermarket did not get the traction of e.g. github
> > > - last release date is probably the best indicator. In my  
> > > experience most cookbooks that are not updated within the last 12  
> > > months are outdated, e.g. won’t work with the recent distros like  
> > > Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> > > 
> > > Imagine a rather new chef user that needs to deal with systemd unit  
> > > files. Just with that single „trap" he/she will probably lose a  
> > > couple of hours or days or give up and pick something else with  
> > > batteries included.
> > > 
> > > I’m sure this is not intentional and everyone had the best  
> > > intentions doing it the current way - but IMHO it’s broken :-/  
> > > IMHO it’s all about hitting the right spot in between of „too much“  
> > > and „too little“ and the original opscode-cookbooks concept was  
> > > probably a „too much“-problem and today it looks like we’re in a  
> > > „too little“ situation.
> > > 
> > > > why should community maintainers maintain a cookbook? - many. and  
> > > > i dont see the different of this with ruby gem, or any userspace  
> > > > tool (pyhton egg, or a debian in ppa). But the common reasons  
> > > > are: 1) you dont want to reinvent wheel,. if theres no opensource  
> > > > cookbook on ossec, every time i join a place it allows me rapidly  
> > > > roll out ossec cookboook. 2) my job depends on my  
> > > > skills/knowledge, to get a better job, i need to improve my  
> > > > skill. but that not possible if theres no one to mentor inside my  
> > > > own org. opensource brings that possibility. again this is not  
> > > > specific to chef, its very opensource thing, if you dont  
> > > > understand it, or dont know what value you get, dont do it. but  
> > > > for those of us, who are outside chef, uses it, and loves it.  
> > > > exposure is a huge thing, i cant become oracle reporting expert,  
> > > > but i can become chef expert even if dont have much money.
> > > 
> > > Sorry, but that doesn’t answer my question. Many open source  
> > > projects start, when something (technology, framework) becomes  
> > > „hot“. Everyone is trying to learn and get a spot in the eco  
> > > system. Popularity usually also means a rising number of jobs, e.g.  
> > > people can get their OSS contribution funded and/or get an  
> > > interesting job. However this strategy starts to collapse when the  
> > > crowd moves on to „even hotter“ things (typical hype lifecycle).
> > > 
> > > Example 1: now outdated Ruby gems -\> maintainer moved to node -\>  
> > > now outdated npm modules -\> maintainer moved to Go.  
> > > Example 2: cfengine -\> puppet -\> chef -\> ansible -\> docker
> > > 
> > > This brain-drain affects not only the quantity but also the quality  
> > > of projects. Less „eyes“ to find bugs, less „hands“ to fix them,  
> > > less users to use it. Experience for new users will suffer.  
> > > Why should people contribute to $not\_hot\_anymore projects? I don’t  
> > > see that many unique chef-jobs, so having something in the GitHub  
> > > repo/CV doesn’t bring you new opportunities by itself.  
> > > Even a popular (\>200 stars on GH) knife plugin for some trending  
> > > and cheap cloud hosting provider brings you exactly 0 job/project  
> > > offers (btdt).
> > > 
> > > possible options:
> > > 
> > > - provide minimal services that work out of the box by yourself  
> > > (Chef, Inc)
> > > - subsidize community to maintain it (you pay, you decide how)
> > > - offer opportunities so people can benefit from supporting the  
> > > community (e.g. job site, contract projects, sales-partnerships  
> > > with indies)  
> > > otoh: As far as I can see, most „Chef certified partners“ listed  
> > > on [Partners | Chef](https://www.chef.io/partners/#find-a-partner) are not part of  
> > > the community and some companies that provide value to the  
> > > community are not listed there at all…
> > > 
> > > > the last statement you made regarding namespace, is a technical  
> > > > problem. again its no different here than any other place. for  
> > > > example redhat has libvirt-lxc which everyone confuses with  
> > > > standard LXC but the project itself has little code/feature  
> > > > compatibility with main LXC. The point is like namespace is  
> > > > perceived, if you want you can publish a cookbook with samename  
> > > > and if its really good (and assuming theres enough people who  
> > > > wants it) you can definitely outweigh the other cookbook. if  
> > > > thats not happening, lets address that.
> > > 
> > > Your libvirt-example is great, as it shows why nearly nobody used  
> > > it and why Docker has such a huge impact by just providing a fancy  
> > > way to distribute tar archives and wrap some syscalls 😉  
> > > (oversimplification intentional)  
> > > Redhat isn’t very good in community/relationship outside of their  
> > > own Fedora/RHEL area. Just see how they „sell“ systemd to users,  
> > > developers and admins. I think better tutorials and community  
> > > -relations would have prevented that hatery/shitstorm against it.  
> > > When I talk to systemd-"haters", I ask them to write me a sysv-init  
> > > script for a service, then I show them the systemd unit  
> > > representation.  
> > > When ansible users talk to me (chef user), they ask me to write a  
> > > solution that… whops. damn. You understand what I mean?
> > > 
> > > > the definition of critical is very diverse, theres no common  
> > > > critical component/cookbook. nothing. 0. as far as the whole  
> > > > community is concerned. if you freeze platform (since chef run  
> > > > from windows machine to raspberry pi to AIX to solaris) you might  
> > > > get a list of critical cookbooks (like sudo will be for linux),  
> > > > you might get another layer on family (like sysdtemd on ubuntu  
> > > > 15.04) .. we are in process of establishing the family specific  
> > > > maintainers, a similar effort can be made for cookbooks as well..  
> > > > but will be mostly community and few core contributors .. similar  
> > > > to kernel and userspace.. linus and linux foundation or redhat  
> > > > does not maintain ruby specific rpm etc..
> > > 
> > > Why do people need DevOps? To have a reliable infrastructure to  
> > > provide services that make money and to stay competitive. Usually  
> > > that involves more or less custom applications based on common  
> > > frameworks/stacks that need to be deployed. So at least a couple of  
> > > application deployment stacks are critical to show the benefits of  
> > > a DevOps solution. Even the [learn.chef.io](http://learn.chef.io) tutorial falls apart,  
> > > when you’re using the latest releases of cookbooks used in the  
> > > tutorial, so this is also a good definition of critical.
> > > 
> > > > i am very interested in addressing this.. please keep your  
> > > > thoughts pouring 🙂 , but understand we cant solve it in a  
> > > > click, its gonna take some time, we have to keep talking, and out  
> > > > collaborative efforts on the next blockers toward this direction.
> > > 
> > > > fwiw i am the LT of chef on ubuntu, and i am working on a CD  
> > > > system that will test actual community cookbooks on every master  
> > > > merge of chef. Which will greatly reduce the maintenance burden,  
> > > > cause now core devs can also see what affect the changeset has.  
> > > > Next step will be do a survey and get a list of cookbooks and  
> > > > interested folks (brigade as we calling it) for ubuntu. What i  
> > > > wonder is a common pool might not make sense, though Chef is  
> > > > cross platform, majority of cookbook is not.
> > > 
> > > You don’t need a fancy distro/edge-case. Just make sure Debian 8,  
> > > RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t  
> > > mean something like „it installs runit triggered by sysv-init — and  
> > > it still works…“ on a systemd distro 😉
> > > 
> > > regards  
> > > Roland
> > > 
> > > PS: Despite all my examples I’m not a systemd zealot. I was okay  
> > > with upstart… But a common base of various distros is a good thing  
> > > for everyone in the long run. And it’s also a good example for a  
> > > game-changer and about the agility/adoption capabilities of such  
> > > things.
> > > 
> > > > hth  
> > > > ranjib
> > > > 
> > > > On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz [rmoriz@gmail.com](mailto:rmoriz@gmail.com)  
> > > > wrote:
> > > > 
> > > > > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn \<  
> > > > > [jdunn@aquezada.com](mailto:jdunn@aquezada.com)\>:
> > > > > 
> > > > > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob [adam@chef.io](mailto:adam@chef.io)  
> > > > > wrote:
> > > > > 
> > > > > > To speak for Chef Software directly, we have always had  
> > > > > > people on staff  
> > > > > > whose role was assisting the creation and maintenance of  
> > > > > > cookbooks. That  
> > > > > > number has fluctuated up and down over time, with the skill  
> > > > > > sets of people  
> > > > > > we hire, and the normal day-to-day ebb and flow of trying to  
> > > > > > figure out how  
> > > > > > to build a business that is successful. We have people on  
> > > > > > staff today who do  
> > > > > > the same. What is clear is that the energy around cookbooks  
> > > > > > in the community  
> > > > > > is far greater than the energy we can muster as an  
> > > > > > organization (regardless  
> > > > > > of how much capital we do or do not have - y'all outnumber  
> > > > > > us) - and so our  
> > > > > > focus today is on trying to build and support the best  
> > > > > > community we can,  
> > > > > > through development of the supermarket, better tooling, and  
> > > > > > providing a few  
> > > > > > key examples of how best to build a community cookbook (see  
> > > > > > Sean's work on  
> > > > > > the httpd cookbook.)
> > > > > > 
> > > > > > Perhaps we need to organize a PR/merge festival brigade?
> > > > > 
> > > > > Hey Adam,
> > > > > 
> > > > > Would we consider transferring some of those cookbooks our of  
> > > > > {opscode,chef}-cookbooks to a community-organized org like  
> > > > > chef-brigade ([https://github.com/chef-brigade](https://github.com/chef-brigade)) or redguide  
> > > > > ([redguide · GitHub](https://github.com/redguide)) for better maintenance? What  
> > > > > would be  
> > > > > the preconditions to doing that?
> > > > > 
> > > > > Personally I would like the chef-brigade and redguide to be  
> > > > > merged,  
> > > > > but I do not remember all the players involved -- if they are  
> > > > > on this  
> > > > > list perhaps they can speak up.
> > > > 
> > > > How would this prevent the problems that happend with the last  
> > > > migration of former opscode-cookbooks to community maintainers?
> > > > 
> > > > Why should community maintainers care about the cookbooks in the  
> > > > future?  
> > > > It can be a time consuming burden and people need to pay their  
> > > > rent and do their regular jobs…
> > > > 
> > > > I know, this will be very provoking, but:
> > > > 
> > > > If Chef, inc. doesn't want to maintain even critical cookbooks  
> > > > anymore, is there still a valid reason for running a public  
> > > > Supermarket site?  
> > > > If you go the "libertarian way" there is no reason for a  
> > > > supermarket site to protect/block names of cookbooks anymore that  
> > > > prevents users to pick other, maybe better community resources  
> > > > over legacy-cookbooks that are mentioned in guides and examples.
> > > > 
> > > > Either you (Chef, Inc.) control the market (e.g. maintain  
> > > > critical things yourself) or you should allow the free market  
> > > > (=community) to compete against each other based on equal  
> > > > opportunity (= namespaces or no supermarket). Everything else/in  
> > > > between will just end in chaos and anarchy.
> > > > 
> > > > regards  
> > > > Roland

[Next page](https://discourse.chef.io/t/community-cookbook-maintenance-was-re-reprepro-cookbook/6691.md?page=2)