Demokracja

Ansel powinien być prowadzony demokratycznie i sprawiedliwie wobec wszystkich zaangażowanych.

Definiowanie organizacji spółdzielczej wykraczającej poza kod open source

Zakładamy, że deweloperzy i użytkownicy, którzy tu trafiają, dzielą wspólny interes: chcą swobody w tym, jak edytują swoje zdjęcia, teraz i w przyszłości. To znaczy:

• posiadania wystarczającej kontroli technicznej nad treścią i właściwościami swoich obrazów,
• bycia wolnym od kapitalistów, którzy mogą:
  • podnosić cenę aplikacji wyłącznie na korzyść akcjonariuszy,
  • eksplorować zdjęcia klientów w celu trenowania modeli AI bez zgody,
  • wygaszać aplikacje bez udostępnienia kodu źródłowego,
• posiadania prawa do decydowania o kształcie i realizacji owej swobody.

DNA Ansela jest bardziej techniczne i szczegółowe niż w większości edytorów zdjęć RAW, przy jednoczesnym podkreślaniu przyjazności dla użytkownika tam, gdzie to możliwe, głównie w typowych zadaniach zorientowanych na komputer stacjonarny (interakcje z urządzeniami wejściowymi i plikami, paradygmaty GUI itp.). Ansel nie jest Darktable  ani ART , ponieważ jego wizja tego, jakim powinno być dobre oprogramowanie do retuszu obrazów, jest całkiem inna.

Ansel jest wydawany na licencji GNU/GPL , co czyni go wolnym oprogramowaniem / oprogramowaniem open source. Choć daje to (błędne) poczucie długoterminowej dostępności, w rzeczywistości jego długoterminowa dostępność zależy wyłącznie od woli i zdolności pewnych deweloperów do wykonywania (żmudnej) codziennej pracy utrzymaniowej, aby utrzymać go w działaniu, dalej wspierać nowe aparaty itd., co jest niedocenianym zadaniem, ponieważ nie przynosi spektakularnych informacji o wydaniu ani prezentacji.

Co gorsza, tak zwana „wolność" gwarantowana przez licencję GNU/GPL dotyczy wyłącznie kodu źródłowego: jest to wolność inżyniera. Licencje open source zasadniczo zrzekają się własności intelektualnej do kodu, co oznacza, że inżynierowie mogą go studiować i modyfikować, a następnie dzielić się swoimi modyfikacjami. Biorąc pod uwagę, że mniej niż 6 % światowej populacji¹ potrafi faktycznie pisać kod, jest to prawo tylko dla uprzywilejowanej mniejszości. Co zaś do użytkowników, cóż, licencja GPL jest całkiem jasna:

Ten program jest rozpowszechniany w nadziei, że będzie użyteczny, ale BEZ JAKIEJKOLWIEK GWARANCJI;

To stwierdzenie zasadniczo wyklucza użytkowników końcowych z transakcji: nie mają oni żadnych praw poza uruchamianiem kodu w takiej postaci, w jakiej jest, w szczególności nie mają prawa do wsparcia i poprawek błędów, nie mówiąc już o dostosowaniu oprogramowania do swoich potrzeb. Jeśli jakieś wsparcie mimo wszystko jest świadczone, dzieje się to według uznania deweloperów, a użytkownicy powinni być za nie na zawsze wdzięczni. Jest to nadużywane w tak zwanych „społecznościach open source" (czyli „forach oprogramowania"), aby uciszyć i unieważnić wszelkie skargi użytkowników: po prostu nie mogą narzekać, skoro korzystają z darmowej pracy, mimo że marketing projektów open source często rozpływa się w zachwytach nad „profesjonalną" przydatnością tych aplikacji. Ale… obietnice zostały złożone, słowo „pro" padło, lecz nie zostało dotrzymane, więc gdzieś tkwi wprowadzająca w błąd niespójność.

Nawet zrzekając się jakiejkolwiek odpowiedzialności wobec użytkowników, wiele projektów wciąż próbuje zamienić ich, jeśli nie w klientów, to przynajmniej w darczyńców. Co stawia nas wobec smutnego stanu rzeczy: 350 lat kapitalizmu zepsuło nasze umysły do tego stopnia, że myślimy, iż aplikacje open source są najtańszym konkurentem oprogramowania własnościowego. Użytkownicy po prostu siedzą na tyłkach, czekając, aż projekty dostarczą produkt, zanim zdecydują, czy zadadzą sobie trud, by wesprzeć je datkiem. To tak, jakby zacząć finansować NASA dopiero po wystrzeleniu pierwszej rakiety, aby udowodnić, że projekt rzeczywiście może coś dostarczyć: tak się nie da. Trzeba płacić za pracę jeszcze zanim pojawi się produkt na sprzedaż. A gdy produkt zostaje wydany, projekty takie jak Wikipedia wciąż z trudem uzyskują mniej niż 3 $/rok od 2 % swoich użytkowników.

Aplikacje open source są konkurentami aplikacji własnościowych tak samo jak szpitale publiczne są konkurentami prywatnych klinik: nie są. Z jednej strony mamy socjalistyczny projekt zapoczątkowany przekonaniem, że każdy ma prawo do opieki zdrowotnej, a jeśli kogoś na nią nie stać, poradzimy sobie, znajdując dodatkowe pieniądze w społeczności. Z drugiej strony mamy akcjonariuszy próbujących osiągać zyski, zatrudniających chirurgów próbujących spłacić swój dom w Malibu i kolekcję Porsche. Jak niby są konkurentami? Usługa publiczna to sposób na zapewnienie ludziom zasobów potrzebnych do korzystania z ich praw, ponieważ wolność jest tylko teoretyczna, dopóki nie masz środków, by faktycznie z tych praw skorzystać. Prywatna firma sprzedająca dobra lub usługi to sposób na zarabianie pieniędzy z inwestycji. Różnica jest polityczna. Jest też ekonomiczna, ponieważ niemienie akcjonariuszy na liście płac i tak czyni produkt końcowy bardziej przystępnym cenowo.

Ślepą plamką ruchu „wolnego oprogramowania" było unikanie refleksji nad kontekstem i strukturą pracy, w której takie oprogramowanie powstaje, jest rozwijane i utrzymywane. Można to prześledzić wstecz do kultury hakerskiej , która z natury jest indywidualistyczna i pośrednio zgodna z kapitalizmem, poprzez technofilię  i technosolucjonizm . „Dzielenie się tym, co jest" (twoją pracą, twoim kodem, twoimi sztuczkami) pomylono z „troszczeniem się o" (potrzeby, ograniczenia, wyzwania innych ludzi) i podsycano quasi-hagiograficznymi narracjami. Gdy masz młotek, wszystko wygląda jak gwóźdź: gdy wszystko, co znasz, to kod, kod jest rozwiązaniem wszystkiego, a próba owinięcia go w filozofię i (nierewolucyjną) politykę, aby zdefiniować „wolność kodu", wciąż umyka szerszemu obrazowi, jakim jest wyzysk pracy wszystkich przez małą, lecz potężną i samoreprodukującą się klasę społeczną. Podczas gdy 6 % światowej populacji potrafiło pisać kod w 2021 roku, odsetek tych, których w latach 80., gdy rozpoczynał się ruch wolnego oprogramowania, było stać choćby na komputer osobisty, był znacznie mniejszy. Uprzywilejowane mniejszości są zawsze ślepe na swoje przywileje: po tym się je rozpoznaje. Nie dostrzegły, że wolne oprogramowanie było niczym więcej niż dzieckiem tych przywilejów. Jest wolnością tylko dla tych, których na nią stać. A fakt, że metka z ceną nie ma przy sobie znaku dolara, czyni to zdradliwym. Metka z ceną wciąż tam jest.

Ruch wolnego oprogramowania został stworzony, by wpasować się w ten indywidualistyczny, oparty na wolnej przedsiębiorczości kapitalizm liberalnego rynku, i sprawił, że wszyscy uwierzyli, iż wystarczy pozwolić każdemu rozpocząć własny projekt lub odgałęzić go od cudzego. Potem darwinizm społeczny  miałby wszystko uporządkować. Owszem, ale… kto płaci za pracę? Co gorsza, skoro kapitalizm nadaje pracy wartość tylko wtedy, gdy jej produkt jest sprzedawany na liberalnym rynku, a ta wartość jest indeksowana do rzadkości produktu, jak dokładnie mamy przekonać użytkowników, że coś zdematerializowanego, nieskończenie pobieralnego za darmo, ma jakąkolwiek wartość? Wiele projektów open source próbowało wielu różnych strategii finansowania swojej pracy, wszystkie są niepewne i okaleczone, ponieważ wciąż chcą wpasować strukturę pracy, która z natury jest komunistyczna, w ramy kapitalistyczne (więcej o tym poniżej).

Podczas gdy organizacje non-profit mogą sprawdzać się w projektach humanitarnych, gdzie darczyńcy nigdy nie będą docelowymi odbiorcami pracy, to w projektach oprogramowania datki są interesowne, ponieważ darczyńcy są użytkownikami. Podtrzymuje to zachowanie konsumenckie, w którym bierni (i poniekąd uciskani) konsumenci czekają na dobra dostarczane przez elitarną mniejszość członków zarządu, którzy rozdają karty. Te organizacje non-profit i tak są prowadzone prywatnie, a opinia publiczna nie ma żadnego prawa poza zaprzestaniem wpłat, jeśli nie czuje się wysłuchana. Zarząd Linux Foundation  składa się niemal wyłącznie z kadry kierowniczej producentów sprzętu i GAFAM , zarząd Free Software Foundation  składa się z naukowców i techników komputerowych. Nie ma tam reprezentacji użytkowników, są pionowe struktury hierarchiczne „tych, którzy wiedzą" nad „tymi, którzy potrzebują", utrwalające ten sam rodzaj dominacji co kapitalizm, tyle że bez zysków.

Uzasadnia się to faktem, że licencje open source zrzekają wszelkiej formy odpowiedzialności (gwarancji) deweloperów wobec użytkowników, co czyni to transakcją jednostronną, która pozornie daje całą władzę decyzyjną deweloperom. Ale wszystko to jest oczywiście konstruktem, a nie z góry przesądzonym wnioskiem. Z drugiej strony, ponieważ kapitalistyczny dogmat jest tak głęboko wsączony w umysły użytkowników, kod źródłowy wprowadza oprogramowanie na darmowy, zdematerializowany i nierzadki rynek, który unieważnia wszelkie pojęcie wartości kapitalistycznej, co sprawia, że użytkownicy mogą bez skrupułów czerpać produkt pracy bez wkładu: kolejna transakcja jednostronna. Tymczasem niektórzy deweloperzy wypalają się i wyczerpują, aby zapewnić rozsądne wsparcie użytkownikom, nie uzyskując rozsądnego dochodu ze swojej (wyzyskiwanej) pracy, być może w nadziei, że w dłuższej perspektywie się to opłaci, gdy im „się uda". Albo deweloperzy przyjmują niewypowiedzianą regułę open source (że powinno to być tylko hobby / zajęcie w niepełnym wymiarze), co nieuchronnie cofa open source, czyniąc je na zawsze biednym rodzeństwem oprogramowania własnościowego. Albo wreszcie niektóre firmy open source, jak Automattic  czy RedHat , z czasem zaczynają być coraz bardziej agresywnie zachłanne, mierząc się ze sprzeciwem swoich społeczności. To nie jest zrównoważone dla żadnej z zaangażowanych stron.

Musimy zamienić te dwie równoległe transakcje jednostronne w krąg. Oto jak:

1. Żadna technologia nie może istnieć poza społeczeństwem, które ją wytwarza. Technologia potrzebuje nauki. Nauka potrzebuje badań. Badania potrzebują struktur, w których mogą być swobodnie prowadzone. Społeczeństwo jest środowiskiem, w którym to wszystko się dzieje, a także systemem wsparcia, który to umożliwia.
2. Żadna technologia nie może istnieć bez pracy. Jeśli produkt pracy wymyka się systemowi kapitalistycznemu (liberalnemu rynkowi opartemu na rzadkości i konkurencji), to praca go wytwarzająca również powinna mu się wymykać.
3. Żadna technologia będąca własnością prywatną nie będzie służyć dobru wspólnemu i interesowi publicznemu. Technologie, a nie tylko urządzenia, powinny być własnością ich użytkowników, a nie tylko ich twórców.
4. Praca jest jedynym bogactwem. Pracownicy powinni czerpać korzyści ze swojej pracy, niezależnie od tego, czy jest sprzedawana na liberalnym rynku, czy nie: powinna być opłacana bez względu na wszystko. Praca powinna odbywać się w bezpiecznym i sprawiedliwym środowisku. To zbiorowa, społeczna odpowiedzialność, by tak się działo, ponieważ produkt pracy służy dobru wspólnemu i interesowi publicznemu. Praca, która im nie służy, powinna być po prostu zatrzymana.
5. Technologie będące własnością ich użytkowników otwierają drogę do nowego rodzaju produkcji: współpracy między twórcami a użytkownikami, zamiast konkurencji między twórcami i wojen korporacyjnych o zdobycie rynków poprzez przekonywanie klientów o wyższości jakiegoś produktu (w efekcie każąc użytkownikom płacić za reklamę…). Ale kapitalizm nie umie sprzedać produktu współpracy, ponieważ nie ma już osobnego kupującego ani sprzedającego, jest tylko społeczność osób, które wspólnie pracują ku czemuś: zaspokajaniu swoich potrzeb, zamianie swoich teoretycznych praw w rzeczywistą wolność poprzez tworzenie kontekstu do korzystania z nich.
6. Istnieje wzajemna odpowiedzialność twórców wobec użytkowników (zaspokajanie ich potrzeb poprzez technologię / za jej pomocą) oraz użytkowników wobec twórców (zapewnianie im bezpiecznego i sprawiedliwego środowiska pracy oraz materialnych warunków życia). To są absolutne podstawy społeczności²…
7. Open source prowadzące do prawdziwej wolności może zaistnieć wyłącznie wewnątrz struktury spółdzielczej . Która jest starym, sprawdzonym i już działającym komunizmem, gdzie firma (a więc i projekt open source jako całość) jest własnością swoich klientów i swoich pracowników, którzy dzielą się prawem głosu. Wykracza to daleko poza samo zrzeczenie się własności intelektualnej (licencję open source / wolną licencję).

Spółdzielnia jest sposobem na przełamanie tej dychotomii między „nami" a „nimi", twórcami kontra użytkownikami, która karmi wzajemną urazę: deweloperzy są dyktatorami traktującymi aplikację jak swój osobisty plac zabaw, którym użytkownicy powinni być zawsze wdzięczni bez względu na to, jak bardzo ją psują, a użytkownicy są irytującymi pijawkami, które ciągle zgłaszają zawiłe problemy i prośby o funkcje, wpłacając przy tym zbyt mało.

W spółdzielni zarówno twórcy, jak i użytkownicy są członkami-udziałowcami. Wszyscy są właścicielami projektu, wszyscy mają jeden głos na walnym zgromadzeniu. Projektem jest uczynienie edycji zdjęć wolną w dającej się przewidzieć przyszłości, w ramach pewnej jednolitej wizji tego, czym jest edycja zdjęć (jak techniczna i szczegółowa powinna być kontra jak łatwa i przyjazna dla użytkownika). Aby zrealizować ten cel, angażowanych jest wiele środków, jak edukacja, rzecznictwo, dokumentacja i, rzecz jasna, aplikacja. Projekt to coś więcej niż tylko produkt końcowy, którego pojawienie się i przygotowanie może zająć trochę czasu: projekt to wszystko powyżej i wokół, to cel oraz wszystkie środki, by uczynić go rzeczywistością.

Odpowiedzialnością członków jest zapewnienie rocznego budżetu pokrywającego wszystkie koszty projektu, najprawdopodobniej z rocznych składek członkowskich. Z tego budżetu na walnym zgromadzeniu ustala się określoną liczbę godzin pracy według określonej stawki godzinowej. To, jak ten budżet zostanie wydany (jaki rodzaj zadań, sprzęt, narzędzia itp.), również jest ustalane na walnym zgromadzeniu. W przypadku zadań technicznych, jak rozwój oprogramowania, będą to ogólne kierunki (jak ulepszenie maskowania, przepływu pracy wsadowej itd.), a nie szczegóły implementacji czy faktyczny projekt, które słabo nadają się do procesów demokratycznych. Deweloperzy mogą forsować zadania zorientowane na backend (jak przepisywanie lub refaktoryzacja długu technicznego, aby zmniejszyć długoterminowy koszt utrzymania), użytkownicy mogą forsować zadania zorientowane na funkcje (jak wsparcie nowych funkcji aparatów, formatów obrazów itd.): celem walnego zgromadzenia jest naradzenie się i uszeregowanie priorytetów.

Uzgodnione zadania będą następnie realizowane przez opłacanych pracowników w kolejności priorytetów, aż budżet pracy zostanie wyczerpany. Nie ogranicza się to do pracy technologicznej i rozwoju, lecz odnosi się do każdego rodzaju wcześniej uzgodnionej pracy. Gdy budżet zostanie wyczerpany, pracownicy zdadzą sprawę z tego, gdzie się zatrzymali na liście zadań, co zdołali ukończyć, czego nie zdołali i jakich zasobów zabrakło do ukończenia. Walne zgromadzenie zdecyduje wówczas, czy możliwe i pożądane jest zainwestowanie większych zasobów, aby ukończyć, czy przesunięcie pozostałych zadań do kolejnego rocznego budżetu. Daje to pracownikom widoczność ich rocznego dochodu bez promowania nadmiernego obciążania się i wypalenia.

Użytkownicy mogą tworzyć panele, aby wspólnie z deweloperami pracować nad zrozumieniem faktycznie napotykanych problemów, testować i walidować rozwiązania w ramach procesu projektowego. Każdy użytkownik może zostać przekształcony w pracownika i zacząć pobierać wynagrodzenie za swoją pracę nad uzgodnionymi zadaniami, po zatwierdzeniu przez walne zgromadzenie.

Sprawia to, że obowiązkiem każdego jest zadbanie, by zgromadzić zasoby potrzebne do pójścia naprzód, oraz zapewnienie pracownikom tego, czego potrzebują, aby pracować godnie, bezpiecznie, bez bycia wyzyskiwanym. Żadna praca nie powinna być darmowa, bez względu na zadanie. Praca nie powinna ograniczać się do programowania czy innych zadań technicznych.

Granice demokracji

Demokracja przez głosowanie jest zasadniczo wyrażaniem woli większości, o której wiadomo, że uciska mniejszości. Nie jest zatem doskonała. Mniejszości mogą wyrażać rozsądne i uzasadnione obawy, tyle że nie będą one podzielane przez większość. Na myśl przychodzą osoby z niepełnosprawnościami: niektóre szczegóły projektowe mogą uczynić całą aplikację całkowicie bezużyteczną dla nich, mimo że nie mają liczebności, by narzucić swoje poglądy w głosowaniu. Z drugiej strony nie da się zaspokoić osobliwych potrzeb każdego z osobna, nie tworząc potworków. Trzeba to starannie ocenić i rozstrzygnąć.

Odpowiedzialnością większości jest zatem zidentyfikowanie, kim są mniejszości strukturalne, to znaczy jakie właściwości łączą te mniejszości (stan zdrowia, pochodzenie społeczne, wykształcenie, poziom dochodów itd.). Jeśli mniejszość podnosi problem, który jest dla niej blokujący z powodu jednej z definiujących ją właściwości, powinien istnieć sposób na obejście lub przeważenie głosu większości. Pozostaje to do zdefiniowania, ale najłatwiejszym sposobem ujęcia tego jest podczas narad, które opierają się na empatii i zrozumieniu większości.

Innym problemem każdej grupy społecznej jest myślenie grupowe , ponieważ każda grupa społeczna z czasem degeneruje się w klub. Myślenie grupowe zachodzi wtedy, gdy jednostki nie czują się swobodnie, by podnosić kwestie sprzeczne z (rzekomym) konsensusem grupy, w obawie o reperkusje dotyczące ich miejsca i postrzegania w grupie. Te reperkusje mogą być bardzo subtelne, a jednak bardzo realne. Staje się to szkodliwe, gdy jednostki zaczynają wewnątrz grupy popierać decyzje, których na własną rękę by nie poparły: to punkt zwrotny, w którym gubi się indywidualna racjonalność. Aby tego uniknąć, można stosować głosowanie anonimowe, lecz nie ma ono zastosowania do narad, gdzie z konieczności występuje mówca. Istnieje kultura zdrowego sprzeciwu do zbudowania, utrzymania i pielęgnowania. Jednym ze sposobów rozwiązania tego problemu jest losowe wyznaczanie „adwokata diabła" na każdą sesję, którego zadaniem będzie ciągłe wyrażanie sprzeciwu i przedstawianie odpowiadających mu argumentów.

Można oczekiwać, że każda społeczność oparta na wspólnym zainteresowaniu fotografią i wolnym oprogramowaniem będzie stronnicza na korzyść bogatych, wykształconych, obeznanych z komputerami, anglojęzycznych mężczyzn. Trzeba będzie świadomego wysiłku, by starać się włączać kobiety, osoby mniej wykształcone, obywateli spoza świata zachodniego itd. W połączeniu z demokracją przez głosowanie i myśleniem grupowym rozpoczynanie od tak jednorodnej społecznie grupy może być naprawdę szkodliwe, jeśli nie jest zarządzane starannie. Będzie to codzienne wyzwanie, którego każdy musi być świadomy. Będzie to również karmić błąd przeżywalności , gdzie odrzuceni nie są tu, by przekazać informację zwrotną o tym, dlaczego nie dołączyli, nie uczestniczyli ani nie poczuli się mile widziani, a odrzuceni będą wymagać dodatkowej troski, by do nich dotrzeć i ich powitać.³ Żadna doza rasizmu ani seksizmu nie może być tolerowana w takim środowisku, nawet jako żart, ponieważ sprawiłaby, że większość śmieje się kosztem mniejszości w kontekście, z którego są one już odsiane.

Demokracja jest też procesem powolnym. Mogą zdarzyć się rzeczy wymagające szybkiej decyzji, jak włamanie do serwera projektu lub kont w mediach społecznościowych, albo jakakolwiek pilna kwestia prawna. Ktoś powinien być wybrany na krótkoterminowe mandaty, aby móc szybko podejmować takie decyzje w imieniu społeczności.

Granice między ekspertami a laikami

Tak jak lekarze czy prawnicy, deweloperzy posiadają niszowe kompetencje i doświadczenie, które dadzą im pewnego rodzaju władzę, a nawet charyzmę nad laikami. Ta władza może być nadużywana do uciskania większości poprzez wykorzystywanie jej braku wiedzy na korzyść ciemiężcy. Ta relacja zawsze będzie asymetryczna i trzeba to uznać. Ponadto deweloperzy będą musieli być konsultowani podczas narad na walnym zgromadzeniu, aby ocenić wykonalność zadań i potrzebne zasoby, zanim odbędą się głosowania.

Tak jak lekarze, prawnicy itd., deweloperzy powinni przestrzegać pewnego rodzaju kodeksu etyki idącego w parze z ich symboliczną władzą, wśród którego:

1. obowiązek uczciwego informowania, zgodnie z najlepszą wiedzą, oraz prostego wyjaśniania tego, co da się prosto wyjaśnić,
2. obowiązek rzetelnej procedury i należytej staranności przy badaniu i opracowywaniu rozwiązań,
3. zobowiązanie do pracy w najlepszym interesie społeczności.

Z drugiej strony deweloperzy (lub inni eksperci) mogą być postrzegani przez laików jako wszechwiedzący, wszechmocni czarodzieje, którzy mogą wówczas żądać od nich zbyt wiele. Choć oprogramowanie jest dość plastycznym medium, wciąż obowiązują nienegocjowalne ograniczenia techniczne, a nie wszystko, co jest technicznie możliwe, może być możliwe w obecnych okolicznościach przy obecnych zasobach.

Obie te postawy będą musiały zostać zrozumiane, aby zapobiec narastaniu wzajemnej urazy.

Granice współpracy

Każdy jest projektantem.

Każda praca, o której nic nie wiesz, wygląda na łatwą do wykonania. Projektowanie i budowanie obiektów technicznych jest jedną z nich. Wręcz ekscytujące jest wnoszenie do tego wkładu. Ale oprogramowanie, które będzie używane jako narzędzie przez tysiące użytkowników innych niż ty, to nie to samo co twoja własna szafka nocna.

Użytkownicy powinni być mile widziani do udziału w definiowaniu problemu: zacznij od jednego lub kilku użytkowników mających konkretny problem w konkretnym przepływie pracy, sprawdź, czy nie da się go już rozwiązać obecnymi narzędziami i być może odrobiną edukacji, a jeśli nie, spróbuj zbadać, ilu użytkowników dzieli ten sam problem. Jeśli problem nie jest dla wszystkich dokładnie taki sam, spróbuj znaleźć wspólne sformułowanie problemu, które pozwala go uogólnić.

Gdy problem jest zdefiniowany, zaczyna się proces projektowy, który podąża za formalnymi krokami, aby uniknąć pędu ku pierwszemu (i najpewniej nieoptymalnemu) rozwiązaniu, ponieważ, po raz kolejny, ludzka intuicja lepiej sprawdza się w budowaniu szafek nocnych niż narzędzi używanych przez tysiące. Ale podążanie za procesem nie wystarczy.

Psychologia i nauki kognitywne zbiegają się ku konsensusowi: najlepszy rozmiar zespołów roboczych to od 4 do 7 członków. Począwszy od 8 członków produktywność zaczyna dramatycznie spadać.⁴⁵⁶ Dla zespołu 4-osobowego istnieje 6 kanałów komunikacji międzyludzkiej, podczas gdy dla 8 członków istnieją 28 kanały komunikacji. Utrudnia to poznawcze śledzenie wszystkich zaangażowanych, kto za co odpowiada, przetwarzanie sygnałów niewerbalnych, co powoduje przeciążenie komunikacyjne. Powyżej 9 członków zaczynają tworzyć się klany, w proces miesza się polityka i wkracza próżniactwo społeczne .⁴⁵

Oznacza to, że praca powinna być dzielona na zespoły robocze liczące każdy nie więcej niż 6 do 7 członków, nawet jeśli dla społeczności jako całości ekscytujące może być zainteresowanie się wszystkim. Komunikacja jest tu punktem zwrotnym: potrzebujesz jej dokładnie tyle, ile trzeba, nie więcej, nie mniej, w przeciwnym razie poznawczo przeciąża członków zespołu i utrudnia samą komunikację. Wtedy to sama praca obrywa.