title: Jak zacząć udzielać się w projektach Open Source?
class: animation-fade
layout: true

---

# {{title}}

---

???
# Początki bywają trudne.

## Analogia rowerowa

Kto z Was potrafi jeździć na rowerze?

Czy uważacie że jest w tym coś trudnego?

Obserwując codziennie ilu rowerzystów jeździ po Trójmieście można dojść do wniosku że nie ma nic prostszego niż prowadzenie tego środka transportu. Ciekaw jestem ilu z Was pamięta swoje początki? Rower trójkołowy albo czterokołowy, stopniowa nauka łapania równowagi wielokrotnie przypłacona obiciami, otarciami i innymi ranami.

---

## Początki bywają trudne...

---

???
Podobnie jest z udzielaniem się w projektach Open Source. Mnóstwo ludzi z całego świata dzieli się efektami swoich prac z całą społecznością. Patrząc na to co robią może nam się to wydawać łatwe. Sami jednak mamy zwykle opory przed tym by zacząć. Niesłusznie.

---

### <https://doomhammer.info/talks/pyconpl2019>

# Piotr Gaczkowski

![DoomHammer](doomhammer.jpg)

<https://github.com/DoomHammer> | [@doomhammerng](https://twitter.com/doomhammerng)

<https://doomhammer.info>

---

# Czym jest Open Source?

---

???

Jeśli jest na sali ktoś kto nie wie czym jest Open Source pozwolę sobie streścić zamysł. Oprogramowanie Open Source jest udostępniane nie tylko jako gotowy produkt (jak buritto w restauracji) który możemy skonsumować w istniejącej formie bez możliwości modyfikacji. Oprócz produktu dostajemy również kod źródłowy i instrukcję jego zbudowania. To odpowiednik listy produktów i przepisu kulinarnego. Jeśli uwielbiamy burrito ale nie jadamy mięsa, mając do dyspozycji listę składników i przepis jesteśmy w stanie zastąpić mięso dowolnym innym składnikiem.

---

???

Na przykład awokado. Po spróbowaniu takiego burrito z awokado może okazać się że jest ono lepsze od mięsnego wariantu z naszej ulubionej restauracji. Możemy więc przekazać im ten przepis albo opublikować go samemu. Wariant pierwszy odpowiada zgłoszeniu propozycji zmian w oryginalnym projekcie, wariant drugi to publikacja tzw. forka, tudzież odgałęzienia. Osobnego projektu którego historia do pewnego momentu tożsama jest z historią projektu oryginalnego. Potęgą takiego podejścia jest to, że każdy użytkownik ma możliwość uczynić produkt lepszym dla wszystkich podobnych mu odbiorców.

---

???

Wracając z kuchni do biurka: jeśli nie podoba nam się w jaki sposób Mozilla Firefox wyświetla menu, możemy ściągnąć kod źródłowy przeglądarki, zmienić odpowiedni kod, zbudować całość i cieszyć się swoją własną spersonalizowaną wersją.

---

---

## Nie jestem programistą

???

Zanim ci z Was dla których "kod źródłowy" i "kompilacja" brzmią zbyt strasznie opuszczą salę chciałbym zauważyć, że udzielanie się w Open Source nie wymaga znajomości programowania. Przyjrzyjmy się z czego składa się produkt:

---

1. Kod źródłowy najważniejszych funkcji

2. Interfejs użytkownika, projekt graficzny

???

Dla tych którzy gardzą graficznymi interfejsami przypominam że programy konsolowe również mają swój interfejs zaś niemal wszystkie edytory posiadają interfejs graficzny

3. Interakcje z użytkownikiem, użyteczność, UX

4. Media (dźwięki, wideo)

5. Warstwa tekstowa, tłumaczenia

6. Marketing

7. Warstwa prawna

???

Jeśli jesteś w stanie pomóc w którejś z powyższych kategorii, nie ma przeciwwskazań by zacząć udzielać się w Open Source.

---

## Nie potrafię tworzyć

![Firefox](7299833422_000e92f28b_c.jpg)

???

Są dwa główne sposoby udzielania się w Open Source. Możemy zgłosić swój pomysł, propozycję ulepszenia, bądź raport błędu w odpowiednie miejsce i obserwować wątek licząc że ktoś wdroży naszą propozycję lub naprawi błąd. Jest to metoda szczególnie polecana jeśli wydaje nam się że wiemy jak coś powinno wyglądać ale brakuje nam kompetencji by to zrobić samodzielnie. Drugi sposób to wysłanie konkretnych propozycji zmian które jeśli przejdą recenzję i kontrolę jakości mogą trafić do kolejnego wydania interesującego nas produktu.

Jeśli korzystając z Firefox znajdziemy gdzieś literówkę możemy albo zgłosić to jako błąd "hej, napisaliście dpua z błędem" albo znaleźć odpowiednie pliki zawierające tłumaczenia, poprawić literówkę samodzielnie a następnie wysłać nasze zmiany do recenzji.

---

# Dlaczego warto udzielać się w Open Source

---

## Zwiększenie kompetencji

???

Współtworząc Open Source możemy wykorzystać swoje umiejętności w praktyce. Dzięki temu że nasz udział jest poddawany recenzji możemy także uczyć się od innych.

Pracujesz jako developer COBOL, ale całe życie marzyłaś żeby zajmować się UX? Dołącz do projektu Open Source, rozwiń swoje umiejętności i dołącz ten projekt do CV!

## Lepsza widoczność

???

Im więcej się udzielamy tym lepsza nasza widoczność. To z kolei oznacza większą sieć potencjalnych kontaktów i większe grono odbiorców naszych *pozostałych* kanałów (blog, kanał YouTube, LinkedIn, produkty komercyjne). Co za tym idzie?

## Możliwość znalezienia zatrudnienia lub nowych klientów

???

Jeśli komuś spodoba się to w jaki sposób piszemy kod może zechcieć zaprosić nas na rozmowę.

## Możliwość znalezienia potencjalnych pracowników

???

Jeśli komuś spodoba się to jakie projekty tworzymy może zechcieć dla nas pracować.

## Możliwość zrobienia czegoś dla innych (i zdobycie ich wdzięczności)

???

Robicie coś dla siebie, pomagacie innym. Inni są Wam wdzięczni, łapiecie endorfiny i jest błogo. Efekt podobny jak po zjedzeniu tabliczki czekolady, niemniej bardziej rozwijający.

---

## Ładne statystyki

![GitHub Stats](github_stats.png)

---

# Jak znaleźć swój pierwszy projekt?

???

---

## Popularne projekty

https://github.com/search?q=stars:%3E1&s=stars&type=Repositories

???

https://github.com/search?q=stars:%3E1&s=stars&type=Repositories

Wśród popularnych projektów Open Source możemy wspomnieć o Android, Firefox, Chromium (czyli wersji Google Chrome pozbawionej brandingu i kilku innych własnościowych elementów), Kubernetes, Docker, TensorFlow, Atom, Notepad++.

Jest spora szansa że ktoś z Was korzysta z nich na codzień. Być może wiecie o ich irytujących przypadłościach lub macie pomysł jak sprawić by były lepsze. Wasz udział mógłby pomóc milionom potencjalnych odbiorców. Czy zatem powinniście zakasać rękawy i napisać zgłoszenie błędu albo wysłać łatkę do któregoś z powyższych projektów? Nie polecam tej drogi.

Te projekty są ogromne. Mają całe rzesze opiekunów i jescze większe grona użytkowników. Każdego dnia zgłaszane są rozliczne propozycje zmian które trzeba recenzować, poddawać kontroli jakości a przede wszystkim oceniać ich sensownośc i zgodność z wizją produktu. Jest spora szansa, że nasze cenne uwagi przez długi czas pozostaną niewysłuchane. To sprawi, że nasz początkowy entujazm opadnie i łatwo zrazimy się do kolejnych prób. Nasz mózg lubi natychmiastowe wynagrodzenie. Spróbujmy to wykorzystać!

---

class: wrapper
background-image: url(github_most_stars.png)
background-size: contain

---

## Rosnące projekty

https://github.com/trending

---

class: wrapper
background-image: url(github_trending.png)
background-size: contain

???

Za dobry cel pierwszego naszego aktywnego udziału w Open Source polecam projekty nieco mniejsze, choć aktywne (na przykład z listy [GitHub trending](https://github.com/trending)). Alternetywą są duże projekty które charakteryzują się szybkim casem reakcji i wysokim stopniem pozytywnych odpowiedzi. Dobrym przykłądem jest tutaj Homebrew bądź Linuxbrew. Są to zbiorowiska paczek do których łatwo można dodawać własne paczki oprogramowania lub zgłaszać nowe wersje instniejących paczek. Przykładowo jeśli wiemy z Twittera że własnie wysła nowa wersja gry NetHack możemy zgłosić poprawkę do Homebrew która zmienia aktualna wersję Nethack na najnowszą.

---

class: wrapper, center, middle
background-image: url(awesome.svg)
background-size: contain

## Projekty typu `awesome`

https://github.com/sindresorhus/awesome#readme

https://github.com/hackerkid/Mind-Expanding-Books#readme

???

Alternatywą wymagająca najmniej wysiłku jest przejrzenie listy https://github.com/sindresorhus/awesome która wskazuje na inne listy tematyczne. Jest to odpowiednik Wikipedii pozwalający dowolnym osobom dodawać informacje uważane przez nie za ciekawe. Nie wymaga znajomości kodowania, wymaga jedynie wiedzy o czyms wystarczająco fajnym by podzielić się z innymi. Przykład? https://github.com/hackerkid/Mind-Expanding-Books#readme

---

## Imprezy

- [Hacktoberfest](https://hacktoberfest.digitalocean.com/)

- [Google Summer of Code](https://summerofcode.withgoogle.com/)

???

Ostatnim ze sposobów jest wzięcie udziału w imprezie typu https://hacktoberfest.digitalocean.com/ bądź https://summerofcode.withgoogle.com/ gdzie prezentowane są sugestie projektów w których warto się udzielać. Dla osób o niskiej pewności siebie: wystarczy przejrzeć listy z lat ubiegłych bez konieczności brania udziału w imprezie.

---

# Czym charakteryzuje się wartościowy wkład?

---

## Szanujmy warunki pracy innych, szczególnie jeśli oferujemy im swoją pomoc

???

Przede wszystkim przed zgłoszeniem błędu, sugestii lub poprawki sprawdźmy czy ktoś nie zrobił tego wcześniej.

Po drugie wiele projektów posiada dokuemtny takie jak `CONTRIBUTORS.md` w których opisane są warunki współpracy.

https://github.com/dlabspl/zombie-nginx#contributing

Po trzecie niektóre szablony zgłoszeń posiadają wypisane punkty które musimy spełnić zanim wyślemy zgłoszenie. Przeczytajmy je ze zrozumieniem i upewnijmy się że spełniamy odpowiednie standardy.

## Zastanówmy się czy to co oferujemy wnosi wartość również dla innych

???

Czasami nasz świetny pomysł może niezwykle sprytny i zmyślny, ale niekoniecznie wnosi wartość także dla innych. W skrajnych przypadkach może powodwoać spadek wartości. Jeśli będziemy jedynymi odbiorcami danej funkcji prawdopodobieństwo przyjęcia naszej poprawki jest mniejsze. Jeśli odpowiadamy na rzeczywiste zapotrzebowanie społeczności, nasze szanse rosną.

## Bądźmy gadatliwi, lepiej napisać więcej niż ciągnąć długie dyskusje

???

Raport błędu powinien być na tyle szczegółowy by odbiorca znał doskonale kontekst i zamierzone cele użytkownika, ale bez popadania w zbytnią narrację.

Przy zgłaszaniu poprawki wyjśnijmy: co ma ona dawać, jakie są przeiwdywane przypadki użycia, kto może na tym skorzystać. Wepchnięcie komuś pod nos serwetki z napisem `2 + 2 = 4` raczej nie zjedna nam sobie przyjaciół. Co innego gdy opatrzysz to: "stary, masz błąd w czwartym ćwiczeniu, lepiej to popraw jeśli chcesz mieć dobrą ocenę".

## Uruchamiajmy, testujmy, sprawdzajmy jeszcze zanim wyślemy

???

Po raz kolejny temat utrzymania standardów. Ostatnią rzeczą którą chcą zobaczyć opiekunowie projektów Open Source to kawałek kodu który się nei kompiluje bądź nie przechodzi testów. Weźmy pod uwagę że opiekunowie zwykle przeglądają o rząd wielkości więcej zmian niż my wystawiamy. Szanujmy ich czas i swoje nerwy.

---

# Jak nie popaść w depresję w środowisku online?

---

## Nasze najlepsze pomysły nie dla wszystkich są najlepszymi pomysłami

???

Nawet jeśli wymyśliliśmy najlepszy na świecie otwieracz do konserw i znajduja się osoby które uważają że taki otwieracz jest rzeczywiście potrzebny, nie możemy mieć za złe producentowi garniturów że nie chce tego otwieracza dołączać do swoich szytych na miarę zamówień.

Projekty Open Source nie oznaczają, że każdy ma takie samo prawo głosu i każda sugestia może przejść. Ostatecznie to na opiekunów spada ciężar późniejszego utrzymania produktu.

## Nasze najlepsze dzieło nie dla każdego spełnia standardy jakościowe

???

Poruszane już wcześniej. Możemy trafić na projekt w którym opiekunowie mają *bardzo* wysokie standardy dotyczące np. czytelności kodu. Mimo iż damy z siebie wszystko nasza poprawka i tak wróci do nas po recenzji, czasami kilkukrotnie.

Uwaga: udzielanie się w takich projektach może być bardzo wartościowe! Nauczymy się dobrych praktyk szybciej niż gdziekolwiek indziej!

## Co zrobić gdy usłyszymy "nie"?

???

Czasami słusznie, czasami być może niesłusznie zdarzy nam się otrzymać odpowiedź negatywną. "Nie naprawimy tego błędu", "nie potrzebujemy tej poprawki", "ta sugestia wykracza poza zakres projektu". Nie podchodźmy do tej sprawy osobiście. O ile nie mamy na to dowodów powodem odmowy najpewniej nie było to że opiekunowie projektu nas nie lubią. Mogę po prostu mieć odmienną wizję od naszej. Uszanujmy to i spróbujmy ich lepiej zroumieć.

Warto zapytać się jaki jest powód odmowy. Być może jesteśmy w stanie wyciągnąc z tego lekcję i przy kolejnym zgłoszeniu do tego samego projektu zostać zaakceptowani. Być moe tę wiedzę wykorzystamy gdzie indziej.

## Jak radzić sobie z trollami?

[The Complete Guide to Understanding and Dealing with Online Trolls](https://betterhumans.coach.me/the-complete-guide-to-understanding-and-dealing-with-online-trolls-4a606ae25c2c)

???

Najgorszy i jednocześnie najtrudniejszy punkt dotyczący niemal każdych naszych działań online. Bardziej podatni są tu opiekunowie projektów niż osoby zgłaszające pojedyncze poprawki, ale istnieje prawdopodobieństwo że sami staniemy się ofiarami takich ataków. Ponieważ sam nie mam z tym dużego doświadczenia polecam artykuł na [Better Humans](https://betterhumans.coach.me/the-complete-guide-to-understanding-and-dealing-with-online-trolls-4a606ae25c2c).

---

# Jak zarobić na Open Source?

---

## Dotacje, patronaty, finansowanie zbiórkowe

---

### Stałe

- Przycisk Paypal

https://doomhammer.github.io/songcorder/#tips-welcome

---

![Songcorder tips](songcorder_tip.png)

???

Vide: https://doomhammer.github.io/songcorder/

---

### Stałe

- Gittip/Gratipay/[Liberapay](https://en.liberapay.com/explore/repositories)

https://en.liberapay.com/explore/repositories

---

---

### Stałe

- Flattr

---

### Stałe

- Patreon

https://www.patreon.com/sindresorhus

https://www.patreon.com/homebrew

https://www.patreon.com/linuxbrew

---

---

### Stałe

- Patronite

???

https://www.patreon.com/sindresorhus

---

### Jednorazowe

- Kickstarter

https://www.kickstarter.com/projects/aiforeveryone/mycroft-mark-ii-the-open-voice-assistant

---

---

### Jednorazowe

- IndieGoGo

https://www.indiegogo.com/projects/geary-a-beautiful-modern-open-source-email-client

---

---

### Jednorazowe

- Własnym sumptem

https://mediagoblin.org/pages/campaign.html

---

---

## Płatne staże

- https://summerofcode.withgoogle.com/

---

## Firmy rozwijające Open Source

---

## Pozostałe

### Łowcy nagród

https://www.bountysource.com/

### Granty

https://foundation.travis-ci.org/grants

https://www.mozilla.org/en-US/grants/

### Stoisko z lemoniadą

https://github.com/nayafia/lemonade-stand

---

# Przykłady z życia

---

## Markdown Editor

https://doomhammer.github.io/markdown-editor/

http://jbt.github.io/markdown-editor/

???

https://github.com/DoomHammer/markdown-editor

http://jbt.github.io/markdown-editor/

https://doomhammer.github.io/markdown-editor/

## Lean

https://github.com/miekg/lean/pull/6/files

## ls--

https://github.com/trapd00r/ls--/pull/47

---

## ohMediaPlayer

https://github.com/DoomHammer/ohMediaPlayer

## Linuxbrew

https://github.com/Linuxbrew

---

# Dziękuję!

![DoomHammer](doomhammer.jpg)

<https://github.com/DoomHammer> | [@doomhammerng](https://twitter.com/doomhammerng)

<https://doomhammer.info>

### <https://doomhammer.info/talks/pyconpl2019>