I would really like to see Chef not be the SPOF for cookbook sharing and
governance. I would love to see someone aggressively fork the community
site and implement their own code quality standards, supported features
and governance. Because as long as we think we’re trying to produce the
one apache cookbook that works on every RHEL, Debian, Ubuntu, Gentoo,
Arch, Solaris and AIX distro for the past 10 years and supports binary
and source installation, etc we’re going to produce a mess which
satisfies almost nobody. The models of rubygems and CPAN and other
library sites for languages are a really bad metaphor for this domain
because we don’t just have the problem of running on a few different
versions of a language, but running on a huge matrix of different O/Ses
and distros and all the ways that sysadmins like to maintain their
servers. There will never be the OneTrueWayToInstallApache.
It would also be good to see better competition in the ‘marketplace’ for
cookbook governance. I’d love to see us be able to be lazy and just
steal good ideas that other people had implemented and had turned out to
be successful (and also learn from the failures that happen). Ideally
Chef, the company, just gets out of the business of managing cookbooks
entirely and we can focus on building the software behind it all. I
don’t think that happens unless you have a robust, self-supporting
community, though, and right now it feels too much like the Chef
community is just looking entirely at the company to provide all the
leadership here. I don’t think that’s a good thing.
And when people start talking about "enforcement of community standards"
when there’s just one game in town, my inner anarchist gets very upset.
I’d prefer to see different communities, and if one of them has a
complete internal political meltdown over moderation and governance then
you can fork it all and patch the politics.
On 5/23/14, 6:14 PM, Sean OMeara wrote:
We’ve been thinking about this quite a bit lately. With Supermarket on
its way, this is the perfect time to rekindle the conversation.
To answer you first question, we retain a commit bit on cookbooks
which were previously maintained by Chef, but trust the maintainers to
do what they think is best. Currently, issues with maintainer-ship are
handled on an individual case by case basis.
Like Julian mentioned, we’re looking at other projects (Arch Linux,
Perl) for examples of governance policies. The key is to be super
clear about exactly what issues such a policy is intended to solve,
and not to discourage or alienate people when enforcing such policies.
Issues like how to handle abandoned projects clearly need to be addressed.
One of the exciting things about Supermarket shipping, is we’ll
finally have a hackable community site. Instrumenting that to provide
visibility into usage patterns is going to allow us to make better
decisions. It also gives us the freedom to start tinkering around with
things like name spacing.
On Fri, May 23, 2014 at 9:08 PM, Christopher Webber
<email@example.com mailto:firstname.lastname@example.org> wrote:
So first off, thank you for the email Ryan. These issues are super
important and I want to make sure we address them in a thoughtful
and open manner.
So a couple of things stand out to me:
1) At this point, software quality isn’t really a solved problem.
We have great tools like ChefSpec, Test Kitchen, Rubocop and
Foodcritic to give us information about the quality of our code
but they are not 100%. With that said, we should probably work
towards a community standard of what constitutes a quality
cookbook, if only to give those of us writing cookbooks a
yardstick to measure ourselves by.
2) I worry about the idea of “enforcing” high quality. Things like
setting standards for unresponsiveness and cookbook abandonment
make a ton of sense to me, but the problem with enforcing around
quality is that it becomes a very dangerous path and I think I
would rather see us get some of the other aspects down before we
even begin that process.
3) There is another idea that we really haven’t discussed around
ownership. I don’t have enough background to know the actual
agreements around the cookbooks that the community has taken on,
but it doesn’t seem like the cool thing to just take back a
cookbook. Additionally, I worry about the precedent that doing so
would set as the associated implications of doing such a thing. I
think about it this way… Just because a sysadmin has the ability
to read all the email on a system doesn’t mean it is right of them
to do so. There are usually organizational policies and guidelines
that govern when it is acceptable to do so. If we start down a
path of governance and defining rules around these things, this
would be a place I would like to see us address.
I really would like to hear what the community thinks about all of
the things presented. More than anything, I would like to know if
working towards a governance policy or set of guidelines is
something the community wants undertake. I know we (Chef Software,
Inc.) would love to be a part of facilitating that discussion and
are key stakeholders, but I don’t think any of us want to go down
the Governance path if there isn’t support from the greater
community to do so.
On May 23, 2014, at 4:56 PM, Julian C. Dunn <email@example.com
> Hey Ryan,
> I'm actually gonna shift this thread to chef@ so that it gets
> I've been meaning to address some of the points here since we
> Cookbook Governance BoF at ChefConf (and I have been remiss in not
> posting a summary from that). I have a short deck that
> I set up the conversation at the BoF:
> What we heard from folks there is that the community wants Chef
> (Software, Inc.) to be more prescriptive about managing the
> on the community site. In other words, folks who were at the BoF
> wouldn't mind if we set some standards for evicting unresponsive
> maintainers from those namespaces, and/or transferring ownership to
> others who want to take over cookbooks -- provided, of course,
> have made a good faith effort to contact maintainers & encourage
> to do their duty.
> I'd like to hear from others who weren't at the BoF if they also
> this way. If you do, then I think we (Chef Software, Inc.)
> with the community to develop some of these rules, and then enforce
> them, to the extent that 'enforce' means 'be the broker of last
> in case of dispute or cookbook abandonment'.
> I've also asked Chris Webber, our community software developer, to
> weigh in on this thread. He has some thoughts that may be pertinent.
> - Julian
> On Fri, May 23, 2014 at 4:58 PM, Ryan Hass <firstname.lastname@example.org
>> A little over six months have gone by since many of the
>> handed off to various community maintainers. Now seems like a
>> to continue this discussion with wisdom at hand; I am sure many
>> like myself may have questions and surely have ideas on how to
>> Many of the cookbook maintainers have done an outstanding job
>> with the community, resolving issues, and accepting and mentoring
>> changes. Unfortunately, there are a few which have not met the
>> standards which preceded their maintainer-ship. Having said this, I
>> would like to discuss the Chef governance policy with regards to
>> maintainers whom have been unable to fulfill their duties, and the
>> process of ensuring these cookbooks continue to have high
>> Some questions I have are:
>> * What is the current governance of cookbooks which were previously
>> maintained by Chef (Opscode)?
>> * How can the community get involved in this governance process to
>> ensure high quality standards persist for said cookbooks?
>> Please do not hesitate to share your questions or thoughts on the
>> subject of the cookbooks which were handed off. As mentioned, I
>> there are many others with related questions and ideas on the
>> -Ryan H.
>> This electronic message contains information which may be
confidential or privileged. The information is intended for the
use of the individual or entity named above. If you are not the
intended recipient, be aware that any disclosure, copying,
distribution or use of the contents of this information is
prohibited. If you have received this electronic transmission in
error, please notify us by e-mail at (email@example.com
> [ Julian C. Dunn <firstname.lastname@example.org
<mailto:email@example.com>> * Sorry, I'm ]
> [ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
> [ gopher://sdf.org/1/users/keymaker/
<http://sdf.org/1/users/keymaker/> * compliant! ]
> [ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]