a newsletter on infrastructure sovereignty https://mathewstorm.ca/newsletter/ 2026-05-28T00:00:00Z Mathew Storm https://mathewstorm.ca/newsletter/a-forge-of-your-own.html 2026-05-28T00:00:00Z 2026-05-28T00:00:00Z

GitHub is fracturing, but the more interesting story is what was never there in the first place. The forge layer has an open answer already running 320,000 projects in production.

<p>GitHub is fracturing. Zig left in December, Ghostty in April, both citing reliability. Three outages in January took the platform offline for a combined 14 hours - millions of projects unable to handle their core workflow. The platform 100 million developers depend on is changing under their feet, and most haven't decided whether they're staying.</p> <p>The more interesting story isn't who's leaving. It's what was never there in the first place. Garage - the open s3 storage engine - lives on Deuxfleurs' own forge. PeerTube lives on Framagit, a community-run GitLab instance maintained by the nonprofit Framasoft. Neither has ever run their development workflow on GitHub. Both ship serious software that runs in production at scale. There has always been a parallel ecosystem of open source infrastructure that exists outside of GitHub. That ecosystem is only growing larger.</p> <p>If you run an organization that ships code, this is the year that decision becomes yours. The good news is that the answer already exists, in production, hosting roughly 320,000 projects. I started running it last year.</p> <p>The forge is called Forgejo - open source, self-hosted, AGPL-licensed, maintained by Codeberg e.V., a nonprofit in Berlin. Codeberg runs the flagship public instance. I run two of my own: a private one for my company's internal source, and gitforge.ca, a public generalist forge anyone can sign up for. Both on Canadian VPS hardware I operate.</p> <p><img src="/media/images/newsletter/inline/codeberg-forgejo-website.png" alt="The Forgejo project website on codeberg.org, showing the open-source, self-hosted forge." /></p> <p><em>(Reference: codeberg.org/forgejo/website)</em></p> <p>On the day-to-day, Forgejo works the way GitHub works: pull requests, issues, wikis, releases, container registries, built-in CI through Forgejo Actions. SSH and HTTPS push. Custom domains. Migration tooling that pulls your repos, issues, PRs, and contributor history out of GitHub in one command. The difference is where the bytes live, and who controls them.</p> <h2>More Than Just Source Code</h2> <p>Canadian organizations have spent the last three years moving customer data onto Canadian servers. What didn't move is the place where the company itself is written down. The source code. The PR threads where decisions were debated. The issue history. The design documents. The architectural choices made and rejected. All of it sits on American servers, owned by Microsoft, governed by the US CLOUD Act.</p> <p>Source code isn't an asset like a server is an asset. A server can be swapped for an identical one in another data center; the code can't. The code is the only thing that documents how your business actually works - how it ships features, how it handles bugs, how it integrates with the rest of the world. Every other layer of your stack is replaceable infrastructure. The source code is the company.</p> <p>When you accept GitHub as the answer for the forge layer, you accept Microsoft as the keeper of the document of your company and the document of your career. For most of us, that keeper is now a division of Microsoft called CoreAI. The contract didn't have your signature on it.</p> <h2>Sovereignty Doesn't Stop at the Database</h2> <p>Moving source code to Canadian infrastructure is the invisible part of the same work. The same questions apply: where do the bytes live, who can read them, what jurisdiction governs them, how recoverable is the data if the host has a bad week. The answers should be the same too. They're rarely treated that way.</p> <p>A self-hosted Forgejo instance answers them. Where the bytes live: a Canadian VPS, by your choice. Who can read them: your developers and whoever you've authorized, full stop. What jurisdiction governs them: whichever province the VPS is in. How recoverable: a daily backup to an S3 bucket somewhere is twenty lines of cron.</p> <p>The cost is real - someone has to run it. The cost is also bounded. Forgejo at small-to-medium scale runs on a VPS that costs less per month than a few GitHub Enterprise seats.</p> <h2>For Engineers: Your Career Isn't a Hosted Service</h2> <p>A GitHub profile is a rented résumé. The rent buys real value - visibility on a platform 100 million developers visit, a stable URL recruiters bookmark, a contribution graph that signals consistency to people who care about that signal. The rent also has terms. When the platform changes those terms - the API access, the AI training defaults, the search ranking of your repos - your résumé changes with it.</p> <p>The portfolio version is different. The portfolio version is a domain you own, a forge you control or contribute to, and a record of work that's verifiable wherever it lives. A PR merged to a project on Codeberg is a PR merged. A patch landed in a project hosted on the maintainer's own forge is a patch landed. Git is git. The signed commit you pushed to one forge looks identical on any forge that can read it.</p> <p>The case for portability isn't that GitHub is going away tomorrow. The case is that the document of who you are as an engineer should not be one platform's terms-of-service away from changing form. Hosted profiles get demoted in search results, throttled by API changes, auto-opted into uses of their data the profile owner didn't choose. Those things happen on a regular schedule, even to the most-celebrated accounts on the platform. They don't have to happen to yours - if yours doesn't have to live there.</p> <p>The portable version doesn't require leaving GitHub. It requires having a record of work that doesn't depend on GitHub. A domain at yourname.dev. A forge you contribute to that isn't owned by a trillion-dollar company. A signed commit identity that lets contributors verify your patches across forges. Pieces, not a profile.</p> <h2>What's Happening at GitHub</h2> <p>In August of last year, GitHub was folded into Microsoft's new CoreAI division. CEO Thomas Dohmke left the same month. The platform that 100 million developers depend on stopped being primarily a developer platform and started being primarily an AI strategy.</p> <p>The consequences have stacked up. April 2026 uptime came in at 86% - hours per day of blocked workflows across the platform. In February, GitHub confirmed approximately 3,800 internal repositories had been exfiltrated in a breach detected late last year. On April 24, the terms of service auto-opted every non-enterprise user into AI training on their Copilot interaction data - code, context, navigation patterns. Enterprise contracts were exempt; freelancers and small teams were not.</p> <p>The most public response has come from Mitchell Hashimoto - GitHub user 1299, joined February 2008, founder of HashiCorp, creator of Vagrant, Terraform, and Packer. For the month before his April 28 farewell post, he kept a journal marking an X next to every date a GitHub outage blocked his work. Almost every day got an X. On the day he published the post, GitHub Actions was down for two hours. He summarized:</p> <blockquote> <p>I want to ship software, and it doesn't want me to ship software.</p> <p>— "Ghostty Is Leaving GitHub" by Mitchell Hashimoto</p> </blockquote> <p>When the engineer who built Terraform announces he can't use GitHub for serious work, it's a data point about where the platform's priorities have moved.</p> <p>The intermediate position in this conversation is GitLab - more open than GitHub, supports self-hosting, exposes more of its source. GitLab is also open-core, the structural shape we covered last issue with MinIO: a commercial company running an open-source project as marketing for a paid edition. Better than GitHub, not the same category as Forgejo.</p> <h2>The Open Answer Already Exists</h2> <p>In the first issue we covered Garage - the open-source object storage engine, maintained by the French collective Deuxfleurs, demonstrated in production at scale. The forge layer has the same arrangement, in a different country. Codeberg e.V., a registered nonprofit in Berlin, maintains Forgejo and runs the flagship public instance, which hosts roughly 320,000 projects. These two organizations use the same license, similar governance, and are the same kind of proof.</p> <p>The migration off GitHub is not a research project. The forge software exists. The hosting model is established. The migration tooling pulls your repositories, issues, pull requests, and contributor history out of GitHub in one command. The hard part isn't technical - it's the social-capital question, and that question has a workable answer too. You don't have to delete the GitHub mirror. You just have to stop treating it as the only place where your work is allowed to live.</p> <p>My company's source lives on an internal forge. My open source contributions span three forges. The graphs on each are smaller than the unified one I used to maintain on GitHub. The work hasn't slowed down, only the destination has changed.</p> <aside class="spell-callout spell-callout--info"> <span class="spell-callout-icon" aria-hidden="true">ℹ️</span> <div class="spell-callout-body"> <p>Next issue: the CI/CD layer. Once the forge moves, the next question your team asks is where the workflows go. We'll cover Forgejo Actions, Woodpecker, Drone, and what each costs in complexity versus what each buys in independence.</p> </div> </aside> https://mathewstorm.ca/newsletter/the-internet-wasnt-inevitable.html 2026-05-14T00:00:00Z 2026-05-14T00:00:00Z

Three layers of infrastructure had to fight to become open: Linux won, Django won, and now the storage layer is being decided.

<p>In 1995, if you wanted to put a website on the internet, you would be forking over a lot of money in licensing fees for basic software like Operating Systems or Web Servers, and the company that sold them to you had final say over what you could do with them. The open internet you know today - the one where a teenager can spin up a server in a dorm room and reach a billion people - wasn't inevitable. It was the result of a specific bet that, at the time, almost everyone thought was foolish.</p> <p>The bet was Linux: that an operating system built and given away for free could outperform what trillion-dollar companies were selling. The bet won.</p> <p>If Microsoft or Sun had won the early infrastructure battle, the internet would not exist the way you know it. Not as a metaphor - as a literal statement about which servers would be allowed to talk to which clients, which protocols would be permitted, and which startups would have been licensed out of existence before they shipped. The fact that the modern web is mostly open is not a gift from the companies that owned most of it. It's the residue of a fight they lost.</p> <h2>Layer One: Linux</h2> <p>You probably don't think about Linux. That's how completely it won. It runs your phone if it's an Android. It runs the server that delivered this newsletter to you. It runs the routers between your laptop and that server, every one of the world's top 500 supercomputers, and the in-flight entertainment system on the plane you most recently flew. Infrastructure is most successful when you stop noticing it.</p> <p><img src="/media/images/newsletter/inline/linux-market-2025.png" alt="Bar chart: the global Linux operating system market growing from $7.64 billion in 2024 to $18.73 billion in 2029, a 19.8% CAGR." /></p> <p><em>(Reference: The Business Research Company)</em></p> <p>The completeness of the win is the part that's easy to forget. In 2001, Microsoft's CEO Steve Ballmer called Linux "a cancer that attaches itself in an intellectual property sense to everything it touches." In 2014, the next Microsoft CEO stood on a stage and said "Microsoft loves Linux." Today, the Microsoft Azure fleet runs more Linux instances than Windows ones. The company that fought hardest to keep the open layer from existing now makes most of its cloud revenue serving it.</p> <p>The reason it won is the reason it keeps winning whenever the same fight gets fought one layer up. Closed software has to be paid for, which means every line has to be justified to someone's quarterly numbers. Open software gets written by a coalition - sometimes hobbyists, more often paid engineers at companies that all depend on the same code and have decided cooperating on it is cheaper than each maintaining their own fork. Linux is maintained today by thousands of developers, the majority of them paid by companies like Red Hat, Google, Intel, and yes, Microsoft. The work is real work. The difference is that no single one of them owns it.</p> <h2>Layer Two: Django</h2> <p>The same fight got fought at the application layer in the late 2000s, and the same side won. The expensive answer was a Java EE application server from Oracle, IBM's WebSphere, or Microsoft's .NET stack - software you paid licensing fees for, deployed onto hardware you also paid for, and could not modify without violating your support contract. The free answer was Django, a Python web framework released in 2005 by two newspaper developers in Lawrence, Kansas, who needed to ship local news sites faster than their deadlines allowed. They gave it away, letting it get used and improved by the community.</p> <p>By 2012, Instagram was serving a hundred million users on Django. By 2019, it was serving a billion. The proprietary application servers that Oracle and IBM had spent decades selling to enterprise customers are still around, technically - you can still buy WebLogic if you want to - but no new company has started a serious project on one in years. The framework layer is open the same way the operating system layer is open: not because the closed vendors gave up the fight, but because the open option got so good that paying for the closed one stopped making sense.</p> <p><img src="/media/images/newsletter/inline/instagram-backend-stack.png" alt="Diagram of Instagram&#39;s backend tech stack: Nginx fronting Django and Celery, all backed by Cassandra, PostgreSQL, Memcache, and RabbitMQ." /></p> <p><em>(Reference: Ollayor's Blog)</em></p> <p>Two layers down, both fought and won. The third one is where we are now - and the closed vendor this time is not Microsoft or Oracle. It's Amazon.</p> <h2>Layer Three: Where We Are Now</h2> <p>The closed answer is AWS S3, which is so deeply assumed as the default that "S3" has become a generic noun for object storage the way "Kleenex" is for tissues. It's a remarkable product. It's also a single American company holding the data of most of the internet, under American jurisdiction, at prices that change when the company decides they change, with a feature set that grows when the company decides it grows. For most of the past decade, the open answer was MinIO - until MinIO's company changed its license, gutted its open-source release, and effectively shut down the project in February 2026. Tens of thousands of organizations woke up to find that the open storage layer they'd built on was no longer open.</p> <p>The answer that has been quietly waiting for that moment is Garage. It's an S3-compatible object storage engine, written in Rust, AGPL-licensed, designed from the start to run on heterogeneous hardware across multiple geographies - exactly the shape of infrastructure that small operators and sovereignty-conscious organizations actually have. It's built and maintained by Deuxfleurs, a French collective that uses Garage to host their own services. You can read every line of code that holds your data. If you find a bug, you can fix it - last week I submitted a one-line patch that was merged into the main branch within hours. The barrier to participating in the infrastructure you depend on is, for the first time at the storage layer, low enough to walk over.</p> <p>The MinIO failure is the right thing to study before betting on the next open option. MinIO was a VC-backed company that open-sourced its product to drive adoption, then changed the license when that adoption didn't convert to enough revenue to satisfy investors. That's the open-core trap, and it's specific to a particular structure: an open project owned by a single commercial entity whose board has fiduciary obligations to capture more of the value it creates.</p> <h2>The Pattern Itself</h2> <p>Garage is one specific answer, but the bigger answer is the pattern itself.</p> <p>Every layer of the modern internet became open because some group of people built the alternative before there was a customer base waiting for it, and ran it themselves long enough to prove it worked. Linux ran on hobbyist machines for years before it ran the stock exchange. Django ran a few local news sites before it ran Instagram. Garage runs Deuxfleurs and, increasingly, the small infrastructure projects that have been quietly choosing it over the American defaults. The third layer is being decided right now. The companies best positioned for the next decade will be the ones that picked the open option early - not because it was morally virtuous, but because they were unwilling to bet the most valuable thing they own on a vendor whose terms they cannot change.</p> <p>Linux took twenty years to become invisible. Django took fifteen to become inevitable. The storage layer is still negotiable.</p> <aside class="spell-callout spell-callout--info"> <span class="spell-callout-icon" aria-hidden="true">ℹ️</span> <div class="spell-callout-body"> <p>This newsletter is about what owning your stack actually looks like in practice - one layer at a time. Next issue looks at the fracturing of GitHub: the rise of self-hosted forges, what it means for your contributions when they don't all live in one place, and how to keep a professional record that doesn't depend on Microsoft maintaining your résumé for you.</p> </div> </aside> <p>Welcome.</p>