Die Zukunft von Flex

Der Flex Summit ist einige Tage vorbei und hier wie versprochen nun der gegenwärtige Stand der Dinge und einige persönliche Kommentare zur Zukunft von Flex.

Seit meinem letzten Blogpost hat Adobe das Incubator-Proposal an Apache geschickt. Auf der Wiki-Seite des Proposals findet sich neben vielen anderen Informationen zu angedachter Projektstruktur und so weiter auch die Liste der initialen Commiter zu einem zukünftigen Apache Flex (unter "Initial Committers").

Hier fällt zunächst auf, dass es sich entgegen ersten Planungen mit 12 oder vielleicht 24 Committern nun um eine Liste mit 36 Personen handelt. Daran ist nichts falsch – und nur gerade mal 6 der 36 Committer stammen von Adobe. Wer also dachte, dass das Proposal bereits an mangelndem Community-Willen scheitere, der wird hier eines Besseren belehrt.

Peter Elst hat einen weiteren Blogpost veröffentlicht, der die Ereignisse der letzten Tage im Rahmen der Diskussion zum Flex-Proposal zusammenfasst. In der Zwischenzeit hatte ich auch Gelegenheit mit Dirk Eismann, einem der Teilnehmer des Flex Summit in San Francisco, zu sprechen und mir daneben anhand des von Adobe dort mitgeschnittenen Audio- und Video-Materials eine eigene Meinung zu bilden.

(Warnung: Shameless plug für meinen Englischsprachigen Podcast "2 Devs from Down Under": Wer Interesse an Dirks Meinung zur Zukunft von Flex hat, kann mehr dazu in Episode 18 des 2DDU-Podcasts erfahren.)

Sollte Flex in den Apache-Incubator aufgenommen werden, so sehe ich das nun immerhin als eine gute Entwicklung. Vor allem deshalb weil es zumindest eine initiale Committer- und Contributer-Community um Flex herum geben wird, die zum Großteil nicht aus Adobe-Angestellten besteht. Flex kann das – und selbstbestimmte Einflussnahme seitens der Community – nur gut tun.

Nur: Wie selbst bestimmt ist eine Apache-Flex-Community wirklich? Mein Hauptproblem ist nach wie vor die Tatsache, dass Adobe weiterhin die Kontrolle über Flash Player und AIR hat und diese Laufzeitumgebungen im Prinzip je nach Willen des Top-Managements oder der Aktionäre von einem auf den anderen Tag vom Markt nehmen kann. Hier bieten sich zwei Lösungsansätze an:

1. Flex 4.7 oder Flex 5 und folgende Versionen werden "einfach" nur gegen Flash Player 11 und AIR 3 entwickelt. Niemand zwingt Apache, Flex-Versionen des Flash Players und AIR zu "jagen".
2. Wer sagt, dass Flash Player und AIR auch in Zukunft die (einzigen) Laufzeitumgebungen für Flex bleiben müssen? Werkzeuge und/oder Experimente wie Jangaroo oder FalconJS stellen zumindest interessante Startpunkte für die Zukunft dar, und Flex mag in Zukunft ein Framework für die Anwendungsentwicklung mit sowohl Flash als auch HTML/JS als Zielplattform werden.

In dem Interview mit Dirk kommt am Rande auch zu Tage, dass Adobe neben dem Design-Mode in Flash Builder auch das so genannte datenzentrierte Entwickeln von Anwendungen nicht mehr weiter entwickeln wird. Dabei handelte es sich um eine Art interaktive Codegenerierung, die basierend auf Services verschiedener Technologien (unter anderem Java, SOAP-WS, ColdFusion, Zend-PHP, REST) Flex-Quellcode zur Dienstanbindung generiert hat. Dazu konnte dieses Feature auch verschiedene Maskentypen wie CRUD-Formulare oder Übersichtslisten erzeugen.

Es stellt sich die Frage, wo dann noch der Mehrwert von Adobes Flash Builder gegenüber anderen Flex-Entwicklungswerkzeugen liegen wird. Hinsichtlich Produktivitäts-Features haben Werkzeuge wie FDT oder IntelliJ längst zu Flash Builder aufgeschlossen, wenn nicht gar überholt. Sollte Flash Builder 5 nur Flash Builder 4.6 ohne Design-Mode und datenzentrierte Codegenerierung sein, sehe ich keinen besonders großen Markt für dieses Werkzeug mehr.

Was halte ich denn nun persönlich von Adobes Entscheidungen und der Zukunft von Flex? Ich sehe für mich drei Optionen:

1. "Run and move on" – Flex ist tot, hat keine Zukunft mehr (und wenn, dann nur für ein bis zwei Jahre), und HTML und JS/CSS sind das einzige Maß der Dinge in der Zukunft.
2. 100% pro Apache Flex, und ich beteilige mich aktiver in dieser Community und versuche Flex als Framework für Webanwendungen weiter zu entwickeln.
3. "Sitting on the fence" – Mal schauen und weiterhin (neben anderen Technologien) mit Flex arbeiten, Kunden Vor- und Nachteile darlegen und zumindest für die nächsten 1-2 Jahre abwarten, wohin sich ein Apache Flex entwickelt.

Zur Wahl stehen Option 2 und 3 – ich tendiere jedoch stark zu Option 3. Der Hauptgrund für meine Wahl dieser Option liegt in mangelndem Vertrauen in Adobe hinsichtlich der Zukunft seiner Flash-Player- und AIR-Plattformen.

Die Ereignisse von Mitte November haben zu klar aufgezeigt, dass es im Zweifelsfall nur um Shareholder-Value geht und nicht um langfristige Bindung einer Entwicklergemeinde. Diesen Vertrauensverlust hat sich Adobes Top-Management zuzuschreiben, und es würde wohl Jahre konsequenter Arbeit dauern, bis Entwickler wieder ernsthaft an Adobes Committment zu einer Technologie glauben werden.

Weitere Gründe: verstärkte Nachfrage nach Nicht-Flex-Lösungen, die Notwendigkeit auch mit solchen Lösungen Geld zu verdienen und mehr Spaß und Zeit mit einer größeren Bandbreite von Technologien zu verbringen. ()