Puppet Labs CEO: How to Grow an Authentic Open Source Community

Luke Kanies, founder and CEO of Puppet Labs, kicked off the last day of ApacheCon with a keynote on Growing Authentic Communities. Despite being early on the final day of a conference, Kanies managed to draw a respectable crowd at ApacheCon eager to hear about techniques for growing a community.

Growing Not Building

Why were so many people interested in what Kanies had to say? He reasoned that people were interested because he’s running a company and a project simultaneously. That was by design, he says, from the earliest days of Puppet. Doing it the other ways – either trying to graft a company onto an existing community or trying to create a community from a company project – don’t work so well.

“A lot of companies think you can force the creation of a community,” but you can’t says Kanies.

For those who aren’t familiar with Puppet, the project started in 2005 – with a single user on the dev list (Kanies, obviously) and no user list. At the same time, Kanies started the company with the goal of making enough money to pay “a bunch of software developers.”

How would he be able to tell if it was a good project? Whether people were willing to pay, says Kanies, “was a good test of whether it’s good software.”

Obviously, Puppet has grown considerably since its early days. It’s an enormously popular open source configuration management tool, with thousands upon thousands of users and investments from major companies. How’d it go from one guy to a well-functioning community and successful company with plenty of developers?

One thing Kanies says that Puppet has done well is to make pretty major changes (like the switch from the GPL to the Apache Software License) without having “a major outcry.” How’d they manage that? It’s a combination of community practices that other communities would do well to emulate. Engage, don’t announce, says Kanies. It’s much better to say “here’s this thing we’re thinking about” than to make an announcement by fiat – even if the company behind the project can do that, it shouldn’t.

Kanies says the process took about six months, and only two of 3,000 or so people complained.

Transparency is Hard

Another major factor is transparency – which isn’t the same thing as “openness,” says Kanies. Communities should be transparent in how they operate and honest in answering questions, but that doesn’t mean that (for example) Kanies is going to answer questions about funding or other topics that aren’t something he can disclose to the entire community.

He also stressed being willing to admit that a project isn’t perfect, or suitable for every use case. “People are really hesitant to say, ‘yeah, it won’t work for that,’” says Kanies.

When a project is new, it might not work terribly well. When a project is mature, it might be hard to change direction, etc. Any stage of a project is going to have its own problems. Kanies says you have to acknowledge those, and also think about the “great aspects” of the stage the project is currently at rather than being uncomfortable.

Another biggie Kanies mentioned is to admit when you’re wrong. Just do it and move on, don’t focus on being right at the expense of community.

Answer Every Question

Another practice? Kanies says that his philosophy was to “answer every question” even if the answer is “I don’t know.” Make sure every user is responded to and try to help them. This is something that’s very hard to do, but it helps turn might-be users into users, and users into vocal proponents of the community. I remember getting a response directly from Patrick Volkerding shortly after trying Slackware in 1996, when I wasn’t too sure about this Linux thing. Getting courteous, speedy support directly from the man himself convinced me to keep plugging away at learning Linux.

Obviously, as the community scales, a single person will hit the limit of his ability to help. Kanies says it’s important to work with the community to “help them grow to be the people who are going to be the ones to help.”

And while you’re at it, be nice, says Kanies. Don’t focus on who’s right, and don’t be OK with technical rudeness. Insist on comity in the community, even if other FOSS projects might not be quite so friendly. Unfortunately, Kanies says he can’t really point to specific techniques that led to “people being nice and getting work done instead of scoring points. One of the things I’m most surprised by is the complete lack of religion in our company.”

On the corporate side, Kanies says that companies need to make sure that employees are convinced about community “or get them away from the community.” It may not be necessary for every employee to be well-versed or interested in working with the FOSS community – but if they work directly with the community, they’d better be.

Puppet may not be the perfect embodiment of community, but the project and company have grown admirably over the years. Anyone working with a FOSS project that has commercial ties would do well to take his advice to heart.

Joe Brockmeier is employed by Citrix as an advocate for open source cloud computing, and spends most of his time working on or promoting Apache CloudStack Brockmeier is a PPMC member for the project, and can be reached on Twitter or by sending an email to jzb at Apache.org.