Shebanation

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)

Apple’s own Jens Alfke has written a great piece on patent law as compared to copyright law. As a bonus, it also makes fun of Mary Bono. Highly recommended.

[Update 03-02-2007] I had to fix the URL in the post. Somehow Textile preview in TextMate did the right thing with the curly quotes, but the Textile engine used by our version of MovableType did not. Jens - curly quotes in URLs - seriously? Plus, I misspelled Mary Bono's name.

Posted by at 11:00 AM | Permalink

Ted Leung has posted blog entry provocatively titled : Adobe wants to be the Microsoft of the Web and Scoble has picked up on it.

In Ted’s post, he worries about the issues around Flash being sourced from a single vendor:

What is not appealing is going back to a technology which is single sourced and controlled by a single vendor. If web applications liberated us from the domination of a single company on the desktop, why would we be eager to be dominated by a different company on the web? Yet, this is what Adobe would have us do, as would the many who are (understandably, along some dimensions, anyway) excited about Flex? Read Anne Zelenka’s post on Open Flash if you don’t think that Flash has an openness problem. I’m not eager to go from being beholden to Microsoft to being beholden to Adobe.

Despite the title of his post, this isn’t an unreasonable worry. Its unfortunate the title is so sensationalistic¹, though, because Adobe will never be the next Microsoft, and furthermore, we don’t want to be. There is a huge difference between Microsoft’s business model, which is about using the web to drive sales of their underlying monopoly products, and Adobe’s strategy, which is to give away technology that expands the web and sell tools around that technology. If you don’t believe me when I tell you this is a huge difference, I suggest you take look at the revenue numbers for both companies yourself.

I think a big part of the fear of Adobe being a single source vendor comes from thinking about Flash Player the way people think about Windows: if Flash Player becomes the dominant runtime for RIAs, could Adobe hold everyone hostage by charging money for the Flash Player or doing something else equally obnoxious? The answer is, quite simply, no. Flash is an important format for the Web today, but a big part of the reason why its successful is because the Player is free (as in beer), it is installed on the vast majority of desktop computers, and it just works wherever it is installed. If Adobe held Flash Player hostage, the Web would just route around the damage by picking some other format that didn’t have the same restrictions.

Same thing goes for Apollo, only more so. Apollo isn’t just about Flash, it is also about Ajax. If Adobe tried to hold Apollo hostage in some way, developers would just move their Apollo apps back into the web browser.

So that is my logical answer to the question, now let me give you a more emotional argument: Adobe would never try to abuse the dominance of Flash Player because it simply isn’t that kind of company. I’m not saying Adobe has never made mistakes (e.g. Sklyarov), and Adobe certainly has no aversion to making money, but at its core Adobe is the most ethical company I’ve ever worked for, of any size. (Yes, I worked for both Apple and Microsoft previously - there is no comparison.) Holding the Web hostage is something that I believe is completely against Adobe’s values. I realize this leaves me open to charges of naivety, but so be it.

Update 3-03-2007: On being closed source

Michael Coté linked to this post with the comment that it was a “Reply to Ted’s post on Adobe and being a closed source vendor.” While I certainly can’t argue with that characterization, it does make we want to clarify something: when I discuss Adobe’s likely actions, I’m doing it under the assumption the status quo will stay just that: the Flash Player will remain a closed source product, and that the SWF format will continue with its existing license. But that doesn’t mean that I’m arguing for the status quo, or that the status quo can’t and won’t be changed. I know that people like John Dowdell (who are much more involved in Flash Player efforts than I am) have been thinking long and hard about the way forward for Flash Player and Apollo, and have asked many questions publicly about the benefits and costs of opening things up more. Thus I think its fair to say that change is quite possible. I personally would welcome steps in this direction but don’t really have much involvement with that part of Adobe.

¹ Then again, who am I to criticize other people’s sensationalistic titles?

Posted by at 10:43 AM | Permalink | Comments (9)

Just in case you haven’t heard the news, Adobe just announced that the entire PDF 1.7 specification would be submitted to ISO via AIIM. The intent is to take PDF from its current status as a de facto standard and make it into a formally recognized international standard, controlled by a vendor-neutral standards body.

Eighteen years ago, Apple and Microsoft announced a joint effort to create a proprietary replacement for PostScript known as TrueImage and a proprietary replacement for PostScript Type 1 fonts known as TrueType. Only TrueType survived to this day, incorporated into the OpenType font standard format along with the PostScript font format (in CFF guise). When Bill Gates announced the joint effort at Seybold, John Warnock gave an impassioned speech where he announced the opening of the PostScript Type 1 font format specification and said:

This standard is so important in the printing and publishing industry that I’m not going to let it fail.

That statement applies equally well to PDF today, and the stakes are even higher. In fact, virtually every government and company around the world has a stake in the future of the PDF standard. I believe that the history will view this announcement as an historic one for Adobe and even for the software industry as a whole. There are several reasons why I believe this is so:

• It shows how important the creation of vendor-neutral open standards is to the future of the tech industry. PDF has been an open standard for many, many years: anyone can implement the specification without any restriction. The specification itself was defined by Adobe, although we took input from many customers and partners over the years. Furthermore, there are a number of ISO standards that are based on the PDF specification: PDF/X, PDF/A, and so on. The openness of PDF has been sufficient to make PDF the de facto standard for document exchange, and, not incidentally, has helped make the Acrobat product family a significant source of revenue for Adobe.

  But recently an increasing number of customers have told us that they want document formats that are formally defined, freely available, and controlled by a vendor-neutral standards body. Sun and IBM deserve a lot of credit for being the first large companies to recognize this emerging trend and in response submitting ODF to OASIS (and then ISO). PDF following in ODF’s footsteps is important because the PDF format is one of the building blocks of the web.

  I hope this announcement marks a tipping point in the definition of openness for document formats, such that any future document formats that wish to get widespread industry adoption will need to be equally open.

• It helps expose, by contrast, the weaknesses of Microsoft’s own standards efforts. Like Adobe, Sun, and IBM, Microsoft has also recognized the trend towards formal standards and as a result is shepherding OOXML thru ISO via ECMA. Unfortunately, Microsoft is trying to have its cake and eat it too, using a committee charter that is rigged: the committee is required to rubber-stamp the format as defined by Microsoft’s implementation for the sake of “compatibility”. Because the standard is really defined only by Microsoft, the OOXML standard fails the vendor-neutrality test in a fundamental way. It remains to be seen whether or not Microsoft will attempt to pull the same trick with XPS.

• It makes Microsoft’s XPS format even more irrelevant and unnecessary. Why would anyone bother with a competing format this isn’t vendor-neutral, does less, and isn’t nearly as ubiquitous?

For myself, I’m proud that I got to play a small (and I do mean small) role in the process that led up to the announcement. My hat is off to the Adobe management team that made the decision and to the product teams that will have to execute on that decision.

Lastly, on an administrative note, I want to point out that Adobe isn’t announcing anything with respect to the submission of any other document formats to standards organizations, so I can’t speak towards such topics.

Posted by at 9:10 PM | Permalink | Comments (7)

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)

The iPhone is everywhere in the news these days. Like everyone, I enjoyed watching the announcements and think Steve Jobs did his usual brilliant job of pitching it. There are some curious omissions, though:

• No VOIP even though they have WiFi. I suspect this is a concession to the cellular carriers.
• No IM support - no AIM, no Jabber, no Yahoo! Messenger, etc. Using SMS to do chat sucks compared to any of the above. It should be a fallback to SMS when IM isn’t available. I’m mystified by this one, honestly - lots of other smartphones support IM, so it can’t have been the carriers who decided this one, right?
• No tactile feedback on the touchscreen and no voice recognition. Guess Apple thinks no one will ever want to place a call while driving. (Yes, I’m aware this is illegal in some places, and unwise pretty much everywhere. But that doesn’t mean people don’t do so frequently.)

But enough about the iPhone’s limitations. I still want one!

But there’s a deeper, more disturbing undercurrent I noticed in yesterday’s announcements that I wanted to talk about. Here’s my “evidence,” such as it is, but keep in mind that this is based on early and incomplete information.

The first item is the lack of openness in the iPhone platform. Lots of people have written about this. Apple says it supports widgets, but it isn’t clear whether there is any support for third party widgets. Similarly, Apple says that there will be no ability to write applications for the iPhone without making some sort of deal with Apple first. To me, this means that it will be basically impossible for small developers to write for the platform, and difficult even for big players. Could Adobe do a free Acrobat Reader for the iPhone? Could Microsoft provide viewers for Office documents (assuming they’d want to, of course). Could Yahoo! build a widget that lets you view your flickr feed? Thats a lot of questions, with no answers. As a software engineer, though, I have to ask: if the iPhone is a closed system, how does the customer gain from it being based on Mac OS X?

The second item is Apple TV. Apparently it:

• only supports Apple’s own H.323 codec for video. I can understand only supporting Apple’s own DRM for protected content, but what about content from the web? Shouldn’t I be able to stream that stuff without doing hours of downloading and conversion first?
• doesn’t support third party extensibility, not even Apple’s existing iPod games initiative
• doesn’t allow additional disk storage to be added to the box even though they have a USB connector on the back

The third and final item is the new Airport Extreme with support for 802.11n. According to Apple:

Most new Mac computers ship with built-in 802.11n wireless support that can be easily enabled with the installation of enabler software included with new AirPort Extreme wireless base station (see sidebar).

Get that? Apple’s been shipping computers for a while that supported 802.11n, but they crippled the feature until their own wireless router was ready for the market. But that wasn’t bad enough: now that they do have competitive products, they still won’t enable 802.11n on the Mac you already paid for unless you first buy one of their routers. I have no doubt the software will leak to the net, but that is besides the point: if I’m a legitimate Apple customer who has valid reasons to install someone else’s 802.11n routers in my home or business, Apple is going to make that customer do something illegal in order to take full advantage of their Mac hardware.

[UPDATE 01-15-2007] According to this article at iLounge, the reason why Apple isn’t providing 802.11 support on existing Macs is Sarbanes-Oxley. I don’t know that I believe this reasoning, but if true its pretty mind-blowingly weak. Rumor also has it that Apple will soon be selling the update for $4.95 to get around this issue. Here's the key quotes from iLounge:

I’m not going to claim to understand this next part, which really just makes no sense to me at all, but the claim Apple’s making is that it _can’t_ give you the 802.11n-unlocking software for free. The reason: the Core 2 Duo Macs weren’t advertised as 802.11n-ready, and a little law called the Sarbanes-Oxley Act supposedly prohibits Apple from giving away an unadvertised new feature for one of its products. Hence, said the Apple rep, the company’s not distributing new _features_ in Software Update any more, just _bug fixes._ Because of Sarbanes-Oxley. If this is an accurate statement of Apple’s position, which as an attorney (but not one with any Sarbanes background) I find at least plausible, this is really crazy.

Any one of these things on its own would raise questions in my mind. Taken together, though, they imply that Apple may now be putting their own plans for world media domination ahead of the needs of their customers. It also implies that Apple believes they no longer need a software ecosystem to make their products succeed. As a long time Apple fan and former Apple employee, these are both things I’m loath to see. Hopefully they’ll change their tune.

Updated 1-11-2007 to fix a typo and change the title to have a plain old single-quote instead of a curvy one...

Posted by at 4:29 PM | Permalink | Comments (1)

Way back in October, Bob Sutor, IBM’s open standards guru, wrote a piece on his blog where he described the Office Open XML standard as a one way standard, because the format is so complex and so geared towards compatibility with legacy Office compatibility that it could never be implemented as a fully functional file format by any competing personal productivity applications (PPAs) like WordPerfect and OpenOffice. I agree with a lot of his points but didn’t feel compelled to write about it since the issue had been covered pretty comprehensively in the blogosphere.

Today, though, a couple of interesting things happened that made me want to write about this. The first is that ECMA approved the Office XML standard over IBM’s objections. That got me thinking about Bob’s original piece again. The other is that Rick Schaut of Microsoft’s Mac BU wrote an article explaining very eloquently why the Mac version of Office won’t support the Open XML file format until sometime next year. What struck me when I read the latter piece is that Rick absolutely, positively proves Bob Sutor’s point when he explains what it would take to create a file converter from scratch for Mac Word:

[…] a team of 5 developers will implement 25 handlers a week, which means that we’d have all the XML handlers written in 44 weeks. […] Nevertheless, we’ve taken a little less than a year to get the converters reading the new file format. We still aren’t writing the new file format, we have the RTF side of things to worry about, which is actually more complex than the XML side, and I’ve completely left out all of the design and coding for the intermediate representation of the file. The intermediate representation, itself, is at least 6 to 8 months worth of work.

Got that? It would take 5 developers a year to do a quarter of the work. That means the whole job is roughly 20 man-years of development time. That doesn’t include testing, documentation, or localization. That would probably double the number of man-years, at least. But it gets worse:

This is just for Word. We need additional teams for Excel and PowerPoint.

Back of the envelope, we’re now talking about 120 man-years. For Mac Office, Microsoft decided such an investment wasn’t practical, so instead they waited for Win32 Office to go final and are now porting the Win32 code to the Mac:

Lastly, can we port the Win Word converter? Well, actually, in a way, porting the Win Word converter is exactly what we have been doing, but we’re still faced with having to wait until Win Word ships before we have the final source code to merge into what we’ve already ported. Once that merge is done, then we still have to go through several months’ worth of testing and bug fixing before they’re ready for public use.

But it gets even worse! There is a lot of commonality between the in-memory data model for Win32 Office and Mac Office, since they share a lot of the same code, but doing converters for a competitive product that has a different in-memory data model would require more development time and more compatibility testing time.

Breaking out my envelope again, we’re now looking at 150 man years to do the job for a competitive PPA. How can competitors afford to make that level of investment? Novell says they will support import and export for Open XML with financial and technical help from Microsoft. Corel says they’ll do it too. Guess we’ll need to wait and see how successful they’ll be at maintaining fidelity and compatibility, though given what Rick has to say, I’m not super confident.

Posted by at 1:26 PM | Permalink | Comments (9)