Home > Sicherheits- und Compliance-Blog > Unkategorisiert > Warum ownCloud ein Open Source Program Office einführt – und die CLA abschafft

Warum ownCloud ein Open Source Program Office einführt – und die CLA abschafft

von David Walter updated Mai 6, 2026 Kiteworks News

Lesezeit: 7 Minuten

Heute startet Kiteworks aus Regensburg offiziell ein Open Source Program Office (OSPO) mit einer veröffentlichten Governance Charter v0.1, stellt die Contributor License Agreement ein, führt ein Developer Certificate of Origin-Beitragsmodell ein, eine formale KI-unterstützte Beitragsrichtlinie und vieles mehr. Das OSPO fungiert als Governance-Gremium neben einer aktiven Produktionslinie, die aktuell besteht aus: ownCloud Infinite Scale mit vierteljährlichen Releases, ownCloud Classic mit einem bevorstehenden Upgrade auf PHP 8.3, iOS und Android in der Pipeline, dem MCP Server mit einer Beta-Version und vielem mehr. Dieser Beitrag zeigt, was heute bereitgestellt wird, was in Arbeit ist und was Mitwirkende, Kunden und Partner als Nächstes erwarten können.

Wichtige Erkenntnisse

Das OSPO ist ein strukturelles Bekenntnis, kein Marketinginstrument. Die Governance Charter definiert Rollen, Entscheidungsfindung und Transparenzverpflichtungen mit einem Weg zu v1.0 nach Einbindung des Community Advisory Boards.
Die bisherige CLA wird eingestellt. Beiträge erfolgen künftig per DCO-Sign-off (git commit -s), wobei die Urheberrechte beim Beitragenden verbleiben. Es erfolgt keine Abtretung der Urheberrechte mehr an die ownCloud GmbH.
KI-unterstützte Beiträge sind willkommen. Die Richtlinie setzt vier Anforderungen: Offenlegung, Verständnis, Testen und Einhaltung der Lizenzbedingungen. Für alle Pull Requests gilt derselbe Prüfmaßstab. Wir verstehen Inklusion über reine Entwicklungskompetenz hinaus.
Das Sicherheitsprogramm ist aktiv. Das VDP unter security.owncloud.com, die YesWeHack-Bug-Bounty mit gestaffelten Prämien bis zu 5.000 US-Dollar für kritische Funde.
Zwei Plattformen, ein Bekenntnis. ownCloud Classic läuft auf PHP 8.3 und wird aktiv gepflegt; oCIS ist die moderne, datenbankfreie Go-native-Architektur. Ein unterstützter ownCloud Classic-zu-Infinite Scale-Migrator ist in Kürze unter https://github.com/owncloud/migrate_to_ocis und im ownCloud 10 Marketplace verfügbar.
Die Einführung eines Community Advisory Boards, die öffentliche Produkt-Roadmap und der jährliche OSPO-Bericht sind Meilensteine mit verbindlichen Zielzeiträumen, keine bloßen Absichtserklärungen.

ownCloud hat zwei Forks erlebt — Nextcloud 2016 und OpenCloud 2025. Wir haben beide reflektiert. Kurz gesagt: Kommerziell geführte Open-Source-Projekte benötigen inklusive Governance und konsistente öffentliche Kommunikation, schriftlich und nicht nur als Absicht. Das OSPO ist die operative Antwort darauf.

Table of Contents

Das OSPO ist Kiteworks unterstellt und wird von Kiteworks finanziert. Wir sind kein von einer Stiftung geführtes Projekt und geben das auch nicht vor. Unser Bekenntnis ist, dass Steuerung öffentlich erfolgt, jede Begründung dokumentiert wird, die Community echte Einflussmöglichkeiten hat und jedes Governance-Dokument offen für Kommentare und Überarbeitung ist. Das von uns gewählte Wort für diese Beziehung ist Stewardship: Kiteworks als unternehmerischer Treuhänder für nachhaltige Investitionen in Engineering, Sicherheit und Governance, mit klaren schriftlichen Grenzen zwischen den Open-Source-Projekten und den kommerziellen Enterprise-Ebenen für menschliche und KI-Datengovernance, Kontrolle und Compliance.

Der Start erfolgt mit einem Manifest-Paket aus mehreren Dokumenten: Vision & Mission, Manifest, Vorwort von Kiteworks-CSO Tim Freestone, Produktvision für oCIS, Governance Charter, Code of Conduct, Contribution Guide, KI-unterstützte Beitragsrichtlinie, Security Disclosure Policy sowie Empowerment- und Engagement-Dokumente. Alle sind ab heute verfügbar und unterliegen der 30-tägigen öffentlichen Kommentierungsfrist, die die Charter für jede künftige Änderung vorsieht.

Abschaffung der CLA: Was sich durch den DCO für Beitragende ändert

Die bisherige Contributor License Agreement verlangte von Beitragenden die Übertragung der Urheberrechte an die ownCloud GmbH. Das funktionierte rechtlich, war aber ein Hemmnis für Beschaffungsteams in Unternehmen und unabhängige Beitragende und passte nicht zur gewünschten Governance-Haltung.

Beiträge erfolgen jetzt nach dem Developer Certificate of Origin — eine Bestätigung pro Commit, dass Sie berechtigt sind, den Beitrag unter der Repository-Lizenz einzureichen. Das sieht so aus:

git commit -s -m "Add this awesome implementation to ownCloud Infinite Scale"

Der -s-Parameter fügt eine Signed-off-by:-Zeile mit Ihrem Namen und Ihrer E-Mail hinzu. Das war’s. Sie behalten das Urheberrecht. Sie bestätigen die Herkunft. Reviewer können das Sign-off in der CI prüfen. Dasselbe Modell nutzt der Linux-Kernel seit zwei Jahrzehnten. Frühere Beiträge unter der alten CLA bleiben unter ihren ursprünglichen Bedingungen; ab jetzt gilt der DCO.

Neue Repositories verwenden standardmäßig die Apache License 2.0. Bestehende Repositories werden in absehbarer Zeit auf Apache 2.0 umgestellt. Das braucht Zeit, da alle bisherigen Commits, unterzeichneten CLAs, Lizenzen, genutzte Drittanbieter-Lizenzen und Ursprünge einzeln geprüft werden müssen.

Die Governance Charter definiert vier Rollen: Contributor, Reviewer (kann PRs freigeben), Maintainer (Merge-Berechtigung und Architekturentscheidungen im eigenen Bereich) und OSPO (Governance-Policy, Streitbeilegung innerhalb von 10 Werktagen). Bei Uneinigkeit mit einer Maintainer-Entscheidung kann eskaliert werden; das OSPO prüft, konsultiert und trifft fristgerecht eine verbindliche Entscheidung. Governance, die 90 Tage für die Klärung eines Beitragskonflikts braucht, ist keine Governance, sondern Abschreckung.

Die KI-unterstützte Beitragsrichtlinie: Das Werkzeug willkommen heißen, die Messlatte anheben

Wir veröffentlichen auch etwas, das viele kommerziell geführte Open-Source-Projekte bisher vermieden haben: eine formale Position pro KI-unterstützte Beiträge. Unsere Haltung ist klar. KI-unterstützte Beiträge sind willkommen und werden am gleichen Qualitätsmaßstab gemessen wie alle anderen Beiträge. Im Review-Prozess zählt nicht, wie der Code entstanden ist, sondern dass er funktioniert, getestet, dokumentiert und wartbar ist.

Die Richtlinie definiert vier Anforderungen für jeden KI-unterstützten Pull Request:

Offenlegung. Im PR-Beschreibungstext muss stehen, dass KI-Tools genutzt wurden, inklusive Angabe des Tools: Claude Code, GitHub Copilot, Cursor oder ein anderes. Das ist kein Makel, sondern Transparenz und hilft, unsere Review-Prozesse zu verbessern.
Verständnis. Sie müssen verstehen, was der Code tut. Wenn ein Reviewer fragt, warum eine Funktion einen Fehler so behandelt, und die Antwort lautet „das hat die KI geschrieben“, ist der PR nicht bereit.
Testen. KI-generierter Code benötigt Tests — Unit-Tests für Logik, exploratives Testen für UI. Die CI erkennt vieles, aber ersetzt nicht das Nachdenken darüber, was der Code tatsächlich leisten soll.
Einhaltung der Lizenzbedingungen. Sie sind für die Herkunft jeder Codezeile in Ihrem PR verantwortlich. Prüfen Sie, dass Ihr KI-Tool keinen Code aus inkompatiblen Lizenzen übernommen hat.

oCIS wurde bereits nach diesem Workflow weiterentwickelt, und die vollständige Entwicklermethodik ist unter owncloud.dev veröffentlicht. Auch unsere internen Engineering-Teams nutzen diese Tools und halten sich an dieselben Standards: Offenlegung, wo angebracht, vollständiges Verständnis des generierten Codes und menschliche Verantwortung für jeden Merge.

Der Subtext ist wichtig. Es besteht ein echtes Risiko, dass KI-unterstützte Entwicklung als Argument genutzt wird, um Beiträge von weniger erfahrenen Entwicklern auszuschließen. Wir wählen bewusst den gegenteiligen Ansatz. Wenn Sie eine Vision zur Verbesserung von ownCloud haben und KI Ihnen hilft, diese Vision in funktionierenden Code umzusetzen, wollen wir Ihren Beitrag. Was wir nicht akzeptieren können, sind Beitragende, die während des Reviews verschwinden. Die menschliche Verantwortung ist der Kern der Richtlinie. Aber Senior-Level-Coding darf kein Werkzeug zur Exklusion werden. Open Source war und ist Inklusion.

Zwei Plattformen, ein Bekenntnis: Die Zukunft mit oCIS gestalten, Vertrauen mit Classic bewahren

Der OSPO-Start ist auch der richtige Moment, um das Portfolio klar zu beschreiben. ownCloud Infinite Scale (oCIS) ist die aktuelle Plattform: in Go geschrieben, Apache 2.0, mit einer datenbankfreien, Go-nativen Architektur, die Metadaten in Message-Pack-Dateien direkt auf dem Node über die DecomposedFS-Abstraktion speichert. Es gibt keine zentrale SQL-Datenbank, die den Plattformstatus hält, wodurch eine ganze Klasse von Datenbank-Problemen entfällt: kein Schema-Migration beim Upgrade, kein SQL-Flaschenhals unter Last, kein Privilegien-Eskalationspfad auf Datenbankebene und Metadaten, die mit der Datei bei Standard-Dateisystemoperationen mitwandern.

Dasselbe kompilierte Binary skaliert von einem einzelnen Prozess auf einem kleinen Server bis zu verteilten Microservices auf Kubernetes. Produktions-Storage-Backends sind POSIX/NFS und S3-kompatibler Objektspeicher (AWS, MinIO, Ceph). CERN EOS ist als Tech Preview-Backend verfügbar, nicht für den Produktivbetrieb. Authentifizierung ist ausschließlich OIDC. Richtlinien sind programmierbar via OPA/Rego über die File Firewall. Federation nutzt Open Cloud Mesh. Office-Integration läuft über gehärtetes WOPI mit Collabora und ONLYOFFICE. Audit-Logs werden als strukturiertes JSON für SIEM-Ingestion bereitgestellt. Jede Schnittstelle der Plattform — WebDAV, OIDC, OCM, CS3APIs, LibreGraph, OPA/Rego — ist ein offener Standard oder eine veröffentlichte Spezifikation. Die Plattform läuft produktiv im Forschungs-Computing, z. B. bei CERN mit über einer Milliarde Dateien und Multi-Petabyte-Umfang, sowie in öffentlichen Einrichtungen wie der bayerischen Schulcloud (ByCS).

ownCloud Classic — die Linux-, Apache-, SQL- und PHP-Plattform — wird auf PHP 8.3 aktualisiert und aktiv gepflegt, mit laufenden Sicherheits- und Wartungs-Updates. Ein unterstützter Classic-zu-oCIS-Migrator steht kurz vor der Veröffentlichung. Kunden (Community und Enterprise) wechseln nach eigenem Zeitplan, sobald der Migrator allgemein verfügbar ist.

So können Sie sich beteiligen

Die Mechanismen, die es noch nicht gibt, brauchen Sie, sobald sie existieren. Einige konkrete nächste Schritte:

Beobachten Sie die GitHub-Repositories unter github.com/owncloud: oCIS, Classic, die Clients, die Web-Erweiterungen. Mit good-first-issue und help-wanted gekennzeichnete Issues sind echte Anfragen.
Lesen Sie die veröffentlichten Richtlinien. Die Governance Charter, die KI-unterstützte Beitragsrichtlinie, die Security Disclosure Policy und den Contribution Guide.
Melden Sie Sicherheitslücken an das VDP oder die YesWeHack-Bug-Bounty, falls Sie etwas finden.
Bewerben Sie sich für die Community Advisory Board-Gründung für Q4 2026 — fünf bis neun externe Mitglieder auf 12 Monate befristet, mit Verlängerungsoption; Nominierungen werden öffentlich ausgeschrieben.
Kontaktieren Sie das OSPO unter ospo@kiteworks.com. Für Code-of-Conduct-Anliegen nutzen Sie coc@owncloud.com. Organisationen, die ein Enterprise-Abo prüfen, können die Kontaktseite nutzen — das ist aber nur eine Randnotiz, nicht der eigentliche Aufruf.

Häufig gestellte Fragen

Weil Forks für sich genommen kein Beweis für ein Scheitern sind. In Open Source sind Forks oft ein Warnsignal. Sie zeigen, wo Vertrauen, Governance, Kommunikation oder strategische Ausrichtung nicht mehr stimmten. ownClouds aktuelle öffentliche Kommunikation benennt das klar: Der erste Fork 2016 entstand aus Governance- und Transparenzbedenken, der zweite Fork 2025 erneut durch Kommunikations- und Vertrauensprobleme. Entscheidend ist nicht, diese Geschichte zu leugnen, sondern zu zeigen, dass das Projekt daraus gelernt hat.

ownCloud ist heute glaubwürdig, weil es kontinuierlich liefert und Governance sichtbar korrigiert. Die Community-Posts von April 2026 bekräftigen Transparenz, klarere Kommunikation, Community-Beteiligung und das Ziel, „ownCloud wieder zu Ihrer Plattform zu machen“, und verweisen zugleich auf laufende Releases und Investitionen statt auf Aufgabe.

Ein weiteres konkretes Governance-Signal: ownCloud hat öffentlich angekündigt, die CLA abzuschaffen und auf das Developer Certificate of Origin umzustellen. Das wird als Abbau von Machtasymmetrien zwischen Unternehmen und Beitragenden kommuniziert. Das beseitigt nicht automatisch Skepsis, ist aber genau die Art struktureller Veränderung, die ernsthafte Communities erwarten, wenn sie beurteilen, ob ein Steward wirklich sein Verhalten ändert und nicht nur den Ton.

Nichts rückwirkend. Ihre bisherigen Beiträge bleiben unter den Bedingungen, die zum Zeitpunkt der Einreichung galten. Künftig verwendet jeder Commit in jedem ownCloud-Repository das DCO-Sign-off (git commit -s). Sie behalten das Urheberrecht an Ihrem Beitrag.

Nein. Wir prüfen ihn nach denselben Maßstäben wie jeden anderen PR. Die vier Anforderungen — Offenlegung, Verständnis, Testen, Lizenz-Compliance — stellen sicher, dass das Tool die Qualität hebt statt senkt. oCIS wurde bereits nach diesem Workflow weiterentwickelt.

Ja. ownCloud Classic läuft auf PHP 8.3 und wird aktiv gepflegt, mit laufenden Sicherheits- und Wartungs-Updates. Der Classic-zu-oCIS-Migrator ist sehr nah dran.

Öffentlich unter https://github.com/orgs/owncloud/discussions. Das OSPO prüft und beantwortet jeden Kommentar schriftlich vor Veröffentlichung. Schreiben Sie an ospo@kiteworks.com, falls Sie einen Hinweis auf den richtigen Issue-Tracker benötigen.