Open Source gilt immer noch zu oft als eine Möglichkeit, Geld zu sparen, indem man sich von proprietären Softwareherstellern und deren Lock-in-Praktiken emanzipiert. Als Reaktion darauf haben einige Unternehmen und öffentliche Einrichtungen versucht, eine existierende Open-Source-Lösung intern neu zu entwickeln, ohne den Softwarehersteller. Ihr Ziel war, ein Höchstmaß an Kontrolle und Autonomie zu erlangen. Erwartungsgemäß funktioniert dies nicht – Misserfolge häufen sich ebenso wie nicht gehaltene Versprechen.
Warum ist das so? Weil sich die Tätigkeit des Softwareherstellers – auch bei Open-Source-Software – nicht improvisieren lässt und vielfach stark unterschätzt wird. In diesem Artikel erfahren Sie mehr über den wenig bekannten Beruf, das heißt über die Profis, die für 90 % der Open-Source-Software verantwortlich sind.
Die Grundlagen
In diesem Artikel und generell mit Blick auf Open Source ist es wichtig, zu unterscheiden:
- Technische Komponenten, die oft gemeinschaftlich verwaltet werden und nicht für den Endanwender bestimmt sind, sondern Technikern oder Entwicklern zum Aufbau von Lösungen dienen. Beispiele dafür sind Middleware, Datenbanken und Infrastrukturkomponenten wie Nginx oder Cyrus, zu denen in der Regel hauptsächlich Softwarehersteller beitragen.
- Lösungen für Endanwender, zum Beispiel Office-Suiten oder Verwaltungs- und E-Mail-Anwendungen, bei denen die Anwenderakzeptanz, das Ökosystem und die gesamte Umgebung genauso wichtig sind wie die Funktionsweise.
Um die zweite Kategorie dreht sich dieser Artikel.
Eine von hegemonialen Ogern geerbte Angst
„Kopfgeldjägerverhalten“, „mehr verkaufen“ statt „besser verkaufen“, unausgewogene Handelsbeziehungen, technologisches und vertragliches Lock-in, Nichteinhaltung der DSGVO, Extraterritorialität des Rechts … Es mangelt nicht an Argumenten, die öffentliche und private Organisationen dazu veranlassen, nach Alternativen zu den hegemonialen, namentlich amerikanischen, Lösungen zu suchen.
Allerdings gehen einige IT-Verantwortliche, die sich Open Source zuwenden, einen Schritt zu weit: Sie übertragen Ihre legitime Abneigung gegen bestimmte große Softwarehersteller und deren unverschämtes Verhalten auf Softwarehersteller im Allgemeinen und betrachten sie als kommerzielle Parasiten.
Manchmal findet sich diese Abneigung auch bei Leuten, die nicht verstehen wollen, dass sie auch für freie Software bezahlen sollen. Aussagen wie „freie Software darf nur eine Dienstleistung sein“ oder „der Benutzer entscheidet, was er bezahlen muss“ werden jedoch zum Glück seltener, je ausgereifter freie Software ist.
Der Unterschied zwischen Projekt und Produkt
Manche Organisationen entscheiden sich dafür, ihre Lösung intern zu „bauen“, indem sie Open-Source-Dienstleister mit der Entwicklung oder dem Support beauftragen. Dies ergibt Sinn, wenn es keine Lösung von der Stange gibt, die zur Fragestellung passt, oder wenn ein spezifischer Geschäftsbedarf abzubilden ist. Es ist jedoch nicht mehr sinnvoll und immer kontraproduktiv, wenn es bereits eine fertige Standardlösung gibt, die den Bedarf erfüllt. Eine Standardlösung lässt sich nicht mithilfe von Dienstleistungen oder Support entwickeln.
Wichtig zu verstehen: Während man ein Projekt durchführt, schreibt man keine Software! Die tatsächlichen Kosten und Aufgaben für die Entwicklung und Pflege von Standardsoftware sind immens, sie stehen in keinem Verhältnis zu dem, was ein Projekt erfordert. Je mehr Zeit vergeht, je umfangreicher die Software wird und je mehr Versionen es gibt, desto größer wird dieser Unterschied. Die Pflege der Software, der kontinuierliche Aufwand für Tests und Qualität, die notwendige Weiterentwicklung der technologischen Basis und die technischen Schulden werden schnell zu den zeitaufwendigsten (und teuersten) Aufgaben.
Der Wunsch nach Software im Servicemodell
Am anderen Ende des Spektrums steht die Vorstellung, was ein Kunde für Software im Servicemodell auszugeben bereit ist, inklusive Entwicklung neuer Funktionen und Support. Diese hat absolut nichts mit all der Arbeit zu tun, die ein Softwarehersteller leisten muss, um eine qualitativ hochwertige, zukunftssichere Lösung zu liefern.
Die initiale Entwicklung für den ersten Anforderer ist einfach, weil es nur eine einzige Aufgabe gibt: die geforderten Funktionen zu entwickeln. Dies gilt jedoch nur für die erste Version und nur für einen einzigen Kunden – den ersten.
Die Maschine, die die Maschine baut
Häufig beginnt ein Projekt mit der Entwicklung eines Programms oder der Zusammenstellung mehrerer Komponenten und mit dem Ziel, eine bestimmte Aufgabe für einen Benutzer zu lösen. Der anfragende Nutzer ist natürlich zufrieden: Man bietet ihm eine Lösung für seine spezifische Anfrage.
In der Folge denkt sich der Entwickler oder Auftraggeber möglicherweise: „Was wir hier haben, könnte auch anderen nützen, außerdem habe ich eine Menge Ideen, welche Funktionen ich hinzufügen könnte. Ich mache ein Produkt daraus und werde dafür ein paar Leute organisieren, die mit mir zusammenarbeiten oder mich bei der Finanzierung unterstützen.“
Und hier liegt der Fehler: Die Lücke zwischen einem spezifischen Projekt und der Software ist in der Regel 100-mal größer als gedacht! Vom Prototypen zu einer standardisierten, industrialisierten Lösung zu gelangen, ist viel komplexer als die Aufgabe, den Prototypen selbst zu erstellen. Das gilt für Software genauso wie für andere Lösungen, etwa in der Fertigungsindustrie.
Wenn es jemand geschafft hat, ein Auto in der eigenen Garage zu bauen und Fehler mit dem Hammer zu beheben, ist das ein beachtlicher Erfolg. Aber es heißt noch lange nicht, dass derjenige oder ein anderer mühelos der nächste Renault werden kann – mit industrialisierter Produktion, umfangreichen Verpflichtungen/Garantien und einem Wartungs- und Reparaturnetz.
Governance – über den ersten Kunden hinaus
Neben komplexen Anforderungen wie derjenigen, neue Funktionen zu entwickeln und dabei selbstverständlich zu skalieren, hat auch die steigende Anzahl von Kunden Konsequenzen für ein Projekt:
- Wie wollen Sie die Roadmap beherrschen, wenn die Funktionen, die Sie entwickeln, von einem Kunden und dessen Finanzen diktiert werden, und nicht diejenigen sind, die Sie für das Produkt als vorrangig erachten?
- Wer sorgt für Governance, wer definiert und garantiert die langfristige Vision der Lösung?
- Wer ist für Implementierung in Projekten verantwortlich?
- Wer garantiert die Kompatibilität und das Funktionieren in unterschiedlichen Benutzerkontexten?
- Wer pflegt und entwickelt die technologische Grundlage weiter, kümmert sich also regelmäßig um umfangreiche Arbeiten und Aktualisierungspfade bzw. -werkzeuge?
- Wie können die Details der Funktionen und ihre Auswirkungen je nach Implementierung bewertet werden?
- Wer stellt die alten Versionen der Software sicher?
- Wer entscheidet über APIs und Interaktionen mit anderen Tools oder Partnern und wer sichert diese?
- Wie können Sie Know-how und Kompetenz erwerben und entwickeln, wenn sich Teams und Projekte ständig ändern?
Diese Fragen – oder vielmehr die Tatsache, dass befriedigende Antworten fehlen – veranschaulichen, welche Grenzen das Dienstleistungsmodell in der Entwicklung von Open-Source-Software hat. Sie liefern Erklärungen für Misserfolge von Organisationen, die glauben, sich von Softwareherstellern zu befreien und trotzdem eine Standardanforderung decken zu können.
Der Open-Source-Softwarehersteller
Eine Lösung ist kein Quellcode, sondern ein zuverlässiges, unterstütztes, qualitativ hochwertiges Produkt, das den Anwendern gefällt – zu angemessenen, berechenbaren Kosten.
Die Rolle eines Softwareherstellers besteht darin, ein dauerhaftes Produkt zu entwerfen, zu erhalten und weiterzuentwickeln, das den Bedürfnissen der Anwender entspricht – in Bezug auf Funktionalität, Ergonomie, Sicherheit und Leistung.
Softwarehersteller zu sein, stellt sehr hohe Ansprüche: langfristige Verpflichtungen, effiziente Governance, umfangreiche Kapazitäten für Vision, Antizipation, Entwicklung, Qualität und Wartung, außerdem die gesamte Organisation mit dem Ziel, Anfragen und Bedürfnisse der Kunden und Partner, die eine Lösung wollen, zu erfüllen. Das alles lässt sich nicht improvisieren.
Open-Source-Softwarehersteller vermarkten typischerweise Angebote, die die Nutzung und den Betrieb der Lösung ergänzen oder erleichtern. Dazu gehören zusätzliche Tools, zusätzliche Funktionen oder Support durch die „ultimativen Experten“ für diese Software mit garantierter Reaktionszeit. Für diese Angebote gibt es verschiedene Modelle: Abonnements oder Subskriptionen, SaaS-Dienste (Bereitstellung der Lösung als gehosteter Dienst), den Kauf von Modulen oder Zusatzfunktionen vom Typ Freemium bzw. Open Core oder andere Leistungen.
Diese Angebote sind in der Regel gut durchdacht, damit sie ein Gleichgewicht zwischen Einnahmen und Wertschöpfung sicherstellen. Speziell in Frankreich gibt es Anwender, die eine bestimmte Lösung haben möchten, aber nicht das ganze Angebot eines Softwareherstellers. Sie wollen sogar (ein bisschen etwas) dafür bezahlen, möchten aber Ihr Angebot selbst definieren. Ein klassisches Beispiel für die Abneigung gegenüber Softwareherstellern ist der Satz: „Ich bezahle gerne für Support, aber nicht pro Benutzer.“ Auf dieser Aussage beharren manche auch dann noch, wenn es sich dabei um die fairste, relevanteste und einfachste Messgröße handelt.
Es ist wie bei der französischen oder jeder anderen Fußballnationalmannschaft: Am Abend eines Spiels kann man sich leicht vorstellen, dass man der bessere Trainer oder Spieler wäre! Das Angebot eines Softwareherstellers erfordert Respekt. Es ist Teil seines Modells, seiner Berechenbarkeit und seiner allgemeinen geschäftlichen Gleichung. Zu versuchen, es an seiner Stelle neu zu definieren (insbesondere mit Prinzipien, die nicht funktionieren), ist der falsche Ansatz.
Wenn Sie mit einem Open-Source-Softwarehersteller zusammenarbeiten, statt zu versuchen, ihn zu umgehen, maximieren Sie Ihre Erfolgschancen. Sie erhalten eine bessere Lösung, stellen die Kontinuität der Software sicher, nutzen das beste Fachwissen und sparen gleichzeitig Geld. Sie setzen auf eine offene Philosophie, von der alle profitieren.
Ob für Unternehmen, Vereine oder Stiftungen, ob gewinnorientiert oder nicht – Softwarehersteller sind Garanten für die Zukunft von Open-Source-Lösungen. Sie betreiben eine Organisation, ein Geschäft mit Mitarbeitern, einer Roadmap und wirtschaftlichen Herausforderungen. Denken Sie daran: Freie Software lebt nicht nur von Liebe und frischem Wasser!
BlueMind – Open-Source-Softwarehersteller durch und durch
Die Klage, es gäbe zu wenig qualitativ hochwertige Open-Source-Lösungen für den Endanwender, ist paradox. Sie passt nicht zur allgemeinen Abneigung gegen Open- Source-Softwarehersteller.
Für BlueMind ist der Weg klar: Wer eine echte souveräne Alternative zu den hegemonialen amerikanischen Lösungen liefern will, muss in erster Linie ein gutes Produkt anbieten. Und wer zum Thema Messaging ein gutes Produkt bieten will, braucht eine ernsthafte Antwort auf die vier Eckpfeiler der Marktnachfrage:
- Funktionen: Gefragt sind erweiterte Funktionen für das Messaging-Kernsystem, nicht nur ein Abhaken einfacher Funktionen wie Mail, Kalender, Kontakte. Es geht um fortschrittliche Nutzungsszenarien und ein Funktionsmodell, in das sich andere Komponenten der Zusammenarbeit nahtlos integrieren lassen, zum Beispiel Videokonferenzen, Dokumente, Live-Kommunikation und Wissen.
- Gewohnheiten: E-Mail ist das am häufigsten genutzte Arbeitsmittel in Unternehmen. Mehr noch als bei jedem anderen bestimmt dabei der Anwender, welche Lösung er nutzt. Häufig fällt die Wahl auf Outlook. BlueMind hat dieses Problems verinnerlicht und stellt den Anwender in den Mittelpunkt all seiner Entwicklungen. Ziel ist es, das einzige Messaging-System zu bieten, das mit allen Nutzungsarten kompatibel ist – mit Outlook im nativen Modus, aber auch mit anderen Zugangsmöglichkeiten. Im Übrigen: BlueMind ist die einzige Alternative zu Microsoft, die das Kunststück vollbracht hat, Outlook ohne Konnektor zu unterstützen.
- Ausfallsicherheit: Messaging muss funktionieren – und soll nie ausfallen!
- Skalierbarkeit: Die Lösung muss Probleme und Entwicklungen genauso abbilden wie das Wachstum der Bevölkerung und die kollaborative Nutzung.
BlueMind ist ein Open-Source-Softwarehersteller durch und durch – und wird daher diesen vier Eckpfeilern gerecht. Die Entwicklung qualitativ hochwertiger, zukunftssicherer Software für den Anwender erfordert alle Fähigkeiten eines Herstellers. Dieses Metier hat auch im Bereich Open Source wenig Erfolg, wenn es ein serviceorientiertes Modell verfolgt.
Hersteller zu sein bedeutet, sich zu 100 % auf die Lösung zu konzentrieren: auf das Produkt, auf alle Tools und Ressourcen, die es bereichern, zum Beispiel Migrationstools, verschiedene Dokumentationen (technische, funktionale oder kommerzielle) und auf das Ökosystem (insbesondere Integrations- und Technologiepartner). BlueMind setzt auf eine globale, dauerhafte Vision und Governance, um eine stimmige Lösung zu gewährleisten.
Das ist das Qualitätsniveau, das Anwender erwarten. Es erlaubt BlueMind, eine souveräne, glaubwürdige und vor allem von Anwendern und Kunden akzeptierte Alternative anzubieten.
#WirhabendieWahl
