The evolution of Puppet community
Re-introducing community engagement
Many of you know me from my various community-facing roles during my tenure at Puppet. I'm now taking on some new challenges as our Community and Developer Relations Lead and I'm thrilled about it. I'm definitely not the first to say this, but Puppet's community is truly incredible. The level of engagement, commitment, and collaboration never ceases to astound me. When someone new shows up in our Slack, there's always a helpful suggestion or a link to docs or a Forge module that helps solve a problem. Many of our best features started out as community contributions, and the ecosystem of Forge modules is outstanding. Vox Pupuli is one of the most productive volunteer-run organizations I've ever worked with; their deep collaboration with the Puppet team helps us make hard decisions.
We had some big news recently. I wrote an FAQ about it, if you'd like more information. But I'm reminded again that the more things change, the more our core stays the same. Together, we are community, and I'd like to tell you about some efforts we've had in flight to improve our part of this and show up as better citizens of our open source community.
The Puppetlabs Toy Chest and repository archiving
Many of us have faced challenges when trying to contribute to an open source repository. For example, a pull request might sit and languish unacknowledged for months, leaving you wondering whether the repository is still active or maintained. You might wonder if you missed a step, like filing a Jira issue or requesting a review–but who to request from? You begin to wonder whether you should even be using that software in the first place!
In fact, that may be an experience that some of you have had with a few of our repositories in the past. You may have noticed that the puppetlabs GitHub namespace has…. let's just say a lot of repositories. Over the years, we've built many projects and experimented with all sorts of different takes on problems. We've created demos and point-in-time solutions, like the log4jscanner module we released a few months ago. Professional services engineers have created modules to solve specific customer needs that were never intended to be productized. All these repositories sat in the same namespace alongside our existing products and open source projects, without a clear delineation between maintained and unmaintained repositories.
Puppet modules are particularly troublesome in this regard due to the way they're presented on the Puppet Forge. The blue Supported badge makes it clear which modules you can file support requests on, but what about other modules published by Puppet? It could be surprisingly difficult to tell the difference between abandoned modules and fairly well-maintained ones.
This was something we needed to tackle head on, so we started a cleanup project late last year to help resolve this challenge. One of the first things we did is require a valid CODEOWNERS file in all active public repositories. This helps identify who's responsible for a repository. It helps us track down who should cut a release or respond to security alerts, and it helps you by automatically requesting reviews from the right people when you contribute code. It also helped our Open Source Stewards identify un-owned repositories because they were missing that file.
Some repositories that were no longer relevant or useful were deleted (after due process of course), but the repositories that still seemed useful or interesting were archived and stored away in the Puppetlabs Toy Chest, ready for some interested party to pull it back out and give it new life. Maybe that's you? If you'd like to adopt any of the repositories in that org, just follow the guide and let us know!
During that process, several popular modules like lvm, rsync, and xinetd were inadvertently caught by our automation scripts and archived. Of course, this just highlights the problem we're working on resolving.
We are hard at work now, creating an ownership model that meets all our needs and effectively communicates the kind of engagement you can expect from each module repository. These repositories will be unarchived again once this ownership model is complete.
GitHub organization spring cleaning
Another manifestation of our years of organic growth is the sheer number of community folk with actual full org membership! That's enough to give the heebie-jeebies to any security professional or auditor, so we've been working on cleaning that up. We deeply appreciate the contributions from community members, but with mature review and merge processes, org membership is no longer necessary to contribute to our open source projects.
You may have noticed some of this over the past year as we carefully removed membership from people who weren't current Puppet employees.
Sorry, Daenney. We really do love you and all you've done for the community!
We finished up just this last week by removing unnecessary external contributors, which happened to coincide with the acquisition news. (They were unrelated.)
The new Content and Tooling (CAT) team
You may have also noticed radio silence from our modules team recently. Some months ago, we lost a few key team members. We’ve spent that time building a new team focused on enabling high-quality content for the ecosystem. You'll come to know them as the CAT – Content and Tooling – team and they've been taking some time to regroup and perform some housekeeping, prioritization, and roadmapping.
You can read more about them and the projects they're working on at their microsite. I don't want to steal too much of their thunder, but they'll be re-engaging soon with office hours, renewed focus, and more ways to engage. Watch their blog for updates!
And much more…
There's more to come, like easier ways to navigate our GitHub namespaces, more discoverable microsites, better use of our GitHub discussion boards, and more. I wish I could tell you all about it now, but our blog editor is already giving me the stinkeye for going on so long, so that will have to wait until next time!