Cookbook Namspacing

gistfile1.txt

I wrote this on 2010-10-01, and I've been passing it around as the entry to my opinion on why we need namespacing on the community site. Maybe it's a terrible argument since we haven't implemented it yet, but it's a lot of words that I can save myself from typing over again.

I thought there were tickets or mailing list posts with opposition to namespacing, but I can't find them. Drop them in the comments if you know of any please.

Bryan McLellan <btm@loftninjas.org>

###
Earlier in the week we had a meeting (you guys rock) at HQ about
cookbook workflow and one of the subjects we discussed heavily was
cookbook namespace on the cookbook site. At the end of the meeting I
agreed to bring this up in backchannel for further discussion. As I
understand it, this was discussed heavily in the past and the decision
was made to leave it up to the community to work out a solution.

The chief reason I've heard from people as to why they don't upload
cookbooks is because they aren't finished, or more specifically, need
to be "cleaned up." Still, some degree of this may be proprietary
code, but much of it is a disinclination toward uploading something
that feels incomplete or untested. I believe there's value to be
gained in getting these cookbooks uploaded; being able to use other
cookbooks as examples is a huge benefit to those that don't feel
comfortable with the language as they can copy and paste code to
produce working cookbooks. There is a wealth of existing cookbooks,
particularly on github [1], but discoverability is an issue,
particularly for new users. Cookbooks should be the primary site for
distributing finding cookbooks, although not necessarily the primary
hub for developing them.

Some part of the problem may be social, as many of the cookbooks on
the site were uploaded by Opscode which have a certain standard of
testing, they set a bar for others. This bar is useful in some cases,
but not in all. It has been proposed that we add some kind of
"validated stack" function, where cookbooks can be tagged by Opscode
or other partners such as rackspace as having been tested, which would
separate to the rating system; being both a search target and a visual
tag or award.

The current practice for naming cookbooks has always been to name them
after a product or role, such as "mysql" or "webserver." However, our
current system only allows one cookbook to be named "mysql." As we've
produced a mysql cookbook this isn't specifically an issue, but it
likely discourages others from uploaded a cookbook they haven't
heavily tested as _the_ cookbook for product "foo."

While the cookbooks site hasn't gotten a lot of development attention,
I don't think this has specifically been keeping users from uploading
to the site. The community hasn't produced an alternate solution to
naming. I think mostly they've worked around the cookbook site
entirely. I believe that this retards the rate of new user uptake.
Thus, I believe we need to lead and provide a better solution,
followed with active encouragement to jumpstart use of the site.

I propose adding the cookbook user to the namespace for the cookbook
with a forward slash as a delimiter. Existing tools would be modified,
if necessary, to support downloading "btm/mysql" instead of just
"mysql." As a transitional step we could create join table between the
existing single word name space and this new username based namespace.
As the site already has support for multiple users co-maintaining a
cookbook this also adds an "organizational" account feature where a
company like 37signals could upload their cookbooks here under the
company name, allowing individual employees and other contributors to
be able to update the cookbook. Users could effectively fork an
existing cookbook by downloading it and uploading to their own space.
Perhaps we could create a feature to do this through the site, which
could maintain metadata about the source of the package. Keeping in
mind that we're not trying to replicate github, but mimic some of its
feature to create a site centered around cookbook distribution that is
relatively agnostic to development workflows like a specific scm.

While users could provide metadata as to what package a cookbook
provides support for, I don't think we will see users start naming
their apache cookbooks "elephant," and they mysql cookbooks "ocean,"
to avoid overlapping namespace. Everyone is going to have an apache
cookbook, and as we've seen, writing a single apache cookbook that
does everything would be exceedingly complex. Thus we need to expect
for users to have different apache cookbooks and move away from having
a single apache cookbook, using descriptions and metadata to allow
other users to determine if that cookbook is one they want (supports
this os, uses this init system, puts logs into this logging system,
etc). Vendors will provide their own cookbooks that work with features
of their product, be it logging, hosting, or whatnot.

I believe with this system we can promote users to upload cookbooks as
examples that need not be completely functional, and that this is an
important step toward increasing community usage. Thoughts?

Bryan

[1]
http://github.com/opscode/cookbooks
http://github.com/37signals/37s_cookbooks
http://github.com/rediscookbook/rediscookbook
http://github.com/ternarylabs/cookbooks
http://github.com/infochimps/cluster_chef