Ein wesentliches Argument für den Einsatz von Open-Source-Software ist sicher die Einsparung von Lizenzkosten. Doch die Reduktion von Freeware auf den Aspekt "kostenlos" verkennt die Tragweite des dahinter stehenden Modells der Programmentwicklung und die damit verbundene Ökonomie. Eine solche Sicht stößt nicht nur auf Ablehnung bei eingeschworenen Fans quelloffener Software, sie verschenkt zudem Chancen, die der Einsatz solcher Programme im eigenen Unternehmen bietet.
Während sich Anbieter kommerzieller Software kaum in die Karten sehen lassen, gehorcht freie Software viel stärker demokratischen Regeln. Die Kultur der Freeware-Communities eröffnet dem Anwender neue Gestaltungs- und Mitsprachemöglichkeiten, konfrontiert ihn aber mit einer gewachsenen Unübersichtlichkeit. Anstatt auf Marketing-Verlautbarungen großer Hersteller zu lauschen und zu warten, ob diese ihre Versprechungen auch halten, werden Open-Source-Anwender mehr oder weniger Teil eines offenen Entwicklungsprozesses. Der wiederum verlangt zumindest eine aktive Informationspolitik, die bis zur Einmischung in den Produktfahrplan reichen kann. Besonders bei einer strategischen Ausrichtung auf Open Source ist entsprechendes Engagement unverzichtbar.
Die zahlreichen neuen Dienstleister rund um freie Software erheben den Anspruch, dass sie Anwendern genau diese Aufgabe abnehmen und für sie als Mittler zur Entwicklergemeinde auftreten. Sie schirmen DV-Verantwortliche von der Komplexität freier Projekte ab und erlauben ihnen im günstigsten Fall die Nutzung von Open Source nach dem Muster kommerzieller Programme. Das kann oft der richtige Umgang mit quelloffener Software sein, gelegentlich ist aber ein stärkeres Engagement nötig, um die Möglichkeiten dieses Modells besser ausschöpfen zu können. Hinzu kommt, dass bereits der Entschluss, Freeware einzusetzen, und die Wahl des Serviceanbieters ein gutes Verständnis der dahinterstehenden Konzepte erfordern. Ohne Kenntnis der Arbeitsweise freier Entwicklerteams könnten Anwender leicht falsche Erwartungen an Open-Source-Projekte stellen.
Allein die Entkopplung von Programmierung und Marketing aufgrund der ehrenamtlichen Tätigkeit der Entwickler hat großen Einfluss auf die entstehenden Produkte. So müssen sich Open-Source-Teams nicht von außen auf Fertigstellungstermine festlegen lassen, sondern können die Freigabe der Software von technischen Kriterien abhängig machen. Das führt - kombiniert mit der freien Zugänglichkeit des Quellcodes - zwar meistens zu hochwertigen Programmen, kann aber die Geduld des Anwenders, der Termine einhalten muss, strapazieren. Dies gilt besonders dann, wenn eine potenzielle Geschäftsmöglichkeit ungenutzt zu verstreichen droht. Solche unliebsamen Überraschungen kann es gerade bei kleineren Projekten geben, wenn beispielsweise einer der wichtigsten Entwickler nicht mehr so viel Zeit aufbringen kann. So scheint die Arbeit an dem XML-zu-PDF-Konverter "FOP" (http://xml.apache.org/fop) seit dem Rückzug des Initiators James Tauber zu stagnieren. Open-Source-Entwickler haben zudem häufig eine stark technische Ausrichtung und denken beim Zielpublikum oft an ihresgleichen. Deshalb ist freie Software im Allgemeinen nicht mit grafischen Assistenten oder Wizards ausgestattet und entbehrt einer gewissen Benutzerfreundlichkeit. Je nach dem Know-how der IT-Abteilung können daher die Kosten für den Einsatz freier Software leicht die Einsparungen für Lizenzgebühren übersteigen.
Servive bei freier Software besser
Entscheider sollten prinzipielle Überlegungen anstellen, wie sie mit den Unwägbarkeiten von Freeware umgehen, bevor sie mit einem einschlägigen Dienstleister Kontakt aufnehmen. Dieser wird aufgrund seines Geschäftsinteresses dem potenziellen Kunden selten von Linux oder Apache abraten.
Nach Vorstellung des Open-Source-Theoretikers Eric Raymond ist der Service bei freier Software notwendigerweise besser (siehe "The Magic Cauldron", http://www.tuxedo.org). Kommerzielle Anbieter verdienten ihr Geld in erster Linie über Lizenzgebühren für ihre geheimen Bits und Bytes, Support mache sich für sie trotz der gelegentlich teuren Verträge eher als Kostenfaktor bemerkbar. Entsprechend arbeiteten alle talentierten Mitarbeiter in der Entwicklung, die anderen beantworteten Kundenanfragen. Da häufige Updates die Lizenzeinnahmen sprudeln lassen, wollen Hersteller proprietärer Software zudem für alte Versionen möglichst den Support reduzieren, um Anwender zum Umstieg auf aktuelle Ausführungen ihrer Produkte zu bewegen. Dienstleister für Open Source hingegen können mit Lizenzen nichts verdienen und konzentrierten sich daher ganz auf den Service.
In der Praxis fällt dem Anwender die Auswahl des richtigen Partners für Open Source aber nicht so leicht. Auch wenn die Zertifizierungsprogramme von kommerziellen Anbietern keine letzte Gewähr für die Kompetenz eines Business-Partners geben, kann der Kunde doch zumindest gewisse Mindestkenntnisse voraussetzen und sich im schlimmsten Fall beim Hersteller beschweren. In der Open-Source-Szene wird schon seit längerem über verbindliche Zertifizierungsprogramme diskutiert. Faktisch konkurrieren jedoch im Fall von Linux Organisationen wie das Linux Professional Institute (LPI, http://www.lpi.org) oder SAIR (http://www.linuxcertification.org) mit den Programmen der großen Distributoren. Es erfordert einige Marktkenntnis, um bestimmte Zertifikate einschätzen zu können oder um zu wissen, welche Schulungen für die eigenen Mitarbeiter angesichts der geplanten Nutzung von Freeware am besten geeignet sind. Das freie Spiel der Kräfte gibt auch unseriösen Firmen Spielraum. Für negative Schlagzeilen sorgte zuletzt der Trittbrettfahrer Linux One (http://www.theregister.co.uk/991102-000009.html), der zwar keinen Umsatz, kein geschultes Personal oder selbst entwickelte Software vorweisen kann, aber dennoch an die Börse gehen will. Unkorrektes Verhalten ist zwar keine Spezialität von Open-Source-Anbietern, wird aber durch das offene Modell begünstigt.
Der vom kommerziellen Umfeld her gewohnte Ansatz, sich aus einem Sicherheitsbedürfnis heraus an den größten Dienstleister zu halten, muss nicht die beste Wahl sein. Bei den Marktführern im Linux-Umfeld handelt es sich häufig um Anbieter von eigenen Distributionen, die bei Service-Leistungen und Schulungen stark an ihrer eigenen Linux-Variante orientiert sind. Beim Training muss das keine große Einschränkung sein, weil sich die verschiedenen Linux-Ausgaben in den Grundfunktionen weitgehend gleichen. Bei Ausbildungen zur Systemadministration allerdings können sich die Abweichung in der Installation und Konfiguration der Systeme negativ bemerkbar machen. Besonders die Komfortfunktionen, die Distributoren zum quelloffenen Rohprodukt hinzufügen, weichen voneinander ab, wobei Anbieter diese nicht immer als freie Software an die Community zurückgeben. Einige der Differenzen verschwinden aber möglicherweise, wenn das Standardisierungsprojekt "Linux Standard Base" (http://www.linuxbase.org) von Erfolg gekrönt ist.
Nachteilig sein könnte für Anwender, sich für einen Distributor als Dienstleister zu entscheiden, bevor sie sich auf eine Open-Source-Strategie festgelegt haben. So kann sich die Nutzung einer Datenbank unter Linux nachträglich als umständlich erweisen, weil der Hersteller nicht die bereits im Unternehmen vorhandene Linux-Ausführung, sondern eine andere Distribution bevorzugt. Wenn sich aufgrund der unterschiedlichen Eignung von Linux-Varianten für mehrere vorgesehene Zwecke absehen lässt, dass eine gemischte Umgebung zustande kommt, dann erweisen sich distributionsunabhängige Dienstleister wie Innominate oder ID-Pro vielleicht als flexibler.
Konkurrenzvorteil für flexible Anwender
Andererseits können die Anbieter von eigenen Distributionen durch Detailkenntnis und Anpassungen brillieren, wenn ihre Zusammenstellung flächendeckend eingesetzt wird.
Der teilweise chaotische Charakter offener Softwareentwicklung mag konservative Anwender beunruhigen, weil sie die damit verbundenen Unwägbarkeiten fürchten. Wenn sich andererseits Unternehmen auf die Spielregeln der Open-Source-Gemeinde einlassen, können sie sich aus vielen Abhängigkeiten befreien, die ihnen das etablierte Softwaregeschäft auferlegt.
Sind bei freier Software mangels Vermarktungsinteresse die Fertigstellungstermine oft unsicher, so verspäten sich kommerzielle Programme häufig deswegen, weil sie aus Verwertungsgründen zu früh angekündigt wurden. Während Anwender im zweiten Fall außer Warten nicht viel tun können, besteht bei Open Source die Möglichkeit, das Schicksal in die eigene Hand zu nehmen. Der Quellcode von Freeware ist während seines ganzen Entwicklungszyklus frei zugänglich. Aufgrund der hohen Qualitätsansprüche freier Teams werden Programme oft noch als Betaversionen gekennzeichnet, die ein kommerzieller Anbieter schon längst freigegeben hätte. Wenn Unternehmen zur Überzeugung gekommen sind, dass eine Software bereits robust genug ist, können sie nach eigenem Ermessen damit arbeiten, ohne sich auf das zweifelhafte Freigaberitual eines Lieferanten zu verlassen. Im Gegensatz zu kommerziellen Betaversionen ist diese dann nicht durch ein Ablaufdatum beschränkt und beinhaltet keine bremsenden Debug-Informationen. Ein Beispiel dafür ist die Betaausführung des Web-Tools "PHP 4.0", das schon in vielen Produktionsumgebungen läuft.
Privileg der direkten Einflussnahme
Direkten Einfluss können Anwender nehmen, indem sie sich unmittelbar in den Produktionsprozess einschalten. Das kann in Form von Rückmeldungen an die Entwickler geschehen, um diese von der Notwendigkeit oder Unnötigkeit bestimmter Funktionen zu überzeugen oder um Änderungswünsche anzumelden. Bei kommerzieller Software ist selbst großen Anwendern dieses Privileg nur selten gegönnt. Natürlich wird es in Großprojekten wie dem Linux-Kernel schwieriger sein, seine Vorstellungen einzubringen. Einfacher gestaltet sich das aber allemal, wenn Anwender den von ihnen gewünschten Code gleich selbst beisteuern. Allerdings wird Linus Torvalds, auf den zahlreiche Vorschläge und Codebeiträge einprasseln, diese eher verwerfen als es in kleinen Projekten der Fall ist. Gerade bei Letzteren besteht die Möglichkeit, die Fertigstellung zu beschleunigen, indem eine Firma für ein paar Wochen einen Entwickler abstellt. Das ist meist immer noch günstiger als eine komplette Eigenentwicklung und bietet zudem einen Investitionsschutz: Wenn der betreffende Programmierer kündigt, lebt das Projekt dennoch weiter. Zwar kann sich auch die Konkurrenz die Software zunutze machen, hat aber dann meist einen zeitlichen Rückstand und die Software nicht nach den eigenen Anforderungen gestaltet.
Auch bei Service und Support eröffnen sich neue Chancen, wenn sich Unternehmen mit der Open-Source-Kultur anfreunden. Bei Bedarf lässt sich eine fließende Arbeitsteilung zwischen der eigenen IT-Abteilung, der Community und einem Dienstleister organisieren. Bei entsprechendem Know-how sind viele Probleme über das Studium von Frequently Asked Questions (FAQs) und How-tos zu knacken. Diese gehen in der Darstellung von Lösungen meist weit über Herstellerdokumentationen hinaus. Zusätzlich können Anwender die Hilfsbereitschaft in den einschlägigen Foren des Usenet in Anspruch nehmen, wenn sie sich durch gelegentlich unzutreffende Antworten nicht aus der Ruhe bringen lassen. Schlussendlich geht aus den Quellen meist hervor, wer der Autor eines bestimmten Moduls ist. Da im Allgemeinen auch dessen E-Mail-Adresse mit angegeben ist, steht bei Fehlern einer Kontaktaufnahme mit dem Programmierer nichts im Wege - welcher Service kommerzieller Software bietet das schon?