Shebanation

So the folks over at Joyent have announced that Slingshot will be released under a dual licensing model: GPL and a commercial paid license. The surprising thing about their announcement is that they went out of their way to call me out over the licensing issues:

When we announced Slingshot, Andrew Shebanow at Adobe posted about Apollo, Competition, and Openness.

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.

We are charging a license fee to people using Slingshot for commercial purposes. I believe Adobe does this for content producing tools, too. Joyent would like to invite Adobe to open source Apollo and the ecosystem around it (Flex, Flash). Don’t just make it free, free it.

And by way of response. Sandbox? What’s the sandbox Adobe Photoshop runs in? Entire source? More on that, later. Limited to Rails? Yes. Focus.

I have to admit that I’m a little mystified by their hostility. I thought I was pretty evenhanded and positive about their product. David Young, the CEO of Joyent did respond to the post accusing me of FUD, we had some back and forth on it, and I thought it was resolved. Heck, when I posted a while later about DHH’s post, David commented again to thank me. Why the change in attitude now? Beats me.

Anyhow, I tried to respond to the post on Joyent’s blog, but my post disappeared shortly after I submitted it. I thought it might have been a glitch so I posted the comment again. Again it disappeared. This might be a server problem on their end, but it also might be outright censorship, and it feels more like the latter to me since other people’s comments show up. In any event, the net has a way of routing around that sort of thing. Here’s my comment as I wrote it in their blog, unedited. I think my comments were critical but not inflammatory so I’m again at a loss to explain why they’d delete what I said, if that is in fact what happened. Are they really that incapable of dealing with criticism? I hope not.

Wow, holding a grudge, are we?

I addressed your sandbox comment on my original post, but you clearly don’t appreciate the trust model differences between small apps that are downloaded from the internet and large-scale traditional desktop applications. Or maybe you do appreciate the difference but are only targeting the latter. Or you just don’t care. I personally think you are making a big mistake ignoring the security issue but its certainly your right to do so.

I’m happy you’re releasing source under GPL. Duel licensing is an interesting choice, and I look forward to seeing how it works out for you business-wise. There is no question that monetizing a runtime framework is a tricky business.

Can’t really speak to the whole “free vs. free” thing. I’d certainly welcome such a thing but it isn’t something I have any control over. I do want to point out that even though Apollo isn’t fully open source, pieces of it are, like WebKit and Tamarin. That obviously won’t be enough to satisfy everyone, but we expect great things.

Bottom line is I wish you all the success in the world, and I hope you get over your hard feelings.

Posted by at 5:11 PM | Permalink | Comments (2)

Yesterday, John Gruber posted a gripe about the new CS3 panels and palettes and how horrible it is that Adobe put the close box on the right side. To John, this seemed horribly un-Mac-like, and in trademark style he concludes his gripe with an elitist and unsubstantiated slap at Windows users (but hey, at least it was funny):

Ends up the title bar controls for palette windows in CS3 are on the right side, Windows-style. “X” for close, “_” for collapse. God, that just looks so wrong – how did this ever get approved? If Adobe really wanted to put these controls in the same location on both platforms, why not do it the Mac way? If Windows users cared about consistency, they wouldn’t be using Windows.

I wrote him an email where I explained what I thought the actual motivation for the close box on the right decision was: the desire to save vertical space by putting the close box to the right of the palette tab panel interface.

But thinking about it some more, I realized that this answer didn’t really satisfy me. First of all, even though putting the close box on the right does make sense from an overall design point of view, the fact remains that the close box doesn’t look like a Mac-style close box when you run CS3 on a Mac. It doesn’t really look like a Windows close box, either. Instead, it looks like an “Adobe close box”, just as the palettes themselves don’t really look like those of other, non-Adobe applications. But then I had to think about it some more, because despite this realization I still am not bothered by the problem whatsoever when I actually use CS3, and I like to think I have a pretty well tuned design aesthetic (for an engineer).

The reason, I think, is that the goal of a single, consistent platform look and feel, as espoused by John in the quote above, is dead. Long gone. Apple never really achieved this even in the good old days (remember HyperCard? FileMaker?). And looking at Apple’s own applications that ship with a new Mac shows that things have only gotten worse. Its always been a case of “do as I say, not as I do”, and never more so than today.

But I don’t blame Apple or Adobe for the death of the goal. What really killed that goal once and for all was the web. Where once there were only a few popular Mac applications that broke with convention, on the web look and feel consistency isn’t even on the list of things to worry about. YouTube and flickr look and work completely differently. Users today have been trained to expect a different set of UI conventions from every web application they use, and they aren’t complaining about it.

The trend towards Rich Internet Applications using Apollo and its ilk will further cement this trend, as web applications come down to the desktop with their web UI conventions intact. To me, this is a good thing.

[Update 10:36AM] Wow, this is getting a lot of traffic and a lot of comments, especially for something I wrote at 4am when I couldn’t sleep. I want to make a few things clear to people about my intent.

The real thrust of my article isn’t as a defense of putting the close box on the right vs. the left, or about what the ‘x’ looks like. I personally don’t think that discussion is all that important, although there are clearly a number of commenters who disagree.

What I’m really talking about here is how the goal of complete UI consistency is a quest for the grail, a quest for a goal that can never be reached. The fact that you call it a holy grail may make the quest seem more noble, but it doesn’t make the grail any more achievable.

At the end of the article, I talked about how RIAs bringing web conventions to the desktop was a good thing, but I didn’t explain why (I blame lack of sleep). The reason I think this is that it lets us move the conversation away from the discussion of conformance with a mythical ideal and towards a discussion of what a usable UI should be. I really appreciate the comments from folks pointing out places where Adobe’s UI isn’t as usable as it could and should be - they’re the folks who really understand what I’m trying to talk about here.

Finally, I want to point out for those who may have missed it that this is my personal blog and that these are my personal opinions. I am an engineer, not a PR mouthpiece or an evangelist (at least not professionally). Furthermore, I don’t work on CS3, so my opinion shouldn’t be taken as that of the CS3 team or of Adobe as a whole. I never cease to be amazed at how many people seem to confuse this issue.

Posted by at 4:46 AM | Permalink | Comments (17)

Ray Ozzie has done an interview with the always excellent Knowledge@Wharton folks, and its a great read. Its nice that Ozzie is coming out of hiding a bit. In the article, he talks quite a bit about Adobe. Not surprisingly, Dan Farber and Ryan Stewart are talking about it.

I think Dan pullled the most interesting quote out of the article, though he didn’t include the whole thing. Here it is:

Well let me just start by saying that, in my view, we only have one shared future as a software industry. And that is centrally deployed code that has a different lifetime associated with it on the device it’s deployed to.

So, what is HTML or DHTML? Most web pages have JavaScript in them. That’s code that is delivered to the client and it has the lifetime of the browser instance you’re using. Flash — what is that? Well, it involves enhancing the browser runtime by downloading code. But it tethers those enhancements to the service and the lifetime of those things is still within the browser. With Apollo, maybe you can make the lifetime that of the user on that device. They have increased the lifetime from the browser instance to the PC.

All apps — whether Win32 code, Flash code, managed WPF [Windows Presentation Foundation] code — are going to have those lifetime choices and will all be centrally deployed, whether that central deployment is from an enterprise or from a service provider on the web. The concept of CD-based installs, floppy-based installs or USB stick installs are artifacts of a time when we were not fully connected.

I don’t see radical differences in the approaches that Adobe might be taking, that we’re taking, or that the web industry in general is taking. The languages and run-times may be different. And we come at it from a history of the desktop coming up to the web. They are coming from a history of being on the web and going down to the desktop, but the endpoint is the same.

Cool. Ray Ozzie gets the key benefit of Apollo - bringing the web down to the desktop. His key message here is that bits is bits, and that it doesn’t really matter whether its .NET code or Flash or HTML/Javascript that gets deployed on the web - they all end up just being code that runs on the local machine. There is truth to that, but I think he is either being a bit disingenuous or missing the larger point - it isn’t just about the bits, its also about the APIs and tools used to create those bits. Does Ozzie really believe these things are irrelevant? I doubt it.

I’ve written about how I see our vision differing from Microsoft’s in this key area previously, but instead of repeating myself, I’ll instead point to the work of Peter Fisk. He is working on an amazing project to create a complete Smalltalk environment from the ground up, built on a lisp base. Now this is a pretty ambitious project, you have to admit. He started off using .NET and WPF, back in July 2006. After making steady progress for six months, he heard about Flex 2.0 at the end of January 2007. Two days later he had posted his first proof-of-concept tests of lisp implemented in Flex. Within a month, he had significant functionality in place. A month later, he had animation working in Smalltalk. He’s made incredible progress in the last two months, way more than he did in six months with WPF, and I’ve had a blast watching his progress. Now he has had a chance to reflect on the two worlds, and I love what he has to say. Here it is in its entirety:

I have been coding almost exclusively in ActionScript for the past two months, and I am beginning to like it.

The entire Adobe way of doing things is a lot simpler than Microsoft and it seems to produce results that are just as good. So far, I haven’t found anything that I could do in C#/.Net that I can’t do in ActionScript/Flash - in fact, I am finding some capabilities in Flash that aren’t available in .Net.

Here is a car analogy:

Microsoft has built a sports car and Adobe has built a Volkswagen (a real Volkswagen, not the new imitation ones).

So while Microsoft is preparing their latest rocket-powered turbocharger which will be available “real soon now”, you can actually build and deploy stuff in Flash.

A Volkswagen on the road goes a lot faster than a sports car in the repair shop.

Now, a lesser man could take that analogy and run it into a telephone pole, but I won’t go there. :-)

Posted by at 5:35 PM | Permalink | Comments (1)

DHH of Rails fame recently posted to the 37signals blog about not getting the need for “offline web applications”. Although he didn’t mention any one such framework specifically, it seems likely he was talking about Apollo, Slingshot, Firefox 3.0’s offline capabilities, and so forth. The gist of his argument is laid out in his first paragraph:

The idea of offline web applications is getting an undue amount of attention. Which is bizarre when you look at how availability of connectivity is ever increasing. EVDO cards, city-wide wifis, iPhones, Blackberry’s. There are so many ways to get online these days that the excitement for offline is truly puzzling. Until you consider the one place that is still largely an island of missing connectivity: The plane!

Now I have a lot of respect for David and for the products that 37signals has created, but it seems to me like he has made a couple of glaring errors in his analysis.

The first error is his supposition that the plane is the only place where people aren’t connected these days. I can understand how someone who lives and travels in high tech urban areas could make that mistake, but as many commenters on his blog have pointed out, we are far from universal connectivity in the industrialized world, and much of the world is even farther behind. And even where there is connectivity, hills, tunnels, concrete walls, and interference can wreak havoc on reliability and performance. I have no doubt that the trend worldwide is to more and more wireless access, and someday we may get to the point that David thinks is already here. But I don’t believe that we’ll be at the point where we have ubiquitous, reliable access for a long, long time.

The second is the supposition that Apollo, Slingshot, and so forth are all about offline web applications. I don’t think supporting purely offline applications is something most people are all that interested in. The benefits of the offline support are really about making applications that work in occasionally disconnected mode. The disconnect could be because you are on a plane, but it is more likely because your wireless disconnected for a while do to some sort of reliability glitch.

Furthermore, as David Young of Joyent points out, the benefits of RIA frameworks like Apollo and Slingshot aren’t just about being “offline”. They are really about bringing the benefits of web application programming to the desktop. David captures those benefits quite well, though of course his post is very Slingshot-centric. Although there are some huge differences between SlingShot and Apollo, most of what David writes applies equally well to Apollo. (See how I’m FUDing you again, David?)

Posted by at 9:59 AM | Permalink | Comments (1)

I normally don't like to do those "me too" sorts of posts Microsoft folks seem to specialize in, where you just say "look at this great article my coworker wrote". To me, its always seemed like a rather distasteful way to do PageRank/TechMeme manipulation. But Mike Chambers has written a really good article on the rationale behind Apollo, so here I go emulating bad behavior...

While I'm passing on Apollo links, here are a couple of shorter articles I also liked:

• Richard McManus and John Milan argue about online desktop apps vs. offline web apps. I don't really agree with either side, but its a good read.
• Pasz.com has an article on things to like about Apollo from a day-to-day development point of view.
  

Posted by at 12:56 PM | Permalink | Comments (4)

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:

1. 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.
2. 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.
3. 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.

Posted by at 10:55 AM | Permalink | Comments (10)

Om Malik and others have reported on Jive CEO David Hersh’s speech at Etel, where he claimed that IM applications will never migrate off the desktop.

I’m a little mystified by the argument, at least as presented by Om (I haven’t seen an actual transcript or slides for the actual talk):

1. Real Time with IM:
   Real time communication and collaboration are great, no doubt about it. But who says you need to be in a desktop application to achieve those things? Is there some special magic in XMPP, SIP, and Jabber protocols that makes them unimplementable in a VM environment? Of course not, and here is the proof: Adobe Acrobat Connect lets you chat, do VOIP, and more all within a web browser, using Flash. Jive’s own products implement these protocols in Java, which was also a VM environment last time I checked.
2. And then there is the familiar user interface!:
   Again, Flash-based user interfaces are incredibly rich. AJAX-based experiences have come a long way as well. What exactly is the special sauce in desktop IM programs that makes their UI unamenable to the RIA experience? As Om himself points out earlier in his article, if you can do Buzzword or Adobe Remix that way, surely the IM experience can be handled in the same manner…
3. Future full of features:
   Again, what is it about IM as a desktop application that makes it more amenable to new features than an RIA implementation or an AJAX one? Many people think that RIA environments are more productive places to program than the old Win32/Apple worlds. They certainly aren’t less productive.
4. Mobile goes the IM:
   This is a non-sequitir. How mobile IM clients are written will have little or no effect on whether desktop IM applications survive. Besides, mobile platforms could offer IM services based on Flash Lite or J2ME.

I suspect that David Hersh’s argument may actually be a lot simpler than presented by Om. He may just be saying that IM applications won’t ever be predominantly browser-based. But if that is what he’s saying, then my answer is: so what? If the future of IM is as an Apollo app, a Widget/Gadget, or some other such technology, why does it matter how those applications get onto the desktop? They are still going to be built on Web technologies, not on traditional “desktop” APIs.

Posted by at 11:42 AM | Permalink | Comments (2)

Lots of people have been talking about the iPhone’s lack of openness and what it means. In particular, they’ve been discussing the news that Apple is at least considering putting Flash on the iPhone, but has dismissed Java as being too bloated:

Markoff: “What about all those plugins that live within Safari now, like Flash or like Java or like JavaScript?”

Jobs: “Well, JavaScript’s built into the Phone. Sure.”

Markoff: “And what are you thinking about Flash and Java?”

Jobs: “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”

Markoff: “Flash?”

Jobs: “Well, you might see that.”

Lots of people have written about this statement, speculating on what it means for Java on Mac OS X, and wondered whether this should be seen as a eulogy for desktop java in general. Scoble and Gruber think Jobs may be spinning, and I agree - given how big the embedded version of Mac OS X is likely to be, calling JavaME heavyweight seems ridiculous. And because he’s spinning, I personally don’t think this will have any diminishing effect on Apple’s support for Java on the Mac - not that they were doing all that much to begin with.

I think the more interesting question is the one about the future of Java as a platform for GUI-based applications, on the desktop and in mobile devices.

The first thing I’d point out is that Java ME is a very strong player in the mobile space, used for all kinds of games. These games all have exactly the right kind of UI for their platform - a game UI. Should these games have an iPhone-esque UI when they run on an iPhone? Heck no! In fact, I’ll go even further and say that any game that every does get written with an iPhone-esque UI will suck.

Java ME is also used by companies like Google to build mobile applications that run on a variety of cell phones like GMail and Google Maps. Anyone who thinks these applications have inherently bad user interfaces is smoking something - they may not be Mac-like but they are very usable, very performant, and they have that “Google” look and feel (for better or worse). And while writing Java ME applications is anything but “write once run anywhere”, being portable is a lot better than being locked in to one OS or device.

But all that goes double for Flash Lite: richer interactivity, better authoring tools, and better portability. I’ll spare you any further proselytizing on the subject, but I’ve used a bunch of phones and the ones with Flash built in are the most usable on the market (the iPhone may very well change all that but I’ll reserve judgement til I get to hold one in my own hands).

Going back to the desktop, the choice is even starker: Java on the desktop just sucks. I spent many years at PlaceWare building user interfaces in Java, and spent way too many hours working around limitations in the platform. When I got to design and build a Win32 client to replace the Java version it felt so liberating! Isn’t that sad? So I completely sympathize with Jens’ point of view: native OS interfaces are vastly superior when it comes to creating great user experiences.

Unfortunately, when you adopt native APIs, you also get something else: lock-in. It doesn’t really matter whether your native API is Cocoa or Carbon or Win32 or WPF - all of them severely limit the number of places your applications can run. None of them make it practical to make an application that runs on Windows and Mac and Linux and so forth. None of them has a real story for making your code portable between operating systems and devices.

Now Adobe cares a lot about applications that run on more than one operating system, probably a lot more than any other major software company. So we’ve invested a lot in building compelling cross-platform user interfaces, and the UI used in the recently released PhotoShop CS3 is the latest example of that. We’ve even released some of those technologies as open source. But building these types of cross-platform applications requires a huge investment, one that very few companies are willing to make.

So if you are looking to build a cross-platform application without making those kinds of investments, what are your choices? Basically, you can use HTML/CSS/JavaScript, and/or use the Flash/Flex environment. With Apollo, Adobe is trying to bring those two worlds closer together and bring those technologies to the desktop, and eventually Apollo applications will be able to crossover to the mobile side as well. I personally find this a lot more exciting than a world full of non-portable applications. And Flash/Apollo can make applications with UIs that are as compelling as those of OS X and Vista. (I could make the argument that recent developments in OS X and Vista are really just attempts to bring Flash-style user experiences to the native OS, but that’s a topic for another day.)

Now I know that someone will make the point that the Flash/Flex/Apollo world is also a form of lock-in, and to a certain extent I agree: Flash Player is still proprietary (although it is free as in beer), and we do want to make money selling Flex Builder, Flash Professional, and other tools for creating experiences for the platform (the shame! the horror!). But in the end I think developers should invest in a platform that works across multiple operating systems and devices over one that doesn’t. Java could have been such a platform, but it lost its way. How strange that Adobe has had to pick up the mantle.

Posted by at 2:29 PM | Permalink | Comments (3)

John Milan has written an article on Read/WriteWeb where he discusses the future of applications and the implications for google and Microsoft. In Part II, he suggests that one way google could diversify its holdings would be to buy Adobe. Just in case this is true, I’d like to be the first to say that I welcome our new google overlords. :-)

I do think he sells Adobe short in his analysis, though. HTML/CSS and .NET are not the only two execution environments that matter: the Flash Player is the most ubiquitous virtual machine-based operating environment in the world. Flash is doing well in the mobile world, and runs in cars and refrigerators as well. Flash has a one-click deployment story and Apollo makes that story even more powerful. Flex makes it easier for developers to target the Flash Player runtime. You get the idea…

Hey, maybe one day Adobe will buy google…you heard it here first.

Posted by at 3:48 PM | Permalink | Comments (4)