Das Verhältnis zwischen Open Source Projekten und ihren Distributionen ist einzigartig. Die Distributionen benötigen die Open Source Projekte, um Pakete zu schnüren, während die Open Source Projekte die Distributionen brauchen, um ihren Quellcode zu verbreiten. Diese Partnerschaft ist so gut eingespielt, dass große Open Source Gemeinschaften wie KDE keine Pakete mehr bereitstellen, sondern nur noch den Quellcode zum Download anbieten. Die Distributionen sind so eng mit den Projekten verbunden, dass sie Zugriff auf die Quellcode-Pakete vor allen anderen erhalten, um rechtzeitig zum Release Pakete bereitstellen zu können.
Was sind Upstream und Downstream?
Die Beziehung zwischen den Open Source Projekten und ihren Distributionen hat sogar eigene Namen. Die Open Source Projekte werden als “Upstream” bezeichnet und die Distributionen als “Downstream”. Die Projekte fließen also flussaufwärts und der Quellcode strömt stromabwärts zur Distribution. Patches, die von den Distributionen an die Projekte zurückfließen, werden als “to upstream” bezeichnet.
Mir als Maintainer einer Upstream Software sind die “Downstreams” sehr wichtig. Ich kenne die Paketbetreuer unserer wichtigsten Distributionen und unterstütze sie regelmäßig bei der Integration von KWin und der Priorisierung von Bugreports. Genauso wie Upstream die Downstreams braucht, erwartet Upstream auch, dass sich die Downstreams um Upstream kümmern. Eine Sache, die für uns Upstream-Entwickler sehr wichtig ist, ist die Anzahl der integrierten Patches. Wir erwarten von einem guten Downstream, dass Patches “geupstreamed” werden. Wenn das nicht der Fall ist, stellt sich immer die Frage: Warum? Oft wird dann der Vorwurf erhoben, dass Distributionen die Upstreams mit ihren Patches zerstören.
Freiheit des Downstreams
Natürlich ist es einem Downstream erlaubt, den Quellcode zu verändern und zu verteilen. Die dritte Freiheit der Free Software Definition macht dies klar:
Die Freiheit, Kopien deiner modifizierten Versionen an andere zu verteilen (Freiheit 3). Dadurch kannst du der gesamten Community die Möglichkeit geben, von deinen Änderungen zu profitieren. Der Zugriff auf den Quellcode ist eine Voraussetzung dafür.
In den letzten Tagen hat jeder, der die Open Source Welt im Auge behalten hat, wahrscheinlich verstanden, worauf ich mit meiner Einleitung hinauswill: Der Fall Banshee und Canonical, oder anders gesagt: Upstream und Downstream. Zum eigentlichen Fall werde ich nichts mehr sagen, das haben andere bereits viel besser erledigt.
Für mich als Maintainer einer Upstream Software ist das Verhalten des Downstreams jedoch ein äußerst interessanter Fall zum Studieren. Ich bin sicher, dass viele Upstream Entwickler diesen Fall genau beobachten und auch andere Downstreams genau darauf achten. Fakt ist: Canonical hat das Recht, den Code gemäß der dritten Freiheit zu ändern. Ob sie es tun sollten, ist eine andere Frage. Hier ist der relevante Quellcode in Banshee:
// We ask that no one change these affiliate codes. ALL (100%) revenue// generated by these affiliate IDs is sent directly to the GNOME// Foundation. The GNOME Foundation controls/owns these affiliate IDs.// Please help support Free Software through the GNOME Foundation!
Ob es moralisch vertretbar ist, dass ein Unternehmen diesen Code ändert, um selbst davon zu profitieren, muss jeder für sich selbst entscheiden. Für mich persönlich ist es befremdlich zu sehen, dass ein Downstream den Code gegen den Wunsch des Upstream Projekts ändert – auch wenn es sein gutes Recht ist. Es ist noch befremdlicher zu sehen, dass das Geld eigentlich an eine gemeinnützige Organisation gehen soll. Der finanzielle Beitrag ist dabei eher gering. Banshee bringt derzeit etwa 10.000 $ pro Jahr ein. Wir können nicht wissen, wie viel Ubuntu beitragen würde, aber meine Vermutung ist, dass es nicht viel mehr wäre. Der aktuelle Beitrag reicht vielleicht aus, um einen Entwickler einen Monat lang zu unterstützen oder einen Sprint zu organisieren. Die Bewertung überlasse ich dem Leser.
Das Problem liegt im Vorgehen
Für mich liegt das eigentliche Problem nicht darin, dass Canonical den Code geändert hat, sondern in der Vorgehensweise. Es ist meiner Meinung nach mehr als nur schlechter Stil, zunächst eine Diskussion mit den Entwicklern zu beginnen und ihnen zwei Optionen zur Wahl zu stellen, um dann einstimmig zur abgelehnten Option zu wechseln. Persönlich denke ich auch, dass das Hauptproblem hier ein Kommunikationsproblem seitens Canonical war. Und damit meine ich nicht, dass überhaupt Optionen angeboten wurden, wie Mark Shuttleworth es verteidigt hat, sondern dass das Upstream Projekt falsch angesprochen wurde.
Als Distribution sollte man seine Upstreams gut kennen. In Bezug auf die beiden Optionen hätte Canonical im Voraus klar sein müssen, wie sich die Entwickler entscheiden würden. Canonical hätte also wissen müssen, dass die gewünschte Option nicht gewählt wird, und das spätere Durchsetzen stößt jeden Entwickler vor den Kopf. Natürlich wäre es falsch gewesen, gar nicht zu kommunizieren, genauso wie zu kommunizieren, dass es jetzt einfach so gemacht wird. Es ist jedoch durchaus möglich, dass die Community selbst den Vorschlag zur Aufteilung der Einnahmen gemacht hätte – wenn es unbedingt sein müsste. Hier liegt eine klare Aufgabe für einen Community Manager – den Ubuntu bereits hat.
Canonical hat sich mit der ganzen Geschichte keinen Gefallen getan. Canonical und auch Ubuntu stehen schon länger unter genauer Beobachtung von Upstream Projekten. Immer wieder gibt es Vorwürfe, dass Canonical nur nimmt und nichts zurückgibt (vergleiche Diskussionen über Kernel- und GNOME-Quellcodebeiträge). Auch die Art und Weise, wie Canonical mit der Community umgeht, wird kritisiert (Urheberrechtsübertragung, Ayatana, Unity). Ich habe persönlich schon lange und intensiv über Canonical nachgedacht und mich immer wieder gefragt, ob Canonical überhaupt Open Source versteht. Für mich passt das aktuelle Geschehen (leider) zu meinem Bild von Canonical – und wenn viele Entwickler genauso denken, dann ist das eine sehr gefährliche Entwicklung für Canonical. Wenn sich Canonical zu sehr von allen Upstream Projekten distanziert, stehen sie bald alleine da und ob sie dafür die Manpower und Kompetenz in allen Bereichen haben, ist mehr als fraglich.
Hinweis: In diesem Text fehlen viele Fußnoten. Aus aktuellem Anlass habe ich mich entschieden, meine Quellen nicht anzugeben und dem Leser das Suchen der Quellen selbst zu überlassen. Bei der großen Anzahl von Quellen zu diesem Blogpost habe ich leider den Überblick verloren. Dies ist jedoch kein Plagiat, auch wenn Gedanken aus anderen Quellen übernommen wurden. Dies erkennt man schon daran, dass alle nicht angegebenen Quellen auf Englisch sind und dieser Post auf Deutsch verfasst wurde.
=-=-=-=-= Powered by Blogilo
