Flex SDK Going Open Source: Video and Analysis

As Ted, Ryan (see his post for another good link round-up as well), Scoble’s video and others covered at length last night, Adobe announced that they’re open sourcing the Flex SDK. Here’s the official press release.

As you can imagine, Adobe being a client, RedMonk has done a bit of work with Adobe over the past month or so on the issue. Adobe moved at an impressive, break-neck speed: I was actually surprised and enthused to see how quickly they explored the topic, decided, and then delivered.

Talking with Jeff Whatcott

While I was at SAP Sapphire this week, I had the chance to talk with Jeff Whatcott, VP of Marketing & Business Development for Adobe’s Enterprise & Developer Business Unit, on tape:

We covered the general announcement and, beyond “the facts,” what the decision making process was for Adobe.

(Pardon the choppyness of the tape at the end, I’m not quite fully adept at video production yet.)

Widening Flex’s Strategic Appeal to Developers

I’ve been cautious about Flex as a viable, large scale development platform largely because there was no “real” open source aspect to it. In my personal podcast a few episodes ago my podcast buddy Charles and I talked about this issue in-depth. In summary, as a developer you want the tools and technologies you rely on to be a “safe bet” of your time and effort.

When something is open source, the bet can be less riskier. The alternative is taking the risk that a vendor will either close up the technology you rely on or jack up the prices. That is, if things go really pear-shape, you can always fork, for better or worse. In the more rosy scenarios, you can work with the project to control more of the current and future life of the technology you depend on.

Obviously, as I commented when Adobe took PDF to ISO, my inner-“standards bigot” is a bit softer on Adobe now. Granted, this is just an announcement of intent and road-map. Adobe is just at the beginning of truly open sourcing the Flex SDK.

Going Open Source

There is still the issue of the core component of the Flex world, the Flash player. That’s not open source. Sure, the ActionScript VM, Tamarin, was open sourced earlier, but the “whole product” of the Flash player is not. And while you can read tea leaves and make all sorts of guesses, the process of open sourcing is very much one of do’ing rather than hinting. My sense is that the actual Flash player itself is the hardest thing to get everyone (inside and outside of Adobe) happy with open sourcing. If everyone is not immediately on board, choosing the Flex SDK instead of “everything” is a balanced way to start a plan for open sourcing the more of the Flex ecosystem.

As we’ve learned from watching and working with other closed source companies open source their software, the process is more about slow cultural change than just uploading all the code to sf.net. Meaning: it’s largely a process of compromising and experimentation rather than all at once.

Let me clear here: I don’t know Adobe’s plans for any future open sourcing, or if there are even any plans at all. I have no secret knowledge and they haven’t spoken with me beyond the Flex SDK. This “plan” business is just my own wishful thinking. That sad, you can bet that RedMonk will push Adobe for more, of course.

The Buzz

OK saying “this changes things” doesn’t mean jack. Let’s put it this way: I’ll now consider recommending Flex to my employer. —Sam Buchanan

The reaction I’ve gotten from the architects and developers I’ve talked with about open sourcing the Flex SDK is positive. Most of these people had the same general concern of working in a closed source ecosystem as mentioned above. Despite that, even before today’s announcement, they’ve come to see Flex as something interesting rather than something to ignore.

Now, if that positive feeling and the cautious curiosity lasts, they could warm up to using Flex. There’s still the case of paying for tools, but as one enterprise architect said: if it gets the job done quickly and easily enough, maybe paying for tools is worth it.

For this large class of developers, getting to that line of thinking is Adobe’s next big challenge. In the Eclipse era, paying for tools is weird. Even excellent profilers are free. The key to shifting to tools spending is making a sort of development TCO argument: sure, you could spend your time futzing with the front-end, getting your hands dirty, dukesin’ it out…or you could just buy some tools to avoid all that. It’s certainly worked for Genuitec‘s MyEclipse, though their price-point is lower.

GPL & MPL

The one issue that’s come up in my conversations around this is the incompatibility of the MPL with the GPL. Essentially, the problem is that the GPL and the MPL impose their own “restrictions” (to use the cynical diction) on what can and cannot be done with the code. Thankfully, Tom Hull has a nice write-up. To a BSD-man such as myself, it’s all sort of armchair-lawyer comedy.

But, hey, I’m not going to tell you which True Belief is the best: pick a licensing scheme that matches your desires and quells your fears. My interest is not so much about any particular license and more about the desires and fears that drive an organization to pick a given license. Don’t get me wrong, I’m not being dismissive of any given side or license. Nor am I ignoring the implications of MPL when it comes to co-shipping with GPL’ed code. If anything, the read should be that I’m pragmatic over passionate/decided about open source license picks. I will say this, though: I think the GPL+Exception, plus dual licensed with the same old commercial terms (as Adobe is doing with Flex SDK) pick that Sun made for Java was about the best option a company could pick.

Fear is always the major driver here: when open sourcing, you’re always fearful of loosing control such that your enemies can use your open sourcing against you (here, obviously, Microsoft, old habits die hard and enterprise scares are forever). I’m not sure there’s much valid in that fretting (like I said, I’m a BSD-man). But, come on, if you’re open sourcing a previously closed source piece of software, your existing world-view will cause you to worry about vendor-sports and your existing revenue moels, making escaping The Fear of Open-sourcing tough.

Ajax, Rails, and Friends

Pulling back from the open-source-sports, what I’m interested in here is seeing what happens with the weird relationship between Adobe and the web/Ajax world. From the many conversations I’ve had with Adobe since my “forking the web” piece last Fall, I’ve come to a much more nuanced understanding of Adobe’s feelings about Ajax. It’s hard for them to articulate it exactly, but they’re not looking to rub-out Ajax as much as that may seem the case. Even the idea of “evolving the web” isn’t quite right.

As I wrote last month on Adobe “Apollo,” my feel is more that Adobe is targeting the desktop GUI world rather than the web. Indeed, I can see that the web/Ajax world and Adobe could get along — it certainly works at flickr, YouTube, and many other sites. Looking out long term, I’d be more worried if I were a GUI framework than a web framework.

Also, least you, I, or even Adobe forgets, there’s the ColdFusion universe. While Flex and Apollo have gotten the lime-light of late, ColdFusion — though it be closed source — is all about “pure” web applications. My desire is to see Adobe slightly tune their conversation around UI’s to: if you want RIAs and desktop GUIs it’s “Apollo,” whereas if you want “pure” web apps, ColdFusion. As I mentioned to some Adobe folks recently, that would have nuked a lot of the “Adobe forking the web” conversations I’ve been in over the past 6 months.

What Next?

So, why do you care? What should you do?

If you’re a developer, architect, or someone who writes software, give Flex a little more consideration when thinking about the UI layer. There are many, many other options from straight up HTML (with rails, PHP, Java, or whatever driving it) to .Net GUI’s to Eclipse RCP. Also, I don’t have a good read on the maintainability of Flex code (is any code really maintainable past 3.0, though?) and I don’t get the feel that the Flex community is churning out libraries and frameworks like, say, the Java, PHP, or even ruby worlds.

I get the sense that all these new UI frameworks — esp. Flex and Rails — could give organizations to “light” the dark-data and processes locked up in legacy systems. That is, by having nicer UI’s on-top of legacy back-end systems, we might actually be able to move the IT ball forward a bit without mass rip-and-replace. That’s a big theory, but it’s one with pursuing over the next few years.

I’m a cantankerous old web app guy (I write and “think” in HTML), so I feel weird saying it, but Flex is getting more and more momentum and appeal to developers I talk with. I’d be an idiot to ignore what actual developers are telling me, and while there’s not, by far, a majority of people “big” on Flex, there are at least some which is more than the zero I’d been used to hearing from.

For a more enthusiastic quote, In the words of one rock-star developer I talked with this week, “if you’re looking for an instant job, put either ‘Rails’ or ‘Flex’ on your resume.” Bruce Eckel’s piece on hybridizing Java is a must read as well.

Still, for those in my cantankerous-lot, the idea of using Flex is a bit weird. Open sourcing it, though, helps remove some of that weirdness. It gives Adobe the chance to engage further with developers outside of the Flex world beyond the undeniable “hey, cool!” that Flex demo’s can achieve.

Going forward, any given developer tool will have a much better chance of being both widely successful and genuinely what developers want if it’s open source. If you believe that, as I do, then open sourcing the Flex SDK is a good step. Now, “all” that’s left is the hard work of evangelizing and helping developers become rock-stars because they use Flex. More so than open sourcing a closed source code-base, that’s a harder row to hoe for any technology. Should be fun ;>

Disclaimer: Adobe is a client. As mentioned, we worked with them on open sourcing the Flex SDK as well. Eclipse, Sun, Genuitec, and parts of Microsoft are clients as well.

Technorati Tags: adobe, flash, flex, flexsdk, mpl