In meinem heutigen Beitrag kommentiere ich den 2024 State of Open Source Report und vergleiche die enthaltenen Ergebnisse mit meinen pers\u00f6nlichen Erfahrungen.<\/p>\n\n\n\n
Der 2024 State of Open Source Report (im Folgenden auch als Bericht oder Report bezeichnet) wurde von der Firma OpenLogic in Zusammenarbeit mit der Open Source Initiative (OSI) und der Eclipse Foundation erstellt. Der Bericht kann hier als PDF<\/a> kostenlos heruntergeladen werden (der Haken f\u00fcr den Empfang von Kommunikation muss nicht gesetzt werden). Ich werde in diesem Text h\u00e4ufig auf den Bericht als Quelle verweisen, sodass ich euch empfehle, den Report ebenfalls verf\u00fcgbar und im besten Fall gelesen zu haben. Seitenangaben beziehen sich auf das PDF mit dem Bericht.<\/p>\n\n\n\n Transparenzhinweis:<\/em> Ich arbeite als Technical Account Manager f\u00fcr die Firma Red Hat. Meine Arbeit beeinflusst meinen Blick auf den Bericht. Dieser Kommentar stellt ausschlie\u00dflich meine pers\u00f6nliche Sicht dar.<\/p>\n\n\n\n Im Zeitraum vom 10. Oktober bis 8. November 2023 wurde weltweit eine anonyme Umfrage durchgef\u00fchrt, welche insgesamt 2046 Antworten erhielt (siehe S. 4-6). Es findet sich darin kein Hinweis, ob die Umfrage repr\u00e4sentativ ist. Es werden jedoch Angaben dar\u00fcber gemacht, aus welcher Weltregion, Unternehmensgr\u00f6\u00dfe und Job-Rolle die Antworten stammen, um diese einordnen zu k\u00f6nnen.<\/p>\n\n\n\n Es freut mich zu lesen, dass 95 Prozent der Antworten belegen, dass der Anteil an Open Source in den an der Umfrage teilnehmenden Unternehmen gestiegen (67,57\u00a0%) oder gleichgeblieben (27\u00a0%) ist (siehe S. 7). Auff\u00e4llig ist allerdings auch, dass im Mittleren Osten 22,22% angaben, dass der Einsatz von Open Source zur\u00fcckgegangen ist. Unternehmen, die gar keine Open-Source-Software einsetzen, haben vermutlich nicht an der Umfrage teilgenommen. Der Bericht macht dazu keine Aussage. Auf Seite 8 findet sich die Aussage, dass 40\u00a0% aus der C-Level-Abteilung (z.B. CEO, CTO, CIO, CFO, etc.) angegeben haben, dass der Anteil an Open Source gleichgeblieben ist, w\u00e4hrend \u00fcber 60% der Teilnehmer aus technischen Rollen eine Zunahme von Open Source sehen. Laut Bericht deutet dies auf eine m\u00f6gliche Entfernung bzw. Trennung der F\u00fchrung von der Basis hin. Dieser Ansicht mag ich mich nicht anschlie\u00dfen, da immerhin 58,46% der F\u00fchrungskr\u00e4fte ebenfalls eine Zunahme von Open Source in ihren Unternehmen sehen; das ist von den 60% der technischen Rollen doch nun wirklich nicht weit weg. Interessant finde ich die genannten Gr\u00fcnde f\u00fcr den Einsatz von Open Source in Unternehmen (siehe S. 9-10). Ein wenig betr\u00fcbt es mich, dass knapp 37\u00a0% „Keine Lizenzkosten“ und „Kostenminimierung“ als wichtigstes Argument f\u00fcr den Einsatz von Open Source nannten; hat Open Source in meinen Augen doch so viel mehr zu bieten, w\u00e4hrend sich das Ziel der Kostenminimierung nicht in jedem Fall erreichen l\u00e4sst. Meiner pers\u00f6nlichen Erfahrung nach verschieben sich die Aufw\u00e4nde in vielen F\u00e4llen lediglich. So stellten einige Organisationen fest, dass der Einsatz kostenlos verf\u00fcgbarer Open-Source-Software mit einem h\u00f6heren Personalbedarf bzw. einem erh\u00f6hten Aufwand f\u00fcr Wissensaufbau und Fehleranalysekompetenz einhergeht. Hier finden sich zum Teil die Kosten wieder, die man zuvor f\u00fcr Lizenzen und externen Support aufgewendet hat. Es gibt hier keine pauschal g\u00fcltige Empfehlung. Jedes Unternehmen muss f\u00fcr sich selbst bewerten, ob es das erforderliche Personal selbst aufbauen bzw. einstellen kann oder ob der Einkauf externer Unterst\u00fctzung in Zeiten von Fachkr\u00e4ftemangel nicht doch g\u00fcnstiger ist.<\/p>\n\n\n\n Macht man sich von externem Wissen abh\u00e4ngig, l\u00e4uft dies dem Ziel entgegen, sich mit Open Source unabh\u00e4ngiger von einzelnen Herstellern machen zu wollen. Hier ist darauf zu achten, wie viel Auswahl an Anbietern am Markt besteht.<\/p>\n\n\n\n Ich nehme allerdings ebenfalls wahr, dass die wirtschaftliche Situation in vielen Unternehmen angespannt ist und kann das Ziel, Kosten zu reduzieren, nachvollziehen. Ich hoffe darauf, dass Unternehmen, die Open Source zur Kostensenkung einf\u00fchren, auch die weiteren Vorteile, wie z.B. die Vermeidung von Vendor Lock-ins<\/em> sowie offene Standards und Interoperabilit\u00e4t erkennen und zu sch\u00e4tzen lernen. Die zuletzt genannten Punkte sind immerhin 21\u00a0% der Befragten heute schon wichtig. Wie bereits im vorangegangenen Abschnitt erw\u00e4hnt, ist f\u00fcr den Einsatz von Open Source die Verf\u00fcgbarkeit des notwendigen Wissens und entsprechende Fertigkeiten notwendig. Immerhin 38\u00a0% der befragten Unternehmen sehen es als eine Herausforderung an, das notwendige Wissen und die F\u00e4higkeiten zum effizienten Einsatz von Open Source im Unternehmen verf\u00fcgbar zu machen (S. 13). Dabei versuchen sie, dies auf unterschiedlichen Wegen verf\u00fcgbar zu machen. Das Diagramm auf Seite 14 zeigt, dass die Mehrheit mit 45% auf Training des eigenen Personals setzt. Weitere 38% versuchen, Personal mit dem ben\u00f6tigten Wissen einzustellen. Ich arbeite aktuell selbst in einem Unternehmen, in dem die Fort- und Weiterbildung der eigenen Mitarbeiter einen hohen Stellenwert besitzt. Ich freue mich sehr, dass mein Unternehmen mich aktiv dabei unterst\u00fctzt, mein Wissen aktuell zu halten und in verschiedenen Bereichen auszubauen.<\/p>\n\n\n\n Ohne einen Beleg zur Hand zu haben, meine ich mich zu erinnern, dass die Qualifizierung bestehenden Personals f\u00fcr ein Unternehmen h\u00e4ufig g\u00fcnstiger ist, als neues Personal einstellen und einarbeiten zu m\u00fcssen. Falls ihr dazu eine gute Quelle habt, teilt sie mir doch bitte in den Kommentaren mit.<\/p>\n\n\n\n Auf Seite 13 des Berichts findet sich die Aussage, dass es f\u00fcr 40\u00a0% aller Umfrageteilnehmer eine gro\u00dfe bis sehr gro\u00dfe Herausforderung darstellt, die Systeme und Anwendungen auf einem aktuellen Stand (Patchlevel) zu halten. Nach meiner Erfahrung z\u00e4hlen ein geringer Automatisierungsgrad, unzureichende Testprozeduren und eine zu starre Aufbauorganisation mit komplizierten und langwierigen Abstimmungsprozessen zu den gr\u00f6\u00dften Problemen in diesem Bereich. Wenn Wartungsfenster zur Installation von (Sicherheits-)Updates mit 3-6 Monaten Vorlauf angek\u00fcndigt und geplant werden m\u00fcssen und es keinen Prozess f\u00fcr schnelle Notfallupdates gibt, kann man halt nicht innerhalb von 72 Stunden reagieren und Schwachstellen schlie\u00dfen. Wenn die Kommunikation zwischen Betriebs- und Anwendungs-Team rein \u00fcber Ticketsystem l\u00e4uft, hat man zwar einen sauberen Prozessablauf mit Genehmigungs- und Pr\u00fcfschritten; werden die Schritte jedoch alle manuell ausgef\u00fchrt, darf man sich nicht wundern, wenn Updates vier Tage statt vier Stunden brauchen.<\/p>\n\n\n\n Noch immer begegnen mir im Gespr\u00e4ch Szenarien, wo Anwendungsteams nicht \u00fcber Testsysteme und Testpl\u00e4ne verf\u00fcgen. Die Folgen eines Updates\/Patches lassen sich nur direkt in Produktionsumgebung pr\u00fcfen. Bei Fehlern kommt es dann sofort zu einer Beeintr\u00e4chtigung des Dienstes und der Stresslevel steigt. Wo es bereits an der F\u00e4higkeit mangelt, \u00c4nderungen zeitnah zu verifizieren, fehlt oft auch die M\u00f6glichkeit, auf einen zuletzt als funktionierend bekannten Stand zur\u00fcckzurollen. Hier bleibt nur der Weg voran unter Einsatz aller verf\u00fcgbaren Ressourcen, bis das Problem behoben oder das Unternehmen insolvent ist.<\/p>\n\n\n\n Nicht immer ist es ganz so dramatisch. H\u00e4ufig l\u00f6st mangelnde Automation einen langwierigen Abstimmungsprozess aus. Viele Personen m\u00fcssen Zeit einplanen, um diverse Schritte im Prozessablauf manuell auszuf\u00fchren, zu testen und zu dokumentieren. Schnell sind 3,6 kg Excel-Dateien erstellt, das Update aber immer noch nicht abgeschlossen.<\/p>\n\n\n\n Ich erinnere mich an die sch\u00f6ne Zeit zwischen 2011 und 2014. Unser damaliger stellvertretender Abteilungsleiter hatte die Idee, DevOps auszuprobieren. Dazu wurden Teams aus Entwicklern und Systemadministratoren gebildet, die nun gemeinsam f\u00fcr den Betrieb und die Verf\u00fcgbarkeit bestimmter Anwendungen verantwortlich waren. Statt den auf Papier dokumentierten Verantwortungs\u00fcberg\u00e4ngen und dem daraus h\u00e4ufig folgenden Hin- und Herschiebens des schwarzen Peters sa\u00dfen wir jetzt gemeinsam in einem Boot und hatten gemeinsame Ziele. Wir lernten dabei die Sicht- und Arbeitsweise der jeweils anderen Job-Rolle kennen und zu verstehen. Und im gemeinsamen Dialog, gelang es uns Automationsprozesse zu entwickeln, um Updates schneller und erfolgreicher durchf\u00fchren zu k\u00f6nnen. Leider \u00fcberlebte dieses Modell die Zeit nicht. Heute ist mir bekannt, dass mit dem Wechsel dieses Modells auch die alten Probleme zur\u00fcckkehrten und deutlich weniger Updates durchgef\u00fchrt werden.<\/p>\n\n\n\n Oft liegt die Verantwortung f\u00fcr die Installation von Updates\/Patches beim Betrieb. Jedoch ist nur das Anwendungsteam in der Lage, die korrekte Funktionsf\u00e4higkeit der Anwendung\/des Dienstes zu beurteilen. Auch wenn manche Abteilungsleiter es nicht gerne h\u00f6ren, es geht am besten gemeinsam, mit kurzen Abstimmungswegen \u00fcber Team- und Abteilungsgrenzen hinweg.<\/p>\n\n\n\n Der zweite Schl\u00fcssel zum Erfolg ist Automation. Lasst den Automaten die einzelnen Prozessschritte ausf\u00fchren, welche in der Regel wie folgt aussehen:<\/p>\n\n\n\n Zeit und Energie, die hier investiert werden, zahlen sich in aktuellen Systemen mit weniger Sicherheitsl\u00fccken aus. Schafft einen Raum, in dem sich eure Experten aus Systemadministration und Anwendungsentwicklung austauschen und abstimmen k\u00f6nnen.<\/p>\n\n\n\n Selbstverst\u00e4ndlich haben die Qualit\u00e4t der vom Hersteller bereitgestellten Updates ebenfalls einen gro\u00dfen Einfluss auf den Erfolg von Patchinstallationen. Sollte es hier wiederholt Probleme geben und keine Besserung in Sicht sein, ist ggf. ein Wechsel des Anbieters in Erw\u00e4gung zu ziehen. Doch bevor ihr euch Hals \u00fcber Kopf in die Migration st\u00fcrzt, denkt daran, dass das Gras auf der anderen Wiese stets gr\u00fcner wirkt, als es ist. Es geht nicht ohne ausf\u00fchrliche Tests.<\/p>\n\n\n\n Ich w\u00fcnsche allen, die sich f\u00fcr Updates und Patches N\u00e4chte und Wochenenden um die Ohren schlagen m\u00fcssen, dass sich die Situation f\u00fcr euch bessert und sich dies im n\u00e4chsten Open Source Statusbericht ablesen l\u00e4sst.<\/p>\n\n\n\n Manche nennen es den Giftschrank, andere die Schmuddelecke. Gemeint sind damit Betriebssystem-Releases und Anwendungen, die das Ende ihres Lebenszyklus erreicht oder schon \u00fcberschritten haben. Laut Seite 13 des Berichts ist dies f\u00fcr 42\u00a0% der Umfrageteilnehmer ein Thema. Die Gr\u00fcnde warum diese Systeme noch existieren, lauten h\u00e4ufig sehr \u00e4hnlich. Fast immer l\u00e4uft eine gesch\u00e4ftskritische Anwendung darauf,<\/p>\n\n\n\n Im hier kommentierten Bericht wird auf Seite 15 ausgewiesen, dass 22\u00a0% der Befragten noch CentOS einsetzten, dessen Release 7 seit dem 30. Juni 2024 End-of-Life (EoL) ist. In der Umfrage kommt es sogar auf Platz 3 der am h\u00e4ufigsten eingesetzten Distributionen. Egal ob man nun EoL-Betriebssysteme oder EoL-Laufzeitumgebungen betrachtet, die L\u00f6sung ist stets dieselbe. Die dazugeh\u00f6rige Anwendung muss zuerst auf einer neueren und unterst\u00fctzten Version laufen, bevor die alte abgeschaltet werden kann. Dazu m\u00fcssen Teams in der Lage sein, Anwendungen neu deployen und das Deployment testen zu k\u00f6nnen. Auch hier helfen Testsysteme, -prozeduren und Automation. Auch hierbei ist es unerl\u00e4sslich, dass Betrieb und Anwendungsteams zusammenarbeiten, um den Erfolg der Migration sicherzustellen. Je schneller Feedback-Loops und Abstimmungsprozesse sind, desto schneller sind notwendige Prozeduren etabliert. Die Zeit f\u00fcr Releasewechsel l\u00e4sst sich so signifikant verk\u00fcrzen. Ressourcen sind damit schneller frei und k\u00f6nnen f\u00fcr innovative Entwicklungsprojekte genutzt werden.<\/p>\n\n\n\n Leider erlebe ich h\u00e4ufig, dass Abteilungen nur in ihrem eigenen Bereich nach L\u00f6sungen suchen und den Kontakt zu anderen Abteilungen meiden, ja beinahe scheuen. Doch ist dies kein technisches Problem. Es ist eine organisatorische Herausforderung, die angegangen werden muss. Es liegt doch im Interesse aller Beteiligten, regelm\u00e4\u00dfig wiederkehrende Releasewechsel schnell und st\u00f6rungsarm abwickeln zu k\u00f6nnen.<\/p>\n\n\n\n In meinem beruflichen Alltag erlebe ich h\u00e4ufig, dass In-Place-Upgrades als Allheilmittel angesehen werden. Ich hingegen bin kein gro\u00dfer Freund davon. Sie sind der vermeintlich einfache Weg, doch f\u00fchren sie zur dunklen Seite der Macht. Ein In-Place-Upgrade aktualisiert das Betriebssystem inkl. der installierten Bibliotheken und Laufzeitumgebungen. Es befreit nicht von der obligatorischen Aufgabe, die darauf laufenden Anwendungen im Anschluss zu testen. Stellt man dabei Fehler fest, gibt es h\u00e4ufig kein Zur\u00fcck mehr. Eine Ausnahme bilden hier virtuelle Umgebungen, bei denen man zuvor einen Snapshot der virtuellen Maschine erstellen kann.<\/p>\n\n\n\n Wer eine Anwendung immer nur mit In-Place-Upgrades von einem Release auf das n\u00e4chste rettet, verliert mit einer gr\u00f6\u00dferen Wahrscheinlichkeit die F\u00e4higkeit, die Anwendung sauber neu zu deployen. Man tut sich hiermit keinen Gefallen.<\/p>\n\n\n\n Ich bin der \u00dcberzeugung, dass Organisationen in der Lage sein m\u00fcssen, ihre gesch\u00e4ftskritischen Anwendungen mit einem definierten Zustand automatisiert ausrollen zu k\u00f6nnen. Dies unterst\u00fctzt Releasewechsel, erleichtert den Auf- und Abbau von Testumgebungen sowie die Verifizierung von Fehlern und das Nachstellen von Bugs. Anwendungen k\u00f6nnen so auch deutlich leichter und schneller gegen neuen Bibliotheken und Laufzeitumgebungen getestet werden. Es lohnt sich, Zeit zum Sch\u00e4rfen der Axt zu investieren, bevor man mit dem F\u00e4llen der B\u00e4ume beginnt. Oder anders ausgedr\u00fcckt, wer keine Zeit hat, den Zaun zu reparieren, weil er mit K\u00fche einfangen besch\u00e4ftigt ist, wird nie zum Melken kommen.<\/p>\n\n\n\n In dieser Kategorie auf Seite 15 listet der Bericht die Linux-Distributionen auf, die von den Umfrageteilnehmern verwendet werden. Ubuntu f\u00fchrt diese Liste an und liegt mit 46\u00a0% vor Debian mit 23%. Platz 3 geht an CentOS mit 22%. Den undankbaren vierten Platz belegt Amazon Linux mit knapp 20%. Die noch recht neue Distribution CentOS Stream findet sich auf Platz 13 mit 9,5%. Ich habe diese Werte mit denen aus dem State of Open Source Report von 2023 verglichen. Ubuntu hat im Vergleich um 27\u00a0% zugelegt (Platz 1 mit 29% in 2023). Debian kam 2023 mit 16,63% auf Platz 6 hinter CentOS Stream mit 16,74%. Die Pl\u00e4tze 2 und 3 wurden 2023 von Alpine Linux (21,1%) und Oracle Linux (19,72%) belegt. CentOS kam damals mit 15% auf Platz 8. Der Bericht von 2024 spekuliert, dass Red Hat’s \u00c4nderung beim Zugriff auf den RHEL Quelltext und das EoL von CentOS mitverantwortlich f\u00fcr diese Ver\u00e4nderungen sind, kann jedoch keine klaren Belege daf\u00fcr liefern. Laut Bericht sind die Linux Wars<\/em> noch nicht entschieden und wir k\u00f6nnen auf den kommenden Bericht gespannt sein.<\/p>\n\n\n\n Es hat mich \u00fcberrascht, dass RHEL und SLES es gar nicht in das Ranking geschafft haben. Unter Ber\u00fccksichtigung, dass die Kostenreduktion in diesem Bericht die Hauptmotivation f\u00fcr den Einsatz von Open Source darstellt, l\u00e4sst sich ggf. erkl\u00e4ren, warum Distributionen gerade nicht hoch im Kurs stehen, die kostenpflichtige Support-Subskriptionen f\u00fcr den produktiven Einsatz voraussetzen.<\/p>\n\n\n\n Ich freue mich schon darauf, herauszufinden, wie dieses Ranking im n\u00e4chsten Bericht aussieht.<\/p>\n\n\n\n Das Diagramm auf Seite 17 zeigt das Ranking der wichtigsten Cloud-Native Open Source Technologies f\u00fcr die Umfrageteilnehmer. Platz 1 wird von Docker mit 44,6\u00a0% eingenommen, gefolgt von Kubernetes mit 33,61\u00a0%. Der gro\u00dfe Vorsprung von Docker vor Podman mit 16,6\u00a0% hat mich ein wenig \u00fcberrascht. Ich h\u00e4tte den Abstand nicht als so gro\u00df eingesch\u00e4tzt. Hier interessiert mich, welche Vorteile die Nutzer in Docker gegen\u00fcber Podman sehen. Leider macht der Bericht hierzu keine Aussage. Ich selbst nutze Podman unter Debian, Fedora und RHEL. In Debian stehen ung\u00fcnstigerweise nur \u00e4ltere Podman Releases zur Verf\u00fcgung, denen wichtige Funktionen fehlen. Dies ist in meinen Augen eine Erkl\u00e4rung, warum Podman gerade in diesen Distributionen wenig genutzt wird. Dies ist allerdings nur wilde Spekulation meinerseits. Ich kann dies nicht belegen. F\u00fcr mich ebenfalls unerwartet ist OpenStack mit knapp 18\u00a0% sowie OKD und Rancher mit jeweils unter 10%. In diesem Bereich leide ich vermutlich an Betriebsblindheit. Wenn man bei Red Hat arbeitet, kann man leicht den Eindruck gewinnen, dass die ganze Welt nur noch OpenShift macht. Ich freue mich darauf, diese Kategorie \u00fcber die n\u00e4chsten Jahre zu beobachten und zu sehen, wie sich Podman entwickelt, wof\u00fcr ich eine gewisse Vorliebe habe.<\/p>\n\n\n\n Wer die Kategorie Ansible<\/a> in diesem Blog kennt, wei\u00df bereits, dass ich mich gerne mit Ansible besch\u00e4ftige. So freut es mich zu sehen, dass Ansible im betrachteten Bericht auf Seite 25 Platz 1 mit 30% belegt. \u00dcberraschend finde ich hingegen, dass 27% angaben, keinerlei Open Source Automations- bzw. Konfigurationsmanagement zu verwenden. Der Bericht f\u00fchrt dies auf Antworten aus jungen Unternehmen zur\u00fcck, die (noch) keine Notwendigkeit f\u00fcr Automation sehen. Ich m\u00f6chte diesen Unternehmen empfehlen, fr\u00fchzeitig eine Automation First Philosophie zu entwickeln, da ich \u00fcberzeugt bin, dass sich ein konsequenter Einsatz von Automations- und Konfigurationsmanagementwerkzeugen schnell auszahlt.<\/p>\n\n\n\n Unter den Systemadministratoren liegen Ansible (40\u00a0%) und Puppet (36%) als beliebteste Werkzeuge nah beieinander. Es ist immer gut, Auswahl und Wettbewerb zu haben. Ich freue mich \u00fcber den Anteil von Puppet, gerade weil ich in den Nachrichten nur noch wenig Notiz davon nehme. Salt liegt bei unter 10\u00a0% und ich habe auch schon l\u00e4ngere Zeit nichts mehr von diesem Projekt geh\u00f6rt. Schade, die Architektur von Salt finde ich ganz interessant. Im aktuellen Bericht nutzen knapp 23\u00a0% Terraform und der Lizenzwechsel zeigt noch keine gro\u00dfe Abwanderung zu dessen Fork OpenTofu. Da die Datenerhebung jedoch Ende 2023 durchgef\u00fchrt wurde, kann der Bericht eine etwaige Nutzerabwanderung noch nicht darstellen. In 2024 hat IBM die \u00dcbernahme von Hashi Corp bekannt gegeben. Ich bin gespannt, wie es mit den Produkten und deren Nutzung weitergeht. Hoffentlich gibt der n\u00e4chste Bericht erste Einblicke. Durch die Arbeit in einem gro\u00dfen IT-Unternehmen mit einem starken eigenen Portfolio f\u00e4llt es leicht, eine Betriebsblindheit f\u00fcr die Entwicklungen au\u00dferhalb des eigenen Kosmos zu entwickeln. Berichte wie der 2024 State of the Open Source Report helfen, der Betriebsblindheit entgegenzuwirken.<\/p>\n\n\n\n Ich habe nicht alle Kategorien des aktuellen Berichts im Detail betrachtet, sondern mir diejenigen herausgepickt, die mein pers\u00f6nliches Interesse ansprechen. Dar\u00fcber in diesem Blog zu schreiben, hilft mir, \u00fcber den Bericht und meine Erfahrungen zu reflektieren. Und wenn euch dieser Kommentar ebenfalls gef\u00e4llt, freue ich mich umso mehr.<\/p>\n","protected":false},"excerpt":{"rendered":" In meinem heutigen Beitrag kommentiere ich den 2024 State of Open Source Report und vergleiche die enthaltenen Ergebnisse mit meinen pers\u00f6nlichen Erfahrungen. Der 2024 State of Open Source Report (im Folgenden auch als Bericht oder Report bezeichnet) wurde von der Firma OpenLogic in Zusammenarbeit mit der Open Source Initiative (OSI) und der Eclipse Foundation erstellt. [Weiterlesen…]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_metis_text_type":"","_metis_text_length":0,"_post_count":0,"footnotes":""},"categories":[1],"tags":[632,71,430,305],"class_list":["post-3921","post","type-post","status-publish","format-standard","hentry","category-allgemein","tag-kommentar","tag-open-source","tag-osbn","tag-planet"],"_links":{"self":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/3921","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/comments?post=3921"}],"version-history":[{"count":2,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/3921\/revisions"}],"predecessor-version":[{"id":3926,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/posts\/3921\/revisions\/3926"}],"wp:attachment":[{"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/media?parent=3921"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/categories?post=3921"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.my-it-brain.de\/wordpress\/wp-json\/wp\/v2\/tags?post=3921"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Informationen zum Bericht<\/h2>\n\n\n\n
Nutzung und Verbreitung von Open Source in Unternehmen<\/h2>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\nHerausforderungen beim Einsatz von Open Source<\/h2>\n\n\n\n
<\/p>\n\n\n\nUpdates und Patches<\/h3>\n\n\n\n
<\/p>\n\n\n\n\n
Wartung von End-of-Life Versionen<\/h3>\n\n\n\n
<\/p>\n\n\n\n\n
<\/p>\n\n\n\nOpen Source Distributionen<\/h2>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\nCloud-Native Open Source Technologies<\/h2>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\nAutomations- und Konfigurations-Management<\/h2>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\nFazit<\/h2>\n\n\n\n