PL#8: 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:

• (free) Jak analizować rosnące projekty na Github aby ocenić ich potencjał dla Twojego SH

• (paid) narzędzie do analizy repozytoriów na Github (Big Query) aby znaleźć te najbardziej obiecujące dla Twojego SH

• (paid) Anatomia Tornada: zrozumienie tornada, zanim wejdzie się w nie z swoim SH

• (paid) 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 ).

Lista projektów OSS z ostatnich 3 miesięcy - największy przyrost gwiazdek i zgłoszonych issues

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:

Analiza projektów OSS pod kątem fosy kompetencyjnej i fosy problemu

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…