Open Source Inside

Anforderungen an Enterprise Open Source Software

nospam@example.com (Martin Aschoff) — Fri, 26 Aug 2011 08:00:00 +0200

Im EOS Directory, das die Open Source Business Foundation (deren Vorstandsmitglied ich bin) in Kürze neu aufsetzen wird, geht es nicht um Open Source Software, sondern um Enterprise Open Source Software (Enterprise OSS). Das ist zwar im Namen nur ein kleiner, in Wirklichkeit aber ein sehr großer Unterschied! Der Namenszusatz "Enterprise" bedeutet, dass die Software für den professionellen Einsatz in geschäftskritischen Bereichen eines Unternehmens geeignet sein muss. Und die aus diesem Einsatzbereich resultierenden zusätzlichen Anforderungen sind signifikant, wie die Praxis zeigt.

So beinhaltet der Einsatz einer Open Source Software in Unternehmen auf der einen Seite funktionale Anforderungen wie

Schnittstellen für die Integration in eine existierende IT-Infrastruktur

Berücksichtigung von Zeitzonen

Mandantenfähigkeit (sofern erforderlich)

eine mehrsprachige Benutzeroberfläche (sofern eine GUI vorhanden ist) mit Unterstützung verschiedener Zeichensätze

die Unterstützung älterer Browser-Versionen wie Internet Explorer 6 (für Web-Applikationen)

Auf der anderen Seite kommen nicht-funktionale Anforderungen hinzu, wie zum Beispiel

ein stabiler und nicht zu exotischer Software-Stack, der zum Betrieb der Enterprise OSS erforderlich ist (Application Server, DBMS, ESB, o.ä.)

die einfache Skalierbarkeit der Software (z.B. durch Caching, Verteilung auf mehrere Server, etc.)

die Sicherheit der Daten vor Hack-Angriffen (nicht nur von außen, sondern auch von innen

eine gute Usability, die die Bedienung der Enterprise OSS auch Gelegenheitsnutzern erlaubt (oft ein Schwachpunkt bei OSS)

Über die bloßen funktionalen und nicht-funktionalen Anforderungen hinaus haben Unternehmen oft Bedarf an zusätzlichen Dienstleistungen rund um eine Enterprise OSS, und zwar umso dringender, je geschäftskritischer die eingesetzte Software ist. So erwarten Unternehmen auf folgenden Gebieten Service-Leistungen durch externe Anbieter:

Schulung: Dokumentation, Trainingskurse, Experten-Hotline, etc.

Consulting: Workshops von der Spezifikation bis zur Implementierung, Unterstützung bei der Installation und Konfiguration der Software

Service&Support: Sicherstellung des Betriebs der Software und Beseitigung von Problemen im laufenden Betrieb

Wartung: Anpassung, Pflege und Aktualisierung der Software

Entwicklung: Umsetzung von Änderungs- und Erweiterungswünschen (und zwar so, dass diese ein Software-Update überleben und nicht neu programmiert werden müssen)

Infrastruktur-Tools: bedienungsfreundliche und zeitsparende Monitoring- und Administrations-Tools (die im Gegensatz zum Kernprodukt oft nicht Open Source sind)

Sicher ist diese Aufzählung noch nicht vollständig. Doch es ist bereits jetzt eine umfangreiche Aufstellung, die demonstriert, wie hoch die Anforderungen an eine Enterprise OSS im Vergleich zu normaler Open Source Software sind. Und meine persönliche Erfahrung zeigt, dass eine Software, die die oben genannten Punkte nicht oder nur unvollständig erfüllt, für den Einsatz in Unternehmen wenig geeignet ist.

So werben Sie für Ihre kommerziellen Open-Source-Services

nospam@example.com (Martin Aschoff) — Fri, 14 Nov 2008 08:00:00 +0100

Sie können die besten kommerziellen Services für Ihr Open-Source-Projekt anbieten - wenn diese niemand kennt, wird sie auch niemand nutzen und bezahlen. Umgekehrt vergraulen Sie die Nutzer einer Open-Source-Software, wenn Sie Ihre kommerziellen Leistungen zu penetrant anpreisen. Daher ist ein gesunder Mittelweg notwendig.

Hier ein paar Vorschläge, wo Sie dezent (zum Beispiel in Form eines Hinweises mit weiterführender Verlinkung) auf Ihre kommerziellen Services hinweisen können:

im Hilfstext bzw. Hilfsmenü Ihrer Open-Source-Software

auf der Projekt-Website (*.org) unter den Menüpunkten Support und Kontakt

in der FAQ-Datenbank als Antwort auf die Frage "Wo erhalte ich Support, wenn FAQ und Forum nicht weiterhelfen?"

im Support-Forum, wenn knifflige Fragen kommen, die sonst niemand beantwortet

im Blog zu Ihrem Open-Source-Projekt (z.B. in Beiträgen mit Case Studies und Referenzkunden)

im Footer aller E-Mails, die Ihr Unternehmen verlassen

Die Verlinkung sollte jeweils eine passende Landingpage Ihrer kommerziellen Website (*.de bzw. *.com) zum Ziel haben, auf der Sie dann unbeschränkt und ganz massiv für Ihre kommerziellen Leistungen werben können.

Applikationen integrieren mit Open Source

nospam@example.com (Martin Aschoff) — Wed, 05 Nov 2008 08:00:00 +0100

Vor einem guten Jahr habe ich Ihnen mit Jitterbit eine Open-Source-Lösung für die Integration von (Open-Source-)Applikationen vorgestellt. Während Jitterbit eine US-Entwicklung ist, existiert mit Talend Open Studio eine Open-Source-Alternative zu Jitterbit, die ihren Ursprung in Frankreich hat. Und spätestens mit der Version 3.0, die vor einigen Tagen vorgestellt wurde, hat Talend Open Studio Jitterbit hinsichtlich der Funktionalität überholt. Daher und dank reichlich Venture Capital für allerhand Marketing-Aktivitäten gewinnt Talend Open Studio in Europa derzeit rasant an Verbreitung.

Talend Open Studio ist ein leistungsfähiges ETL-Tool (Extract, Transfer, Load), wird in Java entwickelt und setzt auf Eclipse auf, so dass die prinzipielle Bedienung vielen Entwicklern bereits bekannt sein dürfte. Standardmäßig erzeugt Talend Open Studio im Backend Java-Code, optional ist aber auch Perl möglich.

Talend Open Studio bietet zahlreiche Features wie Iteratoren, Lookups/Joins, Filter, Trigger, String-Manipulationen sowie reguläre Ausdrücke und verarbeitet eine Vielzahl von Formaten - darunter nicht nur Standardformate wie CSV oder XML, sondern auch Applikations-spezifische Formate wie Excel, SugarCRM, SAP und diverse Datenbankformate. All diese Formate werden über modulare Connectoren gelesen und geschrieben. Die Dokumentation zur Software ist umfangreich, professionell gestaltet und aktuell - was man bei Open-Source-Software nicht unbedingt erwarten kann.

Die Installation erfolgt Eclipse-typisch durch Entpacken der Download-Datei in das gewünschte Verzeichnis. Anschließend empfiehlt es sich noch, ein Desktop-Symbol für die Startdatei des Open Studio anzulegen (die richtige Datei für Ihr Betriebssystem erschließt sich aus den Dateinamen). Beim ersten Start muss nur noch ein Repository definiert und ein neues Projekt erzeugt werden - fertig!

Talend Open Studio bietet gegenüber der Entwicklung von individuellen Skripten folgende Vorteile:

Die Erstellung und Darstellung der ETL-Prozesse erfolgt per grafischer Benutzeroberfläche, was die Übersichtlichkeit erhöht und Fehler reduziert

Der Talend-Codegenerator erzeugt nicht proprietären Programmcode, sondern Standard-Java-Code oder auch Perl-Code, der beliebig nachbearbeitet und verfeinert werden kann

Es existieren bereits jede Menge vordefinierter Connectoren für Datenbanken wie Microsoft SQL Server, MySQL, Oracle DBMS, PostgreSQL und Sybase sowie für CRM-Systeme wie Salesforce, SugarCRM, vTiger und Centric

Während damit für viele populäre Datenbanken und Applikationen bereits Connectoren vorhanden sind, kann man natürlich auch weitere selbst entwickeln (und ggf. der Open-Source-Community zur Verfügung stellen)

Abschließend jedoch auch noch etwas Kritik: Nervig ist, dass die Talend-Website bei jedem Download-Besuch ohne jegliche Begründung nach persönlichen Daten wie Name, E-Mail-Adresse und Telefonnummer fragt und auch darauf besteht, dass alle Felder ausgefüllt werden. Natürlich kann man hier Nonsens-Angaben machen, aber meiner Meinung widerspricht solch eine Zwangsregistrierung dem Open-Source-Gedanken von der Freiheit der Software-Nutzung.

Ebenfalls etwas störend ist die Größe der Software, die auch auf die Nutzung von Eclipse als Plattform zurückzuführen ist. So hat der Download des Prorammcodes einen Umfang von etwa 300 MByte! Als Folge aus der Mächtigkeit des Codes ist auch die Performance manchmal etwas schleppend. Der Client, auf dem mit Open Studio Projekte bearbeitet werden, sollte daher mit reichlich Arbeitsspeicher und CPU-Power ausgestattet sein (mindestens 2 GByte RAM und 2 GHz Dual Core).

Was tun, wenn das Framework stirbt?

nospam@example.com (Martin Aschoff) — Wed, 08 Oct 2008 08:00:00 +0200

Jedes größere Open-Source-Projekt basiert auf Open Source Libraries und Frameworks. Und so, wie sich Betriebssysteme, Tools und Applikationen weiterentwickeln (müssen), ist dies auch bei den zugrundeliegenden Libraries und Frameworks der Fall. Doch kann es natürlich auch einmal passieren, dass die Weiterentwicklung einer bestimmten Bibliothek oder eines Framework eingestellt wird.

Dies ist zunächst kein Problem, wenn die aktuellste Version stabil ist und keine oder nur unwesentliche Bugs aufweist. Doch die technische Entwicklung bleibt nicht stehen und eine Software-Komponente, die nicht weiter entwickelt wird, veraltet mit der Zeit. Und während sich dieser Umstand bei Closed-Source-Software elegant im nicht zugänglichen Quellcode verstecken lässt, tritt er bei Open-Source-Software für jedermann offen zutage!

Daher muss das Entwicklerteam irgendwann in den sauren Apfel beißen und das sterbende Framework durch ein lebendes, modernes Produkt ersetzen. Im Idealfall wirkt sich solch ein Wechsel nicht nur positiv auf die Architektur der Software aus, sondern macht mittelfristig die Weiterentwicklung der Software sogar einfacher und schneller.

Für Zeitpunkt und Art des Umstiegs gibt es jedoch kein Patentrezept. Stattdessen im folgenden ein Beispiel aus der Praxis:

Für unser Open-Source-Projekt OpenEMM nutzen wir unter anderem das Struts-Framework für die Umsetzung des MVC-Entwurfsmusters im Rahmen einer Web-Applikation. Das Struts-Framework war im Jahr 2000 das erste Open-Source-MVC-Framework, wird jedoch seit zwei Jahren nicht mehr nennenswert weiterentwickelt (die letzte 1.3.9-Beta ist deutlich über ein Jahr alt).

Der Struts-Gründer Craig McClanahan (derzeit bei SUN beschäftigt) hat 2004 mit JavaServer Faces (JSF) ein neues Framework gestartet, das mittlerweile als echter Java-Standard sogar im Wettbewerb zu Struts steht. Darüber hinaus sind im Laufe der Jahre mit Spring MVC, Tapestry und WebWork weitere MVC-Frameworks für Web-Applikationen entstanden, die Struts Konkurrenz machen, und teilweise moderner sind.

Und dann gibt es da natürlich noch die - eigentlich naheliegende - Alternative Struts2. Kurioserweise baut Struts2 allerdings nicht auf Struts(1) auf, sondern auf WebWork2, so dass Struts2 nicht abwärtskompatibel zu Struts ist. Damit erfordert der Wechsel von Struts auf Struts2 genauso ein Refactoring des vorhandenen Quellcodes, wie der Wechsel zu jedem anderen Web-MVC-Framework.

In unserem Fall war nach reiflicher Überlegung trotzdem Struts2 die beste Wahl als Nachfolger für Struts, denn Struts2 bietet gegenüber Struts eine ganze Reihe von Vorteilen:

Es ist viel weniger Infrastruktur-Code erforderlich, weil
1. die Devise "Convention over Configuration" gilt
2. keine FormBeans-Klassen erforderlich sind (die Setter und Getter sind direkt in den Actions und selbst das lässt sich vermeiden)
3. zahlreiche vordefinierte und -implementierte Interceptors (für Exception, I18n, Logging, etc.) und Validatoren vorhanden sind
4. die Struts2-Tags HTML-Code mit generieren können (der sich über Themes der Tag-Templates beeinflussen lässt)
Das Struts2-Framework kümmert sich automatisch um den Datentransfer (inkl. Typ-Konvertierung) zwischen Model und View

Struts2 lässt sich über existierende Plugins für Struts, Spring, Tiles, etc. konfigurationsfrei erweitern

Struts2 (*.action) lässt sich parallel zu Struts (*.do) einsetzen und erlaubt damit die Migration Schritt für Schritt

Die AJAX-Integration ist/wird durch AJAX-Plugins mit Tag-Extensions und AJAX-Templates verbessert

Andererseits sind diese Vorteile für uns nicht so spektakulär, dass sie den Zusatzaufwand für einen sofortigen Umstieg rechtfertigen. Außerdem sind die Struts2-Vorteile - wie bei jedem neuen Framework - nur nutzbar, wenn man sich im Vorfeld intensiv mit dessen Architektur und Funktionsumfang auseinandersetzt, um die neuen Features auch tatsächlich nutzen zu können.

Daher haben wir beschlossen, die Migration von Struts auf Struts2 ganz in Ruhe anzugehen, indem wir jeweils die Teilbereiche, die ohnehin grundlegend überarbeitet werden müssen, im Rahmen des Refactoring auf Struts2 migrieren. Das "alte" Struts ist zwar inzwischen zu einer Sackgasse geworden, aber es handelt sich dabei um ein solides und äußerst stabiles Framework, das bei uns zuverlässig seinen Dienst verrichtet ohne unangenehm aufzufallen. Daher besteht beim Umstieg überhaupt kein Grund zur Eile.

Einnahmequelle 6: weitere Konzepte

nospam@example.com (Martin Aschoff) — Mon, 29 Sep 2008 08:00:00 +0200

Als Abschluss meiner Serie Richtig Geld verdienen mit Open-Source habe ich fünf weitere interessante Ansätze für Einnahmequellen zusammengestellt, die bereits von dem ein oder anderen Unternehmen in der Praxis eingesetzt werden. Ich werde diese Konzepte jedoch nicht weiter kommentieren, weil ich der Meinung bin, dass die Erfolgsaussichten der verschiedenen Ideen stark abhängig von Typ und Komplexität der jeweiligen Open-Source-Software sind:

Der Entwickler einer Open-Source-Software konzentriert sich bei seinen Dienstleistungen zu Service&Support auf (wenige) Multiplikatoren wie z.B. Internet-Provider und -Hoster, Systemhäuser und -integratoren sowie Agenturen und bietet diesen einen 2nd-Level-Support an, während die Partner für ihre (vielen) Kunden den 1st-Level-Support leisten.

Bugfixes für bestimmte Versionen werden vom Entwickler einer Open-Source-Software nur die ersten 3, 6 oder 12 Monate oder bis zur Verfügbarkeit des nächsten Releases kostenlos angeboten. D.h. wer ein bestimmtes Release länger nutzen und nicht ständig updaten möchte, muss einen Wartungsvertrag abschließen, um weiterhin Bugfixes für sein Release zu erhalten.

Der Entwickler einer Open-Source-Software bietet Binärversionen des Source Codes ausschließlich gegen Gebühr im Abonnement an. Die Binärversionen werden für verschiedene (Betriebssystem-)Plattformen angeboten und der Entwickler garantiert jeweils deren Lauf- und Funktionsfähigkeit.

Zur komfortablen Verwaltung von großen Installationen einer Open-Source-Software bietet deren Entwickler bedienungsfreundliche und zeitsparende Monitoring- und Administrations-Tools an, die im Gegensatz zum Kernprodukt kostenpflichtig sind.

Dual Licensing: Steht eine Open-Source-Software unter der GPL und der Nutzer möchte sie mit kommerzieller Software kombinieren (die durch den viralen Charakter der GPL dann ebenfalls zu Open Source werden würde), kann er vom Inhaber der entsprechenden Rechte (in der Regel der Entwickler als Urheber) eine alternative Lizenz mit Nutzungs- und Verwertungsrechten für den kommerziellen Einsatz erwerben.

Abschließend ist zu sagen, dass Sie sich bei der Wahl der Geschäftsmodelle nicht auf ein einziges verlassen sollten, denn in der Regel werden von drei Konzepten ein bis zwei nicht funktionieren. Vielmehr müssen Sie von Anfang an auf mehrere Standbeine setzen, um eine stabile Basis für regelmäßige und auskömmliche Einnahmen zu schaffen.

Einnahmequelle 5: Upgrade auf kommerzielle Version

nospam@example.com (Martin Aschoff) — Thu, 25 Sep 2008 08:00:00 +0200

Mit der Einnahmequelle "Upgrade auf kommerzielle Version" verlassen wir erstmals die reine Open-Source-Lehre. Eine ganze Reihe von Open-Source-Unternehmen (die vornehmlich durch Venture Capital finanziert sind) verfolgt mittlerweile das Geschäftsmodell, die Basisversion einer Software als Open-Source-Version kostenlos zu verbreiten, um schnell und ohne große Marketing- und Vertriebskosten eine hohe Reichweite und breite Nutzerbasis aufbauen zu können.

Im zweiten Schritt wird dann den Nutzern der Open-Source-Version eine kostenpflichtige Closed-Source-Variante der Software angeboten, die attraktive Zusatz-Features bietet, damit der ein oder andere Anwender, der die Open-Source-Software schätzen gelernt hat und konkreten Nutzen daraus zieht, für den Umstieg auf die kommerzielle Version zahlt.

Die Migration der Nutzer einer Open-Source-Software auf die kommerzielle Version kann jedoch nur gelingen, wenn folgende drei Bedingungen erfüllt sind:

Die kommerzielle Software muss Zusatznutzen bieten, die zumindest für intensive Nutzer der Open-Source-Version so attraktiv sind, dass sie den Wechsel auf ein kostenpflichtiges Produkt in Betracht ziehen.

Die Bedienung der kommerziellen Version muss - soweit möglich - identisch zur Open-Source-Version sein, damit der Nutzer nicht umlernen muss und kein Einarbeitungsaufwand anfällt.

Die kommerzielle Software muss das gleiche Datenmodell verwenden, damit sich die Bestandsdaten aus der Open-Source-Version problemlos, d.h. ohne zusätzlichen (und teuren) Konvertierungsaufwand, weiternutzen lassen

Bei AGNITAS verfolgen wir mit dem OpenEMM als Basisversion des kommerziellen E-Marketing Manager (EMM) ebenfalls die beschriebene Upgrade-Strategie. Der OpenEMM ist eine ausgereifte Open-Source-Software, die alle wichtigen Funktionen für E-Mail-Marketing und Transaktionsmails abdeckt und weltweit von tausenden Nutzern regelmäßig eingesetzt wird.

Doch der EMM bietet gegenüber dem OpenEMM noch zusätzliche Premium-Features wie z.B. Mandantenfähigkeit, Auto-Optimierungen und Website-Tracking sowie den Zusatznutzen, dass er auf mehrere Server verteilt werden kann und damit bezüglich Verandgeschwindigkeit und Link-Tracking-Kapazität beliebig skalierbar ist. Damit bietet der EMM einige attraktive Vorteile, die schon manchen OpenEMM-Poweruser zum Umstieg bewegt haben. Aus eigener Erfahrung kann ich daher sagen, dass das Upgrade-Geschäftsmodell - zumindest in unserem Fall - funktioniert.

Ein paar Gedanken zu Google Chrome

nospam@example.com (Martin Aschoff) — Wed, 03 Sep 2008 14:00:00 +0200

Google Chrome beweist, dass ein Open-Source-Projekt, hinter dem ein Unternehmen steht, schneller und zielgerichteter Innovationen schaffen kann, als ein reines Community-Projekt wie Firefox, das eher die Innovationen der Wettbewerber optimiert als eigene zu schaffen und primär auf unbezahlten Freiwilligen aufbaut (übrigens im starken Kontrast zu Ex-Präsidentin Mitchell Baker, die mit über 500.000 US$ pro Jahr entlohnt wurde).

Google Chrome ist nicht bloß ein weiterer Browser um Webseiten zu betrachten, sondern nach meiner Meinung der erste brauchbare Desktop-Application-Server für Web-Applikationen. Google Chrome erlaubt es, künftig Web-Applikationen zu bauen, die sich bei Nutzung von Chrome als Browser wirklich wie Desktop-Programme verhalten. Dazu bietet Chrome folgende Eigenschaften:

Die schnelle Javascript-Engine beschleunigt AJAX-Funktionalität in die Nähe der Reaktionszeiten von Desktop-Applikationen

Das Speichermanagement, das jeden Tab als eigene Instanz verwaltet, sorgt dafür, dass eine im Browser laufende Web-Applikation beim Absturz nicht alle anderen parallel laufenden Applikationen mit sich reißt

Einzelne Tabs, in denen z.B. Web-Applikationen laufen, lassen sich aus Chrome herauslösen und als eigenständige Fenster betreiben - diese lassen sich sogar wie Desktop-Programme per Startmenü, Desktop-Icon oder Schnellstartleiste starten

Das Google-Gears-Framework ist bereits integriert, so dass sich entsprechend angepasste Web-Applikationen selbst dann (eingeschränkt) nutzen lassen, wenn gerade keine aktive Internet-Verbindung vorhanden ist

Last not least: Google Chrome sowie sämtliche Komponenten stehen unter Open-Source-Lizenzen, so dass die Nutzung und Weiterverwendung der Software weder an besonders einschränkende Bedingungen gebunden ist, noch das Produkt als Eintagsfliege zu werten ist (von der Finanzstärke Googles einmal ganz abgesehen)

Die Konsequenz: Mit Chrome kann der Browser zum Desktop-Betriebssystem der Zukunft werden, denn wenn alle Programme als Web-Applikationen im Browser laufen, kann dem Nutzer das Betriebssystem dahinter gleichgültig sein. Damit wird für Software-Anbieter und die Open-Source-Community das Entwickeln von Web-Applikationen, die gegenüber Desktop-Programmen die Vorteile der Plattform- und Standort-Unabhängigkeit bieten, noch attraktiver. Und Microsoft hat einen Grund mehr, sich wegen Google Sorgen zu machen ...

Bericht von der OSCON (Teil 3)

nospam@example.com (Martin Aschoff) — Fri, 25 Jul 2008 23:00:00 +0200

Heute ist die OSCON 2008 zu Ende gegangen. Insgesamt habe ich mir in den vergangenen Tagen genau 13 Keynotes und 13 Vorträge angehört. Die Keynotes waren von stark schwankender Qualität und hatten teilweise überhaupt nichts mit Open-Source-Software zu tun. Die Vorträge, die man sich nach Geschmack aussuchen konnte - weil bis zu 16 (!) parallel liefen - waren dagegen (für mich) durchweg interessant - auch wenn der Inhalt manchmal von Titel und Ankündigungstext der Session etwas abwich.

Besonders erwähnenswert vom letzten Tag ist die Keynote von Microsoft, einem der größten Sponsor der diesjährigen OSCON. Sam Ramji, oberster Open-Sourcler bei Microsoft, hielt seine Keynote in einem Firefox-T-Shirt (!). Während noch vor zwei Jahren zahlreiche OSCON-Teilnehmer das von Microsoft gesponsorte Mittagessen nicht anrühren wollten, wurde Sam als Microsoft-Vertreter dieses Jahr mit einem warmen Applaus empfangen.

Sam hob hervor, welche Open-Source-Projekte Microsoft unterstützt, damit sie besser mit bzw. unter Windows laufen (Linux, Samba, Mozilla Firefox, Apache Http, MySQL, PHP, Ruby, Python, Java sowie Eclipse) und versuchte mit zahlreichen konkreten Beispielen zu belegen, dass Microsoft eine aktive Rolle im Open-Source-Markt übernommen hat. Zuletzt gab er gemeinsam mit einem Apache-Vertreter bekannt, dass Microsoft offiziell Platinum Sponsor der Apache Software Foundation wird, d.h. die ASF finanziell stark unterstützen wird

Damit stellt Sam innerhalb von Microsoft den Gegenpol zu seinem obersten Chef Steve Ballmer dar, der Open-Source-Software gerne mal öffentlich verteufelt. Trotzdem kam es in der anschließenden Q&A-Session dann doch noch zu Tumult-artigen Szenen, als die Teilnehmer Themen wie Software-Patente und das OOXML-Format ansprachen, die Moderatorin angesichts der hochschwappenden Emotionen um Kontrolle ringen musste und Sam Ramji (halbherzig) versuchte, das Verhalten von Microsoft zu rechtfertigen.

Als Fazit lässt sich zur OSCON sagen, dass hier alles eine Nummer größer als in Europa und perfekt organisiert ist. Inhaltlich sind die Themen jedoch mit denen in den Europa vergleichbar, so dass ein Besuch nur aus Lernzwecken nicht lohnt, sondern allenfalls als Incentive für verdiente Open-Source-Entwickler.

Wer Entwicklerthemen aus dem Enterprise-Software-Umfeld oder gar Business-nahe Themen erwartet, wird eher enttäuscht sein. Allerdings können Entwickler direkt Kontakte zu Maintainern und Committern bekannter Open-Source-Projekte knüpfen, die in ihren Sessions auch nicht müde wurden, darauf hinzuweisen, dass sie für ihre Projekte weitere Contributors suchen.

Der inhaltliche Gleichstand von Nordamerika und Europa, der auf der OSCON deutlich geworden ist, überrascht nicht, wenn man bedenkt, dass viele weltweit wichtige Open-Source-Projekte wie Linux, MySQL, PHP, KDE oder OpenOffice ihre Wurzeln in Europa haben. Daher war auch die Zahl von Teilnehmern und Referenten aus Europa auf der OSCON nicht unbeträchtlich, während andere Kontinente praktisch keine Rolle spielten.

Ein Gebiet allerdings, auf dem Nordamerika gegenüber Europa voraus ist, ist die Akzeptanz von Open-Source-Software in großen Unternehmen und auch in sensiblen Einsatzbereichen. Aber ich denke (und hoffe), dass es nur eine Frage der Zeit ist, bis Europas Unternehmen hier nachziehen werden.

Bericht von der OSCON (Teil 2)

nospam@example.com (Martin Aschoff) — Fri, 25 Jul 2008 01:00:00 +0200

Nach zwei Tagen OSCON stelle ich fest, dass ein (etwas ansteckender) elitärer Geist durch die Vortragsräume des Kongresses weht, nach dem Motto "Die meisten Menschen verstehen gar nicht, was wir hier tun, aber wir sind dabei, die Welt zu verändern."

Ein großes Thema ist Mobile Computing bzw. die "Open Phone Platform". Nachdem der Desktop nach wie vor von Microsoft beherrscht wird (Windows) und auch der Server-Krieg gewonnen scheint (Linux), ist die Schlacht um mobile Endgeräte noch völlig offen und hat eigentlich gerade erst begonnen. Auf der einen Seite stehen die proprietären Systeme iPhone und Windows, und auf der anderen Seite die Open-Source-Systeme Android, OpenMoko und (neuerdings) Symbian - wobei meiner Meinung nach das Ressourcen-hungrige Windows auf jeden Fall schon verloren hat.

Auch das zweite große Thema aus Tim O'Reillys gestriger Keynote, die "Open Web Platform", wurde bereits von mehreren Vorträgen aufgenommen und vertieft. Für die Umsetzung dieser Plattform wurde gerade die Open Web Foundation gegründet.

Ansonsten herrschen hier Sessions zu Open-Source-Tools für Entwickler und zu den (Open-Source-)Programmiersprachen Perl, PHP, Python und Ruby vor - wobei mich der hohe Stellenwert, der Perl nach wie vor eingeräumt wird, überrascht.

Überrascht hat mich auch die Internationalität des Publikums. Allein aus den Follow-Up-Mails auf meinen Vortrag konnte ich sieben Nationalitäten identifizieren (Australien, China, Deutschland, Frankreich, Großbritannien, Italien, USA).

Darüber hinaus sind hier zahlreiche große IT-Unternehmen wie HP, IBM, Intel und auch Microsoft mit Mitarbeitern vertreten, oft auch mit einem eigenen Stand. Dadurch hat die den Kongress begleitende Austellung schon das Format einer kleinen Messe. Allerdings scheint die Standgröße der Teilnehmer nicht unbedingt mit der Bedeutung des jeweiligen Unternehmens dahinter zu korrelieren - so hat Google beispielsweise einen Ministand mit nur einem einzigen Mann als Standbesatzung.

Zum Schluss noch ein kleiner Kritikpunkt: Etwas schade finde ich, dass der Kongress auf der einen Seite thematisch etwas ausufert, auf der anderen Seite aber aus meiner Sicht wichtige Themen fehlen. So werden viele Bereiche behandelt, die nur am Rande mit Open Source zu tun haben oder gar nicht (allerdings sehr unterhaltsam aufbereitet sind). Auf der anderen Seite werden Profi-Entwicklerthemen wie Open-Source-Frameworks, innovative Entwurfsmuster und Entwicklungen rund um Java (seit kurzem ebenfalls open source) nur wenig bis gar nicht behandelt.

Bericht von der OSCON (Teil 1)

nospam@example.com (Martin Aschoff) — Thu, 24 Jul 2008 01:00:00 +0200

Zur Zeit befinde ich mich auf dem Open-Source-Kongress OSCON in Portland/USA, dem Mekka der Open-Source-Szene, und wie bereits versprochen, werde ich von hier berichten.

Während Montag und Dienstag nur einige halbtägige Tutorials stattgefunden haben, ist die OSCON heute mit den Keynotes und über 400 Sessions richtig gestartett. Den Auftakt bildeten eine etwas pathetische Begrüßung durch den Veranstalter sowie die erste Keynote von Gründer Tim O'Reilly. Er startete angesichts des 10. Geburtstag der OSCON mit einem historischen Rückblick, zeigte dann, dass in immer mehr Stellenausschreibungen Kenntnisse von Open-Source-Produkten gefordert werden (interessanterweise mit dem größten Wachstum bei Unternehmens-Applikationen), gefolgt von der Vorstellung aktueller Trends wie Cloud Computing. Zuletzt forderte er die anwesenden Entwickler auf, an einer Open Web Platform und einer Open Phone Platform zu arbeiten und stellte die bereits vorhandenen Ansätze vor.

Danach musste ich leider gehen, um mich auf meinen eigenen Vortrag vorzubereiten, der mit ca. 50 Teilnehmern erfreulich gut besucht war (unter anderem auch mit Mitarbeitern von IBM, Intel und Microsoft). Die OSCON-Keynotes werden allerdings auf einer speziellen Website online gestellt, so dass man sich dort nochmal in Ruhe anschauen kann.

Hier schon mal ein paar allgemeine Beobachtungen:

Die (technisch anspruchsvollen) Themen der Sessions sind hauptsächlich auf berufliche Software-Entwickler ausgerichtet

alles ist sehr informell: niemand trägt einen Anzug, niemand trägt eine Krawatte, aber kurze Hosen sind sehr beliebt

überall ist kostenloser Internet-Zugang über ein offenes WLAN möglich

über die Hälfte der Teilnehmer hat während der Sessions geöffnete Notebooks auf dem Schoß

dies hat zur Folge, dass man als Vortragender schon während der Session die ersten E-Mails erhält, diese in der nächsten Pause beantworten kann und wenig später schon wieder eine Antwort darauf erhält

man erhält vom Veranstalter ständig E-Mails mit neuen Informationen, Einladungen, etc. - das funktioniert tatsächlich, weil die Teilnehmer eben fast ständig online sind

ich sitze in der Speaker Lounge mit sieben anderen Personen an einem Tisch, und ich bin der einzige der nicht mit einem Apple-Notebook arbeitet

Wenn ich all das mit der OSMB in Deutschland dieses Jahr vergleiche, liegen doch noch (immer) Welten zwischen Europa und USA!