In der dynamischen Welt der Softwareentwicklung erleben wir zunehmend, wie kommerzielle oder proprietäre Softwareprojekte geöffnet werden, also als Open-Source-Software zur Verfügung gestellt werden. So wurde z.B. Azure RTOS von Microsoft zu einem Open-Source-Projekt unter der Leitung der Eclipse Foundation transformiert. So kann die Software unter einem anderen rechtlichen und organisatorischen Dach weitergeführt werden. Dadurch können z.B. Hosting, Administration und Austauschplattformen zentral kooridniert und Ressourcen effizienter eingesetzt werden.
Communitybuilding als Schlüsselfaktor
Dieser administrative Aufwand hinter einem Softwareprojekt kann viel Zeit in Anspruch nehmen, deswegen kann der Trend, eine Software zu öffnen, besonders für kleinere Projekte wegweisend sein. Doch auch Softwareprojekte, die bereits offen zur Verfügung stehen, können davon profitieren, die Administration an eine übergeordnete Organisation auszulagern.
Unser Ansatz als gemeinnütziger Verein besteht darin, Projekte auf externen Wunsch hin zu übernehmen und sie als Open Source mit einer lokalen Coder-Community weiterführen. Wer an der Entwicklung einer Software mitwirkt, investiert oft viel Zeit, Geld und Hirnschmalz. Die Begeisterung für die Projektidee, der praxisfokussierte Lerneffekt und das Miteinander sind dabei starke Motivatoren, aber keine zuverlässige und langfristige Strategie. Deswegen reflektieren und analysieren wir vor der Migration eines Softwareprojektes die Rahmenbedingungen und überlegen gemeinsam, wo es hingehen soll und überprüfen, ob eine Software zu unserem Satzungszweck passt bzw. ob die Entwickler:innen eine Transformation in diese Richtung anstreben wollen.
Die Öffnung von Softwareprojekten bedeutet in diesem Zusammenhang eine Kultur des Teilens und der Zusammenarbeit. Entwickler:innen können voneinander lernen, bewährte Praktiken austauschen und gemeinsam an neuen Ideen arbeiten. Dies führt zu einer stärker vernetzten und kooperativen Coder Community, die permanent und langfristig an einem Projekt feilt.
Potenziale offener Software
Generell ergeben sich durch die Öffnung einer Software bzw. die Migration einer offenen Software zu einer übergeordneten Organisation diverse Möglichkeiten: Die Transparenz des Quellcodes ermöglicht z.B. den Anwender:innen, die Funktionsweise der Software zu verstehen, Sicherheitsaspekte zu überprüfen und sicherzustellen, dass ihre Anforderungen erfüllt werden.
Die Zusammenarbeit in einer offenen Entwicklergemeinschaft fördert auch die Lösung von Problemen (Issues) und die schnelle Identifizierung von Fehlern (Bugs). Durch die Beteiligung einer breiten Gruppe von Entwickler:innenn mit unterschiedlichen Expertisen können Bugs schneller erkannt und behoben werden, was die Stabilität und Qualität der Software verbessert.
Durch die offene Verfügbarkeit können Softwareprojekte leichter wiederverwendet und angepasst werden, was zu einer effizienteren Nutzung von Ressourcen führt. Dies trägt dazu bei, die Lebensdauer von Softwareprojekten zu verlängern und den ökologischen Fußabdruck zu reduzieren.
Die Transformation zu Open Source bietet auch Chancen für eine nachhaltige Finanzierung. Durch Crowdfunding, Spenden und andere Modelle kann die Community die Entwicklung finanziell unterstützen. Dies schafft Unabhängigkeit von traditionellen Geschäftsmodellen und ermöglicht es, dass Softwareprojekte auch dann florieren können, wenn sie nicht ausschließlich auf kommerziellen Verkauf angewiesen sind.
Herausforderungen offener Software
Neben den vielen positiven Aspekten ist insbesondere die Transformation bzw. Migration eines Softwareprojekts herausfordernd, da bestehende Strukturen unter Umständen abgeändert werden müssen, anstatt dass direkt zu Projektbeginn überlegt wird, was es zu beachten gilt.
Die größte Unsicherheit stellen dabei offene Softwarelizenzen dar. Denn teilweise ist nicht mehr genau nachzuvollziehen, welche Entwickler:innen was beigesteuert haben – oder genauer: Auf Plattformen wie GitHub oder Codeberg lässt sich zwar nachvollziehen, wer wann was beigesteuert hat, aber für viele Codeschnipsel wird auf bewährte wiederkehrende Befehle zurückgegriffen. So ist eine bestimmte Zusammensetzung von Codeschnipseln einzigartig, aber die einzelnen Bestandteile nicht unbedingt und es ist schwierig, Urheberrechte genau zu differenzieren.
Copyleft-Lizenzen, wie die GNU General Public License (GPL) erfordern z.B. , dass abgeleitete Werke unter derselben Lizenz veröffentlicht werden. Zusätzlich kann die Inkompatibilität zwischen verschiedenen freien Softwarelizenzen die Integration und gemeinsame Nutzung von Code erschweren. Insbesondere die Zusammenarbeit von Entwickler:innen mit unterschiedlichen Lizenzpräferenzen kann dadurch beeinträchtigt werden.
Ein weiterer Aspekt betrifft mögliche Konflikte im Zusammenhang mit Patenten. Einige freie Softwarelizenzen beinhalten Patentklauseln, während andere dies explizit ausschließen. Die Verwaltung von Lizenzkonformität erfordert also sorgfältiges Management, um sicherzustellen, dass alle Beteiligten die Lizenzbedingungen respektieren und einhalten.
Softwaremigration als Transformationsprozess
Das schaffen wir u.a. durch einen semi-strukturierten Transformationsprozess, der zwar durch aufeinander aufbauende Schritte strukturiert ist, aber flexibel auf die individuellen Rahmenbedingungen eines Softwareprojekts eingeht. Ein wesentlicher Bestandteil ist dabei der Transition-Workshop, bei dem Worst- und Best-Case-Szenarien ausgearbeitet werden.
Die gemeinschaftliche Entwicklung von Rollenbeschreibungen ermöglicht es den ursprünglichen Entwickler:innen, selbst zu entscheiden, inwieweit sie nach der Übergabe beteiligt werden möchten. Da wir ein gemeinnütziger Verein sind, liegt eine Mitgliedschaft nahe. Daneben können die Entwickler:innen auch regelmäßig auf dem Laufenden oder punktuell konsultiert werden. Diese Rollen sind flexibel und richten sich nach Verfügbarkeit, Werten und Bedürfnissen aller Beteiligten.
Nachdem die Tätigkeitsbereiche, Zuständigkeiten und Erwartungen festgelegt sind, folgt eine formale Übergabe. Dabei wird eine Rahmenvereinbarung unterzeichnet, Passwörter und Domains werden auf unsere datenschutzkonformen Server in Deutschland übertragen. Falls vorhanden, findet ein Onboarding für die Community statt, bei dem auch hier Rollen geklärt und Engagierte vernetzt werden.
Der Neustart umfasst eine Überarbeitung des Quellcodes hinsichtlich digitaler Suffizienzoptimierung und die Veröffentlichung der Software als Open Source auf Codeberg. Je nach Projekt und Zielsetzung wägen wir passende Lizenzen wie die GPL, MIT oder Apache License ab.
Gleichzeitig wird Fundraising betrieben, um die Weiterentwicklung zu unterstützen. Der gesamte Prozess wird dokumentiert, evaluiert und optimiert, um für künftige Softwareprojekte einen möglichst angenehmen und effizienten Prozess zu etablieren.
Die Transformation von kommerziellen Softwareprojekten in Open Source bietet also insgesamt nicht nur technische Möglichkeiten, sondern schafft auch eine konstruktive, partizipative und nachhaltige Entwicklungsumgebung, die von einem breiten Spektrum von Entwickler:innen und Nutzer:innen getragen wird.
Was haltet ihr von diesem Ansatz? Welche Potenziale und Herausforderungen seht ihr noch? Kennt ihr ein Softwareprojekt, das ein Zuhause braucht? Hinterlasst gerne einen Kommentar oder schreibt uns – euer Feedback ist für uns von unschätzbarem Wert.
