Adobe Apollo is dead on arrival

Adobe Apollo is dead on arrival

Summary: After reading an essay by Bruce Eckel about how great Adobe Apollo was going to be, I had high hopes for the product. But after reviewing the alpha release, those hopes were quickly dashed...

SHARE:
40

After reading an essay by Bruce Eckel about how great Adobe Apollo was going to be, I had high hopes for the product. But after reviewing the alpha release, those hopes were quickly dashed.

Apollo represents a new breed of applications that erase the line between desktop and web applications. For lack of a better name I call these "Webtop" applications. In theory, you could write an application once and deploy it on the web and on the desktop with minimal modifications. Speaking as a developer, this sounds great. Unfortunately Adobe's implementation leaves much to be desired.

The biggest problem is the licensing. Apollo is a closed, proprietary system by intentional design. The runtime is closed, and the tools are expensive. While there is a free toolchain available, any serious development will most likely require the commercial tools. And don't hold out too much hope for significant open source competition. Adobe's licensing terms, which you have to accept to use their runtime and SDK, specifically prohibit it:

...Any such information supplied by Adobe and any information obtained by you by such permitted decompilation may only be used by you for the purpose described herein and may not be disclosed to any third party or used to create any software that is substantially similar to the expression of the Software.

There are technical problems as well. Despite describing itself as "allowing developers to leverage their existing web development skills", skills such as HTML, JavaScript, and Ajax are second class citizens in the Apollo universe. The focus is clearly on Flex and Flash technologies. You program in ActionScript, a language that is almost, but not quite the same as JavaScript. While you can embed an HTML panel in an Apollo application, that browser is a completely separate environment. JavaScript code runs in the browser, and an ActionScript/JavaScript bridge is provided to let the two sides communicate with each other. Sounds simple, right?

Adobe is hoping to leverage its tremendous success with Flash into webtop application development. Since Adobe is largely a tool company, their business model is to sell programmers lots of tools and upgrades, locking them into the Adobe brand. It's a fine business model if you can pull it off, but today's Web 2.0 developers are savvy and spoiled by free tools and libraries.

I think webtop applications represent the next natural stage in the evolution of software development. Apollo will serve to stimulate more discussion and innovation in this area, which is good. But until Adobe loosens the reigns on Apollo as Sun has with Java, then it's unlikely to attract much more than a niche following.

Resources:

Topic: Enterprise Software

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

40 comments
Log in or register to join the discussion
  • Alpha Focused on Flex

    This alpha was specifically focused on Flex/Flash, which is why Ajax seems like a second class citizen. When the final product ships, Ajax will be on par with Flash/Flex to the point where you won't ever need to use those "proprietary formats" or "expensive tools". You can just port your current Ajax workflow into Apollo and then use the Apollo-specific JavaScript APIs to add desktop functionality to your application.
    ryanstewart
    • Looking at 1.0 feature set

      I know the alpha is somewhat limited but a) it's an indication of what Adobe thinks is most important, and b) even when the whole 1.0 feature set is there, you'll still have the separation of browser and not-browser worlds.
      Ed Burnette
  • lets try to explain some misconceptions

    I think there are some clear misconceptions to your story -- let me go through some of them

    "The biggest problem is the licensing. Apollo is a closed, proprietary system by intentional design. The runtime is closed, and the tools are expensive."

    Don't see how you come to that conclusion -- there is a free SDK, the technologies used are HTML, AJAX, Flex that you can write using the text editor of your choice (the Flex SDK is free of charge as well).

    If you're referring to Flex Builder, which is a commercial product, the Apollo Extensions they released with the alpha are there to make the workflow easier for existing Flex developers that use that product. By no means is it the only way to do Apollo development.

    There is no pricing information available whatsoever on the Apollo extensions and the Apollo SDK and runtime will be available free of charge.

    "You program in ActionScript, a language that is almost, but not quite the same as JavaScript"

    ActionScript 3.0 is strictly compliant with the ECMAScript Language Specification, Third Edition (ECMA-262) and supports E4X -- no proprietary voodoo code here.

    "While you can embed an HTML panel in an Apollo application, that browser is a completely separate environment."

    Apollo implements the webkit engine (used in Safari), it can be used as a top-level application or embedded into a Flex app. If used in a Flex based app is is rendered within the display stack, you can integrate it with other content and do any manipulation on it you like.

    There is even script bridging to allow javascript in the HTML engine to talk to the application it is embedded in. HTML inside Apollo is not a closed shell.

    "And don't hold out too much hope for significant open source competition. Adobe's licensing terms, which you have to accept to use their runtime and SDK, specifically prohibit it"

    while it might not be open source, developers will have access to the free SDK which is enough to do Apollo development and there is nothing stopping any open source developer from writing any tool that leverages Adobe's Apollo SDK.

    The only restriction I see here is people creating their own compilers and packaging apps for Apollo which makes perfect sense for Adobe to ensure their promise of cross-platform compliance and control the security aspects inherent to bringing applications to the desktop.
    peterelst
    • Closed runtime, expensive tools

      Rather than one huge counter-post I'm going to break this up a bit.

      > > The biggest problem is the licensing. Apollo is a closed,
      > > proprietary system by intentional design. The runtime is
      > > closed, and the tools are expensive.
      >
      > Don't see how you come to that conclusion -- there is
      > a free SDK, the technologies used are HTML, AJAX, Flex
      > that you can write using the text editor of your choice
      > (the Flex SDK is free of charge as well).

      The Flex/Flash/Apollo runtime environment is closed for developers. SWF files are not standardized, neither is the Flash video format. Aside from what a few hackers have managed to put together there's no documentation on the internals. Even if Adobe gave a developer documentation on the internals, it would be against the EULA to use that doc to try and make a compatible player. The license says that "The structure, organization and code of the Software are the valuable trade secrets and confidential information of Adobe Systems Incorporated and its suppliers". You could argue whether or not it's a good idea to allow 3rd party runtimes but this is a textbook example of what's generally meant by the terms closed and proprietary.

      I mentioned the SDK, and there's also a free IDE called FlexDevelop available. The free IDE has syntax highlighting for source files but no GUI builder or advanced workflow. Third party tools are going to continually be playing catch-up with the Adobe tools.
      Ed Burnette
      • SWF and FLV formats not documented?

        For your information please find below the page from which you can get the SWF and FLV file format specification.

        http://www.adobe.com/licensing/developer/

        Basically the license allows you to create SWF and FLV files, the only major restriction is that you can't create your own engine to play it back.

        You can argue whether or not that is right (I believe in the current one Flash Player model, which makes it virtually ubiquitous) but there clearly is documentation available on the file formats.

        I can't help but see this article as more of a general observation on open vs closed source software than an accurate analysis of the Apollo alpha.

        Adobe is making great strides in opening up and standardizing their technologies and are receiving very little credit for it from the people that advocate this practice.
        peterelst
        • SWF and FLV documentation

          Peter,
          I took a look at the page you sent, thanks for the pointer. I also looked up your web site (http://www.peterelst.com) and see that you've been doing Flash programming for at least 4 years, so you know what you're talking about.

          The Adobe site allows one to license the file format specifications from Adobe. In order to get access to this documentation, you have to agree to some rather onerous terms. I've included an excerpt below. They only let you output the files, and require that you do testing with Adobe's authoring and player software to ensure those tools will be able to read it.

          Normally when one says that "something is documented", it's assumed that the documentation is available for anyone to look at, or if it's a commercial product it *might* be restricted to paying customers. That's not the case here.

          Does this count as "documentation"? Strictly speaking, yes. There's something written down, it describes the specifications, and you can get your hands on it. But what you can do with it is severely limited, as is the distribution.

          I'll give you 1/2 a point for that.
          Peter 1/2, Ed 0 :)

          --- excerpts follow (from http://www.adobe.com/licensing/developer/fileformat/license/) ---

          2. Licenses
          Pursuant to the terms and conditions of this License, you are granted a nonexclusive license to use the Specification for the sole purposes of developing Products that output SWF or FLV. ...

          3. Restrictions
          a. You may not use the Specification in any way to create or develop a runtime, client, player, executable or other program that reads or renders .swf files.

          b. You may not use the Specification in any way to create a server, executable, or other program that will stream or deliver data from a client to a server, from a server to another server, or from a server to a client.

          c. You will not make or distribute copies of the Specification, or electronically transfer the Specification outside your company.
          ...
          g. You agree that your Product must output SWF or FLV files that can be opened without Errors in the latest version of the Macromedia Flash authoring software listed at http://www.macromedia.com/software/flash/.
          Ed Burnette
          • license agreement

            I'd say Flash platform products is one of only a few things I'm able to speak with some authority about.

            Sure, you have to agree to that license but apart from not being allowed to build a player is there something world-shocking about them requiring that the SWF and FLV can be opened in their software (which should be the case if you accurately built to spec)

            Lets say some company or the open source community builds a hugely popular FLV editor but turns out it won't import into the Flash IDE. Should Adobe be responsible for bug fixing and implementing workarounds for third parties?

            In that situation the roles are totally reversed and Adobe needs to play catchup to erroneous implementations of its own technology. Lets not go down that route.

            Worth noting is that enforcing EULA's is a bit of a hot issue in the community. There are numerous projects that would strictly speaking break the license agreement and yet are very popular.

            Adobe isn't doing anything about it (yet) resulting in a certain degree of FUD. In some cases there are even articles on the adobe.com developer center talking about these specific projects, many of them are presented at industry events where Adobe is a major sponsor.

            It does illustrate that there needs to be some more clarity surrounding the license agreements and it would be a good time to evaluate where to take the technologies and what role open source development plays in this.
            peterelst
    • ActionScript vs. JavaScript

      > > You program in ActionScript, a language that is
      > > almost, but not quite the same as JavaScript.
      >
      > ActionScript 3.0 is strictly compliant with the
      > ECMAScript Language Specification, Third Edition
      > (ECMA-262) and supports E4X -- no proprietary voodoo
      > code here.

      Yes, but my point was that the developer has to deal with two similar but different languages in the same application. There are also two similar but different parsers and runtimes for those languages active at the same time.
      Ed Burnette
      • javascript implementation issues vs actionscript

        Javascript developers have *always* had to deal with cross-browser issues when writing code. With Apollo this is not the case --they'll have just one HTML engine to target.

        Next generation browsers will support newer versions of ECMAScript and bring it more in line with what ActionScript 3.0 is now, but even so that argument doesn't apply to Apollo.

        Lets consider the Tamarin project and the codebase that was donated to the Mozilla foundation -- that'll make its way into a future release of Firefox.

        The point is mute in my opinion as we're dealing with a compiled and an interpreted technology. Just to clarify that Apollo will allow pure Flex and pure HTML-based apps, you are not forced to mix 'n match.
        peterelst
        • Tamarin

          Hi Peter, I'm really enjoying this conversation. You are correct, that current Ajax/JavaScript developers have to deal with cross-browser issues. But these issues don't go away with Apollo. The Apollo HTML side of things is just one more platform that developers will need to target, and one, I might add, that did not up to now have a very significant market share. So I think I score the point on this one.

          I'm glad you mentioned Tamarin. For those who don't know, Adobe donated their implementation of ActionScript 3.0 (in particular, the ActionScript Virtual Machine AVM2) to the Mozilla Foundation, where it is being developed under the code name Tamarin (http://www.mozilla.org/projects/tamarin/). From the web site:

          <<The goal of the "Tamarin" project is to implement a high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification. The Tamarin virtual machine will be used by Mozilla within SpiderMonkey, the core JavaScript engine embedded in Firefox?, and other products based on Mozilla technology. The code will continue to be used by Adobe as part of the ActionScript? Virtual Machine within Adobe? Flash? Player.>>
          Ed Burnette
          • safari market share

            "But these issues don't go away with Apollo. The Apollo HTML side of things is just one more platform that developers will need to target, and one, I might add, that did not up to now have a very significant market share."

            true, if you're looking at an Apollo app as a desktop extension to an existing web app -- this whole cross-browser compatibility issue is the main reason I now almost exclusively do Flash/Flex development and why I support the current Flash Player license.

            I never want to be in the situation again where you develop applications and need to spend more time checking browsers and coming up with workarounds. This is 99.9% of the time no problem doing Flash work, think of it as a browser that has 80%+ market share and runs on mobile devices, game consoles etc.

            If you take the argument, which is part of the core proposition of Apollo, the you move applications over to the desktop and don't exclusively target it -- it still isn't one more platform to support. Safari is third in line after Internet Explorer and Firefox.

            http://marketshare.hitslink.com/report.aspx?qprid=0

            Supporting Safari should become commonplace if it isn't already with approximately 5% market share, its next competitor coming in at barely 1%. That means one in 20 site visitors vs. 1 in 100 visitors.

            I was rather surprised myself when I first heard they'd use webkit but the reasoning behind it is solid and wouldn't say it has a neglectable market share whatsoever, especially if you look at the trends of people switching over to Mac Intel.
            peterelst
    • Embedding Webkit

      > > While you can embed an HTML panel in an Apollo
      > > application, that browser is a completely separate
      > > environment.
      >
      > Apollo implements the webkit engine (used in Safari),
      > it can be used as a top-level application or embedded
      > into a Flex app. If used in a Flex based app is is
      > rendered within the display stack, you can integrate it
      > with other content and do any manipulation on it you like.

      You did read the part where I mentioned the bridge that allows the two sides to communicate, right?

      An HTML object embedded in a Flex application, is similar to a Flash object embedded in an HTML page. You can have some communication between them through scripting. But they are not a unified whole. For example, even after years of tweaking, when I scroll a web page that has Flash on it, the Flash and HTML parts scroll at slightly different rates. There are the inevitable issues with threads and focus and CPU and memory usage when two very different runtimes try to interact.

      On top of that, the Webkit/Safari browser doesn't get high marks in my book for HTML compatibility and overall smoothness as compared to say, Firefox or Opera. Hopefully that will improve over time but so far my experience with it has been lackluster.
      Ed Burnette
      • reasons for webkit

        "On top of that, the Webkit/Safari browser doesn't get high marks in my book for HTML compatibility and overall smoothness as compared to say, Firefox or Opera. Hopefully that will improve over time but so far my experience with it has been lackluster."

        well, that might be a point -- as I see it the reasons why they chose webkit is filesize and the availability of a port for mobile (done by Nokia). Would it've been better for them to write their own HTML rendering engine or heave forbid use Internet Explorer?
        peterelst
        • Ports

          Anything but IE :)

          Your comment about a mobile port for Nokia is interesting. I noticed that Nokia's newest phones have Flash Lite 2 embedded in them. Do you expect to see Nokia phones with full Apollo support?
          Ed Burnette
          • apollo/webkit for mobile

            I'm not really clued in on webkit for mobile -- at the moment I would guess at a similar situation to the Flash player on mobile, going with lite version.

            Quite a few desktop specific features for Apollo won't directly port over to mobile as far as I can see. If I was to venture a guess I'd say at least another 2 to 3 years before we see Apollo on mobile really taking off, but I could be completely missing the ball on this.
            peterelst
          • Apollo on mobile devices

            Ed - I think your article's title is unnecessarily unfair and based on an uninformed opinion. I agree with Peter that your true point appears to be "open source" versus "closed source." You've made several points about the "openness" of Apollo, but you haven't said much at all as to why that's important to you.

            Regardless...

            We did select WebKit for a variety of reasons, the two most important being it's comparably small file size and it's existing mobile codebases. Our plan is to release a mobile version of Apollo next year.

            Regards,
            Mike Downey
            Sr. Product Manager, Apollo | Adobe Systems | mdowney@adobe.com
            mdowney1
    • Restrictions

      > The only restriction I see here is people creating
      > their own compilers and packaging apps for Apollo which
      > makes perfect sense for Adobe to ensure their promise
      > of cross-platform compliance and control the security
      > aspects inherent to bringing applications to the desktop.

      Ah, the old compatibility and security argument. I've heard it many times, even used it myself a few times. The honest reason for these restrictions is to preserve vendor lock-in and maximize profit. I'm not against vendor lock-in per se (and I'm certainly not against making a profit from software), but in the case of a fundamental developer-oriented piece of technology like this I would argue it's a bad idea. It was a bad idea for .NET (Mono somewhat mitigates this but not totally), and it was a bad idea for Java (Java 7 and Apache Harmony and GNU Classpath are addressing that).

      Why do you think there is so much interest in things like SVG despite its technical shortcomings? Why did the Apache web server and Linux come to dominate the server side despite the fact that almost no one really needs to modify the source? Developers and users are demanding more and more open standards and multi-vendor solutions.
      Ed Burnette
      • how open is open enough

        you make an interesting point but I fail to see what is wrong with Adobe going with free SDK's for Flex an Apollo. It gets you the best of both worlds, a reliable platform with a single point of reference and no license fees.

        I for one would not be happy with an open source forked Flash Player, who says my Flash content will run on the specific version a user has installed? What happens with security issues?

        The very thing you argue against has always been its greatest strength -- cross-browser, cross-platform compatibility. Sure Adobe is in this business to make money but you cannot argue that they are purposely closing their formats for developers.

        What are they doing with ECMAScript compliance, what is happening with PDF becoming an ISO standard -- never in its history has Adobe been so open towards the community and made the barrier to adoption of their technology so low.

        Ironically, the very same people that called for Adobe to open up are now up in arms when they make steps in this direction.

        There is nothing to fear, free tools and revenue for all...
        peterelst
        • Open wide

          First of all I don't expect Adobe to change their policies based on anything you or I write. But hypothetically speaking, suppose they removed the restrictions on the file format documentation that we discussed earlier. What harm could come from that, really? Wouldn't that only make the Flex ecosystem larger? I'd really like to hear your opinion.

          Now suppose they made the flash player and SDK code free/open source, say under MPL or GPL. How does that reduce compatibility and security in the long term? (And how long did Linux users have to wait for an up to date player?)

          Assuming Adobe Macromedia always provides a zero cost high quality player and SDK there will be no reason for anyone to fork it. Forks are expensive. You need to have a darned good reason to fork something, and the resources to keep your fork up to date and viable. It's not just something that happens automatically when you make an open source component.
          Ed Burnette
          • open source

            "Wouldn't that only make the Flex ecosystem larger?"

            yes, without any doubt -- and that is a good thing, my only concern with the player going open source is that it would jeopardize reliability of Flash content playback and open up security issues.

            Now if there was some scheme where the flash player code was open sourced but there was a certification process before any ports are allowed out in the wild (by an independent party if you like) with a digital signature that would be a totally different situation that would have my support.

            Suppose the code is open and alternative flash players can be freely distributed -- who is to say that it won't immediately be used to used to push exploits to the user. There is something to be said about people knowing Adobe as a trusted source of the Flash Player.


            "How does that reduce compatibility and security in the long term? (And how long did Linux users have to wait for an up to date player?)"

            For the latest Flash player release they had to wait a long time, only because of the unique situation of them introducing a new VM, they skipped Flash Player 8 and went straight to work on the version 9 release and they've been very open about this.

            http://blogs.adobe.com/penguin.swf/

            "You need to have a darned good reason to fork something, and the resources to keep your fork up to date and viable."

            There is a thriving open source Flash community that would boldly take an open source Flash Player where no man has gone before.

            That isn't necessarily a bad thing, Adobe works closely with this community and Flash Player engineers have been actively involved in getting information to such projects as Papervision3D and how they could possibly tweak the player to optimize for 3D.

            I was surprised to see this happening but Adobe does very actively support open source initiatives, right up to the Senior Vice President of the Platform Business Unit Kevin Lynch plugging them in his presentations.

            Is Adobe listening? Yes. Will Adobe go open-source on the SDK's? Possibly.

            If you look at what has happened with the PDF file format I'm confident they'll find the right way forward for the Flash Player and their proprietary formats.
            peterelst