My take on improving swamp extensions
by Jean-Philippe Evrard (employee post)TL;DR: Swamp extensions could learn from decades of Linux packaging wisdom. This post is a concrete (start of) proposal for a "swamp forge" to close the gap, based on what OBS and AUR got right.
The problem of lacking incentives
In my last post, I promised to come back with ideas on how to fix the extension system. The comparison I keep reaching for is Linux packaging.
If you want a package for niche software, you probably have to craft it yourself. That's not hard. But the real incentive to publish it properly, rather than keep it local, comes from the ecosystem. Your package interoperates with other packages. It interconnects with humans. People could pick it up when you cannot work on it anymore. Its long-term maintenance becomes proportional to how useful it turns out to be.
Swamp extensions don't have that pull. If you only maintain a handful, there's no personal pain from skipping the proper workflow. The gamification on swamp.club is the main incentive right now. That's not enough. The incentive has to come from the ecosystem itself: if you package an extension, you should ideally benefit from it in the long term without much ongoing effort.
What OBS got right
OBS (OpenSUSE Build Service, not the broadcasting software) is worth studying. Take any package on build.opensuse.org and you immediately see what the package contains, who did what and when, what it's been tested against, where it's used, the full changelog, and who owns it. The collaborative history is explicit: personX accepted request N from personY on date D.
That last point matters most. If you are a new contributor, you can see why certain decisions were made. If you were a one-shot contributor, there is a real chance someone will take over your work if it proves useful. If it does not, others can mark it as abandoned rather than leave it to rot silently.
What AUR got right
AUR (the Arch User Repository) is a simpler, more modern take on the same problem. It leans on git, which makes the contribution model feel familiar.
Browse any package on aur.archlinux.org and you get metadata, maintainer roles, submission history, dependency graph, changelog, and comments. When logged in you can flag a package as out of date, vote for it, or submit a request. Contributing feels like git because it is git, but fully integrated into Arch's ecosystem. Yet, you do not need to understand how it works under the hood.
That's very close to what swamp extensions could be.
Where swamp falls short
Right now, swamp.club/extensions gives you the package name and latest version, a readme, what the extension does, a quality indicator, download count, a git link, and some labels.
That's a good start. What's missing: collaborative history (who accepted what from whom, and when), a changelog you can actually follow, real test logs rather than a checklist, dependency information, a contact mechanism, and lifecycle events (Disowning, marking as out of date, marking as ready for core, posting comments, submitting change requests...).
The extension feels like a side quest. It should not. It must not, for the sake of our field.
A proposal: the swamp forge
Here's how to close the gap.
Swamp.club provides a default swamp forge: a hosted git service where each extension gets its own repository, owned by swamp.club. The page swamp.club/extensions/<extension_name> becomes the front-facing interface to that repository. By owning the repo, swamp.club can provide common access control and lifecycle management.
An API or web interface creates the extension and provisions its git repository at, for example, git-extensions.swamp.club/<extension_name>. The creator becomes package owner by default. Owners get write access to unprotected branches. The main branch is protected and owned by swamp.club to enforce quality requirements. Owners can grant access to collectives or individuals, with an auditable trail.
Merges from unprotected branches to main go through an API or web interface. This is where git earns its keep: easy diffs, content hashing, versioning, changelog generation. Each merge records who approved what. The API can also record the reason of the change, giving real historical context, saved in a git commit.
Merges trigger CI jobs. Swamp.club provides default quality checks, with the ability to plug in external jobs. The swamp CLI can nudge users to contribute back at creation or modification time, surfacing the right path rather than making it optional.
All discussion happens in one place, with notifications to the owner's inbox. Any user can flag an extension as out of date or nominate it for "core" inclusion/popularity. Owners can disown cleanly. You can do all of this from the CLI with a swamp.club account, with no git internals required.
Add the existing gamification on top, and extensions stop feeling like extra credit. They become part of the natural experience of being in the club.
The obvious counterargument
The obvious pushback is scope. Swamp.club is not GitHub. Building a forge is a significant investment, and plenty of extensions could live on GitHub with a pointer from the registry. But the point of the forge isn't to host code that already has a home. It's to change the incentive structure, especially for everything that doesn't yet (e.g. forks).
GitHub doesn't know what a swamp extension is! It can't auto-generate changelogs from merge metadata, enforce quality checks, or surface a "mark as ready for core" signal to the right people. Generic git hosting is necessary but not sufficient.
What would change my mind: if swamp.club committed to first-class GitHub integration that replicated all of the above. That's a different path to the same goal. I'd take it :)
[1] Companies wanting a private collaborative space could pay for their own swamp forge instance. That's one way to promote internal reuse in a way that generic git hosting never quite manages.