Irrtümer bei Open Source: Aufklärung und Realität

Ziel des Beitrages

Die Definition des Begriffs und auch die typischen Irrtümer bei Open Source sollen in diesem Beitrag betrachtet werden.
Hinzu kommen noch die Attribute / Eigenschaften von Open Source im Vergleich zu „Closed Source“

Irrtümer bei Open Source

Beim Thema Open Source werden gerne Verhalte angenommen die nicht unbedingt korrekt sind.
Ich beschränke mich auf die 3 häufigsten Irrtümer.

Beispielweise gibt es etliche verschiedene Lizenzen die unter Open Source laufen können.
Dabei kann man, um es übersichtlich zu halten, zwischen 2 Lizenzarten unterschieden.
Die Copyleft und Permissive Lizenz.
Vereinfacht gesagt unterscheiden sich die beiden Arten darin, welche Restriktionen (Einschränkungen) die Lizenz mitgibt.

Copyleft-Lizenz

So kann unter einer Copyleft Lizenz vorgegeben werden, dass Derivate/Forks (eigen Entwicklungen die auf dem Code basieren) unter der gleichen Lizenz veröffentlicht werden müssen.

Permissive-Lizenz

Unter der Permissive-Lizenz existieren deutlich weniger/freizügigere Regeln.
Unterm Strich, darf man bei solchen Lizenzen den „Source Code“ nehmen, beliebig verändern und unter jeder Lizenz verbreiten die man selber möchte, sofern es ein eigenes Werk ist.

Übersicht Lizenzen

Copyleft-Lizenz	Permissive-Lizenz
GNU General Public License (GPL)	Apache License
Affero GPL (AGPL	MIT License
Lesser General Public License (LGPL)	Berkeley Source Distribution (BSD) License
Eclipse Public License (EPL)	Unlicense
Mozilla Public License (MPL)

Das ist schlicht und ergreifend falsch.
Nur weil ein Projekt Open Source ist, bedeutet das nicht automatisch, dass es kostenlos ist.

Entwickler sind Menschen

Doch die Entwickler können sich ohne Geld, nicht dem Projekt und somit ebenso nicht der Pflege widmen, da diese kein Geld einnehmen.
Jedoch sind die Anforderungen von Usern oder auch „Security-Experten“ sehr hoch und man wird auch schnell kritisiert, wenn kein Patch/Update kommt.
Bedeutet, Entwickler die in ihrer Freizeit eine Software schreiben und diese allen zur Verfügung stellen, werden schnell entmutig.
Diese Entwickler rufen auch gerne zu Spenden auf, welche zwar kommen, jedoch nicht in der Menge wie es benötigt werden würde.

Wenn Infrastruktur (Cloud) oder Support geboten werden

Grade, wenn Open Source Projekte eine Infrastruktur (Cloud) oder Support anbieten, ist es wichtig, dass hier die Kosten eingeholt werden.
Beim Thema Cloud werden Hoster wie: Hostinger, Hetzner, Netcup, Amazon Web Services (AWS) uvm. genutzt.
Diese wollen bezahlt werden und können je nach Größe teuer werden.
Auch Mitarbeiter oder die eigene Arbeitszeit ist kostbar, besonders, wenn man das ganze in Vollzeit betreibt.

Beispiel Projekte

Anbei mal eine kleine Auflistung von Open Source Projekten, die kostenpflichtig sind oder kostenpflichtige Abo’s anbieten mit zusätzlichen Funktionen.

Plattform	Kostenlos nutzbar	kostenpflichtig oder Abo
Bitwarden	Yes	Yes
Proxmox	Yes	Yes
Mattermost	Yes	Yes
Joplin	Nur wenn selbst gehostet	Yes

Ja, es gibt hier beide Stimmen.
Dabei muss betrachtet werden, welche Art von Software gemeint ist und unter welcher Programmiersprache(n) diese geschrieben wurde.

An sich sind Sicherheitslücken und Schwachstellen (vulnerabilities) nichts weiter als Funktionen im Programm die „normal“ funktionieren, jedoch nicht so vom Entwickler oder für das Produkt erdacht waren.
Zumindest ist das technisch mal die Ansicht.

Daher kann jedes Projekt, sei es Open Source oder Closed Source mal sicherer oder „unsicherer“ sein als der jeweilige Gegenpart.
Das „einfachste“ Beispiel ist die log4j Schwachstelle, aus der gleichnamigen Bliblitohek.
Diese Bibliothek wurde in vielen Java basierenden Anwendungen verwendet, um ein Logging zu ermöglichen. Jedoch ist im Dezember 2021 eine kritische Schwachstelle in dieserr Bibliothek entdeckt worden, welche log4shell genannt worden ist.
Hiermit konnten nicht autorisierte Personen vollen Admin/Root Zugang erlangen.
Dies war für alle verheerend denn z.B. Dell oder auch VMware waren hiervon betroffen.

Was ist eine Bibliothek?
In der Programmierung spricht man von eine Bibliothek, wenn man externe Ressourcen verwendet, die einem Funktionen bereitstellen, die „im Standard“ nicht vorhanden sind, oder diese vereinfachen.
Quasi eine Art: Du musst das Rad nicht neu erfinden, hier ist die Schablone.
Das ist jetzt stark vereinfacht, sollte den Zweck jedoch erklären.

So funktioniert das Open Source Prinzip

Das Open Source Prinzip ist neben den Irrtümern doch sehr vielseitig.
Es gibt mehrere Gründe, weshalb Entwickler ihre Projekte Open Source machen.
Das Wichtigste ist jedoch: Der Code auf dem das Programm oder der Dienst basiert, ist „offen“, soll heißen dieser ist öffentlich einsehbar und kann von jedem betrachtet werden.

Es sei erwähnt, dass ich mich hier auch auf 3 Gründe beschränke, es gibt natürlich noch mehr.

Dadurch, dass jeder den Code einsehen kann, kann an sich auch jeder feststellen, ob dieser Open Source Code Schädliches tut oder nicht.
Gleichzeitig kann man die Funktionalitäten der Anwendung besser nachvollziehen!
Das schafft Akzeptanz und somit Vertrauen in den Dienst & Entwickler.

Wie heißt es so schön: „Gemeinsam sind wir stark!“
Genau das kann man sich mit Open Source zu nutzen machen.
Denn wenn der Code offen zur Verfügung steht, können auch andere Entwickler etwas zum Code beitragen.

Das kann einiges sein z.B. Fehlerbehebung oder „Patchen“ einer Sicherheitslücke.
Auch neue Funktionen sind möglich.
Worauf man also hier gerne baut, ist das „Schwarmwissen“, bedeutet, man ist als einzelner Entwickler oder auch als Team nicht mehr auf das eigene Wissen begrenzt.
Somit entsteht ein Geben und Nehmen in der Gemeinschaft, was sehr gut funktionieren kann.

---

Grund #3: Persönliche Gründe

Es kann auch sein, dass ein Entwickler oder Team eine Anwendung schön findet, jedoch diese Open Source zur Verfügung stellen möchte.
Das kann aus Gründen sein wie z.B. das man kein Tracking/Telemetrie haben möchte.
Aus Neugier wie so eine Anwendung grundsätzlich aufgebaut ist und funktioniert.

---

Meine Meinung zu Open Source

Meine Meinung zu Open Source ist gemischt.
Das liegt daran, dass bei diesem Thema schnell in Extremen gesprochen wird, die keiner vernünftigen Grundlage entsprechen.
Diese Extreme sorgen dafür, das auch die Lager sehr angespannt sind, dabei können beide voneinander profitieren, da Open Source Entwickler/Teams nicht immer die gleichen Mittel haben wie die Closed Source Gegenstücke.
Gleichzeitig können Closed Source Entwickler/Teams von der Art wie entwickelt wird und der Vielfalt an wissen in den Open Source Communties profitieren.

Wenn man die Extreme mal für sich betrachtet und somit das Thema Open Source davon abkapselt, finde ich Open Source eine effiziente Art, um nicht nur Vertrauen zu schaffen, sondern auch vom Wissen anderer zu profitieren.

Auch kann durch Open Source, die Anwendung so weiterentwickelt werden, dass diese von einem einfachen Use Case zu einem „Alleskönner“ wird.
Gutes Beispiel ist VSCodium, welches auf den Binaries (also bereits kompilierten Programm Code) von Visual Studio Code basiert.
Der Grund ist hierfür, dass Microsoft zwar die Binaries Open Source gestellt hat, jedoch ist die fertige Anwendung also Visual Studio Code (kurz VS Code) nicht Open Source.
Das liegt daran das VS Code Integrationen in die Microsoft Dienste inkl. Telemetrie und Tracking hat.

Anderes Beispiel für ein „Alleskönner“ Programm ist OBS Studio (Open Broadcaster Software Studio), welches durch Plugins der Community stark erweitert werden kann und somit mit professioneller Streaming und Recording Software nicht nur mithalten kann, sondern diese auch übertreffen kann.

Wie ist deine Meinung hierzu?
Kanntest du das Thema bereits?
Ich freue mich auf deine Rückmeldung!