There are many criticisms that one can make of the applications offered by
the free software community, but lack of choice is generally not one of
them. Our community thrives on competition while our licensing makes it
hard to keep secrets from competitors. A recent episode in the Puppet
community shows that, while this competition can sometimes take unwelcome
forms, there is often little to do but to welcome it anyway.
Puppet is an
automated configuration management system intended to make life easier for
system administrators; it can be seen as a competitor to venerable tools
like cfengine. Over time, Puppet
has attracted an active community of users and developers; it would appear
to be a
tool which is growing in capability and popularity. Puppet is managed by
Reductive Labs, which has a clear commercial interest in providing training
and support services for Puppet users.
Recently (January, 2009), a project named Chef announced its
existence. Chef's developers, who have previously worked with the Puppet
code, set out to solve a similar problem. Chef is not a fork of Puppet,
though; it's a new project developed from the beginning. Among other
things, the Chef developers decided to use Ruby as the configuration
language and they chose the Apache License (Puppet, instead, is distributed
under the GPL). This project claims to be in active, production use, but
its community, at this point, is clearly small. As of this writing, the chef-dev
mailing list shows a total of four messages over its entire history.
Initially, the Puppet developers responded
confidently to the Chef announcement:
Everything else in Chef seems pretty basic. They certainly have a
smaller code base than Puppet does, but they're also brand new -
Puppet didn't start this large, either, of course. To me, it's
mostly a question of who has the best vision and who can execute.
On those fronts, given my experiences (albeit tempered a bit these
days by fatigue), I'm not afraid of competition.
More recently, though, Puppet
developer Luke Kanies posted to the project's
user list that Chef wasn't competing entirely fairly:
We've recently had some problems where one or two people are
maintaining their presence in the Puppet community solely as a way
to recruit people out of Puppet and into their community, at the
expense of ours, and I think we need a straightforward community
policy on this....
My take is that if your participation in our community is *solely*
for purposes of shrinking it by drawing people into your community
at the expense of ours, then you should be kicked from our
In particular, it is said that one developer from the Chef project has been
sending private mail to Puppet users - especially those experiencing
problems with Puppet - suggesting that they should switch to
Chef. Luke, clearly, sees this activity as a threat to his livelihood;
every Puppet user who deserts is one less potential customer. Even without
that incentive, though; it can be hard to stand by and watch as others try
to woo users away from your project. One need only think back to the days
when "Ubuntu is better" posts were a semi-regular feature of the Fedora
mailing lists to see how galling it can be.
In this case, a cooler perspective quickly won over and it became clear
that there was little to be done. If nothing else, the objectionable
messages were private email; there is little that the project could do to
stop them even if it wanted to. Beyond that, though, certain things are
inherent in the running of a free software project, including:
- There will be competition, in some form or other. Somebody,
somewhere, is sure to decide to scratch an itch, even if that itch is
no more substantial than "I want to run my own project." This is both
a strength and a weakness in our community. The ability for new and
different ideas to develop into functioning projects is the source for
much of the great software we now have, but it also leads to a certain
amount of duplication of effort and confusion of users.
- Some Puppet users expressed dissatisfaction that the Chef developers
had clearly drawn a lot of inspiration and knowledge from the Puppet
project. But, again, that's how our community works. Anybody who
wants to hide the ideas that go into an application would be well
advised to keep their software proprietary and closed. In the free
software world we learn from each other - at least some of the time.
- In a community which values freedom, attempts to silence or banish
inconvenient characters will not get very far. When inappropriate or
unethical behavior is seen (and spamming users of a competing project
to urge them to switch is certainly pushing the boundary), shining
light on that behavior is usually the best thing to do. In this case,
the discussion made it clear that this email campaign did not inspire
respect; it would not be surprising to learn that the pro-Chef emails
have already stopped.
Andrew Shafer summed up the situation
Puppet is awesome, except when it isn't, and the best way to move
things forward is to address those and get back to making more
awesome. That's what we need to be worried about. Just more
awesome, this is not a zero sum game.
Projects which are focused on "awesome" tend, over the long term, to be
rather more successful than projects which worry about what others might be
saying about them. They are also likely to be more successful than
projects which put their effort into trying to poach another project's
users. Puppet appears to have good code and an active and engaged user
community. If it can stay focused on that code and that community, this
project need not fear what its competitors are doing.
(Thanks to Friedrich Clausen for calling our attention to this discussion).
to post comments)