Open Source in Unternehmen – Programmierer als Bremser
14. März 2004 von Wolfgang SommergutMatthew Langham berichtet in seinem interessanten Beitrag, dass sich nach seiner Erfahrung die Manager oft leichter von den Vorteilen freier Software überzeugen lassen als firmeninterne Entwickler. Während Entscheider meist aufgrund einer überzeugenden Kosten-Nutzen-Analyse auf Open Source einschwenken, bleiben Programmierer häufig bei einer ablehnenden Haltung. Hier die von Matthew Langham genannten Hauptgründe für dieses Verhalten:
- In Zeiten des Outsourcing fürchten viele firmeninterne Entwickler ohnehin um ihre Daseinsberechtigung. Diese Ängste werden noch verstärkt, wenn das Unternehmen freie Software einsetzt anstatt selbst zu entwickeln.
- Unternehmensinterne Programmierer arbeiten zumeist mit komfortablen kommerziellen Tools, während in der Open-Source-Welt spartanische Werkzeuge wie CVS, IRC oder Maven vorherrschen.
- Kulturelle Differenzen: Den Entwicklern in der IT-Abteilung ist die Kooperationweise von weltweit verteilt arbeitenden Teams nicht geläufig. Außerdem verstehen sie oft nicht, welche Vorteile es bringt, wenn man eigenen Code wieder an das Open-Source-Projekt zurückgibt.
Nach meiner Erfahrung würde ich noch einen weiteren Grund hinzufügen: Hausinterne Programmierer konzentrieren sich oft auf eine kleine Zahl von Werkzeugen, mit denen sie jedes Problem zu lösen versuchen. Bereits existierende Lösungen jenseits ihres Tellerrands sind ihnen häufig unbekannt, d.h., sie haben meist einen erstaunlich geringen Marktüberblick.
Kategorie: Open Source 5 Kommentare »
In einem nicht unwichtigen Punkt muss ich den Artikel ergänzen. Vorstand, Geschäftsführung oder IT-Leitung sichern sich in Deutschland in der Fragen Softwarelizensierung gerne ab. Sie wägen die Risken bei Anschaffungen zwischen „Kosteneinsparung“ und „Wartung, Haftung und Gewährleistung“ ab. Sie tendieren dabei immer noch zu Software von grossen (und internationalen) Herstellern wie beispielsweise IBM, SAP oder Microsoft. Deutlich ist aber auch, dass sie sich als Alternative immer häufiger mit Open Source beschäftigen. Die meisten scheuen aber noch diesen Schritt. Ein Ausweg bieten Open Source basierte Produkte wie beispielsweise von SuSe oder Red Hat, die Service- und Wartungsverträge bieten bzw. lizensieren. Diese Vorgehensweise scheint mir auch der Schlüssel zum Erfolg von Open Source in grösseren Unternehmen zu sein.
Mir scheint noch ein anderer Punkt, den Matthew Langham ebenfalls
anschneidet, ausschlaggebend:
„I can write it quicker and better myself than if I try and understand what
the other developer wrote“. While Open Source software is not always well
documented (at least probably not according to your corporate standards), this
argument probably stems more from the fact that the developer is trying to
maintain his perceived value.“
Aus meiner zugegebenermaßen recht bescheidenen Erfahrung in diesem Bereich
kann ich bestätigen, dass der Zeitaufwand im Umgang mit Open Source sehr häufig
aufgrund der schlechten Dokumentation enorm ist. Zu bedenken ist auch, dass es
zwischen Open-Source-Entwicklern und dem firmeninternen einen weitern
wesentlichen Unterschied gibt, der die Zusammenarbeit erschwert. Während
Letztere ihre Brötchen mit der Entwicklung von Software verdienen müssen, ist
die Motivation der freien Entwickler meist der Spaß am Programmieren. Dies
schlägt sich in der Regel auch in der Arbeitsweise nieder. Schlecht
dokumentierter Code ist ein Beispiel dafür. Der typische Entscheider versteht
häufig von den technischen Zusammenhängen wenig. Er sieht vor allem, dass es da
ein Stück Software scheinbar kostenlos gibt, lässt den Aufwand, den die
Einführung von Open Source nach sich zieht, aber gern unberücksichtigt.
Jim, da sind viele Entscheider anderswo auch nicht mutiger. Nicht umsonst ist der Satz „Nobody ever got fired for buying IBM“ in den USA entstanden. Der Anteil von Open Source ist in deutschen Unternehmen vergleichsweise hoch. Bemerkenswert fand ich aber an Matthews Beitrag, dass ausgerechnet Programmierer so resistent gegen Open Source sein können. Von Managern hätte man das vielleicht erwartet.
Michael, du bist beim Zitieren etwas tendenziös. Der Beitrag verweist nämlich auch darauf, dass unternehmensintern entwickelte Anwendungen ebenfalls oft lausig dokumentiert sind:
„Back in the 90’s most corporate projects were written from scratch and often „close to magic“. The only people who really knew the software were the people who actually worked on it. And due to the lack of documentation – they were doubly important.“
Schlechte Doku ist übrigens kein Privilg von freier Software. Dort geschieht es zumindest nicht mit schlechter Absicht – anderes als bei namhaften Herstellern, die ihre APIs, Dateiformate und Protokolle bewusst nur unvollständig offenlegen.
Make or buy (oder eben download) ist für die Entwickler einfach wichtiger als für die Verwaltungsetage, weil es ihr Gebiet berührt. Das ist wie wenn man einen Kfz-Meister mitnimmt, sich einen Gebrauchten anzuschauen: er kann einem wichtige Tipps geben, doch geht er viel zu detailiert vor und quasselt einen voll mit Dingen, die man nicht versteht.
Ich habe es zumeist (gerade letze Woche wieder) erlebt, das wenn man sich die Zeit nimmt, mit den Betroffenen (also den späteren Nutzern) zu sprechen und ihnen zuzuhören und ihnen dann eine Open Source Software vorschlägt, die sogar neumodisch und unkonventionell ist, und ihnen erklärt, welche Vor- und Nachteile sie hat und warum sie die Aufgabe am besten löst, dann stösst man, wenn überhaupt, nur auf politische Probleme. (In dem kontreten Fall ging es um eine Einführung eines Wikis auf PHP und MySql-Basis als Grundlage für das Accounting Manual eines großen deutschen Softwareunternehmens. Der Vorschlag wurde angenommen.)
Allerdings muss ich Michael Recht geben: 99% der Open Source Software ist _lausig_ dokumentiert, wenn überhaupt. Viel zu oft lautet die Antwort auf die Frage nach einer Doku: „Wir haben ein Mailinglistenarchiv.“.
Die oft „lausige“ Dokumentation ist ja nicht nur ein Problem, sondern auch ein Markt. Ich arbeite seit vielen Jahren ausschließlich mit Open Source Produkten und verdiene mein Geld mit dem Know How über Tomcat, JBoss, Maven, Struts …
Was gerade die Jakarta-Produkte angeht ist der Quelltext oft vorbildlich und gut dokumentiert und außerdem sehr gut mit JUnit-Tests abgedeckt. Die JUnit-Tests sind dann oft die Anwenderdokumentation aber da sieht man ja dann auch, wie es geht.
Ein entscheidendes Argument für Open Source: Die Entwickler entscheiden, wann ein Release ausgerollt wird und nicht Manager oder Kunden. Das macht dann oft das Stück „mehr Qualität“ aus, zumindestens im Jakarta Umfeld.