o Ruby

Stwierdzenie, że idea wolnego oprogramowania to wspaniała rzecz nie będzie zbyt odkrywcze. Na tej idei może skorzystać praktycznie każdy, niezależnie czy jest wielką korporacją, średnią lub małą firmą czy też "niedzielnym" koderem. Czyż to nie wspaniałe, że można zbudować praktycznie dowolnie skomplikowane oprogramowanie i nie trzeba za to płacić ogromnych pieniędzy?

Świat ten rządzi się swoimi prawami. Istnieje głównie dlatego, że są ludzie, którzy dzielą się swoim kodem (nie oszukujmy się, większość z nas tego nie robi), rzecz jasna tylko ten dobry jest zauważany i używany przez innych. Co lepsi urastają nawet do miana "celebrytów". Któż z programistów Rubiego nie zna takich osób jak Yehuda Katz czy też Ryan Bates (ten ostatni jest przykładem tego iż nie zawsze chodzi o oprogramowanie)?

Jedną z idei towarzyszącej temu ekosystemowi jest "forkowanie" (na język polski trzeba by było to przetłumaczyć jako "skopiuj kod, na przemian udoskonalaj go i dziel się z innymi"). Niektórzy mogą odnieść wrażenie, że to zjawisko jest dosyć młode i jest dzieckiem twórców GitHuba. Prawda jest jednak taka, że to zjawisko jest stare jak świat, a wspomniany serwis tylko go spopularyzował czy też wręcz uczynił prostackim (bo czymże jest to jedno kliknięcie w przycisk "fork"?).

Powiem Wam, że to co zrobiono na GitHubie było bardzo nieprzemyślane i głupie. Zanim stwierdzisz, że bredzę przeczytaj proszę do końca to co mam Ci do powiedzenia.

Cofnijmy się do czasów gdy jeszcze GitHub nie istniał. Każdy kto chciał rozwijać swoją wersję jakiegoś projektu (czyli sforkować) mógł to robić. Nie istniała żadna techniczna przyczyna by tego nie robić. Jednakże czynili to nieliczni. Po pierwsze wymagało to odrobinę wysiłku (skopiuj kod, załóż własne repozytorium), po drugie trzeba było mieć konkretny pomysł na własny fork. Że co, pomysł? Ano właśnie tak! Fork bez konkretnego celu jest niczym innym jak zbędną kopią oryginału. To, że dorzucisz do niego kilka swoich zmian (które najczęściej wynikają z jakiejś konkretnej potrzeby i nie przyda się innym) nie czyni go czymś użytecznym. Wręcz przeciwnie. Nikogo nie obchodzi to, że potrzebowałeś opcji "--bardzo-specjalna-zachcianka" i dlatego zrobiłeś forka. Bądź tak miły i zachowaj te zmiany dla siebie i nie pokazuj je innym.

Tak jak wspomniałem - fork musi mieć konkretny cel. Cel, które nie da się zrealizować w projekcie "matce". To, że autor nie chce zmergować Twojego wspaniałego patcha z "bardzo specjalną zachcianką" ciągle nie jest wystarczającym powodem (gdyby tak robili wszyscy to ich kod zamieniłby się bardzo szybko w coś brzydkiego i cuchnącego). Nie ma nic złego w tym, że kopiujesz czyjś kod (oczywiście jeśli pozwala na to licencja), ale wystawianie go dla innych i nazywanie tego Twoim własnym forkiem jest kłamstwem w żywe oczy.

Najgorsze jest to że robi się niepotrzebny bałagan. Są takie projekty, że ciężko jest rozróżnić który projekt jest tym oryginalnym. Tylko dlatego, że autorowi nie chciało się napisać w pliku README "Hej, to tylko mój prywatny fork gdzie eksperymentuję z bardzo specjalną zachcianką. Używaj proszę wersji oryginalnej." Wiem, że GitHub pokazuje umieszcza napis "forked from", ale to wciąż za mało. Nie pozwala mi to rozróżnić forków stworzonych bo taką zachciankę miał forkujący od forków, które faktycznie wnoszą coś nowego (innego) do projektu. Tym bardziej, że w przypadku gdy projekt zostanie po prostu sklonowany, a potem wypchany ze zmianami taki napis się nie pojawi (a powinien to być bardziej naturalny sposób powstawania forków). Nie mówiąc już o tym, że skopiowany projekt może być trzymany zupełnie gdzie indziej.

Wspomniany bałagan najlepiej widać w grafie sieci połączeń między forkami. Za przykład weźmy projekt bundler.

Obejrzyj pełną wersję grafu

To tylko część grafu, ale widzimy co najmniej 3 forki, które mają po 1 commicie. Podejrzewam, że intencją autorów było poprawienie jakiejś małej rzeczy i namówienie autora oryginalnego projektu do zmergowania zmian. Takie kopie w ogóle nie powinny być widoczne dla świata bo i po co? Ten graf miał na celu pokazanie jak wygląda rozwijanie projektu, a przez ten bałagan nic z niego nie wynika. Ba, spróbujcie obejrzeć sobie ten graf dla projektu rails/rails. Niestety nie jest to możliwe a winowajcami są wszyscy Ci, którzy sforkowali railsy tylko dlatego, że robi się to załatwo.

Taki graf miałby sens gdyby było tak jak wcześniej napisałem. Wtedy zawierałby 2, 3, może 5 albo 10 (ale nie 1000!) takich pod projektów, a każdy z nich miał swój konkretny cel (np. "lepszy GC dla Rubiego"). Widać byłoby faktycznie, że ludzie pracują nad nowymi wersjami, które mają konkretne zmiany i które nie są mergowane przez autora głównego projektu.

Co można by było zrobić by poprawić tę sytuację? Jeśli chodzi o GitHuba to uważam, że sforkowanie projektu nie powinno być od razu widoczne. Niestety to raczej nie wchodzi w grę ponieważ w wersji darmowej nie można posiadać prywatnych projektów. Musimy zatem wziąć w swoje ręce. Po pierwsze nie powinniśmy tak lekkomyślnie tworzyć forków, a po prostu tworzyć lokalne klony na komputerze. Po drugie jeśli utworzyłeś fork tylko po to by prosić autora o tzw. "pull request" to napisz w README, że zainteresowani powinni używać wersji oryginalnej. Wydaje mi się, że dobrym pomysłem jest utworzenie osobnego brancha dla naszych zmian i pozostawienie w spokoju mastera (wtedy nie powinno być niepotrzebnych połączeń w grafie). Po trzecie jeśli faktycznie tworzysz fork (czyli wprowadzasz nową większą ideę do projektu) to opisz to w README. Napisz jaki cel przyświeca Twojemu forkowi i dlaczego zdecydowałeś się na swoją wersję zamiast gnębić autora o zmergowanie zmian.

Chociaż nie ma pisanych zasad by robić tak czy inaczej to i tak takie zasady istnieją. Dzięki niepisanym zasadom instalacja większości projektów w C to "make && make install". Takie niepisane zasady powinny także obowiązywać w kwestii forkowania. Inaczej sami sobie tworzymy dżunglę, w której tylko nieliczni sobie poradzą. Mam nadzieję, że chociaż część z moich argumentów ma dla Ciebie sens.

ps. Dowodem mojej tezy może być fakt, że railsy mają 929 forków (sic!), ale wciąż mają otwartych 900 ticketów! Jak widać ilość nie przekłada się na jakość.