Opensource und die “eigene geheime Technologie”

von Marc am 11. Oktober 2009

Viele Webapps im Netz basieren ja auf Opensource. Inzwischen ist es doch so, dass man durch den Opensource-Supermarkt schlappen kann und sich das nimmt was man für seine Apps braucht und nur noch alles zusammenrühren und in den Ofen stellen muss.

Was mir aber in letzter Zeit aufgefallen ist, immer mehr große Firmen geben Teile ihrer Infrastruktur als Opensource frei. Siehe Facebook mit Thrift, Cassandra, Tornado Web, Hive usw. Auch Google ist dabei mit GWT, Wave und ihrem Code Inkubator. Wir nutzen alle diese Technologien stillschweigend und freuen uns wenn sie funktionieren, doch wie können wir was zurückgeben und gleichzeitig unser eigenes Produkt damit verbessern ohne die Kerntechnologie offenzulegen? Hier ein paar Überlegungen die ich mir dazu gemacht habe:

Welche Technologie macht das eigene Unternehmen aus? Welche Teile unterstützen die Technologie und lassen sich kapseln? Wieviel kann ich offenlegen, ohne meine Geschäftsgrundlage auszuhebeln?

Beispiele:

  • Facebooks Tornado Webserver in Python. Er stellt nur einen kleinen Teil der Facebook Technologie dar, es ist also unkritisch ihn Opensource zu machen. Aber: Viele Entwickler beschäftigen sich nun damit und finden Bugs die Facebook (oder eben Friendfeed) nicht gefunden haben. Viele freuen sich, einen neuen, superschnellen asynchronen Webserver nutzen zu können. Ergo zieht Facebook auch einen Benefit aus dem veröffentlichen des Sourcecodes.
  • Google’s GWT. Ursprünglich geschrieben um Webapps wie Gmail einfacher entwickeln zu können, heute Opensource. Seitdem hat sich viel getan und es sind viele externe Libraries dazugekommen. Also auch hier ein Mehrgewinn für Google.

Was ich eigentlich damit sagen will ist, dass wir uns gerade überlegen was wir von ONchestra und seiner Platform Opensource stellen soll. Nicht um unser Gewissen zu beruhigen, sondern auch mit dem Gedanken dass mehrere Geeks sicher darin Bugs finden könnten, auf die man selbst nicht kommt.

Was würde Euch am meisten interessieren?

  • Umatics Tension – Unser EC2 für Arme :) (@Philipp: Habt Ihr denn auch vor Teile Eueres ähnlichen Konzeptes zu opensourcen?)
  • Umatics Chester – MongoDB ORM mit Validation und Referencing für Ruby
  • Umatics MongoDB Object – Ähnlich wie Chester nur für Python

Was mich noch interessieren würde:

  • Stellt Eure Firma teile Ihres Codes unter einer Opensource Lizenz ins Netz?
  • Wenn ja, welche Erfahrungen habt Ihr damit gemacht?

Ganz am Rande: Ich frage mich schon seit einiger Zeit, was im Webumfeld als Technologie definiert werden kann. Ist eine einfach Webapp bereits Technologie oder erst der eigens entwickelte Loadbalancer mit neuartigem Queuing Algorithmus? Was meint Ihr?

Gedankenspielereien, Technikhimmel

3 responses

3 responses


Do you want to comment?

Comments RSS and TrackBack Identifier URI ?

Philipp

Unsere Plattform ist nicht mit EC2 vergleichbar. Aber Open Source ist bei uns definitiv ein Thema. Nicht nur als Nutzer.

Was wir sicher Open Source stellen werden sind die libs für den Zugriff auf die REST-API und auch der Kommandozeilenclient.

Ob und wenn ja was von den serverseitigen Komponenten Open Source wird ist noch nicht entschieden. Wir halten uns da erstmal verschiedene Möglichkeiten offen.

11. Oktober, 2009 22:34

Robert Kummer

Also mich würde am ehesten Umatics Tension interessieren. Wir sind gerade dabei einen LoadBalancer für die EC2 zu entwickeln, der tageszeitabhängig mit etwas Vorlauf die benötigten Engines startet und automatisch verteilt und dann auch wieder abschaltet, wenn der Traffic passt. Quasi auf statistischer Erfahrung basierend Geld spart und jeden Trafficansturm verkraftet mit etwas Zeitverzögerung ;)

Grundsätzlich würde ich sehr viel unseres Quellcodes OpenSource stellen, da die “Technologie” ja auch die Geschäftsprozesse und Abläufe im Hintergrund umfasst. Vom blanken Quellcode kann ein Dritter mit unserem Quellcode noch lange kein Geld verdienen. Das ist für mich der Grundgedanke.
Die erste Bibliothek, die wir OpenSource stellen werden, wird eine XMLRPC-Schnittstelle für die Online-Faktura GSales 1.x sein. Diese haben wir für unser Produkt demobereich gebraucht, damit wir live im Zahlungsprozess Rechnungen parallel kreieren können. Allerdings brauchen wir dazu erst unsere neue Seite online.

PS.: Macht weiter so. Ich finde das sehr gut, wie ihr das macht und es erinnert mich an meine/unsere Anfangszeit vor 8 Jahren. Wir sitzen ja auch direkt um die Ecke in Ludwigsburg, also kommt doch mal vorbei auf nen Kaffee.

12. Oktober, 2009 06:51

Marc

@philipp: hehe, ja unser system ist auch weniger EC2 mehr heroku.com aber ich war zu faul das im detail zu erklären und EC2 kennt ja jeder auf anhieb :)

die frage ist halt ob es sinn macht so einen kernbereich der geschäftsidee freizugeben oder ob das zu riskant ist. ich weiß es ehrlich gesagt nicht.

@robert: ich geb dir auf jeden fall recht, dass der code alleine nicht reichen wird um einen 1:1 clon hochzuziehen…aber er könnte doch ein entscheidender faktor sein? eine agentur mit 20 hansel die gerade keine aufträge haben könnten dann doch relativ flott daraus was richtiges bauen wozu wir als kleines team keine manpower hätten.

letzendlich denke ich macht es aber schon sinn, nicht allzu pingelig und verschlossen mit dem code umzugehen. schließlich würde dieser garnicht existieren wenn alle so denken. ein henne ei problem :)

wenn ich das richtig gesehen habe, macht philipp mit cloudcontrol und robert mit demobereich etwas vergleichbares?

@robert: auf dein angebot kommen wir gerne zurück. lass uns deswegen doch nochmal per mail reden.

12. Oktober, 2009 11:52

Kommentieren
















Trackbacks