Když Mitchell Hashimoto 28. dubna 2026 oznámil, že Ghostty odejde z GitHubu, nebyla to běžná stížnost na výpadek služby. Hashimoto je na GitHubu od února 2008, má uživatelské číslo 1299 a podle vlastního textu platformu otevíral prakticky denně více než 18 let. Jeho odchod proto působí jinak než nespokojený komentář po jednom pokaženém odpoledni.

V příspěvku Ghostty Is Leaving GitHub píše, že problém není Git. Vadí mu infrastruktura kolem něj: issues, pull requesty, Actions a další části práce, bez kterých projekt běžně nefunguje. Zdroják o tom informoval ve zprávičce Ghostty opouští GitHub po 18 letech. Zpráva ale míří dál než k jednomu terminálovému emulátoru. Ukazuje, jak málo dnes znamená samotná věta „kód je přece v Gitu“.

Repozitář přenesete. Týmový provoz se stěhuje hůř

U GitHubu se snadno namítne, že o klasický vendor lock-in nejde. Git je distribuovaný, repozitář lze naklonovat, změnit remote a přesunout na GitLab, Codeberg, Forgejo, SourceHut nebo vlastní server. Historie commitů neleží v uzavřeném formátu, který by otevřel jen jeden produkt.

Jenže moderní projekt na GitHubu obvykle nemá jen Git repozitář. Má tam pull requesty s review historií, issues, projektové boardy, workflow v GitHub Actions, secrets, branch protections, rulesets, package registry, bezpečnostní upozornění, Dependabot, CodeQL a někdy také Copilot v review nebo při práci nad issues. Migrace pak není změna git remote. Je to stěhování celého pracovního prostředí.

Paralela se SourceForge proto není v konkrétních chybách. GitHub neopakuje stejný příběh a není to stejný produkt v novém kabátě. Podobnost je jinde: z místa pro projekt se stalo prostředí, kde projekt žije. Jakmile se v něm usadí infrastruktura, reputace a návyky komunity, odchod začne být problém mimo samotný kód.

GitHub kdysi vyhrál přehlednějším workflow

GitHub uspěl, protože spolupráce nad kódem najednou působila přirozeněji. Fork byl viditelný, pull request měl jasné místo, webové rozhraní bylo přehlednější a sociální vrstva kolem projektu nepůsobila jako přilepený doplněk. GitHub nebyl lepší jen tím, že hostoval Git repozitáře. Změnil běžný postup, jak se do open source projektu posílá změna. GitHub už není jen rozhraní nad repozitářem. Tým tam plánuje práci, spouští buildy, publikuje balíčky, nastavuje bezpečnostní pravidla a čím dál častěji pouští AI agenty k běžným úkolům.

Lock-in vzniká po malých rozumných krocích

GitHub dnes drží pohromadě věci, které dříve často běžely vedle sebe. GitHub Actions řeší CI/CD a automatizace. GitHub Packages spojuje registry s repozitáři a oprávněními. Projects přesouvají plánování práce přímo nad issues a pull requesty. Code scanning, Dependabot a další bezpečnostní funkce dělají z repozitáře také bezpečnostní frontu.

Pro menší tým je to pohodlné. Nemusí provozovat vlastní CI server, registry, board, bezpečnostní skenery a boty pro pull requesty. Všechno běží pod stejnými účty, se stejnými oprávněními a ve stejném proudu notifikací.

Závislost přitom nevznikne jedním velkým rozhodnutím. Tým nejdřív přidá workflow pro release. Pak automatické štítkování, cache v Actions, branch protection, Dependabot, publikování balíčků, projektový board, OIDC napojení do cloudu a nakonec AI review. Každý krok dává sám o sobě smysl. Dohromady z nich ale vznikne provozní model, který se nepřenáší tak snadno jako repozitář.

AI agenti posouvají závislost do procesu

Nejnovější vrstva je AI. Původní Copilot byl hlavně asistent v editoru. Takový nástroj se dá vyměnit poměrně snadno: jeden doplňuje kód ve VS Code, jiný v JetBrains, další běží v terminálu. Jakmile se ale AI přesune do issues, pull requestů a CI, už nejde jen o editor.

Copilot cloud agent podle dokumentace umí zkoumat repozitář, připravit plán, dělat změny na větvi a podle zadání otevřít pull request. Pracuje v dočasném vývojovém prostředí poháněném GitHub Actions a úkoly může dostávat z GitHubu, z issues nebo z dalších vstupních míst. GitHub zároveň představil Agent HQ, tedy rozhraní pro práci s agenty od více dodavatelů přímo nad GitHubem.

V tu chvíli už není hlavní otázka, jestli tým používá Copilot, Codex, Claude Code nebo jiný nástroj. Důležitější je, kde agent pracuje, jak dostává oprávnění, jak vytváří větve, kdo kontroluje jeho pull requesty a z jakého rozpočtu se platí jeho běh. GitHub v dubnu 2026 oznámil, že Copilot přechází od 1. června 2026 na účtování podle GitHub AI Credits. AI se tím posouvá do stejného prostoru jako buildy a review.

Ghostty, Zig a Gentoo ukazují tři různé reakce

Odchody z GitHubu zatím nevypadají jako masový exodus. Spíš jde o jednotlivé případy, na kterých je vidět, co různým maintainerům vadí.

Ghostty ukazuje provozní frustraci. Hashimoto neodchází kvůli obecné debatě o decentralizaci. Vadí mu, že výpadky a problémy GitHubu zasahují review, CI a běžnou práci maintainerů. GitHub ve svém availability reportu za duben 2026 uvádí deset incidentů s dopadem na služby. Incident z 27. dubna se dotkl služeb závislých na vyhledávání, včetně Issues, Pull Requests, Projects, Repositories, Actions, Package Registry a Dependabot Alerts. Ten výčet dobře ukazuje, proč už nejde jen o dostupnost repozitáře.

Zig zvolil ostřejší postup. V oznámení Migrating from GitHub to Codeberg Andrew Kelley mluví o agresivním vendor lock-inu, udělal repozitář ziglang/zig na GitHubu read-only a vývoj nově vede na Codebergu. Důležitá je hlavně migrační taktika: staré issues zůstaly na GitHubu, nové číslování na Codebergu začalo od 30000 a komunita má přesouvat jen věci, které potřebuje dál editovat. Velký projekt nemusí přenést historii dokonale. Stačí přepnout budoucí práci.

Gentoo podle The Register přesouvá contribution workflow a zrcadla na Codeberg hlavně kvůli tlaku Copilotu v repozitářích. Vlastní primární Git a bug tracking si přitom ponechává. To je třetí model: GitHub nemusí zmizet ze dne na den, stačí mu odebrat roli místa, kde se projekt skutečně odehrává.

Používat GitHub ano, ale vědět proč

Závěr nemusí znít: GitHub je nová SourceForge, odejděte. GitHub pořád řeší mnoho praktických problémů dobře a pro řadu týmů bude dál nejlepší volbou. Integrovaná platforma není chyba. Šetří čas, sjednocuje oprávnění a dává menším týmům funkce, které by samy těžko provozovaly.

Užitečnější kontrolní otázka zní: ví tým, které části jeho práce jsou přenositelné a které už jsou platformní dluh?

Buildy je dobré držet co nejvíc ve standardních skriptech a kontejnerech, ne jen v akcích z Marketplace. Release postup by měl být čitelný i mimo GitHub Actions. U secrets, OIDC a oprávnění má smysl vědět, co by migrace znamenala. U package registry je dobré mít plán, jak by vypadalo publikování jinam. U issues a projektových boardů se vyplatí aspoň občas ověřit exportní cestu. U AI agentů nestačí řešit jen kvalitu výstupu. Tým potřebuje znát hranice oprávnění, náklady, audit a pravidla pro review.

GitHub kdysi uspěl jako opak SourceForge, protože vývojářům ukázal, že spolupráce nad kódem nemusí znamenat zmatek ve verzích. Dnešní riziko je jiné: spolupráce může být tak pohodlná, až tým přehlédne, kolik rozhodnutí už za něj dělá jedna platforma.

Repozitář půjde odnést skoro vždycky. Otázka je, kolik práce, historie, automatizace a návyků zůstane viset kolem něj.