Wie geht es weiter mit Jenkins & Co?

Fünfzehn Jahre lang wurde Jenkins unter der Leitung von Kohsuke Kawaguchi entwickelt. Bis zum Januar 2020. Vor wenigen Wochen hat sich Kohsuke Kawaguchi als leitender Entwickler von Jenkins verabschiedet und ebenso seine Tätigkeit bei CloudBees aufgegeben, wie er auf seiner Website erläutert hat.¹

Jenkins ist ein Continuous Integration & Continuous Delivery Server, der dabei hilft, die Entwicklung von Software durch kontinuierliche Integration und Bereitstellung teilweise zu automatisieren. Man spricht hier auch von CI/CD. Entwickelt wurde Jenkins von Kohsuke Kawaguchi bei Sun Microsystems. Sun veröffentlichte die erste Version der Software im Jahr 2005 auf Java.net unter dem Namen Hudson. 2010 wurde Sun von Oracle übernommen. Damit gingen auch die Namensrechte an Hudson auf Oracle über.

Wegen dieser Namensrechte entschieden sich die Entwickler, Jenkins als Fork von Hudson abzuspalten. Kohsuke Kawaguchi verließ Sun bzw. Oracle und wechselte als technischer Direktor zum Unternehmen CloudBees. CloudBees ist auf Dienstleistungen und Support rund um Jenkins spezialisiert.

Kohsuke Kawaguchi schreibt, er habe bereits 2019 begonnen, sich allmählich aus der Entwicklung von Jenkins zurückzuziehen. Er hat gemeinsam mit einem langjährigen Kollegen und Jenkins-Veteranen ein Startup namens Launchable gegründet. Zukünftig werde er sich auf Lösungen zur Steigerung der Softwarequalität durch Machine Learning spezialisieren. Er sei zwar noch emotional und finanziell in CloudBees investiert, aber er werde CloudBees und die Jenkins-Entwickler nur noch von der Seitenlinie aus beraten und anfeuern.

Die Rolle von CloudBees bei Jenkins

Seit vielen Jahren entwickeln überwiegend Mitarbeiter von CloudBees Jenkins weiter, wie sich aus der Liste der aktiven Teilnehmer am Jenkins-Projekt bei GitHub ergibt.² Auch die leitenden Gremien des Jenkins-Projekts sind mehrheitlich durch Mitarbeiter von CloudBees besetzt.³ Die Gegenwart und nahe Zukunft von Jenkins liegt damit eindeutig in den Händen von CloudBees.

Doch wer steckt eigentlich hinter dem Unternehmen? Laut einer Mitteilung von CloudBees beläuft sich die gesamte Finanzierung des Unternehmens auf ca. 120 Millionen US-Dollar. Davon seien 72 Millionen US-Dollar in den Jahren 2018 und 2019 in CloudBees investiert worden.⁴

Zu den Investoren zählen verschiedene Risikokapitalgeber, außerdem Verizon sowie die Großbank HSBC. Das Investment von HSBC wurde damit begründet, dass HSBC die auf Jenkins basierenden Technologien von CloudBees selbst nutze und CloudBees für HSBC von strategischer Bedeutung sei.

CloudBees hat aber nicht nur die Organisation und die Entwicklung von Jenkins gefördert, sondern bietet seit der Übernahme von Codeship auch eine alternative CI/CD-Lösung als Software as a Service (SaaS) an.

Das große Angebot an CI/CD-Lösungen

Der Markt für Werkzeuge und Support im Bereich CI/CD ist ebenso groß wie hart umkämpft. Die großen Softwarekonzerne haben ebenso wie mehrere kleinere Unternehmen viele neue und alternative Produkte und Lösungen zu Jenkins im Bereich CI/CD geschaffen:

• Amazon Web Services (AWS) bietet eine eigene CI/CD Lösung als Software as a Service unter dem Namen AWS CodePipeline und AWS CodeBuild an.

• Apple hat mit Xcode Server eine CI/CD-Lösung für die App-Entwicklung im Portfolio.

• Atlassian bietet zwei CI/CD-Lösungen an, nämlich Bamboo für den Eigenbetrieb und Bitbucket Pipelines als Software as a Service.

• Google Cloud bietet eine CI/CD-Lösung namens Cloud Build an. Außerdem ist Google neben anderen Kapitalgebern bei GitLab finanziell engagiert, das eine CI/CD-Lösung namens GitLab CI umfasst.

• IBM offeriert eine Lösung namens IBM Cloud Continuous Delivery. Das zu IBM gehörende Red Hat nennt seine CI/CD-Lösung Red Hat OpenShift Pipelines.

• JetBrains ist nicht nur bekannt für seine Entwicklungswerkzeuge und die Programmiersprache Kotlin, sondern offeriert auch eine eigene CI/CD-Lösung namens TeamCity.

• Microsoft bietet mit Azure DevOps ebenfalls eine CI/CD Lösung an. Und auch das zu Microsoft gehörende GitHub bietet seit kurzer Zeit mit GitHub Actions eine eigene CI/CD-Lösung an.

• Oracles Entwicklungsplattform namens Developer Cloud Service umfasst auch CI/CD-Funktionen. Die Weiterentwicklung des Jenkins-Vorgängers Hudson hat Oracle dagegen schon vor mehreren Jahren faktisch eingestellt.

• Die genannten CI/CD-Lösungen sind nur die Spitze des Eisbergs. Es gibt sehr viele weitere CI/CD-Lösungen, beispielsweise CircleCI, Concourse, Drone, GoCD, Travis CI und natürlich Jenkins.

Die Doppel-Strategie der Anbieter

Die meisten der genannten CI/CD-Lösungen sind technologisch recht flexibel und gut in verschiedene IT-Umgebungen und Arbeitsprozesse integrierbar. Sie haben unterschiedliche technologische Schwerpunkte, Stärken und Schwächen.

Es lässt sich nicht pauschal sagen, welche Lösung die jeweils beste für ein Projekt ist. Die Beantwortung dieser Frage hängt konkret davon ab, was für eine Software man entwickelt und wie die Infrastruktur sowie die technischen Rahmenbedingungen gestaltet sind.

Besonders die Cloud- bzw. SaaS-Anbieter führen nicht nur einen Qualitätswettbewerb, sondern teilweise auch einen recht harten Preiswettbewerb, insbesondere die Cloud-Anbieter mit eigenen Rechenzentren.

Viele Cloud-Anbieter konkurrieren trotz eigener CI/CD-Produkte nicht offen mit Jenkins, sondern bieten den Jenkins-Anwendern sowohl Hosting als auch Support für den Betrieb von Jenkins an. Sie verfolgen insoweit eine Doppel-Strategie. Die Gründe dafür liegen auf der Hand.

Die Zahl der Jenkins-Installationen ist in einem wachsenden Markt in den letzten Jahren deutlich gestiegen. Nach Angaben des Jenkins-Projekts waren im Januar 2020 mehr als 260.000 Jenkins-Instanzen aktiv.⁵ Eine beeindruckende Zahl.

Jenkins ist zwar lizenzkostenfrei, verursacht aber im Eigenbetrieb beachtliche Kosten für Wartung, Pflege, Updates und Support. Die sehr häufig veröffentlichten (Sicherheits-) Updates für Jenkins und seine Plugins müssen jeweils zeitnah und regelmäßig eingespielt werden. Alles andere wäre fahrlässig. Viele IT-Fachmedien haben darüber berichtet, dass nicht aktualisierte Jenkins-Server für Angriffe auf die IT-Infrastrukturen von Unternehmen genutzt werden konnten.

Eine Jenkins-Instanz netzwerktechnisch oder sogar physisch abzuschotten, ist unter Gesichtspunkten der Sicherheit zwar effektiv und zumindest vordergründig auch kostengünstig. Aber ein solcher Ansatz schränkt die Arbeitsprozesse bei der Softwareentwicklung oft zu stark ein und kann hohe Folgekosten verursachen, die oft intransparent bleiben.

Immer mehr technische Teams arbeiten überregional zusammen. Das erfordert einen bedienungsfreundlichen überregionalen Zugang zu Werkzeugen wie Jenkins. Besonders für Unternehmen mit vielen Jenkins-Installationen und Anwendern stellt der Eigenbetrieb eine organisatorische, technische und finanzielle Herausforderung dar. Zur Lösung von Fragen des Betriebs von Jenkins versprechen viele Cloud-Anbieter Unterstützung. Einige kooperieren auch offiziell mit CloudBees.

Da Jenkins eine freie, kostenlose und quelloffene Software ist, steht CloudBees hier gleichwohl im Wettbewerb. Letztendlich gehört Jenkins nicht CloudBees, auch wenn die Entwickler von CloudBees sehr viel Code beigetragen und starken Einfluss auf die Entwicklung von Jenkins genommen haben, nicht zuletzt Kohsuke Kawaguchi.

Zweifelsfrei hilft es CloudBees strategisch, die Entwicklung von Jenkins durch eigenes Personal und dessen Expertise beeinflussen zu können. Aber die Softwareindustrie hat sich von einer technologischen Abhängigkeit von Jenkins durch zahllose alternative Angebote längst frei gemacht.

Vor dem Hintergrund der steigenden Nachfrage nach weniger wartungsintensiven SaaS-Lösungen kann es nicht überraschen, dass CloudBees im Jahr 2018 den Wettbewerber Codeship übernommen hat, einen Anbieter von Software as a Service im Bereich der kontinuierlichen Integration und Bereitstellung von Software.

Denn Jenkins ist technologisch nicht als hoch skalierbare SaaS-Anwendung für Hunderttausende von Anwendern konzipiert. Und sehr viele Anwender von Jenkins dürften ohnehin zum Eigenbetrieb von Jenkins tendieren. Jedenfalls zunächst.

Aussichten und Optionen

Die Zukunftsaussichten von Jenkins sind vor diesem Hintergrund heiter bis wolkig. Für Jenkins’ Zukunftsfähigkeit spricht, dass Jenkins schon lange auf dem Markt ist und zweifelsfrei einen großen Kreis von Anwendern hat, sicherlich nicht zuletzt aus der Java Community.

Die Doppel-Strategie vieler Anbieter von CI/CD-Lösungen, einerseits Unternehmen durch Hosting und Support beim Betrieb von Jenkins zu unterstützen, andererseits innovative alternative SaaS-Lösungen zu offerieren, spricht allerdings dafür, dass die Industrie damit rechnet, dass sich Software as a Service im Bereich CI/CD durchsetzen wird und sich somit Jenkins - jedenfalls im Eigenbetrieb - von einem vermeintlichen Standard zu einem deutlich unauffälligeren Dasein entwickeln könnte. Vom Markt verschwinden wird Jenkins in absehbarer Zukunft sicherlich nicht.

Man geht besser nicht davon aus, dass Jenkins ein Grasswurzel-Projekt wäre, das von einer finanziell selbstlosen Community organisiert würde. Die vergangene und die zukünftige Entwicklung von Jenkins wurde und wird weiterhin wesentlich von Unternehmen und Kapitalgebern mit einer legitimen Absicht der Gewinnerzielung beeinflusst. Ehrenrührig ist das nicht.

Es ist unternehmerisch aber immer riskant und marktwirtschaftlich etwas kurios, wenn Unternehmen gar kein Geld für das Nutzungsrecht an einer verwendeten Software zahlen und gleichzeitig hoffen, dass sich die technologische Herausforderung der (Weiter-) Entwicklung der benötigten Software von selbst lösen wird. Die Entwicklung von Software wird ja - anders als beispielsweise der Bau und Betrieb von Straßen - nicht aus dem Steueretat des Staates finanziert.

Das bedeutet in einem falschen Umkehrschluss übrigens nicht, dass kommerzielle Standardsoftware zwangsläufig hochpreisig sein müsste. Es gibt selten nur die beiden extremen Optionen zwischen kostenloser und sehr teurer Software.

Auch für freie oder quelloffene Software gibt es keine Ewigkeitsgarantie - im Gegenteil - und damit auch nicht für Jenkins. Die technischen Rahmenbedingungen ändern sich ständig. Der technische Fortschritt ist enorm. Selbst langjährige einflussreiche Entwickler von freier Software können das Interesse an einem Softwareprojekt verlieren, wenn sie ihren angestrebten Lebensstandard davon nicht finanzieren können.

Erfahrene Softwareentwickler wissen ganz genau, dass sie keine Software für die Ewigkeit erschaffen. Ein Haus wird vielleicht für Jahrzehnte oder für Jahrhunderte gebaut. Aber wenn man nicht ständig daran arbeitet, dann wird selbst ein Haus innerhalb von wenigen Jahren unbewohnbar und damit wertlos. Mit Software verhält es sich im Grunde nicht anders.

Der Code einer Software verändert sich zwar nicht von selbst, wohl aber ändern sich die verfügbare Hardware, das Betriebssystem, die Schnittstellen zu anderen Systemen und die Bekanntheit von Sicherheitslücken. Die technischen und wirtschaftlichen Rahmenbedingungen machen jede Software mit der Zeit nutzlos und damit wertlos, wenn man sie nicht regelmäßig an die aktuellen Bedingungen anpasst und erneuert.

Gerade bei lizenzkostenfreien Softwareprodukten sollte man immer ein Auge darauf haben, ob sie noch technologisch aktuell und wirtschaftlich interessant für ihre Sponsoren sind. Denn Innovation erfordert kreative Arbeit. Und Arbeit erfordert Zeit. Und Zeit ist bekanntlich Geld. Ob ein verwendetes Produkt noch auf der Höhe der Zeit ist, das wird man nur erfahren, wenn man die auf dem Markt angebotenen Lösungen von Zeit zu Zeit miteinander vergleicht.

Es spricht wenig dagegen, verschiedene CI/CD-Lösungen in einem Unternehmen zu evaluieren und parallel einzusetzen. Der Zeitaufwand ist überschaubar. Es spricht viel dafür, den verschiedenen agilen Entwicklerteams mehr als eine CI/CD-Lösung zur Auswahl zu geben und nicht nur eine pauschale Lösung vorzugeben. Insbesondere Software as a Service vereinfacht diese Herangehensweise ungemein.

Ein Wettbewerb im Bereich der CI/CD-Lösungen um die jeweils effektivste und effizienteste CI/CD-Lösung für ein Projekt muss für die Anwender absolut kein Nachteil sein. Der sehr dynamische Markt bietet eine breite Palette an Werkzeugen und eröffnet damit viele Chancen und Optionen zur Steigerung der Kreativität, Produktivität und Zufriedenheit von Entwicklerteams. Und das wirkt sich am Ende positiv auf das wirtschaftliche Ergebnis aus.