Adobe Engage: Good Morning Apollo

I’m here at the Adobe Engage event with James, Anne, and several other influencers and Cool Groupies. (Interestingly, RedMonk is the only analyst firm here…right?.) The premiss of the day is showing off Apollo to all these folks, drumming up buzz, and engaging (the word of the day) with All of Us around Apollo. There’s many coders, Internet Rock-stars, PR Mavens, and, of course, Adobe Flex, Flash(?), and Evangelist folks.

As I was telling Duane, I’ve seen the basics of Apollo previously at MAX, in briefings, and in other contexts. Nonetheless, what’s most interesting here is to see the reactions of other people. I still have mixed feelings about Apollo and RIA’s in general. I will be honest though: I have been softening up since (a.) paying attention more, and, (b.) Bruce Eckel’s case for using Flex for UI development.

Apollo itself is, to be blunt, a new GUI framework evolved from Flash, Flex, ActionScript, and lots of XML. The idea is “brining the web to the desktop” (not a direct quote) or, as Kevin Lynch put it this morning during a great presentation/Q&A,

we’ve really seamlessly integrated the web applications into the desktop model

Yuh!

For Adobe, Pretty is a Feature

The demos for Apollo have always been compelling both visually and functionally. Adobe always managed to look super-cool without having the snooty ‘tude of Apple. Layering a nice looking, quick moving, offline/online enabled GUI on-top of eBay is a great demo awesome. Layering a nice GUI on-top of MySpace’s goat-but ugly and slow interface would be awesome as well …and I’d probably use it.

Speaking of that attitude, Kevin Lynch, as a presenter, works well in this format as he always comes across as genuine and caring. You never get the sense that he’s out to make lots of money above making what he thinks are great user and developer experiences.

Native Desktop Integration

For sometime, tight(er) integration with the desktop has been missing. Windows, OS X, and Linux have had a strangle-hold on doing things natively. Ever since Microsoft has dominated the desktop, Everyone Else has been trying to write UI frameworks around Windows, obscuring out Microsoft with deep clouds of APIs, FUD, and alternative UIs. The last White Knight to go up against — Java desktop — turned out more like Don Quixote than Sir Gawain. (Now, there’s been much scrambling of late to fix that, but the web, Microsoft, and things like Apollo have a huge jump over Java GUIs.) Now we have the web, which is a sort of de-centralized approach to combating Microsoft (insert your own n-th generation warfare metaphor here).

As we’ve covered before, the position of Adobe is similar to the one I often cite from Joel from several years ago: Hey! I want that nice desktop functionality! At the same time as providing a desktop GUI, Apollo is inherently web-aware and intended to be used as a network application rather than a desktop silo’ed application. Some nice screencasts are more called for than endless text describing Apollo.

Revenue Model & Open Something

Adobe’s model for making money is to sell tooling around a free technology. That is, they want to develop a market out of core and freely available technologies, and then sell the best tools for producing and consuming those technologies. Now, sure, there’s the temptation of locking into tools, embrace and extend, and all manner of things to be two-faced about a tool-driven business model.

Since Adobe MAX Adobe has done quite a lot to build trust with me that they’ll stay true to “giving away” the core technology and try to compete on tools and tools integration. I’m still very cautious, but I no longer have a knee-jerk reaction that Adobe will chase the fast-buck in favor of lowering barriers to entry. There is still much to be proved and done on an ongoing basis, but at least they are moving and doing. Open source is by far the wrong comparison to pull in here. But, there is something more open happening than I’m used to from a closed source company. They’re trying to navigate the waters Sun did with Java before going open source in strategy, and it’s interesting to watch.

I’ve spent, and spend, a lot of time observing and interacting with Adobe on this front, sometimes seemingly to the point of confusion by info and perspective over-load. And, as the disclaimer at the end says, RedMonk has a money-relationship with Adobe. At this point — and to one of the points below — it’s time for all of this to simply play out and just see if this dog will hunt. Otherwise, it’s just endless equivocating.

Questions & Concerns

Below are off-the-top-of-my-head concerns. I’m not really definitive about them yet since Apollo is still, really, yet to be released and, to be frank, since I don’t have first hand experience with it. Which is a long way of saying, hey, I could be wrong on these things below: I’ll have to follow-up with reactions and reality.

The Usual Things

In general, all of the usual concerns with a GUI framework are present. Namely, that developers will create crappy interfaces, spammers and fishers will create malicious apps, and the lack of native integration. These concerns are near impossible to really predict ahead of time: you just have to release the framework into the wilds and see what happens. Every framework maker, including Adobe, tries to avoid Bad Things from happening, but the ultimate test is just running it and seeing what happens. My point in mentioning this is that there’s really not much to say about them beyond seeing what happens.

XML

Pulling back to more meaty concerns, my first concern is how much XML is involved. Few developers I talk with “like” XML as a programming medium and I have a personal distaste for “declarative programming,” preferring more direct manipulation through scripting. It’s a topic Charles and I talk about frequently on DrunkAndRetired.

Tomorrow morning I’m going to a hands-on half day with Apollo. I’m hoping to actually code something or, at least, watch someone else code something. In doing that, I hope to figure out how XML-intensive Apollo is. My hope is that it’s just one way to do things or, at worse, that something else can be layered on-top XML to avoid having to “code” in it.

Co-development

Next, despite the frequent mentions of usability studies (esp. around the install and security/sandbox interaction) and the fact that Apollo is Adobe’s third go at this framework, I’m a bit concerned that it’s been developed in classic Big Bang style: code, code, code for years and finally release The Perfect Platform to developers. Sure, you have all sorts of early release coders and other folks playing along. But, there’s not the continual Phoenix rebirth and improvement that we see in open source. That’s a dramatic way of putting it, but the point is that brutal innovation is always hard to achieve if you’re not releasing early and often.

Brutal innovation let’s you try things out, scrap things don’t work, and, most importantly, pull in suggestions and even fixes from users and developers. Open source is one model of this, the evolution of HTML, microformats, OpenID, and non-JSR born Java middle-ware are examples. Sometime over the next year, someone will need to write-up how OpenID evolved without being explicitly organized beyond mailing lists, blogs, and other “loosely coupled” project management (I suspect Cowboys and Heros are involved, but, hey, still interesting).

To cut to the chase: having been developed in a “closed” manner, has Apollo had enough feedback from developers and users to be what both want? I’m not suggesting (only) that it should be open source; like I said, that’s just one (very well understood) method. Rather, I’m pointing out that Apollo seems to have been developed in the “classic style” of technology development instead of the “Wikinomics”/crowd sourcing/co-development/Wealth of Networks style that all us go goo-goo over.

The question is: will the lack of wide-scale experimentation, rapid feedback loops, and refactoring matter for Apollo’s success?

One topic that James and Tim O’Reilly keep pounding is making users the center of concern rather than content producers. One wonders how many users vs. developers and producers Adobe has engaged with in developing Apollo, PDF, and everything else. Not having co-developed the platform, there is no implicit inclusion of those concerns: you have to work to pull them in.

Introducing a New Framework

As mentioned above, Apollo is a new UI framework, centered on the pivot of being “web enabled.” I applaud and welcome the goal. That said, adoption of new UI paradigms is a slow and painful process. It’s yet another thing to learn and a new context to re-learn all the old patterns and mistakes.

Much to the consternation of framework vendors through time, developers will take the path of least resistance and ignore “more powerful” frameworks in favor of easy to use ones. A large part of that is how easy it is to install the platform (which came up many times this morning), while another is pulling over the idioms and “gestures” of the dominate style of coding to the new. See Bruce Tate’s history of Java’s rise by pulling in C/C++ coders.

This is perhaps Apollo’s “strongest bad” as, I suspect and as this event itself proves, Adobe has the know-how, money, and incumbent coder base (Flash, Flex, [Action|Java]Script, and even Ajax developers in the sense that they’re part JavaScript developers) to push through the framework more so than smaller, newer companies. For all the Rails and Springs out there, there’s thousands of other DOA frameworks.

Of course, here, the battles are classic in nature: Microsoft, Sun, and all the usual Elder Company players who employee endless evangelists (yay!). You could throw in “open source” and “the community” here, but I the point of the lack of co-development sort of makes those implicit more than explicit competitors.

As a side-note, another question is: will Apollo be a core framework or just a “feature” as Flash currently is for things like the Flickr orginizr?

PDF, Flash, Flex, Apollo…?

Adobe now finds itself with a mixed portfolio of similar technologies. Will people use Flash, Flex, Apollo…or even PDF w/forms to do their development. How do these things relate? The answer for the moment, from David Mendels this morning, is that Flex can be wrapped easily in Apollo. Technologically, I don’t really see a problem here.

The problem is one of attention, understanding, and messaging. Should developers be using Flex or Apollo? What’s the point of Flex with Apollo? Is Flex now a part of Apollo? How’s about Flash?

My sense is that there’s a layer above all of these worlds in Adobe land. As an example, the Java language and VM as the spanning layer above/between Java SE, ME, EE, and other Java-worlds. I’m not quite sure what it is though. [Action|Java]Script?

How Hackable is Apollo?

The last topic is a question is one of how open and “plain text” Apollo applications would be. Data in the web is inherently “harvestable.” At worse, you can always go screen-scrape text, while at best you can get the raw data via microformats, JSON, or even SOAP. While the saying goes that “information wants to be free,” the oft forgotten lead up to that quote is “information wants to be expensive, because it’s so valuable.”

That is, software vendors see locking up your data as an easy path to monetization. The cliché example is reputation in eBay, but there’s even more annoying things like having to log in to MySpace of FaceBook to look at social networks.

As I said above, a web applications, at some point, has to become (X)HTML which is as close to “plain text” as you can get without being plain text. Once you have plain text, getting your data is possible. Other UI frameworks are not always such: for example, Acrobat can prevent you from cut-n-pasting text from PDFs (!).

“Roach motels” are one of my favorite windmills, and the point of being hackable is to defeat vendors who go the easy path of locking down my data. My question here, then, is how hackable and open is the data in Apollo applications? How easy is it for developers to limit my access to data in an Apollo applications?

Of course, this is a portal into the whole “mash-up” or “composite application” discussion. Without hackable applications and open data, mash-ups and composite apps would be impossible.

Notes

For those who enjoy them, here are my raw notes from this morning:

…

Off to lunch…

Disclaimer: Adobe is (or is almost now) a client. They didn’t pay for this trip though. Sun and parts of Microsoft are clients as well.

Technorati Tags: actionscript, adobe, adobeengage, adobeengage2007, apollo, flash, flex, redmonkadvice, redmonkclients