Was früher als Hack Day bezeichnet wurde, macht sich nun als Tech-Relations-Event zunehmend auch in Deutschland breit. Und was früher oftmals der gemeinsamen Verbesserung von freier Software oder zum Entwickeln freier Anwendungen im Umfeld von gemeinnützigen Einrichtungen oder OpenData gedacht war, wird zum Show-Event für Konzerne und Tech-Buden.
Welche Motivationen gibt es, solch einen Event zu veranstalten?
Ursprüngliches Szenario:
Ein Unternehmen hat ein Produkt entwickelt, dass von externen Entwickler genutzt, verbessert oder integriert werden kann. Die typischen US-Konzerne wie Facebook, Dropbox, Amazon AWS und co. bieten ihre Schnittstellen auch explizit für Produkte von Dritten an, also letzendlich zu einer kommerziellen Veredelung die allen Parteien nutzten kann.
Weiterhin kann solch eine Veranstaltung auch mehr oder weniger direkt dazu genutzt werden, leistungsfähiges, zielorientiertes Personal zu finden. Gerade im IT-Bereich differenzieren die Skills extrem und 1-2 Tage „Probearbeiten“ sollten recht gut zeigen, wie strukturiert und zielorientiert jemand vorgeht. Unabhängig davon, ob die Zeit zur Fertigstellung eines Produktes ausgereicht hat oder nicht!
Deutsches Szenario
Das die IT-Landschaft in Deutschland eine Katastrophe ist und mindestens 15 Jahre hinter den USA zurück ist, werde ich hier nicht näher betrachten, dazu habe ich bereits ausreichend gebloggt. Durch diesen Rückstand in Not geratene Konzerne wie bspw. die Deutsche Telekom, Axel Springer und einige andere, versuchen jetzt so schnell wie möglich jeden Trend mitzumachen um den Rückstand aufzuholen.
Und so werden auch hier mittlerweile Hackathons durchgeführt. Zu gratis Pizza und Getränken investieren Freiwillige ihr Wochenende. Doch statt die Grundlage für eigene Produkte zu bauen oder zumindest eine ausreichende Perspektive zu erhalten (Preis, Job, Finanzierung) verschwendet man hier mit schlechten, halbgaren APIs die Zeit aller Teilnehmer.
Aus Veranstaltersicht könnte man nun meinen: Hauptsache wir hatten Leute im Inkubator und nun einen tollen Beleg für unsere Innovation! Blöderweise sind Menschen schlauer als gedacht und so kommt es, dass Schmalspurevents auch nur Schmalspurentwickler anziehen: Leute die kein eigenes Produkt habe, die selbst oftmals nichts auf die Reihe bekommen und wahrscheinlich auch kein Problem haben, ein Wochenende zu verschwenden (keine Familie oä).
Keiner profitiert hiervon, ausser der Pizzabote und Club-Mate-Lieferant!
Weder sind die Teilnehmer motiviert, talentiert noch erfahren genug, einen nützlichen Beitrag zur Verbesserung des Produktes abzuliefern und andererseits dürfte das auch nicht wirklich gewünscht sein.
Vielleicht will man die eigenen Angestellten auch nur etwas unter Druck setzen, in dem man ein paar Frickel-Hipster einlädt etwas hinzukacken und am Montag den eigenen Entwicklern mangelnde Leistungsfähigkeit vorwirft. Ich weiss nicht, wie das in diesen Unternehmen zugeht, könnte mir das aber vorstellen.
Doch nennen wir mal konkrete Beispiele:
1. ZEIT Online
Als die ZEIT vor über einem Jahr angefangen hat, eine API bereitzustellen, habe ich aus Langeweile zuhause einen API-Wrapper in Ruby geschrieben. Mit Test-Coverage und CI. Leider bin ich auf einige serverseitige Bugs gestossen, die auch nach längerer Zeit nicht gefixt wurde. Eine Erweiterung der Funktionalität seitens der Zeit blieb aus, die Developer-Seiten der Zeit vergammelten und sind lächerlich, wenn man sich die Funktionalität der Guardian– oder NYT-APIs anschaut. Ich würde mich hier als Anbieter schämen!
2. Deutsche Telekom Developer Guarden Hackday
Ende 2013 hat die Telekom einen Hackday durchgeführt. Auch hier war die Teilnahme nicht besonders interessant: Die APIs der Telekom sind lächerlich. SMS verschicken und Voice-Apps kann ich mit anderen, bereits verfügbaren Diensten viel besser oder gar in Eigenregie abwickeln. Für SMS-Versand gibts es seit 15 Jahren unzählige Anbieter. Günstiger und globaler als die Telekom. Und mit fertigen Wrappern. Für Sprachanwendungen kann ich mit Twilio deutlich leistungsfähiger und einfacher umsetzen, als mit dem Krempel der Telekom. Es gibt aus Entwicklersicht schlicht keinen Grund hier mitzumachen. Aus Gründersicht auch nicht. Wer trotzdem kam, hatte nichts besseres zu tun, verschwendete also seine Lebenszeit.
3. Axel Springer Media Hackday
Auch der Startup-Inkubator des Axel Springer-Konzerns veranstalte jüngst einen Wochenend-Hackathon. Im Gegensatz zu o.g. Events waren auch viele (non-IT) Mitarbeiter beteiligt, weshalb hier womöglich das Ziel der Weiterbildung der eigenen Mitarbeiter (und teilnehmenden, anderen Medienunternehmen) im Vordergrund stand. Ansonsten waren die Grundlagen ähnlich schwach wie bei o.g. Veranstaltungen: Schwache APIs von Springer und Spiegel Online. Unzureichend Dokumentiert, leidlich RESTful. Unklare Verwendungsperspektive/Lizenzierung. Somit können externe, unbeteiligte SW-Entwickler die investiere Zeit vollkommen abschreiben, wenn sie nicht einen Amazon Gutschein, ein Dinner mit dem BILD-Chef oder ein Flugticket ins Valley gewonnen haben. Wohlgemerkt für ein durchgemachtes Wochenende.
Ich verstehe nicht, wie man glaubt durch etwas Pizza und Mate qualifizierte Leute für so eine schwache Perspektive ködern zu können? In Berlin findet man zwar immer 50 Leute mit Macbooks, die sozial vereinsamt, froh über gratis Futter und ein Dach über dem Kopf sind. Und die gerne eine Simulation der Produktivität und Innovation mitmachen um sich selbst besser zu fühlen. Zumindest für ein Wochenende.
Aber was nützt das den Beteiligten zukünftig? Nichts.
Harte Worte, zugegeben, aber eine Analyse der Teilnehmer gegen GitHub.com bestätigt meine Einschätzung: Die Leute sind vermutlich auf Jobsuche, aber keine self-starter, oder talentierte OpenSource-Enthusiasten oder Hacker, die Prototypen bauen. Sonst hätten sie viel bereits mehr Code veröffentlich… und wahrscheinlich auch etwas besseres am Wochenende zutun gehabt.
Hier die Daten: https://gist.github.com/rmoriz/fb2f053b5e61cd6dff06
Code dafür: https://gist.github.com/rmoriz/9205e131d9e35d0350f5
Teilnehmer-Quelle: https://www.hackerleague.org/hackathons/media-hack-day-2014/participations
Disclaimer:
Ich bin hier davon ausgegangen, dass der Hackerleague-Username mit dem möglichen GitHub-Username übereinstimmt. Stichprobenartig war dies zwar auch der Fall, trotzdem sind sicherlich einige False-Negatives und False-Positives dabei. Weiterhin sei natürlich auch darauf hingeweisen, dass Quantität an sich nichts aussagt, höchstens einen Trend markieren kann: Es gibt sehr fähige Entwickler mit sehr wenigen GH-Repositories oder Followern und genau das Gegenteil. Dem Leser wird unbedingt dazu geraten, die gemachten Stichproben zu überprüfen und selbst zu bewerten.
Fazit
Hackdays mit kommerziellen Hintergrund können durchaus interessant sein, müssen aber beide Parteien zufriedenstellen. Als Gastgeber will man wirklich nur Leute haben, die auch etwas auf die Beine stellen können und nicht nur die Mate wegtrinken oder, viel schlimmer, einem in falscher Sicherheit wiegen: „Juhu, wir hatten 50 total tolle Entwickler bei uns zu Gast und denen ist auch nichts neues mehr eingefallen!!!“.
Wenn Facebook, Google, Recurly oder Yahoo Hackathons machen, dann weil es ein Produkt gibt, dass Entwickler zum Geldverdienen einsetzen können oder sie an brandheisse Innovationen kommen. Somit lohnt sich die Teilnahme schon aus unternehmerischen Gesichtspunkten als Weiterbildung. Je unbekannter die Bude, je uninnovativer das Produkt oder je schlechter die Weiternutzungsperspektiven, desto geringer das Interesse. Das kann ich mit Essen oder besseren Preisen auch nur beschränkt steuern.
Positives Beispiel:
Ich möchte hier Philips als positives Beispiel erwähnen. Die sind ja auch ein europäischer Tanker und in der Internet-Szene bisher nicht wirklich besonders cool oder hipp. Mit dem LED-Lampensystem Hue haben sie erfahrene Profis aus den Niederlanden beauftragt, diese hat neben der Software-Produktentwicklung auch schon sehr früh eine API bereitgestellt, inklusive guter Dokumentation und ready-to-use Code für diverse Sprachen und Frameworks. Weiterhin sind die Spielregeln der Nutzung klar geregelt, wer seine Zeit oder gar Geldmittel darauf investiert, hat zumindest etwas mehr Sicherheit als ohne.
Für die Bereitstellung von Code wurde GitHub genutzt, für QA wurde StackOverflow verwendet. So konnte eine Community entstehen und viele Entwickler haben nützliche Anwendungen basierend auf der API realisieren können.
Die passende, nachgelagerte(!) Entwickler-Konferenz war also nur ein Nebenprodukt um Philips, deren Software-Team und involvierte, fähige, erfahrene 3rd-Party-Entwickler zusammenzubringen. Nicht umgekehrt!
Am Anfang steht das Produkt. Philips hat eine gute Basis geliefert.Die Zeit, Deutsche Telekom und Axel Springer bisher nicht.
Zaunpfahl-Wink: Ich bin gerne bereit — für Geld — Beratung, Entwicklungs- oder Koordinationstätigkeiten zu übernehmen: Bio und Kontaktdaten, mein GitHub-Account.
Ein mutiger Post. Aber auch ein verfehlter und ich Teilen unverschämter, wie ich finde. Im folgenden möchte ich ausführen warum.
Ich habe selbst am erwähnten Axel Springer Media Hack Day teilgenommen. Mich reizten dabei weder die Preise, noch unternehmerische Antriebe, noch Jobsuche, sondern vielmehr das Interesse an einem möglichen Austausch zwischen Entwicklern, Journalisten und den entsprechenden API Partnern. Die Tatsache, dass in diesem Beitrag allen Teilnehmern einfach mal pauschal „soziale Vereinsamung“ unterstellt wird, und dass nur weil keine offensichtlichen monetären Vorteile von der Teilnahme zu erwarten sind, halte ich daher für zu kurz gedacht.
Die Analyse der GitHub Profile der Teilnehmer finde ich prinzipiell einen interessanten Ansatz, aber leider auch respektlos. „Seht, was für schlechte Entwickler an dem Hackathon teilgenommen haben“. So kommt diese Auswertung rüber, und da hilft ein nachgeschobener Disclaimer leider auch recht wenig. Wenn die Darstellung ohnehin die hier aufgestellten Thesen nicht belegt, da es nicht mal einen Vergleichserhebung zu einem „guten hackathon Teilnehmerfeld“ gibt, dann kann man sie auch vollständig weglassen.
Gegen Ende hin wird dieser Beitrag zwar etwas konstruktiver, aber zumindest bei mir hatten sich bis dahin bereits folgenden Kernaussagen soweit eingehämmert, dass die – so hoffe ich doch positiven – Absichten des Artikels nicht mehr ankamen.
Pauschale Kernaussagen die ich höre sind:
– Veranstalter – ihr wisst nicht wie es geht
– Teilnehmer – ihr seid schlechte Entwicklern, und dürft daher nicht zu einem hackathon gehen
– zu guter Letzt – Der Autor weiß wie es geht und möchte euch allen gerne helfen, wenn er ordentlich bezahlt wird
Ja, dass ist überspitzt. Ähnlich überspitzt wie dieser Beitrag. Was passiert, wenn man das Feedback zu überspitzt und somit auch zu einseitig darstellt wie in diesem Beitrag? Genau, die Leute hören einem nicht mehr zu. Denn niemand hat Lust sich mit Destruktivem auseinanderzusetzen.
Es sei noch gesagt, dass ich ebenfalls angefangen hatte einen Post über den Hackathon zu schreiben, in dem es auch keineswegs um reine Lobhudelei für die Veranstalter ging, wie man solche Events noch interessanter machen könnten. Ich glaube, dass das möglich sein muss, ohne pauschal und großflächig über alle Veranstalter und Teilnehmer herzuziehen.
Ein letzter Hinweis: Ich denke es wäre fair gewesen, den Beitrag auf Englisch zu schreiben. Dann könnte ein Großteil der Entwickler, die an den entsprechenden Events teilgenommen haben, zumindest auch ernsthaft Stellung beziehen.
Hallo Sebastian,
ich kann leider die beschriebene Situation nicht beschönigen. So haben andere europäischen Medien schon sehr lange Schnittstellen in guter oder befriedigender Qualität. Z.b. Guardian, BBC, El Pais und viele andere. Von den US-Größen wie NYT ganz zu schweigen. Hier kann man natürlich mit ca 5 Jahren Verzögerung auch alle Fehler nachmachen, das wird aber die Lücke nicht schliessen.
1. Hackathons und Hackdays sind aber ursprünglich „gemeinnützige“ Veranstaltungen, dies zu unternehmerischen Zielen umzubiegen UND dabei auch noch gute Leute zu gewinnen, braucht eben mehr als nur eine Location und Pizza. Ganz gleich, wer der Veranstalter ist.
2. Qualifikation ist kein gleichmäßig verteiltes Gut, sondern basiert auf Talent, Ausbildung und Erfahrung. Die Unterschiede in der Software-Entwicklung sind hier zwischen Anfänger und Senior nicht einfach eine um ein paar Prozent gesteigerte Produktivität, sondern liegt vermutlich bei mehreren hundert Prozent (siehe: http://programmers.stackexchange.com/questions/179616/a-good-programmer-can-be-as-10x-times-more-productive-than-a-mediocre-one).
Wenn ich technologisch neue Bereiche betrete oder, auf externe Entwickler/Nutzer setze (API…), dann muss ich auch die besten Leute ansprechen. Leute, die überhaupt erst in der Lage sind, experimentelle Dinge zu nutzen, Leute die Vergleichswerte haben und deshalb auch qualifiziertes Feedback liefern zu können. Opensource-Aktivität ist ein ganz gutes Maß: Veröffentlichter Code erlaubt eine Art Peer-Review und das Beurteilen der Qualität (Struktur, Arbeitsweise, Tests, Coverage, Dokumentation).
Es liegt also in der Natur der Sache, dass sich Hackdays für inoffizielle/experimentelle Dinge an die fähigsten Entwickler richten müssen, die dann Feedback, Beispiele und Code liefern um daraus eine allgemein nutzbare Lösung herzustellen bzw. die Herstellung durch den Anbieter zu ermöglichen.
Wenn ich aber sehr viele Anfänger oder Leute mit sehr wenig OSS/Community-Aktivität habe, dann kann ich dieses Feedback schlicht nicht bekommen, egal wie sympathisch diese Leute auch sein mögen. Sie sind die ideale Zielgruppe für einen späteren Reality-Check eines (etwas reiferen) Produktes, also wenn bereits die Grundlagen geschaffen wurden.
Es gibt in Berlin extrem viele sehr gute Entwickler, alleine schon in der Ruby-Community. Wie kommt es, dass hier bspw. keiner teilgenommen hat?
3. Der direkte Tonfall ist bewusst gewählt worden um aufzurütteln, denn gerade Axel Springer behauptet von sich auch im digitalen Bereich ganz weit vorne mitzuspielen (auch beim Leistungsschutzrecht…). Das ist im Bereich Technologie nicht der Fall.
Die Kritik gilt also nicht Dir oder anderen Teilnehmern persönlich, sondern der Orga der angesprochenen Hackathons und dem jeweils zuständigen R&D- und Community-Managements. Die angesprochenen Probleme sind auch nicht originär Probleme von Springer oder dem MHD14, sondern typisch für die dt. IT-Landschaft. Ich habe versucht dies oben durch die Nennung weiterer Beispiele deutlich zu machen.
Das ich zu diesem Zeitpunkt nach dem MHD etwas gebloggt habe, soll zeigen, dass ich versuche eine konstruktive Verbesserung zu erreichen. Ein Teilnehmer oder gar Lieferant von Springer (Der ZEIT, Telekom…) wird dies vermutlich so nicht schreiben können ohne seine wirtschaftliche Existenz zu riskieren, hier bin ich frei, deshalb kann ich mir diese ehrliche Einschätzung erlauben. Ich glaube auch, dass Springer hier noch am ehesten zu einer Verbesserung, einer aktiven Handlung in der Lage ist und für unkonventionelle Entscheidungen und das konsequente Infragestellen alter Handlungsmuster/Vorgehensweisen bekannt ist. Jede Wahrheit braucht einen Mutigen, der sie ausspricht 😉
6. Ich hatte in den letzten 15 Jahren das Glück als Developer für sehr einige US-Konzerne und einige große deutsche Unternehmen arbeiten zu dürfen, z.B. Launch von Amazon Marketplace in 2002, bei Yahoo/FIFA WM 2006 und für einige kleine US-Tech-Startups (Remote). Die Unterschiede zu deutschen Unternehmen (Projekte bei Burda, Holtzbrinck, Allianz, SAP) sind schon technologisch einfach unfassbar groß.
Viele meiner Kollegen weigern sich mittlerweile schon für Startups und Konzerne aus Deutschland zu arbeiten, arbeiten lieber Remote für GitHub, Basecamp (37Signals) oder kleinere US-Unternehmen und rollen mit den Augen über das was bspw zur Zeit in Berlin, München und Hamburg läuft.
Andere bauen eigene Dienste aus Spass, technologischem *und* aus finanziellem Interesse (in Berlin bspw Travis CI, Launch/CO, Upstream Agile, Peritor (heute Amazon OpsWorks)).
Um diesem Brain Drain entgegenzusteuern, muss man deutlich attraktiver sein, als o.g. Alternativen. Sonst wird man eben nie diese Leute ansprechen können und nie in die technologische Nähe der „Vorbilder“ kommen (die bleiben ja auch nicht stehen oder werden selten „langsamer“).
Danke für die weiteren Ausführungen. Da steckten viele interessante Überlegungen drin. Den Kommentar fand ich konstruktiver und weniger bissig, denn in der Hauptsache ging es mir in meinem Feedback ja um die Tonalität der Blog Posts.
Ich habe meine Gedanken zum Media Hack Day auch mal aufgeschrieben. Da kann man denke ich auch deutlich erkennen, dass ich keinesfalls ein hackathon-Fähnchenschwenker bin 🙂 http://spier.hu/2014/03/media-hack-day-2014-how-hackathons-work/