Was ist Enterprise Open Source?

Klar, wir wissen bereits, was Open Source ist. Über dieses Thema wurde schon vieles aus den verschiedensten Perspektiven geschrieben. Es gibt sogar eine praktische Definition der Komponenten von Open Source, aber wie sieht es mit Enterprise Open Source aus? Mit diesem Blogbeitrag möchten wir dieses Konzept erklären – ohne Anspruch auf Vollständigkeit zu erheben.

Zunächst einmal lasst uns feststellen: Es handelt sich um Open Source. Wir bezeichnen ein Produkt nicht als „Enterprise Open Source“, nur weil es eine einzelne tolerant lizenzierte Open Source-Bibliothek integriert oder mit Open Source „funktioniert“ oder „ausgeführt“ wird.

Für den Einsatz im Unternehmen getestet und gehärtet

Jeder kann Open Source-Projekte herunterladen und installieren oder kompilieren und im aktuellen Zustand über das Upstream Repository bereitstellen. Dies aber bedeutet keinen zusätzlichen Mehrwert für ein Projekt und kann Risiken mit sich bringen.

Um unter den Begriff der Enterprise Open Source zu fallen, müssen Produkte ausgiebig getestet, leistungstechnisch angepasst und proaktiv auf Sicherheitsschwachstellen untersucht werden. Weiterhin notwendig sind ein Sicherheits-Team zu ihrer Unterstützung sowie Prozesse, um auf neue Sicherheitsschwachstellen zu reagieren, Nutzer darüber zu informieren und ihnen Hilfe bei der Problembehebung zu leisten.

Wenn Sie in Bezug auf Qualitäts- und Sicherheitsprobleme auf sich alleine gestellt sind, dann handelt es sich nicht um Enterprise Open Source.

Unternehmensfähige Features

Die Anforderungen von großen Organisationen, die wir der Einfachheit halber einfach in die Kategorie „Enterprise“ (oder Unternehmen) einordnen, weichen beträchtlich von denen kleiner Firmen und von Privatanwendern ab.

So sind für Letztgenannte Aspekte wie Single Sign-On (SSO), Integration mit SSO-Plattformen, Verzeichnismanagement, Kalenderplattformen usw. ziemlich uninteressant. Zugegeben, ich kenne einige technisch versierte Leute, die über hoch technisierte Heimnetzwerke verfügen, aber in den meisten Fällen spielen solche Anforderungen und ihre Einrichtung nur für Unternehmen ab einer bestimmten Größe eine Rolle.

Kleinere Organisationen haben es auch nicht mit dem gleichen Umfang an Auditing-Anforderungen oder der Konsolidierung von Services über mehrere Rechenzentren und/oder Public Clouds hinweg zu tun. Unternehmenskunden sehen sich vor Herausforderungen wie große Datenspeicheranforderungen, umfassende Komplexität sowie Disaster Recovery gestellt, die über die Bedürfnisse von KMUs weit hinausgehen.

Oder nehmen wir zum Beispiel Java. Da gibt es Java als Kernprogrammiersprache auf der einen und Enterprise Java auf der anderen Seite. Enterprise Java enthält APIs und Anwendungsserver, um die Entwicklung unternehmensfähiger Software langfristig zu vereinfachen und wartungsfreundlicher zu machen. Wenn Sie Tausende gleichzeitiger Nutzer handhaben müssen, dann benötigen Sie definitiv Unternehmenssoftware und eben auch Open Source für Unternehmen. Dies betrifft den Bereich der Features, aber kommen wir noch einmal auf den angesprochenen langfristigen Aspekt zurück.

Vorhersehbarer langer Lifecycle

IT-Umgebungen von Unternehmen erfordern hohe Investitionen und eine umfassende Planung und können arbeitstechnisch eine aufregende Herausforderung sein, wenn Sie gerne neue Dinge erlernen und mit Technologie zu tun haben. Allerdings ist diese Technologie primär dafür vorgesehen, andere Menschen bei ihrer Arbeit zu unterstützen. Also Personen, die generell keinen Spaß daran haben, die Nutzung von Systemen neu zu erlernen oder erleben zu müssen, wie eine Anwendung quer schlägt, weil sie durch ein Update (oder seine zugrundeliegenden Komponenten) unbrauchbar gemacht wird.

Die meisten von uns im Arbeitsalltag genutzten Anwendungen bestehen aus einem komplexen Stack, der auf robuster Hardware, einem stabilen Betriebssystem, einer oder mehreren Programmiersprachen, einer Handvoll Bibliotheken, einer Datenbank, Inhouse Code, Konfigurationen sowie Nutzerdaten aufsetzt.

Wenn eine Komponente so aktualisiert wird, dass sie mit der darunter oder darüber liegenden Schicht inkompatibel wird, kann das die gesamte Anwendung ausbremsen. Wenn Sie beispielsweise ein Betriebssystem auf einer neuen, ungetesteten Hardware-Schicht installieren, dann kann es gut sein, dass Sie nicht über die benötigten Treiber verfügen und dadurch das Networking nicht funktioniert. Oder es treten Kompatibilitätsprobleme mit dem Storage oder der Grafikkarte auf.

Was, wenn Sie das OS aktualisieren und dies eine neue OpenSSL-Bibliothek oder Python-Version integriert, die nicht mit Ihrer Anwendung kompatibel ist?

Enterprise Open Source hat einen vorhersehbaren Lifecycle, der von vorneherein definiert ist und Informationen zu Komponenten enthält, die unterschiedliche Release-Cycles haben können. Darüber hinaus besitzt das Produkt eine Lebensdauer, die Unternehmen die Bereitstellung wichtiger Anwendungen ermöglicht. Im Falle des Betriebssystems z. B. bietet eine jede Hauptversion von Red Hat Enterprise Linux einen Lifecycle von 10 Jahren.

Ein Anbieter von Unternehmenssoftware wie Red Hat übernimmt oft auch die komplexe Aufgabe der Unterstützung von Komponenten, lange nachdem neue Versionen für das Upstream-Projekt veröffentlicht worden sind. Dies ist notwendig, damit der Kunde Software in einem zeitlichen Rahmen nutzen kann, der für Organisationen in Unternehmensgröße Sinn macht.

Es kann sein, dass die Upstream Community die Rückportierung von Sicherheitsschwachstellen für eine Version bereits seit Jahren eingestellt hat. Wir führen jedoch diese Aufgabe fort, damit unsere Nutzer Apps nicht refaktorieren oder große Upgrades für missionskritische Software durchführen müssen.

Zertifizierungen

Enterprise Open Source zeichnet sich nicht nur durch einen mit den Anforderungen von Unternehmen ausgerichteten Lifecycle, sondern auch durch Zertifizierungen aus.

Es lohnt sich Hardware auszuwählen, die mit dem Betriebssystem und den Anwendungen kompatibel ist, die Sie bereitstellen. Das ist der Grund, warum wir mit einer Vielzahl an Hardware-Partnern zusammenarbeiten, um RHEL für diese Plattformen zu zertifizieren und Features wie GPU Passthrough für Red Hat OpenShift und Red Hat OpenStack Platform zu aktivieren.

Und für Produkte wie Red Hat Enterprise Linux und Red Hat OpenStack Platform. Sie können mit diesen Plattformen Workloads ausführen, die für Ihr Unternehmen wichtig sind – darunter auch diejenigen, die von ISVs angeboten werden. Oder vielleicht sind Sie auch selbst ein ISV und möchten Ihren Kunden versichern, dass Ihre Produkte wie erwartet auf RHEL oder Red Hat OpenStack Platform funktionieren.

Mit das Beste an Open Source ist, dass Sie so viel Auswahl haben. So haben Sie Zugriff auf den Quellcode und können Projekte beliebig kombinieren, vorausgesetzt, sie sind miteinander kompatibel. Eine größere Auswahl und Vielfalt aber können für Ops-Teams frustrierend sein, die in Produktion befindliche Systeme unterstützen müssen. Und InfoSec-Teams sind davon auch nicht begeistert, denn sie müssen wissen, was in ihren Umgebungen ausgeführt wird und welche Schwachstellen wann und wo zum Problem werden können.

Aus diesem Grund unterhalten wir Programme für die Zertifizierung von ISV-Produkten, damit die Kunden sie voller Vertrauen auf unseren Plattformen ausführen können. Definitionsgemäß ist die Auswahl bei Enterprise Open Source etwas eingeschränkt, allerdings ist der Fokus auch auf unterstützbaren Konfigurationen, die die für missionskritische Anwendungen so wichtigen Features bieten.

Service Level Agreements und Support

Sicherlich nützt auch die beste Zertifizierung nichts, wenn sie bei Problemen keine Unterstützung erhalten.

Enterprise Open Source bedeutet, dass Ihnen Händler zur Verfügung stehen, die Support und Service Level Agreements (SLAs) bereitstellen, die festlegen, was genau unterstützt wird und wie schnell Sie eine Antwort und Abhilfemaßnahmen erwarten können.

Natürlich geht es beim Support um noch viel mehr. Dazu gehören auch Bemühungen und Materialien, die dem Kunden bei der Bereitstellung und Verwaltung von Software helfen, darunter Dokumentation, Wissensdatenbank-Artikel und Foren. Einige Umgebungen benötigen dazu unter Umständen Hilfe von einem Technical Account Manager (TAM), dessen Aufgabe es ist, für den zugewiesenen Kunden Probleme präventiv zu identifizieren und zu verhindern.

TAMs sind technisch hoch-versierte Produktspezialisten, die Kunden bei der Planung von Bereitstellungen, Patch-Installationen und mehr unterstützen.

Training

Da wir schon beim Thema sind... Training und Produkt-/Fachbereichszertifizierungen sind ein weiteres Markenzeichen unserer Definition von Enterprise Open Source. In den Anfängen von Linux hatten Organisationen große Mühe damit, qualifizierte Systemadministratoren von Stellensuchenden zu unterscheiden, die sich nach einer erfolgreichen Installation von Slackware schon zu den Linux-Experten zählten.

Trainings- und Zertifizierungsprogramme erfordern in Sachen Zusammenstellung und Pflege einen hohen Arbeitsaufwand. Dazu muss eine Technologie bereits einen gewissen Reifegrad erreicht haben, um für Trainingskurse und Zertifizierungen geeignet zu sein, ganz zu schweigen von missionskritischen Workloads und langfristigem Support.

Integration

Ein weiteres Charakteristikum von Enterprise Open Source ist die Integration. Wie einer meiner Kollegen sagen würde: „Upstream Communities eignen sich hervorragend für die Entwicklung der ‚Einzelteile‘ einer Lösung.“ Wenn Sie einen innovativen Webserver benötigen, hält die Open Source Community eine große Auswahl bereit. Wenn Sie nach robusten Datenbanken oder Frameworks suchen, kein Problem. Messaging Bus, Daten-Streaming-Plattform, verteilter Storage usw. – für all das gibt es zahlreiche Open Source-Projekte.

Aber möchten Sie, dass sie alle miteinander funktionieren? Wenn ja, für wie lange? Über den zweiten Teil des Lebenszyklus hinaus? Jahrelang? Aha. In diesem Fall kommen Sie an Enterprise Open Source eigentlich nicht vorbei.

Projekte vs. Produkte

Sie können den Begriff der Enterprise Open Source auch definieren, indem Sie fragen, ob Sie es mit einem Projekt oder einem Produkt zu tun haben.

Open Source-Projekte werden den Nutzern und der Community der Beitragenden in verschiedenen Güteklassen angeboten. Manche, wie Fedora, sind eher für größere Nutzergemeinschaften geeignet und umgehend einsatzfähig. Andere erfordern ein wenig Do-it-yourself-Programmierung, eine Kompilierung oder die Kombination verschiedener anderer Komponenten.

Für Projekte wird im Allgemeinen kein Personal benötigt. Für sie sind Beitragende zuständig, die vielleicht in Vollzeit an einer Technologie arbeiten und von einem Anbieter (wie Red Hat) bezahlt werden. Beiträge können auch von Personen stammen, die täglich mit einer Technologie arbeiten und sie für eine zukünftige Verwendung pflegen und verbessern möchten.

Es gibt nur wenige Projekte, bei denen Personen für Release-Management, Dokumentation oder andere potenzielle Produktaspekte entlohnt werden. Bei denjenigen, auf die das zutrifft, wie Fedora, möchte der Anbieter das Projekt im Interesse eines Produkts unterstützen. Projekte, zumindest diejenigen, die wir als gesund erachten, verfügen über eine Governance, die nicht nur von einer einzelnen Entität kontrolliert wird.

Hieran können auch Personen außerhalb des Sponsorunternehmens beteiligt sein und Änderungen und Richtung des Projekts beeinflussen, zumindest im Rahmen der Mission des Projekts. (Egal, wie leidenschaftlich oder engagiert Sie auch sind, Sie werden die Verantwortlichen des Fedora-Projekts wohl nicht davon überzeugen können, x86-64 zu vernachlässigen und sich auf TRS-80s und Retro Computing zu konzentrieren.)

Viele Produkte weisen die bereits erwähnten Charakteristika auf: vorhersehbarer Lifecycle, Support, Zertifizierungen, Training, ggf. ein ISV-Partnernetzwerk sowie die Kontrolle durch eine einzelne Entität, die sich an den Anforderungen und Preisen des Markts orientiert. Features und Roadmaps werden im Hinblick auf Kundenanforderungen geplant und nicht dahingehend, welche Personen bereit sind, an einem bestimmten Projekt zu arbeiten.

Funktioniert in Verbindung

Open Source-Projekte und Enterprise-Open-Source-Produkte sind nicht das Gleiche, aber so verschieden sind sie nun auch wieder nicht. Wenn alles gut läuft, kommt der Arbeitsaufwand für Enterprise-Open-Source-Produkte den Open Source-Projekten und mit ihnen allen Projektnutzern zugute, nicht nur bezahlten Anwendern und Anbietern.

Idealerweise kombiniert Enterprise Open Source das Beste aus zwei Welten, nämlich die Vorteile von Open Source und die Stabilität, Performance, Unterstützung sowie das Partnernetzwerk, die von Unternehmenssoftware bereitgestellt werden.