Schlagwort-Archiv: Open Source

Versteckte CLI-Optionen in Open-Source-Projekten: Fluch oder Segen?

Transparenzhinweis: Der Entwurf dieses Artikels wurde mithilfe der Mistral-KI Le Chat erstellt und von mir redigiert.

Versteckte CLI-Optionen: Warum Entwickler sie nutzen – und warum das umstritten ist

In der Welt der Open-Source-Software gibt es eine Praxis, die immer wieder für Diskussionen sorgt: das Verstecken von CLI-Optionen (Command Line Interface). Diese Optionen sind oft nicht in der offiziellen Dokumentation aufgeführt, werden aber dennoch im Code implementiert – sei es für Debugging-Zwecke, als Notlösung für spezielle Anwendungsfälle oder als „Geheimtipp“ für erfahrene Nutzer.

Ein Beispiel ist der Commit im xfsprogs-Projekt, der die Erstellung von XFS-Dateisystemen kleiner als 300 MB standardmäßig blockiert. Gleichzeitig wurde eine undokumentierte Option (--unsupported) eingeführt, um diese Beschränkung zu umgehen – allerdings ohne Hinweis in der Manpage mkfs.xfs(8) oder Hilfeausgabe.

Doch warum tun Entwickler das? Und welche Vor- und Nachteile hat diese Praxis für Nutzer, Maintainer und die Community?


Warum versteckte CLI-Optionen existieren

1. Flexibilität für Entwickler und Tester

  • Debugging & Testing: Versteckte Optionen ermöglichen es Entwicklern, spezielle Testumgebungen zu simulieren oder Fehler zu reproduzieren, ohne die Stabilität der Software für Endnutzer zu gefährden.
  • Beispiel: Im xfsprogs-Commit wird die 300-MB-Beschränkung für automatisierte Tests (fstests) deaktiviert, wenn bestimmte Umgebungsvariablen gesetzt sind. Das verhindert, dass Hunderte von Tests angepasst werden müssen.

2. Schnelle Lösungen für Nischenprobleme

  • Manchmal gibt es seltene Anwendungsfälle, die so selten sind, dass eine offizielle Unterstützung nicht sinnvoll erscheint.
  • Beispiel: Die Option --unsupported für mkfs.xfs, da diese im Normalbetrieb gefährliche Folgen, wie den Verlust von Leistung und Redundanz, haben können.

3. Vermeidung von Missbrauch

  • Manche Optionen sind potenziell gefährlich (z. B. das Umgehen von Sicherheitsprüfungen). Durch das Verstecken sollen nur Nutzer mit entsprechendem Wissen darauf zugreifen.

Die Kehrseite der Medaille: Warum versteckte Optionen problematisch sind

1. Mangelnde Transparenz

  • Open Source lebt von Transparenz und Gemeinschaft. Versteckte Optionen widersprechen diesem Prinzip: Nutzer wissen nicht, welche Möglichkeiten es gibt, und können die Software nicht voll ausschöpfen und damit nicht uneingeschränkt nutzen.
  • Frage: Wenn eine Option (nur in seltenen Ausnahmefällen) nützlich ist, warum sollte sie nicht dokumentiert werden?

2. Wartungsaufwand und „Technical Debt“

  • Undokumentierte Features werden schnell zu „Technical Debt“: Neue Entwickler kennen sie nicht, Nutzer stoßen zufällig darauf und die Optionen werden nie offiziell unterstützt, obwohl sie vielleicht weit verbreitet sind.
  • Beispiel: Im Linux-Kernel gibt es zahlreiche obskure Kernel-Parameter, die nur in Mailinglisten oder alten Foren erwähnt werden.

3. Frustration für Nutzer

  • Nutzer, die auf ein Problem stoßen, finden keine Lösung in der Dokumentation, obwohl diese vielleicht existiert. Das führt zu unnötigen Support-Anfragen oder Workarounds.
  • Beispiel: „Für eigene Tests möchte ich XFS-Dateisysteme kleiner 300 MB erstellen. Bis ich die Option --unsupported im Quelltext gefunden habe, war mir dies nicht möglich, ohne eine veraltete Version von xfsprogs zu nutzen.“

Deine Meinung zählt: Sollten versteckte CLI-Optionen abgeschafft werden?

Die Diskussion um versteckte Optionen ist auch eine Frage der Philosophie: Sollte Open-Source-Software maximale Freiheit bieten – auch auf Kosten von Komplexität? Oder sollte sie benutzerfreundlich sein und nur offizielle, getestete Features anbieten?

Was denkst du?

  • Hast du schon einmal von einer versteckten CLI-Option profitiert oder dich über das Fehlen einer Dokumentation geärgert?
  • Sollten Projekte wie xfsprogs alle Optionen offenlegen, selbst wenn sie offiziell nicht unterstützt und im IT-Betrieb gefährlich sind?
  • Oder ist es in Ordnung, wenn Entwickler „Hintertüren“ für spezielle Fälle einbauen?

Teile deine Erfahrung in den Kommentaren!

Kommentar zum 2024 State of Open Source Report

In meinem heutigen Beitrag kommentiere ich den 2024 State of Open Source Report und vergleiche die enthaltenen Ergebnisse mit meinen persönlichen 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. Der Bericht kann hier als PDF kostenlos heruntergeladen werden (der Haken für den Empfang von Kommunikation muss nicht gesetzt werden). Ich werde in diesem Text häufig auf den Bericht als Quelle verweisen, sodass ich euch empfehle, den Report ebenfalls verfügbar und im besten Fall gelesen zu haben. Seitenangaben beziehen sich auf das PDF mit dem Bericht.

Transparenzhinweis: Ich arbeite als Technical Account Manager für die Firma Red Hat. Meine Arbeit beeinflusst meinen Blick auf den Bericht. Dieser Kommentar stellt ausschließlich meine persönliche Sicht dar.

Informationen zum Bericht

Im Zeitraum vom 10. Oktober bis 8. November 2023 wurde weltweit eine anonyme Umfrage durchgeführt, welche insgesamt 2046 Antworten erhielt (siehe S. 4-6). Es findet sich darin kein Hinweis, ob die Umfrage repräsentativ ist. Es werden jedoch Angaben darüber gemacht, aus welcher Weltregion, Unternehmensgröße und Job-Rolle die Antworten stammen, um diese einordnen zu können.

Nutzung und Verbreitung von Open Source in Unternehmen

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 %) oder gleichgeblieben (27 %) ist (siehe S. 7). Auffällig ist allerdings auch, dass im Mittleren Osten 22,22% angaben, dass der Einsatz von Open Source zurückgegangen 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 % aus der C-Level-Abteilung (z.B. CEO, CTO, CIO, CFO, etc.) angegeben haben, dass der Anteil an Open Source gleichgeblieben ist, während über 60% der Teilnehmer aus technischen Rollen eine Zunahme von Open Source sehen. Laut Bericht deutet dies auf eine mögliche Entfernung bzw. Trennung der Führung von der Basis hin. Dieser Ansicht mag ich mich nicht anschließen, da immerhin 58,46% der Führungskräfte 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ünde für den Einsatz von Open Source in Unternehmen (siehe S. 9-10). Ein wenig betrübt es mich, dass knapp 37 % „Keine Lizenzkosten“ und „Kostenminimierung“ als wichtigstes Argument für den Einsatz von Open Source nannten; hat Open Source in meinen Augen doch so viel mehr zu bieten, während sich das Ziel der Kostenminimierung nicht in jedem Fall erreichen lässt.

Meiner persönlichen Erfahrung nach verschieben sich die Aufwände in vielen Fällen lediglich. So stellten einige Organisationen fest, dass der Einsatz kostenlos verfügbarer Open-Source-Software mit einem höheren Personalbedarf bzw. einem erhöhten Aufwand für Wissensaufbau und Fehleranalysekompetenz einhergeht. Hier finden sich zum Teil die Kosten wieder, die man zuvor für Lizenzen und externen Support aufgewendet hat. Es gibt hier keine pauschal gültige Empfehlung. Jedes Unternehmen muss für sich selbst bewerten, ob es das erforderliche Personal selbst aufbauen bzw. einstellen kann oder ob der Einkauf externer Unterstützung in Zeiten von Fachkräftemangel nicht doch günstiger ist.

Macht man sich von externem Wissen abhängig, läuft dies dem Ziel entgegen, sich mit Open Source unabhängiger von einzelnen Herstellern machen zu wollen. Hier ist darauf zu achten, wie viel Auswahl an Anbietern am Markt besteht.

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ühren, auch die weiteren Vorteile, wie z.B. die Vermeidung von Vendor Lock-ins sowie offene Standards und Interoperabilität erkennen und zu schätzen lernen. Die zuletzt genannten Punkte sind immerhin 21 % der Befragten heute schon wichtig.

Herausforderungen beim Einsatz von Open Source

Wie bereits im vorangegangenen Abschnitt erwähnt, ist für den Einsatz von Open Source die Verfügbarkeit des notwendigen Wissens und entsprechende Fertigkeiten notwendig. Immerhin 38 % der befragten Unternehmen sehen es als eine Herausforderung an, das notwendige Wissen und die Fähigkeiten zum effizienten Einsatz von Open Source im Unternehmen verfügbar zu machen (S. 13). Dabei versuchen sie, dies auf unterschiedlichen Wegen verfügbar 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ötigten 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ützt, mein Wissen aktuell zu halten und in verschiedenen Bereichen auszubauen.

Ohne einen Beleg zur Hand zu haben, meine ich mich zu erinnern, dass die Qualifizierung bestehenden Personals für ein Unternehmen häufig günstiger ist, als neues Personal einstellen und einarbeiten zu müssen. Falls ihr dazu eine gute Quelle habt, teilt sie mir doch bitte in den Kommentaren mit.

Updates und Patches

Auf Seite 13 des Berichts findet sich die Aussage, dass es für 40 % aller Umfrageteilnehmer eine große bis sehr große Herausforderung darstellt, die Systeme und Anwendungen auf einem aktuellen Stand (Patchlevel) zu halten.

Nach meiner Erfahrung zählen ein geringer Automatisierungsgrad, unzureichende Testprozeduren und eine zu starre Aufbauorganisation mit komplizierten und langwierigen Abstimmungsprozessen zu den größten Problemen in diesem Bereich. Wenn Wartungsfenster zur Installation von (Sicherheits-)Updates mit 3-6 Monaten Vorlauf angekündigt und geplant werden müssen und es keinen Prozess für schnelle Notfallupdates gibt, kann man halt nicht innerhalb von 72 Stunden reagieren und Schwachstellen schließen. Wenn die Kommunikation zwischen Betriebs- und Anwendungs-Team rein über Ticketsystem läuft, hat man zwar einen sauberen Prozessablauf mit Genehmigungs- und Prüfschritten; werden die Schritte jedoch alle manuell ausgeführt, darf man sich nicht wundern, wenn Updates vier Tage statt vier Stunden brauchen.

Noch immer begegnen mir im Gespräch Szenarien, wo Anwendungsteams nicht über Testsysteme und Testpläne verfügen. Die Folgen eines Updates/Patches lassen sich nur direkt in Produktionsumgebung prüfen. Bei Fehlern kommt es dann sofort zu einer Beeinträchtigung des Dienstes und der Stresslevel steigt. Wo es bereits an der Fähigkeit mangelt, Änderungen zeitnah zu verifizieren, fehlt oft auch die Möglichkeit, auf einen zuletzt als funktionierend bekannten Stand zurückzurollen. Hier bleibt nur der Weg voran unter Einsatz aller verfügbaren Ressourcen, bis das Problem behoben oder das Unternehmen insolvent ist.

Nicht immer ist es ganz so dramatisch. Häufig löst mangelnde Automation einen langwierigen Abstimmungsprozess aus. Viele Personen müssen Zeit einplanen, um diverse Schritte im Prozessablauf manuell auszuführen, zu testen und zu dokumentieren. Schnell sind 3,6 kg Excel-Dateien erstellt, das Update aber immer noch nicht abgeschlossen.

Ich erinnere mich an die schöne 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ür den Betrieb und die Verfügbarkeit bestimmter Anwendungen verantwortlich waren. Statt den auf Papier dokumentierten Verantwortungsübergängen und dem daraus häufig folgenden Hin- und Herschiebens des schwarzen Peters saßen 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ühren zu können. Leider überlebte dieses Modell die Zeit nicht. Heute ist mir bekannt, dass mit dem Wechsel dieses Modells auch die alten Probleme zurückkehrten und deutlich weniger Updates durchgeführt werden.

Oft liegt die Verantwortung für die Installation von Updates/Patches beim Betrieb. Jedoch ist nur das Anwendungsteam in der Lage, die korrekte Funktionsfähigkeit der Anwendung/des Dienstes zu beurteilen. Auch wenn manche Abteilungsleiter es nicht gerne hören, es geht am besten gemeinsam, mit kurzen Abstimmungswegen über Team- und Abteilungsgrenzen hinweg.

Der zweite Schlüssel zum Erfolg ist Automation. Lasst den Automaten die einzelnen Prozessschritte ausführen, welche in der Regel wie folgt aussehen:

  1. Anwendung bzw. Dienste stoppen
  2. Updates/Patches installieren
  3. System neu starten
  4. Anwendung bzw. Dienste starten
  5. Anwendung/Dienst auf korrekte Ausführung testen
  6. Bei Fehlschlag –> Rollback bzw. bei Erfolg –> Update erfolgreich

Zeit und Energie, die hier investiert werden, zahlen sich in aktuellen Systemen mit weniger Sicherheitslücken aus. Schafft einen Raum, in dem sich eure Experten aus Systemadministration und Anwendungsentwicklung austauschen und abstimmen können.

Selbstverständlich haben die Qualität der vom Hersteller bereitgestellten Updates ebenfalls einen großen 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ägung zu ziehen. Doch bevor ihr euch Hals über Kopf in die Migration stürzt, denkt daran, dass das Gras auf der anderen Wiese stets grüner wirkt, als es ist. Es geht nicht ohne ausführliche Tests.

Ich wünsche allen, die sich für Updates und Patches Nächte und Wochenenden um die Ohren schlagen müssen, dass sich die Situation für euch bessert und sich dies im nächsten Open Source Statusbericht ablesen lässt.

Wartung von End-of-Life Versionen

Manche nennen es den Giftschrank, andere die Schmuddelecke. Gemeint sind damit Betriebssystem-Releases und Anwendungen, die das Ende ihres Lebenszyklus erreicht oder schon überschritten haben. Laut Seite 13 des Berichts ist dies für 42 % der Umfrageteilnehmer ein Thema.

Die Gründe warum diese Systeme noch existieren, lauten häufig sehr ähnlich. Fast immer läuft eine geschäftskritische Anwendung darauf,

  • Von der im Unternehmen niemand mehr weiß, wie sie funktioniert, um sie auf ein neues Betriebssystem zu migrieren
  • Für deren Migration keine Ressourcen verfügbar sind
  • Mit der komplizierte und langwierige Abstimmungsprozesse zur Migration verbunden sind; niemand will das Ding anfassen
  • Die für keine aktuellere Betriebssystem-Version zertifiziert ist

Im hier kommentierten Bericht wird auf Seite 15 ausgewiesen, dass 22 % 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äufigsten eingesetzten Distributionen.

Egal ob man nun EoL-Betriebssysteme oder EoL-Laufzeitumgebungen betrachtet, die Lösung ist stets dieselbe. Die dazugehörige Anwendung muss zuerst auf einer neueren und unterstützten Version laufen, bevor die alte abgeschaltet werden kann. Dazu müssen Teams in der Lage sein, Anwendungen neu deployen und das Deployment testen zu können. Auch hier helfen Testsysteme, -prozeduren und Automation. Auch hierbei ist es unerlässlich, 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ür Releasewechsel lässt sich so signifikant verkürzen. Ressourcen sind damit schneller frei und können für innovative Entwicklungsprojekte genutzt werden.

Leider erlebe ich häufig, dass Abteilungen nur in ihrem eigenen Bereich nach Lösungen 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äßig wiederkehrende Releasewechsel schnell und störungsarm abwickeln zu können.

In meinem beruflichen Alltag erlebe ich häufig, dass In-Place-Upgrades als Allheilmittel angesehen werden. Ich hingegen bin kein großer Freund davon. Sie sind der vermeintlich einfache Weg, doch führen 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äufig kein Zurück mehr. Eine Ausnahme bilden hier virtuelle Umgebungen, bei denen man zuvor einen Snapshot der virtuellen Maschine erstellen kann.

Wer eine Anwendung immer nur mit In-Place-Upgrades von einem Release auf das nächste rettet, verliert mit einer größeren Wahrscheinlichkeit die Fähigkeit, die Anwendung sauber neu zu deployen. Man tut sich hiermit keinen Gefallen.

Ich bin der Überzeugung, dass Organisationen in der Lage sein müssen, ihre geschäftskritischen Anwendungen mit einem definierten Zustand automatisiert ausrollen zu können. Dies unterstützt Releasewechsel, erleichtert den Auf- und Abbau von Testumgebungen sowie die Verifizierung von Fehlern und das Nachstellen von Bugs. Anwendungen können so auch deutlich leichter und schneller gegen neuen Bibliotheken und Laufzeitumgebungen getestet werden. Es lohnt sich, Zeit zum Schärfen der Axt zu investieren, bevor man mit dem Fällen der Bäume beginnt. Oder anders ausgedrückt, wer keine Zeit hat, den Zaun zu reparieren, weil er mit Kühe einfangen beschäftigt ist, wird nie zum Melken kommen.

Open Source Distributionen

In dieser Kategorie auf Seite 15 listet der Bericht die Linux-Distributionen auf, die von den Umfrageteilnehmern verwendet werden. Ubuntu führt diese Liste an und liegt mit 46 % 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 % zugelegt (Platz 1 mit 29% in 2023). Debian kam 2023 mit 16,63% auf Platz 6 hinter CentOS Stream mit 16,74%. Die Plätze 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 Änderung beim Zugriff auf den RHEL Quelltext und das EoL von CentOS mitverantwortlich für diese Veränderungen sind, kann jedoch keine klaren Belege dafür liefern. Laut Bericht sind die Linux Wars noch nicht entschieden und wir können auf den kommenden Bericht gespannt sein.

Es hat mich überrascht, dass RHEL und SLES es gar nicht in das Ranking geschafft haben. Unter Berücksichtigung, dass die Kostenreduktion in diesem Bericht die Hauptmotivation für den Einsatz von Open Source darstellt, lässt sich ggf. erklären, warum Distributionen gerade nicht hoch im Kurs stehen, die kostenpflichtige Support-Subskriptionen für den produktiven Einsatz voraussetzen.

Ich freue mich schon darauf, herauszufinden, wie dieses Ranking im nächsten Bericht aussieht.

Cloud-Native Open Source Technologies

Das Diagramm auf Seite 17 zeigt das Ranking der wichtigsten Cloud-Native Open Source Technologies für die Umfrageteilnehmer. Platz 1 wird von Docker mit 44,6 % eingenommen, gefolgt von Kubernetes mit 33,61 %.

Der große Vorsprung von Docker vor Podman mit 16,6 % hat mich ein wenig überrascht. Ich hätte den Abstand nicht als so groß eingeschätzt. Hier interessiert mich, welche Vorteile die Nutzer in Docker gegenüber Podman sehen. Leider macht der Bericht hierzu keine Aussage. Ich selbst nutze Podman unter Debian, Fedora und RHEL. In Debian stehen ungünstigerweise nur ältere Podman Releases zur Verfügung, denen wichtige Funktionen fehlen. Dies ist in meinen Augen eine Erklärung, warum Podman gerade in diesen Distributionen wenig genutzt wird. Dies ist allerdings nur wilde Spekulation meinerseits. Ich kann dies nicht belegen.

Für mich ebenfalls unerwartet ist OpenStack mit knapp 18 % 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 über die nächsten Jahre zu beobachten und zu sehen, wie sich Podman entwickelt, wofür ich eine gewisse Vorliebe habe.

Automations- und Konfigurations-Management

Wer die Kategorie Ansible in diesem Blog kennt, weiß bereits, dass ich mich gerne mit Ansible beschäftige. So freut es mich zu sehen, dass Ansible im betrachteten Bericht auf Seite 25 Platz 1 mit 30% belegt. Überraschend finde ich hingegen, dass 27% angaben, keinerlei Open Source Automations- bzw. Konfigurationsmanagement zu verwenden. Der Bericht führt dies auf Antworten aus jungen Unternehmen zurück, die (noch) keine Notwendigkeit für Automation sehen. Ich möchte diesen Unternehmen empfehlen, frühzeitig eine Automation First Philosophie zu entwickeln, da ich überzeugt bin, dass sich ein konsequenter Einsatz von Automations- und Konfigurationsmanagementwerkzeugen schnell auszahlt.

Unter den Systemadministratoren liegen Ansible (40 %) und Puppet (36%) als beliebteste Werkzeuge nah beieinander. Es ist immer gut, Auswahl und Wettbewerb zu haben. Ich freue mich über den Anteil von Puppet, gerade weil ich in den Nachrichten nur noch wenig Notiz davon nehme.

Salt liegt bei unter 10 % und ich habe auch schon längere Zeit nichts mehr von diesem Projekt gehört. Schade, die Architektur von Salt finde ich ganz interessant.

Im aktuellen Bericht nutzen knapp 23 % Terraform und der Lizenzwechsel zeigt noch keine große Abwanderung zu dessen Fork OpenTofu. Da die Datenerhebung jedoch Ende 2023 durchgeführt wurde, kann der Bericht eine etwaige Nutzerabwanderung noch nicht darstellen. In 2024 hat IBM die Übernahme von Hashi Corp bekannt gegeben. Ich bin gespannt, wie es mit den Produkten und deren Nutzung weitergeht. Hoffentlich gibt der nächste Bericht erste Einblicke.

Fazit

Durch die Arbeit in einem großen IT-Unternehmen mit einem starken eigenen Portfolio fällt es leicht, eine Betriebsblindheit für die Entwicklungen außerhalb des eigenen Kosmos zu entwickeln. Berichte wie der 2024 State of the Open Source Report helfen, der Betriebsblindheit entgegenzuwirken.

Ich habe nicht alle Kategorien des aktuellen Berichts im Detail betrachtet, sondern mir diejenigen herausgepickt, die mein persönliches Interesse ansprechen. Darüber in diesem Blog zu schreiben, hilft mir, über den Bericht und meine Erfahrungen zu reflektieren. Und wenn euch dieser Kommentar ebenfalls gefällt, freue ich mich umso mehr.

Was ich 2022 für/mit FLOSS getan habe

In diesem Artikel führe ich auf, was ich 2022 für bzw. mit FLOSS getan habe. FLOSS steht dabei für Free/Libre Open Source Software. Es geht dabei nicht um weltbewegende Projekte oder große Beiträge. Es ist mehr eine Sammlung von Kleinigkeiten. Dennoch möchte ich diese öffentlich machen, um zu zeigen, was man mit FLOSS tun und wie man sich beteiligen kann.

Ansible-Rolle zum Deployment von Nextcloud und MariaDB in einem Podman Pod

Dieses kleine Projekt ist etwas verrückt und für den Einsatz in Produktion vermutlich nicht geeignet. Doch konnte ich mich gleich mit zwei Themen intensiv beschäftigen, die mich interessieren, Ansible und Podman. Mein Ziel war es, die Anwendungen Nextcloud und MariaDB zur Bereitstellung einer privaten Cloud in einem rootless Podman Pod zu provisionieren. Die ganze Geschichte kann in der kleinen Serie Nextcloud im Container nachgelesen werden.

Die Quellen der Ansible-Rolle gibt es auf:

RHEL-Patchmanagement

Seit 2016 entwickle und pflege ich ein Patch-Management für Red Hat Enterprise Linux Systeme. Dieses Jahr habe ich Release 3.3.0 und 3.3.1 veröffentlicht.

Mit diesem Projekt habe ich ein Patch-Management gebaut, welches sehr gut die Anforderungen meines Arbeitgebers abdeckt und sich ohne Zusatz-Subskriptionen wie das Smart-Management-Addon für RHEL-Subskriptionen realisieren lässt. Seit 2018 läuft es vollautomatisch und stellt sicher, dass verfügbare Sicherheits-Updates mindestens einmal pro Monat installiert werden.

Es erfreut sich auch außerhalb unserer Organisation einiger Beliebtheit:

Drei Ansible-Rollen dank Open Source

Häufig haben Unternehmen/Organisationen sehr individuelle Anforderungen, für die keine fertigen Lösungen von der Stange existieren. Open Source schafft die Möglichkeit, sich selbst helfen zu können. So habe ich ohne großen Aufwand Ansible-Rollen geschrieben, um Proxy-Einstellungen für den subscription-manager und YUM bzw. DNF zu konfigurieren sowie um Red Hat Enterprise Linux registrieren und den System Purpose konfigurieren zu können.

Quellen:

Meine erste Linux System Role

Die Linux System Roles sind eine Sammlung von Ansible-Rollen zur Konfiguration diverser Betriebssystem-Komponenten von Linux. Ziel der Sammlung ist es, Ansible-Rollen zur einfachen Nutzung durch Systemadministratoren bereitzustellen.

Ich habe viel über den Entwicklungsprozess von Ansible-Rollen gelernt, bis meine erste Rolle pam_pwd aufgenommen wurde. Mit dieser Rolle kann PAM konfiguriert werden, um eine Passwort-Richtlinie zu etablieren.

Sie befindet sich noch in einem sehr frühen Stadium. Nutzt sie auf eigene Gefahr. Der Lerneffekt für mich war jedoch sehr groß, so dass sich die Arbeit in meinen Augen gelohnt hat.

Quelle:

Mit Ansible Labor-Umgebungen in KVM und vSphere provisionieren

Ich benötige immer mal wieder Labor-Umgebungen mit frischen Betriebssystem-Installationen für verschiedene Versuche und Tests. Um die Provisionierung dieser Laborumgebung zu vereinfachen und zu beschleunigen, habe ich zwei Ansible-Rollen erstellt, mit denen sich diese Labor-Umgebungen auf KVM- und vSphere-Hypervisoren provisionieren lassen:

Blogs, Issue-Reports Pull-Requests

Man kann FLOSS auch dadurch unterstützen, indem man darüber spricht bzw. schreibt. Letzteres tue ich in diesem Blog. Der My-IT-Brain Jahresrückblick 2022 gibt einen Überblick darüber.

Hinzu kommen kleine Beiträge in Form von Issue-Reports und Pull-Requests. Details kann man meiner Contribution Activity auf Github entnehmen.

Spenden

Viele FLOSS-Projekte werden ohne funktionierendes Geschäftsmodell von Menschen in deren Freizeit entwickelt und gewartet. Diese Projekte sind auf Spenden angewiesen.

Ich setze mir jedes Jahr ein persönliches Budget, aus dem ich an die Projekte spende, deren Anwendungen ich häufig benutze oder die mir besonders sympathisch sind. Das ist nicht immer ganz einfach. Ich persönlich bevorzuge eine Banküberweisung oder eine Einmalzahlung per Kreditkarte. Mich erst bei einem Zahlungsdienstleister anzumelden stellt für mich meist eine zu hohe Hürde dar.

Fazit

Es muss nicht das eine große Projekt sein. Auch mit der Summe kleiner Teile kann man eine Menge erreichen.

FLOSS hat mir geholfen, viele meiner Anforderungen zu erfüllen. Für mich ist es selbstverständlich, die Ergebnisse dieser Arbeit ebenfalls wieder unter einer freien Lizenz zu veröffentlichen, um auf diesem Weg etwas an die FLOSS-Gemeinschaft zurückzugeben. Doch denkt immer daran: „Nutzung auf eigene Gefahr.“

Freie Software und Open Source…

… was ist das eigentlich? Und wie wirkt sich die Nutzung für den einzelnen Nutzer oder eine Organisation wie ein Unternehmen oder eine Behörde aus? Zu diesen Fragen mache ich mir in diesem Beitrag ein paar Gedanken, die ich gern mit euch diskutieren möchte.

Die Antwort auf die erste Frage fällt mir dabei noch leicht. Freie Software bzw. Open Source Software (FLOSS) sind Anwendungen, die unter einer freien bzw. freizügigen Lizenz stehen. Dabei orientiere ich mich an den Debian-Richtlinien für Freie Software (DFSG), welche u. a. bestimmen:

  1. Die Software darf uneingeschränkt weitergegeben oder verkauft werden.
  2. Der Quelltext der Software muss offen und für jeden frei zugänglich sein. Eine Weitergabe der Software muss sowohl als Quelltext als auch in kompilierter Form erlaubt sein.
  3. Es muss erlaubt sein, die Software zu untersuchen, zu ändern, zu erweitern und unter den gleichen Lizenzbedingungen wie die Original-Software weiterzugeben.
  4. Die Lizenz darf keine Person oder Gruppe von Personen diskriminieren.
  5. Die Lizenz darf keine Einschränkungen hinsichtlich des Einsatzbereichs vornehmen. Beispielsweise darf sie nicht verhindern, dass das Programm geschäftlich oder für genetische Forschungen verwendet wird.

Was habe ich als (privater) Nutzer davon?

Auch wenn es schön ist, den Quelltext bei Interesse studieren zu können, glaube ich persönlich nicht, dass viele Nutzer von dieser Möglichkeit Gebrauch machen. Und wenn doch, haben sie den Text vermutlich schnell wieder von ihrem Bildschirm verbannt.

Nun sind viele FLOSS-Anwendungen kostenlos erhältlich und nutzbar. Und obwohl ich die Geiz-ist-geil-Mentalität nicht mag, ist dies für den Anwender tatsächlich ein großer Vorteil.

Zu meinen Schul- und Ausbildungszeiten kostete professionelle und oftmals proprietäre Bürosoftware verdammt viel Geld. Teilweise waren dies mehrere hundert DM bzw. EUR. Und dafür durfte man die entsprechenden Anwendungen nur auf einem einzigen PC installieren. Nun hatte ich damals weder die Bereitschaft noch die Mittel, so viel Geld für ein Office-Paket aufzubringen, von dessen Funktionsumfang ich nur einen Bruchteil benötigte und nutzen würde.

Daher war ich hoch erfreut, dass es OpenOffice gab. Entstanden aus den offengelegten Quelltexten von StarOffice bot sich mir hiermit die Möglichkeit, meine Briefe, Aufsätze, Tabellen und Präsentationen zu gestalten, ohne mich dafür in Unkosten zu stürzen. Zugegeben sahen die Präsentationsvorlagen damals schon wie Tapeten aus den siebziger Jahren aus. Aber die proprietären Alternativen waren damals nicht viel besser.

Viele unter euch kennen sicherlich die Überraschungen, die man erleben kann, wenn man Text- und Tabellen-Dokumente zwischen freien und proprietären Office-Suiten austauscht. Aber glaubt mir, diese Problemchen sind nicht mit denen vergleichbar, als ich meinem Lehrer den Aufsatz, verfasst auf einem C64, auf einer 5,25-Zoll-Diskette überreicht habe. Zum Glück hatte ich noch die auf Endlospapier gedruckte Fassung dabei, erstellt auf einem 9-Düsen-Tintenstrahl-Drucker, welche mir die Note rettete.

Ein ärgerliches Problem jedoch bleibt. Es nützt dem Bürger nichts, wenn seine mit freier Software erstellten Dokumente von Behörden nicht angenommen bzw. verarbeitet werden können. Genauso doof ist die Situation anders herum. Wenn man von Behörden Dateien übermittelt bekommt, welche sich nur mit der proprietären Software anzeigen lassen, mit der sie erstellt wurden. Hier ist in den letzten zwanzig Jahren schon vieles besser und einfacher geworden. Und als Optimist glaube ich daran, so lange zu leben, dass ich noch erleben werde, dass es noch besser wird.

Habt ihr ähnliche Erfahrungen gemacht? Wie seht ihr die Situation heute?

Mit den Jahren hat sich die Situation bei der Bürosoftware geändert. So gab es zwischenzeitlich für private Nutzung und für Schüler/Studenten eine proprietäre Office-Suite für 99 EUR, welche gleichzeitig auf bis zu drei Geräten installiert und genutzt werden durfte. Hier stimmt für meinen Geschmack das Preis-Leistungsverhältnis. Nur war diese Software nicht für mein Betriebssystem erhältlich und kam somit nicht in Frage. Ich glaube jedoch bis heute, dass es entsprechende Angebote nicht gegeben hätte, ohne dass freie Alternativen verfügbar gewesen wären und es heute noch sind.

Ein weiteres Beispiel für FLOSS ist die in diesem Beitrag schon für einige Links verwendete Wikipedia. Früher hatte man vielleicht ein Lexikon oder den Brockhaus daheim. Wobei letzterer sogar eine echte Geldanlage war. Das Wissen in den Büchern verstaubte, wie die Bücher selbst auch. Heute haben dank Wikipedia sehr viele Menschen dieser Welt freien Zugang zu nahezu unbegrenztem Wissen. Ich finde dies großartig.

Ich schrieb eingangs, dass ich kein Freund der Geiz-ist-geil-Mentalität bin. Dies liegt in der Annahme begründet, dass gute Software nicht nur in der Freizeit von Entwicklern zwischen 22:00-23:50 Uhr entsteht. Wenn viele Entwickler gute Anwendungen programmieren, sollten sie dafür auch bezahlt werden. Doch scheint es wider der Natur des Menschen zu sein, für eine Leistung zu bezahlen, die er auch kostenlos erhalten kann. Dies missfällt mir und ich habe beschlossen, da nicht mitzumachen.

Ich selbst bin mittleren Alters, habe Familie, stehe mitten im Berufsleben und beziehe ein Einkommen, welches meiner Familie und mir ein gutes Auskommen ermöglicht. Und ich habe beschlossen, einen kleinen unbedeutenden Teil meines Einkommens für FLOSS-Projekte zu spenden.

Dabei überlege ich mir einmal im Jahr, welchen Betrag ich insgesamt spenden möchte und welche Anwendungen oder Projekte ich besonders häufig genutzt habe; bzw. welche Anwendungen/Projekte mir besonders wichtig waren. Anschließend entscheide ich, wie ich den von mir festgelegten Betrag aufteile und überweise die einzelnen Summen. Mir ist bewusst, dass der gespendete Betrag nichtmal einem Monatsgehalt eines professionellen Software-Entwicklers entspricht. Doch ich denke, Kleinvieh macht auch Mist und habe ein gutes Gefühl dabei.

Heute nutze ich fast ausschließlich freie Software. E-Mail-Client, Textverarbeitung, Editoren und Betriebssystem; alles FLOSS. Dabei bin ich der Nutzung proprietärer Software gar nicht abgeneigt. So würde ich auch heute noch zu proprietären Anwendungen für die Steuererklärung oder das Online-Banking greifen, bevor ich mich mit den freien Alternativen abquäle.

Zwar existieren einige liebgewonnene Anwendungen heute nicht mehr, weil die Hersteller sie abgekündigt oder zur Unbenutzbarkeit weiterentwickelt haben. Doch habe ich das gleiche auch schon mit FLOSS-Anwendungen durchgemacht.

Wie ist das bei euch? Verwendet ihr freie bzw. quell-offene Software in eurem Alltag? Wenn ja, in welchem Umfang? Und wie zufrieden seid ihr damit? In welchen Bereichen fehlt es eurer Meinung nach an freien Alternativen? Nutzt gern die Kommentarfunktion oder schreibt mir per E-Mail, wenn ihr mögt.

Was tun, wenn’s klemmt?

FLOSS und proprietäre Software haben gemein, dass sie fehlerbehaftet sind. Ohne eine Gewährleistungspflicht auf Software wird sich dieser Umstand auch nie ändern. Doch was kann man als Privatanwender tun, wenn eine Anwendung mal nicht so will, wie sie soll? Oder man einfach nicht weiß, wie man sein gewünschtes Ziel erreicht?

In meinen Augen gehört zu jeder Anwendung auch ein Handbuch, eine Anleitung und eine Befehlsreferenz als Dokumentation. Je nach Hersteller, Projekt bzw. Anwendung schwankt die Qualität von Dokumentation von „nicht vorhanden“ über „beschissen ist geprahlt“ bis „erfreulich gut“. Hier lohnt sich ein erster Blick. Kommt man mit der vorhandenen Dokumentation nicht weiter, findet man häufig Hilfe in den unzähligen Internetforen, wo freiwillige, engagierte Nutzer anderen Nutzern bei Sorgen, Nöten und Problemen weiterhelfen.

Um nicht ständig die gleichen Fragen aufs neue zu beantworten, wird lediglich verlangt, das verdammte Handbuch (RTFM) gelesen und die Suchfunktion verwendet zu haben, bevor man ein neues Thema eröffnet. Wer sich an diese einfachen, grundlegenden Regeln hält und darüber hinaus stets freundlich bleibt, dem wird mit großer Wahrscheinlichkeit geholfen.

Wer hingegen rüpelhaft, in rauhem Ton sofortige Unterstützung und Lösungen für ein Problem mit einer Anwendung einfordert, für die man nichtmal einen Cent zu spenden/zahlen bereit war, darf sich nicht wundern, am langen Arm zu verhungern. Und das ist in meinen Augen vollkommen in Ordnung.

Neben der Dokumentation und den Internetforen gibt es natürlich noch die technisch begabten Verwandten. Diese reisen meist an Wochenenden und hohen Feiertagen an, um die IT-Probleme ihrer Familie und Nachbarn zu fixen. Doch bitte nutzt die Hilfe dieser edlen Ritter ohne Rüstung nicht schamlos aus. Sie kommen euch unter Umständen viel häufiger besuchen, wenn sie für den Kaffee nicht drei Laptops und zwei Handys neuinstallieren müssen.

Damit sind die Möglichkeiten eigentlich auch ausgeschöpft. Kommerzielle und finanziell interessante Support-Angebote für Privatanwender existieren meines Wissens nach so gut wie nicht.

FLOSS lebt vom Mitmachen, nicht vom Meckern

Freie Software wird meist unentgeltlich zur Nutzung angeboten. Diese wird nicht selten von Freiwilligen in deren Freizeit geschaffen. Auch Unternehmen, welche der Gemeinschaft etwas zurückgeben möchten, beschäftigen Entwickler, die einen Teil ihrer Arbeitszeit an Open Source Software arbeiten können.

Fehler werden höchstwahrscheinlich nicht mit Absicht eingebaut. Und nicht jeder erdenkliche Anwendungsfall wird von Beginn an in der Entwicklung berücksichtigt. Darüber zu meckern und Forderungen für etwas zu stellen, was man kostenlos nutzen darf, hat bisher in den seltensten Fällen geholfen.

Hat man Wünsche den Funktionsumfang einer Anwendung betreffend, kann man diese an das jeweilige Projekt richten. Liest man zuvor die sog. Contribution guidelines (zu Deutsch in etwa: Beitragsleitlinie), erhöht dies die Chancen, dass ein Beitrag Berücksichtigung findet.

Unterstützung und Hilfe ist an allen Ecken und Enden des FLOSS-Universums von Nöten und oft herzlich willkommen. Dabei muss man kein Software-Entwickler sein. Denn oft mangelt es an Dingen, die mit dem Code nicht viel zu tun haben. So kann man zum Beispiel:

  • Dokumentationen schreiben, erweitern und verbessern
  • Dokumentationen in andere Sprachen übersetzen
  • Nutzern in Internetforen und auf Maillinglisten bei der Lösung ihrer Probleme helfen
  • Fehlerbilder verifizieren und Patches testen

FLOSS ist Software von der Gemeinschaft für die Gemeinschaft. Bring dich ein, mach mit!

Ein (paar) Wort(e) an Entwickler und Paket-Betreuer

Ihr habt zum Teil großartige Anwendungen geschaffen und stellt sie der Gemeinschaft zur Verfügung. Ihr seid auf Hilfe angewiesen und braucht/sucht Nachwuchs, der bereit ist, zu lernen, wie man Software erstellt, pflegt, pakettiert und verteilt? Dann denkt bitte daran, dass jeder mal klein anfängt und man dem Nachwuchs aufs Pferd helfen muss, bevor dieser losreiten kann.

Zum Teil habt ihr rund um eure Software Ökosysteme aus Versionskontrollsystemen, Build-Umgebungen, CI/CD und Kommunikationskanäle geschaffen, die für Anfänger und technisch interessierte Laien nur schwer zu durchdringen sind. Wer sich bei der Beantwortung der Frage, wie man ein Distributions-Paket betreuen kann, tagelang durch verschiedenste Wiki-Seiten und gefühlt das halbe Internet gewühlt hat, gibt danach oft frustriert auf.

Ich habe kein Patentrezept, wie man es optimal gestalten kann. Doch klafft IMHO zwischen Tutorials wie „Wie baut man ein {DEB,RPM}-Paket“ und „So baut und betreut man Pakete für Distribution XY“ eine große Lücke, durch welche potenzieller Nachwuchs durchfällt.

Hier ist eventuell eine Diskussion innerhalb der einzelnen Communities notwendig, wie der Prozess der Nachwuchsgewinnung verbessert werden kann.

Oder habe ich hier ein falsches Bild von der FLOSS-Welt und es gibt kein Nachwuchsproblem, weil man sich vor neuen Paketbetreuern kaum retten kann?

Was haben Unternehmen und Behörden von FLOSS?

TL;DR: Mehr Souveränität. Keine starke Abhängigkeit von einem einzelnen Anbieter. Und Freiheit.

Ich habe in vorstehendem Absatz ganz bewusst auf Begriffe wie „kostenlos“, „unentgeltlich“ und „Kostenreduzierung“ verzichtet. In meinen Augen greift die Reduzierung von FLOSS auf vermeintliche Kostenvorteile zu kurz und ist nicht selten mit ein Grund für das Scheitern von Migrationsprojekten hin zu FLOSS. Statt dessen möchte ich in diesem Beitrag Aspekte hervorheben, die IMHO häufig zu kurz kommen.

Dazu beginne ich mit einem Beispiel aus der Closed Source Welt. Es wird ein Produkt wie zum Beispiel ein Betriebssystem oder eine Anwendung eines proprietären Herstellers erworben und in die eigenen Geschäftsprozesse integriert. Nicht selten zahlt man einmal für die Lizenz, um das Produkt überhaupt nutzen zu dürfen und darüber hinaus für ein Abonnement, über welches man Updates, Sicherheits-Patches und Unterstützung durch den Hersteller-Support bekommt. Der Hersteller kann beliebig darüber entscheiden, wie lange er ein Produkt unterstützt und wann er es abkündigt, so dass der Kunde ggf. ein Nachfolgeprodukt erneut kaufen muss. Wenn es ganz dumm läuft, stellt der Anbieter ein Produkt komplett ein, ohne dass es ein Nachfolgeprodukt gibt. Als Kunde guckt man dann halt in die Röhre und kann sich erneut auf die Suche nach einem Produkt machen, das man ggf. unter Anpassung der eigenen Prozesse integriert. Damit einher geht häufig die Anpassung weiterer Systeme und Prozesse, sowie der Austausch von Client-Anwendungen und Anwenderschulungen.

Die schlechte Nachricht ist, dies alles kann beim Einsatz von FLOSS ebenfalls passieren. Doch gibt es bei FLOSS noch eine weitere Option, die sich als vorteilhaft erweisen kann. Auch dazu möchte ich euch ein Beispiel geben.

Angenommen es wird eine Software genutzt, die ein engagierter FLOSS-Entwickler als Hobby-Projekt in seiner Freizeit erstellt hat. Die Software besitzt ausschließlich Abhängigkeiten zu anderen FLOSS-Technologien und deckt alle Anforderung des Unternehmens bzw. der Behörde ab. Die Nutzung ist unbeschränkt und kostenlos möglich. Mittlerweile ist die Anwendung tief in die eigenen Prozesse integriert und elementarer Bestandteil der Wertschöpfungskette. Alle sind glücklich und alle sind froh.

Doch dann endet eines Jahres die Unterstützung für eine FLOSS-Technologie von der diese Anwendung abhängt. Es gibt ein Major-Release-Upgrade für diese Technologie. Die FLOSS-Anwendung muss jedoch angepasst werden, um weiterhin lauffähig zu sein.

Nun kann man den bzw. die Entwickler der Anwendung ganz lieb fragen, ob sie die notwendigen Anpassungen vornehmen mögen. Vielleicht hat man Glück und dies geschieht innerhalb weniger Tage. Vielleicht hat man auch Pech und sie haben einfach keine Lust.

Wenn es an der Motivation fehlt, kann man auf die verrückte Idee kommen und den Entwicklern anbieten, sie für die notwendigen Anpassungen zu bezahlen und einen Preis mit ihnen aushandeln. Für mich liegt dieser Gedanke nahe, würde man einen proprietären Hersteller doch auch bezahlen. Und das häufig sogar für Änderungen, die man gar nicht wollte/brauchte.

Nun kann es durchaus immer noch passieren, dass der/die Entwickler das Angebot ablehnen. Sie haben einfach keine Lust, sich weiterhin um ihre alte Anwendung zu kümmern. Was bleibt nun übrig, außer eine Markterkundung durchzuführen, eine Alternative zu eruieren und Himmel und Hölle in Bewegung zu setzen, um diese zu implementieren?

Halt! Stopp! Es gibt noch eine weitere Alternative. Die Anwendung ist quell-offen und der Quelltext liegt euch vor. Die Anwendung kann jederzeit aus diesem neu erstellt werden und ihr habt das Recht, beliebige Anpassungen am Quelltext vorzunehmen. Wenn euch die Anwendung wichtig genug ist, hindert euch nichts und niemand daran, eigene Entwickler einzustellen, welche den Quelltext studieren und notwendige Anpassungen vornehmen. Und da ihr diese Entwickler selbst bezahlt, könnt ihr sie auch mit Priorität an euren Wunsch-Funktionen arbeiten lassen.

Jetzt wurde auch schon deutlich, warum ich das Argument, FLOSS sei kostenlos bzw. günstig, doof finde. Es trifft nicht zu. Spätestens wenn ich eigene Entwickler beschäftige und hoffentlich auch bezahle, kostet dies ebenfalls Geld; nur investiert man das Geld hierbei in eigene Ressourcen. Ähnlich ist es, wenn man sich Funktionen im Auftrag entwickeln lässt. Nur behält man hierbei die Souveränität über die Software, im Gegensatz zum Produkt eines proprietären Anbieters.

Selbstverständlich mag dies nicht in jedem Fall möglich sein. Doch in vielen Fällen ist dies ein gangbarer Weg und einer der großen Vorteile des FLOSS-Entwicklungsmodells. Ein weiterer Vorteil besteht darin, dass man nicht die gesamte Entwicklungsarbeit allein bewältigen muss. Die Last kann auf viele Schultern weltweit verteilt werden. So arbeiten Entwickler aus verschiedensten Branchen mit am Linux-Kernel. Gleiches gilt für den BSD-Kern und unzählige andere Projekte.

Wer hilft wenn’s klemmt?

Grundsätzlich stehen die gleichen Optionen zur Verfügung, die auch Privatnutzern offen stehen. Darüber hinaus bietet sich häufig die Möglichkeit, Support-Verträge mit Herstellern oder Systemhäusern abzuschließen.

So bieten z.B. Red Hat, SUSE, Canonical und Oracle verschiedene Support-Optionen für das jeweilige Portfolio an. Darüber hinaus haben sich auch im deutschsprachigen Raum einige Firmen etabliert, welche Support-Dienstleistungen für vielfältige FLOSS-Projekte/Produkte anbieten.

Diese Firmen verdienen nicht nur Geld mit Dienstleistungen rund um FLOSS. Sie beteiligen sich häufig mit eigenem Personal und/oder finanziell an der Weiterentwicklung diverser Projekte.

Die Qualität des Supports ist meiner Erfahrung nach mit dem proprietärer Anbieter vergleichbar. Das gilt sowohl im positiven wie negativen Sinne.

Nutzt einfach die Suchmaschine eures geringsten Misstrauens und ihr werdet bestimmt einen passenden Dienstleister finden.

Auch hier gilt, nicht meckern, mitmachen!

Ich möchte mich wiederholen: „FLOSS ist Software von der Gemeinschaft für die Gemeinschaft. Bring dich ein, mach mit!“

Dies sollte in meinen Augen besonders für Behörden und Organisationen gelten, die den Betrieb und die Entwicklung ihrer Anwendungen mit dem Steuergeld von Bürgerinnen und Bürgern finanzieren. Deshalb unterstütze ich die Kampagne „Public Money, Public Code“. Innovationen und Investitionen in Freie Software verschwinden nicht hinter verschlossenen Türen zum Nutzen Weniger; statt dessen können alle Nutzer davon profitieren. So z.B. auch Bürgerinnen und Bürger, die daheim evtl. die gleichen FLOSS-Anwendungen nutzen, die auch der Staat nutzt und mit weiterentwickelt.

Bisher ist vieles davon noch bloße Utopie. Scheitert es doch im öffentlichen Dienst schon oft genug daran, an Open Source Projekte zu spenden. Geld für Berater-Verträge auszugeben ist da schon einfacher möglich. Doch auch auf diesem Weg kann man ja FLOSS-Projekte unterstützen. Ich glaube da wo ein Wille ist, ist auch ein Weg.

Schlussworte

Freie Software und Open Source Software sind frei im Sinne von:

  • Der Quelltext liegt offen vor und kann von jedem Menschen eingesehen, studiert und weitergegeben werden.
  • Jeder Mensch hat das Recht den Quelltext zu verändern.
  • Die Verwendung der Software ist in keiner Weise beschränkt.

Wer einfach nur seine Arbeit erledigen möchte, mag dabei mit FLOSS-Software genau so viel Glück oder Pech wie mit proprietärer Software haben. FLOSS bietet hingegen Souveränität und Freiheit; mit allen Vor- und Nachteilen, die das mit sich bringen mag. Technisch interessierte Menschen können sich mit ihr vertraut machen, dazulernen und Teil einer Gemeinschaft werden.

Ich mag FLOSS und glaube Open Source Entwicklungsmodelle sind auch in Zukunft nicht mehr aus unserer Welt wegzudenken.

F-Droid – Freie und Open Source Software Repository für Android

F-Droid stellt ein Repository bereit, über welches Freie und Open Source Software (FOSS) für das Betriebssystem Android bezogen werden kann.

Damit stellt das F-Droid-Repository eine Alternative bzw. Ergänzung zum Google Play-Store dar. Um die Gründe zu erläutern, die für eine Nutzung von F-Droid sprechen, möchte ich Finn Christiansen zitieren:

1. Man hat kein Google Konto, kann also den Play Store nicht nutzen, möchte aber trotzdem komfortabel Apps installieren und verwalten. (Wie in meinem Fall)
2. Man hat ein Google Konto, nutzt den Play Store, möchte aber einige Apps lieber aus dem F-Droid Repository installieren (Misstrauen gegenüber dem Play Store / keine Kosten in F-Droid)

Finn hat in seinem Artikel „Das F-Droid-Repository für Android installieren“ sehr schön beschrieben, wie man das F-Droid-Repository unter seinem Android-Gerät einrichten und nutzen kann. Leider führt der Link zu Finns Anleitung heute ins Leere. Doch lässt sich F-Droid heute auch ganz einfach, ohne gesonderte Anleitung, einrichten.

Ich möchte noch eine Empfehlung zum Schutz eures Android-Gerätes beifügen. Man muss die Installation aus Quellen unbekannter Herkunft erlauben, um F-Droid bzw. Apps aus dem F-Droid-Repository installieren zu können. Dies stellt ein Sicherheitsrisiko für euer Gerät dar. Mit dieser Einstellung kann es passieren, dass Apps oder Webseiten ohne euer Wissen Schadprogramme auf eurem Gerät installieren. Doch durch die Deaktivierung dieser Funktion nach Installation von F-Droid und der gewünschten Apps lässt sich dieses Risiko zum Glück sehr einfach minimieren.

Während der normalen Nutzung bleibt damit die Installation aus Quellen unbekannter Herkunft untersagt. Diese Option aktiviere ich nur direkt vor der Installation einer neuen App aus dem F-Droid-Repository und deaktiviere sie anschließend wieder. Die bereits installierten Apps lassen sich anschließend problemlos weiterverwenden.

Als ich diesen Artikel 2015 geschrieben habe, konnte man die Installation aus unbekannten Quellen nur global für das gesamte Gerät aktivieren. Heute ist es auf den meisten Android-Geräten möglich, diese Berechtigung für einzelne Apps zu aktivieren. Wem das oben beschriebene Prozedere zu mühsam ist, kann so z.B. ausschließlich der App „F-Droid“ die Installation aus unbekannten Quellen erlauben. Damit ist sichergestellt, dass andere Apps nicht einfach etwas nachinstallieren dürfen.

Neugierig geworden? Probiert es aus. Es tut nicht weh. Mich hat F-Droid in den vergangenen Tagen überzeugt.

Vorstellung freiesMagazin

In diesem Artikel möchte ich auf das kostenlose und online erscheinende Magazin „freiesMagazin“ hinweisen. Was ist freiesMagazin?

freiesMagazin berichtet monatlich über Wissenswertes und Neues aus den Welten Freier Software, Open Source und Linux. Was 2005 als loser Newsletter begann, reifte mit der Zeit durch Akzeptanz und Teilnahme der Linux-Community zum regelmäßig erscheinenden Magazin. Getreu dem Motto „der Community etwas an Wissen, Spaß und Freude zurückzugeben“ laden wir auch weiterhin Autoren zum Wissensaustausch ein.

Neben interessanten Hintergrundartikeln und Neuvorstellungen gefallen mir auch die Artikelreihen, welche als Tutorial in Skript- und Programmiersprachen wie PHP, Perl, Java oder die Objektorientierte Programmierung allgemein einführen.

Die Ausgaben sind als PDF-, HTML- und EPUB-Version verfügbar. Bei dieser Aufwahl lässt sich das Magazin auf so gut wie jedem elektronischen Device gut lesen. Sei es der PC, das Notebook, Tablet oder eReader. Für mobile Geräte werden auch Versionen ohne Bilder bereitgestellt, um Speicherplatz zu sparen.

Somit ist es für mich ein leichtes alle Ausgaben der Jahre 2008 – 2011 auf meinem Kindle dabei zu haben. Damit man leichter die Übersicht behält gibt es für jedes Jahr einen Index, welcher alle erschienen Artikel aufführt und dem man entnehmen kann in welcher Ausgabe ein Artikel erschienen ist.

Die Jahressammlungen werden auch zum Download als *.tar.gz Archiv angeboten. Auf der Seite www.freiesmagazin.de/mobil gibt es die HTML-Versionen mit und ohne Bilder. Mit dem Programm wget und dem folgenden kurzen Bash-Skript könnt ihr euch alle Ausgaben automatisch auf euren Rechner laden.

#!/bin/bash
# Downloader für freiesMagazin HTML-Ausgaben
for i in {2008..2011}
do
for j in {01..12}
do
wget http://www.freiesmagazin.de/mobil/freiesMagazin-${i}-${j}.html
done
done

echo „Download abgeschlossen.“

Und nun wünsche ich euch viel Spaß beim Lesen. ;-)