Jakiś tutek OSS

Mirki z #programowanie #informatyka, niektórzy macie wakacje, uczycie się programować. Ktoś może mieć repo na githubie, gitlabie, bitbuckecie, ale wstydzicie się pokazać kod źródłowy albo uważacie, że kod jest marny i nie warto commitować do projektu opensource? No to błąd, przez 2 miesiące w jednym projekcie opensource pracując po 4-5h dziennie nauczycie się znacznie więcej niż przez rok w pracy. Taka prawda, sam tego doświadczyłem jak i moi znajomi którym poleciłem tą metodę.

Od czego zacząć pracę w OSS?

0. Podstawowa znajomość angielskiego by się tylko porozumieć, bardzo często w projektach są Polacy, są developerzy z Hiszpanii, którzy nie znają angielskiego więc piszą po hiszpańsku, potem inny developer tłumaczy w skrócie - to zdarza się.
1. znajdź projekt który Cię interesuje, cokolwiek. Warto używać aplikacji z F-Droida (java) czy na Linux (java, c, c++, wszystkie języki skryptowe, Qt)
2. używasz aplikacji więc widzisz niedociągnięcia i błędy.
3. próbujesz je samodzielnie rozwiązać.
3.5 jak nie dajesz rady to zgłaszasz issue na ich liście zgłoszeń, opisujesz krótko problem i co próbowałeś zrobić i z czym masz problem
4. rozwiązujesz problem i zrobisz im pull/merge requesta
5. czekasz aż zostanie przejrzany i złączony do gałęzi właściciela repozytorium

2.5 jak nie masz takiego projektu to wbijasz na https://openhatch.org/ - jest to społeczność która zajmuje się wyszukiwaniem programistów do projektów opensource o których mogliście nigdy nie słyszeć albo nie wiedzieć że są OSS. Pomagają znaleźć projekt pod kątem:
* złożoność projektu
* język / technologie / użyte biblioteki
* ilość zadań do zrobienia
* trudność zadań do zrobienia
* ilość osób z którymi współpracujesz

Środowisko jest zawsze bardzo miłe i przyjazne, każdy wie, że nikt nie zaczyna z poziomu master tylko uczymy się commitować, kodować, projektować, pisać i komunikować. Każdy popełnia błędy i każdy się uczy.

Udzielam się obecnie w 3 projektach OSS, dwa w Javie, jeden w C++(11/14)/Qt, we wszystkich tych projektach potrzebujemy kogoś od CSS, co jakiś czas kogoś od baz danych, raz w tygodniu kogoś od UI/UX. Proste zadania z ams/C są na porządku dziennym. Z Javy android/java 7/8. Przez dwa lata w 2 projektach nie przepuściliśmy ani jednego commita bez code-review albo komentarzy (nie licząc tłumaczeń). Zdarza się, że dyskusje nad rozwiązaniem problemu są tak soczyste że przenosimy je z githuba/gitlaba na email albo irc, więc uczymy się dużo.
Masz problem z gitem? Też Cię nauczymy, generalnie w OSS w użyciu gita nie wychodzi się za często poza git everyday, wystarczy umieć zrobić git add, git pull, checkout -b, git commit i push.

Powiem tylko czego unikać:
* bycia nachalnym - ten kod jest dla mnie bardzo ważny, chcę żeby został włączony do mastera!
* zmiany licencji kodu który modyfikowaliście - zdarzało się że kilka osób uparcie stawiało, że jak zmieni for(int i) na foreach to teraz należy im się wzmianka w licencji, więc zmienili licencję w kilku plikach z Apache2 na GNU-GPLv3 (MUH FREEDOMS) - nie róbcie tego. Jak używacie gita to i tak zostaniecie na liście autorów pliku na zawsze bo tak działa git. Generalnie jest zasada, że projekty mają swoje listy autorów, generowane automatycznie, więc nikt nie zostanie pominięty, a autorem pliku/klasy jest pierwotny autor i jego zostawia się w nagłówku pliku. Niektórzy się dopisują i potem nagłówek ma 15 autorów, jak usuwam wszystkich to jest płacz że kurde tyle pracy w to włożyłem a teraz mnie usuwasz obraża mnie to i wgl.
* nie obrażaj się na krytykę - w OSS każdy commit jest cenny, ale są commity które konfliktują z przyszłymi funkcjami projektu albo designem - wtedy po prostu jest to odrzucane. Nikt tego nie lubi, ani właściciele repo ani autorzy zmian, ale tak bywa i nic się na to nie poradzi. Sam pisałem przez 6dni jedną fajną funkcję do programu a zanim ją skończyłem pisać cały moduł projektu został usunięty bo zajmował za dużo miejsca i był przestarzały.
* nie wymagaj, żeby ktoś prowadził Cię za rękę jak skompilować projekt. RTFM. Jak sobie z tym nie poradzisz albo się wkurzysz że nie działa to wiedz, że potem będzie trudniej i będziesz tą czynność powtarzać dziesiątki razy. W OSS jest dużo więcej samodzielnej pracy niż w normalnej (płatnej) pracy.
* Najważniejszą osobą w projekcie jest właściciel repozytorium albo osoba której właściciel powierzył repo.

#linux #opensource @Wyrewolwerowanyrewolwer