Kolumne: Die flinke Feder

GitHubs fehlendes Feature

Bernd Fondermann

Bereits vor einigen Monaten sollte sich „Die flinke Feder“ mit dem Vergleich von GitHub und Apache beschäftigen. Aus diesem Thema wurde erstmal nichts, andere Dinge waren interessanter. In den letzten Wochen wurde nun eine Diskussion in den Medien sowie in den einschlägigen öffentlichen und privaten Foren ausgetragen, die in vielfachen Variationen Schlagzeilen produzierte, zum Beispiel „Apache sträubt sich gegen Git!“.

Die Fakten sind folgende: Seit vielen Jahren gibt es ein einziges, riesiges Subversion Repository, in das alle Apache-Projekte ohne Ausnahme ihren Code einchecken. Es ist quasi die Zentralregistratur, das Archiv. Quellcode, der dort nicht liegt, den gibt es nicht. Jedenfalls nicht bei Apache. Aus SVN heraus werden Webseiten generiert, aber vor allem Releases. Subversion zeichnet auf, wer welchen Code wann wie verändert hat. Fakt ist auch, dass Subversion mittlerweile ein Apache-Projekt ist und langjährige Apache Member wie Board-Mitglied Greg Stein es entwickelt haben.

Sie kennen das vielleicht aus Ihrem eigenen Umfeld: es gibt Menschen, die springen auf technische Innovationen schnell an. Andere sind zuerst reserviert und warten ab, um sich vielleicht später dem Thema zu öffnen – oder es auf ewig abzulehnen. Nicht anders ist es bei Apache. Von außen kann man die Apachen durchaus als homogene Gruppe wahrnehmen, von innen sieht das ganz anders aus. Dem Vernehmen nach ist Subversion dort bei seiner Einführung auf Bedenken gestoßen. Übrigens ebenso wie CVS selbst – ja, es gab eine Zeit vor CVS!

Auch über Java oder Maven wurden und werden immer noch bei der ASF genauso wie anderswo Auseinandersetzungen geführt. Warum? Weil jede relevante Technologie unseren Umgang mit der Welt zumindest ein kleines bisschen verändert. Was wiederum Auswirkungen auf die nicht technischen Aspekte unseres Lebens hat. Und gerade über diese Themen wird bei Apache am meisten diskutiert. Weil es einerseits Menschen gibt, die technische Innovationen schnell adoptieren und andererseits solche, die es sehr langsam tun.

Doch bleiben wir kurz bei der Technik. Verteilte Versionskontrolle ist beleibe nicht mehr neu. Bitkeeper und Mercurial sind seit vielen Jahren verfügbar, Git [1] ist ebenfalls bereits erwachsen. Die Adaptionskurve, insbesondere von Git, steigt derzeit rasant. Der Grund dafür ist nicht zuletzt GitHub [2]. GitHub bietet jedem Entwickler seine eigene kleine Plattform zum Veröffentlichen des eigenen Quellcodes. Auch auf der kommenden JAX werden wieder viele Referenten ihren Beispielcode auf GitHub posten. Viele ähnliche Portale haben zuvor auch schon Ähnliches geboten, eines der bekanntesten ist sicher Sourceforge [3]. Aber anders als diese bietet GitHub keine Mailinglisten, keine Wikis, Projektgruppen oder andere klassische Communitytools. GitHub ist quasi das Twitter der Open-Source-Entwicklung. Jeder bleibt in seinem eigenen Bereich, ähnlich wie in seiner Twitter-Timeline, und interagiert mit anderen über eigene Beiträge (Tweets), die wiederum von anderen Usern in ihre Timeline übernommen werden (Retweet) oder auch nicht. Für GitHub bedeutet das konkret, dass User Follower der Repositories der anderen werden können und dafür Code-Patches anbieten, so genannte Pull Requests. Der Besitzer des Repositories kann diesen Patch per Pull-Kommando in seinen Code integrieren und dann sein Projekt auf GitHub konsolidiert bereitstellen (pushen). Jeder ist und bleibt aber dediziert für seinen eigenen Bereich zuständig. Verantwortlichkeit wird nicht geteilt. Die Technik ist fortgeschritten. Was sich nicht oder kaum geändert hat in den letzten Jahren ist, dass Personen und Institutionen sich gegenseitig verklagen. Oracle vs. Google, Apple vs. Samsung. Nachbarn verklagen sich, geschiedene Ehepartner. Trotz Demokratie, Proxy Pattern, Friedensbewegung und Unit Testing. So ein einsamer Programmierer steht bei GitHub schnell ganz allein im eiskalten, juristischen Wind des Patent- und Lizenzrechts sowie des Copyrights. Die Betreiber von GitHub übernehmen selbstverständlich keinerlei Haftung. Das Feature „Rechtsanwalt“ fehlt.

Bei Apache wird Verantwortung nicht nur geteilt, sondern auch institutionalisiert: Die Committer-Gruppe innerhalb eines Projekts, die das Project Management Committee (PMC) bildet, übernimmt gemeinschaftlich die Verantwortung für sauberen Code und ordnungsgemäße Releases. Und kommt ein solches Release zustande, übernimmt die Foundation die Haftung für die Mitglieder des PMC und theoretisch sogar für die User der Apache-Software. Das ist bisher allerdings noch nicht vor einem Gericht herausgefordert worden. Mit zunehmender Anzahl von Projekten und Releases wird das allerdings getreu dem Gesetz der Großen Zahl [4] irgendwann mal passieren. Das alles ist natürlich kein Argument, Git bei Apache prinzipiell nicht zu erlauben. In der Tat wird schon seit Längerem Git-Unterstützung für viele Projekte angeboten [5]. Darüber hinaus werden diese Apache-Projekte auch auf GitHub gespiegelt [6]. Kritisch ist sowieso allein der schreibende Zugriff auf Apaches Sourcecode Repositories. Lesen darf ja eh jedermann. Es muss sichergestellt sein, dass das PMC ein Release eindeutig, reproduzierbar und unveränderlich beurteilen und freigeben kann. Sonst kann die Haftung nicht gewährleistet werden. Dafür wird bereits an Lösungen gearbeitet. Letztendlich ist es wieder ein soziales Problem, nämlich dass das PMC funktionieren muss, und kein technisches.

Doch durch die Git-Diskussion ist noch ein anderer Punkt berührt worden: Tools. Firmen wie Facebook und Google entwickeln Software ganz anders als die meisten von uns heute, mit wesentlicher Unterstützung durch Werkzeuge wie kolaborative Review Boards, automatisierte Builds und Tests sowie mittels statistischer Analysen. Bei Facebook wird für jeden Commit ein „Risikowert“ ermittelt, der von der Größe des Patches, der Review-Diskussion um den Patch und dem Track Record des Entwicklers abhängt [7]. Von solchen Werkzeugen ist Apache weit entfernt, obwohl gerade dort das notwendige Know-how vorhanden sein sollte. Aber Apache-Releases gehen ja auch nicht direkt in die Produktion. Immerhin kommen Ant und Maven als klassische Build-Tools ja aus Apache selbst heraus. Da jedoch die Infrastruktur weitgehend von Freiwilligen aufrecht gehalten wird, wird offensichtlich nicht genug Energie für darüber hinausgehende Entwicklungsunterstützung freigesetzt. Es hat eine kleine Ewigkeit gedauert, bis intern LDAP für die Accountverwaltung verwendet wurde. Auch der Support für die Nutzung von Git entwickelte sich lange schleppend, getragen hauptsächlich von Jukka Zitting. Wie sehr das nun ein Zeichen für Apaches Niedergang ist, sei dahingestellt.

Bernd Fondermann (bernd[at]zillion-one.com) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt am Main und Member der Apache Software Foundation. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop oder Lucene und bietet unter zillion-one.com einen Big-Data-Hosting-Service an.
Geschrieben von
Bernd Fondermann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.