Tytuł oryginału: “Homesteading the Noosphere”
Autor: Eric S. Raymond
Tłumaczenie pochodzi z serwisu: www.linuxcommunity.pl
Tłumaczenie: Artur Skura, marzec 2001 r.
Korekta: Little Snake

Co sprawia, że ludzie tworzą oprogramowanie, które rozdają za darmo? Na czym polegają różnice między Open Source, a Wolnym Oprogramowaniem? Czym jest prawo własności do oprogramowania? Jakie cechy powinien posiadać idealny lider dużego projektu? Na te i wiele innych pytań próbuje odpowiedzieć Eric S. Raymond w swoim eseju “Homesteading the Noosphere”.

Abstrakt

Z

aobserwowawszy sprzeczność między “oficjalną” ideologią, przedstawioną w licencjach open source a zachowaniem hackerów, zbadamy zwyczaje regulujące posiadanie i sprawowanie kontroli nad oprogramowaniem open source. W niniejszym eseju wykażemy, że zwyczaje te wskazują na istnienie teorii praw własności, analogicznej do teorii praw własności do ziemi Locke’a, którą przedstawimy w kontekście analizy kultury hackerskiej jako “kultury prezentu”, której członkowie współzawodniczą o prestiż ofiarowując swój czas, energię i kreatywność. Zbadamy również implikacje tej analizy w świetle rozwiązywania problemów w kulturze hackerskiej i wyciągniemy pewne ogólne wnioski.

Pierwsza sprzeczność

Każdy, kto obserwuje pracowity i płodny świat internetowego oprogramowania open source, musi zauważyć interesującą sprzeczność między tym, w co – jak mówią – wierzą hackerzy, a ich zachowaniem; między oficjalną ideologią kultury open source a praktyką.

Kultury posiadają pewne mechanizmy przystosowawcze. Kultura open source jest odpowiedzią na określony zestaw skłonności i bodźców. Jak to zwykle bywa, przystosowanie do okoliczności przejawia się zarówno w świadomej ideologii jak i w niepisanej, nieuświadomionej lub na wpół uświadomionej wiedzy. I, jak to się często zdarza, nieświadoma część przystosowawcza czasem nijak ma się do świadomej ideologii.

W niniejszym eseju spróbuję dociec źródła tej sprzeczności, próbując odkryć przyczynę owych skłonności i napięć. Dojdziemy do pewnych interesujących wniosków dotyczących kultury hackerskiej i związanych z nią zwyczajów. Zakończymy sugestiami dotyczącymi lepszego wykorzystania niepisanej wiedzy istniejącej w tej kulturze.

Różne rodzaje ideologii hackerskich

Ideologia internetowej kultury open source (czyli to, w co – jak sami twierdzą – wierzą hackerzy) jest sama w sobie złożonym tematem. Wszyscy żyjący w tej kulturze są zgodni co do tego, że open source (to jest oprogramowanie, które jest swobodnie rozpowszechniane, można je łatwo rozwijać i modyfikować w celu przystosowania do zmieniających się okoliczności) jest dobrą rzeczą, wartą znacznego, zbiorowego wysiłku. Takie przekonanie praktycznie decyduje o tym, czy dana osoba należy do tej kultury czy nie. Można jednak zaobserwować duże różnice w motywacji jednostek i różnych subkultur: istnieją różne powody, dla których hackerzy utożsamiają się z tym stwierdzeniem.

Pierwsza grupa zróżnicowanie dotyczy entuzjazmu – bez względu na to, czy uważa się open source za dobry środek, umożliwiający osiągnięcie pewnego celu (dobre narzędzia i fajne zabawki są częścią ciekawej zabawy), czy też cel sam w sobie.

Bardzo entuzjastyczna osoba może powiedzieć: “Wolne oprogramowanie jest moim życiem! Żyję po to, by tworzyć użyteczne, piękne programy i zasoby informacyjne, by następnie rozdać je innym”. Osoba o umiarkowanym entuzjazmie powie: “Open source to dobra rzecz, której zamierzam pomóc, poświęcając jej znaczną część swojego czasu”. Osoba o niewielkim entuzjazmie może powiedzieć: “Tak, open source jest czasami dobre. Bawię się nim i szanuję ludzi, którzy je tworzą”.

Dalsze zróżnicowanie można zaobserwować w natężeniu wrogości w stosunku do komercyjnego oprogramowania i/lub firm, które uważa się za dominujące na rynku komercyjnego oprogramowania.

Osoba o nastawieniu bardzo antykomercyjnym może powiedzieć: “Komercyjne oprogramowanie to kradzież i ukrywanie kodu. Piszę wolne oprogramowanie by położyć kres temu złu”. Osoba o nastawieniu mniej antykomercyjnym powie: “Ogólnie rzecz biorąc oprogramowanie komercyjne jest OK, ponieważ programiści zasługują na zapłatę, jednak złem są firmy dryfujące na swoich bublach i panoszące się wszędzie”. Z kolei osoba o nastawieniu nie-antykomercyjnym powie: “Komercyjne oprogramowanie jest OK, używam i/lub piszę oprogramowanie open source po prostu dlatego, że jest lepsze”. (Dziś, zważywszy na rozwój open source’owej części przemysłu od chwili pierwszej publikacji tego eseju, można również usłyszeć: “Oprogramowanie komercyjne jest w porządku, o ile działa lub otrzymam wraz z wersją binarną kod źródłowy”.)

Łącząc wymienione wyżej postawy otrzymamy dziewięć kombinacji, które możemy znaleźć w kulturze open source. Warto na nie zwrócić uwagę, ponieważ odpowiadają różnym agendom, różnym zachowaniom w związku ze współpracą i przystosowaniem do zmieniających się okoliczności.

Z historycznego punktu widzenia, najbardziej widoczna i najlepiej zorganizowana część kultury hackerskiej jest zarówno bardzo entuzjastyczna jak i antykomercyjna. Fundacja Wolnego Oprogramowania (Free Software Foundation), założona przez Richarda Stallmana (RMS) udziela wielkiego wsparcia rozwojowi oprogramowania open source od początku lat osiemdziesiątych: programy takie jak Emacs czy GCC są wciąż podstawowymi narzędziami w świecie open source i nic nie wskazuje na to, by sytuacja ta się zmieniła w dającej się przewidzieć przyszłości.

Przez wiele lat FSF jako jedyna najważniejsza organizacja jednoczyła hackerów open source, tworząc ogromną liczbę narzędzi o istotnym znaczeniu dla kultury open source. FSF była również jedynym sponsorem open source, posiadającym instytucjonalna tożsamość, widoczną dla zewnętrznych obserwatorów kultury hackerskiej. Skutecznie zdefiniowano termin “wolne oprogramowanie”, świadomie nadając mu aspekt konfrontacji (którego równie świadomie unika nowa etykieta – “open source”).

Tak więc zarówno zewnętrzni obserwatorzy jak i sami hackerzy identyfikowali kulturę hackerską z entuzjastycznym i antykomercyjnym podejściem FSF. Sam RMS zaprzecza stwierdzeniu, że jest antykomercyjny, jednak jego przesłanie zostało w ten sposób odczytane przez wielu ludzi, włączając w to jego najgłośniejszych zwolenników. Energiczne i jasno wyrażone kroki FSF w kierunku “położenia końca ukrywaniu oprogramowania” stały się elementem najbliższym ideologii hackerów, zaś RMS osobą najbliższą postaci lidera kultury hackerskiej.

Licencja FSF, zwana “General Public License” (GPL), przedstawia nastawienie FSF. Jest ona bardzo rozpowszechniona w świecie open source. Metalab w Północnej Karolinie (http://metalab.unc.edu/pub/Linux/welcome.html) (wcześniej Sunsite {1}) jest największym i najpopularniejszym archiwum oprogramowania w świecie linuksowym {2}. W czerwcu 1997 roku około połowa pakietów na Sunsite była udostępniona na licencji GPL.

Jednakże FSF nigdy nie była jedyną grupą. W kulturze hackerskiej zawsze istniał cichszy nurt, mniej konfrontacyjny i bardziej przyjacielsko nastawiony do rynku. Jego zwolennicy – pragmatycy – byli wierni nie tyle ideologii, co inżynierskim tradycjom opartym na wczesnych pracach open source, istniejących przed FSF. Najważniejszymi elementami tych tradycji były dwie kultury: uniksowa oraz internetowa z przedkomercyjnego okresu rozwoju Sieci. Typowo pragmatyczne nastawienie jest tylko umiarkowanie antykomercyjne, zaś najcięższym zarzutem wobec świata komercyjnego nie jest samo “ukrywanie” kodu, lecz jego perwersyjny upór w odrzucaniu lepszych dróg rozwoju, włączając w to otwarte standardy, UNIX-a i oprogramowanie open source. Jeśli pragmatycy czegoś nienawidzą, to raczej nie będą to “ukrywacze”, lecz obecny Król Wstecz establishmentu w oprogramowaniu; kiedyś był nim IBM, dziś – Microsoft.

Dla pragmatyków GPL jest użyteczna jedynie jako narzędzie, a nie cel sam w sobie. Jej główną wartością nie jest to, że jest bronią przeciwko “ukrywaniu”, lecz narzędziem zachęcającym do dzielenia się oprogramowaniem i rozwoju wspólnot tworzących w bazarowym stylu. Pragmatyk bardziej ceni sobie dobre narzędzia i zabawki, niż nienawidzi komercji, dlatego może używać wysokiej jakości komercyjnego oprogramowania bez ideologicznej niewygody, zaś doświadczenie open source nauczyło go standardów jakości technicznej, którym może sprostać niewiele komercyjnych programów.

Przez wiele lat pragmatyczny punkt widzenia objawiał się w kulturze hackerskiej głównie jako uparty prąd, który sprzeciwiał się się agendzie FSF w ogólności, zaś GPL w szczególności. W latach osiemdziesiątych i na początku dziewięćdziesiątych postawę tę kojarzono z fanami UNIX-a z Berkeley, użytkownikami oprogramowania na licencji BSD i wczesnymi wysiłkami mającymi na celu zbudowanie uniksów open source na podstawie kodu BSD. Grupom tym nie udało się jednak stworzyć bazarowych wspólnot o dużych rozmiarach; stały się one poważnie podzielone i nieefektywne {3}.

Jednak dopiero eksplozja Linuksa w latach 1993 – 94 dała pragmatyzmowi potężne podstawy. Chociaż Linus Torvalds nigdy nie sprzeciwił się RMS, dał przykład patrząc z pobłażaniem na rozwój komercyjnego oprogramowania dla Linuksa, publicznie deklarując, że wykorzystuje wysokiej jakości oprogramowanie komercyjne do specyficznych celów, łagodnie ośmieszając najbardziej purystyczne i fanatyczne elementy obecne w kulturze hackerskiej.

Skutkiem ubocznym gwałtownego rozwoju Linuksa było nadejście licznych rzeszy nowych hackerów, dla których Linux był głównym obiektem lojalności, zaś agenda FSF miała jedynie wartość historyczną. Chociaż nowsza fala linuksowych hackerów opisuje ten system jako “wybór generacji GNU”, większość naśladuje Torvaldsa niż Stallmana.

Antykomercyjni puryści coraz bardziej stawali się mniejszością. Doniosłość tych przemian ujawniła się dopiero w lutym 1998, kiedy Netscape ogłosiło, że będzie udostępniać program Navigator 5.0 wraz z kodem źródłowym, co zaowocowało większym zainteresowaniem “wolnym oprogramowaniem” w świecie korporacyjnym. Apel do społeczności hackerskiej, by wykorzystać tę sposobność i zmienić nazwę jej produktu z “wolnego oprogramowania” na “open source” spotkał się z natychmiastową akceptacją, która zaskoczyła wszystkich zainteresowanych.

Pragmatyczna część kultury hackerskiej rozwijała się coraz bardziej, by w połowie lat dziewięćdziesiątych skupić się wokół różnych centrów zainteresowań. Z pierwotnego korzenia UNIX-a/Internetu zaczęły wyrastać nowe, pół-niezależne społeczności, z własną samoświadomością i charyzmatycznymi liderami. Najważniejszą z nich po Linuksie była kultura Perla, której przewodzi Larry Wall. Mniejszymi, lecz istotnymi subkulturami były społeczności skupiające się wokół Tcl-a {4} Johna Osterhouta i Pythona {5}. Te trzy społeczności wykazały swoją niezależność nie korzystając z GPL, lecz tworząc swoje własne schematy licencji.

Rozwiązła teoria, purytańska praktyka

Mimo tych wszystkich zmian panowała dość powszechna zgoda co do zakresu znaczeniowego “open source” czy “free software”. Najbardziej przejrzysty przykład tej zgodności można znaleźć w różnych licencjach open source, wszystkie bowiem posiadają pewne wspólne, najistotniejsze elementy.

W 1997 roku te wspólne elementy zostały umieszczone w “Normach Wolnego Oprogramowania Debiana {7}”, które przekształciły się w Definicję Open Source (Open Source Definition, http://www.opensource.org). Według zaleceń OSD, licencja open source ma chronić niczym nie ograniczone prawo każdej osoby do modyfikacji (i redystrybucji zmodyfikowanych wersji) oprogramowania open source. Tak więc niepisana teoria OSD (jak również licencji zgodnych z OSD, takich jak GPL, BSD czy licencji artystycznej Perla) mówi, że każdy może być hackerem. Nic nie może przeszkodzić kilku ludziom wziąć dany projekt open source (choćby kompilator GCC Free Software Foundation), zduplikować źródła, skierować je na nowe, rewolucyjne tory i ogłosić je jako _ten_ produkt.

W praktyce jednak takie rozwidlenia {8} prawie nigdy się nie zdarzają. Występują bardzo rzadko i zawsze towarzyszy im zmiana nazwy i wiele publicznych wypowiedzi usprawiedliwiających tego typu posunięcie. Jest oczywiste, że w takich przypadkach jak rozwidlenie GNU Emacs/Xemacs, GCC/egcs czy rozwidlenia w różnych grupach BSD, osoby je inicjujące czuły, że sprzeciwiają się całkiem potężnej normie przyjętej przez społeczność [1].

Kultura open source posiada rozwinięty system zwyczajów związanych z posiadaniem (co stoi w sprzeczności z teorią “każdy-może-być-hackerem), o których się raczej nie mówi. Zwyczaje te regulują takie kwestie, jak np. kto może modyfikować oprogramowanie, okoliczności, które pozwalają na dokonanie takich modyfikacji, oraz (szczególnie) kto ma prawo dystrybuować zmodyfikowane wersje wśród społeczności. Rozmaite tabu kultury hackerskiej są dość ostro zarysowane. Dlatego, mając na względzie przyszłe rozważania, podsumujemy kilka najważniejszych:

• Istnieje silne presja społeczna sprzeciwiająca się rozwidlaniu projektów. Rozwidlenia nie mają miejsca, chyba że w obliczu palącej konieczności, czemu towarzyszy zmiana nazwy i wiele wyjaśnień na forum publicznym.
• Zmiany dystrybucyjne wprowadzane do projektu bez współpracy z moderatorami są źle widziane; nie dotyczy do przypadków, kiedy chodzi o niewielkie poprawki związane z przenośnością.
• Usuwanie nazwiska danej osoby z historii projektu, podziękowań czy listy opiekunów projektu nie jest w ogóle praktykowane, chyba, że osoba ta wyraźnie wyrazi na to zgodę.

W pozostałej części eseju bardziej szczegółowo zajmiemy się tymi tabu i zwyczajami związanymi z posiadaniem. Zbadamy nie tylko ich funkcjonowanie, ale i odsłoniętą przez nich dynamikę i struktury bodźców w społeczności open source.

Posiadanie i open source

Co oznacza termin “własność”, kiedy posiadany obiekt można nieskończenie powielać i zmieniać, zaś otaczająca go kultura nie dysponuje środkami przymusu, ani gospodarką materialnego ubytku?

W przypadku kultury open source łatwo odpowiedzieć na to pytanie. Właścicielami projektu są ci, którzy mają wyłączne prawo, uznane przez całą społeczność, do redystrybucji zmodyfikowanych wersji. (Omawiając “posiadanie” w tej części eseju będę używał liczby pojedynczej, z czego mogłoby wynikać, że właścicielem wszystkich projektów jest jakaś jedna osoba. Należy jednak pamiętać, że właścicielami projektów mogą być grupy. Zbadamy wewnętrzną dynamikę takich grup w dalszej części eseju.)

Według standardowych licencji open source, wszyscy uczestnicy gry ewolucyjnej maja równe prawa. W praktyce istnieje jednak przyjęty podział na “oficjalne” łaty, zaakceptowane i zintegrowane z ewoluującym oprogramowaniem przez oficjalnych opiekunów, oraz “podstępne” łaty, udostępniane przez osoby trzecie. “Podstępne” łaty widuje się rzadko i zazwyczaj im się nie ufa.

Łatwo dojść do wniosku, że publiczna redystrybucja jest kwestią podstawową. Panujący zwyczaj zachęca użytkowników do łatania źródeł na osobisty użytek, kiedy zajdzie taka potrzeba. Zwyczaj jest neutralny wobec ludzi, którzy dystrybuują zmodyfikowane wersje wśród zamkniętej grupy użytkowników czy w grupie programistów. Kwestia własności ujawnia się dopiero wtedy, kiedy modyfikacje te zostają udostępnione szerszej publiczności.

Ogólnie rzecz biorąc istnieją trzy drogi uzyskania prawa własności do projektu. Pierwszą, najbardziej oczywistą, jest rozpoczęcie własnego projektu. Kiedy projekt od chwili powstania ma tylko jednego opiekuna, a opiekun ten wciąż jest aktywny, zwyczaje nie pozwalają nawet zakwestionować jego prawa własności do projektu.

Drugim sposobem na zdobycie prawa własności do projektu jest przejęcie go od poprzedniego opiekuna (proces ten nazywany jest czasem “przekazywaniem pałeczki”). Społeczność rozumie, że właściciele projektu mają obowiązek przekazać go kompetentnym następcom, kiedy już nie będą mogli lub chcieli inwestować swojego czasu w rozwój projektu czy prace nad jego utrzymaniem.

Warto zauważyć, że w przypadku dużych projektów, owo “przekazywanie pałeczki” jest zazwyczaj ogłaszane wśród dźwięków fanfar. Chociaż bowiem nie słyszy się o sprzeciwach szerokich rzesz społeczności co do wyboru przez opiekuna swojego następcy, zwyczajowo zakłada się, że uwzględnienie opinii publicznej jest istotne.

Jeśli chodzi o mniejsze projekty, zazwyczaj wystarczy wzmianka w pliku historii {9} wspominająca o zmianie właściciela. Przyjmuje się, że jeśli poprzedni właściciel nie zrzekł się projektu dobrowolnie, może próbować odzyskać nad nim kontrolę ogłaszając swoje roszczenia na forum publicznym w rozsądnym terminie.

Trzeci sposób uzyskania prawa własności polega na tym, że zauważywszy, iż projekt wymaga dopracowania, zaś jego opiekun zniknął lub stracił zainteresowanie, podejmuje się obowiązkowe wysiłki, by go odnaleźć. Jeśli się nie udaje, można próbować ogłosić w odpowiednim miejscu (np. grupie dyskusyjnej poświęconej aplikacjom), że projekt został osierocony i że jest rozważana możliwość przejęcia za niego odpowiedzialności.

Zwyczaje wymagają, że należy poczekać przez pewien czas przed ogłoszeniem się nowym właścicielem. Jeśli w tym okresie ktoś ogłosi, że pracuje nad projektem, jego roszczenia będą decydujące. Dobrym zwyczajem jest ogłoszenie swoich zamiarów więcej niż raz; jeszcze więcej dobrych punktów za przestrzeganie etykiety można otrzymać zamieszczając ogłoszenia na kilku odpowiednich do tego forach (odpowiednie grypy i listy dyskusyjne), a jeszcze więcej za cierpliwość w oczekiwaniu na odpowiedzi. Im więcej poczyni się wysiłków, by pozwolić odpowiedzieć właścicielowi i innym osobom roszczącym sobie prawa do projektu, tym większe znaczenie będzie miało owo ogłoszenie intencji jeśli nikt się nie zgłosi.

Jeśli przeszło się ten proces na oczach społeczności i nikt nie zgłosił sprzeciwu, można ogłosić przejęcie osieroconego projektu i odnotować to w pliku historii. Jest to jednak mniej bezpieczne niż przekazanie pałeczki; nie można też spodziewać się uznania za w pełni prawowitego opiekuna projektu dopóki znacznie się go nie ulepszy w oczach społeczności.

Obserwowałem funkcjonowanie tych zwyczajów przez dwadzieścia lat, pamiętając jeszcze starożytną historię oprogramowania open source z czasów sprzed FSF. Zwyczaje te zawierają kilka ciekawych aspektów. Jednym z najbardziej interesujących jest fakt, że większość hackerów stosuje się do nich nie będąc ich w pełni świadomymi. Być może ten esej jest ich pierwszym świadomym i w miarę kompletnym pisemnym podsumowaniem.

Następny aspekt polega na tym, że zwyczajów tych przestrzega się z żelazną (czasem zadziwiającą) konsekwencją. Przyglądałem się ewolucji dosłownie setek projektów open source, a jednak przypadki poważnego pogwałcenia owych norm mogę policzyć na palcach.

Trzecim interesującym aspektem jest zjawisko ewolucji tych zwyczajów, które rozwijają się w jasno określonym kierunku. Kierunkiem tym jest zwiększanie odpowiedzialności przed społecznością, poświęcanie większej uwagi społeczności oraz troska o zachowanie informacji o autorach i dokonywanie zmian w plikach historii projektu tak, by (między innymi) prawo do posiadania projektu przez obecnych opiekunów nie budziło wątpliwości.

Jeden z wcześniejszych czytelników zwrócił moją uwagę na fakt, że konfrontacja internetowej kultury hackerskiej z kulturą krakerów / piratów (owi “warez d00dz” skupieni są wokół systemów BBS, a zajmują się łamaniem zabezpieczeń gier komputerowych) rzuca światło na wzorzec generatywny tych kultur. Do d00dz powrócimy jeszcze w tym eseju, by uwydatnić różnice między nimi a hackerami.

Locke i prawo do ziemi

W zrozumieniu wzorca generatywnego może nam pomóc historyczna analogia, nie mająca większego związku z normalnymi sferami zainteresowań hackerów. Studenci historii prawa i filozofii politycznej mogą zauważyć, że wyrażona w zwyczajach hackerskich teoria własności jest praktycznie identyczna z anglosaksońską teorią dzierżawy ziemi! W teorii tej wspomina się o trzech
sposobach zdobycia prawa własności do ziemi.

Na granicy, gdzie znajduje się ziemia, która nigdy nie miała właściciela, można było uzyskać prawo własności przez zagospodarowanie, łącząc swoją pracę z ziemią niczyją, stawiając ogrodzenie i broniąc swojego tytułu.

Zwykłym sposobem przemieszczania się na zasiedlone tereny było przeniesienie tytułu, czyli otrzymanie aktu własności od poprzedniego właściciela. W teorii tej dużą role odgrywa koncepcja “łańcucha tytułów”. Idealnym dowodem własności był łańcuch aktów własności i przekazań praw własności mający swój początek w czasach, kiedy ziemia zostałą pierwotnie zagospodarowana.

Teoria ta wspomina wreszcie o utracie lub porzuceniu tytułu (np. w przypadku, kiedy właściciel umiera nie pozostawiając dziedzica, zaś rejestr potrzebny do sporządzenia łańcucha tytułów do bezpańskiej ziemi zaginął). Pozostawiona w ten sposób ziemia może zostać “zasiedziana” – ktoś może się wprowadzić, wprowadzić ulepszenia i bronić swojego tytułu do ziemi tak, jakby ją zagospodarował.

Teoria ta, podobnie jak i zwyczaje hackerów, ewoluowała organicznie w czasach, kiedy władza centralna była słaba lub nie było jej wcale. Jej początków należy szukać w prawie germańskich i nordyckich plemion, z którego ewoluowała przez ponad tysiąc lat. Ponieważ w czasach współczesnych usystematyzował i zracjonalizował ją angielski filozof polityczny, John Locke, dlatego czasem nazywa się ją teorią własności Locke’a.

Teorie podobnej do tej pod względem logicznym ewoluowały zawsze wtedy, kiedy własność miała duże znaczenie dla gospodarki czy przetrwania, zaś żadna władza centralna nie była wystarczająco silna, by wymusić centralne przydzielanie dóbr. Zasada ta sprawdza się nawet w kulturach prymitywnych, które czasem romantycznie uważa się za pozbawione koncepcji “własności”. Np. w tradycji buszmenów !Kung San z pustyni Kgalagadi (wcześniej Kalahari) nie istnieje nic takiego jak posiadanie terenów łowieckich. Istnieje jednak pojęcie własności źródeł wody, zaś rządzące nim zasady bardzo przypominają teorie Locke’a.

Przykład! Kung San jest pouczający, ponieważ ukazuje, że opisane przez Locke’a zwyczaje związane z własnością manifestują się jedynie wtedy, kiedy oczekiwana korzyść przewyższa koszt obrony danego zasobu. Tereny łowieckie nie są własnością, ponieważ korzyść z polowania jest rzeczą zmienną i bardzo trudną do przewidzenia i choć ma dużą wartość, nie jest rzeczą niezbędną do przetrwania z dnia na dzień. Natomiast źródła wody pitnej mają fundamentalne znaczenie dla przetrwania i są wystarczająco niewielkie, by je bronić.

“Noosfera” w tytule niniejszego eseju to terytorium idei, przestrzeń wszystkich możliwych myśli [2]. W zwyczajach hackerskich związanych z posiadaniem widzimy teorię praw własności Locke’a w jednym z podzbiorów noosfery: w przestrzeni wszystkich programów. Stąd też “zagospodarowywanie noosfery” to działanie towarzyszące każdemu nowemu projektowi open source.

Faré Rideau (fare@tunes.org) słusznie zwraca uwagę na fakt, że hackerzy poruszają się nie tylko w świecie czystych idei. Faré twierdzi, że hackerzy posiadają projekty programistyczne – punkty skupienia materialnego wysiłku (rozwój projektu, serwis itd.), z którymi wiążą się takie kwestie jak reputacja, zaufanie itd. Uważa więc, że przestrzeń zajmowana przez projekty hackerów nie jest noosferą, lecz pewnego rodzaju połączeniem – przestrzenią projektów programistycznych eksplorujących noosferę. (Tutaj gest przeprosin w kierunku czytających to astrofizyków: z etymologicznego punktu widzenia, tą podwójną przestrzeń można by nazwać “ergosferą”, czyli “sfera pracy”.)

Rozróżnienie między noosferą a ergosferą nie ma praktycznego znaczenia dla naszych rozważań. Można wątpić, czy w ogóle istnieje coś takiego jak noosfera w czystym sensie określonym przez Faré – trzeba by chyba być platonistą, by w nią wierzyć. Rozróżnienie miedzy noosferą a ergosfera ma jedynie praktyczne znaczenie jeśli chce się dowodzić, że idei (elementów noosfery) nie można posiadać, można jednak posiadać ich instancje, czyli projekty. Kwestia ta wiąże się z pewnymi aspektami teorii własności intelektualnej, które wychodzą poza obszar tematyczny niniejszego eseju {3}.

Jednak, aby uniknąć nieporozumień, warto zauważyć, że ani noosfera ani ergosfera nie jest tym samym co całość wirtualnych lokacji w mediach elektronicznych, którą czasem (ku obrzydzeniu większości hackerów) nazywa się “cyberprzestrzenią”. Tam kwestie własności są regulowane przez całkowicie inne zasady, bliższe składnikowi materialnemu: ten, kto jest właścicielem medium i maszyny, na której znajduje się część cyberprzestrzeni, jest praktycznie właścicielem tego kawałka cyberprzestrzeni.

Logika Locke’a silnie sugeruje, że hackerzy open source przestrzegają swoich zwyczajów, ponieważ oczekują pewnego wynagrodzenia za swój wysiłek. Wartość tego wynagrodzenia musi przekraczać koszt wysiłku włożonego w zagospodarowanie projektów, utrzymywanie historii wersji dokumentujących “łańcuch tytułów własności” oraz czasowy koszt publicznego ogłaszania i oczekiwania, kiedy przejmuje się osierocony projekt przez zasiedzenie.

Idąc dalej: “korzyść” płynąca z open source musi być czymś więcej niż tylko możliwością korzystania z oprogramowania, czymś, co zostałoby popsute czy rozmyte przez proces rozwidlania. Gdyby liczyło się tylko korzystanie z niego, nie istniałoby tabu sprzeciwiające się rozwidlaniu, zaś posiadanie projektów open source w niczym nie przypominałoby praw własności do ziemi. W rzeczy samej, istnienie alternatywnego świata (w którym jedyną korzyścią jest używanie oprogramowania, zaś rozwidlanie nie jest problemem) zakładają istniejące licencje open source.

Możemy łatwo wyeliminować kilka potencjalnych odpowiedzi na pytanie o istotę “korzyści” w projektach open source. Ponieważ nie da się nikogo efektywnie do niczego zmuszać przez sieć, możemy od razu wyeliminować chęć władzy. Kultura open source nie posiada również niczego przypominającego pieniądze czy wewnętrzną gospodarkę opartą na dobrach materialnych, nie można więc stwierdzić, że hackerzy pragną czegoś analogicznego do materialnych dóbr (tj. gromadzenia materialnych żetonów).

Aktywność open source może jednak pomóc ludziom się wzbogacić; działający w tym wypadku mechanizm stanowi interesującą wskazówkę dotyczącą motywacji tej działalności. Czasem zdarza się, że reputacja uzyskana w świecie open source rozlewa się w rzeczywistym świecie przynosząc wymierne korzyści. Może to być propozycja lepszej pracy, kontrakt na usługi konsultingowe czy napisanie książki.

Tego skutki uboczne mają jednak jednak w najlepszym razie marginalne znaczenie dla większości hackerów i zdarzają się dość rzadko – na tyle rzadko, by wykluczyć tę możliwość jako jedyne wytłumaczenie, nawet jeśli nie weźmiemy pod uwagę ciągłych protestów hackerów, którzy twierdzą, że pracują nie dla pieniędzy lecz z pobudek idealistycznych czy zamiłowania.

Warto jednak zbadać w jaki sposób powstają te skutki uboczne związane ze sferą ekonomiczną. Jak zobaczymy poniżej, samo zrozumienie dynamiki rozwoju reputacji w kulturze open source potrafi wiele wyjaśnić.

Środowisko hackerskie jako kultura prezentu

W zrozumieniu roli reputacji w kulturze open source może pomóc zagłębienie się w antropologię i ekonomię, badając różnicę między kulturami wymiany a kulturami prezentu.

Ludzie odczuwają wewnętrzną potrzebę współzawodnictwa jeśli chodzi o status społeczny; potrzeba ta jest wpleciona w historię naszej ewolucji. Przez 90% czasu przed wynalezieniem rolnictwa, nasi przodkowie żyli w niewielkich grupach polujących nomadów. Osoby o wyższym statusie (te, które były najbardziej skuteczne w informowaniu koalicji i namawianiu innych do współpracy z nimi) miały najzdrowszych partnerów i dostęp do najlepszego jedzenia. Ten pęd ku wyższemu statusowi wyraża się na różne sposoby, co w dużym stopniu zależy od niedostępności dóbr potrzebnych do przetrwania.

Większość metod organizacji, którymi dysponują ludzie, to metody przystosowania do potrzeb i braków. Każda z tych metod zawiera w sobie wiele sposobów uzyskania wyższego statusu społecznego.

Najprostszym sposobem jest hierarchia przełożonych. W hierarchii przełożonych rozdzielanie dóbr jest przeprowadzane przez władzę centralną, której towarzyszy wsparcie siłowe. Hierarchie przełożonych są bardzo słabo skalowalne [4]. W miarę rozrostu stają się coraz bardziej brutalne i niewydajne. Dlatego też hierarchie przełożonych większe niż duża rodzina są zawsze pasożytami żerującymi na większej gospodarce innego typu. W tego typu wspólnotach dostęp do środków przymusu określa status społeczny.

Nasze społeczeństwo opiera się na gospodarce wymiany. Jest to złożony sposób przystosowania się do braku zasobów, który – w przeciwieństwie do modelu hierarchicznego – skaluje się bardzo dobrze. Podział dóbr jest zdecentralizowany i odbywa się poprzez handel i dobrowolną współpracę (a dominującym skutkiem pragnienia współzawodnictwa jest wytworzenie zachowań sprzyjających współpracy). W gospodarce wymiany status społeczny jest określany przez stopień kontroli rzeczy (niekoniecznie w odniesieniu do materialnych), których można używać lub nimi handlować.

Większość ludzi posiada w swoich umysłach oba te modele i rozumieją sposoby interakcji między nimi. Rząd, wojsko i zorganizowane grupy przestępcze to przykłady hierarchii przełożonych, żerujących na szerszej gospodarce wymiany, nazywanej “wolnym rynkiem”. Istnieje jednak trzeci model, zupełnie odmienny od obu pozostałych, o którym mówią raczej tylko antropolodzy: kultura prezentu.

Kultury prezentu dostosowują się nie do braku, lecz do nadmiaru. Powstają w populacjach, w których nie istnieją znaczące problemy materialne związane z dobrami niezbędnymi do przetrwania. Możemy zaobserwować kultur prezentu w kulturach pierwotnych w miejscach, w których nie brakuje pożywienia a klimat jest łagodny. Występują one również w niektórych warstwach naszego społeczeństwa, szczególnie w show businessie i wśród najbogatszych.

Obfitość sprawia, że trudno jest utrzymać hierarchie przełożonych, zaś relacje oparte na wymianie nie mają prawie żadnego sensu. W kulturach prezentu status społeczny określa nie to, co się kontroluje, lecz to, co się rozdaje.

Stąd się biorą party wodza Kwakiutl. Stąd też wielkie akty filantropii multimilionerów, zwykle czynione publicznie. Stąd też długie godziny spędzane przez hackerów czyniących wysiłki, by stworzyć kod wysokiej jakości.

Jeśli podejdziemy do kultury hackerskiej w ten właśnie sposób, stanie się oczywiste, że jest ona kultura prezentu. Nie cierpi na niedobór rzeczy koniecznych do przetrwania – przestrzeni dyskowej, przepustowości sieci czy mocy obliczeniowej. Oprogramowaniem wszyscy dzielą się w swobodny sposób. Ta obfitość stworzyła sytuację, w której jedynym dostępnym miernikiem jest reputacja.

Spostrzeżenie to nie wyjaśnia jednak całkowicie wszystkich cech kultury hackerskiej. Krakerzy i warez d00dz również posiadają kulturę prezentu operującą na tych samych (elektronicznych) mediach, jednak zachowują się inaczej. Mentalność grupowa w ich kulturze jest o wiele silniejsza i bardziej hermetyczna niż u hackerów. Strzegą sekretów zamiast się nimi dzielić, o wiele łatwiej znaleźć grupy krakerskie rozprowadzające pliki wykonywalne bez źródeł umożliwiające złamanie zabezpieczeń oprogramowania, niż praktyczne wskazówki opisujące, w jaki sposób zabezpieczenia te zostały złamane [5].

Wynika z tego – o ile nie jeszcze nie jest to jasne – że kultura prezentu może przejawiać się w różnych formach. Liczą się wartości i historia. jeśli chodzi o historię kultury hackerskiej, podsumowałem ją w Krótkiej historii hackerstwa – geneza jej istnienia w jej obecnej formie nie jest okryta tajemnicą. Hackerzy określili swoją kulturę pewnym zbiorem własnych wyborów dotyczącym formy współzawodnictwa, w którym biorą udział. I tej właśnie formie poświęcimy resztę niniejszego eseju.

Radość płynąca z hakerstwa

Warto przy okazji wspomnieć, że analizując “grę o reputację” nie miałem zamiaru pominąć czy dewaluować czystego artystycznego zadowolenia płynącego z tworzenia wspaniałego oprogramowania i uruchamiania go. Wszyscy doświadczamy tego typu satysfakcji i sprawia nam ona radość. Ludzie, dla których nie jest ona wystarczającą motywacją nigdy nie zostaną hackerami, podobnie jak ludzie, którzy nie kochają muzyki, nigdy nie zostaną kompozytorami.

Być może więc powinniśmy rozważyć inny model hackerskiego zachowania, którego główną motywacją jest czysta radość z wykonywania swojego rzemiosła. Model “rzemieślniczy” przedstawia zwyczaje hackerskie jako metody maksymalizacji zarówno okazji do praktykowania rzemiosła jak i jakości płynących z niego rezultatów. Czy model ten nie koliduje, lub przynajmniej nie sugeruje czegoś innego niż model “gry o reputację”?

Niekoniecznie. Badając model “rzemieślniczy”, dochodzimy do tego samego problemu, który przeszkadza hackerom działać w postaci kultury prezentu. W jaki sposób osiągnąć maksymalna jakość, jeśli nie istnieje żaden miernik jakości? Jeśli w kulturze tej nie działa gospodarka ograniczonych dóbr, jaki system miar przyjąć poza opinią innych? Wydaje się, że jakakolwiek kultura rzemieślnicza musi tworzyć swoje struktury przy pomocy “gry o reputację” – i rzeczywiście możemy zaobserwować tego typu dynamikę w wielu kulturach rzemieślniczych na przestrzeni czasu – od średniowiecznych cechów począwszy.

Model “rzemieślniczy” w porównaniu z “kulturą prezentu” ma jedną słabość: mianowicie nie wyjaśnia nam sprzeczności, od których rozpoczęliśmy ten esej. Warto również zwrócić uwagę na fakt, że motywacja “rzemieślnicza” nie musi być czymś tak odległym od gry o reputację, jak by nam się mogło wydawać. Wyobraźmy sobie nasz wspaniały program zamknięty w szafce i nieużywany. Następnie wyobraźmy sobie ten sam program efektywnie wykorzystywany i dostarczający przyjemności wielu ludziom. Która z tych wizji daje nam satysfakcję?

Mimo to skupimy się na modelu rzemieślniczym, który intuicyjnie wydaje się atrakcyjny wielu hackerom i wyjaśnia również pewne aspekty indywidualnego zachowania. [6,7]

Po publikacji pierwszej wersji tego eseju w Internecie, anonimowy respondent przesłał swój komentarz: “Być może nie pracuje się dla reputacji, jednak reputacja jest rzeczywistą zapłatą niosącą ze sobą konkretne konsekwencje – o ile dobrze wykonuje się swoją pracę”. To subtelna i ważna kwestia. Motywacja związana z reputacją działa, bez względu na to, czy rzemieślnik jest jej świadom czy nie. Dlatego bez względu na to, czy hacker rozumie, że jego postępowanie jest częścią gry o reputację, jego zachowanie będzie kształtowane przez tę grę.

Inne osoby komentujące pierwsze wersje tego tekstu zwróciły uwagę na fakt, że estyma współpracowników i radość płynąca z hackerstwa znajdują się ponad poziomem podstawowych potrzeb w modelu motywacji znanej teorii “hierarchii wartości” Abrahama Maslova [8]. Zgodnie z tym poglądem, radość płynąca z hackerstwa wypływa z potrzeby samorealizacji czy transcendencji, które nie zostaną należycie wyrażone dopóki choć minimalnie nie zaspokoi się niższych potrzeb (takich jak potrzeba bezpieczeństwa czy przynależności, uznania przez społeczność). Dlatego gra o reputację może mieć kluczowe znaczenie dla kontekstu społecznego, w którym radość z hakerstwa może stać się głównym motywem zachowania danej osoby.

Wiele twarzy reputacji

W każdej kulturze prezentu istnieją ogólne powody dla których warto grac o reputację (prestiż). Po pierwsze, reputacja w społeczności jest główną nagrodą – to główny najbardziej oczywisty powód. Zostaliśmy wpleceni w to doświadczenie przez mechanizmy ewolucyjne, o których była mowa wcześniej. (Wielu ludzi nauczyło się przekierowywać potrzebę prestiżu na różnego rodzaju bardziej subtelne formy aktywności, nie mające oczywistego związku z istniejącą społecznością, takie jak “honor”, “integralność etniczna”, “pobożność” itd., co jednak nie zmienia mechanizmu leżącego u jej podstaw.)

Po drugie, prestiż jest dobrym (w czystej gospodarce prezentu – jedynym) sposobem na zwrócenie uwagi i nawiązanie współpracy z innymi ludźmi. Jeśli dana osoba znana jest ze swej szczodrości, inteligencji, uczciwości, zdolności przywódczych i innych zalet, łatwiej przekonać innych, że na współpracy z nią można zyskać.

Po trzecie, jeśli gospodarka prezentu ma kontakt lub przeplata się z gospodarką wymiany lub hierarchią przełożonych, reputacja może się w nich rozprzestrzenić, zaś uzyskany tam status może być nawet wyższy niż w gospodarce prezentu.

Oprócz tych ogólnych powodów istnieje jeszcze kilka okoliczności właściwych kulturze hackerskiej, które sprawiają, że prestiż staje się w niej wartością o wiele cenniejszą, niż byłby w kulturze prezentu w “świecie rzeczywistym”.

Najważniejsza z tych okoliczności to fakt, że rozdawane wyroby (czy też – interpretując to inaczej – widoczne oznaki włożonego wysiłku i czasu) są bardzo złożone. Ich wartość nie jest tak oczywista, jak wartość prezentów materialnych czy pieniędzy w gospodarce wymiany. O wiele trudniej obiektywnie odróżnić dobry prezent od marnego. Podobnie sukces w staraniach o status zależy w pewnym stopniu od krytycznego osądu innych.

Następną szczególna okoliczność to względna czystość kultury open source. Większość kultur prezentu uległo zepsuciu – czy to przez związki z gospodarkami wymiany, takie jak handel luksusowymi towarami, czy też związki z hierarchiami poleceń, takimi jak klany czy rodziny. W kulturze open source nie występują znaczące analogie do tego typu sytuacji, stąd też praktycznie nie istnieją inne sposoby podwyższenia statusu niż reputacja uzyskana w społeczności.

Prawa własności i bodźce skłaniające do uzyskania reputacji
Możemy teraz zebrać poczynione do tej pory wnioski próbując stworzyć spójny obraz hackerskich zwyczajów w odniesieniu do własności. Rozumiemy już korzyść z zagospodarowywania noosfery – jest nią reputacja w hackerskiej kulturze prezentu, wraz ze wszystkimi drugorzędnymi korzyściami i skutkami ubocznymi.

Dysponując tą wiedzą możemy przejść do analizy zwyczajów związanych z własnością według teorii Locke’a uznając je za bodźce do maksymalizacji reputacji, że uznanie zostanie skierowane dokładnie tam, gdzie trzeba, a nie tam, gdzie nie trzeba.

Trzy tabu, które zaobserwowaliśmy wcześniej, w świetle tej analizy układają się w logiczną całość: reputacja danej osoby może ucierpieć, jeśli ktoś inny przywłaszcza i niszczy jej pracę, zaś wymienione tabu (i związane z nimi zwyczaje) mają za zadanie zapobiec takiej sytuacji. (Mówiąc bardziej pragmatycznie: hackerzy zazwyczaj unikają rozwidleń i rozpowszechniania nie wchłoniętych łat do cudzych projektów, by móc zadeklarować bezprawność tego typu działań w stosunku do ich własnych projektów).

• Rozwidlanie projektów jest złe, ponieważ naraża reputację osób pracujących nad projektem przed momentem rozwidlenia na ryzyko, które mogą kontrolować jedynie pracując równocześnie nad oboma projektami po rozwidleniu (co ogólnie rzecz biorąc wprowadza spore zamieszanie lub sprawia zbyt wiele trudności).
• Dystrybucja łat (lub co gorsza – binariów) z trzeciej ręki naraża reputację właścicieli projektu na niezasłużone ryzyko. Nawet jeśli oficjalny kod jest doskonały, właściciele zostaną skrytykowani za błędy w łatach.
• Potajemne usuwanie nazwisk innych z plików składowych projektu jest w tym kontekście kulturowym jedną z najgorszych zbrodni. Czyn ten jest bowiem kradzieżą prezentu ofiary i przedstawienie go jako prezent złodzieja.

Rzecz jasna rozwidlenie projektu czy dystrybucja łat z trzeciej ręki godzi również bezpośrednio w reputację grupy programistów, która rozpoczęła projekt. Jeśli dokonuję rozwidlenia projektu lub rozpowszechniam łaty z trzeciej ręki, tym samym mówię: “Podjęliście złą decyzję [nie prowadząc projektu tam, dokąd ja go prowadzę]”, zaś każdy, kto korzysta z mojej wersji podejmuje to wyzwanie. Samo to jednak jest dość uczciwym wyzwaniem, choć dość daleko idącym – jest to najdalszy koniec aktywności znanej jako “ocenianie kodu źródłowego przez społeczność”. Dlatego nie wystarczy wytłumaczyć tabu, choć samo to przydaje im siły.

Wszystkie trzy zachowania tabu krzywdzą zarówno całą społeczność open source, jak i same ofiary. Pośrednio szkodzą całej społeczności, obniżając szanse na wynagrodzenie za prezent czy produktywne postępowanie każdego potencjalnego uczestnika projektu.

Istotny jest fakt, że istnieją dwa różne wyjaśnienia tych trzech tabu. Po pierwsze, hackerzy często wyjaśniają antypatię do rozwidlania projektów marnotrawstwem wymaganej pracy w przyszłości, jeśli oba projekty miałyby ewoluować równolegle. Wyjaśniają również, że rozwidlanie dzieli społeczność programistów, przez co nad oboma projektami-dziećmi będzie pracowało mniej głów, niż nad projektem-rodzicem.

Jedna z osób komentujących esej zwróciła uwagę na fakt, że niezwykle rzadko zdarza się, by przetrwał więcej niż jeden potomek rozwidlenia, uzyskując po dłuższym czasie znaczący “udział w rynku”. Jest to kolejny bodziec wpływający na wzmocnienie współpracy ze strony wszystkich podgrup w projekcie i tendencje do unikania rozwidleń, ponieważ trudno przewidzieć kto przegra i czyja praca odejdzie w zapomnienie.

Niechęć do dystrybucji łat z trzeciej ręki wyjaśnia się mówiąc, że komplikują one znacznie system śledzenia błędów i dodają pracy opiekunom projektu, którzy i tak mają wystarczająco dużo pracy ze śledzeniem swoich własnych błędów. W wyjaśnieniach tych jest dużo prawdy; z pewnością potwierdzają one również rozumowanie Locke’a w związku z prawami własności. Jednak choć są atrakcyjne z intelektualnego punktu widzenia, nie potrafią wyjaśnić skąd się bierze tyle emocji i przejawów ochrony swojego terytorium w tych rzadkich momentach, kiedy tabu te są łamane lub choćby lekko naruszone – a odnosi się to nie tylko do samych pokrzywdzonych, lecz również zwykłych obserwatorów, którzy często reagują bardzo ostro. Zimna troska o powielanie pracy i dodatkowe obowiązki związane z prowadzeniem projektu niedostatecznie wyjaśniają tego typu zachowanie. Istnieje wreszcie trzecie tabu. Trudno wyjaśnić je czymś innym niż tylko gra o reputację. Co ciekawe, tabu to rzadko jest badane głębiej niż do momentu wyjaśnienia “To byłoby nieuczciwe”; faktem tym zajmiemy się w dalszej części tekstu.

Problem ego

Na początku eseju wspomniałem, że podświadoma wiedza o kulturze nijak ma się do świadomej ideologii. Jasnym dowodem tego stwierdzenia jest choćby powszechne przestrzeganie zwyczajów nakreślonych przez Locke’a, mimo że stoją one w jawnej sprzeczności z intencjami stojącymi u podstaw standardowych licencji.

Omawiając z hackerami grę o reputację zauważyłem inne interesujący przykład występowania tego zjawiska. Chodzi mianowicie o to, że wielu hackerów opierało się przeprowadzonej przeze mnie analizie wykazując dużą niechęć do przyznania, że czynnikiem motywującym ich postępowanie była chęć polepszenia reputacji, czy – jak to wtedy nieostrożnie nazwałem – “zaspokojenia ego”.

Fakt ten rzuca światło na kolejny interesujący aspekt kultury hackerskiej: nie ufa ona i gardzi egotyzmem oraz motywacją związaną z ego; promowanie własnej osoby spotyka się z bezlitosną krytyką, nawet jeśli społeczność jako całość mogła na niej zyskać. Doszło do tego, że “wielcy” i starsi w plemieniu kultury hackerskiej muszą łagodnie się wyrażać i za każdym razem z humorem pomniejszać swoją role, by nie utracić swojego statusu. Wyjaśnienia wymaga związek między tego typu postawą a strukturą bodźców, która w widoczny sposób opiera się w całości na ego.

W sporej części problem polega na tym, że nastawienie do ego w kulturze europejskiej i amerykańskiej jest raczej negatywne. Kulturowa matryca większości hackerów każe im uważać, że pragnienie zadowolenia ego jest złą (a przynajmniej niedojrzałą) motywacją, że ego jest w najlepszym przypadku tolerowane jedynie u primadonn, zaś najczęściej jest oznaką problemów osobowościowych. Akceptowane są jedynie subtelne i zakamuflowane formy, takie jak “reputacja”, “estyma”, “profesjonalizm” czy “duma z osiągniętych celów”.

Mógłbym napisać cały esej o niezdrowych korzeniach tej części naszego kulturowego dziedzictwa, jak również o zdumiewająco dużej krzywdzie, którą czynimy samym sobie oszukując się i wierząc (wbrew wszelkim dowodom, których dostarcza nam nasze zachowanie i psychologia), że w ogóle posiadamy coś takiego jak “nieegoistyczna motywacja”. I być może zrobiłbym to gdyby nie fakt, że Friedrich Wilhelm Nietzsche oraz Ayn Rand w kompetentny sposób wykonali dobrą pracę (bez względu na błędy, które popełnili) rozczłonkowując “altruizm” na niejawne formy interesowności.

Nie zajmujemy się jednak filozofią moralną ani psychologią, przedstawię więc tylko jeden pomniejszy rodzaj szkód, które wyrządza wiara w to, że ego jest złe – chodzi mianowicie o to, że wielu hackerom jest z tego powodu bardzo trudno świadomie zrozumieć społeczną dynamikę ich własnej kultury!

Nasz tok rozumowania nie kończy się w tym miejscu. Tabu zachowania w widoczny sposób motywowanego ego w otaczającej kulturze zostało tak wzmocnione w kulturze hackerskiej, że rodzi podejrzenie, iż spełnia jakąś funkcję adaptacyjną. Tabu to jest bowiem o wiele słabsze (a nawet nie istnieje w ogóle) wśród wielu innych kultur prezentu, takich jak kultury ludzi związanych z teatrem czy najbogatszych członków społeczeństwa.

Wartość skromności

Stwierdziwszy, iż prestiż odgrywa kluczową rolę w funkcjonowaniu mechanizmów nagradzania, spróbujemy zrozumieć, dlaczego mało kto przyznaje się do tego na wpół ukrytego faktu.

Porównanie z kulturą piratów może być bardzo pouczające: w kulturze tej nikt nie ukrywa zachowań mających na celu zdobycie reputacji i podwyższenie własnego statusu. Krakerzy oczekują uznania za udostępnienie “zero-day warez” (oprogramowania, którego zabezpieczenia zostały złamane tego samego dnia, w którym ukazała się oryginalna, zabezpieczona wersja), jednak niechętnie mówią, jak im się udało tego dokonać. Magicy ci nie lubią ujawniać swoich sztuczek. W rezultacie wiedza, będąca podstawą kultury krakerskiej jako całości rozwija się bardzo powoli. Z kolei w kulturze hackerskiej praca jest równocześnie wypowiedzią. Istnieje bardzo ścisła “zasługokracja” (najlepsze dzieło wygrywa) i silny etos głoszący, że jakość powinna (w zasadzie musi) mówić sama za siebie. Największą dumą jest kod, który “po prostu działa”, który może docenić każdy kompetentny programista. Dlatego wiedza w kulturze hackerskiej może rozwijać się bardzo szybko.

W ten sposób tabu odnoszące się do postaw motywowanych ego wpływa na rozwój produktywności. Jest to jednak pomniejszy skutek uboczny – bowiem bezpośrednio chroni się jakość informacji w systemie, w którym społeczność ocenia kod. Innymi słowy chwalenie się i odgrywanie ważnej osoby jest neutralizowane, traktowane jak szum zagłuszający istotne sygnały wypływające z eksperymentów dokonywanych w atmosferze twórczej współpracy.

Z bardzo podobnych powodów nie praktykuje się ataku na autora, lecz na jego kod. Zwróćmy uwagę na pewien subtelny fakt, potwierdzający ten pogląd: mianowicie hackerzy uwielbiają się spierać prowadząc ideologiczne wojny i dyskutując o osobistych różnicach, jednak nie słyszy się, by hacker publicznie zaatakował kompetencje innego hackera jeśli chodzi o kompetencje techniczne (nawet prywatna krytyka jest czymś rzadkim i bardzo delikatnym). Polowanie na błędy i krytyka zawsze dotyczą projektu, nigdy osoby.

Co więcej, programiście nie wypomina się błędów przeszłości – naprawienie błędu uważa się ważniejsze od jego pojawienia się. Jak zauważyła jedna z osób komentujących esej, można uzyskać wyższy status naprawiając “błędy w Emacsie” a nie “błędy Richarda Stallmana”; co więcej – krytykowanie Stallmana za błędy w Emacsie, które już dawno zostały naprawione, byłoby czymś bardzo złym.

Warto w tym miejscu uczynić interesujące porównanie z kręgami akademickimi, w których ważną metodą uzyskiwania reputacji jest zmasowana krytyka prac innych naukowców, które uważa się za błędne. W kulturze hackerskiej tego typu zachowania okryte są sporym tabu, i to taki, że brak tego typu zachowań dostrzegłem dopiero w chwili, kiedy posiadający niezwykłą perspektywę czytelnik tego eseju uzmysłowił mi ten fakt – a nastąpiło to okrągły rok po publikacji!

Tabu dotyczące atakowania czyichś kompetencji (którego nie posiadają kręgi akademickie) ukazuje więcej, niż tabu dotyczące motywacji ego (które kręgi akademickie posiadają), ponieważ możemy ujrzeć związek między nim, a różnicami w komunikacji i strukturach leżących u podstaw kultury hackerskiej i akademickiej.

Medium przekazywania prezentów w kulturze hackerskiej raczej nie jest czymś namacalnym; jej kanały komunikacyjne słabo nadają się do wyrażania emocjonalnych zawiłości, zaś osobisty kontakt miedzy członkami tej kultury jest czymś wyjątkowym. Dlatego też tolerancja szum jest niższa niż w większości innych kultur prezentu i wiele mówi o tabu okrywającym ataki na kompetencje. jakikolwiek incydent kłótni dotyczącej kompetencji hackerów z pewnością ujemnie wpłynąłby na punktowanie reputacji kultury hackerskiej.

Łagodne odnoszenie się do innych jest również istotne jeśli chce się utrzymać udany projekt; należy przekonać społeczność, że posiada się dobry osąd, ponieważ większość pracy opiekun pakietu polega na ocenianiu kodu innych. Kto przesyłałby rezultaty swojej pracy komuś, kto w widoczny sposób nie potrafi ocenić jakości swojego własnego kodu, kogo zachowanie sugeruje, że będzie próbował zagarnąć dla siebie reputacje płynącą z projektu? Potencjalni uczestnicy projektu chcą liderów o wystarczającej skromności i klasie, by – kiedy trzeba – rzec: “Tak, twój kod działa lepiej niż moja wersja, wykorzystam go” – i udokumentować to w odpowiednim miejscu.

Wrażliwość na szum tłumaczy również wymóg publicznej skromności, dotyczący starszych w plemionach kultury hackerskiej. Muszą oni być postrzegani jako ludzie pozbawieni pychy i pozy, by utrzymać tabu związane z niebezpiecznym szumem.

Jest jeszcze inny powód skromnego zachowania: mianowicie w świecie open source rzadko ma się wrażenie, że projekt został “zakończony”, mogłoby to bowiem u potencjalnych uczestników projektu wywołać uczucie, iż są niepotrzebni. Aby uzyskać maksimum z projektu, należy skromnie się wyrażać o stanie jego zaawansowania. Jeśli ktoś przejrzawszy kod powie: “No nieźle – brakuje x,y i z, więc to nie może być dobry program”, często wkrótce potem pojawiają się łaty dodające obsługę x,y i z.

Osobiście zaobserwowałem również, że skromne zachowanie niektórych głównych hackerów wypływa ze szczerej (i usprawiedliwionej) obawy przed staniem się obiektem kultu osobowości. Zarówno Linus Torvalds jak i Larry Wall wielokrotnie okazywali przykłady takiego zachowania. Wybrawszy się kiedyś na obiad z Larry Wallem, zażartowałem: “Ty jesteś superhackerem – do Ciebie więc należy wybór restauracji”, na co on głośno zaprotestował. I słusznie – wiele społeczności upadło, ponieważ nie potrafiło odróżnić dzielonych przez siebie wartości od osobowości swoich liderów. Larry i Linus nie mogli być tego nieświadomi. Z drugiej strony wielu hackerów wiele by dało, by mieć problem Larry’ego – gdyby tylko zechcieli się do tego przyznać.

Globalne implikacje modelu gry o reputację

Analiza gry o reputację zawiera w sobie więcej implikacji, które mogą nie być widoczne na pierwszy rzut oka. Wiele z nich ma swoje źródło w tym, że więcej zyskuje się zakładając udany projekt niż uczestnicząc w istniejącym. Więcej zyskuje się również z projektów uderzająco nowatorskich, niż ze stopniowych usprawnień istniejącego oprogramowania (“ja też!”). Z drugiej strony program, którego nie rozumie lub nie potrzebuje nikt poza autorem jest niewypałem w grze o reputację; często łatwiej jest zwrócić na siebie uwagę udzielając się w istniejącym projekcie niż sprawić, by inni zauważyli nowy projekt. Co więcej, trudniej jest współzawodniczyć z udanym projektem niż wypełnić pustą niszę.

Istnieje więc odpowiednia odległość między danym projektem a sąsiadami (najbardziej podobnymi projektami): zbyt blisko, a projekt stanie się marnym prezentem o ograniczonej wartości, typu “ja też!” (lepiej byłoby pomóc istniejącemu projektowi); zbyt daleko, a nikt nie będzie mógł używać, zrozumieć, ani nawet docenić istoty włożonego weń wysiłku (i w tym przypadku prezent jest kiepski). Dzięki temu powstaje wzorzec zagospodarowywania noosfery, który przywodzi na myśl osadników rozprzestrzeniających się i tworzących fizyczne granice, przy czym ruch ten nie jest chaotyczny, lecz przypomina fraktal o ograniczonej dyfuzji. Projekty mają tendencje do wypełniania przestrzeni funkcjonalnych w pobliżu granic z innymi projektami.

Niektóre projekty, którym się powiodło, mogą stać się przebojami w swojej kategorii; nikt nie chce zagospodarowywać przestrzeni w pobliżu nich, ponieważ zbyt trudno byłoby współzawodniczyć o uwagę hackerów z uformowana już grupą. Dlatego ludzie, którzy mogliby rozpocząć własne projekty pracują nad rozszerzeniami do owych wielkich, udanych projektów. Klasycznym przykładem przeboju w swojej kategorii jest GNU Emacs; jego odmiany wypełniają niszę ekologiczną w pełni programowalnych edytorów do tego stopnia, że od wczesnych lat osiemdziesiątych żaden z konkurentów nie opuścił stadium “projektu jednego programisty”, programiści tworzą za to różne tryby Emacsa.

Ogólnie rzecz biorąc obie te tendencje (wypełnianie nisz oraz tworzenie przebojowych programów) zapoczątkowały regularny trend jeśli chodzi o powstawanie projektów. W latach siedemdziesiątych większość oprogramowania open source była zabawkami lub wersjami demonstracyjnymi. W latach osiemdziesiątych nastąpił zwrot w kierunku narzędzi programistycznych i internetowych, zaś w latach dziewięćdziesiątych – w stronę systemów operacyjnych. Za każdym razem podejmowano rozwiązywanie problemów o wyższym poziomie trudności, kiedy wyczerpano już niemal wszystkie możliwości niższego poziomu.

Z tego trendu wypływają interesujące wnioski jeśli chodzi o naszą najbliższa przyszłość. Na początku 1998 roku, Linux wyglądał jak przebój w swojej kategorii, w niszy “systemów operacyjnych open source” – ludzie, którzy mogliby zacząć pisać alternatywne systemy operacyjne, obecnie piszą sterowniki i rozszerzenia do Linuksa. Istnieje też większość narzędzi niższego poziomu, które kultura mogła sobie wymarzyć jako open source. Co w takim razie zostało?

Aplikacje. W miarę, jak zbliża się rok 2000, można bezpiecznie przepowiedzieć, że wysiłki włożone w rozwój oprogramowania open source będą coraz bardziej przemieszczać się w stronę ostatniego dziewiczego terytorium – programów dla osób spoza kręgów technicznych. Widoczna wskazówka tej zmiany jest z pewnością GIMP (http://www.gimp.org), warsztat obróbki obrazu przypominający Photoshopa, będący pierwszą główna aplikacją open source posiadającą interfejs użytkownika GUI uważany za obowiązkowy w aplikacjach komercyjnych utworzonych w ciągu ostatniej dekady. Innym przykładem jest natężenie hałasu otaczającego projekty aplikacyjno-narzędziowe, takie jak KDE (http://www.kde.org) czy GNOME (http://www.gnome.org).

Jedna z osób komentujących ten esej zauważyła, że analogia zagospodarowywania noosfery wyjaśnia również dlaczego hackerzy reagują z tak gwałtowna złością na politykę “przejmowania i rozbudowywania” Microsoftu, czyli dodawania złożoności i zamykania protokołów internetowych. Kultura hackerska może współistnieć z większością zamkniętego oprogramowania; istnienie Adobe Photoshopa nie czyni terytorium w pobliżu GIMP-a (jego odpowiednika open source) znacząco mniej atrakcyjnym. Jeśli jednak Microsoftowi uda się dokonać “wyłączenia z obrotu handlowego” [12] danego protokołu w taki sposób, że tylko Microsoftowi programiści będą mogli pisać dla niego oprogramowanie, konsekwencją będzie nie tylko krzywda wyrządzona użytkownikom, płynąca z umacniania monopolu. W ten sposób zmniejsza się bowiem ilość jakości dostępnej dla hackerów w noosferze – jakości, którą mogliby zagospodarować i rozwijać. Nie dziwi więc fakt, że hackerzy często nazywają strategie Microsoftu “zanieczyszczaniem protokołów”: reagują dokładnie jak rolnicy, którzy zauważyli, że ktoś zatruwa wodę, którą podlewają plony!

Gra o reputację wyjaśnia również często cytowane powiedzenie: “Nie można zostać hackerem nazywając siebie hackerem; jest się hackerem dopiero wtedy, kiedy zostanie się tak nazwanym przez innych hackerów”. W tym świetle “hacker” to ktoś, kto (rozdając prezenty) zademonstrował, że posiada umiejętności techniczne i rozumie funkcjonowanie gry o reputację. Tego typu osąd zależy w dużym stopniu od świadomości i zakorzenienia w kulturze, a wydać go mogą jedynie ci, którzy stali się częścią tej kultury.

Jaką wartość ma prezent?
Istnieją pewne ustalone wzorce związane z oceną wkładu danej osoby przez kulturę hackerską i obdarzeniem reputacją w zamian. Nietrudno zauważyć następujące prawidłowości:

1. Jeśli program nie działa tak dobrze, jak zasugerowano, nie jest dobry — bez względu na to, jak by nie był dobry i oryginalny. Zwróćmy uwagę na “zasugerowano”. Powyższa zasada nie wymaga doskonałości; oprogramowanie eksperymentalne i wersje beta mogą zawierać błędy. Oczekuje się natomiast, że użytkownik będzie potrafił ocenić ryzyko na podstawie opisu fazy projektu i wypowiedzi deweloperów. U podstaw tej reguły leży fakt, że oprogramowanie open source zwykle przez długi czas znajduje się w fazie beta, zaś wersja 1.0 nie pojawia się, dopóki programiści nie będą pewni, że użytkownikowi nie przytrafi się wiele przykrych niespodzianek. W świecie zamkniętych źródeł wersja 1.0 oznacza “Jeśli jesteś ostrożny, nie dotykaj”; w świecie open source, ten sam numer wersji mówi “Programiści gwarantują działanie programu swoją reputacją”.

2. Praca, która poszerza noosferę jest lepsza od tej, która powiela istniejący fragment funkcjonalnego terytorium. Powyższe można by sformułować w naiwny sposób: Oryginalna praca jest lepsza od powielania funkcji istniejącego oprogramowania. Nie jest to jednak takie proste. Powielanie funkcjonalności istniejącego zamkniętego oprogramowania liczy się tak, jak oryginalna praca, jeśli dzięki temu otwiera się zamknięty protokół lub format i udostępnia nowe terytoria. Dlatego też jednym z najbardziej prestiżowych projektów w obecnym świecie open source jest Samba – kod pozwalający komputerom uniksowym spełniać funkcją klienta lub serwera korzystającego z zamkniętego protokołu współdzielenia plików Microsoftu, SMB. Nie ma tu wiele miejsca na pracę twórczą – chodzi głównie o prawidłowe działanie szczegółów, które uzyskało się deasemblując kod. Mimo to członków grupy rozwijającej Sambę uważa się za bohaterów, ponieważ neutralizują oni wysiłki Microsoftu mające na celu zamknięcie całych populacji użytkowników i odcięcie dużego fragmentu noosfery.

3. Projekt, któremu uda się znaleźć w jednej z głównych dystrybucji, jest lepszy od tego, któremu się to nie uda. Praca wykonywana we wszystkich głównych dystrybucjach jest uważana za najbardziej prestiżową. Główne dystrybucje to nie tylko duże dystrybucje Linuksa, takie jak Red Hat, Debian, Caldera czy SuSE, lecz również inne zbiory oprogramowania posiadające własną reputację, która jest certyfikatem jakości – np. dystrybucje BSD czy kolekcje źródeł Free Software Foundation.

4. Wykorzystanie jest najbardziej szczerą formą pochlebstwa, zaś liderzy w danej kategorii mają większą wartość niż pozostali. Zaufanie do osądu innych ma podstawowe znaczenie dla procesu oceny programu przez społeczność. jest ono niezbędne, ponieważ nikt nie ma czasu badać wszystkich możliwych alternatyw. Dlatego program używany przez wielu uważa się za lepszy od tego, którego używa niewiele osób… Dlatego też program wykonany tak dobrze, że nikomu nie chce się korzystać z alternatywnych rozwiązań, cieszy się największym prestiżem. Najwięcej prestiżu pochodzi z wykonania popularnego, oryginalnego programu, będącego liderem w swojej dziedzinie i zawartego we wszystkich większych dystrybucjach. Ludzi, którym udało się to więcej niż raz, nazywa się czasem pół żartem “półbogami”.

5. Ciągłe poświęcenie ciężkiej, nużącej pracy (takiej jak odpluskwianie czy pisanie dokumentacji) jest godna większego uznania niż radosna zabawa i łatwe programistyczne sztuczki. Powyższa zasada ilustruje nagradzanie zadań, które wydają się hackerom mniej atrakcyjne. Do pewnego stopnia przeczy jej inna reguła:

6. Nietrywialne rozszerzenia funkcjonalności są lepsze od niskopoziomowych łat i odpluskwiania. Jest tak prawdopodobnie dlatego, że jednorazowe dodanie funkcjonalności jest nagradzane bardziej niż naprawienie błędu, chyba że błąd ten jest tak poważny lub subtelny, że wyśledzenie go samo w sobie ukaże niezwykłą zręczność i umiejętności hackera. Jeśli jednak działania te rozkładają się w czasie, wtedy ktoś, kto przez długi czas zwracał uwagę i tropił nawet zwykłe błędy, może cieszyć się większą reputacja niż ktoś, kto włożył podobny wysiłek w dodawanie łatwej funkcjonalności.

Jedna z osób komentujących ten tekst zwróciła moja uwagę na fakt, że zasady te przeplatają się w interesujący sposób, zaś najwyższa użyteczność nie zawsze jest najwyżej nagradzana. Jeśli zapytamy hackera, czy uzyska większy rozgłos pisząc nowe narzędzie czy dodatki do narzędzia kogoś innego, z pewnością odpowie “nowe narzędzie”. Jeśli jednak zapytamy o wybór między (a) nowym narzędziem, używanym tylko kilka razy dziennie przez system operacyjny w sposób niewidoczny dla użytkownika, jednak szybko wychodzi na pozycje lidera w swojej kategorii, a (b) wieloma rozszerzeniami funkcjonalności istniejącego narzędzia, które nie są ani zbyt oryginalne, ani nie należą do liderów w swojej kategorii, ale używa się ich na co dzień i są widoczne dla dużej liczby użytkowników. Prawdopodobnie zauważymy pewne wahanie przed udzieleniem odpowiedzi (a). Obie możliwości oferują mniej więcej taką samą nagrodę.

Wspomniana osoba odniosła to do mojego przypadku dodając: “Przypadek (a) to fetchmail, przypadek (b) to twoje rozszerzenia do Emacsa, takie jak vc.el czy gud.el”. I rzeczywiście miała rację: bardziej prawdopodobne jest, że ludzie nazwą mnie “autorem fetchmaila” niż “autorem mnóstwa trybów Emacsa”, chociaż w ogólnym rozrachunku te ostatnie były prawdopodobnie bardziej użyteczne. Dzieje się tak prawdopodobnie dlatego, że praca z “nową marką” jest bardziej widoczna niż praca nad istniejącą “marką”. Ciekawym tematem zasługującym na dalsze badania byłoby dalsze wyjaśnienie tych reguł i zbadanie płynących z nich wniosków dotyczących systemu punktowego kultury hackerskiej.

Noosferyczna wartość i etologia terytorium

W zrozumieniu przyczyn i konsekwencji zwyczajów opisanych przez Locke’a pomóc nam może spojrzenie z jeszcze innego punktu widzenia: etologii zwierzęcej, a szczególnie etologii terytorium. Własność jest pojęciem ogólnym związanym z terytorium zwierząt, które powstało w wyniku ewolucji jaki środek służący redukcji przemocy miedzy osobnikami tego samego gatunku. Wilk, oznaczając granice swojego terytorium i szanując przestrzeń innych, zmniejsza szanse zaistnienia walki, która mogłaby go zabić lub osłabić i zmniejszyć jego szanse reprodukcji. Rolą własności w społeczeństwie ludzkim jest zapobieganie konfliktom poprzez wyznaczenie granic, które czynią wyraźne rozgraniczenie między pokojowymi formami zachowania a agresją.

W pewnych kręgach modne jest przedstawianie własności jako arbitralnej konwencji społecznej, jest to jednak całkowicie błędny pogląd. Każdy, kto kiedykolwiek posiadał psa szczekającego na przechodniów znajdujących się w pobliżu posiadłości jego pana, doświadczył fundamentalnej ciągłości między przywiązaniem zwierząt do swojego terytorium a własnością u ludzi. Domowi kuzyni wilków wiedzą instynktownie, że własność nie jest zwykłą konwencją społeczną czy grą, lecz istotnym mechanizmem wykształconym w procesie ewolucji, pozwalającym uniknąć przemocy. (Dzięki temu są mądrzejsze od wielu teoretyków politycznych). Roszczenie sobie prawa do posiadania (np. oznaczanie terytorium) jest aktem spełniającym pewną funkcję, przez który określa się, jakich granic będzie się bronić. Poparcie tych roszczeń przez społeczność pozwala zminimalizować tarcia i stworzyć jak najlepsze warunki do współpracy. Zasady te sprawdzają się bez względu na poziom abstrakcji owych roszczeń – zamiast ogrodzenia i szczekania psa może to być choćby nazwisko opiekuna pakietu w pliku README. Tak czy inaczej jest to wyraz roszczeń terytorialnych i (jak inne formy własności) opiera się na instynktach związanych z posiadaniem terytorium, które rozwinęły się by pomóc w rozwiązywaniu konfliktów.

Na pierwszy rzut oka analiza etologiczna może wydać się czymś abstrakcyjnym, czymś, co trudno odnieść to zachowania hackerów. Płynie z niej jednak kilka wniosków: pierwszy wyjaśnia popularność World Wide Web oraz fakt, że projekty open source posiadające strony WWW wydają się bardziej “rzeczywiste” i substancjalne niż te, które ich nie posiadają.

Jeśli spróbujemy rozważyć tą kwestię obiektywnie, będzie nam to trudno wyjaśnić. Wysiłek włożony w stworzenie strony WWW jest niewielki w porównaniu z napisaniem i utrzymywaniem choć małego programu, trudno więc uważać stronę WWW za dowód na istnienie czegoś namacalnego czy nadzwyczajnego wysiłku. Trudno to również wyjaśnić funkcjonowaniem WWW jako takim, bowiem funkcje komunikacyjne strony WWW może równie dobrze (a nawet lepiej) spełniać połączenie serwera ftp, listy dyskusyjnej i grup dyskusyjnych. Tak czy inaczej komunikacja w ramach projektu odbywa się raczej poprzez listy i grupy dyskusyjne, a nie WWW. Skąd więc ta popularność stron internetowych w roli “domostw” projektów?

W uzyskaniu odpowiedzi na to pytanie może nam pomóc przenośnia zawarta w terminie “strona domowa”. Chociaż założenie projektu open source jest roszczeniem prawa do posiadania fragmentu noosfery (które zwyczajowo jest uznawane), na poziomie psychologicznym nie jest ono niczym zobowiązującym – było nie było, oprogramowanie nie posiada przypisanego mu miejsca i można je w każdej chwili powielić. Skojarzenie oprogramowania z pojęciami takimi jak “terytorium” czy “własność” wymaga pewnego wysiłku. Strona domowa projektu jest konkretny przejawem abstrakcyjnego zagospodarowywania przestrzeni możliwych programów, jako że przedstawia “domowe” terytorium w bardziej zorganizowanej przestrzennie sferze światowej pajęczyny. Zejście z noosfery do “cyberprzestrzeni” nie przeniosło nas co prawda do prawdziwego świata pełnego ogrodzeń i szczekających psów, jednakże pozwoliło nam pewniej sformułować teorię dotyczącą roszczeń do własności na poziomie abstrakcyjnym na gruncie rozważań o terytorium. I właśnie dlatego projekty posiadające swoje strony WWW wydają się bardziej “rzeczywiste”.

Prawdziwość tej tezy potwierdzają hiperłącza i istnienie dobrych wyszukiwarek internetowych. Projekt posiadający stronę domową ma większe szanse zauważenia przez kogoś, kto będzie badał jego sąsiedztwo w noosferze; inni zamieszcza na swoich stronach odnośniki do niego, będzie można go znaleźć w wyszukiwarkach… Strona WWW jest więc lepszą reklamą, skuteczniejszym aktem wykonawczym, silniej wyrażonym roszczeniem do terytorium. Analiza etologiczna zachęca nas również do bliższego przyjrzenia się mechanizmom radzenia sobie z konfliktami w kulturze open source. Możemy się domyślać, że zwyczaje odnoszące się do posiadania nie tylko rozwijają bodźce związane z reputacją, odgrywają bowiem również pewną rolę w zapobieganiu i rozwiązywaniu konfliktów.

Przyczyny konfliktów

Rozważając konflikty w świecie open source możemy wyróżnić cztery główne kwestie:

• Kto ma prawo podejmować wiążące decyzje dotyczące projektu?
• Kto i za co jest chwalony lub oskarżany?
• Jak zredukować powielanie wysiłku i zapobiec rozpowszechnianiu nieautoryzowanych łat, komplikujących proces śledzenia błędów?
• Co – z technicznego punktu widzenia – jest Właściwe?

Jeśli jednak ponownie przyjrzymy się pytaniu “Co jest Właściwe”, być może okaże się, że nie ma ono silnych podstaw. Jeśli chodzi o pytania tego typu, to albo istnieje jakieś obiektywne kryterium pozwalające zadecydować wszystkim zainteresowanym, albo nie. Jeśli jest, następuje koniec gry i wszyscy wygrywają. Jeśli nie, pytanie sprowadza się do “kto decyduje?”.

Dlatego też istnieją trzy problemy, które powinna rozwiązać nasza teoria rozwiązywania konfliktów: (a) na kogo spada podejmowanie decyzji projektowych, (b) jak zdecydować czyj wkład jest nagradzany i jak, oraz (c) jak zapobiec rozszczepieniu się grupy projektowej i samego produktu na rozgałęzienia. Rola własności w rozwiązywaniu kwestii (a) i (c) jest jasna. Zwyczaje potwierdzają, że to właściciele projektu podejmują wiążące decyzje. Wcześniej zaobserwowaliśmy, że zwyczaje te sprzeciwiają się rozwidlaniu projektu, które powoduje rozdrobnienie własności.

Warto zauważyć, że zwyczaje te mają sens nawet jeśli pominie się grę o reputację i przyjmie się czysto “rzemieślniczy” punkt widzenia na kulturę hakerską. Zgodnie z tym poglądem wspomniane zwyczaje mają większy związek z ochroną praw rzemieślnika do realizacji własnej wizji niż z rozdrabnianiem reputacji. Model “rzemieślniczy” nie wystarcza jednak do wyjaśnienia zwyczajów hackerskich dotyczących (b) – kto jest za co nagradzany, ponieważ osoba będąca wyłącznie rzemieślnikiem, którą nie obchodzi gra o reputację, nie dba o tego typu rzeczy. Tak więc by przeprowadzić dalszą analizę, musimy jeszcze bardziej rozciągnąć teorię Locke’a i zbadać konflikty oraz funkcjonowanie praw własności w ramach projektów, jak również w relacjach między nimi.

Własność i struktura projektu

Najbardziej trywialny jest przypadek, kiedy projekt ma jednego właściciela czy opiekuna. W tym wypadku konflikt nie może powstać, ponieważ właściciel podejmuje wszystkie decyzje, zbiera wszystkie pochwały i krytykę. Jedyny możliwy konflikt może dotyczyć sukcesji: kwestii nowego właściciela, który może się pojawić, kiedy stary właściciel zniknie lub straci zainteresowanie projektem. Również społeczność ma pewien interes w (c) niedopuszczeniu do rozwidlenia projektu. Interes ten przejawia się w zwyczaju, według którego właściciel czy opiekun powinien publicznie przekazać tytuł innej osobie jeśli nie jest już w stanie opiekować się projektem.

Jeśli chodzi o nietrywialne przypadki, najprostszym będzie projekt, który skupia wielu opiekunów wokół jednego “łagodnego dyktatora” i równocześnie właściciela projektu. Zwyczajowo jest to preferowany model grupowego rozwoju projektów; sprawdził się w tak dużych projektach jak jądro Linuksa czy Emacs i nie gorzej niż inne modele radzi sobie z problemem “kto decyduje”. Zazwyczaj grupa skupiona wokół “łagodnego dyktatora” powstaje w wyniku ewolucji z jednoosobowego projektu, w miarę jak założyciel przyciąga deweloperów. Nawet jeśli właściciel pozostaje dyktatorem, model ten wprowadza nowy poziom dyskusji odnośnie przyznawania zasług za różne części projektu. W tej sytuacji zwyczaj nakazuje właścicielowi-dyktatorowi uczciwie informować o wkładzie pozostałych uczestników projektu (np. wspominając o nim w pliku README czy plikach historii). Jeśli rozpatrzymy tę kwestię biorąc pod uwagę model własności Locke’a, zauważymy, że jest to konsekwencją faktu, iż wnosząc swój wkład w rozwój projektu, gromadzimy płynącą z niego reputację (jak i krytykę).

Podążając tym tropem możemy zauważyć, że “łagodny dyktator” nie jest w rzeczywistości absolutnym właścicielem całego projektu. Chociaż posiada prawo do podejmowania wiążących decyzji, to jednak wymienił część udziałów z puli reputacji przypadającej na projekt na pracę innych programistów. Trudno nie dostrzec analogii do dzielenia się zbiorami w gospodarstwie rolnym, tyle tylko, że nazwisko osoby wnoszącej swój wkład pozostaje w odpowiednim pliku i wciąż do pewnego stopnia “zarabia”, nawet jeśli nie jest już ona aktywna.

W miarę jak projekty posiadające łagodnego dyktatora gromadzą coraz więcej uczestników, zazwyczaj formują się dwie warstwy: warstwa osób stale pracujących nad projektem oraz tych, którzy od czasu do czasu wniosą coś do projektu. Osobą stale pracującą nad projektem zostaje się zazwyczaj przez przejęcie odpowiedzialności za jedną z głównych części programu. Można też przejąć rolę “mistrza odpluskwiacza”, która polega na naprawianiu wielu błędów. Tego typu osoby stale poświęcają znaczącą część swojego czasu projektowi.

W naszych dalszych rozważaniach zajmiemy się zwłaszcza rolą osoby odpowiedzialnej za jedną z głównych części projektu. Hackerzy zwykli mawiać “władza przychodzi wraz z odpowiedzialności”. Deweloper, który przejął odpowiedzialność za dany podsystem, zazwyczaj kontroluje zarówno jego implementację jak i interfejsy łączące go z resztą projektu, które może poprawiać jedynie lider projektu (pełniący funkcję architekta). Możemy zauważyć, że reguła ta tworzy zamknięte posesje wewnątrz projektu jeśli przyjąć model Locke’a, zaś jej rola – tak jak i innych reguł wyznaczających granice – polega na zapobieganiu konfliktom.

Zwyczajowo “dyktator” czy lider w tego typu projekcie powinien konsultować kluczowe decyzje z osobami odpowiedzialnymi za główne jego części. Tyczy się to zwłaszcza decyzji dotyczących podsystemu “należącego” do danego dewelopera (czyli takiego, w który zainwestował swój czas i za który wziął odpowiedzialność). Mądry lider, który uznaje wewnętrzne granice własności w projekcie, nie wkracza bez powodu na teren właściciela podsystemu ani nie podważa jego decyzji. Niektóre duże projekty całkowicie odrzucają model “łagodnego dyktatora”. Jednym wyjściem jest uformowanie z osób opiekujących się podsystemami komitetu deweloperów z prawem głosu (tak jak w projekcie Apache). Innym jest zmieniająca się dyktatura, przekazywana z ręce na ręce w zamkniętym kręgu deweloperów – w ten sposób funkcjonuje zespół tworzący Perla.

Powszechnie uważa się tego typu skomplikowane ustalenia za niestabilne i trudne. Trudność zależy głównie od ryzyka towarzyszącemu “komitetowemu projektowaniu” i od samych komitetów – są to problemy, których kultura hackerska jest świadoma i rozumie je. Ja jednak odczuwam głęboki wewnętrzny niepokój myśląc o komitetach czy przekazywaniu przewodnictwa, ponieważ trudno wpasować je do podświadomego modelu Locke’a, z którego hackerzy korzystają myśląc o prostszych przypadkach. W tego typu złożonych organizmach rozliczyć kogoś z posiadania w sensie kontroli czy korzyści płynących z reputacji. Trudno stwierdzić, gdzie znajdują się wewnętrzne granice i trudno uniknąć konfliktu, chyba że członkowie grupy żywią do siebie wyjątkowo duże zaufanie i panuje wśród nich duża harmonia.

Konflikty i ich rozwiązywanie

Zauważyliśmy już, że rosnąca złożoność związana z pełnieniem ról w projekcie znajduje swój wyraz w rozproszeniu władzy dotyczącej decyzji projektowych i dzielonych prawach własności. I choć jest to wydajny system propagowania bodźców motywujących do rozwijania projektu, jednocześnie rozprasza on władzę lidera projektu, a przede wszystkim zmniejsza jego władzę tłumienia konfliktów w zarodku. Mogłoby się wydawać, że najbardziej oczywistą przyczyną konfliktów powinny być spory dotyczące spraw technicznych; rzadko jednak powodują one poważniejsze kłótnie. Zazwyczaj łatwo je rozwiązać stosując terytorialną zasadę “władza przychodzi wraz z odpowiedzialnością”.

Inna zasada pomagając a rozwiązywać konflikty to zasada starszeństwa: jeśli między dwoma uczestnikami lub grupami uczestników projektu pojawia się problem, którego nie można obiektywnie rozwiązać i żadna ze stron nie jest właścicielem terenu, o który toczy się spór, wygrywa ten, kto włożył najwięcej pracy w projekt jako całość (a tym samym posiada większe prawa własności do projektu). (Tak więc strona, której uczestnicy mniej zainwestowali w projekt, przegrywa. Interesujący jest fakt, że obowiązująca tu heurystyka do złudzenia przypomina rozwiązywanie sytuacji patowych w wielu systemach relacyjnych baz danych. Kiedy dwa wątki równocześnie odwołują się do tego samego zasobu, wątek, który najmniej zainwestował w bieżącą transakcję zostaje naznaczony jako ofiara i unicestwiony, przez co zwyciężają zazwyczaj najdłużej uruchomione czyli najstarsze transakcje.)

Wymienione wyżej zasady pozwalają rozwiązać większość problemów, resztę załatwia zwykle wypowiedź lidera projektu. Rzadko zdarzają się dysputy, którym uda się przejść przez oba te filtry. Zazwyczaj konflikty nie są niczym poważnym, chyba że obydwa wymienione kryteria (“wraz z odpowiedzialnością pojawia się władza” oraz “starszeństwo ma pierwszeństwo”) prezentują odmienne stanowiska, zaś autorytet lidera projektu jest niewielki lub nie ma go w ogóle. Najbardziej oczywistym przypadkiem jest dyskusja mająca miejsce po zniknięciu lidera projektu. Uczestniczyłem w jednej z takich potyczek – była wstrętna, bolesna i długa; skończyła się dopiero wtedy, kiedy wszystkie strony konfliktu były na tyle wyczerpane, by przekazać kontrolę nad projektem osobie z zewnątrz. Mam wielką nadzieję, że już nigdy nie znajdę się w pobliżu czegoś podobnego.

Na zakończenie warto zauważyć, że wszystkie mechanizmy rozwiązywania konfliktów opierają się na woli szeroko rozumianej społeczności hackerskiej do wprowadzania ich w życie. Jedyne dostępne mechanizmy to gorące kłótnie (flames) i ignorowanie; innymi słowy – publiczne potępienie osób łamiących zwyczaje i późniejsza odmowa współpracy z nimi.

Mechanizmy wprowadzające w kulturę hackerską i związki ze środowiskami akademickimi

Wcześniejsza wersja tego eseju zawierała następujące pytanie: w jaki sposób społeczność informuje i instruuje swoich członków o panujących w niej zwyczajach? Czy te zwyczaje są oczywiste, czy może formują się na poziomie podświadomości – a może są przekazywane za pomocą przykładu czy bezpośrednich wyjaśnień? Bezpośrednie wyjaśnienia należą z pewnością do rzadkości choćby z tego powodu, że do tej pory powstało niewiele opisów norm obowiązujących w społeczności hackerskiej.

Wiele z nich jest przekazywanych za pomocą przykładu. Weźmy bardzo prosty przykład: istnieje reguła mówiąca, że każdy pakiet z oprogramowaniem powinien zawierać plik README lub READ.ME, zawierający wyjaśnienia z którymi należy się zapoznać przed przejrzeniem reszty pakietu. Zwyczaj ten był w użyciu co najmniej od początku lat osiemdziesiątych; od czasu do czasu pojawiał się nawet w pisanej formie. Zwykle jednak autorzy zamieszczają w pakiecie plik README ponieważ zauważyli go w wielu innych pakietach.

Z drugiej strony wiele zwyczajów hackerskich formuje się samoistnie w chwili, kiedy (nawet podświadomie) zaczyna się rozumieć podstawowe zasady gry o reputację. Większości hakerów nikt nigdy nie nauczył trzech tabu, które wymieniłem wcześniej w tym eseju, a przynajmniej gdyby ich zapytać odpowiedzieliby, że zasady te są oczywiste i nie stanowią części żadnego przekazu. Warto się bliżej przyjrzeć temu zjawisku – być może uda nam się go wyjaśnić badając proces pozyskiwania przez hackerów wiedzy o swojej kulturze.

W wielu kulturach istnieją ukryte wskazówki (a dokładniej “tajemnice” w religijno-mistycznym sensie), które funkcjonują jako mechanizmy pozwalające wniknąć w daną kulturę – są to tajemnice nie zdradzane osobom trzecim: potencjalny członek społeczności powinien odkryć je sam. Aby zostać zaakceptowanym, należy wykazać, że rozumie się tajemnicę, odkrytą w sposób zaakceptowany przez kulturę.

W kulturze hackerskiej zazwyczaj często i celowo używa się tego typu niejawnych wskazówek i testów. Mechanizm ten działa na co najmniej trzech poziomach:

• Sekrety przypominające hasła. Można tu podać przykład grupy dyskusyjnej alt.sysadmin.recovery, której sekret bardzo rzuca się w oczy. Nie można wysłać listu na tę grupę nie znając owego sekretu; jeśli go się pozna, jest się uznanym za osobę mogącą wysyłać listy. Wśród stałych dyskutantów istnieje bardzo silne tabu dotyczące ujawniania tego sekretu.
• Wymóg inicjacji w pewne misteria techniczne. Aby móc rozdawać wartościowe prezenty, trzeba wchłonąć sporo wiedzy technicznej (np. trzeba znać przynajmniej jeden z trzech głównych języków programowania). Wymóg ten funkcjonuje na większą skalę analogicznie do poprzedniego: jest to filtr dotyczący pewnych właściwości (np. zdolności do abstrakcyjnego myślenia, wytrwałości i giętkości umysłu), które musi się posiadać chcąc być członkiem społeczności.
• Sekrety będące częścią kontekstu społecznego. Proces stawania się częścią kultury następuje w wyniku uczestniczenia w projektach. Każdy projekt stanowi żywy kontekst społeczny, który przyszły uczestnik musi zbadać i zrozumieć – zarówno społecznie jak technicznie – by móc w nim funkcjonować. (W tym wypadku konkretnym sposobem przeprowadzenia takich badań może być np. zapoznanie się ze stronami WWW danego projektu i/lub archiwami list dyskusyjnych). Nowi członkowie społeczności nabywają wzorców zachowań od doświadczonych hackerów właśnie w grupach projektowych.

Zapoznając się z wymienionymi sekretami, przyszły hacker zdobywa wiedzę kontekstową, dzięki której (po pewnym czasie) wspomniane tabu stają się “oczywiste”. Można by się spierać, że struktura hackerskiej kultury prezentu sama w sobie stanowi tajemnicę dla samej siebie: nie można uważać się za członka społeczności (a konkretnie: nikt nie nazwie danej osoby hackerem) dopóki nie wykaże się ona dogłębną znajomością gry o reputację i związanych z nią zwyczajów i tabu. Fakt ten jednak niewiele mówi, w końcu wszystkie kultury wymagają podobnej wiedzy od swoich przyszłych członków. Co więcej, kultura hackerska nie pragnie utrzymywać w tajemnicy swej wewnętrznej logiki i zwyczajów – a przynajmniej nikt jeszcze nie miał do mnie pretensji o to, że je opisałem!

Wiele osób, które podzieliły się ze mną swoimi uwagami na temat tego eseju – a było ich zbyt wiele, by je wszystkie wymienić – zwróciło uwagę na związek hackerskich zwyczajów odnoszących się do własności z praktykami istniejącymi w świecie akademickim, szczególnie wśród osób prowadzących badania naukowe. Społeczność naukowców napotyka podobne problemy podczas eksploracji terytorium potencjalnie twórczych idei, w podobny sposób rozwiązuje również tego typu problemy, korzystając z mechanizmów reputacji i opinii społeczności.

Ponieważ wielu hackerów miało styczność ze środowiskami akademickimi (często zostaje się hackerem będąc w koledżu), zbadanie wspólnej części wzorców przystosowawczych w obu kulturach może bardzo pomóc w zrozumieniu mechanizmów działania tych zwyczajów. Między przedstawioną przeze mnie hackerską “kulturą prezentu” a środowiskami akademickimi można znaleźć wiele analogii. Kiedy badacz zdobędzie prawa do dzierżawy, nie musi się obawiać o przetrwanie. (Idea “dzierżawy posady na uczelni” pochodzi zapewne z czasów wczesnej kultury prezentu, kiedy to “naturalni filozofowie” byli głównie bogatymi dżentelmenami dysponującymi mnóstwem czasu, który mogli poświęcić na działalność naukową). Kiedy brakuje bodźców mających swoje źródło w walce o przetrwanie, główną motywacją staje się praca nad własną reputacją, której sprzyja dzielenie się nowymi pomysłami i badaniami za pośrednictwem prasy fachowej i innych mediów. Jest to działanie obiektywnie uzasadnione, ponieważ badania naukowe, podobnie jak kultura hackerska, “opierają się na ramionach gigantów”, dzięki czemu nie muszą powtórnie odkrywać podstawowych zasad. Niektórzy sugerują nawet, że zwyczaje hackerskie są jedynie odbiciem zasad kultury badawczej, które (w większości przypadków) przejęli hackerzy. To chyba zbyt daleko posunięte stwierdzenie, choćby dlatego, że zwyczaje hackerskie z powodzeniem przejmują inteligentni uczniowie szkół średnich!

Prezent wygrywa z wymianą

Istnieje jeszcze jedna interesująca możliwość. Podejrzewam, że kręgi akademickie i kultura hackerska dzielą te same wzorce przystosowawcze nie z powodu związków genetycznych, ale dlatego, że — wziąwszy pod uwagę ludzkie instynkty i prawa natury — obie te kultury są optymalnymi organizmami społecznymi jeśli chodzi o wykonywanie swoich zadań. Z tego wynika, że wolnorynkowy kapitalizm optymalnym sposobem współpracy, jeśli ma się na celu wydajność ekonomiczną; prawdopodobnie kultura prezentu opierająca się na grze o reputację jest optymalnym sposobem tworzenia (i weryfikacji!) pracy twórczej wysokiej jakości.

Teorię tę potwierdza wiele badań psychologicznych dotyczących związków między sztuką a nagrodą. Badania te nie zwróciły takiej uwagi na jaką zasługują, po części zapewne dlatego, że popularyzujące je osoby miały tendencję do nadinterpretacji wyników i wykorzystywania ich przeciwko wolnemu rynkowi i własności intelektualnej. Tak czy inaczej z rezultatów wynika, że nagrody w stylu tradycyjnej gospodarki wpływają ujemnie na produktywność osób zajmujących się pracą twórczą, np. programistów.

Psycholog Theresa Amabile z Uniwersytetu w Brandeis dokonała ostrożnego podsumowania rezultatów przeprowadzonych w 1984 badań nad motywacją i nagradzaniem, zauważając przy tym: “Możliwe, że praca, która została zlecona, jest mniej twórcza niż taka, która jest wykonywana z czystego zainteresowania przedmiotem”. Amabile twierdzi dalej: “Wraz ze wzrostem złożoności danej aktywności, tym więcej szkody może przynieść nagroda”. Co ciekawe, z badań tych wynika, że stałe pensje nie odbierają motywacji – odbierają ją natomiast premie i opłaty za wykonanie dzieła.

Tak więc z ekonomicznego punktu widzenia przyznawanie premii za wyniki osobom, które smażą hamburgery i kopią doły jest mądrym posunięciem, jednak lepiej jest oddzielić pensję od wydajności w firmie programistycznej i pozwolić pracownikom wybierać projekty (świat open source przyjął obydwa te trendy jako logiczne wnioski). Co więcej, rezultaty badań sugerują, że jedynym momentem, kiedy warto nagradzać programistę za wyniki jest czas, kiedy jego motywacja jest tak silna, że pracowałby be zapłaty!

Inni badacze zajmujący się tymi wskazują na kwestie związane z autonomią i twórczą kontrolą, które tak bardzo zajmują hackerów. “Twórczość człowieka jest ograniczona w takim samym stopniu, w jakim ograniczona została jego kreatywność”. Ogólnie rzecz biorąc, przedstawienie jakiegokolwiek zadania nie jako cel sam w sobie, ale jako środek, odbiera motywację zamiast jej dodawać. Nawet wygrana w konkursie i zdobycie reputacji może odbierać motywację, jeśli postrzega się je jako pracę wykonywaną za wynagrodzenie (co może w pewien sposób wyjaśniać, dlaczego kultura hackerska zabrania swoim członkom jawnie szukać reputacji czy też utrzymywać, że posiada się pewną pozycję).

Aby jeszcze bardziej powikłać kwestię zarządzania przytoczymy jeszcze jeden fakt: mianowicie reakcje werbalne mają tak samo negatywny wpływ na motywację jak opłaty za wykonanie pracy. Ryan odkrył, że pracownicy, którym powiedziano: “Dobrze, pracujesz tak jak trzeba”, mieli “o wiele mniej wewnętrznej motywacji od tych, którzy po prostu otrzymywali informacje”.

Można w inteligentny sposób dostarczać bodźców motywujących, nie mogą im jednak towarzyszyć żadne dodatki, które mogłyby wpłynąć na zablokowanie pracy. Istnieje ogromna różnica (jak zauważa Ryan) między stwierdzeniem “Nagradzam cię ponieważ doceniam wartość twojej pracy” a “Jesteś nagrodzony, ponieważ spełniasz moje wymagania”. Pierwsze nie wpływa negatywnie na motywację, drugie – tak. Na tej podstawie możemy zaryzykować stwierdzenie, że grupa programistów open source będzie o wiele bardziej produktywna (szczególnie na dłuższą metę, kiedy twórczość zyskuje większe znaczenie, pełniąc rolę katalizatora produktywności) niż równorzędna grupa programistów closed-source, (negatywnie) motywowanych tradycyjną zapłatą.

Być może powinniśmy więc spojrzeć na jedną z teorii przedstawionych w krótkiej historii hackerstwa z nieco innego punktu widzenia. Chodzi mianowicie o to, że przemysłowo-fabryczny sposób wytwarzania oprogramowania był z góry skazany na przegraną od chwili, kiedy kapitalizm zaczął wytwarzać taki nadmiar dóbr, że programiści zaczęli żyć w kulturze prezentu. Wydaje się nawet, że receptą na najwyższą produktywność jest niemal paradoksem Zen: jeśli zależy nam na najwydajniejszej produkcji oprogramowania, musimy przestać zmuszać programistów do tworzenia. Należy im zapewnić środki do przetrwania, dać swobodę tworzenia i zapomnieć o terminach. Dla konwencjonalnego menedżera może to sprawić wrażenie wariackiej pobłażliwości, z góry skazanej na niepowodzenie – jest to jednak dokładnie ta sama recepta, dzięki której kultura open source pokonuje konkurencję.

Przypisy:{1} – Sunsite — archiwum poraz kolejny zmieniło nazwę; obecnie nazywa się Ibiblio.
{2} – Obecnie rzadko szuka sie oprogramowania w archiwach Metalab/Ibiblio. Zazwyczaj służy do tego serwis Freshmeat.net, zaś rolę Metalab przejął SourceForge (SourceForge.net).
{3} – Jeśli chodzi o uniksy oparte na kodzie (i licencji BSD), są one dziś coraz bardziej popularne. Najpopularniejsze jest FreeBSD, używane m.in. przez takie serwisy jak Yahoo czy Cdrom.com, a do niedawna również przez zakupiony przez Microsoft Hotmail; na uwagę zasługuje również OpenBSD, uznawane za jeden z najbezpieczniejszych systemów operacyjnych oraz NetBSD, pracujące na dużej liczbie platform.
{4} – Tcl (wym. tikl) – język skryptowy, niegdyś bardzo popularny w kulturze uniksowej, obecnie tracący popularność na rzecz Perla, Pythona czy PHP. Wiele programów z początkowego okresu rozwoju XFree86 i Linuksa napisano przy użyciu Tcl z rozszerzeniami Tk (Tcl/Tk), ponieważ jedyną alternatywą jeśli chodzi o tworzenie graficznych interfejsów użytkownika w owych czasach była komercyjna biblioteka Motif (obecnie używa się głównie bibliotek GTK i Qt). Osterhout rozwijał Tcl przez wiele lat na Uniwersytecie Berkeley, następnie pracując w Sun, po czym założył własną firmę (Ajuba) która oferuje zarówno produkty open source (Tcl, TclPro) jak i komercyjne (utrzymując się z tych ostatnich).
{5} – Python – coraz bardziej popularny, obiektowy język skryptowy, łatwy do nauczenia się, o eleganckiej składni.
{6} – W rzeczywistości Perl jest na podwójnej licencji (tzw. “artystyczna” oraz GPL), Tcl – na licencji BSD, zaś autor Pythona dokłada wszelkich starań, by we współpracy z RMS uczynić licencję Pythona zgodną z GPL (stąd np. wersja 1.6.1 Pythona. Jest to o tyle istotne, że większość oprogramowania open source jest na licencji GPL, zaś niezgodność z nią utrudnia tworzenie rozwiązań hybrydowych, będących mocną stroną Pythona).
{7} – Debian Free Software Guidelines (DFSG) to zespół norm, według których decyduje się, czy dany program może znaleźć się w popularnej dystrybucji Linuksa – Debianie. Debian jest jedną z niewielu dystrybucji, które wyraźnie zaznaczają udział GNU w powstaniu dystrybucji – oficjalna nazwa brzmi “Debian GNU/Linux”. Sama dystrybucja podzielona jest również ze względu na licencje: sekcja “main” zawiera jedynie to oprogramowanie, które spełnia zalecenia DFSG. Reszta znajduje się w sekcjach “non-free”, “contrib”, “non-us”.
{8} – Za rozwidleniem (“fork”) w dużych projektach open source zawsze stoją bardzo silne powody. Przykładem rozwidlenia może być słynny projekt Samba (umożliwiający stacji uniksowej emulację komputera z Windows), którego część członków zdecydowała się poświęcić więcej wysiłku pracy na rzecz zgodności z Windows 2000. Innego rodzaju przypadkiem jest odwrotność rozwidlenia – połączenie (“merge”), którego przykładem jest kompilator egcs, obecnie połączony z gcc.
{9} – Plik historii : źródła projektów zawierają zazwyczaj kilka standardowych plików. Są to: README, często najistotniejszy plik, zawierający najważniejsze informacje; AUTHORS, zawierający informacje o autorach; INSTALL, wyjaśniający jak zainstalować program; Changelog, zawierający historię zmian; NEWS – co nowego, oraz COPYING, czyli licencję. Plik historii to zazwyczaj Changelog.
{10} – deasemblacja (reverse engineering) – proces odtworzenia kodu asemblera (czytelnego dla programisty) z kodu maszynowego (zrozumiałego dla komputera).

Bibliografia.

Rewizja 1.2 pierwsza publikacja na stronie; 10 Kwiecień 1998.
Rewizja 1.3 Typograficzne poprawki oraz odpowiedzi na pierwszą rundę publicznych komentarzy. Pierwsze cztery pozycje w bibliografii. Anonimowo wniesione spostrzeżenia na temat bodźców reputacji funkcjonujących nawet, gdy rzemieślnik nie wie o nich. Dodanie pouczających kontrastów z warez d00dz, materiał na “Oprogramowanie powinno mówić za siebie” – założenia i spostrzeżenia na temat unikania kultów jednostki. Jako wynik wszystkich tych zmian, sekcja “Problem ego” urosła i została zakończona; 12 Kwiecień 1998.
Rewizja 1.7 Nowa sekcja “Globalne implikacje modelu gry o reputację” dyskutująca o historycznych trendach w kolonizacji noosfery, i badająca zjawisko “zabójcy-kategorii”. Dodać inne pytania badawcze; 16 Kwiecień 1998.
Rewizja 1.8 Dodanie Goldhaber’a do bibliografii. Ta wersja zostanie zabrana na przedstawienie na Targach Linux Expo; 27 Kwiecień 1998.
Rewizja 1.9 Uwzględnione rozróżnienie Fare Rideau noosfery / ergosfery. Uwzględnienie twierdzenie RMS’a, że nie jest antykomercyjny. Nowa część na akulturacji i środowisku akademickim (podziękowania dla Ross J. Reedstrom, Eran Tromer, Allan McInnes, Mike Whitaker, i inni). Bardziej o pokorze (“zachowanie pozbawione przerostu ego”) od Jerry Fass i Marsh Ray; 26 Maj 1998
Rewizja 1.10 Usunięte Fare Rideau’s odniesienie do “sławy” przy jego sugestii; 11 Lipiec 1998
Rewizja 1.14 Drobny artykuł wstępny oraz naprawda odnośników; 21 Listopad 1998
Rewizja 1.21 Główna korekta do książki wydawnictwa O’Reilly. Włączyć niektóre przemyślenia na temat kosztów rozwidlania się i tworzenia samemu łat – od Michael’a Chastain’a. Thomas Gagne (tgagne@ix.netcom.com) zauważył podobieństwo pośrodku “starszeństwo wygrywa” i heurystyki bazy danych. Polityczna analogia Henrego Spencer’a. Ryan Waldron i El Howard (elhoward@hotmail.com) – wniesiona sugestia na temat wartości nowości. Thomas Bryan (tbryan@arlut.utexas.edu) wyjaśnił odrazę hackera do “obejmy i poszerzenia”. Darcy Horrocks zainspirował nową część “Jaką wartość ma prezent?”. Inny nowy materiał na połączeniu z hierarchią wartości Maslovian, i tabu przeciwko atakom na kompetencję; Rewizja 1.21 Kwiecień 1999
Rewizja 1.22 Konwersja do wersji DocBook 4.1; 24 Kwieceń 2000;

Więcej informacji: Linux Community, Homesteading