Apollo, Competition, and Openness
As pretty much everyone who reads this blog knows by now, Adobe recently announced Apollo, our runtime that brings web applications to the desktop. I’ve been reading a lot of what has been written and I’m generally happy with the things people have been saying – most people seem to “get” the value of Apollo and are at least intrigued by the prospects it opens up.
The people who write less enthusiastically about Apollo generally bring up a few things I want to talk about:
- Apollo competes with WPF – this meme is attractive to journalists because its easy to write a sexy story about a war between two large companies. The reality is less confrontational: Apollo is designed to bring web applications to the desktop, and WPF is designed to bring Web-style richness to the Windows programming model. Both approaches have advantages and disadvantages, but they don’t really compete with each other: you probably aren’t going to see a lot of HTML/Flash developers adopting WPF, and you probably aren’t going to see a lot of .NET/Win32 programmers adopting Apollo. Different design centers, different audiences. The only way the “battle” metaphor would make sense is if all programmers and all applications had exactly the same set of platform needs. Apollo’s can succeed even if WPF proves to be extremely popular, and vice versa.
- Apollo is no big deal because its “just a mashup” of existing technologies. Its true that Apollo does leverage and depend heavily on existing Web technologies: Flash/Flex, HTML/JavaScript/Ajax, and PDF. That is actually Apollo’s greatest strength: it provides a way to integrate all those technologies into a common programmng model that also leverages the host platform. No one has ever built anything that brings together web technologies in this way, and its a lot harder to do than calling it “just a mashup” makes it sound.
- Apollo is closed source and proprietary. Its true that a number of the pieces that make up Apollo are closed source, but how important this is will vary from developer to developer, and the story around Apollo alternatives is generally even worse.
Lets go into that last bit a little deeper. In the last few weeks, a number of other companies have been announcing frameworks, runtimes, and/or other products that are also trying to bring the web to the desktop, leveraging the Apollo publicity to their own advantage (more power to them – just good marketing as far as I’m concerned). I’ve also been reading the coverage of these tools and find it interesting to compare and contrast the features and openess of these platforms:
- First up is Dekoh, a product that is trying to build a desktop application engine on top of a Java server. Its an ambitious project, and one that is putting a lot of weight on the fact that it is the open source alternative. I think its great that the source for their runtime is freely available, but how does the company that makes it make money? That isn’t at all clear right now. But one thing that they have revealed is that the product relies on a centralized “Dekoh Network Service” for identity, sharing, and so on. The bottom line is that with Dekoh, you are making your application dependent on a closed source, propietary Dekoh service that will own and leverage information about your users and their data. To me, that doesn’t really seem ‘more open’ than Apollo, where the runtime is free and there are no required dependencies on any web services.
- Next is SlingShot from Joyent and Magnetk. I love Ruby on Rails, so this product is very interesting to me. They basically have taken the all-in-one desktop server approach of Locomotive and turned it into an application runtime. Its a great idea, and one that opens up a lot more power to the local application than Apollo. Downsides are a lot of potential security issues (no sandbox?), the fact that the entire source of your application is distributed to the world whether you like it or not, and the fact that it is limited to Ruby on Rails applications. More disturbing, though, is that it sounds like Joyent will be charging a royalty for distributing applications based on their runtime unless you are a customer for their hosting service. Maybe they just plan on charging a flat fee for the SDK. Either way, this is much less open than the Apollo model where the SDK and runtime are both free of charge.
- Some have argued that Yahoo! Widgets is also an Apollo competitor. I don’t really get the comparison, but even if you do think they serve similar needs, the fact is that Yahoo! Widgets is just as closed source and proprietary as Apollo, if not moreso (since Apollo has open source components like WebKit and Tamarin).
- Finally we have FireFox 3. Not really in the same category as the others, since its still fundamentally a web browser and it is nothing but vaporware at the moment. The offline mode and local data store features sound nice, and the open source credentials for Firefox are unimpeachable. But at the end of the day the integration with the host platform is going to be very limited compared to the other things being discussed in this context.
So there you have it: four Apollo competitors. One truly open but serving a different set of needs, the others with significant openness concerns. In this company, I think Apollo’s model is pretty darn attractive, but your mileage may vary.
Shebanator 
Great post, thanks!
Granted, I’m not a programmer, but I am a designer/developer having to do increasingly complex tasks on the Flash Platform. Excuse my ignorance here, but what exactly is Apollo lacking in desktop power in relation to these other products, other than hardware accelerated graphics and memory constraints? And why is that a really big drawback?
I realize that in itself would widen its reach a little for games and graphics intense stuff, but for a while now, web based Flash has been impressing people more visually than most of what they have been seeing from desktop programs. Maybe Apollo and the new AVM will change that.
I think most of the people we’ll be targeting will either be moving and editing data or multimedia, and the Flash Platform is coming to wield a surprising amount of power.
[Andrew says]I agree Flash has plenty of graphical power. Not sure exactly what made you think I was implying otherwise. Perhaps it was my comment that Slingshot “opens up a lot more power to the local application” ? I wasn’t really talking about graphics here – graphically speaking, Flash kicks HTML’s ass and in the end Slingshot is all about serving HTML. What I was talking about was the richness of the functionality available to Ruby applications: the hundreds of gems that do neat stuff, the ability of Ruby to do hardcore metaprogramming, etc. No disrespect to Flash’s speed or computing power was intended.
Generally a fair assessment, Andrew. Calling Firefox 3 “vaporware” less than a week after the release of an Apollo alpha seems kind of disingenuous though…
[Andrew says] I thought I might take a little heat for that, but I stand by it. Apollo may have only shipped an alpha, but it shipped something. Firefox 3 is still quite a ways from doing the same last I heard, yet they talk as though it has already shipped. And if there is one thing I’ve learned in the software business, its that shipping code is what counts.
This is such a great time to be in web development. We’re on the cusp of these new breed of applications hitting mainstream. We have both for profit and open source companies racing to deliver the best platforms to bridge the previously separate advantages of web centralization and desktop persistence. And most importantly, companies have finally realized that openness and collaboration with developers are not only advantageous, they are absolutely necessary.
So, what about the Dojo Toolkit? I think they deserve mention as well with dojo.storage being in beta. I haven’t personally had the chance to do any serious testing with it, but it is open source and there is a non profit foundation at the helm.
I’d love to hear some thoughts from someone who has more experience working with the Dojo Toolkit. When I glanced through the API it looks like they achieve storage by either piggybacking off of Flash or What Working Group (in Firefox).
[Andrew says] I’m not familar with the desktop functionality provided by Dojo. I’ll check it out, though. Thanks for the tip.
[Update 3-28-07] So I went and took a look at the dojo.storage stuff mentioned. I was a bit surprised that it “just” handles the offline storage issue (using Flash, I might add), so I also looked around the dojo docs to see if there were other pieces that address the same concerns as Apollo and the other systems mentioned here. Bottom line is that I don’t think dojo is really addressing the same issues as Apollo. However, it does look like dojo.storage is a good way to get the offline benefits being touted by Firefox sooner rather than later, and in a way that works across browsers. So if that level of functionality is sufficient for your needs, I recommend looking hard at it.
But one thing that they have revealed is that the product relies on a centralized “Dekoh Network Service” for identity, sharing, and so on
Your statement is not correct. Dekoh network comes into picture only if you want to share your application with your buddies. For doing the same things as what Apollo supports, you dont need to use Dekoh network. The software platform to build such applications as well as widgets and several cool applications are open source. So it is true open source as for as developers wanting to write applications on Dekoh.
Vijay
Dekoh
[Andrew says] Thanks for clarifying. But didn’t you tell Ryan Stewart that authenticating through your service was a key component of your securty model? If not, what is your security model? Is it as unbridled as SlingShot?
Furthermore, your contention that the network only comes into play “if you want to share your application with your buddies” seems like pure spin to me. You have a platform, as a whole, that depends on your closed, proprietary server for its features that add value over the compeition. Without those higher level features, your engine is simply a newer, less field-proven Eclipse RCP.
Andrew,
Why does your reponse appear to be posted as Vijay with URL link to my blog?
It is important to understand what is offered by Dekoh before making conclusions.
Dekoh desktop is a small footprint, open source desktop platform on which hybrid desktop-web applications can be deployed. Your statement You have a platform, as a whole, that depends on your closed, proprietary server is incorrect and an attempt to create FUD.
If a developer wants to write applications on the desktop and use it on his/her computer or just download and install application from dekoh gallery, it is as good as installing a Apollo application. There is “no spin”.
In addition to this applications can be shared web 2.0 style and buddies can comment. This is thru the secure Dekoh network. Whether a user wants to share application/content is optional. My statement “if you want to share your application with your buddies” is correct.
your engine is simply a newer, less field-proven Eclipse RCP. Lets leave this opinion/decision to users.
Vijay
Dekoh
[Andrew says] I put my responses to comments inline. Its a technique I borrowed from John Dowdell because it works well with the way Adobe’s MovableType system works. I can assure you that I do not edit or censor comments unless they are obscene or personal attacks.
As for the charge of creating FUD, that is not my intent. I’m interested in evaluating platforms from a technical and business point of view. This is something I’ve been doing for a long time – years and years before I ever came to Adobe. I think it is of value to the people who read my blog to get my honest assesment of things. Now, I’m not going to claim that I have no pro-Adobe biases, since no one would find such claims credible.
But in the end, I’m writing about software for an audience that is primarily software developers. If using the Dekoh platform means that I as a developer must make any applications I write work with the Dekoh Network Service, that is a completely legitimate openness concern that many developers will care about. It sounds very noble to say let the users decide, but what you are really doing is taking the choice away from the software developer. If developers feel that is a fair tradeoff and decide to develop for your platform, that’s fine by me.
Also, you still haven’t answered my security questions. Do users of my application need to authenticate with your server or not?
Andrew,
Thanks for explaining your intention.
I think you are having difficulty understanding Dekoh network. Let me explain.
Developers dont need to do anything in their application to share on dekoh network(Application can be as simple as a plain HTML file saved in a directory and that will show up on Dekoh desktop portal as an application) Click on share icon and you can share this with your network. One of the applications that will be available for users is wordpress blogging software that is PHP based. We have not changed any code in wordpress for making it sharable on Dekoh network. That is the beauty of Dekoh platform. You can write applications on desktop using web standards and in one click you can share it with your private network of buddies. So if you created Dekoh user ID as andrew, you get andrew.dekoh.net web address where your buddies can access the application from.
The security authentication (on Dekoh network) is only for buddies whom you have shared application with. Please take a look at http://www.dekoh.com/share.jsp and click on the link at the bottom, it shows how sharing works.
When you say “users of my application” are you referring to viewers or owner? owner does not need to authenticate or go to Dekoh network to use the application. Viewers have access to see your desktop application thru dekoh network, so they have to authneticate.
Vijay
Dekoh
[Andrew says] I think we’ll have to just agree to disagree. To me, a platform that requires developers to have their programs interface with a particular web service is not open – that is the very definition of lock-in. You clearly don’t see things that way. As you said in an earlier comment, I think its up to the users to decice. But in this case, the ‘user’ is the application developer. Does anyone else think I’ve misrepresented the situation? I’d like to hear from other developers about the issue.
Andrew,
Sincerely, I dont know why you say “platform that requires developers to have their programs interface with a particular web service is not open”. I gave you an example of how without programming anything an existing web application like wordpress (written in PHP) can be shared on Dekoh network (sharing itself is optional). It is very clear there is no program interface of dekoh an application has to conform to be enabled for sharing…but then if you still want to beleive in what is not true, your conclusion of agree to disagree is acceptable to me.
Vijay
Dekoh
“To me, a platform that requires developers to have their programs interface with a particular web service is not open – that is the very definition of lock-in.”
The distinction here is between a simple web-desktop platform, and sharing and collaboration. Dekoh essentially enables three levels. 1) Run any java web app on the desktop. 2) Enable other users to “access” this deployed app. 3) Build smarter web2.0 apps that enable user-user collaboration.
(1) is absolutely lockin free. (2) locks in just for user authentication- with NO change needed to the application. (3) locks into an open-source collaboration API.
[Andrew says] Thanks for clarifying. Your explanation makes things a lot more understandable, and I’m glad to hear that (1) is possible with your platform – that was not at all clear to me previously.
I still believe (2) is a serious openness concern, and as an application developer I would think twice about the idea of relinquishing control of my customer usage data to Dekoh. But as I said before, that is a tradeoff that each application developer can make for themself.
As for (3), are you saying that your collaboration solution is 100% P2P and that therefore the Dekoh Network Service is not required? You should write about that on your blog(s), particularly how you deal with proxies and firewalls…
@Andrew: first, thanks for the attention. We little guys always enjoy getting notice from the 800-lb gorilla. Second, the *only* thing Joyent has said is that Slingshot will be free to those that use Joyent Accelerators. We didn’t say anything else, though. Everything you say about our model is pure speculation on your part. Third, “no sandbox”? Like, when a compiled application such as Photoshop has direct access to the host operating system? That’s just FUD.
[Andrew says] I’m “the 800-lb gorilla”? I’m just a guy who works for Adobe and happens to write a blog. My opinions are my own, not Adobe’s. Furthermore, even if I was Moses coming down the mountain with the word of Adobe, it isn’t like Adobe is the 800-lb gorilla of the industry – we’re much smaller than Apple, not to mention IBM, Google, Microsoft, etc. Furthermore, I wish you guys no ill will – I’m actually a satisfied TextDrive customer…
That said, you’re right that I was speculating about your licensing, but that speculation was based on things you said and/or implied. I’m happy to be proven wrong. But until you actually come out and say what your model is, I’m afraid you get to stay in the ‘not open’ column, sorry.
Finally, on sandboxing: you’re right that native apps run with no sandbox (although you could argue Vista has a sandboxed environment of sorts for native apps). However, that is not the standard new platforms should be held to. Java, .NET, and Apollo all have a strict sandbox model that is enforced on applications. So do web browsers. The benefits of these sandboxes are enormous for end users and should not be lightly dismissed.
[One more update] More on the 800lb gorilla meme. See this slide from Microsoft’s analyst day presentation last year. Notice how Adobe doesn’t even rate as a major competitor? We’re the underdog, baby!