Open Ttt Cb 2006 11 09

Open Source in der Praxis

Entwicklungsmodelle
Geschäftsmodelle

24.10.06 © 2006 1
http://www.boettger-consulting.de/

Warum Open Source?
● Geringe Kosten
● Keine Lizenzkosten, beliebig oft installierbar
● Hohe Produktivität
●
Unabhängigkeit vom Hersteller
● Wartung und Entwicklung nicht nur durch
den Hersteller
●
Ständige Weiterentwicklung des Produkts

24.10.06 © 2006 2

Warum Open Source?
● Anpassbar
– an eigene Bedürfnisse und an bestehende Software
– erweiterbar
● Hohe Stabilität
● Kontrollmöglichkeit
– Source Code vorhanden,
– dadurch unabhängige Kontrolle möglich

24.10.06 © 2006 3

Warum Open Source?
●
Support auch durch große Entwicklergemeinde
● gegenseitiges Profitieren von Bugfixes und
Erweiterungen
●
schnelle Hilfe möglich
● schnelle Weiterentwicklung

24.10.06 © 2006 4

Beispiele
● OpenOffice.org ● GIMP (Grafik)
● Linux – auch auf dem ● FreeMind, Dia
Desktop ● Thunderbird
● Apache Webserver ●
Firefox
● Samba Fileserver ● Asterisk PBX
● phpGroupWare, E- ● Eclipse
GroupWare,
OpenGroupware, ● Subversion / CVS
Kolab, ... ●
...
24.10.06 © 2006 5

Entwicklungsmodelle
●
Community-getriebene Projekte
– aus persönlichem Interesse der Entwickler
– oft Freiberufler oder Entwicklung in der Freizeit
● Getrieben von Firmengruppen und Stiftungen
– meist mehrere, teils große Firmen stellen Geld und
Arbeitszeit für Projekte zur Verfügung
● Getragen von einer einzelnen Firma
– oft ehemals proprietäre Software, die frei gegeben
wurde
24.10.06 © 2006 6

Projekte

24.10.06 © 2006 7

Entwicklungsmodelle
●
Community-getriebene Projekte
– Debian, phpGroupWare
● Getrieben von Firmengruppen und Stiftungen
– Apache Foundation
●
Getragen von einer einzelnen Firma
– OpenGroupware.org
– MySQL
– Funambol (sync4j)
24.10.06 © 2006 8

Entwicklungsmodelle
●
Projektablauf
– individuell bei den Projekten verschieden
– Zugang zum zentralen Quellcode-Repository meist
öffentlich für lesenden Zugriff
– schreibender Zugriff nur für eingetragene
Entwickler oder (bei von Firmen kontrollierten
Projekten) Firmenangestellten
– Qualitätskontrolle unterschiedlich
● von „erst gründlich testen“ bis zu „einfach
ausprobieren“
24.10.06 © 2006 9

Entwicklungsmodelle
●
Eigene Erweiterungen
– lokal in einer eigenen Kopie des Quellcodes
●
Problem bei Weiterentwicklungen im Hauptprojekt
– als Patches an das Hauptprojekt einreichen und
hoffen, dass es übernommen wird
– selbst Teilnehmer des Projekts werden (falls man
aufgenommen wird)
– entsprechende Entwicklung im Hauptprojekt
bezahlen (falls es entsprechende Modelle gibt)

24.10.06 © 2006 10

Kooperationsmodelle
●
Gemeinsam Entwicklungskosten tragen
– nur einen Teil bezahlen, aber alles nutzen
– erfordert Zeit und breites Interesse an dem
Problem
● Entwicklung direkt bezahlen
– entweder durch Zahlung an das Projekt
– oder durch Beauftragung eines Entwicklers aus
dem Projekt
– oder durch Einbringen von Arbeitsleistung
24.10.06 © 2006 11

Kooperationsmodelle
●
Gegenseitiger Support
– Mailinglisten, Foren, Wiki, ...
– eigene Erfahrungen helfen anderen und umgekehrt
● Sponsorship
– allgemeine Unterstützung für das Projekt, nicht
auf einen Auftrag bezogen
● Mitarbeit bei Dokumentation,
Qualitätssicherung, Organisation, ...

24.10.06 © 2006 12

Geschäftsmodelle
●
Bezahlte Entwicklung von Erweiterungen
– innerhalb des Projekts oder lokal/unabhängig
● Kostenpflichtige, proprietäre Zusatzprodukte
● Update-Service und Support
● Consulting & Beratung
● Betriebsdienstleistungen, Schulungen,
Workshops
● Bücher und Journalismus
24.10.06 © 2006 13

Praktische Durchführung
●
Eigene Beteiligung am ausgewählten Projekt
– direkter Draht
– zeitaufwändig
● Beauftragung eines lokalen Partners
– nur ein Ansprechpartner für alle Projekte
– direkter Support
– nur indirekte Einbindung in die eigentlichen
Projekte

24.10.06 © 2006 14

Wer die Wahl hat ...
● SourceForge.net
– 132.401 Projekte, 1.419.355 Nutzer (22.10.2006)
●
Savannah.gnu.org
– 2.669 Projekte, 45.742 Nutzer (22.10.2006)
● tigris.org
– 968 Projekte (22.10.2006)
●
www.berliOS.de
– 4.711 Projekte, 27.255 Nutzer (22.10.2006)
● weitere Portale und Communities
● sehr viele einzeln gehostete Projekte
24.10.06 © 2006 15

... hat die Qual
● Suche nach geeigneten Projekten
● in den einzelnen Portalen
– nur dort beheimatete Projekte werden gefunden
●
mit Google & Co
– nicht nur Projekte, sondern noch Anderes wird
gefunden
● bei freshmeat
– nur dort freiwillig registrierte Projekte werden
gefunden, derzeit (nur) 41.683 Projekte (22.10.2006)
24.10.06 © 2006 16

Welches Projekt ist geeignet?
● Features: alle nötigen und keine überflüssigen
● Qualität (Code / Datenbankdesign)
– Wartbarkeit, Skalierbarkeit, Sicherheit
– bekannte Bugs
● Security, Einbindung in vorhandene Infrastruktur
●
Ergonomie (bei GUI Anwendungen)
●
“Lebendigkeit“
– Updates, Releases, Zahl der Entwickler

24.10.06 © 2006 17

„weiche“ Faktoren
● „Politik“ des Projekts
– verwendete Lizenzen
– Kommunikation mit den Entwicklern
● Es gibt sehr offene und sehr geschlossene
Projektmentalitäten...
– Rückfluss von selbst geschriebenen Modifikationen
- einige Projekte mögen das gar nicht...
– Reaktion auf Bugreports
●
Welchen der vielen Forks des gleichen Grundprojekts
nimmt man?
24.10.06 © 2006 18

Vergleiche und wähle weise
● Selber schlau machen
– kostet Zeit
– nur für erfahrene Nutzer
● Mediator-Plattformen wie BerliOS nutzen
– kostet auch Zeit, begrenzte Auswahl
●
Hilfe in Anspruch nehmen
– Open Source Broker, Kooperationsprojekte
●
kostet wenig Zeit, aber etwas Geld

24.10.06 © 2006 19

Open Source Broker
● findet und bewertet geeignete Projekte
● vermittelt zwischen Community und kommerziellem
Anwender
● bündelt Wünsche des Kunden / Anwenders und
Informationen aus den Projekten
● bietet Kunden einen „single point of communication“
auch für mehrere bzw. viele Projekte
● übersetzt Kundenanforderungen in „Projektsprache“

24.10.06 © 2006 20

Open Source Broker
● Monitoring
● Überwachung auf Bugfixes, Security Fixes und neue
Features
● Re-packaging für die Umgebung des Kunden
●
Kommunikation mit den Projekten:
– Bugreports, Bugfixing, Erweiterungen, Patch
submission, Feedback in beide Richtungen
●
Kunde / Anwender braucht nur einen
Ansprechpartner für viele eingesetzte Projekte

24.10.06 © 2006 21

Open Source Broker

Die einzelnen Dienstleistungen existieren natürlich schon am Markt.
Allerdings werden sie meist “nebenbei” erbracht und nicht als
Schwerpunkt angeboten, oft auch nicht unabhängig, sondern nur für die
eigenen Lieblingsprojekte.
Wenn sich Open Source bei der Anwendungssoftware weiter durchsetzen
soll, sind unabhängige Bewertungen und Beratungen unerlässlich – sonst
bleiben das Märchen vom „nicht vorhandenen Support“ und das
„Bombenleger-Image“ weiter bestimmend für die Wahrnehmung.
Bisherige Ansätze (LIVE, LiSoG, OSDL, ...) werden kaum wahrgenommen.

„Open Source Broker“ muss auch als praktische,
angewandte Dienstleistung verfügbar werden.

24.10.06 © 2006 22

Vielen Dank für Ihre Aufmerksamkeit!

Dr. Christian Böttger
IT-Beratung & Projektmanagement
C.Boettger@Boettger-Consulting.de
Tel.: +49.5173.9249744
Fax: +49.5173.925769

24.10.06 © 2006 24

Open Ttt Cb 2006 11 09

Weitere ähnliche Inhalte

Andere mochten auch

Ähnlich wie Open Ttt Cb 2006 11 09

Mehr von bofh42

Open Ttt Cb 2006 11 09