The fkra journal
· 3 min· 63 reads

Everyone is quietly building on the same three companies

"Alternatives to GitHub" is really a thread about how much of a team's working knowledge is stored in a vendor's interface rather than their own heads.

An "Ask HN" thread collecting alternatives to GitHub went wide this week. The trigger was the outage. The question underneath it is much older, and it is not really about hosting.

Most of the answers were about features and pricing, which is the boring part. The interesting part was in the replies from people who had actually migrated, because they all described the same surprise.

Git is portable by design. That was the entire point of it. You can clone the whole history onto a laptop and walk out of the building with it.

What is not portable is everything that grew around it. The review conventions nobody wrote down. The issue taxonomy that made sense in 2021 and has been load-bearing ever since. The CI configuration that quietly encodes six years of hard-won knowledge about which tests are flaky and why, in the form of retries nobody dares remove.

What actually moves when you change host
Illustrative. Git is portable by design; the practice that grew around it has no export button.

So teams discover mid-migration that a surprising amount of their engineering practice was stored in a vendor's UI affordances. That is not a licensing problem. It is a memory problem — the practice was never written anywhere a human could read it independently of the tool enforcing it.

There is a cheap way to find out how much of this applies to you, and it costs an afternoon rather than a migration.

Ask someone to describe your team's path from a merged pull request to production, without opening the tool. Where they hesitate is where the knowledge has been externalised.

And that hesitation shows up somewhere else too: it is exactly where onboarding is slowest. A new joiner cannot read a UI affordance. They can only be shown it, which means that knowledge transfers at the speed of somebody else's availability — and disappears entirely when that somebody changes team.

None of this is an argument for leaving. The concentration is usually a rational trade: you get an enormous amount of working practice for free, and rebuilding it yourself would be a poor use of a decade.

The argument is narrower than that. Know which parts of your practice you could carry out by hand, and accept that the rest is rented. That is a perfectly fine position — as long as it is a decision you made rather than a discovery you are about to make.

If you want a concrete next step: write down the five paths that would hurt most to lose — deploy, rollback, release, access review, incident escalation — as instructions a competent person could follow from a plain document.

You are not doing it to leave. You are doing it because writing it down is the only reliable way to find out that three of the five live entirely inside one person's habits.

0
63 views
dependenciesportabilitycompany-memory
MA
mosab alrasheed
Get the next entry

One email when we publish. Research, product decisions, and what teams report back.