Diskursfigur 7: Jenseits der Exklusion
Das ist Teil 7 einer Serie wöchentlich erscheinender Artikel, deren englische Fassung im Journal of Peer Production erscheinen soll. In den Artikeln versuche ich zehn Diskursfiguren zu beschreiben, wie sie im Oekonux-Projekt in über zehn Jahren der Analyse Freier Software und commons-basierter Peer-Produktion entwickelt wurden. Mehr zum Hintergrund im einleitenden Teil. Bisher erschienene Teile: 1, 2, 3, 4, 5, 6.
Diskursfigur 7: Jenseits der Exklusion
[English]
Eine der basalen Spaltungen, die der Kapitalismus erzeugt, ist die zwischen denen, die drinnen sind, und denen, die es nicht sind. Dieses Drinnen-Draußen-Muster betrifft nicht nur die Klassenspaltung (vgl. Diskursfigur 6), und es ist auch nicht eine große Spaltung. Es ist ein struktureller Mechanismus der Inklusion und Exklusion entlang aller möglichen gesellschaftlichen Differenzen: Arbeitsplatzbesitzer_innen vs. Arbeitslose, Reiche vs. Arme, Männer vs. Frauen, Nicht-Weiße vs. Weiße, Bosse vs. Untergeordnete, Eigentümer_innen der Produktionsmittel vs. Eigentumslose, Krankenversicherte vs. Nichtversicherte usw. Die Spaltungen müssen als strukturelles Grundprinzip des Kapitalismus begriffen werden: Ein Einschluss auf der einen Seite bedeutet einen Ausschluss auf der anderen Seite. Für das Individuum heißt das, dass jedes persönliche Vorankommen stets zu Lasten von anderen geht, die nicht vorankommen oder zurückfallen.
Im Allgemeinen sind Commons jenseits der Mechanismen der Exklusion. Je mehr aktive Menschen zum Beispiel bei Freier Software in einem Projekt mitmachen, desto schneller und besser kann ein Ziel erreicht werden. Hier wird die Beziehung zwischen den Menschen nicht durch Inklusions-Exklusions-Mechanismen bestimmt, sondern durch eine inklusive Reziprozität (Meretz 2012). Der Maintainer eines Projekts versucht so viel wie möglich aktive Leute einzubeziehen, strebt nach einer kreativen Atmosphäre und versucht Konflikte in einer Weise zu lösen, das so viele Leute wie möglich dem »groben Konsens« und dem »lauffähigen Programm« folgen können (»rough consensus, running code«).
Wenn ein Konsens nicht möglich ist, dann ist die beste Lösung ein Fork, die Aufteilung eines Projekts. Es ist eine riskante, aber machbare Option, um verschiedene Richtungen der Entwicklung auszuprobieren. Viele der bestehenden Forks (z.B. zwischen KDE und GNOME) arbeiten eng zusammen oder halten eine Atmosphäre der Kooperation aufrecht. Ja, es gibt auch Beispiele des Kampfes gegeneinander. Aber bei diesen unproduktiven Forks spielt das Einwirken fremder Interessen von außen eine wichtige Rolle. Die Firma Oracle versuchte ein Kommando- und Kontroll-Regime einzurichten, nachdem sie OpenOffice als Bestandteil des Kaufs der Firma Sun übernommen hatten. Der Fork zu LibreOffice durch viele wichtige Entwickler_innen war ein Akt der Selbstverteidigung und Selbstbestimmung, um die Bedingungen der Selbstentfaltung aufrechtzuerhalten. Sie wollten nicht zum alten »Arbeitsmodus« der Entwicklung zurückkehren (vgl. Diskursfigur 5).
Während der Kapitalismus strukturell auf Exklusionsmechanismen basiert, erzeugt und befördert die commons-basierte Peer-Produktion die Inklusion.
Kleine Korrektur: Gnome ist kein Fork von KDE oder umgekehrt, da sie nicht auf dem gleichen Code basieren. Gnome war lediglich eine Reaktion auf KDE, wurde aber ohne den Code von KDE entwickelt.
@Daniel: GNOME war kein technischer Fork, insofern hast du recht. Es war aber ein Lizenz-Fork, da damals QT von Trolltech (auf dem KDE basiert) nicht unter der GPL stand (wurde dann erst später nachgeholt).