Benutzen wir eine Open Source Variante oder doch besser die Professional Version einer gängigen Software? Wie kommen wir zur Entscheidungsfindung und wovon hängt diese ab?
In diesem Artikel möchte ich einmal aus unserem Alltag berichten, wie wir mit dem Thema ‚Open Source versus Professional Version‘ umgehen. Als Verfechter von Open Source sehe ich die Notwendigkeit, auch Open Source Software (OSS) professionell zu verwenden und ggf. den lizensierbaren Teil zu benutzen, wenn es einen Mehrwert darstellt.
Gerade im professionellen Einsatz sind der Nutzung der OSS-Software manchmal Grenzen gesetzt. Diese sind nicht immer ursächlich in der Software zu suchen. Sie stellen bewusst eine Erweiterung dar, die bezahlt werden muss.
„Für lau“ Software zu benutzen, ist sicherlich gern gesehen. Ein Unternehmen spart dadurch Kosten und Kostendruck besteht bekanntlich ja immer. Allerdings entwickelt sich auch Open Source Software „nicht von allein und umsonst“. Vielfach besteht eine Software aus einem frei zugänglichen Teil, der OSS Variante, und einem anderen Teil an Closed Software mit lizenzpflichtigen Features. In unserem Beispiel ist dies genau der Fall. Wir benutzen einen Artifact-Storage von Sonatype Nexus. Hier gibt es den sehr weit verbreiteten OSS Nexus, der für kleinere Projekte sehr gut geeignet und schnell eingerichtet ist. Die Verbreitung ist entsprechend hoch.
Das Problem – Wie sieht die Entscheidungsfindung nun im Alltag aus?
Der OSS Nexus ist ein guter Artefact-Storage, der funktioniert. In vorherigen Artikeln hatten wir von Umstellungen auf Gradle im Buildsystem und Performanceoptimierungen berichtet, da kommt der OSS Nexus ins ‚Schwitzen‘, ursächlich ist die integrierte Datenbank und die bei uns vorkommenden sehr vielen kleinen Buildartefakte. Bisherige Erfahrungen waren alle sehr positiv, aber das Attribut ‚gut geeignet für kleinere Projekte‘ trifft vielleicht nicht zu? Hier sind der Open Source Variante Grenzen gesetzt, die sich in der Anzahl an Requests pro Zeitraum äußern. Unsere Legacy Software wird durch eine recht hohe Parallelität mit Gradle gebaut. In der OSS Version bestehen Beschränkungen, die in der dahinterliegenden Datenbank des Nexus zu suchen sind. Mag die Hardware noch so gut sein, ohne den Umstieg auf die Professional Version lässt sich an der Software wenig verbessern.
Die standardmäßige OrientalDB als Backend des OSS Nexus kommt nicht mit, um sehr viele einzelne Artefakte in sehr kurzer Zeit in den internen Index aufzunehmen. Oder zusätzlich alte Artefakte im Nexus zu bereinigen. Nehmen wir die Arbeitsweise mit den fast hundert Feature-Branches bei uns hinzu, lässt sich erahnen, dass hier das Nadelöhr besteht. Leider ist nicht jeder Hersteller transparent im Umgang mit Limits in der Benutzung. Sonatype hat erst kürzlich auf konkret diese Problemstellung in der Nutzung der OSS Variante hingewiesen. Vorher war es eher schwammig formuliert mit hoher Last in der Anzahl an Requests, ohne konkrete Zahlen zu nennen. Dadurch war die Systembestimmung schwierig und eher erfahrungsbasiert.
Was bei uns Schmerzen bereitet hat, war die Erkenntnis, dass wir weit außerhalb der OSS Grenzen an Requests lagen, denn grundsätzlich funktioniert der Artefaktstorage bei uns seit Jahren. Viele andere Konkurrenz-Produkte in dem Marktsegment sind nicht als OSS Variante zu erhalten, das bedeutet, sie sind sofort lizenzpflichtig und entsprechend teuer. Der Einstieg, um Erfahrungen zu sammeln, ist sofort mit Kosten verbunden.
Entscheidung für eine Lizenz
Der Einstieg mittels der OSS-Variante mag manchem als eine Art Lockvogel vorkommen. Für uns war es ein Ansatz, sanft in den Bereich einzusteigen und entsprechend Erfahrungen im Umgang und Einsatz zu sammeln. Wir mussten nicht gleich Geld in Lizenzen investieren. Außerdem ist der Um- bzw. Ausstieg in/aus dem Lizenzbereich in der Benutzung einfach. Im konkreten Fall bedeutet es das Hinzufügen des Lizenzschlüssels und die Pro-Lizenz läuft bzw. das Entfernen des Schlüssels und die Lizenz-Features sind wieder deaktiviert. Das ist in meinen Augen ehrlich und transparent. Sollte sich also an unserem Nutzungsverhalten etwas verändern, besteht die Chance die Lizenz wieder loszuwerden und Kosten einzusparen.
Fazit – Mit OSS Erfahrungen sammeln und dann erneut entscheiden
Daher ist mein Fazit hier, es lohnt sich Erfahrungen mit einem OSS-System aufzubauen und sukzessive ggf. lizenzpflichtige Features dazu zu kaufen, wenn es die individuellen Anforderungen verlangen. Das führt zu deutlich mehr Kostenbewusstsein auf bestimmte Features zu verzichten oder aber auf bestimmte Anforderungen besonders zu achten, da dies augenscheinlich Geld kostet.
In unserem Fall ist es die Menge an einzelnen Artefakten in unserer Software sowie die Menge an parallelen Feature-Branches im Entwicklungsprozess, die zu der sehr hohen Anzahl an Requests pro Zeiteinheit führen. Abstrahiert auf eine höhere Ebene bedeutet das, dass die Architektur und das Entwicklungsmodell die Kosten mitbestimmen. Es bleibt also dem betriebswirtschaftlichen Verständnis vorbehalten, die Kosten gegenüber den möglichen Vorteilen der kostenpflichtigen Features abzuwägen. Bei uns sind die Vorteile der Features aktuell höherwertig und die Kosten der Lizenz vertretbar. Dies trägt der augenblicklichen Architektur Rechnung und gewährleistet weiterhin eine hohe Parallelität an Feature-Branches. Sollte sich in den Bereichen etwas ändern, können wir ggf. wieder zurück auf die OSS Variante. Da ist genau der Vorteil und die Chance für uns gegenüber einer ad-hoc Lizenz Software. I like Open Source.
