Gestern beim GfWM-Wissensmangement-Stammtisch der Metropolregion Nürnberg:
Entweder das Thema, oder der Referent haben gestern Abend fast 30 Teilnehmer angelockt. Es ist auch wirklich spannend, was uns die verschiedenen Open Source Communities zu Zusammenarbeit, Motivation und Ergebnisorientierung vormachen. Prof. Dirk Riehle blickt auf eigene Erfahrungen als Leiter der Open Source Forschungsgruppe bei SAP zurück, und erforscht seitdem an der Friedrich Alexander Universität in Erlangen die Phänomene von Open-Source-Projekten.
Die Grundlage für Open Source-Projekte ist Open Collaboration. Das bekannteste Beispiel dafür ist Wikipedia. Open Collaboration bezeichnet die Art und Weise, wie in solchen Projekten gemeinsam gearbeitet wird. 3 Kriterien kennzeichnen diese Prozesse:
- Egalitär: Man errichtet keine Schranken, Mitmachen ist erwünscht, jeder darf mitmachen
- Meritokratisch: Entscheidungen werden auf Basis der Qualität eines Arguments gefällt. Man diskutiert es aus, das beste Argument gewinnt. Ist manchmal sehr mühsam, aber das Zugeständnis an die Freiwilligkeit.
- Selbstorganisiert: Weil Leute freiwillig kommen, ist auch die Art des Vorgehens ein auszuhandelnder Prozess. (Beispiel: Prozesse des Umgangs in Wikipedia). Damit ist aber auch jedes Open Source Projekt anders. Die Prozesse passen dann aber auch sehr gut auf diese Personen, mit dem Nachteil, dass der Prozess dann auch von diesen Personen abhängig ist.
Das zeigt schon einen entscheidenden Unterschied zu Unternehmen: Dort werden vorab Prozesse definiert, die es dann ermöglichen, die Personen auszutauschen – wenn z.B. ein Mitarbeiter das Unternehmen verlässt, oder andere Aufgaben übernimmt. Die Entscheidungshierarchien sind gesetzt, die Mitarbeiter werden für Projekte bestimmt.
Die interessante Forschungsfrage lautet nun: Kann ein Unternehmen lernen aus den Open Source-Projekten?
Schon seit 2000 machen HP und IBM (IBM internal Open Source Bazaar) eigene Erfahrungen mit internen Open-Source-Projekten. Prof. Dirk Riehle leitete bei SAP in Kalifornien selber ein internes Open-Source-Team für Softwareentwicklung. Seine erste Erkenntnis: Allein die Nutzung des Open Source-Entwicklungstools „SourceForge“ , die alle notwendigen Tools für SW-Entwicklungsprojekte bereitstellt, ist schon eine erhebliche Aufwandsreduzierung gegenüber dem herkömmlichen Vorgehen.
Für interne Projektleiter war zunächst der Umgang mit der totalen Offenheit und Transparenz schwierig, die über Source Forge zu allen Abläufen im Projekt – und auch im Unternehmen geschaffen wird. Diese Plattform bietet ja bewusst viele Infos, die Interessierte möglichst leicht andocken lassen.
Die erste Frage der Projektleiter war dann auch immer: „Wie kann ich mein Projekt verstecken?“ Offenheit ist aber die Voraussetzung dafür, dass sich andere Entwickler für das Projekt interessieren, um dann einige Teilaufgaben daraus zu übernehmen.
Zu den 8 offiziell benannten Projekt-Entwicklern, gesellten sich im Laufe der Zeit auf diese Weise 22 weitere, die neben ihren eigenen Projekten, gewisse Zeiten – teilweise eine halbe Stunde jeden Abend – für das interne Open Source Projekt arbeiteten. Das waren Entwickler aus Nachbarabteilungen, die alle selber viel zu tun hatten. Aber irgendwie wollten sie auch an diesem Projekt beteiligt sein. Für SAP war das am Ende ein sehr großer Erfolg, weil damit schon während der Entwicklungszeit Integrationsarbeit für dieses neue Produkt ins übrige Produktportfolio geleistet wurde. Auch der Projektleiter berichtete am Ende, er habe noch nie erlebt, dass eines seiner Projekte so positiv bekannt war.
Open Source ist aber nicht gleich Open Source!
Grundsätzlich gilt es zu unterscheiden zwischen „Community Open Source“ (z.B. Linux) und „Single Vendor Open Source“ (z.B. MySQL). Bei erstem gehört das Produkt der Community, bei zweitem einem Unternehmen. Auch wenn beide Produkte als Free-Software für jedermann nutzbar angeboten werden, macht das einen Unterschied. Für Unternehmen ist so ein kostenlos angebotenes Open Source-Produkt oft die Vermarktungsstrategie für weitere ergänzende Produkte oder Leistungen. Unternehmen, die im Besitz der Eigentumsrechte sein wollen, verpflichten deshalb die Entwickler, ihnen die Eigentumsrechte am Quellcode zu übertragen. In den Community-Open-source Projekten, bleiben die Eigentumsrechte bei den einzelnen Autoren, nur die Verwertungsrechte gehen an die gesamte Gruppe von Entwicklern. Was ja auch Sinn macht, da SW-Entwicklung fast immer das ineinandergreifende Werk von vielen ist.
Mich beeindruckt die Vielzahl von erfolgreichen Open-Source-Projekten, von Firefox über WordPress bis Drupal. Dahinter stehen ja sehr viele Menschen, die meist ohne Bezahlung, in jedem Falle freiwillig, viele viele Arbeitsstunden geleistet haben, um diese Projekte erfolgreich zu machen. Es muss also noch ganz andere Motivationen geben, als wir sie in Unternehmen bisher nur sehen. Zudem muss es in diesen Projekten ja auch ein gutes Arbeitsklima geben, sonst würde man ja schnell aussteigen. Und das auch noch unter meist fremden Menschen, die in der Regel weit verteilt, ohne direkten Kontakt, gemeinsam arbeiten. Das sind in Unternehmen allein schon große Herausforderungen für Führungskräfte. Hier aber gibt es gar keine eingesetzte Führungskraft. Selbstorganisation scheint ein auch hier sehr mächtiges „Instrument“ zu sein. Es lohnt sich aus meiner Sicht auch für Unternehmen, hier näher hinzuschauen.
Einen ganz herzlichen Dank an Prof. Riehle für die interessanten Einblicke!
Vielen Dank für diesen interessanten Artikel.
In diesem Zusammenhang interessant könnte ein Video sein, in dem es um ein weiteres Modell von Open Source geht. Dabei geht es nicht um Software, sondern um die Herstellung von Autos:
http://thedolectures.co.uk/speakers/speakers-2010/jay-rogers
Die Ausführungen von Jay Rogers sind wirklich faszinierend.
Viele Grüße
Steffen Henkel