CfgMgmtCamp 2026

Config Management Camp 2026 was a hit. The conference had over 750 attendees, and over 450 of them stayed for the optional third "fringe" day. Not only that, but almost everyone in the Vox Pupuli Community Day room stayed through the end of the day. This is distinct growth, and the third day participation numbers over the last two years were higher than they've ever been.

I attribute a decent amount of this boost to the resurgent interest in OpenVox and the Vox Pupuli community. Personally, I had at least 4 fairly well known DevOps community members come chat with me about getting involved with OpenVox again, and I think it's great that we're starting to build momentum again.

This year we were lucky enough to stream about 3/4 of the Vox Pupuli Community Day, but we didn't have advance warning so many of you may have missed it. I'd like to briefly recap some of the conversations and decisions we went over.

PMC Elections

With the growth of the OpenVox project, Vox Pupuli leadership is becoming more and more important. The PMC (project management committee) is a group of people who are democratically elected to make many decisions on the behalf of the community. This includes everything from managing swag to facilitating conversations about platform support to organizing conference participation such as this. Each year at CfgMgmtCamp, we kick off annual elections. Watch this mailing list for information about the current election process.

Research study

You may or may not know, but we have an ongoing research study about Vox Pupuli. Sol introduced the topic of their project: ignorance in open source communities. They focus on unknowns, secrets, denials, and suppression of knowledge, among other types of non-knowledge. They presented a few examples of this in both the software industry in general and specifically corresponding to Vox Pupuli.

They very much hope you can help with this research, and offer several ways:

• You can fill out the questions posted in an encrypted and anonymous pad (until 20 February)
• you can be interviewed
• and for those living in Germany or nearby countries, they would love to accompany you for a day at work to learn about your routines, working styles, tools in use, among other things.

You can contact them in Slack as @Sol Martinez Demarco, Mastodon as @solmd@tech.lgbt or via email at smartinezdemarco@hs-harz.de.

OpenVox 9

One of the biggest topics we covered was roadmapping for OpenVox 9. We have a lot of plans and big ideas, but ultimately we decided a few things:

• We have several platform components coming up on EOL very soon and we don't have much time to get a major release out to support them.
• We don't necessarily need to keep in-line with PuppetCore releases. We can release at our own pace, even if that means major releases are closer together than they have been in the past.
• Deprecating features but not actually removing them is disingenuous and unfair to users.

We decided that the OpenVox 9 release was going to consist of platform component updates and the removal of some years-since deprecated features and then immediately start work on roadmapping to feature updates in OpenVox 10.

What to do about puppetlabs-* modules?

Many modules from Perforce/Puppet have become stagnant. Every day we have someone stop by the slack to complain about ignored pull requests and ask when we'll fork the modules. We've pushed back because it's a large amount of work, but it was pointed out that mitigating bitrot is an ongoing nightmare of extra work too.

We've decided that it's time to start forking and adopting puppetlabs-* modules on a case by case basis. We will follow the standard adoption process, but the PMC will approve each fork before we accept it.

Project licensing

The Apache license is very business friendly and allows for source sequestering. We decided that it was no longer appropriate for the Vox Pupuli community and will be relicensing to GPL. We still have some work to do, such as identifying which specific GPL license is appropriate for each component and such so anyone with license expertise is invited to share their knowledge with the PMC.

See these guides for how the licenses are compatible:

• https://www.apache.org/licenses/GPL-compatibility.html
• https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

De-JVM the server

The PuppetServer is a turducken of technologies. It runs in the JVM, with services implemented in Clojure and the actual Puppet compiler wrapped via jruby. This is wildly inefficient because each boundary introduces redundant copies of objects in memory and we regularly run into incompatible code because of jruby. Worse, we have very few people in the community with either Java or Clojure expertise. We've decided to do an experimental implementation of the OpenVox Server in pure Ruby, without the JVM or Clojure. This will require either a rewritten CA implementation or some glue to integrate an off-the-shelf CA option like SmallStep.

As PuppetDB was originated in Clojure, the cost to do the same would be prohibitive. For this reason, we have no current plans to rewrite OpenVoxDB.

Miscellaneous

We've had long-standing conversations about moving away from Slack. A few members of the Matrix governing board are interested in helping us get a Matrix server stood up and a bridge connected to Slack and IRC to help people migrate. We don't have a timeline for this project, but keep your eyes open for information.

There was another conversation about opening a swag store. See plumbing#262 for existing conversation. Essentially, we are at the point where we all agree this is a good thing to do and just need someone with time to set up and run the store. Could that be you?

People swarmed both the Betadots and the Overlook InfraTech tables with interest and curiosity. We were focal points for a lot of really good conversations. If your company is on the edge of deciding whether to sponsor the event, we'd love to have your table next to ours next year.