Wenn proprietäre Software vom Open Source eingeschüchtert wird

Nachdem ich einen Artikel gelesen hatte, der von einem Anbieter für Marketing-Automation verfasst war und mich völlig aus der Bahn geworfen hat, wollte ich einen klärenden Beitrag zu diesen falschen und irreführenden Aussagen leisten, die so deutlich die Philosophie und die Werte einiger Akteure in diesem Markt zeigen.

Ohne Bashing zu betreiben oder diese Personen beim Namen zu nennen, werde ich lediglich Erklärarbeit leisten und darlegen, warum das, was gesagt wird, äußerst falsch und böswillig ist – oder im besten Fall die Unfähigkeit bestimmter Personen offenbart.

Der Kontext

Das habe ich zu diesem Artikel (bis hierhin durchaus stimmig) gelesen: Er hilft Unternehmen dabei, ihre Marketing-Automation-Software auszuwählen, wie wir sie bei Webmecanik anbieten.

Die Gesetze entwickeln sich, und die Eigentümerschaft an Daten ist zu einem wichtigen Faktor bei Software-Entscheidungen geworden. Obwohl US-Unternehmen weiterhin in Europa dank des Privacy Shield vermarktet werden, gibt es keine Garantie, dass eine Konformität mit dem RGPD über die lange Zeit für Daten gewährleistet ist, die nicht im eigenen Land gehostet werden.

Das ist ein wenig dasselbe mit Open-Source-Lösungen: Da ihre Roadmap offen ist, setzt man sich Versionen von großer Tragweite aus – wie bei Mautic 3 –, die möglicherweise all seine Nutzer und die Nutzer seiner Wiederverkäufer dazu zwingen werden, eine gleichwertige Migration wie bei einem Wechsel der Software durchzuführen, wodurch der TCO dieser Lösungen explodieren wird.

Sie werden verstehen, dass mich nicht nur der erste Absatz stört, sondern im Gegenteil: gerade weil er hilft, den folgenden besser zu verstehen. Und genau dort liegt der wunde Punkt.

Open Source

Für diejenigen, die mit Open Source nicht allzu vertraut sind, finden Sie hier meine sehr einfache und schnelle Erklärung. Ein Open-Source-Projekt ist ein Projekt, dessen Quellcode offen ist. Das bedeutet: Jede Person kann kostenlos auf den Code der Lösung zugreifen, um damit (fast) alles zu machen, was sie möchte. Es selbst hosten, ändern, in eine andere App integrieren usw. Alle Personen, die möchten, können zur Weiterentwicklung dieses Codes (der App) beitragen, damit alle anderen Nutzer von diesen Weiterentwicklungen profitieren können. Dann spricht man von einer Open-Source-Community. Allerdings gibt es Administratoren, die diese Community anführen, sicherstellen, dass Code- und Funktionsvorschläge in die logische und nützliche Richtung für die Mehrheit der Nutzer des Projekts gehen. Zum Beispiel gehöre ich persönlich zum Core von Mautic mit einer Handvoll anderer Personen, um die Kohärenz der Weiterentwicklungen sicherzustellen.

Einige Beispiele für Open-Source-Projekte zeigen Ihnen, dass es bei weitem kein Problem ist: WordPress, Magento, Prestashop, Drupal. Sogar Google, Facebook und Microsoft stellen heute den Großteil ihres Codes (Framework) als Open Source bereit. Also, nur zu – auf Open Source zu setzen, ist gefährlich (Gelächter). Und um abzuschließen, wissen Sie, dass die Mehrheit (das gesamte Sortiment?) proprietärer Anwendungen (wie bei diesem Anbieter) auf einem Code (Framework) basieren, der selbst Open Source ist (PhP, Java, Symfony usw.), Ruby im Fall unseres bevorzugten proprietären Anbieters…

Mensch, sie lassen sich beim Schummeln in die Konfitüre greifen.

Die Realität von Open Source vs. proprietär

Gehen wir jetzt diese Aussage Punkt für Punkt durch und vergleichen die Funktionsweise zwischen einer proprietären Software (dem Anbieter, der diesen Satz schreibt) und der Welt von Open Source.

• Die offene Roadmap – Ja, ein Open-Source-Projekt ermöglicht es allen, beizutragen. Das bedeutet, dass man – statt ein Team aus 2 oder 10 Entwicklern zu haben – Hunderte von Entwicklern hat, die gleichzeitig an diesem Projekt arbeiten! Und wie ich es erklärt habe, gibt es Administratoren, die die Kohärenz der vorgeschlagenen Weiterentwicklungen sicherstellen und nicht davor zurückschrecken, Änderungen von den Beitragenden zu verlangen oder deren Beitrag abzulehnen, wenn er nicht passend ist. Die Philosophie ist also, den Nutzer in den Mittelpunkt seiner Roadmap zu stellen. Der proprietäre Anbieter und seine Roadmap? Er entscheidet allein mit einem kleinen Team, das sich um die Funktionen und die Wartung kümmern muss (darauf komme ich gleich zurück).
• Die Hauptversionen – Eine Hauptversion ist dann, wenn Ihre Anwendung eine sehr große Aktualisierung erhält. Das ist bei Mautic 3 der Fall (Übergang von 2.x auf 3.0). Solche Updates erlauben außerdem gewisse Code- oder Funktions-Inkompatibilitäten zwischen den beiden Versionen, die antizipiert und in den Update-Mitteilungen angekündigt werden müssen. Allerdings bedeutet „sich exponieren“ auch, sich diesem Wandel auszusetzen, also sich in Gefahr zu begeben. Im Fall von Mautic 3 hat diese Hauptversion zwei Ziele: die Version von Symfony (Framework) zu aktualisieren, dessen Community-Support 2019 endet (zur Info: eines der am häufigsten verwendeten PhP-Frameworks weltweit), sowie eine strukturelle Neugestaltung bestimmter Elemente der Anwendung vorzunehmen, um sie noch moderner, flexibler, leistungsfähiger und modularer zu machen. Alle Anwendungen haben Versions-Updates (WordPress in 5.0.2, Drupal 8.6.5 usw.). Wenn Sie in Ihrer Webanwendung kein Versions-Update haben, machen Sie sich Sorgen! Das bedeutet: Sie haben keinerlei funktionale Weiterentwicklung, und die Sicherheit Ihrer Anwendung verschlechtert sich! Ach ja, ich hatte es vergessen: Der proprietäre Anbieter muss die Versions-Updates des Codes (Sprache oder Framework) gleichzeitig mit den Funktionen ganz allein handhaben – also läuft alles deutlich langsamer.
• Die Nutzer dazu zwingen, alle Daten zu migrieren – Dann mal los… das ist einfach richtig und doch falsch. Das hängt von der Politik des Anbieters ab. In unserem Fall (weil wir in „allen seinen Nutzern und denen seiner Wiederverkäufer“ angesprochen werden), haben wir hierzu bereits in einem Post über Mautic 3 und wie wir es angehen als der wichtigste Beitragende zu diesem Community-Projekt kommuniziert. Wir stellen sicher, dass die Daten zwischen den beiden Versionen migriert werden – das muss unseren Nutzern einen Mehrwert bringen und nicht wegnehmen. Diese Behauptung ist in unserem Fall also falsch. Der Beweis anhand des Beispiels: Wir haben bereits vor 2 Jahren eine bedeutende Versionsmigration von Mautic 1 zu Mautic 2 durchgeführt. Kein einziger Kunde musste seine Kampagnen neu aufsetzen!

Damit endet diese Erklärung, die Ihnen hoffentlich zeigen wird, wie sehr der gemeinschaftliche und Open-Source-Ansatz einen echten Mehrwert hat für alle Entwickler und Nutzer. Wenn Sie mehr über Open Source lesen möchten, hatte ich außerdem einen Artikel über die Philosophie von Open Source geschrieben.

Solche Aussagen, deren Ziel es ist, Nutzer in Angst zu versetzen, machen mir ebenfalls Angst… denn der Wettbewerb zwischen verschiedenen Mitbewerbern darf nicht durch Behauptungen und Herabwürdigung anderer ausgetragen werden, sondern durch die Darstellung der jeweiligen Stärken. Für alle gibt es Platz auf dem Markt – also bleiben Sie bitte respektvoll gegenüber Ihren Kollegen und vermeiden Sie Desinformation. Was Sie, liebe Unternehmen, Interessenten und Kunden, betrifft, denken Sie daran, einen Anbieter zu wählen, der Ihre Werte teilt !