9 Tipps zum Umgang mit Open Source in eigenen Startups

Ich als jemand, der auch in einer Open Source-Community (nämlich der von Plone) recht aktiv ist, war natürlich an einer Session mit Namen „Startups and Open Source“ sehr interessiert, denn im Prinzip geht es ja bei Web2.0 auch immer um eine gewissen Offenheit, welche die Open Source-Community ja schon länger vorlebt.

Vortragender war Till Backhaus von iliketotallyloveit.com, einer Social Commerce-Plattform in Digg-Style. Er berichtete, dass sie aufgrund der Benutzung einer Open Source-Plattform (nämlich pligg) sehr schnell (nämlich in 2 Wochen) online sein konnten. Im Prinzip also haben sie pligg genommen, einen Fork davon erzeugt und die von ihnen benötigten Features schnell dazugebaut. Der geänderte Code wurde dann wieder veröffentlich, damit sie der genutzten Open Source-Lizenz entsprechen.

Interessant in diesem Zusammenhang war vor allem, dass potentielle Investoren von dem Gedanken eher nicht abgeschreckt worden sind, aber einen Aufschlag wohl für den Fall berechnen, dass die Idee direkt kopiert wird und man ein Recode machen muss (allerdings sind IMHO die meisten Startups technisch am Anfang doch eher leicht kopierbar und es kommt eher auf’s Marketing und auch Usability-Details an).

Insgesamt hat es sich für dieses Startup zumindest in der Anfangsphase wohl gelohnt, da eben schon viel Code vorhanden war und man schnell an den Start gehen konnte.

So ein Vorgehen kann aber auch Gefahren bergen, auf die ich hier kurz eingehen will (und die wir auch diskutiert haben).

Die Probleme

Ein Problem was ist sehe ist, dass man nur durch Benutzung einer Open Source-Plattform noch nicht so direkt auch Open Source lebt. Es geht ja nicht nur darum, Code zu nehmen, zu ändern und wieder zu veröffentlichen, sondern auch sehr stark um Zusammenarbeit. Ein Fork, der nicht wieder in das Hauptprodukt integriert wird (und bei ihnen geht es durchaus um sinnvolle Features wie Bildupload) ist eher ein toter Fork und man wird später Probleme bekommen, wenn Fork und Original mehr und mehr auseinanderlaufen.

Um dieses Problem in den Griff zu bekommen sollte man sich also mit der Community des Originalprodukts auseinandersetzen und partizipieren, heisst also Konferenzen und Sprints/Hackathons besuchen, auf Mailinglisten aktiv sein und dergleichen mehr.

Dies ermöglicht dann auch, dass man weiterhin an neuen Features im Hauptzweig der Entwicklung partizipieren kann. Open Source ist also mehr als nur Code nehmen und geben, sondern vor allem Kommunikation.

Weiterhin wurde noch der Security-Aspekt genannt. Wenn ich meine Eigenentwicklung ohne Community drumrum online stelle, so können natürlich auch potentielle Angreifer den Code einsehen und nach Schwachstellen durchsuchen. Dies wird in diesem Falle aber nicht von der grossen Masse an Entwicklern abgefangen, da diese eben fehlt. Auch daher sollte man nach Möglichkeit immer versuchen, seine geplanten Änderungen in Einklang mit den bestehenden Entwicklern durchzuführen, um eine breitere Entwicklerbasis zu haben.

Open Source in der Unternehmenswelt

Ich habe dann auch noch ein Beispiel aus meinem Erfahrungskreis gebracht, denn mit COM.lounge sind wir ja auch im Open Source-Bereich aktiv. Wenn wir auf Plone-Basis neue Produkte entwickeln, so ist unser Anliegen auch immer, diese Entwicklungen wieder der Community zur Verfügung zu stellen.

Warum macht man das, mag man fragen. Die Antwort ist eigentlich recht einfach: Weil alle (oder zumindest viele) das machen. So spart man auf der anderen Seite eben auch wieder Entwicklungszeit ein, wenn auf Produkte von anderen zurückgreifen kann, die ein bestimmtes Problem schon recht gut lösen. Es gibt auch Firmen, die ihre grosse Eigenentwicklung (Silva von Infrae fällt mir hier ein) sofort als Open Source-Projekt geplant und veröffentlicht haben. Wenn man es schafft, darum eine Community aufzubauen, dann hat man gewonnen, da man einerseits von den Arbeiten derer profitiert, aber natürlich sich auch selbst immer als Experte im entsprechendend Bereich darstellt.
Dies klappt in den meisten Fällen auch recht gut.

Als weiteres Beispiel will ich auch noch Linden Lab nennen, die den kompletten Client unter der GPL veröffentlicht haben, ein gewagter, aber notwendiger Schritt, der viel Planung erforderte und noch erfordert. Dazu aber sicherlich in einem anderen Post noch einmal mehr, wo ich mehr auf benötigte Konzepte und Infrastruktur eingehen will.