Jeśli chcesz zobaczyć, jak w praktyce wygląda myślenie o open source jako o biznesie, posłuchaj całej rozmowy z Przemkiem Jóźwiakowskim. To odcinek o budowaniu produktu, rozmowach z rynkiem i odcinaniu się od złudzeń.
Posłuchaj odcinka DSS#13 na YouTube →Artykuły, które czytasz, są inspirowane tematami poruszanymi w podcaście Druga Strona Sukcesu. Nie są streszczeniem rozmowy 1:1, ale rozwinięciem tego, co padło między pytaniami, błędami i konkretnymi decyzjami. W przypadku odcinka DSS#13 temat jest wyjątkowo praktyczny: czy open source może być modelem biznesowym dla firmy i kiedy taki ruch ma sens.
To nie jest tekst o ideologii otwartego kodu. To tekst o tym, jak zbudować produkt, którego wartość wynika z realnego problemu, a nie z ładnej prezentacji. Przemek opowiada o tym z perspektywy przedsiębiorcy, który łączy technologię, sprzedaż i budowanie firm. I właśnie dlatego jego odpowiedzi są cenne: nie brzmią jak teoria z podręcznika, tylko jak wynik wielu iteracji, pomyłek i zderzeń z rynkiem.
Open source jako model biznesowy nie zaczyna się od kodu, tylko od problemu
Największy błąd przy myśleniu o open source jest prosty: najpierw powstaje projekt, a dopiero potem ktoś zastanawia się, jak go sprzedać. W rozmowie Przemek odwraca ten schemat. Mówi wprost, że zanim usiądziesz do budowania czegokolwiek, trzeba wyjść na rynek i zrozumieć, jaki problem naprawdę boli klienta, jak on go nazywa i za co w ogóle jest gotów zapłacić.
To szczególnie ważne w open source, bo taki produkt łatwo pomylić z „fajnym kodem”. Kod może być dobry, czysty, sensowny technicznie, ale jeśli nie rozwiązuje palącego problemu, to zostaje projektem dla programistów. Przemek bardzo wyraźnie mówi, że lepiej przez trzy miesiące chodzić po rynku i rozmawiać z ludźmi niż po pół roku odkryć, że zbudowało się coś, czego nikt nie chce.
W praktyce oznacza to trzy rzeczy:
- najpierw rozmowy z potencjalnymi klientami,
- potem dopiero szkic rozwiązania,
- na końcu kod i dopracowanie produktu.
To brzmi banalnie, ale w biznesie właśnie banalne rzeczy najczęściej są pomijane. Przemek zauważa, że często problem nie leży tam, gdzie wydaje się founderowi. W jego projekcie data backbone początkowo wydawało się, że chodzi o generowanie raportów finansowych. Rynek pokazał coś innego: ważniejsze było liczenie rentowności, pilnowanie budżetu i łączenie danych z wielu źródeł. Gdyby poszedł za pierwszym pomysłem bez rozmowy z CFO, zbudowałby coś zbyt wysokiego względem realnej potrzeby.
Dlaczego open source może budować przewagę, a nie tylko koszty
W wielu firmach open source kojarzy się z darmością. Przemek patrzy na to zupełnie inaczej. Mówi, że sam kod coraz rzadziej jest przewagą, bo w wielu przypadkach można go odtworzyć. Prawdziwa przewaga powstaje dopiero wtedy, gdy produkt jest osadzony w konkretnym problemie, konkretnym rynku i konkretnym kontekście użytkownika. Open source staje się wtedy nośnikiem wartości, a nie celem samym w sobie.
W jego podejściu ważne jest też to, że kod nie musi być schowany. Jeśli rozwiązanie ma wartość wtedy, gdy ktoś może je pobrać, zainstalować i podłączyć do swoich źródeł danych, to nie ma sensu traktować kodu jak tajemnicy państwowej. Przemek wprost mówi, że niewiele jest dziś rozwiązań high-tech, które naprawdę trzeba ukrywać przed konkurencją. Znacznie ważniejsze jest to, czy produkt faktycznie działa i czy rozwiązuje problem w sposób, który klient rozumie.
To podejście widać też w jego porównaniu do WordPressa. WordPress jest open source, a mimo to zdominował internet. Dlaczego? Bo nie sprzedaje samego kodu, tylko możliwość szybkiego uruchomienia wartościowego rozwiązania. Właśnie tak można myśleć o open source w biznesie:
- jako o otwartej bazie technologicznej,
- jako o sposobie na zbudowanie społeczności i kontrybutorów,
- jako o produkcie, który łatwo wdrożyć i rozwinąć,
- jako o fundamencie pod płatne usługi, integracje albo wdrożenia.
W rozmowie Przemek zaznacza też, że wokół open source można zbudować wiele modeli zarabiania. Sam projekt może być darmowy, ale wokół niego można sprzedawać wdrożenia, konfigurację, wsparcie, wersje enterprise czy specjalistyczne rozszerzenia. Najpierw jednak musi istnieć jasna wartość. Bez niej open source jest tylko repozytorium.
Największy błąd founderów: budowanie firmy na sobie
To jedna z najmocniejszych obserwacji z całej rozmowy. Przemek przyznaje, że jego Akademia Programowania odniosła sukces, ale miała też poważny problem: była zbudowana na nim. Kiedy chciał z niej wyjść, zajęło mu to cztery lata. To klasyczna pułapka firm opartych na założycielu, tylko że w przypadku open source wcale nie jest ona rzadsza. Wręcz przeciwnie — wiele projektów zależy od jednej osoby, która wszystko rozumie, wszystko ustawia i wszystko kontroluje.
Jeśli taki founder chce zbudować model biznesowy wokół open source, musi od początku myśleć nie tylko o produkcie, ale też o strukturze działania. Kto będzie obsługiwał klienta? Kto będzie wdrażał? Kto będzie odpowiadał za rozwój? Co dzieje się wtedy, gdy założyciel znika z operacji? Przemek mówi wprost: nie warto zaczynać od modelu, w którym trzeba osobiście „zakasać rękawy i cisnąć”, jeśli docelowo firma ma być skalowalna.
To prowadzi do bardzo praktycznego wniosku. Jeśli myślisz o open source jako o biznesie, zadbaj o to, żeby produkt nie był zależny od twojej codziennej obecności. W przeciwnym razie będziesz właścicielem nie firmy, tylko bardzo wymagającej pracy. Na poziomie decyzji warto sprawdzić:
- czy produkt można wdrożyć bez twojej stałej obecności,
- czy da się zbudować prosty onboarding,
- czy dokumentacja wystarczy, by klient mógł ruszyć samodzielnie,
- czy ktoś poza tobą rozumie proces i wartość produktu.
Przemek pokazuje też, że w jego przypadku sukces Akademii wynikał z dwóch rzeczy: z pracy jeden na jeden i z bardzo wymagającego podejścia do nauczania. To ważne, bo w open source podobną przewagę może dawać nie tylko sam kod, ale też sposób wdrożenia, komunikacji i pracy z klientem. Kod jest podstawą. Model działania robi różnicę.
W połowie rozmowy pojawia się bardzo konkretny wątek: jak wygląda zderzenie pomysłu z rynkiem i dlaczego problem bywa zupełnie gdzie indziej, niż myśli founder. Jeśli budujesz produkt open source albo myślisz o własnym SaaS-ie, ten fragment jest szczególnie wart odsłuchania.
Posłuchaj odcinka DSS#13 na YouTube →Open source i monetyzacja: gdzie naprawdę pojawiają się pieniądze
W rozmowie pojawia się bardzo zdrowe podejście do zarabiania. Przemek mówi, że można zarabiać na wszystkim, ale warunek jest jeden: trzeba rozumieć, jaką wartość dostarczasz i komu. To dlatego open source sam w sobie nie jest modelem zarobkowym. Jest raczej platformą, na której można zbudować kilka różnych strumieni przychodu.
Przemek zwraca uwagę, że firma zazwyczaj działa wokół jednego głównego procesu. Albo dostarczasz konsultację, albo rozwiązanie, albo budowę, albo wdrożenie. W przypadku open source ten proces może wyglądać inaczej, ale logika pozostaje ta sama: klient płaci za efekt, nie za sam fakt, że kod jest publiczny. To oznacza, że zarabianie może pojawić się na poziomie:
- wdrożeń i integracji,
- wsparcia technicznego,
- wersji dla większych organizacji,
- usług wokół produktu,
- automatyzacji, które skracają czas pracy klienta.
Przemek sam podaje przykład rozwiązania finansowego, które ma działać jak „WordPress dla danych”. Kod ma być otwarty, ale wartość ma tkwić w tym, że klient może wziąć projekt, zainstalować go, podłączyć własne dane i dostać konkretne odpowiedzi. To bardzo dobry przykład tego, jak open source może być produktem, a nie jedynie wspólnym repozytorium.
Jest tu jeszcze jedna ważna rzecz: sprzedaż wokół takiego produktu nadal wymaga zrozumienia rynku. Nawet jeśli technicznie da się zrobić wszystko, to i tak trzeba wiedzieć, jakie problemy są palące. Przemek podkreśla, że rozwiązanie, które jest wartościowe technicznie, nie zawsze jest jeszcze warte pieniędzy. A bez płatności nie ma biznesu. To brutalnie prosty filtr.
Automation first i open source: kiedy warto projektować bez człowieka
W rozmowie pada też temat automation first i AI first. Przemek wyjaśnia to bardzo jasno: nie chodzi o to, żeby najpierw robić coś ręcznie, a potem próbować to zautomatyzować. Chodzi o to, żeby od początku projektować proces tak, by technologia mogła go obsłużyć. To bardzo ważne w kontekście open source business, bo taki model często wymaga myślenia systemowego, a nie tylko produktowego.
Jeśli budujesz otwarty produkt, który ma działać bez twojej ciągłej ingerencji, musisz wiedzieć, które elementy są procesem, a które tylko obsługą procesu. Przemek daje bardzo praktyczny obraz: technologia jest sztywna, człowiek się dopasuje. Jeśli proces jest źle zaprojektowany, automatyzacja go nie uratuje. Właśnie dlatego trzeba najpierw zrozumieć wartość i przebieg pracy, a dopiero potem wciskać w to AI, Make czy inne narzędzia.
To podejście daje też ciekawą przewagę open source. Jeśli rdzeń rozwiązania jest otwarty, ale proces wdrożenia został zaprojektowany tak, by dało się go uruchomić automatycznie lub półautomatycznie, to firma zyskuje skalowalność. Można wtedy budować produkt, który sam się dystrybuuje, a człowiek wchodzi tylko tam, gdzie naprawdę jest potrzebny.
Przemek przyznaje, że w jego biznesach część procesów już działa bez człowieka. To nie jest wizja przyszłości, tylko teraźniejszość. Z biznesowego punktu widzenia to ważna lekcja: open source może być fundamentem nie tylko dla społeczności, ale też dla firmy, która działa oszczędnie, szybko i przewidywalnie.
Budżet, czas i ryzyko: open source też kosztuje
Jest jeszcze jeden mit, który warto rozbić: skoro coś jest open source, to musi być tanie. Nie. Przemek mówi wprost, że żeby zbudować bardziej złożone rozwiązanie, trzeba liczyć się z realnym budżetem i zasobami. W jego przypadku sam z partnerem wydali ponad pół miliona złotych na eksperymenty. To ważny sygnał dla każdego, kto myśli, że otwarty kod sam rozwiąże problem finansowania projektu.
W praktyce open source business wymaga nakładu w trzech miejscach:
- badanie rynku — żeby nie budować w próżni,
- tworzenie produktu — żeby rozwiązanie rzeczywiście działało,
- sprzedaż i dystrybucja — bo nawet dobry open source nie sprzeda się sam.
To ważne szczególnie wtedy, gdy ktoś myśli o budowaniu firmy samodzielnie. Przemek nie ukrywa, że na starcie można zaczynać od małej skali, korzystając z kursów, własnego czasu i prostych narzędzi. Ale jeśli projekt ma uderzać w rynek B2B, w bardziej złożone procesy albo w branże wymagające zaufania, budżet rośnie błyskawicznie. I trzeba to uczciwie uwzględnić, zanim powstanie pierwsza linia kodu.
Wniosek jest prosty: open source nie jest skrótem do biznesu. Jest jednym z możliwych sposobów zbudowania biznesu, ale nadal wymaga dyscypliny, testów, rozmów z rynkiem i odrobiny pokory. Bez tego łatwo stworzyć projekt, który technicznie robi wrażenie, ale nie generuje żadnej realnej wartości.
Co z tego wynika dla przedsiębiorcy, który myśli o open source
Najważniejsza lekcja z rozmowy z Przemkiem jest taka, że open source działa biznesowo tylko wtedy, gdy jest osadzony w realnym problemie i realnej dystrybucji. Kod jest narzędziem. Przewaga powstaje dopiero na styku technologii, rynku i procesu. Jeśli produkt rozwiązuje palący problem, klient będzie gotów za niego zapłacić — nawet jeśli sam kod jest otwarty.
Druga lekcja dotyczy ego. Przemek bardzo mocno podkreśla, że myślenie „wiem najlepiej” zabija rozwój. W biznesie lepiej zakładać, że się nie wie, stawiać hipotezy i je sprawdzać. W open source to szczególnie ważne, bo łatwo zakochać się we własnym rozwiązaniu. A rynek nie płaci za zakochanie. Rynek płaci za trafność.
Trzecia rzecz to kontekst. To, co działa w jednej branży, w drugiej może być kompletnie bezużyteczne. Dlatego Przemek tak mocno stawia na rozmowy z ludźmi z rynku, szukanie ich języka i zderzanie swoich założeń z rzeczywistością. Jeśli chcesz zbudować firmę opartą o open source, zacznij od pytań:
- Jaki problem rozwiązuję?
- Kto naprawdę za niego zapłaci?
- Co jest w tym procesie do zautomatyzowania?
- Co musi zostać zrobione przez człowieka?
- Jaką przewagę daje mi otwarty kod, a nie tylko „ładna technologia”?
Odpowiedzi na te pytania nie muszą być perfekcyjne. Mają być wystarczająco dobre, żeby ruszyć i sprawdzić je w praktyce. Właśnie o tym jest ta rozmowa: o ruchu, iteracji i odwadze do odrzucenia własnego pomysłu, jeśli rynek mówi coś innego.
Jeśli dziś myślisz o open source jako modelu biznesowym, nie zaczynaj od repozytorium. Zacznij od rozmowy z rynkiem, problemu i wartości. Kod będzie później. A jeśli chcesz zobaczyć, jak Przemek Jóźwiakowski myśli o tym w szerszym kontekście — od budowlanki po IT, od błędów po automatyzację — koniecznie obejrzyj cały odcinek.
To nie jest odcinek o open source tylko z nazwy. To rozmowa o tym, jak naprawdę buduje się biznes technologiczny: od błędów, przez rynek, po decyzje, które decydują o tym, czy produkt żyje. Obejrzyj pełną rozmowę, jeśli chcesz więcej konkretów i kontekstu.
Posłuchaj odcinka DSS#13 na YouTube →