Einträge von Martin Aschoff

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.

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.

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).

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:

1. 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)
   
   
2. Das Struts2-Framework kümmert sich automatisch um den Datentransfer (inkl. Typ-Konvertierung) zwischen Model und View


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


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


5. 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.

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:

1. 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.


2. 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.


3. 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.


4. 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.


5. 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.

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:

1. 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.


2. 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.


3. 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.

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 ...

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.