Cześć!

Jestem lekko zdenerwowany, czy też podekscytowany bo to mój pierwszy newsletter - ever. Cieszę się, że mogę go napisać właśnie do Ciebie. W końcu pisanie w eter nie ma sensu. Kończąc wstęp chciałem jeszcze dodać, że plan na ten newsletter jest, żeby:

• wychodził raz w tygodniu (żeby Cię nie zamęczyć),
• poruszać tematy związane z praktykami programistycznymi (niekoniecznie najlepszymi),
• no i żeby nie był to monolog, a raczej dialog. Liczę na Twoje komentarze, pytania,
• treść była unikalna, czyli będę się starał nie powielać tego na blogu czy innym medium (chociaż nawiązania na pewno jakieś się znajdą).

No ale do meritum. Open Source!

Jak pewnie wiesz działam trochę w tym temacie. Od jakiegoś roku jestem “maintainerem” całkiem dojrzałej i względnie popularnej biblioteki .NET - Marten. Pozwala ona zamienić Postgres w bazę dokumentową.

Jak do tego doszło? Mógłbym powiedzieć najprościej: normalnie. Przeszedłem drogę od użytkownika, przez kontrybutora, aż do maintainera. A jak konkretnie?

1. Użytkownik - 3 lata temu zacząłem pracować nad modułem finansowym, kolega powiedział, żebym spróbował zrobić go w Event Sourcing z racji, że ważna jest audytowalność, dokładna analiza itd. Zaproponował użycie Martena. Pierwsze zderzenie było trudne. Miałem podstawy teoretyczne, ale teoria, teorią, praktyka swoje. Sam Marten nie miał wtedy jeszcze wybitnej dokumentacji (teraz uważam, że ma bardzo przyzwoitą). To co mnie motywowało, żeby dać szansę tej bibliotece to osoba Jeremy’ego D. Millera - weterana Open Source - twórcy m.in. Structure Map.
2. Pierwszy PR - pracując z Martenem, pewnych rzeczy zaczęło mi brakować, więc stwierdziłem, “czemu nie - spróbuję! Sam dorzucę zmiany.” - no i wyjechałem z mega grubym PRem na początek https://github.com/JasperFx/marten/pull/841. Nie było to najbardziej rozważne posunięcie. To tak jak wejście z buta do salonu w amerykańskim westernie. Na szczęście nieco się przygotowałem, bo zrobiłem dobry opis PRa, po dłuższej dyskusji, byciu asertywnym udało mi się mieć wmerdżowany PR do projektu Open Source! Jeeej!
3. Kontrybutor - po pierwszym PR już poszło z górki. Dorzucałem kolejne PRy (niekoniecznie takie wielkie, ale zdarzały się i większe). Dołączyłem do kanału Martena na Gitter. Okazało się, że ludzie zadają pytania i mają takie problemy z jakimi sam się ścierałem. Zacząłem podrzucać swoje rozwiązania - pomagać. Wrosłem w tę społeczność. Ta społeczność jest też wg mnie jedną z największych wartości Martena. Ludzie są życzliwi, otwarci i pomocni co jest bardzo ważne.
4. Maintainer - jakieś rok temu Jeremy doszedł do wniosku, że sam nie będzie w stanie wszystkiego samemu ogarniać, widząc też zaangażowanie Babu, Joona-Pekka oraz mnie niżej podpisanego - zaprosił nas do zostania maintainerami Martena. Dla mnie to było wielkie wyróżnienie. Jeeej! Ale też odpowiedzialność. Będąc kontrybutorem sam wybierałem sobie to co dla mnie ciekawe i czym się zajmę. Będąc maintainerem muszę bardziej skupiać się na tym czego potrzebują inni użytkownicy. Czyli jak w każdym projekcie - bugfixing, tłumaczenie, objaśnianie, analiza pull requestów. Trzeba być konsekwentnym i dobrze trzymać balans, żeby się nie zagrzebać.

Jakie mam zatem porady na start pracy z Open Source?

1. Zacznij od czegoś małego. Nie wjeżdżaj z buta jak ja. Ryzykujesz wtedy, że spotkasz się z postawą defensywną u maintainerów lub po prostu nie trafisz w konwencję repozytorium. Dobrze opisz swój PR, nie wrzucaj po prostu samego kodu. Najlepiej to zgłoś issue i dodaj, że chętnie zrobisz PRa i poproś o wskazówki. Maintainerzy naprawdę uwielbiają małe, drobne zmiany, szczególnie do dokumentacji np. takie. Zaczynając w ten sposób możesz nawet zostać kontrybutorem .NET Core. Na większe rzeczy przyjdzie czas. Nie wiesz co dorzucić? Przeszukaj kod frazą “TODO” - to są dobrzy kandydaci do rozpoczęcia. Często też sami maintainerzy wrzucają labelkę “Up for grabs” czy inną wskazującą na coś co może być dobrym startem.
2. Dołącz do społeczności - każda poważna biblioteka ma jakiś swój kanał komunikacji - czy to slack, czy to gitter czy lista mailingowa. Dołącz do niej, sprawdź jak ludzie ze sobą się komunikują, jak się do siebie odnosza, czy to na pewno jest miejsce gdzie chcesz być. Po takim kanale możesz też ocenić czy społeczność żyje, wtedy jest też większa szansa że biblioteka jest utrzymywana.
3. Pomagaj - Open Source jak nazwa wskazuje polega na O T W A R T O Ś C I. Pytaj, radź się, ale też pomagaj. Nawet jeśli nie uważasz się za eksperta to Twoja porada może okazać się dla kogoś cenna. Nie bój się, że ktoś Ci powie, że się nie znasz. Nawet jeśli Twoja porada nie będzie optymalna i ktoś ją skrytykuje to przynajmniej dowiesz się czegoś nowego. Skonfrontujesz swoje myslenie.
4. Nie bądź roszczeniowy - pamiętaj, że po drugiej stronie jest człowiek, który robi to zwykle ze swojej pasji i kosztem innych rzeczy. Widzisz, że czegoś brakuje? Dorzuć, zaproponuj.

Chcesz utworzyć swoją bibliotekę Open Source?

1. Zrób coś co ma wartość dla Ciebie - nie wymyślaj jakiegoś Wunderwaffe. Przemyśl jaki Ty masz problem i go rozwiąż.
2. Dowoź etapami - nie rozgrzebuj wielkiej funkcjonalności na branchu, ryzykujesz, że nigdy tego nie skończysz. Podziel to na mniejsze fragmenty i dowoź. Nie ma nic bardziej motywującego niż skończenie czegoś.
3. Zadbaj o dokumentację - zapewniam Cię, że bez tego nikt Twojej bibliteki nie będzie używał. To wcale nie jest takie trudne - np. Github daje możliwość automatycznego generowania dokumentacji na podstawie plików md przy pomocy Jekyll. Zrób co najmniej porządne README.
4. Utwórz podstawowy flow CI/CD - jest bardzo dużo narzędzi, które dają możliwość ekspresowego skonfigurowania darmowego procesu CI dla projektów Open Source: Azure DevOps, AppVeyor, Github Actions, Travis, itd. Nie rób nie wiadomo jak skomplikowanego od razu, ale niech chociaż upewni się, że projekt się buduje i testy są odpalone. To jest bardzo ważne też dla potencjalnych kontrybutorów. Nic tak nie odstręcza jak niebudujący się projekt, albo konieczność zrobienia Mambo Jumbo, żeby zacząć pracę nad kodem.
5. Dbaj o kompatybilność wsteczną - to jeden z ważniejszych elementów tworzenia bibliotek. Stabilność i przewidywalność API jest bardzo ważna. Jeśli co chwilę będziesz wrzucać Breaking Change, to użytkownicy albo nie będą się przenosić do nowszych wersji, albo po prostu zrezygnują. Stosuj zasady Semantic Versioning. Niestety wymaga to jednej rzeczy - myślenia przed implementacją. Tak aby nie wypuszczać niczego co potem będziesz żałować.
6. Less is more - skup się na małych rzeczach, dowieź mniej, ale lepiej. Dotyczy też to detali technicznych - udostępniaj tylko to co chcesz, żeby użytkownicy używali. Jeśli niechcący udostępnisz klasę jako publiczną, to potem jak będziesz chciał ją wywalić możesz się zdziwić jak dużo użytkowników jej używa i jak dziwne rzeczy z nią robią.

No i już na koniec 2 pytania które już słyszałem kilka razy:

• “Ile dostajesz za pracę nad Martenem/Open Source?” - Pieniędzy? Okrągłe zero. Niedawno dostałem od JetBrains licencję na ich produkty na swoją działalność Open Source - i to była jedyna materialna korzyść jaką z tego odniosłem. Niestety brutalna rzeczywistość pokazuje, że jest to filantropia. Robisz coś za darmo, a inni tego używają, często i zarabiają. Temat “Open Source Sustainability” to szeroki temat, nawet na osobny mail lub wpis na blogu (jeśli chcesz, żebym o tym napisał daj znać!). Póki co zerknij np. na kontrowersje z licencją Redis, dyskusję o tym jak twórca jednego z głównych pakietów npm zaczął prosić o wsparcie. Pojawiają się takie inicjatywy jak Open Collective, Github Sponsors, Patreon, niektóre projekty są sponsorowane, ale póki co model finansowy Open Source nie jest sprawiedliwy. Czy chciałbym zarabiać na swojej pracy Open Source? Oczywiście. Czy zarabiam? Nie - zero złotych, zero groszy. Czy mi to przeszkadza? Nie, to moja pasja, cieszę się, że mogę pomagać, ale jednak fajnie by było to uczynić trochę bardziej zrównoważonym. Dlatego zanim zaczniesz działać Open Source - upewnij się, że to Ci odpowiada. Zachęcam do lektury świetnego wpisu temat tego, że Gwiazdki na Github Ci nie zapłacą: link.
• “Czy spotykasz się z hejtem?” - ja osobiście nie. Oczywiście zdarzają się osoby roszczeniowe, ale tak jak wspominałem - społeczność Martena jest bardzo w porządku, być może to specyfika samej biblioteki, pewnie też to, że nie jest to biblioteka z tysiącami/milionami użytkowników, ale też myślę tez i ciężkiej pracy, żeby taka była.Na pewno jest w tym światku sporo hejtu, zdarzają się sytuacje niezdrowe i “dramy” - jak np. ostatnie wydarzenie w społeczności React: zerknij tutaj. Mnie osobiście póki co częściej spotykają takie sytuacje jak ta: link. Wtedy człowiek czuje, że warto. Chce się żyć!

Uf! Jeśli jesteś jeszcze ze mną to należy Ci się naklejka “Dzielny czytelnik”! Mam nadzieję, że zaciekawiłem Cię trochę i nie zmarnowałem Twojego czasu. Będę Ci bardzo wdzięczny za informację czy taka formuła Newslettera jest dla Ciebie ciekawa. Jeśli masz propozycje inne - chętnie przyjmę. Pytania - chętnie odpowiem! Odpisuję na każdego maila.

Dziękuję bardzo za lekturę i do napisania!

Pozdrawiam Oskar

p.s. Jak lektura “Faktów i Mitów o Event Sourcing”? Jestem bardzo ciekaw Twoich wrażeń i opinii. p.s.2. Niedługo rusza Hacktoberfest - świetny moment, żeby zacząć przygodę z Open Source - chętnie Ci w tym pomogę. Daj znać!