A Puppet module might only be some 500 lines of code and a bunch of tests, but that doesn't mean it's effortless to maintain. Puppet modules should run on a range of operating systems and support a range of Puppet versions (and hence, Ruby versions)—and that in and of itself makes it quite challenging.
So while a single person could easily write a Puppet module, what happens when that person gets sick? Changes jobs? Or simply loses interest?
Three years ago, we were in a situation where many "standard" modules were practically unmaintained for reasons like these. Dissatisfied with the status quo in Puppet Land, and being old-school open source rebel queers, Daenney and I launched Vox Pupuli to give more weight to the community of Puppet, an open source project led by a single company.
Buying a domain and slapping a few words on a gh-pages site made it official. And then, for some time, nothing of note happened. For a long time, we feared that our community would become a graveyard for abandoned projects.
Our goals
When Vox Pupuli started, there were three main issues we wanted to address:
- Give more voice to the community
- Create an adoption center for puppet-related projects
- Adopt new puppet features faster than Puppet could
We had a simple idea: When modules go unmaintained, we offer to adopt the module and give merge access to anyone who contributes.
A number of things started happening once we started actively promoting this. Today, we have 78 modules published on the forge and 90+ contributors with merge access.
How we've evolved
In the beginning, we adopted a lot of our style and guidelines from Puppet. We also adopted many of their unsupported modules. As the number of our contributors surpassed Puppet's Modules team, Puppet started looking (or often, pointing) towards us for new community guidelines.
Our IRC channel became a seemingly more approachable replacement for #puppet-dev—despite the enormous overlap of users. I point this out because Puppet's community is famously friendly. This is something we inherited without any effort of our own, and we've worked hard to keep it that way.
We've driven automation and embraced openness. And we're still looking into pushing that further: Recently our contributor expansion has stalled, so our next goal will be to automatically invite anyone who contributed a successfully merged pull request.
Even our (actually, Puppet's) competition has recognized the usefulness of our approaches and has started adopting it for its community. And, most recently, we've been accepted as part of the Software Freedom Conservancy. For me, the community's greatest milestone was to see it outgrow its founders: Neither of us is on the steering committee. Daenney even transcended beyond Puppet.
How to create your own project community
Now that you see how great a community of practice can be, it's time to see how you can make your own!
- Think of a good name
- Define your scope
- Adopt and enforce a strong code of conduct
- Reach out to (struggling) maintainers
- Promote your project
- Invite people who are willing to help
- Help the ones who need a hand
If this is too rough a guide, you can always copy how others have done it:
- Voxpupuli: Opensource Speedtrain transcript of a talk I gave in 2016
- Sous Chefs Chef practitioners' community of practice
- fruitful community of JavaScript package maintainers
- terra-farm Terraform community
Comments are closed.