gik|iewicz

Mitchell Hashimoto, użytkownik GitHub #1299, dołączył do platformy w lutym 2008 roku. Po 18 latach współtwórca HashiCorp przenosi projekt Ghostty gdzie indziej. Powód? Chroniczne awarie, które uniemożliwiają normalną pracę.

TL;DR: Mitchell Hashimoto przenosi terminal Ghostty z GitHub po 18 latach korzystania z platformy. W kwietniu 2026 złych dni było więcej niż dobrych. GitHub stał się zawodny dla poważnej pracy programistycznej. Hashimoto szuka alternatywy.

Źródło: Ghostty Is Leaving GitHub – Mitchell Hashimoto

Dlaczego Mitchell Hashimoto porzuca GitHub po 18 latach?

Mitchell Hashimoto to nie przypadkowy użytkownik. To współtwórca HashiCorp, firmy sprzedanej IBM, autor Vagrant i Terraform. Jego konto na GitHub ma numer #1299 – dołączył w lutym 2008, gdy platforma była w powijakach. Przez niemal dwie dekady opierał na niej swoje projekty open source i komercyjne. Ghostty, jego nowy emulator terminala, również tam trafił.

Źródło: Ghostty is ditching GitHub over chronic reliability failures, and no one knows where it’s going yet

Jednak relacja z platformą uległa pogorszeniu. Hashimoto udokumentował miesiące ciągłych awarii GitHub, które blokowały rozwój Ghostty. Jak napisał w swoim blogu: „I can’t code with GitHub anymore.” To silne słowa od kogoś, kto spędził na platformie połowę życia zawodowego.

Co więcej, jego krytyka jest bardzo osobista. Na Lobsters napisał, że kocha GitHub bardziej niż człowiek powinien kochać rzecz, i jest na niego zły. To nie chłodna decyzja biznesowa. To frustracja kogoś, kto czuje zawód ze strony narzędzia, któremu ufał przez lata.

Jakie problemy z niezawodnością GitHub udokumentował twórca Ghostty?

Hashimoto nie rzuca oskarżeń bez dowodów. Przez miesiące dokumentował awarie GitHub, które wpływały na jego codzienną pracę nad Ghostty. W kwietniu 2026 złych dni było więcej niż dobrych – platforma działała prawidłowo rzadziej niż psuła się. To absurdalna sytuacja dla narzędzia, od którego zależą miliony programistów.

Na Lobsters jeden z komentatorów zauważył coś wymownego. Wpis Hashimoto zawiera wiele przypisów w stylu: „Nie, nie ta awaria, tamte inne.” To pokazuje skalę problemu – awarii było tak dużo, że trzeba je było rozróżniać.

Zatem problemy dotyczyły wielu aspektów platformy. GitHub Actions, system pull requests, interfejs webowy – wszystko to zawodziło w nieprzewidywalnych momentach. Dla twórcy aktywnie rozwijającego projekt open source oznacza to przestoje, frustrację i utracony czas.

Oto lista najczęstszych problemów z GitHub udokumentowanych przez społeczność:

• Awarie GitHub Actions uniemożliwiające CI/CD
• Niedostępność interfejsu webowego repozytoriów
• Problemy z pull requests i code review
• Opóźnienia w powiadomieniach i webhookach
• Błędy w renderowaniu Markdown
• Problemy z dostępnością API
• Niespójne czasy odpowiedzi strony
• Awarie systemu Issues i dyskusji

Co to oznacza dla ekosystemu open source?

Odejście tak wpływowego programisty z GitHub to sygnał dla całej społeczności. Hashimoto to nie jedyna osoba frustrująca się niezawodnością platformy. Jego głos jest po prostu najgłośniejszy, bo ma za sobą autorytet HashiCorp, Vagrant i Terraform.

Projekty open source zależą od platformy hostingowej kodu. Jeśli platforma zawodzi, praca nad projektami się zatrzymuje. Dla małych projektów to irytujące. Dla dużych, aktywnie rozwijanych jak Ghostty, to bezpośrednie zagrożenie dla produktywności.

Ponadto GitHub ma pozycję monopolisty w hostingu kodu. Większość projektów open source tam rezyduje. Gdy platforma ma problemy, cały ekosystem odczuwa skutki. Odejście Hashimoto pokazuje, że nawet tak zakorzeniony użytkownik może zrezygnować, gdy zawodność przekracza pewien próg.

Gdzie Ghostty się przeniesie?

Na ten moment nie wiadomo. Hashimoto napisał, że podzieli się szczegółami dotyczącymi nowej lokalizacji projektu w najbliższym czasie. To oznacza, że decyzja o migracji zapadła, ale nowa platforma nie została jeszcze ogłoszona.

Możliwe kierunki migracji obejmują kilka opcji. GitLab, SourceHut, Codeberg, Gitea – to platformy, które regularnie pojawiają się w dyskusjach jako alternatywy dla GitHub. Każda z nich ma inną filozofię i inny model biznesowy.

Co więcej, Hashimoto może wybrać self-hosting. Jego doświadczenie z infrastrukturą w HashiCorp sugeruje, że potrafi samodzielnie zarządzać serwerami. W takim przypadku Ghostty mógłby trafić na własną instancję Gitea lub Forgejo. Jednak to wymagałoby dodatkowych zasobów na utrzymanie.

Z kolei wybór platformy ma znaczenie dla społeczności Ghostty. Kontrybutorzy muszą założyć konta w nowym miejscu. Procesy code review, CI/CD, zarządzanie issue – wszystko trzeba odbudować. Migracja projektu to nie tylko przeniesienie kodu.

Jak społeczność zareagowała na decyzję o migracji Ghostty?

Decyzja Hashimoto wywołała szeroką dyskusję na platformach takich jak Lobsters i Hacker News. Komentatorzy podzielili się na dwa obozy – jedni wspierają krok programisty, inni wskazują na ryzyko fragmentacji ekosystemu. Wątek na Lobsters zebrał dziesiątki odpowiedzi, z których wiele potwierdza własne problemy z niezawodnością GitHub.

Reakcja społeczności pokazuje skalę frustracji. Programiści od lat zgłaszają awarie GitHub, ale głos Hashimoto ma szczególny ciężar. Jego autorytet jako współtwórcy HashiCorp sprawia, że opinie te trafiają do szerszego grona. Na Lobsters jeden z użytkowników zauważył wymowny szczegół – wpis Hashimoto zawiera wiele przypisów w stylu „nie, nie ta awaria, tamte inne.” To pokazuje, że problem jest systemowy.

Ponadto wielu komentatorów dzieli się własnymi doświadczeniami. Awarie GitHub Actions, problemy z interfejsem webowym, opóźnienia w powiadomieniach – to codzienność dla wielu zespołów. Jednakże niewielu decyduje się na tak radykalny krok jak pełna migracja projektu.

Oto najczęstsze reakcje społeczności na decyzję Hashimoto:

• Wsparcie dla decyzji i współdzielenie frustracji
• Pytania o docelową platformę dla Ghostty
• Obawy o fragmentację ekosystemu open source
• Wezwania do GitHub do poprawy niezawodności
• Dyskusje o alternatywach takich jak SourceHut czy Codeberg
• Porównania z poprzednimi migracjami projektów
• Apel o decentralizację hostingu kodu
• Wątpliwości o wpływ na kontrybutorów Ghostty

Jakie są realne alternatywy dla GitHub?

GitHub dominuje na rynku hostingu kodu, ale istnieje kilka platform, które mogą zastąpić go dla projektów open source. Każda z nich ma inną filozofię, model biznesowy i poziom dojrzałości. Wybór zależy od priorytetów projektu – niezawodności, wolności oprogramowania, czy łatwości współpracy.

GitLab to najczęstszy wymieniany konkurent GitHub. Oferuje podobną funkcjonalność – repozytoria, CI/CD, code review, issue tracking. Ponadto może być hostowany samodzielnie, co daje pełną kontrolę nad infrastrukturą. Dla kogoś z doświadczeniem infrastrukturalnym Hashimoto to istotna zaleta.

Z kolei SourceHut przyjmuje inne podejście. Platforma opiera się na liście mailingowej i prostych narzędziach, unikając ciężkiego interfejsu webowego. Codeberg to opcja oparta na Forgejo, wolnym oprogramowaniu, hostowana w Niemczech. Gitea i Forgejo pozwalają na self-hosting z pełną kontrolą.

Czego ta sytuacja uczy o ryzyku zależności od jednej platformy?

Przypadek Ghostty ilustruje problem vendor lock-in w kontekście platform hostingowych kodu. Projekt, który opiera się na jednym dostawcy, staje się bezbronny wobec jego awarii. Hashimoto spędził na GitHub 18 lat – to niemal cała historia platformy – a mimo to zmuszony jest szukać alternatywy.

Zależność od jednej platformy niesie konkretne ryzyko operacyjne. Gdy GitHub ma awarię, praca nad Ghostty się zatrzymuje. Nie ma planu B. CI/CD nie działa, pull requests są niedostępne, code review zablokowane. W kwietniu 2026 złych dni było więcej niż dobrych, co oznacza, że projekt tracił więcej czasu na czekanie niż na właściwy rozwój.

Dlatego coraz więcej projektów rozważa strategie dywersyfikacji. Mirrorowanie repozytoriów na innych platformach, samodzielne hostowanie CI/CD, trzymanie krytycznych procesów poza GitHub – to sposoby na zmniejszenie ryzyka. Migracja Ghostty to przypadek ekstremalny, ale pokazuje kierunek myślenia.

Co więcej, sytuacja zwraca uwagę na kwestię kontroli nad własnym kodem. Platforma chmurowa to wygoda, ale też zależność. Hashimoto ma zasoby i wiedzę, by przenieść projekt gdzie indziej. Mnóstwo mniejszych projektów nie ma takiej możliwości i zostaje na GitHub niezależnie od jakości usługi.

Jak GitHub reaguje na krytykę dotyczącą niezawodności?

GitHub nie pozostał głuchy na głosy krytyki dotyczące awarii. Platforma publikuje status page i raporty o incydentach, ale zdaniem Hashimoto to za mało. W swoim wpisie napisał, że powrót na GitHub będzie możliwy jedynie pod warunkiem „realnych rezultatów i poprawy, nie słów i obietnic.”

To istotne rozróżnienie. Status page pokazuje, że GitHub wie o problemach. Jednakże dokumentowanie awarii to nie to samo co ich naprawianie. Hashimoto oczekuje poprawy niezawodności, a nie lepszej komunikacji o awariach. To perspektywa kogoś, kto potrzebuje narzędzia do pracy, a nie excusów.

Wobec tego krytyka ze strony tak wpływowego użytkownika to cios wizerunkowy dla GitHub. Mitchell Hashimoto to nie przypadkowy programista – to współtwórca HashiCorp, firmy, której produkty (Vagrant, Terraform) są fundamentem infrastruktury IT na całym świecie. Jego odejście to sygnał dla innych.

Jakie kroki musi podjąć projekt przy migracji z GitHub?

Migracja projektu open source z GitHub to proces logistycznie złożony. Nie wystarczy przenieść kodu – trzeba przenieść cały ekosystem narzędzi i procesów wokół niego. Ghostty to aktywnie rozwijany projekt z kontrybutorami, issue trackerem, CI/CD i procesami code review.

Przede wszystkim trzeba wybrać nową platformę i skonfigurować infrastrukturę. Następnie przenieść repozytorium kodu, historię commitów, tagi i gałęzie. To najprostsza część – Git jest rozproszony, więc kopia kodu jest kompletna u każdego kontrybutora.

Trudniejsza część to procesy społecznościowe. Otwarte issue, pull requests, dyskusje – to wszystko zostaje na GitHub. Kontrybutorzy muszą założyć konta w nowym miejscu. Procesy CI/CD trzeba odbudować od zera, chyba że nowa platforma oferuje kompatybilność z GitHub Actions.

Oto lista kroków wymaganych przy migracji projektu:

• Wybór nowej platformy hostingowej
• Sklonowanie i przeniesienie repozytorium
• Rekonfiguracja CI/CD pipeline
• Migracja otwartych issue i dyskusji
• Poinformowanie kontrybutorów o zmianie
• Aktualizacja dokumentacji i linków
• Przekierowanie starego repozytorium
• Testowanie nowych procesów współpracy

Często zadawane pytania

Dlaczego Mitchell Hashimoto decyduje się na migrację Ghostty właśnie teraz?

Hashimoto udokumentował, że w kwietniu 2026 złych dni na GitHub było więcej niż dobrych (źródło: XDA Developers). Dla aktywnie rozwijanego projektu open source taka zawodność uniemożliwia normalną pracę.

Czy inne projekty open source również planują odejść z GitHub?

Na Lobsters wielu programistów potwierdza problemy z niezawodnością GitHub, ale niewielu podejmuje tak radykalne kroki jak pełna migracja (źródło: Lobsters). Ghostty to przypadek szczególny ze względu na autorytet Hashimoto.

Jakie platformy są realną alternatywą dla GitHub?

GitLab, SourceHut, Codeberg, Gitea i Forgejo to najczęściej wymieniane alternatywy (źródło: dyskusje na Lobsters i Hacker News). Każda z nich oferuje inne podejście do hostingu kodu i współpracy.

Czy migracja projektu z GitHub wpływa na kontrybutorów?

Tak, kontrybutorzy muszą założyć konta na nowej platformie i dostosować swoje procesy pracy. Hashimoto zapowiedział, że podzieli się szczegółami migracji w przyszłości (źródło: mitchellh.com).

Podsumowanie

Przypadek Ghostty i Mitchella Hashimoto rzuca światło na kilka istotnych kwestii dla ekosystemu open source:

• GitHub ma poważne problemy z niezawodnością, które wpływają na produktywność projektów
• Nawet użytkownik z 18-letnim stażem i numerem #1299 może zrezygnować z platformy
• Vendor lock-in w kontekście hostingu kodu to realne ryzyko operacyjne
• Istnieją alternatywy – GitLab, SourceHut, Codeberg, Forgejo – ale każda z nich wymaga kompromisów
• Migracja projektu to proces złożony logistycznie, dotykający całego ekosystemu współpracy

Gdy platforma, od której zależy twój projekt, zawodzi częściej niż działa – pora szukać opcji. Ghostty pokazuje, że nawet głęboko zakorzeniona zależność da się przezwyciężyć. Warto śledzić decyzję Hashimoto o nowej lokalizacji projektu, bo może zapoczątkować szerszy trend migracji z GitHub. Sprawdź oryginalny wpis na blogu Hashimoto i wątek na Lobsters, by poznać szczegóły tej historii.