Nie musisz pomagać Elonowi Muskowi w budowie algorytmów pomocnych przy kolonizacji Marsa, aby kontrybuować w Open Source

Forkuj, merdżuj, pull requestuj. Daj coś z siebie dla innych (i nie tylko...)

13 October, 2017

O tym jak działanie w społecznościach i ogólnie rynku wolnego oprogramowania wpłynęło i zmieniło moje życie mógłbym rozwodzić się godzinami. Przygoda, która trwa w moim życiu już któryś rok, dostała ostatnio jeszcze dodatkowego kopniaka motywacyjnego za zasługą prezentacji Adama Sitnika wygłoszonej na Programistoku, o którym pisałem w swoim poprzednim wpisie. To co jednak zmotywowało mnie do popełnienia tego wpisu to rozmowy w kuluarach z osobami, które poczuły się zainspirowane do działania, będąc jednocześnie pod wielkim wrażeniem tego jakie możliwości płyną z kontrybuowania w projektach o otwartym kodzie źródłowym. Jak to zatem wygląda w praktyce? Gdzie są $$$, a gdzie krew, pot i wdrożenie?

Zacznijmy od końca...

Chciałbym jednak zacząć od czegoś co może Wam wszystkim choć trochę pomóc się zmotywować do działania. Mamy październik. W Niemczech nasi sąsiedzi świętują Octoberfest, a developerska brać wykreowała Hacktoberfest!

hacktoberfest-2017-social-card-894a0558dba205f7142f3130c06823d72427a9d751d0f8c7db8a0079397178aa.jpg

Firma DigitalOcean wyszła z inicjatywą wsparcia projektów open source i we współpracy z Githubem oferuje za spełnienie kilku warunków - pamiątkowy t-shirt z akcji. Darmo dają? Biere! :)

O co chodzi?

  • Hacktoberfest jest otwarty dla każdego na całym świecie!
  • Pull requesty mogą być wykonane do dowolnego repozytorium/projektu hostowanego na Githubie
  • Zarejestrować do akcji można się w ciągu całego miesiąca października

Zasady: Aby zgarnąć t-shirt trzeba wykonać 4 pull requesty pomiędzy 1-31 października (w dowolnej strefie czasowej). Jak wyżej wspomniałem, mogą być one wykonane do dowolnego repozytorium publicznego hostowanego na Githubie. Oczywiście musisz być autorem tego co dodajesz do projektu. Tyle.

Wydawałoby się zupełnie niczym dla osoby, która aktywnie współpracuje przy projektach open source, ale podnieście ręce (albo zostawcie komentarz!) Ci, co już przy takich projektach pracowaliście??? Podejrzewam, że pomimo wszystkiego, jest Was nadal mniejszość. Pytanie dlaczego?

Bo: "Nie mam czasu na pracę po pracy"

To często powielany i dość solidny argument. Wiadomo, że czasu od chińczyków kupić sobie nie jesteśmy w stanie, a doba każdego z nas ma tyle samo - TYLKO 24 godziny. Jak je spożytkujemy to kwestia indywidualna i nie każdy ma chęć, energię i możliwości, by po pracy zajmować się również "pracą". To w pełni zrozumiałe.

Jakie jest tego rozwiązanie? Sprawić, aby stało się to elementem naszej codziennej, "normalnej" pracy. Czy to możliwe? Pewnie!

Na pewno na co dzień pracujecie z systemami, frameworkami i narzędziami, które posiadają swoje open source'owe odpowiedniki. A może już wykorzystujecie jakieś narzędzia z otwartym źródłem, może nawet o tym nie wiedząc?

os_big_data_open_source_tools-v21.jpg open-source-icons4638740636_a12cdcfd86_z.jpg

Czy któryś z powyższych logotypów jest Wam znajomy i wykorzystywany w Waszej pracy?

O ile narzuceniem odgórnym projektu(ów) nie jest wydanie tony pieniędzy na licencje, to śmiało z tego typu rozwiązań skorzystać można. A jak już do korzystania dochodzi to... pojawiają się problemy :) Niestety, to nieodłączne, a wiadomo także, że nikomu nie udało się jeszcze zbudować softu bez bugów, idealnie realizującego zadania, do których został stworzony i po prostu pasującego wszystkim we wszystkim.

Tutaj zatem pojawia się furtka na kontrubucje wszelkiego rodzaju. O ich różnych wymiarach jeszcze opowiemy sobie trochę później.

Innym rozwiązaniem jest po prostu zaliczenie tego do czasu nauki i rozwoju swoich umiejętności. Wielu z moich znajomych programistów utknęło w zespołach, w których nie są już w stanie się rozwijać. Porzekadło mówiące o tym, że jeśli jesteśmy najmądrzejsi w pokoju to pora zmienić pokój jest tutaj jak najbardziej na miejscu. A od kogo się uczyć jeśli nie od najlepszych w branży? To wszystko jest na wyciągnięcie ręki, a Wasz kod może być poddany ocenie i rozwinięty przez osoby, które do tej pory podziwialiście na YouTube czy konferencjach branżowych. Just do IT!

Ostatnie z rozwiązań, chyba najbardziej drastyczne to po prostu zmiana pracy / środowiska. Skoro czujecie, że chcielibyście się rozwijać, uczyć i "oddawać" trochę tej wiedzy dalej, a nie macie do tego możliwości to CO WY DO CHOLERY DALEJ ROBICIE W TYM SAMYM MIEJSCU?!?!?!?! :) O zmianach pisałem na samym początku mojego bloga - tutaj. Nie należy ich się bać i są one zawsze na lepsze. Gwarantuję, iż jedynie żałować będziecie czasu, który zajęło Wam podjęcie decyzji, na pewno nie samego faktu jej podjęcia. A, że branżę mamy taką, a nie inną... problemu z pracą raczej mieć nie będziecie.

Osobiście przez całe swoje developerskie życie czułem chęć dzielenia się swoją wiedzą z innymi. Od zawsze jednak w liście priorytetów lądowało to jednak dalej niż wszelkie inne sprawy, które pozwalały mieć z czego opłacić rachunki i inne takie tam.. Próbując czasem robić więcej, zarzynałem się często pracując po 16h lub więcej, zawalając przy tym jakościowo i terminowo sprawy ważne od tychże spraw fajniejszych z perspektywy developera. Szukałem więc cały czas złotego środka i takie opcje jak WOW School - w którym z początku realizowałem się jako IT Belfer dla najmłodszych, czy współpraca z The Cogworks - gdzie mam okazję prowadzić szkolenia i kontrybuować do Umbraco i tworzyć dodatki, które udostępniamy wszystkim jego użytkownikom, są takim 2w1 w rezultacie. Bo zarówno stanowią moją pracę, przy tym dając mi jeszcze sporo zabawy i wolnej amerykanki wokół tego co, z kim, gdzie i jak robię. Polecam ten stan.

Bo: "To trudne" a.k.a. jestem za cienki w uszach

Drugim najczęściej pojawiającym się w dyskusjach argumentem jest brak wystarczających umiejętności, który często idzie również z brakiem wiary w już posiadane skille i możliwości.

Nie musicie pomagać Elonowi Muskowi w budowie algorytmów pomocnych przy kolonizacji Marsa, ani też optymalizować algorytmów niskopoziomowo redukujących czas wykonania kwerend w projektach, aby aktywnie kontrybuować w Open Source! A wielu z Was właśnie tak to sobie wyobraża w zestawieniu z "idolami" czy "guru", którzy prowadzą projekty, w których coś może byśmy dodali / zmienili. Żeby Wam bardziej uświadomić jakie błahe kontrybucje mam na swoim koncie, to w ostatnim czasie wyłapałem brak query stringów w module do porównywania wersji Umbraco dostępnym pod adresem: https://our.umbraco.org/contribute/releases/compare. Zwyczajnie w świecie potrzebowałem udostępnić naszemu PM link, w którym widoczne jest czarno na białym co zmieniło się od wersji 7.5.x do najnowszej wersji 7.7.x. Coś nie banglało. Pobrałem kod źródłowy, uruchomiłem u siebie na maszynie, pogrzebałem w widokach i voila - okazało się, że formularz tam obecny miał metodę POST jako action, zamiast GET - co ustawiłoby parametry jako wartości query stringów w adresie i tym samym zaczytało przy udostępnieniu linka dalej.

Mój PR sprowadził się więc do zmiany jednego słowa w akcji formularza i tę żenującą akcję możecie zobaczyć tutaj: https://github.com/umbraco/OurUmbraco/pull/132. Jak widać nie zrobiłem zbyt wiele, a tym samym odblokowałem ten ficzer wszystkim, którzy będą w tej samej potrzebie co ja. Kod został sprawdzony, zmerge'owany i uruchomiony na właściwym, produkcyjnym forum społeczności Umbraco. #dumny!

Kontrybuować możemy na wiele sposobów np:

  • Zgłaszając błędy i pomysły na rozszerzenie funkcjonalności

    Tak, to najprostsza chyba forma kontrybucji, która jest równie ważna jak samo poprawianie istniejących błędów. Nie uwierzycie jak wiele umyka osobom, które dzień w dzień siedzą nad tym samym projektem. Obserwuję to od lat pracując z Umbraco. Jeśli napotkacie na jakiś problem, albo coś nie działa tak jak działać powinno i ten problem, wraz ze scenariuszem jego odtworzenia prześlecie do twórców programu - możecie już nazywać siebie kontrybutorami, bo zrobiliście kawał brudnej roboty, która przyczyni się - prędzej czy później - do wyeliminowania tego problemu.

  • Tworząc lub aktualizując dokumentację projektu

    To kolejna bardzo niedoceniania i często nielubiana przez developerów rola w projektach informatycznych. Nie każdy przecież lubi dokumentować cokolwiek, cykać screeny, nagrywać screencasty i tłumaczyć nowym użytkownikom jak małym dzieciom jak się mają z czymś obchodzić. A inni (myself included!) to bardzo lubią. Myśląc o tym, pomyśl o sytuacjach, które w Tobie powodowały uczucia tj. "dlaczego nie ma tego w dokumentacji!?!?!" lub "tam było napisane, żeby wywołać x() a nie y() - straciłem na to tyle i tyle..." i wówczas postaraj się pomóc innym np. naprawiając i aktualizując stare zapisy w dokumentacji, tudzież opisując nowe. To jest na wagę złota!
  • Dodając tłumaczenia językowe

    Tak, tak, tak. Bo z reguły nawet w UK, gdzie Polski jest drugim pod względem popularności językiem mowy, nie wszyscy go znają ;) Śmiem nawet stwierdzić, że Polacy często są jednak niszową populacją w globalnych projektach IT. A często twórcy chcieliby swój produkt również dopasować do rynku w naszym kraju i zdobyć nowe źródło klientów. Możemy im w tym pomóc. To, co często sprowadza się do tłumaczeń wyrażeń w plikach XML / JSON / etc. pozwoli nam stać się częścią projektu i osobą, która w nie mniejszym stopniu niż najbardziej aktywni koderzy, przyczynia się do rozwoju produktu. 
  • Kodując!

    Tutaj to już Kapitan Oczywisty bierze górę, ale tak - kodując też możemy kontrubuować :) Słyszałem o wielu przypadkach, w których ktoś uczył się nowej technologii w ten sposób, ew. zgłębiał tajniki konkretnych narzędzi. Nie jest to zatem zawsze pomoc w rejonach, które są nam dobrze znane i lubiane. Można więc śmiało upiec dwie pieczenie na jednym ogniu, do czego serdecznie zachęcam (choć sam jeszcze z tej opcji nie korzystałem, za skromny i za cienki w uszach chyba jeszcze jestem ;))

A czy samo "kontrybuowanie" jest trudne? Podejrzewam, że większość z Was korzysta z gita i standardowy git-flow zna / praktykuje. Z reguły sprowadza się to zawsze do tego samego i można to opisać w kilku krokach.

  1. Robimy "Fork" repozytorium głównego do swojego konta.
  2. Wykonujemy operacje "Clone" celem wejścia w posiadanie kodu, na którym będziemy pracować.
  3. Budujemy, pracujemy nad projektem wykorzystując wiedzę z dokumentacji i instrukcji dot. kontrybucji.
  4. Commitujemy i Pushujemy kod zgodnie z wymaganiami i zasadami.
  5. Tworzymy Pull Request zmian do brancha, do którego chcielibyśmy włączyć nasze zmiany.
  6. Otwieramy piwo i popcorn i czekamy na Code Review oraz Merge / Decline naszego PR.

Na przykładzie z mojego podwórka - Umbraco zrobiło nawet graficzny poradnik "jak zacząć", który możecie podejrzeć tutaj: https://our.umbraco.org/contribute/quick-start-guide/.

Jeśli nadal jest to dla Was czarna magia to w dzisiejszych czasach nie jest to już żadne rocket science, a klienci nawet z GUI wyręczają nasze głowy z pamiętania złożonych komend i instrukcji do wykonywania nawet bardzo złożonych operacji na repozytoriach kodu. Osobiście korzystam na co dzień z GitKraken'a, którego UI mnie po prostu urzekło (inna sprawa, że zmarnowałem na początku kilka godzin szukając jak zrobić tam push na inny branch, a okazało się, że wystarczy drag&drop...).

Image 2017-10-13 at 5.20.34 PM.png

Wszystkie szanujące się repozytoria Open Source dodają również do każdego z nich zestaw instrukcji i wymagań dot. samej jakości tworzonego kodu, wykorzystywanych narzędzi czy też najzwyczajniej wskazówek jak rozpocząć pracę z projektem. Zwykle to wszystko ląduje w magicznym pliku o nazwie CONTRIBUTING.md.

Bo: "Po co?"

"Last, but not least" - jakby to Kayah zaśpiewała: "Po co? Po co? Po co? Po co?".

maxresdefault (1).jpg

Jeden zrezygnuje, bo mu nikt przecież za to nie zapłaci. Drugi, bo jednak będzie wolał spędzić czas, nawet w "pracy", w inny sposób np. na Wykopie czy innym pożeraczu czasu. A jeszcze inny po prostu nie czuje potrzeby i tyle.

Patrząc jednak z perspektywy człowieka, który wsiąkł w Open Source już jakiś czas temu, śmiało mogę stwierdzić, że to zmieniło moje życie i sposób postrzegania programowania, branży i samego "kodu" jako narzędzia w naszych rękach. Zdecydowanie bardziej wyluzowałem odkąd pracuję nad projektami z otwartym źródłem. Mocniej też uwierzyłem w siebie (choć nadal twierdzę, że do pięt nie dorastam większości moich guru i idoli, czy nawet kolegów z pracy). Jednak obserwowanie tego, że nawet ci najlepsi nie są wcale też tacy idealni bardzo buduje. Inna sprawa, że tak samo bardzo uczy: umiejętności twardych, miękkich (np. negocjacji tego kto ma rację w danym PR) czy też zwyczajnie pokory.

Czy są z tego pieniądze - często pytacie. Są. Tylko nikt nikomu po kilku commitach i PR nie wskakuje z przelewem $$$ na konto. Co raz jednak więcej rekruterów i zwyczajnych właścicieli software housów czy agencji patrzy na to co dzieje się na Githubie, wyłapując ciekawe persony i oferując im współpracę. O przypadkach "wsiąknięć" programistów w projekty, w których kontrubuowali wcześniej non-profitowo to już próżno mówić, bo takich przypadków jest wiele.

W każdym razie najważniejszym i głównym argumentem i odpowiedzią zarazem na pytanie z tego paragrafu jest i zawsze będzie: DLA SIEBIE. Dla waszego rozwoju, dla ucieczki z drogi ku wypaleniu zawodowemu i dla lepszej przyszłości i jakości Waszej pracy. Nic tak nie mobilizuje do nauki jak poprawiane i wytykane nam publicznie błędy w tym co tworzymy :)

Zróbcie więc coś zatem dla siebie jak najprędzej, a jak Wam w szafie mało t-shirtów to może tej od DigitalOcean i Githuba będzie dla Was dobrą mobilizacją do rozpoczęcia przygody z OSS.

P.S.

Jeśli poszukiwalibyście kontrybutorów do Waszych projektów to chętnie poświęcę kilka h w miesiącu na współpracę przy jakichś ciekawych projektach. Dajcie znać w komentarzach!