… Could have been the title of this post 3 months ago. Given the recent layoffs and announcements in the past few weeks, it may seem short sighted to be overly excited faced with this news today. This was, however, a part of the announcements recently by Adobe regarding Flex. They are committed to contributing Flex (and several complimentary projects) to the Apache Software Foundation (ASF). I personally witnessed the commitment and plan for this at their San Francisco office. Many leaders of the Flex community gathered at Adobe SF by request of group product managers Deepa Subramaniam and Andrew Shorten this week. We heard from senior management on their new strategic vision for Adobe around digital marketing and digital media. We heard apologies for the accelerated and miscommunicated nature of the messaging of the past few weeks. And, we, most importantly, heard about the future of Flex as it may likely live in the ASF.

There has been a lot of focus lately on the poor messaging to the community around the announcements of late. I don’t disagree about how destructive and misguided this messaging was, but I do think it’s important to see it as the past and move on. Many in the community may criticize this idea. It would be easy to say this is one of many moves towards under valuing the community. Again, I wouldn’t totally disagree, but I do think this particular moment in history is different than in the past. Here’s a bit of an explanation…

The ASF model for development is much different than how a product is developed by a corporate software vendor. On an Apache project there are no project managers, product managers, senior vice presidents, presidents, CEOs, CTOs, development managers, senior engineers, or any other title of a role that you can think of; other than “commitor”. A commitor has the right to commit code to and vote on a project. You can read a lot more about the ASF process on their site. So, what’s the big deal? Why is this different than a time in the past that Adobe (or any company) did wrong by it’s community, said “we’re sorry”, and kept moving right along? – This time they’re actually handing over the reigns of the project to us; to the community.

Adobe will not have contributors on the Apache Flex project. Neither will Spoon, Roundarch or any other corporation or group. This is (technically) true because contributors are individuals. So, there will be some individuals who are contributors on Apache Flex that will also be Adobe employees, but they will not have any higher status or privilege than any other contributors on the project. This is by design. The design of the ASF. The process of Adobe contributing Flex to Apache is in the form of a proposal. That proposal states the intention of all initial commitors to create an Apache Flex project, among other details. Up until Apache Flex is realized as a full project there will be a phase of incubation. During this time Apache will work with the proposal submitters to help arrive at a proposal that fits the Apache model. This is to ensure the best possible arrangement for a successful Apache Flex. That’s why this moment is different than similar times in the past. By this model, Adobe gives up the sole control and direction of Flex and enters into a partnership with the community to drive the future of the framework, with the guidance of Apache. Without that partnership Apache will not accept this contribution. So, for those claiming Adobe is “giving Flex to Apache to die” or “dumping off Flex with Apache”, this is simply not true. It also shows a severe lack of understanding and respect for what the ASF does and has done.

We have not heard this before. This is a new approach with a high potential for excellent collaboration of all the individuals and entities that depend on Flex for critical business needs. These individuals and enterprises need a path to a future that enables their teams and businesses to deliver the high quality solutions they (and their customers) are accustomed to. For many enterprises developing highly complex applications with millions of lines of code, large development teams, and high expectations for success, Flex was and still is an extremely valid technology, for others it is a requirement. There are enterprises that are so vested in using Flex to build (or maintain) a platform for their businesses that a short term migration is simply not possible. This is not an understatement. Individuals from enterprises like what I’m describing were present and vocal at this recent Flex Summit.

So, what else did we hear as it’s relevant to Flex?

A paraphrased quotation, as I can’t remember the exact wording:

Adobe will not continue to develop Flex as a “stand alone” business.

It was also stated that Adobe does not currently have plans to develop any product targeted at enterprise scale user interface development. That’s not to say they aren’t developing tools for HTML5 development, just not a platform like Flex based on HTML5. They are committed to their runtimes for what seems like a minimum of 3-5 years. All of the current runtimes (less Flash Player for mobile browsers): Flash Player for desktop browsers, AIR for mobile (iOS, Android), and AIR for desktop (Windows, Mac OS).  However, it does seem clear that this runtime development will be focused in line with their new strategy of digital marketing and digital media. For Flash that means game development and video. There are certainly concerns around this regarding Flex. Game development is very different from enterprise class development. They have also stated that they will commit to backwards compatibility to meet all the dependencies that exist today in Flex 4.6.

My thoughts on the future of Apache Flex…

Apache is the the future for enterprise class Flex. For those highly skeptical and critical of Adobe, my message to you is this: The move to Apache is a big one and categorically different from anything we’ve seen in the past. Is Apache perfect? I doubt it. What it’s not is proprietary or corporate. It also answers in no way to a group of public share holders. It is not driven by senior management who are making business decisions to please those public share holders. It has no “layoffs”. It is not driven by the sales of an IDE. Further more, it has no goals of making profit – at all.  It was founded and is governed by folks that really understand open source development. It is one of the most respected software foundations in the world. What Apache Flex can be is a powerful force for the community to drive the future development of Flex and deliver in a way that holds true with the most important needs of the community – governed and guided by the Apache model for open source development.

I also believe that development is just one factor in the future success of Flex. Now that Adobe is stepping back from Flex there will be gaps in the future in the areas of: education, community (user groups, conferences, etc), quality assurance, support, tooling and potentially others. The Spoon Project may likely provide an appropriate group to support in these areas. There are already of mass of talented folks rallied around problems similar to these gaps in Spoon.

So, down to brass tacks:

What’s the reality of HTML5 as it relates to Flex at this moment in time?

HTML5 and open standards for the web will play a dominant role in the future of technology. What I believe is that this future is farther off and a bit more uncertain than many that make this statement. Let’s consider some recent figures by IDC. IDC predicts that 90% of smartphones and tablets will have HTML5-ready browsers by 2013. This means that 90% of consumers will be able to access your HTML5 application on their smartphone or tablet by end of 2013 (still 12 months away). However, the Gartner prediction of 81% smartphone penetration/adoption for 2012 was off by 50%. That stat is actually 44%. Even looking at the past month, smart phone purchases are only at 56%, well below that 81% prediction. The staggering number is 2015. 90% browser adoption of HTML5 is estimated for 2015. The Flash Player has historically had 90-99% adoption in desktop browsers. Additionally, there is no complete HTML5 specification. Notice: “Draft”.

In that respect an even more staggering number is 0. 0 is, technically, the current browsers that support an open standards based implementation of HTML5. Without a complete open standard it’s impossible to have compliance around that standard.

As Google, Microsoft, Apple, now Adobe and others seem to have consensus around the support for HTML5 in the future, none of these companies seem to do a great job at messaging when, exactly, this future is. Along with that I think many analysts are also doing a poor job of analyzing and messaging the capabilities of current web technologies. Part of that problem is the term HTML5 is now being used for anything related to HTML. Current support for HTML, JavaScript and CSS is a lot better than it was years ago, but comparatively (both to what HTML5 will be and what Flex and the like are now) it has many drawbacks. There is still a considerable amount of browser fragmentation to deal with, there are considerable challenges with styling for some experiences, there is a severe limit to the amount of performance of any browser’s JavaScript “runtime”, and there is still a lacking of support for mature approaches to software engineering when it comes to JavaScript. That doesn’t mean I hate JavaScript or think it isn’t a great tool for solving a lot of problems. It is my opinion on the comparison of the available choices for developing software on the web today – not the how that may or may not look in the future.

In the future that is next week and next year, Flex still has a place.. and that future is considerably more relevant than speculation on what is 3 years away… but back to the topic at hand: Apache doesn’t hedge on those futures. It supports a thriving community interested in building software. This is another huge reason that I see so much potential for Apache Flex. So, you won’t be hearing me making blanket statements like HTML5 is the future and you shouldn’t be building Flex apps. Or, Flex will be around for decades and HTML5 is completely overrated. Anyone who makes makes these kinds of huge generalizations is in one (or all) of these categories:

• A person who is trying to sell you something
• A company man (or woman)
• A technology zealot

If you’re an engineer or part of management driving the technological future of your organization, it’s probably not a good idea to listen to these kinds of people as your only source of information (or maybe at all). The sales person is driven by profits. The company man is driven by a career towing the company line. The technology zealot holds to their particular technology views without necessarily analyzing the reality of the tech landscape. These are all risky people to put your faith in. The technologist that can analyze trade offs, discuss options, strategize to meet business goals effectively; that is a person who I trust. That is a person who I want on my team, working with my customers, and solving critical technology problems with me.

More to come on Apache Flex as it develops…

Google+ comments.

Flex 3 with multiple selectors:

This example shows how powerful CSS can be with the ability to apply multiple selectors to each component. Each style is used generically and applied to a component regardless of the component’s type. So, we’re able to share a “redBorder” selector between button1, innerBox, and button2 without adding unique styles about the button’s text colors, padding, etc to the “redBorder” selector.

Degrafa skin with styled elements:

This example shows a simple Degrafa circle with it’s style properties (color, angle, alpha) abstracted into CSS. From a skinning perspective the lack of styles in Degrafa has always been just a little annoying for me. On large, enterprise applications it is essential to create conventional approaches to tasks performed throughout the app. Skinning is one of these tasks. Without the support of CSS, styling a Degrafa skin is much different than styling a halo skin, but now with the CSSPropertyInjector util a similar styling approach can be taken with both skins types.

Flex Chart with styled elements:

Another painful set of elements to style is the Flex Charting Framework. In this example you’ll see that the color and weight of stroke of the LineSeries is styled using CSS.

Flex 4 FXG with styled elements:

FXG is similar to Degrafa and easily styled using CSSPropertyInjector.

So, this is a start for CSSPropertyInjector. It’s checked into flexlib and ready for you to play with. I look forward to your feedback on making this a complete addition to flexlib. Please feel free to leave a comment on this post, e-mail me directly, or comment in the flexlib Google Code project.

We’ve released the first public beta on Google Code as well as opened a Google Group. There is also a repo for Merapi examples.

Here are the important links:

http://merapi.googlecode.com/
http://merapi-examples.googlecode.com/
http://groups.google.com/group/merapi-project

To find out more, keep an eye on our blogs. We’ll be releasing more tutorials and answering questions as they appear.