Gratis-Online-Buch von Frank Obels

Transkript

1 Die Dinge sind nie so, wie sie sind. Sie sind immer das, was man aus ihnen macht. Jean Anouilh Gratis-Online-Buch von Frank Obels (Copyright 2003 Frank Obels, Online-Version Copyright Frank Obels) Version: 0.1 Kostenloses Gratisexemplar überreicht durch: Seligenstädter Str. 100 D Karlstein FreeCall:

2 Gratisdokument von Was Sie unbedingt wissen müssen zur Online-Version dieses Buches Sehr geehrte Damen und Herren, verehrte Internetsurfer, Das Buch, das Sie gleich zu lesen beginnen, ist die erste Pre-Release-Version des gleichnamigen Fachbuchs von Frank Obels, das im Oktober 2003 erscheinen wird. INCONET veröffentlicht diese early book version, um Anregungen und Wünsche der Leser optimal berücksichtigen zu können. Insofern befindet sich dieses Buch erst am Anfang seines Weges und Sie haben die Chance, diesen Weg mitzugestalten. Ein gewisser Herr Eric S. Raymond hat unsere Vorgehensweise in die passenden Worte gefasst: Release early - Release often - And listen to your customers. Die Frage, die man uns im Vorfeld der Buchankündigung immer wieder gestellt hat, lautet: «ist es wirklich nötig, ein Projekthandbuch für Linux zu schreiben?» Wir haben diese Frage direkt an den Autor weitergegeben und hier ist seine erstaunliche Antwort: «Nein, wenn Sie einen gestandenen Projektmanager vor sich haben, so wird dieser mit jedem Projekt glücklich werden auch wenn die Vorzeichen auf Linux stehen. Dieses Buch ist aber nicht für Profis geschrieben, sondern für die vielen Menschen, die eine nichttechnische Betrachtung des Themas Linux benötigen. Bis zum heutigen Tag können viel zu wenig Menschen etwas mit dem Thema Linux anfangen. Gleichzeitig nimmt die Zahl der Linux-Projekte zu und immer wieder rufen mich Kollegen an, die zu plötzlichen Projektleiterehren im Linux-Umfeld gekommen sind, wo sie denn entsprechende Informationen finden könnten. Für diese Menschen ist dieses Buch geschrieben. Linux ist etwas Neues und damit für IT-Verantwortliche und ihre Manager auch etwas Unheimliches das ist die emotionale Komponente der Wahrnehmungen aus der Praxis. Linux wird selten in einem Unternehmen eingeführt, weil man es rundherum mag, sondern weil es andere auch machen, weil man Geld sparen will und sich noch eine Reihe weiterer Vorteile verspricht. Aber es sind ausgewachsene Sorgen vorhanden, weil man noch immer das Freak-Image von Linux im Hinterkopf hat und nicht einmal weiß, was denn da für Menschentypen auf einen zukommen, die sich Linux-Spezialisten nennen. Dieses Buch will einen Einblick geben, was es mit Open Source und den Themen darum herum auf sich hat und was dies für den Projektverlauf bedeuten kann. Mehr will dieses Buch gar nicht vermitteln, und wenn die Leser schließlich zu dem Ergebnis kommen, dass das Thema ja gar nicht so wild ist, dann ist wieder ein Stückchen der Sorge vor dem Unbekannten gewichen. Dies ist das Anliegen der nachfolgenden Seiten: an der einen oder anderen Stelle eine Hilfe zu sein. Seite 2

3 Version 0.1 Linux-Projekte erfolgreich managen Die Botschaft an die Leserinnen und Leser ist daher auch denkbar einfach: Entnehmen Sie diesem Buch das, was Ihnen wichtig erscheint. Und den Rest lassen Sie einfach als Zeitdokument stehen!» Danke an den Autor und Ihnen nunmehr viel Spaß mit seinen Ausführungen. Wenn Sie einen Kommentar über dieses kleine E-Book loswerden möchten, dann freuen wir uns, ist dieser Kommentar auch noch konstruktiver Natur, dann freuen wir uns sehr. Karlstein, im August 2003 Seite 3

4 Gratisdokument von Linux-Projekte erfolgreich managen! Projektmanagementleitfaden für Einsteiger Autor: Frank Obels Version: 0.1 Seite 4

5 Version 0.1 Linux-Projekte erfolgreich managen Der Inhalt [0] Vorwort [1] Einleitung [2] Linux-Software für den Unternehmenseinsatz [3] Erfolgreiches Projektmanagement Hinweis Soweit in diesem Buch personenbezogene Begriffe verwendet werden, kommt diesen ausdrücklich keine geschlechtsspezifische Bedeutung zu. Zur einfacheren Lesbarkeit wurde eine diesbezügliche Ungenauigkeit akzeptiert. Seite 5

6 Gratisdokument von Inhaltsverzeichnis 0Vorwort Für wen ist dieses Buch? Warum noch ein Buch über Projektmanagement? Zielsetzung dieses Buches Was dieses Buch nicht ist Aufbau dieses Buches Einleitung Die gute Nachricht vorneweg Projektmanagement in Linux-Zeiten Open Source-Software Die Geschichte von Open Source-Software Die Open Source-Kriterien Ein Paradigmenwechsel vollzieht sich Wie entsteht ein Open Source-Projekt wer leitet es? Zehn Mythen über Open Source Software Hintergründe zu Linux Das Für und Wider von Open Source-Software Vorteile von Open-Source Schwächen und Probleme Die Kosten von Open Source-Software Linux-Anmerkungen mit auf den Weg Der Sprung ins kalte Wasser Linux-Software für den Unternehmenseinsatz Linux-Distributionen Die großen und bekannten Allround-Distributionen Derivatdistributionen Spezialdistributionen Open Source-Software für die Projektdurchführung Eine neue Dienstleistung: Open Source Software Scout Freie Software zur internen Projektdurchführung Der Open Source Software-Auswahl-Prozess ASP-Lösungen für das Projekt Open Source Alternativen zu kommerziellen Applikationen Finanzbuchhaltung für kleine Unternehmen Customer Relationship Management Enterprise Resource Planning Software für den Server Konkurrenz für den Microsoft Exchange Server Webserver Datenbankserver Samba-Server Sonstige Server-Software Seite 6

7 Version 0.1 Linux-Projekte erfolgreich managen 2.5Software für den Desktop SuSE Linux Desktop-Produkte Office-Pakete Mail-Clients Webbrowser Thin Clients als Desktop-Alternative Emulationssoftware zur Integration von Spezialanwendungen Integration von DOS-Anwendungen Virtueller PC Software für die Kleinigkeiten Organizer und PDA Handies Erfolgreiches Projektmanagement Die Grundlagen Einführung in das Projektmanagement Projektphasen und -verlauf Projektorganisation Typische Rollen im Linux-Projekt Projektumwelt und umfeld Projektmanagementprozess Warum scheitern Projekte Vorprojektphase Projektinitiierung Grobplanung Projektentscheidung Projektdefinition Design der Projektorganisation Das Kick-off Meeting Definition der Projektziele Der Projektauftrag Projektplanung Projektstrukturplan (PSP) Methoden der PSP-Erstellung Prinzipien der PSP-Erstellung Arbeitspaketspezifikation Meilensteine Terminplanung Aufwandsschätzung und Ressourcenplanung Kostenplanung Kommunikationsplanung und -management Risikoplanung und -analyse Qualitätsplanung Projektdurchführung Was es bei der Projektdurchführung zu tun gibt Durchführungs- und Erfolgskontrolle Projektstatusbericht Projektabschluss Vorbereitung des Projektabschlusses Die Übergabe als Projektabschluss Off topic: Das Optimierungsprojekt Seite 7

8 Gratisdokument von 3.7Praxis-Empfehlungen für Projektmanager Die Top 20-Erfolgsregeln Umgang mit diffusen Vorstellungen Entscheidungen werden nicht getroffen Alltagshilfen zum Schluss Und nun setzen Sie Ihr Wissen um! Besondere Tipps für Frischgebackene! Die Strategie für den Erfahrenen! Und schließlich dies noch! Seite 8

9 Version 0.1 Linux-Projekte erfolgreich managen 0 Vorwort Der wahre Zweck eines Buches ist, den Geist hinterrücks zum eigenen Denken zu verleiten. Marie von Ebner-Eschenbach Projekte werden häufig als etwas Unheimliches oder Unabwendbares angesehen, dem ein Unternehmen, ein Projektauftraggeber, ein Projektleiter oder jedes einzelne Mitglied des Projektteams völlig hilflos ausgeliefert sind. Zu dieser ohnehin nicht sehr positiven Wahrnehmung gesellt sich nun das IT-Phänomen Linux. Kaum ein Thema war in der IT-Geschichte so sehr mit Mythen, freien Erfindungen, Vorurteilen, Unkenntnis und Ängsten verbunden. «Niemand mit gesundem Menschenverstand reißt sich um ein Linux-Projekt, für das es noch keine Erfahrungswerte aus ähnlichen Projekten gibt», so die einhellige Meinung meiner Kollegen. Das Anliegen dieses Buches ist es, dem Einsteiger in die Thematik Projektmanagement, sowie dem Projektmanager, der sich freuen darf, bald die Verantwortung für ein LinuxProjekt zu übernehmen, eine Praxishilfe zu sein. Viele Publikationen zum Thema Linux drängen derzeit auf den Markt. Es sollte Linux also bald gelingen, das Image des Unbekannten abzulegen. Interessant wird sich die Frage gestalten, was sich in einigen Jahren hinter dem Begriff Linux verbergen wird. Immer noch ein freies Betriebssystem? Werden die Rechte an Linux von einem Unternehmen erworben und wird somit aus Linux eine proprietäre Angelegenheit? Seite 9

10 Gratisdokument von Für wen ist dieses Buch? Dieses Werk ist ein Leitfaden für alle diejenigen, die sich zum einen für Projektmanagement interessieren und zum anderen die Besonderheiten eines LinuxProjekts kennen lernen möchten. Die typischen Leser dieses Buches werden sein: Projektleiter, Teilprojektleiter und interessierte Projektteammitglieder Führungskräfte und Vorgesetzte von Projektleitern Projektauftraggeber sowie Projektstakeholder im allgemeinen Abteilungsleiter und Manager, deren Mitarbeiter einem Projekt zugeordnet werden Trainer, die Projektmanagement unterrichten Berater und Spezialisten, die im Projektmanagementkontext Dienstleistungen erbringen. Dieses Buch ist weder vollständig noch all umfassend und ist auch kein Projekthandbuch im strengen Sinne der Definition. Es stützt sich auf meine Erfahrungen aus nunmehr dreizehn Jahren Projektmanagement und möchte diese, zusammen mit den wertvollen Erkenntnissen aus drei umfassenden Linux-Projekten, an Sie weitergeben. Besondere Berücksichtigung finden weiterhin die typischen Fragestellungen der Teilnehmer meiner Projektmanagementseminare. 0.2 Warum noch ein Buch über Projektmanagement? Nun, das vorliegende Werk ist auch eine Einführung in das Thema Projektmanagement und derer gibt es viele das ist wahr. Aber es plaudert eben auch, bei passender Gelegenheit, aus der Linux-Projekt-Praxis. Und zu diesem Thema gibt es offensichtlich einigen Erklärungsbedarf, wenn ich die vielen Hilferufe von Unternehmern, IT-Verantwortlichen, Führungskräften und Projektmanagern recht interpretiere. Es scheint als gäbe es ausreichende Literatur zu den technischen Themen von Linux, ebenso zu IT-Projektmanagement an sich. Was aber zu fehlen scheint, ist eine nichttechnische Betrachtung von Linux, die mit Durchführungsempfehlungen für die Praxis ausgestattet ist. Dieses Buch will in diesem Bereich ein wenig Pionierarbeit leisten, damit dann schließlich Andere kommen können und es besser machen. Gelänge es, diesen Prozess anzustoßen, so wäre dem Thema Linux damit sehr geholfen, denn was nutzt das schönste IT-System ohne eine entsprechende Lobby. Ist schon das Thema Projektmanagement anspruchsvoll genug, weil es sich überwiegend auf der nicht-handwerklichen Ebene abspielt, so scheint der Projektmanager-Nachwuchs obendrein erhebliche Schwierigkeiten mit dem Menschenbild Open-Source-Entwickler zu haben. Und jeder echte Linux-Fan identifiziert sich mit dieser Gattung Mensch. Seite 10

11 Version 0.1 Linux-Projekte erfolgreich managen Die Erwartungshaltung des höheren Managements gegenüber Linux scheint dem zukünftigen Projektleiter ebenfalls erschwerend entgegenzuwirken. Kurzum, Anfänger und gestandene Profis haben offensichtlich einige Mentalprobleme mit dem Thema Linux. Dies ist jedoch völlig unnötig, wie ich Ihnen aus mehreren kleinen und den drei großen Linux-Projekten berichten darf. Womit ich mein Buch bereits beenden könnte, denn das Wesentliche ist gesagt. «Die Botschaft hör ich wohl, allein, mir fehlt der Glaube», so ungefähr lauten die Reaktionen, wenn ich Kollegen von der einfachen Migration auf Linux berichte. Also habe ich mich entschlossen, mich hinzusetzen und einige, mir wesentlich erscheinende, Aspekte zu diesem Thema niederzuschreiben. 0.3 Zielsetzung dieses Buches Dieses Buch stellt in erster Linie ein Praxiswerk im Bereich Projektmanagement dar, mit dem Fokus auf Besonderheiten in der Linux-Projektarbeit. Konzipiert als unterhaltsamer, und in lockerer Ausdrucksweise geschriebener, Praxisleitfaden, behandelt dieses Werk eine erhebliche Themenbreite, von den Eigenarten der Linux-Welt bis hin zum optimalen Projektverlauf. Nach meinen Erfahrungen wird das hier vorgestellte Themenspektrum von einem Projektleiter im IT- und insbesondere Linux-Umfeld gefordert sein. Dieses Buch will Sie dabei unterstützen, dass Sie mit dem Geforderten nicht überfordert sind! Egal, ob Sie Manager in der Linie oder Projektleiter sind, Sie werden nach der Lektüre dieses Buches die Praxis-Optionen von Linux-Projekten verstanden haben. Die übrigens gar nicht so bedeutend sind, wie von manchem Berater immer wieder gerne postuliert. Nach dem gründlichen Durcharbeiten der folgenden 157 Seiten (das nennt man Motivation!) werden Sie sich gut vorbereitet fühlen, ein Linux-Projekt erfolgreich anzugehen. 0.4 Was dieses Buch nicht ist Dieser Abschnitt wendet sich an diejenigen Kritiker, die gerne durch vernichtende Kommentare ihr Selbstwertgefühl anheben und ihren Kompetenzanspruch unterstreichen wollen. Seite 11

12 Gratisdokument von Zunächst zu dem gerne vorgebrachten Argument, dass der Inhalt nicht halte, was der Titel verspricht. Um dies zu vermeiden, steht Ihnen bereits das erste Pre-Release dieses Buches zum kostenlosen Download zur Verfügung. Niemand muss also die Katze im Sack kaufen. Dieses Buch ist auch kein Lehrbuch, derer gibt es reichlich! Klappen Sie dieses Buch bitte auf der Stelle wieder zu, wenn Sie ein fertiges Kochbuch zum Thema Linux-Projektmanagement erwarten. Dieses Buch gibt Ihnen Hinweise auf die Projektpraxis eines Linux-Vorhabens. Doch schon allein der Begriff Linux-Projekt ist als Allgemeinbegriff schwer zu greifen. Was ist ein Linux-Projekt? Eine Server-Migration? Eine Desktop-Migration? Ein Umbau auf Parallelbetrieb? Der Aufbau eines Linux-Clusters, zum Anbau an Mainframes oder Midrange-Systeme? Softwareentwicklung? Web-Development? Dieses Buch ist keine Handlungsempfehlung, sondern eine Denkempfehlung, versehen mit den notwendigen Informationen. Eine gehirnschonende Nachmach-Studie stellt dieses Buch nicht dar! 0.5 Aufbau dieses Buches Lassen Sie uns einen Blick auf den Aufbau und die Gliederung dieses Buches werfen. Kapitel 1 (Einleitung) ist eine Einführung in die Thematik Open Source. Es gibt derart viele Ansichten und Glaubenssätze zum Thema Open Source und Linux, die Ihnen ganz oder teilweise in Ihrem Projekt begegnen werden, dass Sie in der Lage sein sollten, diesen fundiert zu begegnen. Gerade weil der Großteil eines Projektes im unsichtbaren psychosozialen Bereich verläuft, werden Ihnen die Erkenntnisse aus diesem Kapitel eine gute Unterstützung bieten. Kapitel 2 (Linux-Software für den Unternehmenseinsatz) möchte dem Linux-Unbedarften einmal aufzeigen, was es denn alles an Open-Source-Software rund um das Thema Linux gibt. Wenn Sie in einem Projekt beurteilen müssen, ob ein kommerzielles Softwareprodukt durch ein freies ersetzt werden kann, erhalten Sie in diesem Kapitel wertvolle Hinweise. Kapitel 3 (Erfolgreiches Projektmanagement) ist eine Reise durch die Projektmanagementlehre. Es werden die wichtigen Themen für ein Linux-Projekt aufgegriffen. Diese Lehrreise wird durch zahlreiche Praxistipps aufgelockert und werden Ihnen viele Anregungen für Ihr Projekt geben. Nun wünsche ich Ihnen einen ordentlichen Lesegenuss und viel Erfolg in Ihrer Projektarbeit. Frank Obels Seite 12

13 Version 0.1 Linux-Projekte erfolgreich managen 1 Einleitung Alles Fertige wird angestaunt, alles Werdende wird unterschätzt. Friedrich Nietzsche 1.1 Die gute Nachricht vorneweg Allein die Tatsache, dass es Linux heute mit einer gewissen Marktbedeutung gibt, hat den bestehenden IT-Markt ordentlich in Bewegung gebracht. IT-Entscheider und Unternehmer sind aus ihrer Lethargie erwacht und stellen plötzlich fest, dass Software-Monokulturen kein Naturgesetz oder Schicksal sein müssen, dem man sich klaglos unterordnen muss. Linux und Open Source-Software stellen eine Alternative zu Etabliertem dar. Überall wird heute über Linux diskutiert. Die Offenlegung von Quellcodes, also den Bauplänen und Konstruktionsunterlagen der Software, gibt dem kundigen IT-Verantwortlichen die Möglichkeit der Prüfung auf die eigenen Ansprüche, ebenso wie die Anpassungsmöglichkeit an spezifische Bedürfnisse. Es ist ein gutes Gefühl, eine solche Möglichkeit zu haben, genutzt wird sie im Regelfall selten. IT-Managern steht es frei, sich gegen Linux zu entscheiden, wenn es nicht den Ansprüchen einer Unternehmens-IT entspricht das scheint die Mediendiskussion zeitweise zu übersehen. Man muss sich nicht für Linux entscheiden niemand zwingt einen. Doch seit die Europäische Union die Empfehlung ausgesprochen hat, bevorzugt Open Source Software einzusetzen, seit die Stadt München sich uneingeschränkt für Linux ausgesprochen hat, wird immer mehr Zweiflern bewusst, dass es wohl bei Open Source doch nicht nur um Spielzeuge begeisterter Informatik-Menschen geht, sondern um Systeme von Profis für den professionellen Einsatz. Seite 13

14 Gratisdokument von Die gute Nachricht lautet noch immer, dass niemand sich einfach so für Open SourceSoftware entscheiden muss. Doch wenn eine Entscheidung für Linux & Co. gefallen ist, erwartet das Unternehmen und seine Verantwortlichen viel Neues und Spannendes. Bleibt noch die gute Nachricht für angehende Projektmanager im Linux-Umfeld zu erwähnen: vor Ihnen liegt ein Buch, das Sie von der Projektseite her an das Thema Open SourceSoftware heranführen möchte, und Ihnen zeigen kann, wie Sie ein Linux-Projekt, einfach und erfolgreich, dem (hoffentlich) definierten Ziel entgegenführen. 1.2 Projektmanagement in Linux-Zeiten Glaubt man den Medien, Befragungsinstituten, Herstellern, Distributoren, Messebesuchern und Anwendern dann unterliegt Linux einer ständig wachsenden Verbreitung. Für viele IT-Verantwortliche im Unternehmen stellt Linux etwas Neues dar, der Umgang mit diesem Neuen erscheint unsicherer als sonst. Paart man diese Unsicherheit mit dem ohnehin allzu oft nur rudimentär vorhandenen Projektmanagement-Know-how der Fachabteilungen, so erhält man die optimale Mixtur für eine erfolglose Linux-Migration. Wer heute als Projektmanager in der Verantwortung für ein Linux-Projekt steht, muss die teilweise grenzenlos erscheinenden Möglichkeiten von Linux kennen und sie in seine Strategieüberlegungen mit einbeziehen. Dabei gilt es Mythen von Tatsachen zu unterscheiden, das Für und Wider von Open Source-Software zu kennen und sich bewusst zu machen, dass gerade hinsichtlich der Projektpsychologie neue Spielregeln zu erlernen sind. Ganz zufällig hat die Zunft der Persönlichkeitstrainer, im richtigen Moment, das Fehlen einer wichtigen Führungsqualität bei vielen (Projekt-)Managern klar erkannt. Das Zauberwort nennt sich Emotionale Intelligenz. Und so konnte ich kürzlich lesen, dass mit dem bisherigen Repertoire an eingefahrenem Denken eines altbewährten Projektmanagers ein anspruchsvolles Linux-Projekt nicht zu bewältigen sei. Ich hatte weder in meinen Projekten, noch in meinen Vorträgen und Seminaren den Eindruck, dass Projektmanager ein eingefahrenes Denken auszeichnet. Also interpretiere ich den Zeitungsbeitrag dahingehend, dass ein neues Zusatzdenken, im Sinne einer Horizonterweiterung, sicherlich bei einem Linux-Projekt nichts schadet. Also lassen Sie uns dieses Zusatzdenken nunmehr gemeinsam entwickeln. Beginnen möchte ich mit der wichtigsten Open Source-Philosophie: Open Source-Software wird von ihren Entwicklern als Gemeingut betrachtet. Dies sollten Sie vor Ihrem nächsten Projekt verstanden haben. Seite 14

15 Version 0.1 Linux-Projekte erfolgreich managen Lassen Sie uns an dieser Stelle auch gleich klären, was sich hinter diesem Begriff Source, auch Sourcecode oder Quellcode genannt, verbirgt: Computerprogramme sind eigentlich Textdateien, so wie ein Brief beispielsweise. Nur schreibt der Programmierer in diesem Falle nicht einem Menschen, sondern der Hardware (dem Prozessor) eines Computers. Er benutzt dazu eine klar strukturierte Sprache, die aus Befehlen besteht. Diese Befehle schreibt er einen nach dem anderen auf und der Computer wird diese später brav ausführen. Eine solche Liste (Datei) von Befehlen nennt sich Programm und wenn dieses noch unverändert vorliegt, kann jeder, der die Programmierbefehle versteht, die Befehlsabläufe einsehen und ändern. Da der Computer aber keine Textdateien interpretieren kann, muss man ihm diese Befehlsansammlung in ein anderes Format (die sogenannte Maschinensprache) übersetzen. Der Nachteil dabei ist, dass jetzt niemand mehr (außer dem Computer) diese umgewandelte Datei verstehen (oder einsehen) kann, denn sie besteht nur noch aus Binärzeichen. 1.3 Open Source-Software Jeder (auch die Microsoft Corporation, Redmond) spricht heute über Open SourceSoftware. Vorbei die Zeiten, da sich ausschließlich IT-Spezialisten für dieses Thema interessierten. Heute hat sich auch das Top-Management mit offener Software zu beschäftigen, begünstigt durch wirtschaftlich schwierigere Zeiten. Die Einsatzgebiete von Open Source Software sind groß. Sie umfassen den DesktopBereich, Server-Bereich und den Embedded-Bereich. Im Server-Bereich wird Open Source-Software als Betriebssystem (Linux), Web Server, Anwendungsserver und Datenbankserver eingesetzt. Im Desktop-Bereich erfolgt der Einsatz als Betriebssystem (Linux), Standard-Office-Anwendung, Bildbearbeitung, Datenbank, Internet-Anwendung und Entwicklungsumgebung. Doch was es mit Open Source-Software wirklich auf sich hat, ist nach wie vor für viele Menschen unklar. Deshalb wollen wir uns zunächst einmal mit einigen grundlegenden Informationen rund um die Open Source-Software beschäftigen Die Geschichte von Open Source-Software Software, man mag es kaum glauben, war einmal nur eine kostenlose Beigabe eines Hardware-Herstellers bei der Auslieferung von neuen Rechnersystemen. Die Hersteller verdienten ausschließlich über die Zahl der verkauften Boxen. Der Quellcode war für die Welt der begeisterten Programmierer frei zugänglich und damit frei einsehbar, und auf eigenes Risiko auch frei veränderbar. Seite 15

16 Gratisdokument von Mit Hilfe dieser Programmierer, die in keinem Angestelltenverhältnis zu den HardwareHerstellern stehen mussten, entstanden vor allen Dingen Anwendungsprogramme. Dies alles war bis zur Mitte der sechziger Jahre so. Dann jedoch begannen die großen Hardware-Hersteller, wie etwa IBM, eine neue Richtung einzuschlagen. Der Quellcode wurde nicht mehr zusammen mit dem Betriebssystem der Großrechner ausgeliefert. Man hatte eine neue Chance Geld zu verdienen gewittert. Da die großen Hardwareunternehmen im Laufe der Zeit in ausreichendem Maße eigene Computerspezialisten ausgebildet hatten, sah man sich in der Lage, auf die externen Entwickler verzichten zu können. Software wurde eine eigenständige Geldeinnahmequelle. Dies stellten auch viele der freien Programmierer fest, die mit der von ihnen entwickelten Software erhebliche Einkünfte erzielten. So entstand zu Beginn der siebziger Jahre das bis heute bekannte Modell, sich mit Hilfe von Lizenzverträgen, und dem damit verbundenen eingeschränkten Nutzungsrecht für den Kunden, fröhlich sprudelnde Geldquellen zu sichern. Die Weitergabe von Software war entweder stark eingeschränkt oder gänzlich verboten. Und so wurden die Quellcodes zu den bestgehütetsten Geheimnissen der neuen Unternehmergeneration. Bereits zu Beginn der achtziger Jahre gab es praktisch keine frei verfügbaren Quellprogramme mehr. Hard- und Software hatten sich längst als getrennte Industrien etabliert und Software wurde nur noch hinter hermetisch abgeriegelten Labortüren produziert. Wenn Sie zu der älteren IT-Generation meiner Leser gehören, dann spüren Sie vielleicht, gerade in diesem Moment, auch so eine ganz schwache Leere in sich, so als hätte man der Welt damals etwas endgültig weggenommen. So fühlten sich tatsächlich viele Programmierer der damaligen Zeit, Fassungslosigkeit machte sich breit. Für die Computeranwender hatte die skizzierte Entwicklung zur Folge, dass sie sich bei Programmfehlern oder Änderungswünschen nunmehr immer an den Softwarehersteller wenden mussten, der sich jeden Handschlag üppig bezahlen ließ. Und so machte sich neben Fassungslosigkeit schnell auch eine erhebliche Unzufriedenheit breit. Der wohl unzufriedenste unter ihnen war ein gewisser Richard Stallman vom renommierten MIT (Massachusetts Institute of Technology). Dieser Herr Stallman rief 1984 ein Projekt ins Leben, das sich GNU (GNU is not Unix) nannte und zum Ziel hatte, ein freies unix-artiges Betriebs-system zu schaffen. Dabei sollte GNU, in Verbindung mit einem Betriebssystem-Kern, ein komplettes Betriebssystem, viele nützliche Anwendungsprogramme und eine vollständige Software-Entwicklungsumgebung umfassen. Das Ziel Stallmans war es, die offene Zusammenarbeit von Software-Entwicklern, so wie er sie selbst es noch Ende der sechziger Jahre erlebt hatte, durch das GNU-Projekt erneut zu ermöglichen. Stallman betrachtete es als sein natürliches Recht, seine Programme mit seinen Freunden und Kollegen zu teilen. Zum Nutzen aller Computeranwender sollten Quellcodes vervielfältigt, verändert und weitergegeben werden dürfen. Seite 16

17 Version 0.1 Linux-Projekte erfolgreich managen Um seine Ideale zu bewahren und zu fördern, gründete Stallman zusammen mit Freunden 1985 die Free Software Foundation, kurz FSF. Die FSF ist heute der institutionelle Rahmen für GNU und erarbeitete ein formelles Lizenzprozedere, mit dem sich die Freiheit an der Software erhalten ließ und gleichzeitig das Urheberrecht gesichert wurde. Diese ist heute in der Version 2 von 1991 uns allen unter der Bezeichnung GNU General Public License (GPL) bekannt. Ein Anwender darf also nun, gemäß GPL, Software, die GPL-lizenziert ist, modifizieren, kopieren und verbreiten vorausgesetzt, dass seine abgeleitete Software wiederum unter der GPL veröffentlicht wird. Lizenzrestriktionen der eigenen, ursprünglichen GPLSoftware sind verboten. Stallman nennt diesen Ansatz Copyleft, als Anspielung auf das ihm so unbequeme Copyright. Bekannteste Beispiele für GPL-lizenzierte Software sind der Linux-Kernel, die Benutzeroberflächen KDE und Gnome, die gesamte GNU-Software (vom Compiler bis zum Schachprogramm) und eben auch StarOffice (Sun Microsystems, ehemals Star Division) respektive OpenOffice. Nehmen Sie an dieser Stelle bitte auch die Erfahrung mit, dass es rund um die GPL einige Abgrenzungsschwierigkeiten gibt, wie weit man den Begriff abgeleitete Software fasst. Dies fängt beim Linux-Kernel und der Abgrenzung zu Anwendungsprogrammen bereits an. Sofern Sie Rechtsanwalt sind, lächeln Sie doch bitte einen kleinen Moment und danken Sie dem Universum für Linux es wird noch einiges an Aufträgen auf Ihre Branche in punkto Open Source-Software und diesbezüglichen Rechtsfragen zukommen. Die Firma SCO versucht dies in jüngster Zeit pressewirksam zu demonstrieren. Der Begriff der freien Software führte, dank der mehrfachen Bedeutung des Wörtchens free in der englischen Sprache zu einigen Fehlinterpretationen. So wurde das Wort frei immer weniger im Sinne von Freiheit, sondern mehr im Sinne von kostenlos ausgelegt. Unternehmen mit einem grundsätzlich vorhandenen Interesse an GPL-lizenzierter Software ließen sich durch das aufkommende Freibier-Image von freier Software derart abschrecken, dass sie kein Vertrauen in eine derartige Software mehr für den Einsatz im Unternehmensumfeld hatten. Die Jahre vergingen, die Software-Branche entwickelte sich prächtig und die Firma Microsoft begann die Herrschaft über ein kleines Hardware-System, genannt PC, durch seine Software zu übernehmen. Manchmal hörte man noch etwas von freier Software, aber eher selten. Zwar hatte das GNU-Projekt mit den Jahren einen erheblichen Umfang angenommen, aber es fehlte ihm das wesentlichste Element, der Betriebssystemkern. Dieses Problem begann sich mit einer eines jungen finnischen Studenten, im ebenfalls jungen Internet zu lösen. Linus Torvalds stellte 1991 im Internet den Prototypen eines selbst entwickelten Unix-ähnlichen Betriebssystemkerns vor, nannte das Ganze Linux und bat um zahlreiche Kommentare und Verbesserungsvorschläge. Seite 17

18 Gratisdokument von Stallman sah sein Ziel erreicht. Mit dem Erscheinen von Linux war das letzte fehlende Element, der Kernel, für das GNU-System verfügbar und somit stand ein komplett freies Betriebssystem zur Verfügung. Linux erreichte in kürzester Zeit eine Beliebtheit und Verbreitung, wie sie bei freier Software bis dahin unbekannt war. Viele Benutzer entschieden sich für Linux. Mit Linux rückte die freie Software auch wieder in das Blickfeld der kommerziellen Welt. Mehr und mehr kommerzielle Software wurde auf Linux portiert, die Grenzen zwischen freier und nicht-freier Software wurden fließender. Stallman gefiel diese Entwicklung gar nicht, denn er sah mit Sorge die Beteiligung der kommerziellen Unternehmen am Phänomen Linux. Insbesondere der neue Ansatz, freie Software verkaufen zu dürfen, führte zu erheblichen Differenzen, unter anderem mit dem Software-Experten Eric Raymond. Dieser hatte die Entwicklungsmethode der Linux-Kernel-Gemeinde beleuchtet und war von der Effizienz und Wirtschaftlichkeit der offenen Softwareentwicklung begeistert schlug Raymond vor, Software mit offenem Quellcode als Open Source-Software zu bezeichnen und ein Lizenzmodell zu entwickeln, dass sich von den Einschränkungen der (kommerziellen) Nutzung befreite. Auch Linus Torvalds beteiligte sich an der Definition des neuen Open Source-Modells Die Open Source-Kriterien Wenn sich eine Software mit dem Attribut Open Source schmücken möchte, müssen die Lizenzbedingungen, unter denen diese Software veröffentlicht wird, in allen Punkten den Anforderungen der Open Source Definition entsprechen. Nachfolgend finden Sie eine Auswahl der Kriterien, die Sie für Ihr Linux-Projekt interessieren mag. Die vollständige Übersicht aller Kriterien finden Sie im Original unter Freie Weiterverbreitung Der Verkauf oder die Weitergabe der Software muss ohne Einschränkungen möglich sein. Die Lizenz der Software darf keinerlei Nutzungsgebühr verlangen. Verfügbarkeit des Quellcodes Die Software muss den Quellcode beinhalten. Die Verbreitung als Quellcode als auch in kompilierter Form muss gestattet sein. Sollte ein Teil der Software ohne Quellcode verbreitet werden, so muss der kostenlose Download via Internet möglich sein. Ein entsprechender Hinweis hat deutlich zu erfolgen. Seite 18

19 Version 0.1 Linux-Projekte erfolgreich managen Auf der Software basierende Weiterentwicklungen Basiert eine Software ursprünglich auf Open Source und möchte nun ebenfalls zu Open Source werden, so müssen die Lizenzbedingungen des zugrunde liegenden Werks übernommen werden. Keine Diskriminierung von einzelnen Personen oder Gruppen Um das Maximum aus der Open Source-Softwareentwicklung herauszuholen, müssen möglichst viele verschiedene Menschen das Recht haben, Beiträge zu Open SourceSoftware zu leisten. Daher darf niemand aus dem Verfahren ausgeschlossen werden. Keine Einschränkungen für bestimmte Anwendungsbereiche Die Lizenz der Software darf niemanden in der Nutzung der Software auf ein bestimmtes Einsatzgebiet beschränken. Sie darf beispielsweise nicht die kommerzielle Nutzung verbieten. Die Lizenz darf nicht für ein bestimmtes Produkt gelten Die zur Software gehörenden Rechte müssen unabhängig von einer bestimmten Softwaredistribution sein. Wird das Programm außerhalb einer solchen Distribution genutzt oder verbreitet, so gelten für den Benutzer dieselben Rechte, die in der Originaldistribution bestehen Ein Paradigmenwechsel vollzieht sich Wer sich auf Open Source einlässt, sollte sich auf einen Paradigmenwechsel einstellen. Open Source wird gerne als Kulturwandel in IT-Bereich bezeichnet. Es ist unbestritten, dass Open Source andersartige Geschäftsmodelle und veränderte Rechtsbeziehungen mit sich bringt. Der Konsument bekommt zunächst viele Open Source-Programme kostenlos, muss aber als Unternehmer eine völlig neue Art von Folgekosten berücksichtigen oder neue Gewährleistungsrichtlinien kennen lernen. Seite 19

20 Gratisdokument von Als Projektmenschen sollten wir uns vergegenwärtigen, dass Software, die frei verfügbar ist, eine starke Anziehungskraft ausübt. Die Reaktionen des menschlichen Umfeldes sind in zwei Grundrichtungen gespalten: bei den einen kennt die Begeisterung keine Grenzen und Open Source wird als die Lösung aller IT-Probleme angesehen bei den anderen überwiegt ein starkes Unwohlsein, da sie befürchten, auch aus Unkenntnis der Materie, ihr gesamtes Weltbild ändern zu müssen oder Schiffbruch zu erleiden. In der heutigen (wirtschaftlich schwierigen) Zeit ist die Angst vor misslungenen ITProjekten groß. In Ihrem Projekt werden Ihnen Vertreter beider Gruppen begegnen, unter Umständen mit ausgeprägter Rivalität zueinander. Beide werden Ihre Ansichten nicht nur in der Öffentlichkeit diskutieren, sondern alle möglichen Probleme sehr gerne auf Sie als Projektverantwortlichen projizieren. Hier haben Sie möglicherweise ein wenig Sprengstoff zu entschärfen und auf ausgelegte Tretminen zu achten. Erfahrungsgemäß stellt die Haltung des Top-Managements eine weitere Hürde dar. Sie sollten als Projektleiter frühzeitig klären, aus welcher Richtung der Wind bläst Wie entsteht ein Open Source-Projekt wer leitet es? Am Anfang eines Open Source-Projektes steht häufig der Ärger von Softwareentwicklern über Probleme mit einer Software oder fehlende Funktionalität. Richard Stallman wollte am MIT einen Druckertreiber dazu bringen, bei Papierstau oder ähnlichen Betriebsproblemen, eine Mitteilung an alle Benutzer im Netzwerk zu schicken, dass der Drucker momentan nicht betriebsbereit sei. Doch der Druckerhersteller verweigerte den Einblick in den Quellcode und Stallman musste einen komplett neuen, eigenentwickelten Druckertreiber nachbauen. Ich erinnere mich noch gut, wie ich unbedingt, in einem Projekt meinem Kunden eine spezielle Projektabrechnungssoftware zur Verfügung stellen wollte. Aber es gab nur schlechte Ansätze, und ausschließlich kommerzieller Natur. Also programmierten wir im Team eine solche Software mal eben selbst. Es sind diese Mangelzustände, die zumeist zur Geburt eines Open Source-Projektes führen. Ein Software-Entwickler möchte ein bestimmtes Problem lösen, das ist im Regelfall der Ausgangspunkt. Also schreibt er ein Programm und veröffentlicht bereits die ersten Versionen mitsamt Quellcode im Internet. Sofern die Lösung des Problems auch für andere interessant ist, wird er schnell Wegbegleiter finden, die die Software mitentwickeln oder aber als freiwillige Software-Tester zur Verfügung stehen. Je größer die Gemeinde, umso mehr Fehler können gefunden werden (vor allen Dingen in völlig unterschiedlichen IT-Umgebungen) und umso schneller schreitet die Entwicklung voran. Dies schließt den Funktionsumfang mit ein, denn häufig entdecken andere Softwareentwickler ihre Funktionswünsche und implementieren diese. Und das alles ohne eine Leitungsinstanz, einfach so, jeder mit jedem? Seite 20