1. Introduction
Source forges and git hubs come and go. Being backed by a private company gives them the resources to have reach and gather users, but also tends to doom them to activities that those not desperate for profitability may deem unconscionable.
It is as unfortunate as it is axiomatic that the network effects which make these systems so attractive to venture capital work so well in gathering developers to use them. And so the cycle continues.
2. Self-Hosting
Self-hosting one's own forge is ideal in many ways. It grants a level of autonomy that commercial forges do not provide. However, it also comes with its own drawbacks:
- Other developers are far less likely to sign up and submit pull requests.
- Hosting costs are not zero. Especially if your projects become popular!
- Your projects will likely die when you do. Nuggets of context that could otherwise be mined by future generations will be lost forever.
- Your code is not findable! Nobody will submit pull requests if they cannot find your projects!
Regardless, some degree of autonomy is a necessity, to the extent required to combat the potential decay of centralized platforms. To that end, we believe it is ideal for a modern developer to be autonomously mobile. To be able to jump from one forge to the next (or straddle more than one!) with relatively little difficulty.
There are a few ways to go about this. The worst of all possible worlds is to eschew code forges altogether. This loses engagement, discoverability, and longevity while still requiring hosting costs. There are also peer-to-peer solutions like Radicle, which are intriguing due to their theoretical longevity, though these are currently hampered by their esoteric nature.
3. The Hybrid Approach
While not perfect, our current solution is a self-hosted platform that pushes updates to several other platforms on a regular basis. This approach brings some of the benefits of self-hosting, while minimizing the costs:
- Nobody has to sign up to your site!
- Hosting costs are less (or nothing, if you simply run your central forge on your own network, pushing all updates to public repos on public forges!)
- Your projects will live as long as the longest-lived forge on which they exist.
- Your code can be found!
Of course, there are still drawbacks. This is certainly a more complicated solution than any of its constituent parts! Additionally: as much as your code becomes available to fellow humans, it may also be incorporated into machine learning algorithms. This latter drawback may be mitigated by careful selection of the forges you push to, at the cost of some significant share of reach.
4. Forgejo
For this plan, we use Forgejo. It can be hosted in a container, a FreeBSD jail, or whatever works for you. It's written in Go and consequently, it's very flexible in how you can set it up!
The centerpiece of this plan is Forgejo's Push Mirrors feature. This allows individual repos to be setup to push to one or more remote code forges.
Again, there are tradeoffs: This feature must be setup on each repository, for each remote it pushes to. The remote repositories on the code forge sites must be created manually and one must get OAuth keys from those sites setup beforehand. But this also means that it's a simple matter to not push repos to forges you do not wish them to be present on, and you have fine control over whether you want one key for the whole remote site or individual keys per repo.
5. Pull Requests
Without a doubt, the key benefit to centralized forges is engagement, particularly in the form of issues and pull requests. This situation allows us to merge a pull request on one site, pull it directly down to our local repo, and then push it back up to our self-hosted Forgejo instance. From there, it is pushed back, both to the site on which it originated and any other mirrors present!
This maximizes our reach in a way no individual centralized forge could. Because Forgejo uses force-pushes for our mirroring, it also tends to run smoothly. Just be sure to grab the repo just after the pull request merge, or there's a chance it may be overwritten!
6. Remote Options
Additionally, there is the decision of which sites to host on. We've been making use of the following:
| Centralized Forge | Notes |
|---|---|
| GitHub | Great reach and engagement, but they do train their ML on your code! |
| CodeBerg | Non-profit, but their discovery tools and engagement are still in their infancy stages. |
| WorkTree | Canadian-aligned. |
| SourceForge | They still exist! But they do not seem to support OAuth2. You must use your account password. |