PL#9 Dlaczego setki gwiazdek na Github nie przynoszą biznesu | Forki jako sygnał potencjału OSS| Lęk przed byciem twarzą firmy vs strategia | Agentic Commerce Protocol - Goryle otwierają pusty tron

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) Od “zrobiliśmy i nic” do strategicznego OSS: Problem, Timing i Decydent jako fundament sukcesu

• (paid) Nietypowy sposób jak sprawdzić czy dany projekt OSS ma potencjał dla agencji software - po forkach go poznacie

• (paid) Jak lęk przed byciem twarzą swojej firmy, ekspertem w danej niszy warunkuje jej strategię?

• (paid) Agentic Commerce Protocol - kiedy dwóch Goryli otwiera pusty tron

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.

---

Dlaczego setki gwiazdek na Github nie przynoszą biznesu

Rozmawiałem ostatnio z SH, który zainwestował sporo czasu w budowanie OSS, zdobyli nawet kilkaset gwiazdek na Github, pojechali na konferencje, ale żadnego biznesu to nie przyniosło. Takich historii jest wiele, za każdym razem słyszę ten sam motyw:

zrobiliśmy, wypuściliśmy i ... nic.

Problem jest w tym, że nie rozumiemy problemu jaki rozwiązujemy naszym narzędziem/projektem. Tak jak to jest z tym newsletterem, jaki problem ja nim rozwiązuję?

Mój cel to pomagać firmom usługowym typu Software House rosnąć, dając gotowe, sprawdzone lekcje z mojej pracy i przemyśleń. Lekcje w różnej formie, czasem narzędzi, artykułów, nawet książek.

Lekcja zatem z takiego działania czyli z tworzenia projektu Open Source jest taka, że nie tworzymy go w dowolnym obszarze tylko musimy naprawdę dobrze zrozumieć kontekst narzędzi i rozwiązań, które są alternatywami.

Przykładowo, jeśli tworzymy narzędzie do optymalizacji zarządzania promptami w systemach agentowych to alternatywą może być prosty panel CRUD, który deweloper generuje w Cursorze w 10 min z promptami w backendzie i pozwala na ich wersjonowanie. To oczywiście przykład i alternatyw tak naprawdę jest dużo więcej, ale wiecie o co mi chodzi.

Zatem problem, który rozwiązujemy i jego otoczenie alternatywnych rozwiązań definiuje to jak kluczowe będzie skorzystanie z Waszej pomocy, jak bardzo unikatowa to będzie wiedza.

Druga kluczowa sprawa to timing.

Nie jest to taka prosta sprawa bo timing jest na dwóch poziomach: Developer Journey oraz Technology Journey (lub inaczej cykl adopcji technologii). Co się kryje pod tymi tajemniczymi pojęciami?

Developer Journey to podróż dewelopera podczas której tworzy kolejne wersje systemu dla danej firmy. Podczas tej podróży występują ciekawe momenty, które są różne w zależności od rozmiaru firmy i jej rodzaju, ale możemy je sprowadzić do takich bardzo prostych:

1. Potrzeba biznesowa - coś z biznesu prowadzi nas do wniosku, że trzeba zbudować nową część systemu. Czasem ta potrzeba pojawia się od strony zespołu technicznego, ale i tak jest argumentowana biznesowo (zaoszczędzimy/przyspieszymy/poprawimy X dzięki temu.)

2. Badanie architektury/technologii - wtedy ktoś techniczny sprawdza czy dana potrzeba może być rozwiązana i jak.

3. Szacunki i budżet. Czasem ten etap jest mocno oddzielony od samej realizacji danego systemu, szczególnie w dużych organizacjach.

4. Budowanie zespołu i rozpoczęcie prac. Tutaj mamy już wiedzę jaki mamy budżet i jaką technologią dany projekt tworzymy i chcemy go rozpocząć realizować.

5. Budowanie systemu i jego dostarczenie na produkcję.

6. Iteracja z rynkiem.

7. Powrót do punktu 0 dla obecnego systemu i tworzenie nowych modułów/wersji.

Jak myślicie, czy firma w etapie 5 będzie tak samo otwarta na współpracę z Agencją Software jak firma w etapie 1, 2 lub 3? z moich obserwacji to przepaść. Jeśli trafiacie do firmy w momencie wyboru technologii to możecie być poproszeni o pomoc w całym procesie szacunków, a potem wytworzenia. Jeśli lądujecie w fazie 4, 5 często firmy już kogoś mają, albo wewnętrznie, albo agencję. Wejście jest arcy-trudne.

Druga sprawa w timingu to Technology Journey/Adoption Cycle. Co to oznacza? jeśli technologia OSS, którą budujesz lub chcesz rozwijać jest we wczesnej fazie rynku np. nie jest jeszcze standardem, a na rynku jest duży gracz, który obecnie ten standard wyznacza, to warto o tym wiedzieć. Co więcej, tych etapów adopcji technologii jest kilka (innowatorzy, wizjonerzy, przepaść, wczesny rynek, kręgielnia, tornado/główny rynek, późny rynek) i zrozumienie gdzie dana kluczowa technologia jest ma kolosalne znaczenie. Jeśli inwestujecie czas i energię w coś niszowego, wcześnie na rynku to jego adopcja będzie trwała długo, bardzo długo. Drugą stroną tej podróży jest technologia, która już dawno jest na tzw. głównym rynku, dajmy na to Erlang, ale niestety nie stała się wiodącym standardem dla wielu nisz, ale raczej jest ciągle wyjątkową technologią do określonego segmentu.

Nie chcę się tutaj za mocno rozpisywać, ale ten przykład jest po to aby pokazać, że:

wybór projektu OSS może szybko być złym strzałem jeśli rozwiązujemy jakiś niewielki problem (biorąc pod uwagę alternatywy), późno w podróży developera, technologią która jest np. bardzo wcześnie na rynku.

Natura problemu - biznes czy tech?

Wracając jeszcze do problemu, który dany projekt rozwiązuje to kluczowe jest także to, czy ten problem jest bezpośrednio osób technicznych czy wychodzi od biznesu.

Jeśli wychodzi od biznesu (przykładowo: wkurza ich cennik Stripe i chcą zmienić dlatego zlecają to osobom technicznym aby podały alternatywy) to nawet jeśli stworzyłeś mega super fajne narzędzie adresujące ten problem to osoby techniczne, które dotrą do niego i powiedzą “wow! ta firma jest super” nie kupią tego od Ciebie tylko pójdą do szefa i powiedzą “no jest taki tool, ale kosztuje/nie wiemy jaka jest licencja”. Z dużą dozą szczęścia może się uda, ale często w tym właśnie momencie same osoby techniczne mówią “to może poszukam czegoś darmowego...”.

Budowanie projektów OSS, które są późno w developer journey może mieć jednak swój sens...

Przykładowo w 2015 Mike Grabowski stworzył projekt OSS na React Native, który potem został połączony z React Native core. To sprawiło, że Mike i firma za nim stojąca stała się rozpoznawalna na rynku. Sam projekt OSS stał się akredytacją, dowodem, że Mike i jego zespół są mistrzami w danej technologii. Natomiast to tylko przepustka, taki projekt to coś co pozwala na budowanie marki firmy, która pracuje z największymi graczami na rynku, która jest zapraszana na konferencje. Niestety, sam projekt OSS w takim przypadku będzie tylko i aż - górą lejka marketingowego i z racji wielu tysięcy gwiazdek na Github - darmowym banerem reklamowym do super określonej grupy docelowej.

Taktyka OSS polegająca na pisaniu bardzo popularnych projektów, które nie trafiają wcześnie w Developer Journey, ma sens jeśli poruszamy się w ekosystemie problemów, które dana technologia rozwiązuje dla osób technicznych. Wówczas budowanie w oczach tych liderów reputacji ma sens bo oni są decydentami ekonomicznymi i kolejny problem, dużo wyżej w developer journey, mogą Tobie zlecić, szczególnie jeśli dużo o tym będziesz mówił, pisał, i pomagał tym ludziom.

To kluczowa różnica - zrozumieć źródło problemu i dla kogo go rozwiązujesz. Jeśli jest to decydent technologiczny to wówczas budowa projektów OSS późno w Developers Journey nadal się zwróci bo ten decydent dzięki temu Tobie zaufa.

Dlatego warto stanąć trochę z boku tych swoich prób i zadać sobie pytanie:

Czy faktycznie wiem, w którym momencie, jaki problem i dla kogo rozwiązuję?

jeśli nie, to zapewne zdajesz się na szczęśliwy los... co czasem też się udaje, ale częściej, widzę to z autopsji, prowadzi do efektu, że nawet jak dana Agencja Software dosłownie “siedzi” na kurze znoszącej lub mogącej znosić dla nich złote jajka to nie wie o tym i rozmawia z rynkiem w nieodpowiedni sposób.

Nietypowy sposób jak sprawdzić czy dany projekt OSS ma potencjał dla agencji software - po forkach go poznacie

Ostatnio odkryłem kolejne pokłady wartościowych danych na Github. Forki…