Well, it appears that Perforce has taken another step down the enshittification journey. For some strange reason, it appears that they don’t want you writing Puppet modules unless you’re a paying customer. That’s right, they killed the open source PDK and sequestered the source away, just like they did with Puppet. They would like you to pay for the privilege of creating content for them.
This is a very strange strategic move on their part. Their ecosystem is almost
entirely supported by community authors building and maintaining Puppet modules.
A full 96% of their paying customers use modules supported by Vox Pupuli, many
of which are open source users. They barely even maintain their own modules in
the puppetlabs namespace. Most of the contributions there have for years come
from community members using the Trusted Contributors
program that I built when I was still there.
On a related note, it also appears that they’ve shut down the Trusted Contributors program as it’s no longer mentioned on their website.
In reality, they don’t even have a dedicated modules team anymore! One with any sense at all would think that given this lack that they’d want to encourage people to build and maintain quality content in the ecosystem rather than putting barriers in place to make that harder to do. 🤔
My only assumption can be that the Puppet Core sales aren’t so hot and they need something, anything, to juice the numbers a bit.
But does it actually matter?
In all reality, many of us never really liked using the PDK. It’s really big
and inflexible. The customization options are confusing and tedious. It
generates way too many random config files for services that most people never
used, unless you customize it, which again is super awkward. And maybe worst of
all, it was designed primarily for the use of Puppet’s modules team (it still
existed back then) rather than being designed for community developers. For
example, until a few years ago, it configured PR testing and publishing
workflows with GitHub actions that assumed that you were using Honeycomb for
profiling and hardcoded the puppetlabs namespace.
Vox Pupuli developer tools
Luckily, Vox Pupuli has been working on replacements for a while. We believe that developer tools should be small and purpose-built rather than trying to jam pack all the things for all the people into a single massively overloaded tool.
Rather than using the exact same command used to
- create a module from a template
- run unit testing in CI pipeline
- manage installed Puppet versions
- build and publish modules
- drop into the debugger REPL that you probably didn’t even know existed,
Vox Pupuli’s toolkit includes smaller tools that do one or two things well instead of being mediocre at trying to do everything.
For example, our modulesync tool makes it easy to create, manage, and update
a group of modules based on a template. No more broken dependencies because you
haven’t remembered to update one of your modules for the last four years. All
your modules, whether that’s one or one hundred, will be in a consistent state
and tested against your current infrastructure.
Or you can get zero-install access to a whole suite of module testing and
management tasks with
voxbox. Update your module’s metadata, validate all of its dependencies,
and publish a new version all with a few podman commands.
The Vox Pupuli Devkit SDK
Now that easy access to the PDK is disappearing, we’ve put together a project
to collect all these tools and more into a coherent suite that’s usable,
discoverable, and maintainable. We’ll build the missing parts along the way. For
example, I’m currently working on an asdf / mise plugin to easily manage
OpenVox versions using an industry standard tool rather than something bespoke
that’s constrained to very specific and limited workflows.
We don’t have a timeline on this yet. But luckily, there’s not much development on the PDK except to make it harder for you to use. You can very likely simply continue to use the version you already have installed until we have more news for you.
Watch this space and we’ll soon have information for you about the new Devkit SDK!