🧩 Open source

Kto tworzy open source i jak się dogadują

Trzydzieści krajów, jeden kod. Mapa commitów z całego świata.

4 min czytania
Kto tworzy open source i jak się dogadują

Kiedyś wysłałem do pewnego projektu małą poprawkę i została przejrzana, przedyskutowana, poprawiona i przyjęta przez trzy osoby, których nigdy nie spotkałem, w trzech krajach, w ciągu dwóch dni, bez ani jednej wideokonferencji, bez kierownika projektu i bez wiedzy kogokolwiek o tym, czym reszta zarabia na życie. Jako ktoś, kto przesiedział bardzo wiele spotkań o koordynowaniu pracy, uznałem to za lekko obraźliwe i niezwykle ciekawe.

Jak projekt z tysiącami współtwórców, bez wspólnego pracodawcy, bez wspólnej strefy czasowej i bez wspólnego języka poza kiepskim angielskim produkuje coś, co działa? Odpowiedzią nie jest entuzjazm. Odpowiedzią jest zestaw mechanizmów i da się je skopiować.

Wszystko jest zapisane, bo nic innego nie przetrwa

Pierwsza i najważniejsza właściwość: dyskusja jest zapisem. Propozycje, zastrzeżenia, uzasadnienia, ostateczna decyzja — wszystko tekstem, wszystko publicznie, wszystko na stałe. Nie notatka spisana potem przez kogoś, kto był w pokoju. Sama rozmowa, tak jak przebiegła.

Wymusza to okoliczność, a nie cnota. Kiedy współtwórcy są rozrzuceni po wszystkich strefach czasowych, dyskusja synchroniczna jest niemożliwa, więc wszystko musi działać przy czytaniu osiem godzin później przez kogoś, kto spał. Ale efekt uboczny jest ogromny: osoba dołączająca za pięć lat może przeczytać, dlaczego podjęto decyzję, łącznie z zastrzeżeniami, które przegrały. W większości firm, w których pracowałem, to uzasadnienie istniało wyłącznie w głowach ludzi, którzy już odeszli.

Małe, przeglądalne kawałki

Wkłady przychodzą jako pojedyncze zmiany, każda robiąca jedną rzecz, każda tłumacząca samą siebie. Nikt nie wysyła sześciu miesięcy pracy w jednej dostawie, bo nikt nie byłby w stanie tego przejrzeć.

To jest mechanizm czyniący zaufanie zbędnym, i tę część uważam za naprawdę sprytną. Opiekun nie musi wiedzieć, czy współtwórca jest kompetentny, uczciwy albo zatrudniony przez konkurencję. Musi umieć przeczytać zmianę. Małą zmianę jedna osoba zrozumie w całości w jeden wieczór; dużej nie zrozumie nikt, i dlatego duże są odrzucane niezależnie od tego, kto je przysłał.

Pod tym wszystkim siedzi narzędzie zbudowane specjalnie do tego problemu: system kontroli wersji pozwalający tysiącom ludzi pracować jednocześnie nad tymi samymi plikami, trzymający każdą wersję i pokazujący dokładnie, kto co zmienił. Napisała je ta sama osoba, która zaczęła kernel, dokładnie z tego powodu, i można argumentować, że to bardziej wpływowy z tych dwóch projektów.

Autorytet zdobywany publicznie

Jest hierarchia i jest ścisła — ktoś decyduje, co wchodzi, a jego decyzja jest ostateczna. Nietypowe jest to, jak dochodzi się do tej pozycji. Nie przez mianowanie, nie przez staż, nie przez pracodawcę. Przez długi, widoczny zapis dobrego osądu w tym samym publicznym archiwum, które czytają wszyscy pozostali.

Praktyczna konsekwencja jest taka, że dobry argument nieznanej osoby może wygrać ze słabym argumentem znanej firmy, bo oba są spisane obok siebie i każdy może je porównać. Widziałem, jak korporacyjną propozycję rozłożył na części ktoś, kto na oko był studentem. Tak to nie wygląda w sali konferencyjnej, gdzie osoba z tytułem zwykle wygrywa z automatu.

Ile to kosztuje, bo nie jest darmowe

Powolność. Przegląd asynchroniczny znaczy, że mała zmiana potrafi zająć dni, a sporna miesiące. Przy czymkolwiek z terminem ten model jest naprawdę gorszy niż cztery osoby w pokoju, a udawanie inaczej byłoby nieuczciwe.

Szorstkość. Przegląd pisemny bez tonu głosu, często od osób piszących w drugim języku, produkuje uwagi czytające się brutalnie. Część z nich jest brutalna. Kilka projektów straciło tak dobrych współtwórców, a te, które świadomie nad tym popracowały, zwykle rosły szybciej, co sugeruje, że szorstkość nigdy nie była źródłem jakości.

Oraz problem jednej osoby, gorszy, niż wygląda. Struktura koncentruje autorytet w małej liczbie opiekunów, a wiele krytycznych komponentów ma dokładnie jednego. To jest kruchość, której ten model nie rozwiązał.

Część, którą ukradłem do własnej pracy

Zapisuj uzasadnienie tam, gdzie znajdzie je następna osoba. Nie dokumentację — uzasadnienie. Dlaczego ten dysk, a nie tamten. Dlaczego backup chodzi o tej godzinie. Dlaczego maszyna tego klienta jest skonfigurowana inaczej.

Zacząłem to robić z powodu tego, jak działają otwarte projekty, a osobą, której to najbardziej pomogło, jestem ja, osiemnaście miesięcy później, patrzący na decyzję, której już nie pamiętam. Jednoosobowa firma ma dokładnie ten sam problem z utratą wiedzy co projekt rozproszony — kolegą, którego nie było w pokoju, jest Twoje przyszłe ja, i ono też nie będzie pamiętać.

Zobacz open source w praktyce.

Na naszym demo działa n8n — ten sam kod, który możesz pobrać i zaudytować — oraz oftionn ai, nasza własna usługa zbudowana na otwartych modelach. Reszta stacku: Nextcloud, Immich, Jellyfin, Stirling PDF i Home Assistant, to ten sam otwarty kod, preinstalowany na sprzęcie, który dostarczamy.