Wie immer bei diesen Themen gibt es nicht die eine Wahrheit, da das Verständnis dieser Begriffe auch Auslegungssache ist. Es empfiehlt sich also auf jeden Fall, alle Seiten zu betrachten und eine eigene Meinung zu bilden. (Sagt man so etwas zu Zeiten von Fake News überhaupt noch, oder jetzt erst recht?)

Closed Source, die eine Seite der Medaille

Software ist Arbeit:

  • Planung,
  • Architektur,
  • Prototyp,
  • Entwicklung,
  • Tests,
  • Dokumentation,
  • Rollout,
  • Updates und so weiter.

Schon kleine Projekte erreichen schnell zigtausend Zeilen Code, bei aktuellen Betriebssystemen reden wir je nach Zählweise von mehreren 100 Millionen Zeilen Quellcode. Nur zu verständlich, dass Unternehmen die Arbeit und Betriebsgeheimnisse, die darin enthalten sind, schützen wollen. Der lesbare Quellcode bleibt also im Unternehmen, Kunden erhalten lediglich das ausführbare Programm in unlesbarer Binärform. Daran geknüpft ist in den meisten Fällen eine Lizenzvereinbarung, die Nutzung und Weitergabe einschränkt.

Frei und Quelloffen, die andere Seite

In den 1980ern entwickelte sich unter Führung von Richard Stallman die Free Software Foundation, FSF, wobei Free hier ausdrücklich für Frei und nicht für Kostenlos steht. Die FSF setzt sich für Freiheit und Rechte der Nutzer ein. Beide Ziele sind nur mit freier, quelloffener Software erreichbar.

Frei im Sinne von kostenlos ist dabei oft ein angenehmer Nebeneffekt, wobei die Lizenzen, wie die GPL, die von der FSF entwickelt wurde, die Monetarisierung von Software nicht verbieten. In den letzten Jahren bauen immer mehr Firmen ihr Geschäftsmodell ausschließlich auf freier Software auf. Und die Zahl der Firmen, die weder direkt noch indirekt Open-Source-Software einsetzen, um ihre eigenen Softwarelösungen zu erstellen, geht gegen Null.

Risiken und Chancen von Closed Source vs. Open Source

Jetzt sind Schwarz und Weiß natürlich zwei Extreme eines gewaltigen Spektrums. Um die Gegensätze ein wenig konkreter einzuordnen, bietet es sich an, die Risiken und Chancen, die der Einsatz von Software immer mit sich bringt, im Kontext dieser beiden Gegenpole etwas differenzierter bewerten:

Risiken von Closed Source und Open Source

RisikoClosed SourceOpen Source
Software wird nicht weiter entwickeltMeist steht der Quelltext auch nach der Abkündigung nicht zur Verfügung, so dass es keine Funktions- oder Sicherheitsupdates mehr geben kann.Durch den offenen Source Code besteht die Möglichkeit auch nach der Abkündigung einer Software Änderungen vorzunehmen.
Sicherheitslücken in AnwendungSicherheitslücken können nicht von jedermann anhand des Quellcodes gefunden werden – allerdings sind z.B. sogenannte Fuzzing-Tools unterdessen so fortgeschritten, dass Fehler automatisiert, ohne Kenntnis des Quellcodes gefunden werden können.Durch den offenen Quellcode kann die Community, aber natürlich auch ein Hacker aktiv nach Sicherheitslücken im Quellcode suchen.
Vendor-Lock-InJe mehr proprietäre Komponenten in einer Software verwendet werden, desto schwieriger wird die Umstellung auf einen anderen Anbieter.Open Source ist keine Garantie für gute Software. Die Chance steht aber gut, dass offene Standards verwendet wurden. Falls nicht, kann im Notfall immer noch der Quellcode erweitert werden, um Daten in einem portablen Format auszugeben.
ComplianceEs lässt sich ohne Unterstützung des Herstellers nicht prüfen, was mit Daten innerhalb der Software passiert.Dank des offenen Quellcodes lässt sich in Audits genau nachvollziehen, wie Daten innerhalb der Lösung verarbeitet werden. Der Aufwand hierfür darf aber in keinem Fall unterschätzt werden.
Steigende KostenDurch das Vendor-Lock-In liegt die Preisgestaltung für Lizenzen und Support allein beim Anbieter.Theoretisch fallen für Lizenzen von Open-Source-Software keine Gebühren an, und den Support kann jeder übernehmen, der sich mit den verwendeten Technologien auskennt. In der Praxis hängen beide Kostenblöcke stark von der Verbreitung der jeweiligen Technologien ab.
Garantie und SupportDer Hersteller übernimmt Garantie und SupportEs gibt keine Garantie und Support nur über die Community. Allerdings gibt es viele Anbieter, die Support für Open-Source-Software anbieten.
Rechtliche UnsicherheitDer Hersteller übernimmt die Haftung bei lizenzrechtlichen Fragen zum Quellcode.Bei Open-Source-Projekten, die von einer Community entwickelt werden, gab es einzelne Fälle, in denen Rechteinhaber direkt die Nutzer in Regress genommen haben.

Chancen von Closed Source und Open Source

ChanceClosed SourceOpen Source
Erweiterung der LösungNur möglich über freigegebene APIsMöglich über APIs und Änderungen am Code, allerdings muss hier die Updatefähigkeit bedacht werden, so dass Änderungen ggf. Dem Hauptprojekt zur Verfügung gestellt werden sollten
SoftwarequalitätIn der Vergangenheit hatten bei unterschiedlichen Analysen vor allem kleinere Open-Source-Projekte einen Vorsprung vor Closed Source. Durch den breiten Einsatz von Open-Source-Technologien in Closed-Source-Software verschwimmen die Unterschiede.
Entwicklungs-geschwindigkeitDie Entwicklungsgeschwindigkeit hängt von den Ressourcen des Herstellers ab.Die Entwicklungsgeschwindigkeit hängt von der Grösse der Community ab.
Adaption neuer TechnologienBei bestehenden Lösungen, häufig eher späte Adaption neuer Technologien.Neue Technologien entstehen häufig aus der Open-Source-Community und werden dementsprechend auch schneller adaptiert.

Fazit Open Source vs. Closed Source

In diesem Kontext passende Punkte zu finden und zu bewerten, ohne in die Allgemeinplätze der klassischen Grabenkämpfe zu verfallen, ist gar nicht so einfach (ich bin dankbar über Anregungen für weitere Punkte). Insgesamt wird aber deutlich: sowohl Closed-Source- als auch Open-Source-Software haben ihre Risiken und jeweiligen Vorteile. Open-Source-Software bringt aus meiner Sicht mehr Chancen als Closed Source mit, diese müssen aber auch genutzt werden. Mit aktivem Maintainer und einer Community funktionieren Open-Source-Projekte, ohne meist nicht.

Dieses Fazit geht Hand in Hand mit Microsoft, Google, SAP, Oracle, IBM und vielen weiteren Größen, die unterdessen alle aktiv Open-Source-Projekte unterstützen und selbst betreiben.

Die spannende Frage ist noch: wie steht 1CRM und das Team von visual4 als größter deutscher Partner zu Open Source?

Wie steht 1CRM und das Team von visual4 zu Open Source?

Unsere CRM-Historie gründet ganz klar auf dem Community-getriebenen Open-Source-Projekt XRMS. Wir haben das System bei Kunden implementiert und auf Sourceforge die Entwicklung unterstützt. Leider waren wir irgendwann die einzigen und hatten nicht genügend Manpower, die Entwicklung alleine zu stemmen. Etwa zeitgleich lernten wir Michael Whitehead, den Chef von Longreach/ Infoathand, unterdessen 1CRM kennen.

Sein Produkt war und ist ein kommerzielles Open-Source-Produkt auf Basis von SugarCRM, dass durch den All-in-One Ansatz nahezu alle Anforderungen unserer Kunden erfüllte. 1CRM bringt viel Positives aus beiden Welten zusammen: Es gibt einen Hersteller, der weitestgehend auf offene Standards setzt und den Quellcode von 1CRM allen Kunden zur Verfügung stellt. Durch die Verwendung von Open-Source-Bibliotheken wird trotz eines überschaubaren Teams eine hohe Entwicklungsgeschwindigkeit erreicht. Risiken wie #1 in meiner Liste lassen sich mit Sicherheit nicht ganz eliminieren, wir entschärfen sie aber durch eine sehr enge Partnerschaft mit 1CRM und umfangreiche Vereinbarungen.

Nicht die reine Open-Source-Lehre, aber aus unserer Sicht eine Win-Win Situation für uns und unsere Kunden. Die beste CRM-Lösung in diesem Segment, entwickelt von 1CRM in Kanada, als perfekte Lösung für unsere Kunden adaptiert, dank offenem Quellcode.

OSS Verbreitung und Qualität:
https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-19.pdf