[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!

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…

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

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.

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?

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.

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.

[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.

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.