Czym jest open source i jak GitHub rozwinął się oraz zarabia pieniądze?

Open source nie polega po prostu na upublicznieniu kodu źródłowego. Jest to sposób przyznawania innym osobom praw do używania, analizowania, modyfikowania i redystrybucji oprogramowania na warunkach określonej licencji. GitHub rozwinął się w komercyjną platformę, łącząc taki model współpracy w jeden przepływ pracy obejmujący repozytoria, kontrolę wersji, przegląd kodu i automatyzację.

Podstawowy model biznesowy GitHub nie polega na bezpośredniej sprzedaży publicznych projektów open source. Platforma przyciąga dużą grupę bezpłatnych użytkowników, a następnie pobiera opłaty za prywatną współpracę, kontrolę dostępu, bezpieczeństwo, zgodność z wymaganiami, automatyzację, chmurowe środowiska programistyczne i funkcje sztucznej inteligencji, których potrzebują przedsiębiorstwa.

Spis treści

• Precyzyjne znaczenie open source
• Tło ruchu open source
• Jak działa rozwój oprogramowania open source
• Różnice między open source, Git i GitHub
• Początki i rozwój GitHub
• Model przychodów GitHub
• Dlaczego bezpłatne open source tworzy wartość ekonomiczną
• Ograniczenia i kryteria oceny

Czym dokładnie jest open source?

Oprogramowanie open source to oprogramowanie, którego właściciel praw autorskich przyznaje użytkownikom określone prawa za pośrednictwem licencji, w tym prawo do uruchamiania, analizowania, modyfikowania i redystrybucji. Kluczowe nie jest wyłącznie to, czy kod można zobaczyć, lecz jakie prawa są prawnie dozwolone.

Zgodnie z definicją Open Source Initiative (OSI) licencja open source musi zezwalać na swobodną redystrybucję, udostępniać kod źródłowy oraz pozwalać na dystrybucję modyfikacji i utworów pochodnych. Nie może dyskryminować żadnej osoby, grupy ani dziedziny zastosowania. W konsekwencji, jeżeli obowiązują ograniczenia takie jak „wyłącznie do użytku niekomercyjnego” lub „nie może być używane w produktach konkurencyjnych”, oprogramowanie trudno uznać za open source w zwykłym rozumieniu, nawet jeśli jego kod źródłowy jest publiczny. OSI의 Open Source Definition↗

Rozróżnienie to jest szczególnie istotne w przypadku publicznych repozytoriów na GitHub. Nawet jeśli repozytorium jest publicznie widoczne dla wszystkich, w przypadku braku licencji open source obowiązuje domyślne prawo autorskie. Inni mogą przeglądać lub forkować repozytorium w usłudze GitHub, ale nie uzyskują automatycznie prawa do swobodnego kopiowania, modyfikowania i rozpowszechniania kodu. GitHub również wyjaśnia, że aby projekt był rzeczywiście open source, potrzebna jest licencja określająca uprawnienia do korzystania z niego. GitHub의 저장소 라이선스 안내↗

Poniższe trzy stwierdzenia oznaczają zatem różne rzeczy:

• „Możesz zobaczyć kod” opisuje, czy kod źródłowy jest publiczny.
• „Możesz używać go bezpłatnie” opisuje jego cenę.
• „Jest open source” opisuje prawa przyznane przez licencję.

Darmowe oprogramowanie nie musi być oprogramowaniem open source, a oprogramowanie open source może być również sprzedawane.

Jakie tło doprowadziło do powstania ruchu open source?

Praktyka udostępniania kodu oprogramowania i wspólnego jego ulepszania istniała we wczesnych społecznościach badawczych zajmujących się komputerami. Wraz z rozwojem oprogramowania jako samodzielnego produktu komercyjnego oraz wzmacnianiem praw autorskich i ograniczeń użytkowania narastała jednak także troska o możliwość analizowania i naprawiania oprogramowania przez użytkowników.

W latach 80. Richard Stallman uruchomił Projekt GNU i ruch wolnego oprogramowania. W określeniu „wolne oprogramowanie” słowo „wolne” nie odnosi się do ceny, lecz do swobody użytkowników w zakresie uruchamiania, analizowania, modyfikowania i redystrybucji programu, zarówno w oryginalnej, jak i zmodyfikowanej postaci. GNU의 자유 소프트웨어 정의↗

Nazwa „open source” powstała podczas spotkania strategicznego, które odbyło się wkrótce po ogłoszeniu przez Netscape planów udostępnienia kodu źródłowego swojej przeglądarki w 1998 roku. W tym samym roku Eric Raymond, Bruce Perens i inni utworzyli OSI oraz uporządkowali Open Source Definition na podstawie Debian Free Software Guidelines. Celem było wyraźniejsze przedstawienie firmom i opinii publicznej praktycznych zalet współtworzenia oprogramowania. OSI 역사↗

Wolne oprogramowanie i open source w dużej mierze pokrywają się pod względem akceptowanych licencji, ale różnią się akcentami.

Różnica ta nie oznacza, że któraś ze stron zawsze ma przewagę. Oznacza, że ten sam program można wyjaśniać z jednej perspektywy, koncentrując się na prawach użytkowników, albo z drugiej, skupiając się na efektywności przejrzystego rozwoju i rozproszonej współpracy.

Jak działa rozwój oprogramowania open source?

Open source nie oznacza, że „każdy może zmienić kod, jak tylko zechce”. Udział może być otwarty, ale o tym, co zostanie włączone do oficjalnej wersji, decydują opiekunowie projektu i ustalone procedury.

Typowy proces rozwoju przebiega następująco:

1. Opiekun publikuje kod źródłowy, licencję, instrukcje użycia i zasady wnoszenia wkładu.
2. Użytkownik klonuje lub forkuje repozytorium, aby utworzyć niezależne środowisko pracy.
3. Poprawki błędów lub rozwój funkcji są realizowane w osobnej gałęzi.
4. Współtwórca składa Pull Request zawierający zmiany i ich uzasadnienie.
5. Opiekunowie przeglądają kod, wyniki testów, kierunek projektu i wpływ na bezpieczeństwo.
6. Do oficjalnego repozytorium są scalane wyłącznie zmiany spełniające kryteria.
7. Wydawana jest nowa wersja, a problemy wykryte później są ponownie śledzone.

W tym procesie występują różne role. Użytkownicy korzystają z oprogramowania i zgłaszają problemy. Współtwórcy przesyłają kod lub dokumentację. Opiekunowie zajmują się przeglądami i wydaniami. Komitet sterujący projektem albo fundacja może również zarządzać znakami towarowymi, budżetami i zasadami podejmowania decyzji.

Innymi słowy, „otwartość” open source nie oznacza braku władzy decyzyjnej. Możliwości uczestnictwa i prawa do używania kodu są otwarte, podczas gdy oficjalne projekty mają struktury kontroli służące utrzymywaniu jakości.

Czym różnią się licencje open source?

Licencje open source można ogólnie podzielić na licencje permisywne oraz licencje copyleft.

Licencje permisywne

Typowymi przykładami są MIT, BSD i Apache License 2.0. Pod warunkiem spełnienia wymagań, takich jak zachowanie informacji o prawach autorskich i tekstu licencji, licencje te zasadniczo pozwalają na włączanie zmodyfikowanego kodu do oprogramowania własnościowego.

Dzięki temu firmom łatwo jest integrować taki kod z produktami komercyjnymi, ale nie ma gwarancji, że ulepszony kod wróci do pierwotnej społeczności. Apache License 2.0 zawiera również wyraźne postanowienia dotyczące patentów, dlatego jej warunki prawne nie są identyczne z warunkami licencji MIT.

Licencje copyleft

Reprezentatywnym przykładem jest GNU General Public License (GPL). W przypadku dystrybucji zmodyfikowanego kodu lub dystrybucji utworu pochodnego połączonego z tym kodem licencja może wymagać udostępnienia kodu źródłowego na tej samej licencji.

Copyleft nie zakazuje użycia komercyjnego. Oprogramowanie może być sprzedawane komercyjnie, ale należy spełnić obowiązki dotyczące ujawnienia kodu źródłowego w zakresie określonym przez licencję. Warianty takie jak LGPL i AGPL zostały zaprojektowane z odmiennymi warunkami dotyczącymi linkowania bibliotek i usług sieciowych.

Przy wyborze licencji nie należy kierować się wyłącznie tym, że korzysta z niej znany projekt. Należy zbadać zakres ujawniania utworów pochodnych, postanowienia patentowe, świadczenie usług sieciowych oraz zgodność z innymi licencjami.

Jaka jest różnica między open source, Git i GitHub?

Te trzy pojęcia często pojawiają się razem, ale działają na różnych warstwach.

• Open source to pojęcie opisujące prawa do używania oprogramowania oraz metodę wspólnego rozwoju.
• Git to program open source do kontroli wersji, który w rozproszony sposób zarządza historią zmian plików.
• GitHub to usługa komercyjna hostująca repozytoria Git w internecie i zapewniająca funkcje przeglądu kodu, zarządzania problemami, automatyzacji, bezpieczeństwa i współpracy.

Git powstał w 2005 roku po zakończeniu współpracy między społecznością rozwijającą jądro Linux a własnościowym, rozproszonym narzędziem kontroli wersji BitKeeper. Potrzebne było narzędzie, które obsłuży szybkość, pracę rozproszoną i dużą liczbę równoległych gałęzi wymaganych przez projekt tak duży jak Linux. Git 공식 역사↗

W Git każdy deweloper może utrzymywać repozytorium zawierające pełną historię zmian bez stałego połączenia z centralnym serwerem. Sam Git z wiersza poleceń utrudniał jednak zarządzanie tym, kto zaproponował zmianę, dlaczego była potrzebna, kto ją zrecenzuje i kiedy zostanie scalona. GitHub uporządkował właśnie ten proces współpracy za pomocą interfejsu internetowego.

Z Git można korzystać bez GitHub, a repozytoria mogą działać na GitLab, Bitbucket lub serwerach hostowanych samodzielnie. Z drugiej strony GitHub zawiera nie tylko open source, lecz także prywatny kod firmowy i publiczny kod bez licencji. GitHub i open source nie są synonimami.

Jak powstał GitHub?

GitHub był rozwijany przez Toma Preston-Wernera, Chrisa Wanstratha i PJ Hyetta, a jako publiczna usługa został uruchomiony w 2008 roku. Scott Chacon, ekspert Git znany później jako autor Pro Git, również dołączył do wczesnego zespołu.

Pierwszy commit w wewnętrznym repozytorium GitHub wykonano w październiku 2007 roku, a usługa została uruchomiona w kwietniu 2008 roku. Około pierwszej rocznicy GitHub miał ponad 20 000 publicznych repozytoriów i czterech pracowników pełnoetatowych, nie otrzymawszy żadnej inwestycji zewnętrznej. GitHub의 첫해 기록↗

Problem, który GitHub chciał rozwiązać, nie ograniczał się do przechowywania plików. Platforma miała stworzyć środowisko współpracy wizualizujące zmiany w rozproszonych repozytoriach Git, pomagające deweloperom odkrywać pracę innych oraz ułatwiające przeglądanie propozycji zmian. Udostępniony przez GitHub w 2008 roku wykres sieciowy był również próbą pokazania na jednym ekranie relacji między gałęziami i commitami wielu użytkowników. 초기 Network Graph 소개↗

Podejście to zaczęto później nazywać „social coding”. Profile deweloperów, historia aktywności, obserwowania, forki, gwiazdki, problemy i pull requesty zostały powiązane z repozytoriami kodu, przekształcając sam proces rozwoju w sieć, którą można było wyszukiwać i obserwować.

Dlaczego GitHub rósł tak szybko?

Wzrostu GitHub nie można wyjaśnić wyłącznie oferowaniem bezpłatnego przechowywania repozytoriów Git. Wspólnie zadziałały odpowiedni moment technologiczny, doświadczenie użytkownika, efekty sieciowe i model biznesowy dla przedsiębiorstw.

Uczynił złożony proces współpracy w Git zrozumiałym w internecie

Gałęzie, commity i scalanie to potężne funkcje Git, ale początkującym niełatwo zrozumieć je wyłącznie za pomocą poleceń. GitHub połączył różnice w kodzie, dyskusje, wyniki przeglądów i stan testów w interfejsie pull requestów.

Zamiast przesyłać pliki patch przez e-mail, deweloperzy mogli udostępniać zmiany za pomocą jednego łącza. Opiekunowie projektów mogli ograniczać koszty przeglądu, ponieważ kod i proces dyskusji były rejestrowane razem.

Publiczne repozytoria stworzyły sieć deweloperów

Gdy projekt dołącza do GitHub, użytkownicy i współtwórcy tego projektu również częściej zakładają konta. Użytkownicy ci następnie tworzą inne projekty lub uczestniczą w już istniejących.

Wraz ze wzrostem liczby repozytoriów deweloperzy odwiedzają GitHub, aby znajdować kod. Wraz ze wzrostem liczby deweloperów opiekunowie projektów wybierają GitHub, aby przyciągać współtwórców. Jest to dwustronny efekt sieciowy.

Publiczna historia aktywności służyła także jako portfolio deweloperów. Firmy mogły oceniać rzeczywisty kod kandydatów i ich doświadczenie we współpracy, a deweloperzy mieli zachętę do budowania historii aktywności ze względu na możliwości zatrudnienia i reputację.

Rozwijał jednocześnie open source i produkty dla przedsiębiorstw

GitHub obniżył barierę wejścia dla publicznych repozytoriów open source, jednocześnie pobierając od początku opłaty za prywatne repozytoria. W 2011 roku uruchomił GitHub Enterprise, który mógł działać na wewnętrznych serwerach firm i odpowiadał na potrzeby przedsiębiorstw w zakresie uwierzytelniania, kopii zapasowych i zarządzania zespołami. GitHub Enterprise 출시 기록↗

Taka struktura pozwoliła indywidualnym deweloperom uczyć się korzystania z GitHub przy projektach open source, a następnie używać korporacyjnej wersji tego samego przepływu pracy po dołączeniu do firmy. Umożliwiła wdrażanie oddolne, w którym deweloperzy wprowadzali produkt do swoich organizacji bez odrębnych działań sprzedażowych skierowanych do osób indywidualnych.

GitHub podał, że osiągnął rentowność i wzrost dzięki płatnym usługom bez inwestycji zewnętrznych, a pierwszą inwestycję zewnętrzną pozyskał w 2012 roku. GitHub의 2012년 투자 발표↗

Rozszerzył bezpłatny plan i ograniczył powody przechodzenia do konkurencyjnych usług

W 2019 roku GitHub zaczął oferować prywatne repozytoria bezpłatnym kontom osobistym. W 2020 roku usunął także limity współpracowników w bezpłatnych prywatnych repozytoriach i udostępnił bezpłatnie podstawowe funkcje zespołowe. Zaawansowane zarządzanie uprawnieniami, funkcje bezpieczeństwa i wsparcia potrzebne firmom pozostały płatne. GitHub Free 확대 발표↗

Rozszerzanie bezpłatnego planu oznacza rezygnację z części przychodów subskrypcyjnych w krótkim okresie. Pozwala jednak zatrzymać na platformie więcej osób i małych zespołów oraz tworzy możliwości konwersji na produkty Team, Enterprise, bezpieczeństwa i AI wraz z rozwojem ich organizacji.

Jak przejęcie przez Microsoft wpłynęło na rozwój GitHub?

Microsoft zgodził się przejąć GitHub w 2018 roku za akcje Microsoft o wartości 7,5 miliarda dolarów. Wówczas GitHub zgłaszał ponad 28 milionów użytkowników. Microsoft oświadczył, że GitHub zachowa niezależność operacyjną i charakter stawiający deweloperów na pierwszym miejscu. Microsoft의 GitHub 인수 발표↗

Przejęcie odpowiadało strategicznym potrzebom obu stron. GitHub mógł korzystać z globalnej infrastruktury chmurowej, sieci sprzedaży dla przedsiębiorstw oraz możliwości w zakresie bezpieczeństwa i zgodności. Microsoft mógł wyjść poza swój dawny wizerunek firmy skoncentrowanej na Windows i własnościowym oprogramowaniu oraz nawiązać kontakt z deweloperami niezależnie od systemu operacyjnego czy języka programowania. Zyskał też możliwości połączenia Azure, Visual Studio, VS Code i GitHub.

Po przejęciu GitHub rozszerzył się poza hosting repozytoriów w platformę obejmującą pełny cykl życia oprogramowania. GitHub Actions automatyzuje kompilacje, testy i wdrożenia; Codespaces zapewnia chmurowe środowiska programistyczne; produkty Advanced Security skanują kod, zależności i sekrety; a Copilot zapewnia wspierane przez AI funkcje pisania i przeglądania kodu.

W październiku 2022 roku Microsoft ogłosił, że GitHub osiągnął 1 miliard dolarów rocznych przychodów cyklicznych (ARR) i rozrósł się do ponad 90 milionów użytkowników, czyli trzykrotnie więcej niż w momencie przejęcia. Microsoft FY2023 1분기 실적 발표↗

GitHub ogłosił, że z platformy korzystało ponad 100 milionów deweloperów w 2023 roku oraz ponad 180 milionów w 2025 roku. W 2025 roku łączna liczba projektów osiągnęła 630 milionów, a GitHub uznał, że około 81,5% wszystkich wkładów miało miejsce w prywatnych repozytoriach. Pokazuje to, że GitHub stał się jednocześnie przestrzenią open source i infrastrukturą rozwoju korporacyjnego na dużą skalę. GitHub Octoverse 2025↗

Liczby te są jednak metrykami platformy liczonymi według własnych kryteriów GitHub. Liczby zarejestrowanych deweloperów nie należy interpretować jako liczby miesięcznych aktywnych użytkowników ani płacących klientów. Microsoft również nie ujawnia co roku szczegółowo bieżących przychodów i zysku operacyjnego GitHub jako odrębnej jednostki biznesowej, dlatego zgłoszony w 2022 roku ARR na poziomie 1 miliarda dolarów należy traktować jako reprezentatywną miarę skali ujawnioną w tamtym czasie, a nie jako aktualne przychody.

Na czym dokładnie zarabia GitHub?

Model przychodów GitHub można podsumować jako model freemium: pozyskuje użytkowników poprzez bezpłatną publiczną platformę, a pobiera opłaty za kontrolę i produktywność, których organizacje potrzebują do prowadzenia działalności.

Subskrypcje za stanowisko użytkownika

Bezpłatny plan umożliwia osobom indywidualnym i małym zespołom używanie podstawowych funkcji repozytoriów. Plan Team zapewnia zaawansowane funkcje współpracy, a plan Enterprise oferuje bezpieczeństwo, zgodność, scentralizowaną administrację i opcje wdrożenia.

Według oficjalnej strony cenowej sprawdzonej we wrześniu 2026 roku plan Team zaczyna się od 4 dolarów za użytkownika miesięcznie, a Enterprise od 21 dolarów za użytkownika miesięcznie. Rzeczywiste kwoty mogą różnić się w zależności od okresu umowy, regionu, podatków i warunków dużych kontraktów. GitHub 공식 가격표↗

Rozliczanie według stanowisk ma tę zaletę, że przychody cykliczne mogą rosnąć wraz ze wzrostem zatrudnienia w firmie. Gdy kod i procesy pracy zostaną zakorzenione na platformie, rosną także koszty zmiany dostawcy, co zwiększa prawdopodobieństwo utrzymania umów.

Subskrypcje produktów AI i rozliczanie zależne od użycia

GitHub Copilot ma płatne plany dla osób indywidualnych i organizacji. Firmy kupują stanowiska dla każdego użytkownika, a po przekroczeniu użycia AI zawartego w planie mogą obowiązywać dodatkowe opłaty. Copilot rozwija się więc w model łączący tradycyjne subskrypcje oprogramowania z rozliczaniem za użycie zasobów obliczeniowych AI. GitHub Copilot 조직 청구 안내↗

Copilot nie tylko dodaje GitHub nowe źródło przychodów, lecz także sprawia, że AI jest używana w obrębie ustalonych przepływów pracy związanych z repozytoriami, problemami, pull requestami i przeglądem kodu. Dzięki temu łatwiej sprzedawać dodatkowe produkty obecnym klientom platformy niż odrębne narzędzie AI.

Produkty bezpieczeństwa i zgodności

Duże przedsiębiorstwa nie płacą jedynie za miejsce do przechowywania kodu. Potrzebują kontroli kont, dzienników audytowych, jednokrotnego logowania, wykrywania sekretów, analizy podatności kodu, zarządzania łańcuchem dostaw i zgodności regulacyjnej.

Wraz ze wzrostem zależności od komponentów open source organizacje muszą stale skanować podatne pakiety i ujawnione dane uwierzytelniające. Rozszerzanie bezpłatnego ekosystemu paradoksalnie zwiększa także potrzebę korporacyjnych produktów bezpieczeństwa.

Użycie zasobów obliczeniowych, pamięci masowej i automatyzacji

Usługi takie jak GitHub Actions, Codespaces i Packages obejmują określoną ilość użycia w ramach planu, a za przekroczenia pobierają opłaty. Rachunek przedsiębiorstwa może obejmować nie tylko licencje Enterprise, lecz także nadmiarowe użycie Actions lub Codespaces oraz dodatkowe licencje na produkty takie jak Copilot i narzędzia bezpieczeństwa. GitHub Enterprise 청구 구조↗

Model ten pozwala przychodom GitHub rosnąć wraz ze wzrostem aktywności programistycznej. Z drugiej strony GitHub ponosi również koszty serwerów wykonawczych, urządzeń pamięci masowej, sieci i modeli AI, więc nie wszystkie przychody z użycia są zyskiem.

Prowizje transakcyjne Marketplace

Deweloperzy zewnętrzni mogą sprzedawać płatne aplikacje za pośrednictwem GitHub Marketplace. GitHub zapewnia obsługę płatności i subskrypcji oraz zatrzymuje część wartości transakcji jako opłatę operacyjną. Zgodnie z oficjalną dokumentacją udział zatrzymywany w transakcjach aplikacji od 2021 roku wynosi 5%. GitHub Marketplace 판매 대금 안내↗

Poza bezpośrednimi opłatami Marketplace ważne jest także to, że zewnętrzne narzędzia skupiają się wokół GitHub. Im więcej aplikacji jest używanych, tym więcej narzędzi programistycznych trzeba zastąpić przy opuszczaniu GitHub, co wzmacnia trwałość platformy.

Dlaczego bezpłatne open source ma wartość ekonomiczną dla GitHub?

Dla GitHub bezpłatne publiczne repozytoria nie są po prostu pozycją kosztową. Są podstawowym zasobem służącym pozyskiwaniu użytkowników i tworzeniu ekosystemu.

Po pierwsze, projekty open source przyciągają nowych użytkowników. Deweloperzy, którzy chcą użyć konkretnej biblioteki, zgłosić problem albo przesłać patch, zakładają konta GitHub. GitHub może pozyskiwać tych użytkowników bez wydatków na reklamę.

Po drugie, aktywność open source sprawia, że sposób pracy GitHub staje się faktycznym standardem branżowym. Deweloperzy uczą się forków, problemów i pull requestów w szkole lub przy projektach osobistych, a następnie preferują to samo podejście w pracy.

Po trzecie, publiczny ekosystem i prywatny rozwój korporacyjny są od siebie zależne. Prywatne produkty firm również korzystają z niezliczonych publicznych bibliotek i narzędzi. W danych GitHub z 2025 roku większość aktywności związanej z wkładem odbywała się w prywatnych repozytoriach, podczas gdy projekty publiczne stanowiły większość pod względem liczby repozytoriów. Bezpłatny publiczny ekosystem zapewnia podstawę płatnej pracy przedsiębiorstw.

Po czwarte, bardziej aktywne projekty publiczne zwiększają popyt na bezpieczeństwo i automatyzację. Konieczne stają się aktualizacje zależności, wykrywanie złośliwych pakietów, zarządzanie licencjami oraz testowanie i wdrażanie na dużą skalę.

Wsparcie GitHub dla bezpłatnego open source trudno więc wyjaśniać wyłącznie filantropią lub wyłącznie działalnością komercyjną. Zapewnia ono rzeczywistą wartość społeczności deweloperów, jednocześnie będąc długoterminową strategią dystrybucji prowadzącą do płatnego rynku przedsiębiorstw.

Jak firmy open source generalnie zarabiają pieniądze?

Model biznesowy GitHub jest jednym z kilku modeli przychodów wykorzystujących open source. Firmy open source często pobierają opłaty nie za sam kod, który można powielać, lecz za wygodę operacyjną, odpowiedzialność, bezpieczeństwo i specjalistyczną wiedzę.

• Wsparcie i konsulting: Udostępniają oprogramowanie bezpłatnie i pobierają opłaty za instalację, reagowanie na incydenty, szkolenia i długoterminowe wsparcie.
• Zarządzana chmura: Obok open source, które klienci mogą wdrożyć samodzielnie, sprzedają SaaS obsługujący je w imieniu klienta.
• Open core: Udostępniają publicznie podstawowe funkcje, a funkcje zarządzania korporacyjnego, bezpieczeństwa i analityki oferują na własnościowych licencjach.
• Podwójne licencjonowanie: Oferują ten sam kod jednocześnie na licencji open source i licencji komercyjnej, umożliwiając użytkownikom wybór zależnie od ich sytuacji.
• Hosting i użycie: Pobierają opłaty zależne od użycia pamięci masowej, sieci, zasobów obliczeniowych i wykonywania automatyzacji.
• Sponsoring i darowizny: Osoby indywidualne, firmy i fundacje wspierają opiekunów albo działalność projektów.
• Certyfikacja i szkolenia: Uzyskują przychody z oficjalnych szkoleń, egzaminów, certyfikatów technicznych lub programów partnerskich.

Modele te działają, ponieważ koszty oprogramowania nie ograniczają się do ceny licencji. Firmy biorą pod uwagę całkowity koszt posiadania, w tym czas instalacji, ryzyko przestojów, incydenty bezpieczeństwa, aktualizacje, zgodność regulacyjną i niedobory wyspecjalizowanego personelu. Nawet jeżeli mogą uzyskać kod bezpłatnie, mogą być skłonne płacić za niezawodną odpowiedzialność operacyjną.

Jakie są ograniczenia open source i GitHub?

Open source nie staje się automatycznie bezpiecznym i trwałym oprogramowaniem tylko dlatego, że ma wielu uczestników.

Obciążenia związane z utrzymaniem mogą skupiać się na kilku osobach

Nawet szeroko używana biblioteka może zależeć od zaledwie kilku opiekunów odpowiedzialnych za faktyczne przeglądy i wydania. Wraz ze wzrostem użycia rośnie obciążenie związane ze zgłaszaniem problemów i reagowaniem na zagrożenia bezpieczeństwa, podczas gdy wynagrodzenie opiekunów może nie rosnąć proporcjonalnie.

Publiczny przegląd nie gwarantuje jakości

Fakt, że kod źródłowy jest publiczny, różni się od faktu, że ktoś wystarczająco go przeanalizował. Ryzyka w łańcuchu dostaw obejmują podatności, złośliwe wkłady, przejęte konta opiekunów oraz skażone zależności.

Obowiązki licencyjne mogą zostać przeoczone

Open source nie jest dobrem publicznym wolnym od praw autorskich. Należy przestrzegać warunków każdej licencji, w tym zachowywania informacji o prawach autorskich, udostępniania kodu źródłowego, oznaczania zmian i stosowania tej samej licencji. Zgodność licencji należy sprawdzać szczególnie w produktach komercyjnych łączących wiele zależności.

Koncentracja platformy tworzy nowe zależności

Ponieważ Git jest rozproszony, repozytoria można przenieść na inne serwery. Pełna migracja problemów, dyskusji pull requestów, workflowów Actions, zasad dostępu, aplikacji Marketplace i zapisów bezpieczeństwa jest jednak znacznie trudniejsza.

Im wygodniejszy staje się GitHub, tym bardziej społeczności programistyczne mogą zależeć od cen, zasad, reakcji na incydenty i zmian funkcji wprowadzanych przez jedną firmę. Należy klonować kod lokalnie, tworzyć kopie zapasowe wydań i dokumentacji oraz rozumieć zależności od funkcji konkretnej platformy.

Jakie są powszechne błędne przekonania?

„Jest publiczne na GitHub, więc jest open source”

Bez licencji nie powstają zwykłe prawa do korzystania z open source. Widoczność i licencjonowanie to odrębne ustawienia.

„Całe open source jest darmowe”

Koszt kopiowania może nie istnieć, ale operacje, wsparcie, usługi chmurowe, szkolenia i funkcje bezpieczeństwa mogą generować koszty. Licencje open source nie zakazują płatnej sprzedaży.

„Każdy może dowolnie zmienić oficjalny kod”

Prawo każdego do modyfikowania własnej kopii różni się od uprawnienia do włączania zmian do oficjalnego projektu. O tym, czy zmiany zostaną oficjalnie uwzględnione, decydują opiekunowie i zasady zarządzania projektem.

„Sam GitHub jest open source”

GitHub hostuje projekty open source na dużą skalę i wydaje różne narzędzia open source, ale cała usługa GitHub nie jest jednym produktem open source. GitHub jest komercyjną platformą należącą do Microsoft.

„Ponieważ GitHub ma wielu użytkowników, większość z nich płaci”

Podawane przez GitHub liczby deweloperów obejmują bezpłatne konta. Łączna liczba zarejestrowanych deweloperów, aktywnych deweloperów, klientów korporacyjnych i płatnych stanowisk to różne metryki.

„Microsoft prowadzi GitHub za darmo”

Chociaż bezpłatne repozytoria są szeroko dostępne, GitHub generuje przychody ze stanowisk korporacyjnych, AI, bezpieczeństwa, automatyzacji, zasobów obliczeniowych, pamięci masowej i Marketplace. Bezpłatni użytkownicy zapewniają zarówno potencjał konwersji na płacących klientów, jak i wartość sieciową.

Jak oceniać projekt open source?

Przy wdrażaniu open source w rzeczywistym projekcie nie należy kierować się wyłącznie liczbą gwiazdek ani pozycją w rankingu GitHub. Warto wspólnie przeanalizować następujące elementy:

• Plik LICENSE oraz zgodność prawna z zamierzonym użyciem
• Częstotliwość ostatnich wydań i aktualizacji bezpieczeństwa
• Liczbę głównych opiekunów i zależność od konkretnych osób
• Szybkość przeglądania problemów i pull requestów
• Istnienie procedur testowania, automatyzacji i zgłaszania podatności
• Kompletność dokumentacji i wskazówek dotyczących aktualizacji
• Personel i koszty wymagane do samodzielnego hostowania
• Zależność od GitHub lub konkretnej usługi chmurowej
• Dostępne alternatywy i możliwość migracji w przypadku zakończenia projektu

Te same zasady mają zastosowanie przy wyborze GitHub jako platformy pracy. Zamiast porównywać wyłącznie ceny bezpłatnych planów, należy łącznie ocenić potrzebne zarządzanie uprawnieniami, audyt, bezpieczeństwo, użycie automatyzacji, użycie AI, lokalizację danych, reakcję na incydenty i koszty migracji.

Jak należy rozumieć relację między open source a GitHub?

Open source to zbiór reguł rozdzielających prawa do wspólnego używania i ulepszania oprogramowania. Git jest narzędziem do rozproszonego zarządzania historią tych zmian, a GitHub jest platformą pośredniczącą na dużą skalę we współpracy opartej na Git.

GitHub nie wynalazł open source. Uprościł natomiast procesy odkrywania, kopiowania, dyskusji, przeglądu i scalania potrzebne społecznościom open source, łącząc je w jednolity przepływ pracy w sieci. Publiczne projekty stworzyły sieć deweloperów, a ta sieć przyciągnęła na GitHub również prywatny rozwój korporacyjny.

W rezultacie GitHub, zamiast pobierać opłatę za dostęp do publicznego kodu, zbudował model naliczający opłaty za kontrolę, bezpieczeństwo, automatyzację, zasoby obliczeniowe i AI, których firmy potrzebują do współpracy na dużą skalę. Początkowo opierał się na modelu „publiczne jest bezpłatne, a prywatne płatne”, lecz obecnie można go rozumieć jako biznes platformy programistycznej, w którym „podstawowa współpraca jest bezpłatna, a funkcje rozwiązujące złożoność organizacyjną są płatne”.