Open-Source-Engineering
Wir bauen und pflegen die Open Source, auf der Ihre Plattform läuft
Kein Reseller, kein Support-Desk. Wir tragen zu den Projekten bei, von denen unsere Kunden abhängen, pflegen sie mit und stehen kommerziell für sie ein.
Das Problem
Ihr kritischer Pfad führt durch Software, die niemand in Ihrer Organisation pflegt
Das ist normal. Es ist zunehmend auch ein Governance-Problem mit regulatorischer Dimension.
Es zeigt sich auf drei vorhersehbare Weisen. Eine kritische CVE trifft eine Komponente, für die niemand verantwortlich ist, und die Behebung dauert Wochen, weil niemand die Codebasis gut genug kennt, um die Betroffenheit zu bewerten, geschweige denn zu patchen. Ein Projekt, von dem Sie abhängen, verliert seine Maintainer, und es gibt keinen Plan. Ihre Engineers schreiben einen Fix, tragen ihn als Fork mit, weil das Upstreaming Arbeit ist, für die niemand Zeit hat, und zwei Jahre später blockiert dieser Fork jeden Upgrade-Pfad, den Sie haben.
Cyber Resilience Act, NIS2 und DORA setzen inzwischen alle voraus, dass Sie Fragen zu Herkunft, Pflege und Sicherheitsreaktion der Software beantworten können, die Sie betreiben und ausliefern. „Das ist Open Source“ ist keine Antwort mehr.
Was wir tun
Unsere Arbeit
Wir entwickeln upstream
Wir steuern Features, Fixes und Reviews zu den Projekten bei, von denen unsere Kunden abhängen. Wenn Ihre Anforderung besser im Projekt gelöst wird als daneben, bringen wir sie dorthin, über den Prozess des Projekts, als Contributor mit Standing und nicht als Fremde, die einen Pull Request öffnen.
Wir pflegen
Bei Projekten, in denen unsere Engineers Maintainer- oder Reviewer-Rollen halten, tragen wir echte Verantwortung: Reviews, Releases, Sicherheitsreaktion und die unspektakuläre Arbeit, die ein Projekt am Leben hält. Dieses Standing ist es, was unsere kommerziellen Zusagen glaubwürdig macht.
Wir supporten
Vertraglich zugesicherte Absicherung für die Komponenten in Ihrem kritischen Pfad: Sicherheitsreaktion mit einer Betroffenheitsanalyse für Ihre konkrete Nutzung statt eines generischen Schweregrads, Upgrade- und Kompatibilitätsunterstützung sowie Deep-Dive-Hilfe, wenn etwas auf eine Weise bricht, die die Dokumentation nicht abdeckt.
Wir kümmern uns um die Lieferkette
SBOM-Erzeugung und -Validierung, Provenance, Lizenzlage und die Dokumentation, die Ihre Compliance-Funktion braucht, eingeordnet in die Pflichten, die tatsächlich für Sie gelten.
Wir beraten zur Strategie
Contribution-Richtlinie, Governance, Inner-Source-Praxis, Aufbau eines Open Source Program Office und Engagement in Foundations, für Organisationen, die im Ökosystem mitwirken und es nicht nur konsumieren wollen.
Unsere Angebote
Wie wir zusammenarbeiten
Open Source Assurance
Vertraglich zugesicherte Abdeckung für die Komponenten, die für Sie zählen: Sicherheitsreaktion, Upgrade-Unterstützung, Kapazität für Upstream-Beiträge und Nachweise zur Lieferkette.
Ergebnis
Eine benannte, verantwortliche Antwort auf die Frage, wer das pflegt.
Upstream-Entwicklung
Feature- und Fix-Entwicklung in den Projekten, von denen Sie abhängen, upstream geliefert.
Ergebnis
Ihre Anforderungen im Projekt, Ihre Anzahl an Forks sinkt.
Fork-Reduktion und Upstreaming
Erfassung der Patches, die Sie mitschleppen, und deren Überführung nach upstream.
Ergebnis
Ein Upgrade-Pfad, der nicht länger durch Ihre eigenen Patches blockiert ist.
Lieferkette und Compliance
SBOM, Provenance und Lizenzlage für Ihren Open-Source-Bestand, abgebildet auf die Pflichten aus CRA, NIS2 und DORA.
Ergebnis
Nachweise statt Behauptungen.
Long-Term-Support-Pfade
Wo ein Projekt sich schneller oder langsamer bewegt, als Sie mitgehen können, erarbeiten und pflegen wir die Antwort, einschließlich verlängerter Wartung von Versionen, auf denen Sie bleiben müssen.
Ergebnis
Eine unterstützte Position statt einer ungesteuerten.
Open-Source-Strategie und Governance
Contribution-Richtlinie, OSPO-Aufbau, Inner Source, Engagement in Foundations.
Ergebnis
Eine bewusste Open-Source-Haltung statt einer zufälligen.
Arbeitsweise
Wie wir arbeiten
Standardmäßig öffentlich
Die Arbeit, die wir für Sie leisten, geht upstream, öffentlich, unter unseren eigenen Namen im Projekt. Genau das macht sie dauerhaft: Ein upstream aufgenommener Fix wird vom Projekt für immer gepflegt, ein privater Patch von Ihnen für immer.
Konkret, nicht allgemein
Wir decken benannte Komponenten ab, mit erfasster Version und Konfiguration, denn eine CVE, die allgemein kritisch ist, ist für Ihre Nutzung oft irrelevant und gelegentlich deutlich schlimmer. Generische Advisory-Feeds können Ihnen nicht sagen, welches von beidem zutrifft.
Innerhalb der Projekte, nicht außerhalb
Eine Änderung in ein gesundes Open-Source-Projekt zu bekommen, ist ebenso ein sozialer wie ein technischer Vorgang. Standing, Historie und die Maintainer zu kennen, ist der Unterschied zwischen einem Fix in drei Wochen und einem Fix, der nie kommt.
Ehrlich über unsere Reichweite
Wir behaupten nicht, die gesamte Cloud-Native-Landschaft zu pflegen. Wir sagen Ihnen, wo wir echtes Standing haben, wo wir funktionierende Beziehungen haben und wo wir genauso am Anfang stünden wie Sie. Diese Unterscheidung steht in Ihrem Scoping-Dokument.
Was Sie erhalten
Zielorientierte Ergebnisse
Ein benannter, dokumentierter Komponentenumfang mit erfassten Versionen, Konfigurationen und mitgeführten Patches
Überwachung von Security Advisories mit Betroffenheitsanalyse für Ihre konkrete Nutzung
Upstream-Beiträge, öffentlich in Ihrem Namen eingebracht
SBOM- und Provenance-Nachweise in dem Format, das Ihre Compliance-Funktion benötigt
Vorab-Hinweise zu Upgrades und Breaking Changes
Ein benannter technischer Ansprechpartner und ein Eskalationsweg
Quartalsweise Überprüfung von Umfang, Beiträgen und Roadmap
Wo das im Stack sitzt
Warum das alles andere trägt
Open Source ist das, was den Rest des Stacks überprüfbar macht. Eine Souveränitätszusage, die auf einem Vertrag beruht, ist ein Versprechen. Eine Souveränitätszusage, die auf Software beruht, die Sie einsehen, überall betreiben und verlassen können, ist eine Eigenschaft der Architektur. Eine Plattform auf Open-Source-Basis kann von Ihrem Team betrieben, auf ein anderes Substrat verlagert und von jedem geprüft werden, den Sie dafür auswählen.
Es ist auch der Grund, warum wir „kein Lock-in“ sagen und damit etwas Konkretes meinen können.
Angebotspakete
Starten Sie mit einem definierten Schritt
12 Monate, rollierend
Open Source Betrieb & Wartung
Ihre Plattform läuft auf Open Source. Wir pflegen sie, bringen Ihre Fixes upstream und stehen für die Komponenten ein, die für Sie zählen, als Maintainer, nicht als Support-Desk.
8 Wochen, Betrieb optional
OpenBao Implementation and Operation
Produktionsreifes Secrets Management mit OpenBao in acht Wochen: ausgerollt, in Ihre Workloads integriert und auf Wunsch von uns betrieben. Open Source, in Ihrer Infrastruktur, mit Ihrer Schlüsselhoheit.
FAQ
Fragen, die uns gestellt werden
Ist das ein Supportvertrag wie bei Red Hat?
Nein, und der Unterschied ist wesentlich. Ein Herstellersupportvertrag deckt die Distribution dieses Herstellers ab. Unserer deckt die Komponenten ab, die Sie tatsächlich betreiben, aus welchen Projekten auch immer, in Ihrer Konfiguration, und enthält Kapazität, diese Projekte in Ihrem Namen zu verändern. Wenn Ihr Bestand die Distribution eines einzelnen Herstellers ist, ist dessen Vertrag vermutlich die bessere Antwort, und wir sagen Ihnen das.
Was, wenn Sie eine Komponente nicht pflegen, von der wir abhängen?
Wir sagen es Ihnen. Das Scoping der Abdeckung enthält eine ehrliche Angabe zu unserem Standing je Komponente: wo wir pflegen, wo wir beitragen, wo wir Beziehungen haben und wo wir die Codebasis gemeinsam mit Ihnen kennenlernen würden. Sie sollten misstrauisch sein, wenn jemand gleichmäßige Tiefe über eine derart große Landschaft behauptet.
Müssen unsere Fixes öffentlich upstream gehen?
Ja, und das lohnt sich zu verstehen statt zu verhandeln. Ein öffentlicher Upstream-Fix wird ab dann vom Projekt gepflegt. Ein privater Patch wird von Ihnen gepflegt, für immer, und er blockiert Ihre Upgrades. Wenn die Änderung wirklich sensible Geschäftslogik enthält, gehört diese Logik meist ohnehin nicht in eine Infrastrukturkomponente, und wir klären gemeinsam, wo sie hingehört.
Können Sie eine Freistellung von Haftungsansprüchen anbieten?
Nein. Wir liefern Engineering, Maintainership und Nachweise. Eine solche Freistellung ist ein Versicherungsprodukt und sollte bei einem Versicherer eingekauft werden.
Wie hilft das beim Cyber Resilience Act?
Es verschafft Ihnen die beiden Dinge, die die Pflichten voraussetzen: eine dokumentierte Position zu Pflege und Sicherheitsreaktion für Ihre Komponenten und Nachweise zur Lieferkette in einer Form, die Sie auf Anfrage vorlegen können. Wir liefern die technische Position und die Nachweise; Ihre Rechts- und Compliance-Funktionen verantworten die Feststellung, welche Pflichten für Sie gelten.
Welche Komponenten rauben Ihnen den Schlaf?
Die meisten Gespräche beginnen mit einer kurzen Liste: drei oder vier Komponenten im kritischen Pfad ohne Verantwortlichen. Das ist ein guter Anfang.