Vom Dasein eines Apache Software Foundation-Mitglieds

Stefan Bodewig: Ja, ich bin Stefan Bodewig, ich arbeite seit ungefähr zwei Jahren für innoQ, aber mache seit 16/17 Jahren Software und habe in der Zeit diverse Programmiersprachen/Frameworks/Systeme benutzt. In den letzten Jahren hauptsächlich Java und .NET. Und in den letzten zwei Jahren habe ich im wesentlichen Software entwickelt, ein bisschen Architekturberatung gemacht. Solche Dinge.

Till Schulte-Coerne: Ja, unser Thema heute soll die Apache Software Foundation sein. Das ist ja jetzt ein relativ unspezifisches Thema, deswegen fangen wir auch mal unspezifisch an. Kannst du uns vielleicht mal kurz sagen, worum es sich dabei überhaupt genau handelt und worauf vielleicht diese Foundation zurück geht.

Stefan Bodewig: Ja. Also Foundation wäre eigentlich im Deutschen Stiftung, aber die Apache Software Foundation ist eher mit einem Verein nach deutschem Recht zu vergleichen. Dieser Verein ist nach amerikanischem Recht konstituiert und will Open-Source Software produzieren für die Öffentlichkeit um Gutes zu tun. Das ist so Sinn und Zweck des Vereins und hat sich dafür Regeln gegeben. Entstanden ist das Ganze Mitte der 90er Jahre, eigentlich auch aus einer Gruppe von Software- Entwicklern, die an dem Webserver des NCSA gearbeitet haben, ein paar Patches hatten für diesen Webserver. Und der wurde dann nicht weiter entwickelt, sodass die sich selbstständig gemacht haben. Das war dann die Apache Group. Dieser Webserver hat sich verbreitet, viele Leute haben ihn eingesetzt und dann ist glaube ich IBM gekommen und wollte das in kommerziellen Produkten einsetzen und hat dann so ein bisschen nachgeholfen, dass das ganze auf vernünftige juristische Beine gestellt wurde. Dann ist dieser Verein gegründet worden, durchaus mit Unterstützung von Legal Department von IBM und es gibt halt eben jetzt einen eingetragenen Verein, mit einem Board of Directors und großen Bylaws, also mit einer – weiß ich nicht, wie würde es im deutschen Verein heißen? – irgendeiner Satzung, die diese Stiftung halt hat, in der drin steht: “Wir schaffen Open-Source Software für die Öffentlichkeit und wollen Gutes tun.” Und sind damit steuerlich begünstigt, Spendenquittungen könnten damit ausgestellt werden und sowas.

Till Schulte-Coerne: Ja gut. Der Name, geht der tatsächlich darauf zurück “a patchy” also ein gepatchter Webserver “Apache (a patchy) Webserver”?

tb: Ich bin damals nicht dabei gewesen, aber nach allem, was ich weiß, ist das ein Gerücht. Ein Gerücht, was schön klingt, also kann man sich gut vorstellen, dass das so der Name gewesen ist, aber eigentlich ist ursprünglich – Roy Fielding hat das mal auf irgendeiner Mailing-Liste geschrieben – ursprünglich war es einfach nur der Name, weil er gut klang. Apache klang vernünftig und diese Legende ist dann eigentlich erst im Nachhinein entstanden, soweit ich das weiß.

Till Schulte-Coerne: Ja. Es gibt ja jetzt mittlerweile deutlich mehr als nur den einen Webserver, den die meisten wahrscheinlich immernoch damit verbinden. Mittlerweile gibt es ja eine ganze Reihe sehr großer Projekte, teilweise unter diesem Dach. Kannst du vielleicht einfach mal ein paar in den Raum werfen und vielleicht kurz sagen, was es ist?

tb: Ja also der Webserver ist sicherlich das Flagschiff nach wie vor. Auch das, was man mit dem Namen verbindet. Es ist halt der Apache, oft auch. Dann sind es eben Projekte, gerade im Java-Ökösystem gibt es eine ganze Menge von Projekten. Hadoop ist sicherlich eins, das im ganzen Big Data Hype immer wieder auftaucht. Lucene ist auch nicht weg zu denken aus dem ganzen Bereich der Suche. Dann halt die Build-Tools wie Maven und Ant und Buildr. Also gleich drei Stück. Webframeworks, ich glaube fünf oder sechs oder sieben, alleine für die Java- Ecke. Es ist ziemlich Java-lastig, aber nicht ausschließlich in dieser Richtung aufgestellt. Es gibt da ein paar .NET-Projekte. Es gibt sicherlich einiges, was im Python-Bereich passiert. Es gibt CouchDB, was ja in Erlang im Wesentlichen gebaut ist. Also es ist schon eine relativ große Bandbreite, die da abgedeckt ist. Aber schon so, dass vieles vieles im Server-Bereich ist, bis dann eben vor zwei Jahren OpenOffice inzwischen ja auch ein Apache-Projekt geworden ist. Also es ist eine extrem große Bandbreite.

Till Schulte-Coerne: Ist das dann vielleicht auch der Unterschied zu anderen Software-Foundations, wie der Eclipse Foundation z.B., die ja doch sich relativ stark auf eine bestimmte – ich sag mal – Plattform spezialisieren?

Stefan Bodewig: Technisch wahrscheinlich ist da ein Unterschied, dass die Eclipse Foundation ihr Kernprodukt hat, um das herum weitere Produkte gebaut werden. Aber ich glaube, da gibt es auch Projekte, die nicht zwingend direkt mit der Eclipse-Plattform zusammenhängen. Und dann gibt es natürlich organisatorische Unterschiede. Die Apache Software Foundation sind einfach nur eine Sammlung von Menschen, von Individuum, die Lust haben, Software zu entwickeln. Die sicherlich auch dafür bezahlt werden zum Teil. Aber innerhalb der Apache Software Foundation gibt es keine Vertretung für Firmen. Während innerhalb der Eclipse Foundation Firmen selber Mitglied sein können, dieser Stiftung.

Till Schulte-Coerne: Bei euch sind es vor allem dann Sponsoren. Also ich meine die Platin-Sponsoren sind Google, Mircosoft und wahrscheinlich IBM oder sowas.

Stefan Bodewig: Die aber, außer dass sie Geld geben, keinerlei Einfluss auf die Entwicklung haben. Während bei Eclipse ein Member durchaus auch sagen kann, wir nehmen jetzt folgendes Projekt auf. Oder irgendein Projekt nicht auf, aus unspezifischen Gründen.

Till Schulte-Coerne: Politischen im Zweifel.

Stefan Bodewig: Und solche Entscheidungen werden innerhalb der Apache Software Foundation auch nicht vom Board getroffen, sondern das sind Entscheidungsprozesse, die von den Leuten getragen werden, die wirklich die Arbeit tun. Auch das ist glaube ich ein Unterschied zur Eclipse Foundation.

Till Schulte-Coerne: Das nennt sich nicht demokatischen Prinzip, sondern mediokratisch?

Stefan Bodewig: Meritokratisch.

Till Schulte-Coerne: Meritokratisch, okey.

Stefan Bodewig: Meriten, also der Ruhm, den man sich erworben hat. Je mehr Ruhm man sich erworben hat, desto mehr Entscheidungsbefugnisse bekommt man. Wobei auch das nicht ganz stimmt.

Till Schulte-Coerne: Und wie bekommt man Ruhm? Ist das ein formalisierter Prozess oder?

Stefan Bodewig: Ja schon, in einem gewissen Umfang. Also wenn man anfängt, an einem Projekt teilzunehmen, dann wird das darin bestehen, dass man sich in einer Mailingliste subscribed und Fragen stellt. Vielleicht findet man Fehler und öffnet irgendwelche Bug-Tickets und möglicherweise ist man in der Lage, diesen Fehler selber zu beheben. Dann wird mein einen Patch zur Verfügung stellen. Wenn man das oft genug gemacht hat, dann passiert es mehr oder weniger zwangsläufig, dass einem das Schreibrecht auf dem Verzeichnisbaum angeboten wird. Das ist dann der Commiter, der Commit-Recht hat. So wie das halt in Sourcecode-Management- Systemen heißt, wenn man schreiben darf. Und dann gibt es darüber noch ein paar Ebenen, die eben weiter gehen, die jeweils von den Leuten, die diese Ebene schon erklommen haben, gewählt werden. Das klingt jetzt furchtbar. Also oberhalb des Committers gibt es in jedem Projekt ein Project-Management-Committee. Das besteht aus allen Leuten, die Committer sind und bereits lange genug dabei sind. Das ist aber in einigen Projekten verschieden, wie stark man das handhabt. Es gibt Projekte, wie das gute alte Cocoon, in dem Committer gleich auch PMC-Member werden, also Mitglied dieses Project-Management-Committee. Und bei anderen dauert es eben ein halbes Jahr oder so, bis man dann auch dazu gewählt wird. Und die Menschen, die im Project-Management-Committee sind, sind diejenigen, die juristisch das Recht haben, zu wählen. Im Vergleich zu allen anderen, die sagen: “Ja, ich finde diese Software gut und das soll jetzt in einen Release gehen.”, werden bei einer Release-Abstimmung tatsächlich de facto nur die Stimmen der PMC-Member gezählt. Juristisch gewertet, weil nur diese durch die Stiftung eine juristische Deckung haben, eine Rückendeckung.

Till Schulte-Coerne: Du hast ja jetzt schon viele Wörter gesagt, Member, PMC usw. Wie genau ist jetzt die Organisationsstruktur? Also ganz oben ist das Directorsboard, wie viele sind das? Acht?

Stefan Bodewig: Neun.

Till Schulte-Coerne: Neun.

Stefan Bodewig: Also die Stiftung selber – die Foundation – gehört sozusagen den Membern. Die Member sind lang gediente Entwickler der Apache Software Foundation und diese wählen…

Till Schulte-Coerne: Das sind um die 400 oder sowas aktuell.

Stefan Bodewig: Das sind, ja etwa denke ich. Ich weiß die Zahl gerade gar nicht. Aber es sind mehrere Hundert. Und diese wählen ein Board aus neun Leuten für jeweils ein Jahr. Und dieses Board verteilt unter sich nochmal bestimmt Rollen, da gibt es dann den Chairman und den President. Das sind so die amerikanischen Organisationsstrukturen, die dann mehr oder weniger sowas wie Geschäftsführer und Aufsichtsratvorsitzender oder sowas wären, aber eigentlich eher in der Außenwirkung und in der Kommunikation mit anderen Leuten da stehen. Das sind diejenigen, die gefragt werden, wenn die Presse etwas wissen will oder die auf Konferenzen Vorträge halten, um die Apache Software Foundation vorzustellen. Die Membership wird auch einmal oder zweimal im Jahr aufgestockt. Da gibt es dann Wahlen, wo die Menschen, die bereits Member sind, neue Member wählen. Aus dem Pool der Committer im Wesentlichen. Es gibt ganz wenige Member, die nie Committer gewesen sind, sondern auf eine andere Art und Weise sich verdient gemacht haben. Da gibt es dann Sally, die im Marketing gearbeitet hat und eben Pressemitteilungen schreibt und solche Dinge tut, die aber nie wirklich selber Code geschrieben hat. Und es gibt ein Member, der als Rechtsanwalt die Apache Software Foundation beraten hat. Aber es sind immer individuelle Geschichten, also es sind Menschen, die hinein gewählt werden für das, was sie getan haben, nicht weil sie für irgendeine Firma arbeiten oder ähnliche Dinge.

Till Schulte-Coerne: Ja und dann gibt es immer noch diese Vice-Presidents, diese spektakulären Bezeichnungen. Was sind das? Wir ordnet sich das ein ins Gesamtbild?

Stefan Bodewig: Vice-President ist glaube ich auch einer amerikanischen Organistationstruktur einfach geschuldet, wo jeder Filialdirektor einer Bank Vice-President dieser Bank ist, weil man Vice-President sein muss, um Unterschriften tätigen zu dürfen. In der Apache Software Foundation gibt es Projekte, die immer so eine – ja im groben – eine Richtung, eine Codebasis repräsentieren, die von den Project-Management-Committee gesteuert werden und der Vorsitzende dieses Project-Management-Committee, der ist gleichzeitig Vice- President der Apache Software Foundation und zuständig für eines der Projekte.

Till Schulte-Coerne: Im Normalfall also ist der auch Member, im Normalfall oder deckt sich das nicht zwingend so?

Stefan Bodewig: Das ist nicht so 100%-ig. Es ist häufig so, dass wenn Projekte dort sind, deren Project-Chairman kein Member ist, dann fällt einem das auf. Wenn man dann neue Member wählt, dann ist die Wahrscheinlichkeit relativ hoch, dass anschließend das wieder deckungsgleich wird.

Till Schulte-Coerne: Ja, jetzt haben wir viel über die Foundation erfahren, jetzt wollen wir auch mal ein bisschen über dich und deine Rolle vielleicht in der Foundation wissen. Was machst du denn da genau?

Stefan Bodewig: Ich bin ein Member der Apache Software Foundation seit 2000, seit Oktober 2000. Habe angefangen Ende 99, Anfang 2000 an diversen Projekten teilzunehmen.

Till Schulte-Coerne: Welche?

Stefan Bodewig: Insbesondere Apache Ant, bei dem ich dann auch im Juni 2000 Committer geworden bin. Es ging dann relativ schnell, dass ich Member der Apache Software Foundation geworden bin aus Gründen, die heute niemand mehr versteht. Aber damals ging das halt tatsächlich einfach noch extrem schnell. Und seitdem habe ich in einigen anderen Projekten meine Nase mit drin gehabt, ich bin in einigen Apache Commons Projekten drin. Das sind so kleine Java-Bibliotheken, die hoffen, Funktionalität bereitzustellen, die man dann eben wiederverwenden kann. So ziemlich alle Java-Entwickler werden, wenn sie mit Maven bauen, unzählige Commons-jars auf ihrer Platte liegen haben.

Till Schulte-Coerne: Das fällt aber wahrscheinlich nicht auf, bei dem ganzen Rest, den man auch noch runter lädt.

Stefan Bodewig: Wahrscheinlich geht es unter, in dem ganzen Rest, ja. Ich bin Vice-President, tatsächlich auch, weil ich Chairman des Gump-Projektes bin. Das ist ein Continuous Integration System, das innerhalb der Apache Software Foundation genutzt wird, um eigentlich über Projektgrenzen hinweg continuous intergration zu betreiben, aber ich glaube außerhalb der ASF von niemandem verwendet wird. Und habe…

Till Schulte-Coerne: Wenn doch, dann ist derjenige oder diejenige herzlich aufgerufen, sich bei uns zu melden.

Stefan Bodewig: Ja gerne. Und ja darüber hinaus bin ich in einigen Projekten dabei gewesen. Tatsächlich die meiste Zeit verwende ich momentan auf so ein Stückchen auf Log4NET. Das ist ein Port von Log4J, der Logging-Bibliothek aus der Java-Richtung für die .NET-Plattform. Und Commons Compress als eine der Bibliotheken, die sich mit Kompression und Archivierungsformaten auseinander setzt. Auch hauptsächlich deshalb, weil dort Code von Ant hingewandert ist, den wir ursprünglich da für .tar und .zip als Archivierungsformate gebaut haben und eben Ant. Aber das verteilt sich immer mal wieder schwankend, wo ich mehr mache und wo ich weniger tue.

Till Schulte-Coerne: Und du setzt dann auch nicht irgendwelche Bibliotheken für deine Kompressionsalgorithmen ein, sondern du bist derjenige, der aus einem Eingabebyte ein gezipptes Byte macht oder wie genau? Bzw. nicht du, sondern deine Bibliothek.

Stefan Bodewig: Teilweise. Also es ist so, dass zumindest für den ZIP-Bereich das schon ganz unten aufbaut auf dem, was auch die Java-Class-Library macht. Was heißt, es ist unten drunter zlib, eine native C-Bibliothek, die auf jedem Linux- System, auf jedem Mac und auch unter Windows zu finden ist. Was auch vom Betriebssystem verwendet wird, wenn man Ordner komprimieren möchte oder sonst irgendwas. Das macht dann aber das java.util.zip-Package aus der Java-Ecke. Aber bei vielen anderen Dingen, wie TAR oder CPIO, den anderen Algorithmen, die dort sind, sind das Implementierungen, die innerhalb des Projektes sind aber natürlich nicht alle von mir stammen.

Till Schulte-Coerne: Das wäre auf jeden Fall auch ein interessantes Podcast- Thema, ginge heute aber wahrscheinlich eher etwas zu weit.

Stefan Bodewig: Ja.

Till Schulte-Coerne: Ja, wenn du jetzt also z.B. an deinen Wochenenden oder an Feiertagen oder nach Dienstschluss nach Hause kommst und dich vor deinen Rechner klemmst, wie sieht denn dann so der Alltag eines Apache Committers aus? Schmeißt du dich an deinen Rechner und fängst an, Code zu schreiben, oder was genau ist sozusagen unter dem Alltag eines Apache Committers sich vorzustellen?

Stefan Bodewig: Das ist glaube ich sehr sehr individuell, das machen Leute sicherlich sehr verschieden. Es gibt Leute, innerhalb der Apache Software Foundation, Committer durchaus, die werden dafür bezahlt, dass sie an einem bestimmten Projekt arbeiten, wo einfach Redhat jemanden beschäftigt, um am Tomcat mitzuarbeiten oder SpringSource. Dann gibt es Leute wie mich, die das im Wesentlichen in ihrer Freizeit betreiben und da wird es einige geben, die im Wesentlichen Code schreiben und andere, die durchaus auch auf den Mailinglisten Fragen beantworten, Bugtickets machen und solche Dinge. Bei mir ist es eher so, dass ich viel mehr Zeit mit E-Mails und mit Bugticktes verbringe, als ich wirklich Code schreibe. Oft ist es auch so, dass es dann aufhört, Spaß zu machen und ich auch mal so ein Wochenende brauche, an dem ich nichts anderes mache, als Code zu schreiben, weil ich das ja eigentlich deshalb mache, weil mir das Programmieren Spaß macht und weil ich vielleicht auch noch so ein paar Dinge beim Entwickeln nochmal lernen möchte oder mit Umgebungen arbeite, mit Themen arbeite, die mir so am Tag, während meines normalen Jobs, nicht begegnen. Und dann versuche ich das eben auszugleichen. Aber es ist schon so, dass sicherlich für das Lesen und Beantworten von E-Mails ungefähr eine Stunde pro Tag drauf geht und wenn dann ja, Familie oder sonst irgendjemand noch Zeit haben möchte oder ich mal was anderes tun möchte als Code zu schreiben, bleibt da nicht mehr so wahrsinnig viel Zeit übrig.

Till Schulte-Coerne: Also die Motivation ist eigentlich immer noch für die das Coden und weniger dieser organisatorische Aspekt.

Stefan Bodewig: Das Organisatorische ist im Wesentlichen Randgeräusch, eigentlich.

Till Schulte-Coerne: Aber ihr müsst ja eigentlich auch Positionen haben oder Mitglieder haben, die sich sehr um dieses organisatorische Thema kümmern, weil ich ja eben auch z.B. wahrscheinlich auch mit Rechtsstreitigkeiten konfrontiert seit. Und wenn ihr halt eine komplett ehrenamtl… Ist es dann so, dass ihr eine ehrenamtliche Anwaltsgilde z.B. habt?

Stefan Bodewig: Also zum einen beschäftigt die Apache Software Foundation sogar ein paar Leute, das sind im Wesentlichen Menschen, die das Operating machen, also Systemadministratoren, die dafür sorgen, dass die Server laufen und regelmäßig laufen. Da kann man sich nicht nur auf Freiwillige beschränken, weil dann im Zweifel sonntags Nacht niemand da wäre, der sich um irgendeinen Rechner kümmern kann. Aber was das Rechtliche angeht. Also zum einen gibt es keine Rechtsstreitigkeiten bisher, in denen die Apache Software Foundation verwickelt wäre. Auf einer gewissen Ebene wäre das auch keine gute Publicity, wenn man die Apache Software Foundation verklagt. Das ist Aufgabe des Boards, diese juristischen Dinge zu tun. Und es gibt dann ein Legal-Management-Committee oder sowas ähnliches, wo auch mehrere Rechtsanwälte mit auf einer Mailingliste sind, weil alle Kommunikation innerhalb der Apache Software Foundation per E-Mail erfolgt. Die dann, wie oft es bei Rechtsanwälten der Fall ist – nicht anders als bei Softwareentwicklern – auch nicht einig sind, wie denn irgendwas zu bewerten ist. Aber es ist schon tatsächlich pro bono Beratung, die da statt findet. Also kostenlos. Wenn es denn notwendig würde, würden sicherlich auch Anwälte bezahlt werden.

Till Schulte-Coerne: Da würden dann vermutlich auch noch andere Organisationen zur Hilfe springen und ähnliches, wenn man es denn wollte.

Stefan Bodewig: Ja, davon würde ich auch ausgehen.

Till Schulte-Coerne: Du warst eben gerade schon bei eurem Operating. Da ist irgendwie in meinem Hinterkopf immernoch sowas, dass die Apache Software Foundation heute immernoch Subversion benutzt. Ist das immernoch so oder gibt es da mittlerweile Bestrebungen zu Git oder habt ihr da eigentlich keine Lust drauf?

Stefan Bodewig: Es gibt sowohl Subversion als auch Git. Projekte können sich aussuchen, ob sie Subversion oder Git verwenden möchten. Es ist bis vor zwei Jahren so gewesen, dass Subversion das einzige Sourcecode-Management-System gewesen ist. Es ist ja auch Apache Subversion, auch ein Apache Projekt. Insofern essen wir da unser eigenes Hundefutter und dann kamen eben Projekte durch den Incubator – das ist so der Einstiegsweg in die Apache Software Foundation für Projekte, die von außen kommen –, die mit einer Git-Vergangenheit gestartet sind und die gerne Git weiterhin benutzten wollten. Dann hat es einige Probleme gegeben, wie Git zusammen passt mit bestimmten juristischen Bedenken, die im Raum standen, dass man auch bei jedem einzelnen Commit sauber nachvollziehen kann, von wem der eigentlich stammt. Weil ich in so einem Git-Commit auch irgendeine E-Mailadresse reinschreiben kann und ich nicht nachher nachvollziehen kann, anhand des Commits alleine, dass es wirklich dieser Committer gewesen ist, der das war. Aber diese Probleme sind alle ausgeräumt und es gibt ein git@apache und es gibt auch Github-Mirror, über die durchaus auch Pull-Requests reinkommen für Projekte. Also es öffnet sich so ein wenig auch in die Entwicklungsrichtung, die Github gemacht hat.

Till Schulte-Coerne: Also wenn ich jetzt an deiner Commons-Implementierung mitwirken wollen würde, dann gäbe es dafür ein entsprechendes Github-Repository, wo ich meine Issues einstellen könnte und meine Pull-Requests oder müsste ich da noch eher E-Mails schicken?

Stefan Bodewig: Du könntest. Allerdings wäre es schöner, du würdest ein Jira- Ticket öffnen, weil das der offizielle Issue-Tracker dafür ist. Pull-Requests würden tatsächlich als E-Mails an die Mailingliste durchgereicht werden und dann wird es vielleicht umgewandelt in ein Jira-Ticket. Es gibt da inzwischen auch stärkere Integration, wo Pull-Requests automatisch Kommentare in Jira-Tickets auslösen und solche Dinge, wenn sie entsprechend funktionieren. Aber es ist schon so, dass Pull-Requests eher so eine zusätzliche Option darstellen und nicht die bevorzugte Option sind, zumindest für das Commons-Projekt. Aber ich glaube, die CouchDB-Entwickler beispielsweise haben sehr viel stärker einen Git- zentrierten Entwicklungsweg und da spielt auch Github eine wesentlich größere Rolle.

Till Schulte-Coerne: Noch eine Frage zu dem Commons. Es gab ja früher dieses Jakarta-Projekt bei Apache. Das gibt es jetzt glaube ich nicht mehr so richtig. Wo ist denn da jetzt genau der Unterschied?

Stefan Bodewig: Das Jakarta-Projekt war 2000 das Projekt, was gegründet worden ist, im wesentlichen um Tomcat aufzunehmen. Tomcat ist die Referenz- Implementierung für die Servlet-Spezifikation gewesen von Sun und ist der Apache Software Foundation gespendet worden und das Jakarta-Projekt war dann über einige Jahre hinweg das Sammelbecken für alles, was irgendwie mit Java zu tun hatte innerhalb der Apache Software Foundation. Und das hat dann irgendwann nicht mehr funktioniert, es wurde zu groß, es wurde zu unübersichtlich. Es war so, dass man im Prinzip ein zweites Board hatte, dass das Board der Apache Software Foundation irgendwie alles überblickte, was nicht Java war und das Project-Management-Committee des Jakarte-Projektes mindestens 70% der Projekte eigentlich dort überblicken sollte. Dann sind 2003/2004 die Projekte aus dem Jakarta-Projekt heraus gegangen. Ant war eines der ersten die Jakarta verlassen haben. Tomcat ist auch relativ früh raus gegangen. Und das Commons-Projekt war ursprünglich auch ein Unterprojekt von Jakarta. Es war…

Till Schulte-Coerne: Also ein Unterprojekt, was Unterprojekte hat.

Stefan Bodewig: Genau. Da war es – ursprünglich ist Commons gemacht worden von den Leuten, die damals Struts und Turbine – ich weiß gar nicht, ob man heute Turbine noch kennt – und andere Webframeworks gemacht haben, um dort miteinander Code auszutauschen für Dinge, die sowieso jeder nochmal neu erfunden hat. Und das hat glaube ich sogar relativ gut funktioniert. Also man hat in der früheren Zeit zwischen Struts und Turbine überhaupt keinen Code gehabt, der von beiden benutzt wurde, sondern das war so ein “not invented here”, jeder hat seinen eigenen Datenbank-Pool und andere Dinge gemacht. Und das hat sich glaube ich mit dem Commons-Projekt ganz gut entwickelt. Und das Jakarta-Projekt ist am Ende daran gestorben, dass keine Projekte mehr übrig waren, die da noch überwacht werden mussten.

Till Schulte-Coerne: Wir haben jetzt schon mehrmals diese rechtlichen Sachen angesprochen. Insbesondere äußert sich das ja auch in der mit der Apache Software Foundation – ich sage mal – assoziierten Lizenz, der entsprechenden. Kannst du uns vielleicht auch da ein paar Details sagen? Also was kennzeichnet die Lizenz und was unterscheidet sie z.B. von einer GPL oder einer MIT License?

Stefan Bodewig: Wobei MIT und GPL natürlich die beiden Extreme sind, um es damit zu vergleichen. Die ursprüngliche Lizenz, die die Apache Software Foundation benutzt hat, ist eigentlich eine BSD Lizenz gewesen. BSD ist im wesentlichen die MIT Lizenz, die sagt: “Nimm meinen Code, mach damit, was du magst, aber verklag mich nicht, wenn irgendwas kaputt sein sollte.” Und die BSD Lizenz hat dem noch so ein paar Klauseln hinzugefügt, die sagen “Und wenn du meinen Code benutzt, dann wäre es schön, wenn du darauf hinweist, dass du das machst, aber dafür darfst du deine Dinge nicht so nennen, wie meins.” Also ich will meinen Namen in irgendeiner Art und Weise schützen können. Und die Apache Software License in der Version 2, die aktuell eingesetzt wird, ist eine sehr viel länger gewordene, sehr viel ausführlicherere Formulierung des gleichen Grundgedankens. Du kannst mit der Software mehr oder weniger tun, was du willst. Eigentlich kannst du damit tun, was du willst, du kannst Closed-Source daraus machen, du kannst es ändern und alle möglichen Dinge damit machen, aber im wesentlichen schützen wir unseren Namen, dass du also nicht sagen kannst, ich mache jetzt meine eigene Version von Apache Ant, ich ändere da ein paar Dinge und nenne das dann Apache Ant+ oder was in dieser Form. Dass man da also so Namensrechte schützt und ein bisschen gibt es da Patentschutz, also dass man sich dagegen schützen will, dass irgendwelche Patentklagen eingestielt werden. Es ist sehr sehr viel, sehr langer Text, sehr juristischer Text, aber die Kernidee ist immernoch die, zu sagen “Wir wollen Software zur Verfügung stellen, mit der derjenige, der sie verwenden möchte, möglichst viel Freiheit hat.”

Till Schulte-Coerne: Und was ist es dann, die Abgrenzung zu GPL?

Stefan Bodewig: Die GPL hat eigentlich einen ganz anderen Fokus. Wenn ich gerade eben gesagt habe, dass die Apache Lizenz darauf abzielt, dass derjenige, der sie benutzen möchte, größtmögliche Freiheit hat, ist es hier eher die Freiheit des Entwicklers, die da so im Zentrum steht. Die GPL steht eigentlich da, um die politischen Ziele der Free Software Foundation – alle Software nach Möglichkeit sollte frei sein und niemandem gehören – durchzusetzen und führt eben deshalb aus diesem Fokus heraus dazu, dass ich als jemand, der es benutzt, nicht mehr die volle Freiheit habe, sondern ich kann nur noch bestimmte Dinge damit tun. Ich kann sie benutzen, das darf ich in jeder Form, aber wenn ich sie verändere, dann gehe ich damit verschiedene Verpflichtungen ein. Nämlich wenn ich meine Software weitergebe, dann muss ich diese weiter gegebene Software ebenfalls unter der GPL veröffentlichen und demjenigen, dem ich es weitergebe, auch den Quelltext geben. Dann gibt es natürlich die abgeschwächteren Versionen der LGPL, in der ich dann vielleicht nur linkbaren Object-Code weitergeben muss, nicht zwingend die Quelltexte, aber da ist einfach so die Zielrichtung eine andere.

Till Schulte-Coerne: Also ihr seit an der MIT Lizenz auf jeden Fall näher dran als an der GPL, so zusammenfassend.

Stefan Bodewig: Ja, philosophisch gehören wir eher in diese Ecke.

Till Schulte-Coerne: Und dagegen kommt natürlich irgendwie jedes Mal die Frage, gerade jetzt auch im Unternehmen, z.B. wir haben etwas geschrieben, wir wollen es mit der Allgemeinheit teilen. Unter welcher Lizenz macht man das jetzt? Also Beispiel, in einer Bank wurde etwas geniales erfunden, was jetzt der Welt zur Verfügung gestellt wird, um z.B. Aktualisierungen von der Community zurück zu bekommen oder Fehlermeldungen und ähnliches. Was würde man da dann üblicherweise wählen?

Stefan Bodewig: Kommt sicherlich auch ein Stück weit darauf an, was man damit weiter machen möchte. Wir haben das in Projekten schon gemacht, dass wenn der Kunde es zulässt, wir kleinere Bibliotheken Open-Source stellen und nutzen dafür die Apache Software License. Tatsächlich auch, um zu sagen “Nehmt es wirklich und macht da was nützliches mit.” Aber wenn ich da möglicherweise in einem gewissen Umfang auch eine ganz wichtige Kernkomponente meiner Firma drin sehe, von der ich Angst habe, dass Mitbewerber das nutzen könnten, um mich dann aus dem Markt zu drängen, dann ist vielleicht die GPL die näher liegende.

Till Schulte-Coerne: Wobei, dann würdest du es wahrscheinlich eh nicht Open- Sourcen, oder?

Stefan Bodewig: Möglicherweise nicht, aber das ist durchaus einer der Gründe, weswegen OpenJDK unter der GPL daher kommt, um auf diese Art und Weise erzwingen zu können, dass niemand ein Java heraus bringen kann, auf Basis des OpenJDK, das aber Closed-Source macht. Damit Oracle – urspünglich Sun, jetzt Oracle – halt durchsetzen kann, dass auch diese davon abstammenden Implementierung wiederrum unter der GPL veröffentlich werden müssen, es sein denn man schließt andere Lizenzabkommen mit Oracle.

Till Schulte-Coerne: Denkst du denn, dass wenn man jetzt z.B. ein großes Projekt hat, was vielleicht auch schon auf der Apache License angesiedelt ist, dass es sinnvoll wäre dann auch zu überlegen, irgendwann zur Apache Software Foundation zu gehen mit dem Projekt und das unter diesem Dach weiter zu betreuen? Also wann würdest du das Thema jemandem empfehlen?

Stefan Bodewig: Die Apache Software Foundation ist ja nicht nur die Lizenz, sondern sie ist auch in gewisser Weise ein Modell dafür, wie man Software entwickelt. Wie eine Community, die sich um so ein Projekt gebildet hat, wie die die Software entwickelt. Und das mag nicht für jedes Projekt passend sein. Wenn ich ein Apache Software lizensiertes Projekt habe, das eindeutig von einer Firma dominiert wird – Spring, das Spring-Framework, das von SpringSource dominiert wird – dann wäre das nicht passend für die Apache Software Foundation, weil es dort sehr viel wichtiger ist, dass alle, die an diesem Projekt mitwirken, das gleiche Mitspracherecht haben und – ganz im Gegenteil – Dominanz einer Firma eher negativ wäre. Denn da ist eben die wichtige Ausrichtung zu sagen, die Software soll es überleben können, wenn eine Firma kein Interesse mehr hat, diese Software weiterzuentwickeln.

Till Schulte-Coerne: Hat es denn schon mal gegeben, dass eine Firma Dominanz in einem Projekt ausgeübt hat oder es versucht hat und was ist dann passiert?

Stefan Bodewig: Das, was durchaus gelegentlich passiert, ist, dass eine Firma nach und nach alle Committer einstellt. Dagegen kann man sich nicht wehren. Das ist z.B. bei Lucene eine Zeit lang so gewesen, dass beinahe alle Kern-Committer innerhalb der gleichen Firma gearbeitet haben. Da wird dann schon mit Argusaugen drauf geachtet, dass dort nicht die Firma ihre eigenen Interessen gegen die Interessen anderer Contributor durchsetzt und dass eben auch weiterhin unabhängige Committer oder unabhängige Contributor die Chance haben zu Commiter gewählt zu werden und in den PMC zu kommen. Ob die dann anschließend wieder von der Firma eingestellt werden, ist eine andere Frage.

Till Schulte-Coerne: Ja. Wenn ich jetzt z.B. am Wochenende ein geniales Open- Source Tool gebaut habe und jetzt der Meinung bin, das sollte ich unbedingt mal unter dem Dach der ASF veröffentlich – warum auch immer, wegen dem Rechtsschutz, wegen dem Ansehen oder weil ich es einfach der Welt zur Verfügung stellen will – wie würde ich das dann genau machen?

Stefan Bodewig: Der Einstiegspunkt ist der Incubator, also so ein Inkubationskasten, ein Brutkasten, in dem die Projekte wachsen können, um echte Apache Projekte zu werden. Da ist der Einstieg, dass man sich jemanden sucht in der Apache Software Foundation, der als Shepherd wirkt, als Hirte, der einem dann auch den Weg zeigt und einen dort einführt. Und dann muss man zunächst einmal einen Antrag stellen, um in diesen Incubator zu kommen.

Till Schulte-Coerne: Per E-Mail? Per Post?

Stefan Bodewig: Per E-Mail, selbstverständlich. Ich glaube, man muss noch eine Wiki-Seite schreiben und auf dieses verweisen und dann darüber abstimmen lassen. Das macht dann eben der Shepherd, der das ganze durchführt. Und dann gibt es einen Inkubationsprozess, bei dem die Apache Software Foundation oder das Incubator-Projekt eigentlich mehr Mentoren zur Verfügung stellt, um zu erklären, so soll das ganze funktionieren, auf diese Art und Weise wird bei der Apache Software Foundation Software entwickelt. Und man braucht kritische Masse, man muss mindestens drei unabhängige Entwickler haben, um überhaupt Releases zu machen, weil ein Apache Release mindestens drei – in einer Abstimmung müssen drei Menschen zustimmen, ob was da als Software released werden soll auch wirklich würdig ist ein Software-Release zu werden. Und sie müssen unabhängig voneinander sein, dürfen nicht alle drei in der gleichen Firma sein. Also es gibt ein paar Regeln, über die dann eben abgestimmt wird durch den Incubator, wenn man sagt “Wir sind jetzt soweit.” Ob dies alles eingehalten ist, ja die können auf ihren eigenen Füßen stehen. Und dann entscheidet letztendlich das Board darüber, ob ein solches Projekt vom Incubator zu einem normalen Apache- Projekt wird.

Till Schulte-Coerne: Es entscheidet weniger eine marktwirtschaftliche Analyse über den Erfolg, sondern mehr eigentlich Code-Qualität, Community-Support und ähnliches.

Stefan Bodewig: Absolut. Marktwirtschaftliche Analysen spielen da überhaupt keine Rolle bei. Sonst gäbe es auch keine konkurrierende Projekte, denke ich. Da würde man ein Webframework haben oder ein Build-Tool und nicht n davon.

Till Schulte-Coerne: Habt ihr denn aktuell Personalengpässe oder ähnliches? Also gibt es jetzt Gründe hier über den Podcast z.B. einen Aufruf zu machen, aquiriert ihr irgendwelche neuen Projekte oder verhaltet ihr euch eher passiv, weil ich den Luxus habt, dass euch eh alle Welt liebt.

Stefan Bodewig: Was Projekte angeht, ist es schon eher passiv. Da gibt es nicht die Botschafter, die unterwegs sind und versuchen, Projekte einzuwerben. Habe ich zumindest in der Form nicht wahrgenommen. Manchmal kommt es so aus heiterem Himmel, dass plötzlich was großes ankommt. In einem gewissen Umfang glaube ich auch, dass die Apache Software Foundation für bestimmte Projekt nicht cool genug wirkt, dass wir vielleicht zu behäbig, zu bürokratisch manchmal wirken.

Till Schulte-Coerne: Was wäre die Alternative? Einfach so bei Github ein Projekt einstellen?

Stefan Bodewig: Zum Beispiel. Das ist eine der sicherlich viel flexibleren Alternativen. Ich glaube, dass bei Node.js beispielsweise ernsthaft darüber diskutiert wurde, ob man eine neue Heimat suchen sollte und da war schon die Stimmung “Die Apache Software Foundation ist eigentlich viel zu langweilig für uns.” Und zu behäbig, zu träge.

Till Schulte-Coerne: Was bietet denn dann die Apache Software Foundation, wenn sie mich so viel Bürokratie kostet? Also was ist der Anreiz für jemanden, sein Projekt doch da einzustellen und eben nicht nur ein Github-Repository zu machen und die Apache Lizenz in die License.txt-Datei reinzukopieren?

Stefan Bodewig: Ich müsste dem jetzt natürlich energisch widersprechen, was die Kosten von Bürokratie angeht, aber das sprengt jetzt alles. Was die Apache Software Foundation bietet, ist im wesentlichen Rechtssicherheit. Rechtssicherheit sowohl für den einzelnen Entwickler als auch Rechtssicherheit für Firmen, die anschließend das Produkt weiterverwenden wollen. Es ist nicht nur die Apache Lizenz, sondern es ist auch der Prozess, der sicher stellt, dass in ein Release, ein Software-Release der Apache Software Foundation, nach besten Wissen und Gewissen nur Code eingeflossen ist, der auch wirklich verteilt werden darf. Und auf der anderen Seite, für den einzelnen Entwickler habe ich die Sicherheit, dass wenn jemand glaubt, ich hätte gegen sein Patent verstoßen mit meiner Software, dann wird der nicht mich als individuellen Contributor verklagen, sondern er verklagt die Apache Software Foundation.

Till Schulte-Coerne: Was er lieber lässt.

Stefan Bodewig: Und wenn ich mein kleines Github-Projekt habe, dann kriege ich vielleicht eine Abmahung und dann würde ich vielleicht doch eher Geld zahlen, um meine Ruhe zu haben.

Till Schulte-Coerne: Ganz grundsätzlich, als Arbeitgeber, wenn man einen Apache Software Member beschäftigt oder einen Committer bei der Apache Software Foundation beschäftigt, was könnte man als Arbeitgeber üblicherweise tun, um das zu unterstützen, in welcher Form auch immer?

Stefan Bodewig: Puuh. Zeit. Zeit ist immer so ein wichtiger Faktor. Ich habe ja eben schon gesagt, dass ich mehrere Stunden am Tag E-Mails lese und beantworte, solche Dinge. Also durchaus den Raum zu lassen, dass man auch so zwischendrin mal seine Mails beantworten kann. Ansonsten gibt es sicherlich immer die Möglichkeit, wenn sich das im Projekt-Alltag, wenn es passt, zu sagen “Ok, wir brauchen hier noch so ein Feature, du kannst nochmal richtig Zeit investieren in ein bestimmtes Feature einer Bibliothek, die wir ohnehin verwenden, hinzufügst.” oder etwas in der Form. Auch das ist im wesentlichen wieder, Zeit zur Verfügung zu stellen.

Till Schulte-Coerne: Ja, ich bin dann soweit durch mit den Sachen, die mir noch einfallen. Hast du vielleicht noch ein paar abschließende Worte zu dem Thema?

Stefan Bodewig: Ich möchte natürlich dann jetzt die Gelegenheit nutzen, Leute einzuladen, mitzumachen. Nicht unbedingt Projekte zu aqurieren für die Apache Software Foundation, sondern Leute dazu einzuladen, selber Teil zu nehmen an Open-Source Projekten. Weil es Spaß macht und weil man dabei Dinge lernen kann und nicht nur so den einzelnen kleinen Bug fixen kann, der einem gerade im Weg steht, sondern durchaus auch die Möglichkeit hat, zu beinflussen, in welche Richtung etwas weiter geht. Vielleicht dafür zu sorgen, dass die ein oder andere Schnittstelle in irgendeiner Bibliothek schöner wird und nützlicher wird. Und wenn man da nicht mitmacht, kann man es nicht beeinflussen.

Till Schulte-Coerne: Schöne letzte Wörte, vielen Dank Stefan.

Stefan Bodewig: Gerne.

[!]