In Zeiten der Wirtschaftskrise ist Kosteneinsparung eines der wichtigsten Schlagworte. Für IT-Abteilungen bedeutet das derzeit oft Investitionsstopp und Versuche, Lizenzkosten für Softwareprodukte zu reduzieren.
Und da denken viele an Open Source. Viele setzen dabei “Open Source” gleich mit “frei“. Dies ist jedoch nicht unbedingt (immer) korrekt. Zunächst einmal gibt es da oft Missverständnisse durch leichtfertige Übersetzung aus dem Englischen:
“In der englischen Sprache bedeutet free nicht nur “frei”, sondern auch “kostenlos”. Englischsprachige Entwickler und Aktivisten machen die Unterscheidung mit free as in freedom und free as in beer deutlich. Bei freier Software (Originalausdruck auf Englisch: free software) bezieht sich „frei“ auf die erste Bedeutung, auf die Freiheiten für den Nutzer der Software. Zu den garantierten Freiheiten gehört auch, freie Software zu einem beliebigen Preis verkaufen zu dürfen.”
Wie üblich, wenn ein Hype aufkommt, möchte dann jeder dazu etwas anbieten können. Also entwirft man eine entsprechende Produktstrategie und heftet sich diese Wörter and die Fahnen (eben zB auch “Open Source”). Dabei wird dann in der Praxis nicht immer so streng vorgegangen, wie sich das Richard Stallman wünschen würde. Dies führt in der Praxis zu einer gewissen “Aufweichung” des Begriffes. Viele Leute reden von Open Source und die Vorstellungen gehen dabei auseinander.
Eine der häufigsten Fragen, die Hersteller von freien Open Source Produkten zu hören bekommen, ist dann: “Wie verdienen Sie denn dann noch Ihr Geld?” – Eigentlich klingt das ja komisch, zuerst wollen Kunden alles möglichst billig haben und dann kommt die Sorge auf, ob denn die Firma so überhaupt bestehen kann. Die Sorge ist berechtigt, den selbst wenn kein oder nicht viel Geld in die Implementation eines neuen Produktes gesteckt wird, dann wünscht man sich auch etwas Kontinuität (die sich in diesem Feld durch längerfristig verfügbare Support-Leistungen und Updates bemerkbar macht).
Nun, ich kann folgende Varianten ausmachen, wenn ich mir verschiedene Strategien unterschiedlicher Hersteller ansehe:
- Kommerzielle Produkte mit Source Code.
Bei dieser Variante versuchen Hersteller meist, bisher rein kommerzielle Produkte für diejenigen Kunden attraktiver zu machen, die ihre Abhängigkeit vom Hersteller reduzieren möchten. Wer das Produkt kauft, bekommt den Source-Code mit dazu und kann daher auch unter Zuhilfenahme eigener Arbeitskräfte selbst Anpassungen durchführen. Selbst wenn der Hersteller einmal nicht mehr ist, kann der Kunde selbst das Produkt weiter warten, sodaß es zumindest einige Betriebssystem-Updates “überlebt”. Der Kunde bezahlt hier für das Produkt generell und für den Source-Code.
- Freie Community-Version mit weniger Features als die kostenpflichtige Enterprise-Version.
In diesen Fällen wird die Sache noch etwas weiter geführt. Der Hersteller möchte potentielle Kunden dadurch gewinnen, daß er eine freie Version anbietet, die jeder selbst ausprobieren kann und in den Testbetrieb bringen kan. Der Source-Code bietet die zusätzliche Möglichkeit, selbst “rumzubasteln” und die Integration mit anderen bestehenden Systemen zu versuchen. Der Hersteller hofft darauf, daß der Benutzer “auf den Geschmack kommt” und mehr will bzw. “braucht” oder um Unterstützung bei Anpassungen ansucht. Dann werden Dienstleistungen und Wartungsverträge angeboten, um in den Genuß zusätzlicher Funktionen zu kommen. Der Kunde bezahlt in diesem Fall für Support und Zusatzfeatures.
- Freie Community-Version als “Beta-Version” für eine spätere, stabilere Enterprise Version.
Auch in diesem Fall möchte man den potentiellen Kunden dazu bringen, Gefallen an der Software zu finden und diese einzusetzen. Der Hersteller möchte in diesem Fall die Kreativität und Manpower der Community nützen, um das Produkt zu verbessern und erweitern. In die Enterprise-Version werden dabei nur die bereits stabil funktionierenden Features mit hereingenommen. Der Kunde bezahlt hier für den Support und die Sicherheit, eine stabil funktionierende Software zu bekommen.
- Keine Unterschiede im Code zwischen Community- und Enterprise-Versionen. Die Enterprise-Version beinhaltet allerdings Zusatzprodukte.
Zwei Code-Basen zu verwalten (wie bei 2. und 3. üblich) geht natürlich mit Schwierigkeiten einher und ist auch nicht so attraktiv für Mitglieder der Community, weil sie (unter anderem) meistens davon ausgehen müssen, daß ihre Beiträge letztendlich in die kostenpflichtige Version einfließen können, ohne daß die Mitglieder etwas davon haben. Die Kunden sind bei den Varianten 2. und 3. auch oft im Zwiespalt, auf welche Version (Community oder Enterprise) es wohl klüger wäre, zu setzen. Bei dieser Variante stellt sich das Problem nicht. Der Kunde bezahlt für Support-Dienstleistungen und für Zusatzprodukte (Analyse-Tools, Performance-Tuning, Import- und Export-Tools etc.).
Bei meinen Beobachtungen fällt mir auf, daß die 4. Variante scheinbar den größten Erfolg hat. Versetze ich mich in die Lage des Kunden und desjenigen, der selbst zum Produkt beitragen möchte, ist das die Variante, mit der ich mich am wohlsten fühle. Bei den Varianten 2. und 3. ist auch die Gefahr größer, daß es zu Zerwürfnissen zwischen der Community und dem Hersteller – und damit zu sog. “Forks” kommt.
Kritiker der Bewegung hin zu freien und Open Source Software-Produkten bemängeln immer wieder die fehlende Unterstützung und das Fehlen eines Verantwortlichen, der rechtlich in die Pflicht genommen werden kann, wenn das Produkt grobe Mängel aufweist. Aus diesem Grunde bieten die großen Investoren, die oft hinter größeren Open Source Software-Produkten stehen, eben diese entsprechenden Verträge an. In der Praxis sind daher bei größeren Unternehmen die freien Versionen ohne entsprechende Support-Verträge kaum zu finden.
Was bedeutet das? Open Source und freie Software ist im Allgemeinen nicht gratis!
Selbst beim Einsatz der freien Varianten entstehen Kosten:
- Investition in Personen, die sich mit der Installation und Administration beschäftigen – im Unternehmen das System warten (typischerweise User- und Berechtigungs-Verwaltung, Backup & Restore, Erhaltung der entsprechenden Infrastruktur, End-User-Support, …).
- Inanspruchnahme von (eigenen, aber meist auch fremden) Dienstleistungen, um das System mit bestehenden Infrastrukturen zu integrieren oder Probleme zu beheben, die über die tägliche Wartung hinausgehen.
- Migrationskosten durch Updates auf neue Releases (bei den freien Varianten gibt es tendenziell mehr Migrationsprobleme).
Der springende Punkt ist: Es gibt mittlerweile in vielen Bereichen Alternativen zu rein kommerziellen Produkten und in vielen Fällen zahlt es sich finanziell aus, auf diese Alternativen umzustellen, weil die entsprechenden “Enterprise-Verträge” oft weit günstiger sind, als die Lizenzkosten bei großen rein kommerziellen und Closed-Source-Produkten. – Nicht gratis, aber oft wesentlich günstiger.
Die entscheidende Frage, die sich stellt: Gibt es zu einem eingesetzten Produkt einegünstigere Alternative, die meinen Anforderungen genügt und in die restliche Infrastruktur integriert werden kann? – Diese Frage kann nicht global beantwortet werden, sie muß für jeden Einzelfall separat geprüft werden. Ein IT-Berater Ihres Vertrauens mit entsprechendem technischen Hintergrundwissen und Erfahrungen kann dabei gute Dienste leisten und Ihnen bei der Entscheidungsfindung helfen. Gerade in der Evaluierungsphase von Alternativprodukten geht oft sehr viel Zeit auf. Eine gute Analyse der eigenen bestehenden Prozesse und aktuellen wie zukünftigen Anforderungen ist dabei eigentlich unumgänglich und in manchen Bereichen wird eine Ablöse aus heutiger Sicht schwer möglich sein.
In manchen Bereichen gibt es allerdings schon eine Vielzahl an erfolgreichen Projekten, wo statt der gängigen kommerziellen Produkte quelloffene Alternativen zum Einsatz kommen und es gibt auch entsprechende Studien dazu, zB zum Einsatz von Open Office / Star Office. Einige gängige Alternativen sind
- MySQL oder PostgreSQL statt Microsoft SQL Server oder Oracle
- Open Office oder Star Office statt Microsoft Office
- SugarCRM statt verschiedener kommerzieller Produkte (in diesem Bereich gibt es wirklich eine mächtige Auswahl)
- Zarafa statt Microsoft Exchange Server
nur um einige Beispiele zu nennen. Das bedeutet jedoch nicht, daß diese Alternativen generell immer verwendet werden können – wie schon erwähnt, muß das für jeden Einzelfall geprüft werden! Ganz wichtig ist auch – falls man bestehende Systeme umstellt – nicht zu viele Produkte auf einmal zu ersetzen – mit schrittweisem Vorgehen kommt man mit wesentlich weniger “blauen Flecken” zum Ziel!
Der philosophische oder religiöse Aspekt: Im Grunde sollten die Vor- und Nachteile der jeweiligen Produkte in ihren Funktionen mit den Anforderungen abgewogen werden – jeweilige Kosten und Nutzen für das eigene Unternehmen gegenübergestellt werden. Es ist jedoch oft gar nicht so einfach, das genau in Zahlen zu fassen. Eine sehr schwer in Zahlen quantifizierbare Sache ist das Gefühl, daß die Investition langfristig gesichert ist. Dieses Gefühl macht sich zum Beispiel breit, wenn man sich sicher ist, auf Technologien und Produkte zu setzen, deren Bestand langfristig gesichert ist. Den Source-Code eines Produktes zu besitzen, trägt auch einen Teil zum Gefühl bei, daß die Investition langfristig gesichert ist. Denn man hat immer die Möglichkeit, selbst Programmierer darauf anzusetzen (auch wenn man vielleicht nur im Notfall darauf zurückgreifen würde) und wenn von einem Produkt der Source-Code öffentlich verfügbar ist, ist die Wahrscheinlichkeit größer, daß sich Leute finden, die diesen auch kennen und entsprechenden Mehrwert einbringen können. Eigentlich ein gehöriger Mehrwert – besonders, wenn man schon öfter die Erfahrung gemacht hat, daß Fehler, die man an einen Hersteller gemeldet hat, nur langsam (oder gar nicht) behoben werden… – Es ist also auch zu verstehen, wenn Firmen aus Prinzip auf Freiheit und Open Source setzen, selbst wenn man dabei auf manches besondere Feature oder buntere Icons verzichten muß.
