TL;DR

Model „fair code” – alternatywa dla tradycyjnego open source, pozwalająca na darmowe użycie przy zakazie komercjalizacji przez trzecie strony
Adopcja przed zyskiem – skupienie na wzroście użytkowników zamiast na natychmiastowej monetyzacji jako kluczowa strategia rozwoju
Product Hunt i Hacker News – kluczowe platformy do zdobycia pierwszych użytkowników i uwagi inwestorów
Telemetria wprowadzona późno – dodana dopiero po roku działania, z pełną transparencją i możliwością wyłączenia
Równowaga work-life – praca 2-3 dni tygodniowo dla innych firm przez 3 lata, aby utrzymać projekt przy życiu
Design ma znaczenie – inwestycja w profesjonalny wygląd (250$ na Fiverr) od samego początku jako czynnik sukcesu
Community-to-employee pathway – Ricardo pracował 5 miesięcy za darmo, tworząc 50 node’ów przed zatrudnieniem

Jan Oberhauser, founder i CEO n8n, dzieli się w rozmowie z Aviyel swoją drogą od pracy w przemyśle filmowym do zbudowania 20-osobowego zespołu wokół projektu automatyzacji workflow’ów.

Geneza n8n – od problemów branży filmowej do automatyzacji

Oberhauser rozpoczął karierę w przemyśle filmowym jako kompozytor i pipeline TD w firmach takich jak Digital Domain. Ostatnim filmem, nad którym pracował, był „Maleficent” Disneya. Jego rola polegała na automatyzacji procesów dla artystów.

„Widziałem tam duży potencjał do automatyzacji rzeczy, ale wiele nigdy nie zostało zautomatyzowanych. Mieliśmy inteligentnych ludzi, którzy marnowali czas na rzeczy, których nie powinni robić” – opisuje Oberhauser problemy branży.

Wszystkie narzędzia w branży VFX były node-based. Artyści znajdowali się w pozycji „żebrania” o automatyzację, podczas gdy technical director był zawsze w sytuacji odmowy z powodu braku czasu. „Nie jest to miła pozycja dla nikogo.”

Boilerplate code jako uniwersalny problem

Po odejściu z branży filmowej Oberhauser założył startup Linkfish w branży bookmarkingu, ale problem pozostał ten sam: „Zawsze miałem ten sam problem – marnowałem dużo czasu na ten rodzaj boilerplate code. Dostajesz informacje z GitHub – musisz zbadać APIs, napisać boilerplate code, napisać prawdziwy kod, znaleźć serwer, uploadować tam, dostać certyfikaty, domenę. To było wszystko super denerwujące.”

Szczególnie frustrujące było to, że „te rzeczy zostały już zrobione milion razy przez milion różnych ludzi.”

Nazwa n8n – inspiracja Kubernetes

Oberhauser potrzebował być efektywny z czasem jako solo founder. Miał kilka ulubionych nazw, ale wszystkie były zajęte. Jedna dostępna opcja to „nodemation” (node + automation), ale była za długa.

„Leżałem w łóżku pewnej nocy i pomyślałem: mogę zrobić to samo co Kubernetes – N, 8 liter, N. I to wygląda znacznie lepiej.”

Początkowo w wynikach Google dominował belgijski piosenkarz o tej nazwie. „Jeśli wpisałeś n8n trzy lata temu, wszystko było o tym belgijskim piosenkarzu. Jeśli wpiszesz teraz n8n, wszystko jest o nas.”

Pierwszy workflow i początki projektu

Pierwsze eksperymenty rozpoczęły się prawdopodobnie w lutym lub marcu 2018 roku. Oberhauser testował połączenie danych JSON i binarnych. Pierwszy workflow łączył dane z Google Sheets, używał merge node’a (jeden z pierwszych) i generował karty z imionami – przykład: kartki urodzinowe.

Praca programistyczna trwała do czerwca 2019. „Programowałem tam przez jakiś czas, aż poczułem się wystarczająco pewnie, że projekt był użyteczny. Wciąż miałem problemy, nie miałem odpowiedniej dokumentacji.”

Moment przełomowy: Product Hunt i Hacker News

Oberhauser opublikował projekt na GitHub w czerwcu 2019, następnie na Alternative.to i Hacker News dla początkowego feedback’u. Prawdziwy przełom nastąpił na początku października – launch na Product Hunt i Hacker News.

„Miałem szczęście – robiłem launch tylko na Product Hunt. Chciałem później uruchomić wieczorem na Hacker News, ale ktoś inny to opublikował, więc musiałem tylko to upvote’ować i faktycznie trafiłem na pierwszą stronę.”

Rezultat był natychmiastowy: ludzie uznali, że naprawdę im się to podoba, zaczęli używać, rozpoczęli contribution’y. „Wtedy też dostałem e-maile od pierwszych inwestorów.”

Oberhauser podkreśla znaczenie persystencji na tych platformach: „Czasami musisz postować kilka razy, więc ktoś faktycznie to polubi. Całkowicie w porządku jest postowanie 3-4 razy, a za czwartym razem może nastąpić przełom.”

Model „fair code” – rozwiązanie dylematów monetyzacji

Problemy tradycyjnego open source

Oberhauser myślał o licencji od początku: „Naprawdę lubiłem open source, ale byłem też świadomy wszystkich problemów, szczególnie wokół monetyzacji.” Programiści nie są tani, więc potrzebował sposobu na pełnoetatową pracę nad projektem.

Scenariusz, którego chciał uniknąć: „Tworzysz projekt open source, uruchamiasz go, ktoś go lubi – w skrajnym przypadku może to być AWS – bierze kod, tworzy hostowaną wersję i pobiera za to opłaty. Znajdą błąd, zgłoszą go, ja go naprawię, zapewniam wsparcie za darmo i nigdy nie zarabiam ani centa.”

„To nie jest w niczyim interesie. Nie w moim, szczególnie nie w interesie społeczności, bo problem polega na tym, że pieniądze nie idą do projektu, tylko gdzieś indziej i znikają. Ale chcesz, żeby szły do firmy stojącej za projektem, bo oni wkładają pieniądze z powrotem w projekt.”

Rozwój koncepcji fair code

Oberhauser znalazł Commons Clause, która zakazywała komercjalizacji kodu. „Naprawdę podobał mi się pomysł.” Uruchomił n8n jako Apache 2 z Commons Clause, ale otrzymał „dużo krytyki” za używanie terminu „open source” w cudzysłowie.

„Prezydent OSI skontaktował się ze mną, próbowaliśmy znaleźć tam rozwiązanie. Nie wyszło tak dobrze, jak miałem nadzieję, ale było całkiem miło.”

Przełom nastąpił podczas spotkania w San Francisco: „Spotkałem się pewnego dnia z drugim contributorem, gdy byłem w San Francisco w barze i rozmawialiśmy o tym. Następnie stworzyliśmy tekst na stronę internetową i uruchomiliśmy to.”

Założenia fair code

Model pozwala na:

Darmowe użytkowanie przez wszystkich
Pełny dostęp do kodu
Zakaz komercjalizacji przez strony trzecie
Umowy revenue share z firmami chcącymi integrować

„Mamy miłą sytuację win-win. Nie mają żadnego ryzyka. Jeśli nie zarabiają pieniędzy, nie płacą nic. Jeśli rosną, płacą nam naszą sprawiedliwą część.”

Obecnie n8n używa Apache 2 z Commons Clause, ale pracuje nad własną licencją opartą na Elasticsearch Community License 2.0.

Strategia rozwoju społeczności

Adopcja jako North Star

„Adopcja jest naszą gwiazdą przewodnią. Obecnie cloud revenue nie jest dla nas tak ważne. Najważniejsze jest, żeby ludzie zaczęli nas używać i żebyśmy ulepszali produkt.”

Oberhauser wyjaśnia: „Jeśli próbujesz zarabiać zbyt dużo zbyt szybko, może koncentrujesz się na złych rzeczach. Najważniejsze to mieć świetny produkt, a z czasem możesz na nim zarabiać. To samo z wszystkim – znajdziesz VC z świetnym produktem, nie tworząc pitch decki.”

Metryki społeczności – jakość nad ilością

N8n śledzi wzrost przez codziennie uruchamiany workflow zbierający dane z GitHub, Twitter, LinkedIn, forum. Docker pulls okazały się problematyczne: „Mamy dni z 20-50 tysięcy pullów, inne dni pół miliona. To super zmienne, więc nic nie znaczy.”

Lepsze metryki to te, które ludzie mogą wykonać tylko raz: GitHub stars, followers. „Wciąż bardzo złe metryki, ale przynajmniej są bardziej znaczące.”

Najważniejsze są PR-y i issues: „Im więcej ludzi używa produktu, tym więcej problemów znajdą. Jeśli ktoś ma problem na GitHub, najpierw musi używać produktu, potem problem musi być wystarczająco duży, żeby zainwestował czas w stworzenie tego GitHub issue.”

Zespół używa również Orbit Love, które „pobiera informacje z wielu różnych źródeł, GitHub, Twitter i tak dalej, i daje lepsze zrozumienie faktycznego rozmiaru społeczności, bo łączy ludzi.”

Community-to-employee pathway

N8n ma inspirujące przykłady ewolucji contributors:

Ricardo – jeden z bardzo wczesnych contributors:

„Pracował jak pełny etat dla n8n za darmo przez około pięć miesięcy”
„Stworzył około 50 node’ów za darmo”
„Po prostu dlatego, że tak bardzo lubił projekt, dopóki nie miałem pieniędzy, żeby go zatrudnić”
„Teraz jest oczywiście z n8n”

John – członek społeczności:

„Niesamowity, odpowiada na wszystkie pytania super szybko”
„Mamy też nadzieję zatrudnić go wkrótce”

Kanały komunikacji

Obecne kanały: spotkania społeczności co dwa miesiące, Discord i Discourse, Twitter, LinkedIn. „Nie robiliśmy dużo z zewnętrznymi eventami, sponsoringami – to może ewoluować z czasem.”

Oberhauser ostrzega przed real-time komunikacją: „Każdemu mówię: proszę, nie dodawajcie żadnych kanałów komunikacji w czasie rzeczywistym, bo to taki drain czasowy. Nigdy nie zdążysz nic zrobić, bo odpowiadasz na to samo pytanie milion razy.”

Telemetria – późne, ale transparentne wprowadzenie

„Nie robiliśmy tego przez bardzo, bardzo długi czas. Właśnie wprowadziliśmy to około miesiąca temu.” Oberhauser „zawsze chciał tego unikać przez długi czas, szczególnie dlatego, że to naprawdę trudna sprawa.”

Lekcje z innych projektów

„Rozmawiałem z GitLab – mieli dużo backlashu, bo myślę, że nie było tak świetnie. Myślę, że też używali zewnętrznego vendora. Rozmawiałem z innymi projektami open source – po prostu mieli to od początku, nie można tego deaktywować i ludzie w ogóle nie mają problemu.”

Implementacja

N8n podeszło transparentnie:

„Komunikowaliśmy bardzo dobrze”
„Poprosiliśmy o feedback od społeczności”
„Powiedzieliśmy bardzo jasno, co śledzimy”
„Dodaliśmy opcję, że każdy może to bardzo łatwo deaktywować”

Tech stack: „Przechowujemy wszystko w postgres i używamy RudderStack w backendzie, a także front end SDK.”

System anonimizacji: „Gdy uruchamiasz n8n po raz pierwszy, tworzy rodzaj hasła używanego do szyfrowania credentials i hashujemy część tego hasła, żeby stworzyć unikalny ID dla każdego użytkownika. Wiemy, że ktoś ma 10 wykonań lub milion wykonań, ale nie wiemy kim ta osoba jest.”

Równowaga między CEO a maintainer

„Nie programuję już dużo i jest… Na szczęście mamy teraz więcej developerów, którzy wykonują tę pracę.” Oberhauser znajduje czas głównie „w samolocie, w aucie, w pociągu” gdy nie ma dostępu do internetu.

Obecne obowiązki maintainera:

„Wciąż nie robię już review kodu – ktoś inny przegląda kod, ja wciąż mergeuję”
„Robię pobieżny przegląd, sprawdzam czy wygląda dobrze”
„Jeśli są otwarte PR-y, które wyglądają wystarczająco prosto, normalnie próbuję je zmergować”
„Normalnie po prostu patrzę na nie, żeby upewnić się, że nie zostają zablokowane zbyt długo”

„Dziś chciałem wypuścić nową wersję. Nie jestem pewien, czy uda mi się to zrobić, ale tak to generalnie działa. To już nie moja praca programować.”

Oberhauser ma świadomość ewolucji: „Z czasem, gdy więcej ludzi dołącza do zespołu i więcej kodu zostaje napisane, oczywiście mam trudniejszy czas. Na początku oczywiście pisałem wszystko sam, a teraz więcej kodu zostaje zastąpione.”

Praktyczne wyzwania projektów open source

Design i UX z ograniczonym budżetem

Oberhauser wiedział, że design ma znaczenie: „Jeśli masz produkt, który wygląda niesamowicie, ale jest całkowicie kiepski w środku, ludzie zaczną go używać. Jeśli masz najlepszy produkt, ale wygląda bardzo źle, ludzie nigdy nie zaczną go w ogóle używać.”

Przed launchem „dostałem design na Fiverr. Myślę, że zapłaciłem 250 za cały design.” Logo kosztowało 75$. „Nie kosztuje to dużo pieniędzy. Nie miałem wtedy dużo pieniędzy, wciąż było ciężko. Ale myślałem: jeśli chcesz zbudować coś poważnie, przynajmniej zainwestuj trochę pieniędzy.”

Zarządzanie contribution’ami

„Większość PR-ów, które dostajemy, dotyczy node’ów. Integracji, co ma sens.” To pozytywne, bo „nie chcesz, żeby ktoś przepisał cały core, zainwestował dużo czasu, a potem musisz powiedzieć: przepraszam, to nie pasuje do produktu.”

Dla większych contribution’ów: „Normalnie prosimy: czy możesz się z nami skontaktować najpierw, żebyśmy upewnili się… Powiedz nam, co chcesz zrobić. Sprawdzimy, czy to ma sens, czy chcemy iść w tym kierunku i jak chcemy to zaimplementować.”

Fundraising bez pitch decków

„Nigdy nie musiałem tworzyć pitch decka. To totalna strata czasu. Jeśli masz dobry produkt, którego ludzie używają, to znacznie lepsze niż marnowanie godzin, właściwie dni i tygodni na tworzenie ładnego pitch decka i otrzymywanie feedback’u.”

Po Product Hunt i Hacker News „inwestorzy normalnie się kontaktują” gdy widzą produkt, który im się podoba i który zyskuje dużo zainteresowania.

Timeline fundraisingu: „Termsheet podpisaliśmy znacznie wcześniej. Były problemy IP, bo miałem to w prywatnej firmie i musiałem to transferować.” Pierwszy team member zaczął oficjalnie w kwietniu 2020.

Work-life balance przy budowaniu projektu

Strategia berlińska

Oberhauser miał żonę i dwoje dzieci: „Mieszkałem w Berlinie, gdzie koszty życia są wciąż dość rozsądne.” To umożliwiło strategię part-time.

„Pracowałem 2-3 dni tygodniowo dla różnych startupów. Normalnie 10 godzin dziennie, żeby mieć przynajmniej 30 godzin tygodniowo, co pozwalało mi zarabiać wystarczająco pieniędzy, żeby móc jeść i gdzieś spać, a potem resztę czasu mogłem zainwestować w swoje projekty.”

Ta strategia trwała około 3 lat. „Nie byliśmy bogaci – na pewno nie mieliśmy najbogatszego życia i nie mogliśmy robić wielu rzeczy, żadnych fancy kolacji. Ale jeśli to jest to, na czym ci zależy, znajdziesz pracę 3-dniową.”

Pierwsze zatrudnienia – strategia poza inżynierią

Pierwszy oficjalny team member oraz jeszcze dwie osoby zaczęły w kwietniu 2020, ale żadna nie była inżynierem:

Head of DevRel – „pracował oczywiście szczególnie nad dokumentacją”
Head of Design – „robił design, ale dużo pracy channel’owej także”
Head of Operations – „super ważna osoba, którą radzę każdemu non-technical founderowi zatrudnić”

„Ona zajmuje się wszystkim, co prawdopodobnie zapomniałbym i robiłbym źle. Myślę, że dostałem bardzo złe doświadczenie onboardingu dla pierwszych pracowników. Ona po prostu upewnia się, że wszyscy są zaopiekowani i tworzy odpowiednie job posty.”

Rady dla nowych maintainerów

Kiedy publikować projekt

„Na pewno radzę wypuszczać wcześniej. N8n było bardzo niedoskonałe. Prawdopodobnie mogłem też uruchomić znacznie wcześniej. Było dużo funkcji, które wciąż chciałem dodać jako super istotne.”

Wiele z tych funkcji „wciąż nie jest wydanych teraz, a niewiele osób ich brakuje. Bardzo często wkładasz dużo pracy w coś, na czym nikomu nie zależy.”

Przed publikacją produkt „oczywiście nie powinien być super buggy, żeby ludzie wciąż czuli, że mogą go używać.” Oberhauser radzi też inwestycję w UI „żeby wyglądało jak profesjonalny projekt.”

Persystencja w promocji

„Product Hunt i Hacker News – czasami musisz postować kilka razy, więc ktoś faktycznie to polubi. Całkowicie w porządku jest postowanie 3-4 razy, a za czwartym razem może nastąpić przełom. W najgorszym przypadku nikt tego nie widzi, więc nikt nie będzie narzekać.”

Wybór projektu z wielu pomysłów

Dla osoby z „100 pomysłów na projekty”: „Mam nadzieję, że wciąż jest jeden, na którym ci zależy bardziej niż na innych. Prawdopodobnie bym nad tym pracował.”

Kryteria wyboru:

Problem, który sam doświadczasz („możesz iterować znacznie szybciej”)
Weryfikacja z innymi ludźmi
Koncentracja na rozwiązywaniu rzeczywistych problemów, nie rzeczach które „brzmią fajnie, ale to nie jest faktyczny problem”

Checklista: przygotowanie projektu do publikacji (na podstawie rad Jana)

Design i podstawy:

Zaprojektowanie profesjonalnego logo (~75$)
Stworzenie spójnego UI (~250$)
Sprawdzenie, czy produkt nie jest „super buggy”
Przygotowanie podstawowej dokumentacji

Platformy launch’u:

Przygotowanie do publikacji na Product Hunt
Planowanie posta na Hacker News (bądź gotowy na kilka prób)
Publikacja na Alternative.to
Uruchomienie forum lub platformy wsparcia
Unikanie kanałów real-time komunikacji

Checklista: wprowadzanie telemetrii transparentnie (na podstawie doświadczeń n8n)

Komunikacja ze społecznością:

Wyjaśnienie powodów wprowadzenia telemetrii
Poproszenie o feedback przed implementacją
Szczegółowe opisanie śledzonej zawartości
Dodanie łatwej opcji wyłączenia

Implementacja techniczna:

Zaprojektowanie systemu anonimizacji
Użycie sprawdzonych narzędzi (Postgres + RudderStack)
Testowanie z zachowaniem prywatności

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Maintainer Spotlight- Jan Oberhauser, Founder/CEO – n8n.io

Tag: Maintainer

Od filmów do open source: historia twórcy n8n #EN112