Jak oceniać rosnące projekty na GitHub? | Anatomia Tornada | Rust vs Go dla SH?
Grow Your Software House to metody, narzędzia GPTs, analizy i nagrania, które pomagają software house'om odkryć swój silnik wzrostu.
Cześć! Nazywam się Maciej Greń i od 17 lat zajmuję się rozwojem firm typu Software House. Grow Your Software House to biuletyn z częścią darmową na Linkedin rozwinięty o płatne analizy tutaj na Substack wraz z wiedzą, narzędziami i filmami pokazującymi jak przestać błądzić i zacząć systematycznie rozwijać swój Software House. W dzisiejszym numerze:
Jak analizować rosnące projekty na Github aby ocenić ich potencjał dla Twojego SH
narzędzie do analizy repozytoriów na Github (Big Query) aby znaleźć te najbardziej obiecujące dla Twojego SH
Anatomia Tornada: zrozumienie tornada, zanim wejdzie się w nie z swoim SH
Test Tornada: Rust vs. Go - która technologia jest dobra dla Twojego SH?
Zebrana wiedza w tym biuletynie powinna być używana z rozwagą i na własną odpowiedzialność. Zapożyczam w nim nagminnie frazy z języka angielskiego, wybaczcie, robię to celowo ponieważ w codziennej pracy korzystamy z tych fraz nieustannie.
Jak analizować rosnące projekty na Github aby ocenić ich potencjał dla Twojego SH/firmy usługowej IT?
Github to olbrzymie źródło wiedzy. Widzimy tam rosnące projekty, możemy zobaczyć, które rosną w liczbie gwiazdek na GH korzystając na przykład z tego adresu: https://github.com/trending. To bardzo pomocne w ręcznym szybkim skanowaniu tego co jest bardzo hot obecnie w przestrzeni OSS, ale totalnie niepraktyczne do analiz strategicznych dla firm typu software house/agencji software.
Dlaczego?
Ponieważ nie mamy większej perspektywy czasowej na przykład trzech miesięcy na wzrost danego projektu OSS oraz brakuje kilku krytycznych aspektów, które powodują, że dany projekt OSS może być obiecującym kandydatem dla Software House do budowy swojego silniku wzrostu.
TIP: Dlaczego warto budować swój software house/agencję wytwarzającą oprogramowanie i jego przewagę na rynku w oparciu o Open Source? pisałem o tym w #6 numerze naszego biuletynu (https://www.shgrowth.com/i/171716643/jakie-sa-kluczowe-cechy-projektu-oss-aby-stał-sie-sercem-silnika-wzrostu-w-sh). Jest tam przykład firm Callstack oraz Rigby, które prężnie rosną z bardzo wysokimi marżami.
Na szczęście z pomocą przychodzi nam AI, które potrafi generować bardzo wygodne skrypty w Big Query, do przerabiania bazy danych Github wzdłuż i wszerz. Stworzyłem dzięki temu skrypt Big Query, który można dostać pod tym linkiem -dostęp dla abonamentów SHG na Substack.
Dla osób bez dostępu do płatnej części, tutaj jest rezultat działania tego skryptu: https://docs.google.com/spreadsheets/d/1q1xVtsLAdPVQ9K5uKEd6_AlR_O7L639DmFWcql0zQIg/edit?usp=sharing ).
Mając listę 1000 projektów z całej bazy Github, które otrzymały największą liczbę gwiazdek i największą liczbę zgłoszonych unikalnych issues, możemy dokonać naszej analizy.
Czemu akurat te dwa kluczowe parametry?
liczba gwiazdek i liczba unikatowych issues to kluczowe metryki dla software houseów/firm usługowych IT. To, że dany projekt otrzyma dużą liczbę gwiazdek w ciągu dłuższego okresu np. trzech miesięcy w połączeniu z dużą liczbą zgłoszonych unikatowych issues to bardzo mocny sygnał, że projekt OSS nie tylko jest ciekawy, ale jest wdrażany przez bardzo dużą grupę developerów. Co jeszcze istotniejsze, to, że te issues są zgłaszane publicznie oznacza, że projekt ma określoną naturę: jest tworzony w trybie build in public, przez społeczność dla społeczności.
Nie każdy projekt na Github jest tak tworzony. Jest wiele projektów, które zyskują olbrzymią liczbę gwiazdek, ale issues są zgłaszane przez zamknięte fora, gdzie developerzy mają dostęp do wsparcia firmy, która daną technologię rozwija. To jest niestety obszar śmierci dla software housów ponieważ firma technologiczna w tym przypadku jest też firmą usługową i jej ekspertyza jest totalną przewagą nad każdą inną firmą - nie ma tutaj co po was.
Dlatego te dwa parametry: liczba gwiazdek i liczba unikatowych issues muszą iść ze sobą w parze.
Jak szybko odrzucić dany obiecujący projekt OSS z naszej listy kandydatów na silnik wzrostu?
Na powyższym obrazie widzimy na samej górze projekt vscode, claude-code. To są narzędzia developerskie do rozwoju systemów ze wsparciem agentów AI. Ta technologia jest obecnie w fazie bardzo intensywnego tornada, można powiedzieć, że cyklonu, w którym developerzy korzystają z nowych wersji tych narzędzi w zupełnie nowy sposób. Starają się wejść w fazę rozwoju oprogramowania z użyciem AI bo czują presję kierownictwa. Czy ta technologia jest dobrym punktem otwarcia przewag dla Software House? nie.
Popatrzmy na to z wizją celu. Jeśli jako dany software house/firma usługowa IT chcesz zbudować swoje liderstwo w danej technologii na świecie, to czy masz szansę zrobić to w oparciu o bycie np. core-contributor do vscode czy claude-code? z pewnością może to być bardzo wzmacniające Waszą pozycję w świecie jeśli nie tylko używacie, ale też tworzycie narzędzia do rozwoju oprogramowania z AI, ale to niestety nie jest właściwy moment.
Znaleźć właściwy moment wejścia danej technologii do firmy
Każda firma gdy rozważa wprowadzenie danej technologii do firmy robi to w określonych momentach. Jeśli dana technologia jest przełomowa dla niej, wymaga zmiany sposobu pracy systemów, pracy inżynierów to wybór tej technologii spoczywa na liderach/zarządzie. Dokonują analiz i wyboru określonego rozwiązania. Pojawia się tutaj moment wyjścia z firmy i szukania najlepszych standardów na rynku. W przypadku vscode/claude-code narzędzia te są częścią całego development stack’a technologicznego danej firmy, który musi być odświeżony. Ten stack technologiczny od razu zostaje wtłoczony w ręce developerów, którzy mają od tego momentu jedno zadanie - dostarczać lepszy kod, szybciej dzięki AI. Tutaj nie ma miejsca na zaproszenie zewnętrznej firmy usługowej - Ciebie! no może do szkoleń, ale Twoim największym przeciwnikiem jest obecny zespół developerów w firmie, którzy mają się nauczyć używania tego narzędzia od Ciebie i na tym zakończyć współpracę z Tobą. Możesz być ich przewodnikiem, ale nadal - jesteś firmą doradczą, której zadaniem jest towarzyszyć w przejściu, a nie przeprowadzić przejście.
W skrócie analizując dany projekt OSS musisz zobaczyć w jakim etapie wytwarzania oprogramowania dana technologia jest wybierana. Jeśli w tym etapie w firmie jest już zespół developerów, którzy muszą się jej nauczyć - to będzie Tobie trudniej tam wejść.
Co innego jeśli dana technologia jest tak trudna do opanowania, że lider technologiczny celowo unika jej wprowadzenia do swoich obecnych zespołów, a nadal chce ją wdrożyć.
Tutaj pojawia się bardzo kluczowy paradoks/konflikt. Z jednej strony lider technologiczny wie, że nie może danej technologii przekazać do obecnych osób w firmie, z drugiej strony - czuje, że musi tą technologię wdrożyć.
Jeśli miałbyś pod tym kątem ocenić te technologie, które są w naszym pliku, to które z nich są:
rozważane przez liderów technologicznych jako kluczowy filar dla nowego projektu lub jako kluczowy filar dla projektu migracji z starej na nową technologię? (fosa problemu vs rozwiązania)
które z tych technologii są bardzo trudne do opanowania w krótkim czasie przez inżynierów, nawet tych doświadczonych w różnych językach? (fosa kompetencyjna)
Korzystając z AI można wkleić ten artykuł powyższy do tego miejsca, wysłać do niego csv i poprosić o analizę. Otrzymamy wówczas:
To czy dana technologia jest w odpowiednim momencie cyklu wytwarzania oprogramowania oraz czy stanowi odpowiednią fosę kompetencyjną to dobry start. Jest jednak szereg innych metryk, które warto wziąć pod uwagę:
w jakiej fazie rynku i adopcji jest dana technologia
jak jest dopasowana do Twojego DNA
czy są goryle usługowe, goryle technologiczne, biznesowe, które przeszkadzają i pomagają
czy technologia jest w fazie tornada czy na main-street, a może w przepaści i dopiero toruje swoją drogę w dane nisze)
czy jest luka kompetencji
czy model biznesowy goryli koliduje z Twoim
No jest tego sporo…
Najważniejsze jest jednak odsiać 80%, a powyższy artykuł w tym bardzo pomaga. Poniżej tłumaczę jak zanalizować czy dana technologia jest w odpowiedniej fazie przełomu na rynku, aby być dla Twojej firmy falą, na której zbudujesz stabilny rozwój.
Anatomia Tornada: Zrozumieć Burzę, Zanim w Nią Wejdziesz
W poprzednim numerze SHGrowth spojrzeliśmy w lustro, aby zrozumieć nasze strategiczne DNA. Teraz, uzbrojeni w tę wiedzę, musimy skierować wzrok na horyzont i zrozumieć naturę siły, którą chcemy ujarzmić.
Tornado nie jest po prostu marketingowym hasłem na "szybki wzrost". To specyficzny, gwałtowny i często brutalny fenomen rynkowy, który redefiniuje całe branże. Próba wejścia w nie bez dogłębnego zrozumienia jego mechaniki jest jak wypłynięcie na ocean podczas huraganu bez mapy i kompasu.
W tym rozdziale przeprowadzimy dogłębną analizę anatomii Tornada. Zrozumiemy jego dwa fundamentalne typy, poznamy cykl życia i, co najważniejsze, zidentyfikujemy kluczowych graczy i dynamikę, która decyduje o zwycięstwie lub porażce.
2.1. Dwa Silniki Tornada: Przełom Technologiczny vs. Biznesowy
Każde Tornado jest napędzane przez przełom paradygmatyczny – fundamentalną zmianę, która czyni stary sposób działania przestarzałym. Ale natura tego przełomu determinuje całą dynamikę rynku i strategię, którą musisz przyjąć.
Tornado napędzane Przełomem Technologicznym:
Czym jest: Pojawia się fundamentalnie nowy i lepszy sposób na rozwiązanie horyzontalnego problemu inżynieryjnego. Wartość jest wewnętrzna dla technologii – jej wydajność, bezpieczeństwo, skalowalność.
Jakie nisze atakuje: W strategii Kręgielni (czyli metodycznego zdobywania rynku nisza po niszy), twoje przyczółki nie są zorientowane branżowo, ale technologicznie.
Przykłady nisz technologicznych: systemy rozproszone, przetwarzanie danych w czasie rzeczywistym, natywne aplikacje mobilne, bezpieczeństwo pamięci.
Naturalny Pretendent: Ta ścieżka jest idealna dla firmy o DNA Architekta Poziomu "Principal".
Tornado napędzane Przełomem Biznesowym:
Czym jest: Nowa technologia staje się kluczowym narzędziem, które umożliwia realizację nowego, przełomowego modelu biznesowego w konkretnej branży. Wartość jest zewnętrzna – leży w wyniku biznesowym, który technologia umożliwia.
Jakie nisze atakuje: Kręgielnia jest tu zorientowana wertykalnie (branżowo). Twoje przyczółki to kolejne firmy w ramach jednego, specyficznego sektora.
Przykłady nisz biznesowych: platformy e-commerce B2B dla producentów maszyn, systemy do zarządzania łańcuchem dostaw w farmacji, platformy do rezerwacji dla branży hotelarskiej.
Naturalny Pretendent: Ta ścieżka jest idealna dla firmy o DNA Eksperta Domenowego.
2.2. Cykl Życia Tornada: Od Iskry do Hegemonii
Kiedy Tornado się zaczyna? Tornado nie zaczyna się w momencie, gdy powstaje technologia. Rozpoczyna się, gdy na rynku zderzają się dwie potężne siły, tworząc iskrę, która zapala całą prerię.
Siła #1: Nagromadzone Napięcie Rynkowe. Przez długi czas pragmatycy w danej niszy odczuwają rosnący ból. Stare narzędzia i procesy stają się coraz większą barierą dla wzrostu, efektywności lub bezpieczeństwa. Napięcie rośnie, ale strach przed ryzykiem związanym z nową, niedojrzałą technologią jest wciąż silniejszy.
Siła #2: Sygnał Bezpieczeństwa od Goryla. To jest właśnie ten brakujący katalizator. Rynek pragmatyków czeka na potężny, jednoznaczny sygnał, że nowa technologia jest już bezpieczna. Ten sygnał pochodzi od Goryli:
W Przełomie Technologicznym, jest to błogosławieństwo od Goryla Technologicznego (np. Microsoft ogłaszający wsparcie dla Rust w Windowsie). To sygnał, że platforma jest stabilna.
W Przełomie Biznesowym, jest to dowód wdrożeniowy od Goryla Biznesowego (np. Heineken ogłaszający sukces z Medusa.js). To sygnał, że rozwiązanie przynosi realne ROI.
Dopiero po tym sygnale, pierwszy, odważny pragmatyk w niszy decyduje się na wdrożenie, a Goryl Usługowy (taki jak Ty) pomaga mu zbudować "Cały Produkt". Sukces tego pierwszego wdrożenia staje się ostateczną, publiczną referencją, która uruchamia reakcję łańcuchową strachu przed pozostaniem w tyle (FOMO) w całej sieci pragmatyków. To jest moment, w którym Tornado oficjalnie się rozpoczyna.
Ilu jest pretendentów przed Tornadem? W fazie Kręgielni, tuż przed wybuchem Tornada, może istnieć wielu (5-10) obiecujących pretendentów do tronu Goryla Usługowego. To czas intensywnej konkurencji o zbudowanie najlepszego "Całego Produktu" i zdobycie tych kluczowych, pierwszych referencji, które odpalą burzę.
Kiedy Tornado się kończy? Tornado kończy się, gdy rynek jest nasycony, a bitwa o de facto standard jest rozstrzygnięta. Sygnałem końca jest zmiana języka rynku: pytanie "Którą technologię/partnera powinniśmy wybrać?" zostaje zastąpione przez "Jak możemy uzyskać lepszą cenę na standard X?". To jest płynne przejście na Główną Ulicę (Main Street) – fazę dojrzałości rynkowej.
Ilu zostaje po Tornadzie? Hierarchia Rynkowa. Rynek po Tornadzie jest brutalnie hierarchiczny:
Jeden Goryl: Zdobywa dominujący udział w rynku (50-60%+). Nie musi być najlepszy, ale jest postrzegany jako najbezpieczniejszy wybór. Dyktuje ceny premium.
Jeden lub dwóch Szympansów: Zdobywają znaczący, ale drugorzędny udział (15-25%). Są silną alternatywą, ale muszą konkurować ceną. Ich marże są konkurencyjne, nie premium.
Cała reszta to Małpy: Walczą o resztki rynku. Konkurują wyłącznie ceną, a ich marże są minimalne. Twoim celem jest uniknięcie tego losu za wszelką cenę.
2.3. Wewnętrzny Komitet Zakupowy: Zrozumieć Graczy i ich Role
Strategiczna sprzedaż w Tornado nigdy nie jest rozmową z jedną osobą. To kampania prowadzona wewnątrz wewnętrznego komitetu zakupowego klienta. Musisz zrozumieć trzy kluczowe role, które twoja oferta musi zadowolić. Pamiętaj, że te role mogą być odgrywane przez różne osoby, a czasem jedna osoba (np. CTO) może odgrywać kilka ról jednocześnie.
Rola #1: Biznesowy Lider Zmiany (The Business Change Leader)
Kim jest: Head of E-commerce, Dyrektor ds. Innowacji, CEO.
Jego cel: Wzrost, zdobycie przewagi konkurencyjnej, realizacja strategii biznesowej.
Jego pytanie: "Czy to rozwiązanie pomoże nam wygrać rynek?".
Rola #2: Lider Optymalizacji (The Optimization Leader)
Kim jest: Head of Engineering, Lider Zespołu Deweloperskiego.
Jego cel: Efektywność, produktywność zespołu, jakość i szybkość dostarczania oprogramowania.
Jego pytanie: "Czy to rozwiązanie uczyni mój zespół szybszym i bardziej efektywnym?".
Rola #3: Strażnik Platformy (The Platform Guardian)
Kim jest: Head of SRE, Dyrektor ds. Infrastruktury, Architekt Enterprise, CISO.
Jego cel: Stabilność, skalowalność, bezpieczeństwo i kontrola kosztów operacyjnych (TCO).
Jego pytanie: "Czy to rozwiązanie jest bezpieczne, skalowalne i czy nie wysadzi nam budżetu w powietrze za rok?".
2.4. Dynamika Władzy: Kto Decyduje, a Kto Wetuje?
Rola, jaką te archetypy odgrywają w procesie decyzyjnym, zależy całkowicie od natury przełomu.
W Przełomie Technologicznym:
Główny Bohater (Czempion i Inicjator): Lider Optymalizacji lub Strażnik Platformy. To on ma problem i to on jest twoim głównym celem.
Kluczowy Sojusznik: Musisz go uzbroić w argumenty biznesowe, aby mógł przekonać Biznesowego Lidera Zmiany (który jest tu Nabywcą Ekonomicznym) do zatwierdzenia budżetu.
Twoja strategia: Sprzedajesz do lidera technicznego, ale myślisz o tym, jak on sprzeda to swojemu szefowi.
W Przełomie Biznesowym:
Główny Bohater (Czempion i Nabywca Ekonomiczny): Biznesowy Lider Zmiany. To on jest właścicielem problemu i budżetu.
Kluczowy Strażnik Bramy: Lider Optymalizacji i Strażnik Platformy mają prawo weta. Ich zadaniem jest techniczna walidacja twojego rozwiązania. Ich "nie" może zabić projekt, nawet jeśli lider biznesowy jest przekonany.
Twoja strategia: Jest dwutorowa. Prowadzisz sprzedaż strategiczną do lidera biznesowego, jednocześnie prowadząc sprzedaż techniczną do liderów technologicznych, aby zneutralizować ich obiekcje i zamienić ich w sojuszników.
2.5. Wniosek Fazy Analizy: Zrozumienie Mapy to Nie To Samo, co Wygranie Wojny
W tym rozdziale stworzyliśmy mapę pola bitwy. Zrozumieliśmy, że Tornado może być napędzane przez dwa różne silniki – Przełom Technologiczny lub Biznesowy – i że każdy z nich tworzy zupełnie inną dynamikę rynkową i wymaga innej strategii "Kręgielni". Zobaczyliśmy, jak brutalnie hierarchiczny jest rynek po przejściu burzy, z miejscem dla tylko jednego Goryla i kilku Szympansów.
Co najważniejsze, zidentyfikowaliśmy kluczowych graczy w wewnętrznej grze o tron u klienta: Biznesowego Lidera Zmiany, Lidera Optymalizacji i Strażnika Platformy. Zrozumieliśmy, że w zależności od natury przełomu, ich role – od inicjatora po strażnika z prawem weta – ulegają fundamentalnej zmianie.
Jaki jest zatem ostateczny wniosek z tej analizy?
Samo zrozumienie anatomii Tornada nie wystarczy.
Możesz perfekcyjnie zdiagnozować, że nadchodzi burza, możesz idealnie zmapować wewnętrzny komitet zakupowy, ale jeśli twoja oferta, twoja komunikacja i twoja strategia nie będą precyzyjnie dopasowane do twojego DNA zdiagnozowanego w Fazie 0 (Lustro), przegrasz.
Firma o DNA "Architekta Poziomu Principal", która próbuje sprzedawać do "Biznesowego Lidera Zmiany" językiem wzrostu, będzie brzmiała fałszywie. Firma o DNA "Eksperta Domenowego", która nie potrafi uspokoić obaw "Strażnika Platformy", nigdy nie przejdzie przez jego bramę.
Dlatego mapa, którą właśnie stworzyliśmy, nie jest jeszcze planem zwycięstwa. Jest tłem, na którym, w kolejnych rozdziałach, zbudujemy strategię. Strategię, która połączy twoją autentyczną supermoc z głębokim zrozumieniem mechaniki rynku, aby stworzyć ofertę, której nie da się oprzeć.
Test Tornada: Rust vs. Go
Każdy z nas prowadzi firmę w tym samym, wyczerpującym wyścigu. To gra o bycie "lepszym dostawcą" w czerwonym oceanie setek podobnych firm usługowych IT. Konkurujemy portfolio, stawką godzinową i pozycją w rankingu Clutch. Ta gra rzadko prowadzi do zbudowania trwałej, dominującej pozycji na rynku. Prawdziwe zwycięstwo, status Goryla Usługowego, wymaga czegoś więcej: świadomego wyboru fali technologicznej, która jest na tyle potężna, by zredefiniować zasady gry i stworzyć na szczycie próżnię do wypełnienia.
Celem tego raportu nie jest kolejna akademicka analiza technologii. To strategiczny rekonesans. Używamy precyzyjnego i bezlitosnego frameworku "Testu Tornada", aby ocenić dwie fundamentalnie różne ścieżki, które stoją dziś przed każdą ambitną firmą technologiczną.
Dlaczego właśnie Rust i Go?
Ponieważ te dwie technologie nie są po prostu dwoma językami programowania. Reprezentują dwa archetypy strategicznych decyzji, dwa zupełnie inne pola bitwy, na których możemy walczyć o przyszłość naszej firmy:
Go (Golang) — Król Głównej Ulicy: To obecny, niekwestionowany władca ery chmurowej. Dojrzały, pragmatyczny, wspierany przez Google i stanowiący fundament ekosystemu Kubernetes. Wybór Go to wejście na ogromny, ugruntowany rynek, na którym popyt jest pewny, a "Cały Produkt" jest w pełni rozwinięty. To gra na "Głównej Ulicy" — bezpieczna, ale i zatłoczona. Pytanie strategiczne brzmi: czy na tak dojrzałym rynku jest jeszcze miejsce na zbudowanie dominacji, czy to już tylko walka o udział i marżę?
Rust — Rewolucyjny Pretendent do Tronu: To technologia o fundamentalnie innej obietnicy. Zamiast prostoty, oferuje bezkompromisowe bezpieczeństwo i wydajność. Jej "Fosa Kompetencyjna" jest legendarnie głęboka, co odstrasza większość, ale dla nielicznych tworzy historyczną szansę na zbudowanie fosy biznesowej. Wybór Rusta to zakład, że nadchodzi Tornado napędzane potrzebą niezawodności w krytycznych systemach. Pytanie strategiczne brzmi: czy ta fala jest wystarczająco silna i szeroka, a tron Goryla Usługowego wciąż pusty, aby uzasadnić ryzyko i inwestycję w trudną, ale potencjalnie rewolucyjną technologię?
Ten raport to strategiczny sparing. Zderzamy ze sobą dojrzałego króla z ambitnym pretendentem. Używając "Testu Tornada", nie pytamy "która technologia jest lepsza?". Pytamy: "Które pole bitwy daje nam, jako firmie usługowej, większą szansę na ucieczkę z czerwonego oceanu i zdobycie tronu Goryla?".
Każda faza Testu Tornada ma także etap “Challengera” czyli pytania kontrujące nasze tezy, pytania, które pewnie także Ty zadajesz sobie czytając poniższy raport.
Technologia: Rust vs. Go (Golang)
Data analizy: 8 września 2025
Analityk/wersja: Gemini 2.5 pro zasilony ebookiem Test Tornada i szablonem raportu.
Hipoteza przewodnia (1 zdanie): Rust tworzy warunki dla nowego, wysokomarżowego Goryla Usługowego (dominującego lidera rynku) w niszy systemów krytycznych, podczas gdy Go jest dojrzałym rynkiem "Głównej Ulicy", gdzie walka toczy się o udział, a nie o tron.
Zakres rynku/nisz: Infrastruktura chmurowa, systemy wbudowane (embedded), FinTech, backendy o wysokiej wydajności.
Źródła/rozmowy: Publiczne dane (raporty Stack Overflow, CNCF), keynote'y z konferencji (KubeCon, RustConf), analizy rynkowe, publiczne case studies (Microsoft, AWS, Google, Cloudflare).
Executive Summary
Rust
Werdykt: ✅ GO
Confidence (0–100%): 90%
Dlaczego teraz (one-liner): Tornado (gwałtowna fala masowej adopcji) właśnie się formuje, Przepaść Talentowa jest ogromna, a tron Goryla Usługowego jest całkowicie pusty.
Najmocniejszy sygnał / największe ryzyko: Błogosławieństwo od wszystkich Goryli Technologicznych i pusty tron / Konieczność zbudowania elitarnego, drogiego zespołu od zera.
Decyzja warunkowa (gate): Jeśli do Q2 2026 nie zdobędziemy 1-2 projektów typu Lighthouse (strategicznych, publicznych wdrożeń referencyjnych) w niszy migracji C++, dokonujemy reewaluacji przyczółka.
Go
Werdykt: ❌ NO-GO (dla strategii "Tornado")
Confidence (0–100%): 95%
Dlaczego teraz (one-liner): Tornado dawno minęło, rynek jest nasycony, a tron Goryla Usługowego jest rozdrobniony na wielu silnych graczy (Szympansów - silnych graczy nr 2).
Najmocniejszy sygnał / największe ryzyko: Ogromna popularność i dojrzałość ekosystemu / Ekstremalna konkurencja i presja na marże (czerwony ocean).
Decyzja warunkowa (gate): N/A. To jest rynek "Main Street", wymagający innej strategii (walka o udział, a nie o dominację).
F1 — Technologia (czy to inny gatunek, a nie tylko lepsza wersja?)
F1.1 Przełom paradygmatyczny (0–5)
Rust: 5/5. Wprowadza fundamentalnie nowy model zarządzania pamięcią (ownership & borrow checker), eliminując całe klasy błędów i potrzebę garbage collectora. Jest to przełom paradygmatyczny – zmiana, która czyni stary sposób pracy przestarzałym – w programowaniu systemowym, łącząc bezpieczeństwo i wydajność w sposób wcześniej niemożliwy.
Go: 4/5. Wprowadził przełom w prostocie i produktywności dla systemów sieciowych. Model współbieżności (goroutines, channels) był rewolucją w praktyce, upraszczając coś, co w Javie/C++ było ekstremalnie złożone. Nie jest to jednak tak fundamentalna zmiana w modelu obliczeń jak w przypadku Rusta.
Wniosek: Obie technologie są rewolucyjne, ale przełom Rusta jest głębszy i dotyka bardziej fundamentalnych problemów informatyki, co tworzy większy potencjał na redefinicję rynku.
F1.2 Przewaga 10× (0–5)
Rust: 5/5. Przewaga 10x leży w redukcji ryzyka. Microsoft publicznie podaje, że ~70% ich krytycznych luk to błędy pamięci – Rust eliminuje je w czasie kompilacji. Dla Strażnika Platformy (osoby odpowiedzialnej za stabilność i bezpieczeństwo systemu), jest to przewaga 100x.
Go: 4/5. Przewaga 10x leży w produktywności deweloperskiej (TTM). Zespół może dostarczać niezawodne usługi sieciowe znacznie szybciej niż w Javie/C++. Jest to ogromna wartość dla Lidera Optymalizacji (osoby odpowiedzialnej za efektywność zespołu deweloperskiego).
Wniosek: Obie oferują ogromną przewagę, ale Rust rozwiązuje problem o wyższej wartości strategicznej (bezpieczeństwo vs. szybkość developmentu), co pozwala na dyktowanie wyższych cen za usługi Goryla Usługowego.
F1.3 Fosa kompetencyjna (0–5)
Rust: 5/5. Fosa kompetencyjna – bariera wiedzy oddzielająca ekspertów od amatorów – jest w przypadku Rusta legendarna. Stroma krzywa uczenia się i złożoność koncepcyjna (borrow checker, lifetimes) tworzy trwałą, głęboką barierę, gwarantując rynek na elitarną, wysokomarżową ekspertyzę.
Go: 2/5. Go został celowo zaprojektowany, by mieć płytką fosę. Prostota i mała liczba funkcji to jego główne zalety. To przyspiesza adopcję, ale prowadzi do szybkiej komodytyzacji usług, ponieważ rynek szybko nasyca się kompetentnymi deweloperami.
Wniosek: Fosa Rusta jest idealnym fundamentem dla Goryla Usługowego, chroniąc jego marżę. Płytka fosa Go jest strategicznym zagrożeniem, prowadzącym do walki cenowej.
F1.4 Szerokość Tornada (0–5)
Rust: 4/5. Zasięg jest ogromny: od systemów wbudowanych, przez systemy operacyjne, infrastrukturę chmurową, po backendy FinTech. Wszędzie tam, gdzie bezpieczeństwo i wydajność są krytyczne. Problem, który rozwiązuje, jest uniwersalny na poziomie infrastruktury.
Go: 5/5. Zasięg jest jeszcze szerszy na poziomie aplikacji. Jest to de facto standard dla narzędzi CLI, mikrousług i dużej części ekosystemu CNCF. "Pożar" (potrzeba szybkich, skalowalnych API) jest powszechny w niemal każdej firmie.
Wniosek: Go ma szerszy, bardziej horyzontalny zasięg, co doprowadziło do jego szybkiej adopcji. Rust celuje w wertykalne, ale głębsze i bardziej wartościowe nisze, co buduje trwalszą przewagę.
Implikacja fazy: Rust → potencjał Tornada (okno 6–24 mies.). Go → bowling alley długotrwały / Main Street.
Challenger F1: Czy fosa Rusta nie jest zbyt głęboka, co spowolni adopcję? (Odpowiedź: Błogosławieństwo Goryli to niweluje, dając pragmatykom sygnał bezpieczeństwa). Czy prostota Go nie jest właśnie tym, czego potrzebuje 90% rynku, czyniąc Rusta trwale niszowym? (Odpowiedź: Rynek na usługi premium żyje w pozostałych 10%, gdzie "wystarczająco dobry" to za mało).
F2 — Rynek (czy scena jest gotowa?)
F2.1 Błogosławieństwo goryli (0–5)
Rust: 5/5. Platynowe błogosławieństwo od wszystkich: Microsoft, AWS, Google, Meta. Jest oficjalnie integrowany z Linuksem, Windowsem i Androidem. Sygnał dla rynku jest jednoznaczny i potężny.
Go: 5/5. Stworzony i promowany przez Google, jest fundamentem całego ekosystemu Kubernetes i CNCF. Błogosławieństwo jest absolutne i ugruntowane od lat.
Wniosek: Obie technologie mają maksymalne poparcie Goryli, co eliminuje ryzyko adopcji dla pragmatycznych klientów.
F2.2 Faza „przed tornadem” (0–5)
Rust: 4/5. Jesteśmy w fazie "zaawansowanej kręgielni", gdzie technologia metodycznie zdobywa kolejne nisze ("kręgle"), budując referencje i pęd przed masową adopcją. Widać to po rosnącej liczbie referencji od pragmatyków (np. Cloudflare, Figma) i ogromnym FOMO ("Fear Of Missing Out") wśród elity inżynierskiej.
Go: 1/5. Tornado dla Go miało miejsce w latach 2014-2018. Dziś to jest dojrzała technologia na "Głównej Ulicy" – fazie dojrzałości rynkowej, gdzie technologia jest standardem. Dowodem jest jej wszechobecność w ofertach pracy, kursach uniwersyteckich i status domyślnego wyboru dla narzędzi chmurowych. Pociąg już dawno odjechał.
Wniosek: Timing dla Rusta jest idealny, by wejść i zdefiniować rynek usług. W Go, rynek jest już zdefiniowany, a gra toczy się o optymalizację i udział w istniejącej strukturze.
F2.3 Przepaść talentowa (0–5)
Rust: 5/5. Ostry, strukturalny deficyt. Znalezienie doświadczonego inżyniera Rusta jest jednym z największych wyzwań rekrutacyjnych w IT, co winduje stawki i tworzy naturalny popyt na usługi firm, które ten talent posiadają.
Go: 2/5. Rynek jest zrównoważony. Dzięki prostocie języka, podaż kompetentnych inżynierów jest duża, co obniża stawki i barierę wejścia dla konkurencji.
Wniosek: Gigantyczna przepaść talentowa w Ruście tworzy idealne warunki dla Goryla Usługowego do zbudowania wysokomarżowego biznesu.
F2.4 „Pusty tron” (0–5)
Rust: 5/5. Tron jest całkowicie pusty. Rynek usług jest rozdrobniony na małe, szanowane butiki (np. Ferrous Systems, Tweede Golf), ale brakuje globalnego lidera o znaczącej skali. Istnieje ewidentny wakat na firmę, która zdefiniuje i zdominuje tę kategorię.
Go: 1/5. Rynek jest zatłoczony. Istnieje wielu silnych graczy (Szympansów, Goryla brak!), a konkurencja jest zacięta. Firmy takie jak EPAM, Accenture, Billennium czy Canonical mają rozbudowane i dojrzałe praktyki Go. Próba wejścia na ten rynek jako nowy lider byłaby niezwykle kosztowna i skazana na walkę z ugruntowaną konkurencją.
Wniosek: Szansa na zdobycie tronu w Ruście jest historyczna. W Go, gra toczy się o bycie jednym z wielu silnych graczy, a nie o dominację.
Challenger F2: Czy pusty tron Rusta nie jest sygnałem, że rynek jest wciąż zbyt mały, by go utrzymać? (Odpowiedź: Wskaźniki adopcji i inwestycje Goryli przeczą tej tezie, pokazując, że rynek gwałtownie rośnie).
F3 — Problem Biznesowy (czy gasimy prawdziwy pożar?)
Rust: 5/5. Rozwiązuje krytyczny problem bezpieczeństwa i wydajności w fundamentalnych częściach systemów. To jest "painkiller" o najwyższej możliwej wartości, z presją czasu (zero-day exploits) i regulacji. ROI jest mierzony w milionach dolarów za uniknięty incydent bezpieczeństwa.
Go: 4/5. Rozwiązuje bardzo ważny problem szybkości dostarczania i skalowalności usług. To również jest "painkiller", z mierzalnym ROI w postaci niższego TCO i szybszego TTM, ale stawka jest zazwyczaj niższa niż w przypadku Rusta.
Werdykt: Rust → Krytyczny Painkiller. Go → Painkiller.
Challenger F3: Czy klient jest gotów zapłacić 2x więcej za Rusta, jeśli Go jest "wystarczająco dobry"? (Odpowiedź: Dla systemów krytycznych, takich jak infrastruktura płatnicza czy systemy operacyjne, "wystarczająco dobry" nie istnieje, a koszt błędu jest nieskończenie wyższy niż koszt developmentu).
F4 — „Whole Product” (co musi istnieć, aby pragmatycy kupowali?)
Rust: 3/5. "Cały Produkt" – czyli kompletne rozwiązanie problemu klienta, włączając narzędzia, integracje i wsparcie – szybko dojrzewa, ale wciąż istnieją luki. To jest zarówno ryzyko, jak i szansa dla Goryla Usługowego, aby te luki wypełnić, budując własne IP i akceleratory.
Go: 5/5. "Cały Produkt" jest kompletny i niezwykle dojrzały. Tooling, biblioteki, dokumentacja i wsparcie społeczności są światowej klasy.
Wniosek: Dojrzałość Go obniża barierę wejścia i marże. Niedojrzałość ekosystemu Rusta tworzy naturalny, trwały popyt na usługi eksperckie o wysokiej wartości.
Scoring & Progi Decyzji
Interpretacja wyniku:
Rust: 62.5 / 72.5 = 86% → ✅ GO
Go: 46.4 / 72.5 = 64% → ❌ NO-GO (ponieważ wynik < 75% oraz kluczowe wskaźniki "Tornado" (F2.2, F2.4) są na poziomie 1). Wynik 64% plasuje go w kategorii WATCH, ale w kontekście strategii Tornada jest to jednoznaczny NO-GO.
Rust: Rust ma przełom 5/5, 10× 5/5 i szerokość 4/5; rynek jest w fazie Pre-Tornado, tron usług jest pusty. W 90 dni: zbudować PoC migracji C++ dla FinTechu, pozyskać lighthouse w tej niszy, zbudować akcelerator Rust-Assured Migration™.
Go: Go ma przełom 4/5, 10× 4/5 i szerokość 5/5; rynek jest na Głównej Ulicy, tron usług jest zajęty. Strategia wymagałaby walki o udział w dojrzałym rynku, a nie zdobywania nowej kategorii.