Demokratie

Ansel sollte demokratisch und fair gegenüber allen Beteiligten geführt werden.

Eine kooperative Organisation jenseits von Open-Source-Code definieren

Von Entwicklern und Benutzern, die hier landen, wird angenommen, dass sie ein gemeinsames Interesse teilen: Sie wollen Freiheit darin, wie sie ihre Bilder bearbeiten, jetzt und in Zukunft. Das bedeutet:

• eine ausreichende technische Kontrolle über Inhalt und Eigenschaften ihrer Bilder zu haben,
• frei zu sein von Kapitalisten, die möglicherweise:
  • den Preis ihrer Anwendung allein zum Vorteil der Aktionäre erhöhen,
  • die Fotos der Kunden ausbeuten, um KI-Modelle ohne Einwilligung zu trainieren,
  • Anwendungen einstellen, ohne den Quellcode freizugeben,
• ein Recht darauf zu haben, über die Konturen und die Umsetzung dieser Freiheit zu entscheiden.

Die DNA von Ansel ist technisch orientierter und feinkörniger als die der meisten RAW-Fotobearbeitungsprogramme, während dennoch, wo immer möglich, Wert auf Benutzerfreundlichkeit gelegt wird, hauptsächlich bei typischen desktopzentrierten Aufgaben (Interaktionen mit Eingabegeräten und Dateien, GUI-Paradigmen usw.). Ansel ist nicht Darktable  oder ART , weil seine Vision davon, was eine gute Bildbearbeitungssoftware sein sollte, recht unterschiedlich ist.

Ansel wird unter der GNU/GPL-Lizenz  veröffentlicht, was es zu einer freien/quelloffenen Software macht. Während dies ein (falsches) Gefühl langfristiger Verfügbarkeit vermittelt, hängt die langfristige Verfügbarkeit in Wirklichkeit allein vom Willen und der Fähigkeit einiger Entwickler ab, die (mühsame) alltägliche Wartung durchzuführen, um sie funktionsfähig zu halten, weiterhin neue Kameras zu unterstützen usw. – eine unterschätzte Aufgabe, weil sie keine spektakulären Release Notes oder Keynotes hervorbringt.

Schlimmer noch: Die sogenannte „Freiheit", die die GNU/GPL-Lizenz gewährt, betrifft nur den Quellcode: Es ist die Freiheit der Ingenieure. Open-Source-Lizenzen verzichten im Wesentlichen auf das geistige Eigentum am Code, was bedeutet, dass Ingenieure ihn studieren und modifizieren und dann ihre Modifikationen teilen können. Da weniger als 6 % der Weltbevölkerung¹ tatsächlich Code schreiben können, ist dies ein Recht nur für eine privilegierte Minderheit. Was die Benutzer betrifft, nun ja, die GPL-Lizenz ist ziemlich eindeutig:

Dieses Programm wird in der Hoffnung verbreitet, dass es nützlich sein wird, jedoch OHNE JEDE GEWÄHRLEISTUNG;

Diese Aussage schließt Endbenutzer im Wesentlichen von der Transaktion aus: Sie haben keine anderen Rechte, als den Code so wie er ist auszuführen, insbesondere kein Recht auf Support und Fehlerbehebungen, geschweige denn ein Recht darauf, dass die Software an ihre Bedürfnisse angepasst wird. Wenn doch etwas Support geleistet wird, dann nach Ermessen der Entwickler, und die Benutzer sollten dafür auf ewig dankbar sein. Dies wird in sogenannten „Open-Source-Communities" (gemeint sind „Software-Foren") ausgenutzt, um jede Beschwerde von Benutzern abzuwürgen und für ungültig zu erklären: Sie können sich schlicht nicht beschweren, da sie kostenlose Arbeit nutzen, auch wenn das Marketing von Open-Source-Projekten oft in schwärmerischen Tönen von der „professionellen" Tauglichkeit dieser Anwendungen redet. Aber… es wurden Versprechen gemacht, das Wort „pro" wurde ausgesprochen, aber nicht eingelöst, also gibt es da irgendwo eine irreführende Ungereimtheit.

Selbst wenn sie jede Verantwortung gegenüber den Benutzern von sich weisen, versuchen viele Projekte dennoch, sie, wenn schon nicht in Kunden, so doch zumindest in Spender zu verwandeln. Was auf eine traurige Sachlage stößt: 350 Jahre Kapitalismus haben unsere Gehirne so verdorben, dass wir denken, Open-Source-Anwendungen seien der billigste Konkurrent zu proprietärer Software. Die Benutzer sitzen einfach auf ihren vier Buchstaben und warten darauf, dass die Projekte ein Produkt liefern, bevor sie entscheiden, ob sie sich überhaupt die Mühe machen zu spenden. Das ist so, als würde man erst dann anfangen, die NASA zu finanzieren, nachdem die erste Rakete gestartet wurde, um zu beweisen, dass das Projekt tatsächlich liefern kann: Das kann nicht funktionieren. Man muss die Arbeit bezahlen, noch bevor es ein Produkt zu verkaufen gibt. Und wenn das Produkt veröffentlicht ist, haben Projekte wie Wikipedia immer noch Mühe, weniger als 3 $/Jahr von 2 % ihrer Nutzerbasis zu bekommen.

Open-Source-Anwendungen sind Konkurrenten proprietärer Anwendungen, so wie öffentliche Krankenhäuser Konkurrenten privater Kliniken sind: Sie sind es nicht. Auf der einen Seite haben wir ein sozialistisches Projekt, das von der Überzeugung ausgeht, dass jeder ein Recht auf Gesundheitsversorgung hat, und wenn er sie sich nicht leisten kann, kommen wir zurecht, indem wir zusätzliches Geld in der Gemeinschaft auftreiben. Auf der anderen Seite haben wir Aktionäre, die Gewinne erzielen wollen und Chirurgen anstellen, die versuchen, ihr Haus in Malibu und ihre Porsche-Sammlung zu bezahlen. Wie sind sie Konkurrenten? Ein öffentlicher Dienst ist eine Möglichkeit, sicherzustellen, dass die Menschen die Mittel haben, ihre Rechte auszuüben, denn Freiheit ist nur theoretisch, solange man nicht die Mittel hat, tatsächlich von seinen Rechten Gebrauch zu machen. Ein privates Unternehmen, das Waren oder Dienstleistungen verkauft, ist eine Möglichkeit, aus Investitionen Geld zu machen. Der Unterschied ist politisch. Er ist auch wirtschaftlich, denn die Aktionäre nicht auf der Gehaltsliste zu haben, macht das Endprodukt ohnehin erschwinglicher.

Der blinde Fleck der „Freie-Software"-Bewegung war es, nicht über den Kontext und die Arbeitsstruktur nachzudenken, in der solche Software entsteht, entwickelt und gewartet wird. Dies lässt sich auf die Hacker-Kultur  zurückführen, die von Natur aus individualistisch und über Umwege kapitalismuskompatibel ist, und zwar durch Technophilie  und Technosolutionismus . „So-wie-es-ist-Teilen" (der eigenen Arbeit, des eigenen Codes, der eigenen Hacks) wurde mit „Sich-Kümmern" (um die Bedürfnisse, Grenzen und Herausforderungen anderer Menschen) verwechselt und mit quasi-hagiographischen Erzählungen ausgeschmückt. Wenn man einen Hammer hat, sieht alles wie ein Nagel aus: Wenn alles, was man kennt, Code ist, ist Code die Lösung für alles, und der Versuch, ihn in Philosophie und (nicht-revolutionäre) Politik zu verpacken, um „Code-Freiheit" zu definieren, verfehlt weiterhin das große Ganze, nämlich die Ausbeutung der Arbeit aller durch eine kleine, aber mächtige und sich selbst reproduzierende soziale Klasse. Während 2021 6 % der Weltbevölkerung Code schreiben konnten, war der Anteil derer, die sich in den 1980er Jahren, als die Freie-Software-Bewegung begann, überhaupt einen Personal Computer leisten konnten, viel kleiner. Privilegierte Minderheiten sind immer blind für ihre Privilegien: So erkennt man sie. Sie versäumten es zu erkennen, dass Freie Software nichts weiter als das Geistesprodukt dieser Privilegien war. Es ist Freiheit nur für diejenigen, die sie sich leisten können. Und die Tatsache, dass an dem Preisschild kein Dollarzeichen hängt, macht es hinterhältig. Es hat trotzdem ein Preisschild.

Die Freie-Software-Bewegung wurde so gestaltet, dass sie in diesen individualistischen, auf freies Unternehmertum und liberalen Markt ausgerichteten Kapitalismus passt, und ließ alle glauben, es genüge, jeden sein eigenes Projekt starten oder es von anderen forken zu lassen. Dann würde der Sozialdarwinismus  die Dinge schon regeln. Ja, aber… wer bezahlt die Arbeit? Schlimmer noch: Da der Kapitalismus der Arbeit nur dann einen Wert beimisst, wenn ihr Produkt auf einem liberalen Markt verkauft wird, und dieser Wert an der Knappheit des Produkts bemessen wird, wie genau sollen wir die Benutzer davon überzeugen, dass etwas Entmaterialisiertes, unendlich oft kostenlos Herunterladbares überhaupt einen Wert hat? Viele Open-Source-Projekte haben viele verschiedene Strategien ausprobiert, um ihre Arbeit zu finanzieren, sie sind allesamt prekär und lahmgelegt, weil sie nach wie vor eine von Natur aus kommunistische Arbeitsstruktur in einen kapitalistischen Rahmen pressen wollen (mehr dazu weiter unten).

Während Non-Profit-Organisationen bei humanitären Projekten funktionieren mögen, wo Spender niemals die eigentlichen Empfänger der Arbeit sein werden, sind Spenden bei Softwareprojekten interessengeleitet, weil die Spender Benutzer sind. Dies unterhält ein konsumentenähnliches Verhalten, bei dem passive (und gewissermaßen unterdrückte) Konsumenten auf die Güter warten, die von einer elitären Minderheit von Vorstandsmitgliedern geliefert werden, die das Sagen hat. Diese Non-Profit-Organisationen werden nach wie vor privat geführt, und die Öffentlichkeit hat kein anderes Recht, als das Spenden einzustellen, wenn sie sich nicht gehört fühlt. Der Vorstand der Linux Foundation  besteht fast ausschließlich aus Führungskräften von Hardware-Herstellern und GAFAM , der Vorstand der Free Software Foundation  besteht aus Wissenschaftlern und Computertechnikern. Es gibt dort keine Vertretung der Benutzer, es gibt vertikale hierarchische Strukturen „derer, die wissen" über „diejenigen, die brauchen", welche dieselbe Art von Herrschaft wie der Kapitalismus fortsetzen, nur ohne Profite.

Dies wird durch die Tatsache gerechtfertigt, dass die Open-Source-Lizenzen jede Form von Verantwortung (Gewährleistung) der Entwickler gegenüber den Benutzern von sich weisen, was es zu einer einseitigen Transaktion macht, die scheinbar alle Entscheidungsmacht den Entwicklern gibt. Aber all das ist natürlich ein Konstrukt und keine ausgemachte Sache. Auf der anderen Seite bringt der Quellcode, weil das kapitalistische Dogma so tief in die Gehirne der Benutzer eingeprägt ist, eine Software auf einen freien, entmaterialisierten und nicht-knappen Markt, der jede Vorstellung von kapitalistischem Wert aufhebt, was es für die Benutzer in Ordnung erscheinen lässt, das Produkt der Arbeit ohne Gegenleistung zu erhalten: eine weitere einseitige Transaktion. Unterdessen brennen einige Entwickler aus und erschöpfen sich, um vernünftigen Benutzersupport zu leisten, ohne ein vernünftiges Einkommen aus ihrer (ausgebeuteten) Arbeit zu erzielen, vielleicht in der Hoffnung, dass es sich langfristig auszahlen wird, sobald sie es „geschafft" haben. Oder die Entwickler akzeptieren die unausgesprochene Regel von Open Source (es sollte nur ein Hobby / eine Teilzeitbeschäftigung sein), was Open Source unweigerlich zurückwirft, als für immer armes Geschwister proprietärer Software. Oder schließlich beginnen einige Open-Source-Unternehmen wie Automattic  oder RedHat  mit der Zeit immer aggressiver gierig zu werden und sehen sich dem Gegenwind ihrer Communities gegenüber. Das ist nicht nachhaltig, für keine der beteiligten Parteien.

Wir müssen diese beiden parallelen, einseitigen Transaktionen in einen Kreislauf verwandeln. So geht das:

1. Keine Technologie kann außerhalb der Gesellschaft existieren, die sie hervorbringt. Technologie braucht Wissenschaft. Wissenschaft braucht Forschung. Forschung braucht Strukturen, in denen sie frei betrieben werden kann. Die Gesellschaft ist die Umgebung, in der all das geschieht, ebenso wie das Unterstützungssystem, das es geschehen lässt.
2. Keine Technologie kann ohne Arbeit existieren. Wenn das Produkt der Arbeit dem kapitalistischen System (knappheitsbasierter und wettbewerbsbasierter liberaler Markt) entkommt, dann sollte auch die Arbeit, die es hervorbringt, ihm entkommen.
3. Keine Technologie, die sich in Privatbesitz befindet, wird dem Gemeinwohl und dem öffentlichen Interesse dienen. Technologien, nicht nur Geräte, sollten ihren Benutzern gehören, nicht nur ihren Herstellern.
4. Arbeit ist der einzige Reichtum. Arbeiter sollten von ihrer Arbeit profitieren, ob sie nun auf einem liberalen Markt verkauft wird oder nicht: Sie sollte in jedem Fall bezahlt werden. Arbeit sollte in einem sicheren und fairen Umfeld stattfinden. Es ist eine kollektive, gesellschaftliche Verantwortung, dafür zu sorgen, denn das Produkt der Arbeit dient dem Gemeinwohl und dem öffentlichen Interesse. Arbeit, die diesen nicht dient, sollte schlicht eingestellt werden.
5. Technologien, die ihren Benutzern gehören, eröffnen den Weg zu einer neuen Art der Produktion: Zusammenarbeit zwischen Herstellern und Benutzern, anstelle von Wettbewerb zwischen Herstellern und Firmenkriegen, um Märkte zu gewinnen, indem man die Kunden von der Überlegenheit irgendeines Produkts überzeugt (wobei die Benutzer am Ende für die Werbung bezahlen…). Aber der Kapitalismus weiß nicht, wie man das Produkt der Kooperation verkauft, weil es keinen getrennten Käufer oder Verkäufer mehr gibt, sondern nur eine Gemeinschaft von Personen, die gemeinsam auf etwas hinarbeiten: ihre Bedürfnisse zu erfüllen, ihre theoretischen Rechte in tatsächliche Freiheit zu verwandeln, indem sie den Kontext schaffen, um sie auszuüben.
6. Es gibt eine gegenseitige Verantwortung der Hersteller gegenüber den Benutzern (ihre Bedürfnisse durch/mit Technologie zu erfüllen) und der Benutzer gegenüber den Herstellern (ihnen ein sicheres und faires Arbeitsumfeld und materielle Lebensbedingungen zu geben). Das sind die absoluten Grundlagen einer Gemeinschaft²…
7. Open Source, das zu wahrer Freiheit führt, kann nur innerhalb einer genossenschaftlichen  Struktur entstehen. Das ist ein alter, erprobter und bereits funktionierender Kommunismus, bei dem das Unternehmen (und damit das Open-Source-Projekt insgesamt) seinen Kunden und seinen Arbeitern gehört, die sich die Stimmrechte teilen. Das geht weit über einen bloßen Verzicht auf geistiges Eigentum (Open-Source-/freie Lizenz) hinaus.

Eine Genossenschaft ist eine Möglichkeit, diese Dichotomie zwischen „uns" und „ihnen", Herstellern gegenüber Benutzern, aufzubrechen, die gegenseitigen Groll nährt: Die Entwickler sind die Diktatoren, die die Anwendung zu ihrer persönlichen Spielwiese machen und denen die Benutzer stets dankbar sein sollten, egal wie sehr sie sie zerstören; die Benutzer sind die lästigen Blutegel, die ständig kryptische Issues und Feature-Wünsche aufwerfen, während sie zu wenig spenden.

In einer Genossenschaft sind Hersteller und Benutzer gleichermaßen Mitglieder-Anteilseigner. Ihnen allen gehört das Projekt, sie alle haben eine Stimme in der Generalversammlung. Das Projekt besteht darin, die Fotobearbeitung für die absehbare Zukunft frei zu machen, unter einer einheitlichen Vision davon, was Fotobearbeitung ist (wie technisch und feinkörnig sie sein sollte gegenüber wie einfach und benutzerfreundlich). Um dieses Ziel zu erreichen, sind viele Mittel im Spiel, wie Bildung, Interessenvertretung, Dokumentation und natürlich eine Softwareanwendung. Das Projekt ist mehr als nur ein Endprodukt, das einige Zeit brauchen kann, um zu erscheinen und fertig zu sein: Das Projekt ist alles darüber und darum herum, es ist ein Ziel und all die Mittel, um es Wirklichkeit werden zu lassen.

Die Verantwortung der Mitglieder besteht darin, ein Jahresbudget zu sichern, um alle Projektkosten zu decken, höchstwahrscheinlich aus jährlichen Mitgliedsbeiträgen. Aus diesem Budget wird in der Generalversammlung eine bestimmte Anzahl von Arbeitsstunden zu einem bestimmten Stundensatz beschlossen. Wie dieses Budget ausgegeben wird (welche Art von Aufgaben, Hardware, Werkzeugen usw.), wird ebenfalls in der Generalversammlung beschlossen. Für technische Aufgaben, wie die Softwareentwicklung, werden das die übergeordneten Ausrichtungen sein (wie die Verbesserung von Maskierung, Stapelverarbeitungs-Workflow usw.) und nicht Implementierungsdetails oder das eigentliche Design, die sich schlecht für demokratische Prozesse eignen. Entwickler könnten backend-orientierte Aufgaben vorantreiben (wie das Umschreiben oder Refactoring von technischen Schulden, um langfristige Wartungskosten zu senken), Benutzer könnten funktionsorientierte Aufgaben vorantreiben (wie die Unterstützung neuer Kamerafunktionen, Bildformate usw.): Der Zweck der Generalversammlung ist es, zu beraten und Prioritäten zu ordnen.

Die vereinbarten Aufgaben werden dann von bezahlten Arbeitern in der Reihenfolge der Priorität angegangen, bis das Arbeitsbudget aufgebraucht ist. Dies ist nicht auf technologische Arbeit und Entwicklung beschränkt, sondern gilt für jede Art von zuvor vereinbarter Arbeit. Wenn das Budget aufgebraucht ist, werden die Arbeiter berichten, wo sie in der To-do-Liste aufgehört haben, was sie fertigstellen konnten, was nicht, und welche Ressourcen zur Fertigstellung fehlten. Die Generalversammlung entscheidet dann, ob es möglich und wünschenswert ist, mehr Ressourcen zur Fertigstellung zu investieren, oder die verbleibenden Aufgaben in das nächste Jahresbudget zu verschieben. Dies gibt den Arbeitern Übersicht über ihr Jahreseinkommen, ohne Überengagement und Burn-out zu fördern.

Benutzer können Gremien bilden, um mit den Entwicklern zusammenzuarbeiten, um die tatsächlich auftretenden Probleme zu verstehen, Lösungen zu testen und in einem Designprozess zu validieren. Jeder Benutzer kann zu einem Arbeiter werden und beginnen, ein Einkommen für seine Arbeit an vereinbarten Aufgaben zu beziehen, vorbehaltlich der Zustimmung der Generalversammlung.

Das macht es zur Verantwortung eines jeden, sicherzustellen, dass die Ressourcen zum Vorankommen zusammengetragen werden, und den Arbeitern zu geben, was sie brauchen, um anständig, sicher und ohne ausgebeutet zu werden, arbeiten zu können. Keine Arbeit sollte kostenlos sein, unabhängig von der Aufgabe. Arbeit sollte nicht auf Programmierung oder andere technische Aufgaben beschränkt sein.

Die Grenzen der Demokratie

Demokratie durch Abstimmung bedeutet im Wesentlichen, den Willen der Mehrheit zum Ausdruck zu bringen, was bekanntermaßen Minderheiten unterdrückt hat. Sie ist daher nicht perfekt. Minderheiten könnten vernünftige und berechtigte Anliegen vorbringen, nur werden diese nicht von der Mehrheit geteilt. Menschen mit Behinderungen kommen einem in den Sinn: Einige Designdetails können die gesamte Anwendung für sie völlig unbrauchbar machen, obwohl sie nicht die Zahlen haben, um ihre Sichtweise in einer Abstimmung durchzusetzen. Auf der anderen Seite ist es nicht möglich, den eigentümlichen Bedürfnissen aller und jedes Einzelnen gerecht zu werden, ohne Monster zu erschaffen. Dies muss sorgfältig abgewogen und geschlichtet werden.

Die Verantwortung der Mehrheit besteht daher darin, zu identifizieren, wer die strukturellen Minderheiten sind, das heißt, welche Eigenschaften diese Minderheiten zusammenbinden (Gesundheitszustand, soziale Herkunft, Bildung, Einkommensniveau usw.). Wenn eine Minderheit ein Problem aufwirft, das für sie aufgrund einer der definierenden Eigenschaften dieser Minderheit blockierend ist, sollte es eine Möglichkeit geben, die Mehrheitsabstimmung zu umgehen oder neu zu gewichten. Dies bleibt noch zu definieren, aber der einfachste Weg, dies zu erfassen, ist während der Beratungen, was auf der Empathie und dem Verständnis der Mehrheit beruht.

Ein weiteres Problem jeder sozialen Gruppe ist das Gruppendenken , denn jede soziale Gruppe neigt dazu, mit der Zeit zu einem Klub zu verkommen. Gruppendenken liegt vor, wenn sich Individuen nicht frei fühlen, Probleme anzusprechen, die dem (vermeintlichen) Gruppenkonsens widersprechen, aus Angst vor Konsequenzen für ihren Platz und ihre Wahrnehmung in der Gruppe. Diese Konsequenzen können sehr subtil und dennoch sehr real sein. Es wird schädlich, wenn Individuen anfangen, innerhalb der Gruppe Entscheidungen zu unterstützen, die sie allein nicht unterstützt hätten: Das ist der Wendepunkt, an dem die individuelle Rationalität verloren geht. Um dies zu vermeiden, kann eine anonyme Abstimmung verwendet werden, aber sie gilt nicht für Beratungen, bei denen es notwendigerweise einen Redner gibt. Es gibt eine Kultur der gesunden Meinungsverschiedenheit aufzubauen, zu pflegen und zu fördern. Eine Möglichkeit, dieses Problem zu lösen, besteht darin, für jede Sitzung nach dem Zufallsprinzip einen „Advocatus Diaboli" zu ernennen, dessen Aufgabe es sein wird, ständig zu widersprechen und entsprechende Argumente darzulegen.

Von jeder Gemeinschaft, die auf einem gemeinsamen Interesse an Fotografie und freier Software basiert, ist zu erwarten, dass sie zugunsten reicher, gebildeter, computerkundiger, englischsprachiger Männer voreingenommen ist. Es wird eine bewusste Anstrengung erfordern, zu versuchen, Frauen, weniger gebildete Personen, nicht-westliche Bürger usw. einzubeziehen. In Kombination mit Demokratie-durch-Abstimmung und Gruppendenken kann es wirklich schädlich sein, mit einer solch sozial homogenen Gruppe zu beginnen, wenn dies nicht sorgfältig gehandhabt wird. Dies wird eine tägliche Herausforderung sein, deren sich jeder bewusst sein muss. Es wird außerdem den Survivorship Bias  nähren, bei dem die Ausgestoßenen nicht anwesend sind, um Rückmeldung darüber zu geben, warum sie nicht beigetreten sind, teilgenommen haben oder sich willkommen gefühlt haben, und die Ausgestoßenen werden zusätzliche Fürsorge benötigen, um erreicht und willkommen geheißen zu werden.³ Kein Maß an Rassismus oder Sexismus kann in einem solchen Umfeld toleriert werden, selbst als Witz, denn das würde die Mehrheit auf Kosten von Minderheiten lachen lassen, in einem Kontext, aus dem sie ohnehin schon herausgefiltert sind.

Demokratie ist auch ein langsamer Prozess. Es können Dinge geschehen, die eine rasche Entscheidung erfordern, wie ein Sicherheitsverstoß in den Projektserver oder die Social-Media-Konten oder eine dringende rechtliche Angelegenheit. Jemand sollte für kurzfristige Mandate gewählt werden, um solche Entscheidungen im Namen der Gemeinschaft schnell treffen zu können.

Die Grenzen von Experten gegenüber Laien

Genau wie Ärzte oder Anwälte haben Entwickler Nischenkompetenzen und -erfahrungen, die ihnen eine Art Macht und sogar Charisma gegenüber Laien verleihen. Diese Macht kann missbraucht werden, um die Mehrheit zu unterdrücken, indem ihr Mangel an Wissen zum Vorteil des Unterdrückers ausgenutzt wird. Diese Beziehung wird immer asymmetrisch sein, und das muss anerkannt werden. Außerdem werden die Entwickler während der Beratungen in der Generalversammlung konsultiert werden müssen, um die Machbarkeit von Aufgaben und die benötigten Ressourcen einzuschätzen, bevor Abstimmungen stattfinden.

Genau wie Ärzte, Anwälte usw. sollten Entwickler eine Art Ethikkodex einhalten, der mit ihrer symbolischen Macht einhergeht, darunter:

1. eine Pflicht, nach bestem Wissen ehrlich zu informieren und einfach zu erklären, was einfach erklärt werden kann,
2. eine Pflicht zu ordnungsgemäßem Vorgehen und gebotener Sorgfalt bei der Erforschung und Entwicklung von Lösungen,
3. eine Verpflichtung, im besten Interesse der Gemeinschaft zu arbeiten.

Auf der anderen Seite könnten Entwickler (oder andere Experten) von Laien als allwissende, allmächtige Zauberer wahrgenommen werden, die dann zu viel von ihnen verlangen. Obwohl Software ein recht formbares Medium ist, gelten dennoch nicht verhandelbare technische Beschränkungen, und nicht alles, was technisch möglich ist, ist auch möglich unter den gegebenen Umständen mit den gegebenen Ressourcen.

Beide Positionen müssen verstanden werden, um zu verhindern, dass gegenseitiger Groll wächst.

Die Grenzen der Zusammenarbeit

Jeder ist ein Designer.

Jeder Beruf, von dem man nichts versteht, sieht leicht auszuüben aus. Das Entwerfen und Bauen technischer Objekte ist einer davon. Es ist sogar reizvoll, dazu beizutragen. Aber eine Software, die von Tausenden von Benutzern außer einem selbst als Werkzeug verwendet wird, ist nicht dasselbe wie der eigene Nachttisch.

Benutzer sollten willkommen sein, sich an der Problemdefinition zu beteiligen: Man geht von einem oder mehreren Benutzern aus, die ein bestimmtes Problem in einem bestimmten Workflow haben, prüft, ob es sich nicht bereits mit den aktuellen Werkzeugen und vielleicht etwas Aufklärung lösen lässt, und versucht andernfalls zu erheben, wie viele Benutzer dasselbe Problem teilen. Wenn das Problem nicht für alle genau dasselbe ist, versucht man, einen gemeinsamen Ausdruck des Problems zu finden, der es erlaubt, es zu verallgemeinern.

Sobald das Problem definiert ist, beginnt der Designprozess, der formalen Schritten folgt, um zu vermeiden, dass man zur ersten (und höchstwahrscheinlich nicht optimalen) Lösung hetzt, denn, noch einmal, die menschliche Intuition ist besser geeignet, um Nachttische zu bauen, als um Werkzeuge, die von Tausenden verwendet werden. Aber dem Prozess zu folgen, reicht nicht aus.

Psychologie und Kognitionswissenschaften laufen auf einen Konsens hinaus: Die beste Größe für Arbeitsteams liegt zwischen 4 und 7 Mitgliedern. Ab 8 Mitgliedern beginnt die Produktivität dramatisch zu sinken.⁴⁵⁶ Bei einem Team von 4 Mitgliedern gibt es 6 zwischenmenschliche Kommunikationskanäle, während es bei 8 Mitgliedern 28 Kommunikationskanäle sind. Dies macht es kognitiv schwierig, den Überblick über alle Beteiligten zu behalten, wer wofür zuständig ist, nonverbale Signale zu verarbeiten, was eine Kommunikationsüberlastung erzeugt. Ab 9 Mitgliedern beginnen sich Klüngel zu bilden, Politik mischt sich in den Prozess, und das soziale Faulenzen  setzt ein.⁴⁵

Das bedeutet, dass die Arbeit in Arbeitsteams aufgeteilt werden sollte, die jeweils nicht mehr als 6 bis 7 Mitglieder haben, auch wenn es für die Gemeinschaft insgesamt reizvoll sein mag, an allem Anteil zu nehmen. Kommunikation ist hier der entscheidende Punkt: Man braucht genau die richtige Menge davon, nicht mehr und nicht weniger, sonst sättigt sie die Teammitglieder kognitiv und behindert die Kommunikation selbst. Da ist es die Arbeit selbst, die Schaden nimmt.