Rozdział 3. Infrastruktura techniczna

Projekty wolnego oprogramowania wykorzystują technologie wspierające gromadzenie i integrację informacji. Im więcej doświadczenia posiadasz w ich użyciu, i przekonywaniu do tego innych, tym większe szanse, że twój projekt będzie udany. Ta zasada jest tym ważniejsza, im bardziej projekt rośnie. Dobre zarządzanie informacjami sprawia, że projekt nie zapada się pod ciężarem prawa Brooksa^[12], które mówi, że dodanie ludzi do projektu programistycznego, który jest opóźniony, sprawia jedynie, że będzie on jeszcze bardziej opóźniony. Fred Brooks zauważył, że złożoność projektu zwiększa się z kwadratem liczby uczestników. Gdy zaangażowanych jest jedynie kilka osób, każdy może porozumieć się z każdym, ale gdy nad projektem pracują setki osób, nikt nie jest w stanie ogarnąć tego, co robią wszyscy inni. Jeśli dobrym zarządzaniem wolnymi projektami nazwiemy takie, które sprawia, że wszyscy mają wrażenie wspólnej pracy w jednym pokoju, nasuwa się pytanie, co gdy w zatłoczonym pokoju wszyscy usiłują mówić w tym samym czasie?

To nie nowy problem. W dosłownie rozumianych zatłoczonych pokojach, rozwiązaniem jest proces parlamentarny: formalne wytyczne regulujące dyskusje w dużych grupach, uniemożliwiające zagubienie istotnych uwag w zalewie głupich komentarzy, opisujące jak tworzyć komisje, kiedy decyzje można uznać za podjęte, i tak dalej. Istotnym elementem procesu parlamentarnego jest ustalenie, jak grupa korzysta ze swojego systemu gromadzenia informacji. Niektóre uwagi są wpisywane "do stenogramu", inne nie. Sam zapis może ulec zmianie, nie jest traktowany jako dosłowny ślad tego, co się faktycznie wydarzyło, ale jako deklaracja tego, co wydarzyło się według decyzji grupy. Taki zapis nie jest jednorodny, dla różnych celów przyjmuje różną postać. Mogą to być notatki z poszczególnych spotkań, zbiór notatek wszystkich spotkań, podsumowania, agendy i komentarze do nich, raporty komitetów, raporty od nieobecnych korespondentów, listy zadań, i tak dalej.

Tak naprawdę Internet to nie pokój, więc nie musimy matwić się o te elementy procesu parlamentarnego, które zapewniają ciszę, gdy inni mówią. Jednak gdy chodzi o techniki zarządzania informacjami, dobrze prowadzone projekty otwartego oprogramowania to "procedura parlamentarna na sterydach". Jako że praktycznie cała komunikacja w projektach wolnego oprogramowania odbywa się na piśmie, stworzone zostały skomplikowane systemy ułatwiające przekazywanie i etykietowanie informacji, minimalizowanie powtórzeń i niepotrzebnych rozbieżności, przechowywanie i odzyskiwanie danych, korygowanie złych i przestarzałych informacji, łączenie poszczególnych informacji pomiędzy sobą. Aktywni uczestnicy sami zdają sobie sprawę z użyteczności tych technik, i potrafią poradzić sobie z nimi ręcznie. Jednak na dłuższą metę jedyną drogą jest użycie odpowiedniego oprogramowania. Jeśli to tylko możliwe, samo medium wymiany informacji powinno zapewniać jej przekazywanie, etykietowanie czy rejestrowanie, i udostępniać informacje ludziom w najdogodniejszej dla nich postaci. W praktyce interwencja człowieka w tym procesie wciąż będzie czasem konieczna, a więc samo oprogramowanie powinno ułatwiać taką interwencję. Jednak w większości wypadków jeśli człowiek odpowiednio opisze informację wprowadzając ją do systemu, oprogramowanie powinno skorzystać z tych metadanych tak dobrze, jak to tylko możliwe.

Porady w tym rozdziale są mocno praktyczne, oparte na doświadczeniach z opisanym oprogramowaniem i różnymi scenariuszami użycia. Jednak głównym celem nie jest jedynie przekazanie pewnego zestawu technik. Chodzi także o wskazanie (na wielu małych przykładach) dobrego podejścia, który zachęci do skutecznego zarządzania informacjami w projekcie. To podejście składa się zarówno z umiejętności technicznych, jak i tych miękkich. Umiejętności techniczne są konieczne, ponieważ oprogramowanie do zarządzania informacjami zawsze wymaga konfiguracji, a także pewnego wysiłku w utrzymaniu i dostosowywaniu do nowych potrzeb (na przykład patrz dyskusja o tym, jak radzić sobie z wzrostem projektu w „Pre-Filtering the Bug Tracker” dalej w tym rozdziale). Umiejętności miękkie są niezbędne, ponieważ ludzka społeczność także wymaga opieki. Nie zawsze oczywiste jest, jak w pełni wykorzystać stosowane narzędzia, a czasem projekty stosują sprzeczne konwencje (na przykład patrz dyskusja o nagłówku Reply-to w wiadomościach na listach dyskusyjnych, w „Listy dyskusyjne”). Każdy uczestnik projektu powinien być zachęcany, w odpowiednim czasie i w odpowiedni sposób, do dbania o porządek w informacjach projektu. Im większe zaangażowanie uczestnika w projekt, tym bardziej złożonych i wyspecjalizowanych technik będzie musiał się nauczyć.

Zarządzanie informacjami to problem, na który nie ma podręcznikowej odpowiedzi. Występuje tu zbyt wiele zmiennych. Może się zdarzyć, że wszystko jest skonfigurowane tak, jak sobie tego życzysz, a większość społeczności współpracuje, ale rozwój projektu sprawi, że niektóre praktyki przestaną się skalować. W projekcie, którego wzrost osiągnął stabilny poziom, a programiści i użytkownicy przywykli do stosowanej infrastruktury, nowi uczestnicy mogą dziwić się, dlaczego nie stosuje się jakiegoś nowopowstałego systemu zarządzania informacjami. To obecnie dość powszechne zjawisko w projektach, które powstały przed wynalezieniem wiki (patrz http://en.wikipedia.org/wiki/Wiki). Odpowiedź na wiele pytań to sprawa względna, zależna od kompromisu pomiędzy wygodą tych, którzy wprowadzają informację, a tych, do których jest ona kierowana, lub pomiędzy czasem koniecznym na skonfigurowanie systemu zarządzania informacjami, a jego pożytkiem dla projektu.

Wystrzegaj się pokusy nadmiernej automatyzacji, czyli automatyzacji procesów, które w rzeczywistości wymagają ludzkiej uwagi. Infrastruktura techniczna jest istotna, ale tym co sprawia, że projekty wolnego oprogramowania żyją, jest troska ludzi w nie zaangażowanych. Infrastruktura techniczna powinna przede wszystkim być w tym pomocą dla człowieka.