My experience with swamp extensions
by Jean-Philippe Evrard (employee post)TL;DR: The swamp extension ecosystem has potential. Sadly, using it collaboratively has enough friction that the shortcut is usually faster, making it partially broken.
Here's what led me there.
The first near-miss
When I started extending swamp for my own infrastructure, Claude' suggestion was to write shell scripts. It would have worked. It also would have meant ignoring an existing (featureful) extension that already did what I needed.
The ecosystem existed; I nearly walked straight past it. That felt like a warning sign worth holding onto.
The extension route: The libvirt extension and the SSH problem
I found a libvirt extension that was close but not quite right. It bundled SSH as part of its logic, which is not stricto sensu related to libvirt itself. My environment didn't support SSH the way the extension expected. I didn't want to SSH into localhost to make libvirt work. The extension sharing failed in exactly the way any Ansible role would fail when handed an environment it wasn't written for.
So I forked it and stripped it down to pure libvirt.
I could have kept that fork private. It would have been the quickest path. It also would have been a waste. Extensions exist to be shared. A private fork helps no one. I pushed it publicly.
I love this community... Plus, code got merged!
Sergey (magistr) found my fork, incorporated my changes into his own extension, and was genuinely kind about the whole thing. That's exactly what I hoped for, in terms of community collaboration.
His updated extension made mine redundant. Which raised a question: what do I do with the fork?
Yanking it with no migration path is a bad look, even when you're reasonably confident you're the only user. What if you're wrong? What if someone found it, quietly started depending on it, and never told you? Pulling it without warning leaves them stranded.
In my case, I was probably the only user. I will go far with my wishful thinking.
Enter a new collective! The bad-at-naming collective
Rather than leave the fork floating, Sergey and I agreed to collaborate properly. We created a swamp collective: bad-at-naming (the name tells you something about how seriously we take our own branding). The plan was to host shared extensions there, collaborate openly, and avoid the fork-proliferation problem we'd just lived through. I moved to using bad-at-naming/libvirt.
Hurdles are natural
At that point, I found a bug. I worked through the fix, tested it locally, confirmed it worked. Then I opened a PR. Against Sergey's personal repository, because bad-at-naming/libvirt was still actually hosted in his personal git space, not the collective's.
The mechanics of where the repo lives, who reviews what, who merges what, and how changes flow back hadn't been sorted out from the extension perspective, and is directly put as work for the implementer/collective...
At the same time, the quickest path to a working extension is still to fix it locally and skip the upstream.
I have had the same issue with other extensions. It's not a problem of ONE extension. It's a problem of swamp extensions's user experience for the long term.
What this means
Every time I tried to do the right thing, there was friction. Not insurmountable. Not anyone's fault specifically. Just the accumulated drag of a process that hasn't been made easy enough yet.
The shell script is always faster. The private fork is always less hassle. A series of git repos to configure or share ownership.
Swamp is so powerful however, it could have helped. It can help open issues for itself. What we don't have yet is a process that makes collaboration the natural choice rather than the heroic one.
I'll write about what I think needs to change in a follow-up post.