Przez ponad pół roku pracowałem przy Apache Airflow, dużym oprogramowaniu Open Source, które ma ponad 14 tysięcy gwiazdek na Githubie!
W tym odcinku opowiadam o tym, jakie są role w Open Source oraz w czym taki projekt jest podobny do typowego projektu dla klienta.

Kto jest kim?

Na początek mały słownik pojęć związanych z rolami w OSS (Open Source Software – będę używał zamiennie z „Open Source”):

• kontrybutor – jest to każdy, kto przyczynił się do jakiejkolwiek zmiany w kodzie projektu.
• committer – jeśli jesteśmy aktywnym kontrybutorem, to po pewnym czasie możemy zostać zaproszeni do bycia committerem. Jest to osoba, która może akceptować bądź odrzucać zmiany oraz aktywnie uczestniczy w życiu projektu na liście mailowej czy w innych kanałach komunikacyjnych.
• PMC (Project Management Committee) – najbardziej aktywni committerzy mogą zostać członkami PMC i wyznaczać główne kierunki rozwoju projektu oraz brać na siebie odpowiedzialność za kolejne wydania (“releasy”).

Podobieństwa

Zacznijmy od tego, jakie są podobieństwa między pracą w Open Source a typowym, firmowym projektem realizowanym dla klienta.

1. Git jako kontrola wersji

Tak jak w większości projektów programistycznych obecnie, w OSS najczęściej do kontroli wersji używa się gita.

W przypadku projektów OSS kod przeważnie hostowany jest na Githubie. Był on chyba pierwszym dużym, publicznym serwisem umożliwiającym współpracę przy projektach trzymanych w gicie.
Jest dobrze przystosowany do otwartoźródłowych projektów z możliwością łatwego forkowania i modelem Pull Requestów.

W firmowych projektach stosowane są różne rozwiązania, takie jak Gitlab czy Bitbucket, ale Github, najczęściej w wersji Enterprise, też jest bardzo popularny.

2. Prowadzenie backlogu i listy bugów

Każdy szanujący się projekt ma backlog zadań do wykonania i błędów do naprawienia. Nie inaczej jest w przypadku Open Source’a.

Tam ten backlog jest szczególnie potrzebny dlatego, że współpracuje się w gronie osób, które są zdalnie i z którymi ciężko jest „zagadać” i wyjaśnić różne wątpliwości. Można oczywiście napisać na liście mailowej czy na Slacku ale trzeba liczyć się z tym, że nasz rozmówca z San Francisco właśnie smacznie śpi i odpisze nam najwcześniej za kilka godzin.
Kto w ogóle wymyślił strefy czasowe?!

Dlatego taski do zrobienia muszą być bardzo dobrze opisane, nawet lepiej niż w zwykłym projekcie.

W OSS często funkcjonują szablony takich ticketów, np. gdy zgłaszamy błąd, jesteśmy proszeni o opis kontekstu, w jakim on wystąpił, idealnie jakiś zrzut ekranu, dokładne kroki jak ten błąd odtworzyć u siebie itd. Wszystko po to, by druga osoba mogła podjąć to zadanie bez dodatkowego dopytywania.

3. Kod nie zawsze najlepszej jakości

Panuje takie przekonanie, że jak kod jest publiczny, open-source, i każdy może do niego zajrzeć i go ocenić, to nie ma prawa być tam bubli bo zawsze ktoś je wyłapie.

Prawda jest jednak taka, że, szczególnie w dużych projektach pokroju Apache Airflow, tego kodu powstaje tyle, że nie ma opcji żeby każdy commit był wycyzelowany i pozbawiony błędów czy „nieczystego” kodu.

Committerzy nie mają najczęściej mocy przerobowych, żeby wytykać w review każde najmniejsze problemy. Robią to często „po godzinach” w swoim wolnym czasie i skupiają się zazwyczaj na dużych problemach, a na mniejsze przymykają oko.

Jest też ryzyko, że kontrybutor, po wytknięciu mu dużej ilości błędów, z których niektóre nie są wielkiej wagi, zniechęci się i w ogóle nie dokończy swojego Pull Requesta. A tego w Open Source chcemy bardzo uniknąć.

4. Niespójny kod

I tu i tam bardzo często kod nie jest spójny w różnych miejscach projektu. Tak jak w wieloletnich zwykłych projektach jest rotacja ludzi i każdy pisze trochę „po swojemu”, tak samo jest w OSS, ale na jeszcze większą skalę.

Nie dość, że projekt trwa X czasu, to pracuje przy nim jeszcze często masa ludzi. Jak dodamy do tego punkt powyżej o jakości to okazuje się, że kod OSS w różnych modułach np. w różny sposób realizuje te same funkcje, korzysta z kilku bibliotek robiących to samo itd.

Zazwyczaj brakuje czasu i mocy przerobowych na refactoring tego, a nawet jeśli to się uda, to w dużych projektach kod przybywa często w takim tempie, że potem merge’owanie takich refaktoringów to niemały ból głowy.

Podsumowanie

To tyle na ten moment, dzięki za dotrwanie do końca! Mam nadzieję, że znalazłeś tu trochę wartości dla siebie 🙂

W następnym wpisie będzie jeszcze ciekawiej, bo powiem o różnicach między OSS a projektami firmowymi. A do tego podam parę wskazówek, jak można żyć z pracy przy Open Source! How cool is that?!

Jeśli nie chcesz przegapić kolejnego odcinka to zapraszam Cię do subskrybowania mojego kanału na YouTube oraz do polubienia strony na Facebooku!

Do zobaczenia wkrótce, cześć!