Joel Spolsky recently wrote a strategic analysis of web applications and the battle for market dominance on the web called Strategy Letter IV. My friend David Shayer asked for my response to Joel’s analysis.
In the spirit of full disclosure, I need to lay out a bit of my background. I have been intimately involved with web application architecture for a very long time. As a Web Theorist at IBM, it was my responsibility to craft a technical strategy to respond to the ‘missing browser problem’ (e.g. Navigator went poof in December 1997 and we needed to make sure that our customers always had choices in how they deployed web applications). We started a multi-pronged effort involving web standards (JavaScript, SVG, XHTML and Xforms) and browser platforms (IE, Mozilla and HotJava). In addition, in 1998 I promoted active DOM programming. Initially, I proposed creating weblets in Java to manipulate the DOM. We chose Java to enable a secure bi-directional web. Then JavaScript grew up and we put Java weblets on the shelf. Shortly after this, IBM assigned me to help spin Mozilla out of AOL. One of the key points I kept making to potential investors in the Mozilla foundation was that the next evolution of web technology was to become a bi-directional web. We now call this AJAX. In other words, I have an informed opinion on web application architecture and its affect on business. This blog opinion is personal and is not endorsed by IBM in any way.
Technology is the source of business value. Every analysis of the strategic positions of companies needs to start here. Furthermore, technology comes in many forms. Many of which are not obviously tied to the competitive situation between companies. Joel focusses on three areas: software architecture’s exploitation of hardware resources, programming languages that hide platform differences and the emergence of unifying interaction APIs (e.g. common cut and paste methods, etc.). Also, I’ll try to ignore Joel’s sniping at Google’s success (Googleccinos? Oh puleeze.) Hubris happens. It affects the choices folks make but does not change the playing field. It is more like dropping a pass because you did not train sufficiently before the game.
Software Responds to Hardware Largess:
The classic conceit by software architects is to claim that hardware will solve the performance issues introduced by feature creep. (The classic ‘Andy giveth and Bill taketh away’ argument. [Andy is Andy Grove of Intel and Bill is, of course, Bill Gates of Microsoft].) Yet, this is a simplistic view of the technology battle shaped by one’s commercial interests. It is an appropriate view when you are in a race to fill an empty niche created by a platform transition. Since platform transitions are increasingly rare events, I want to look first at the steady state interaction between software features and hardware improvement.
Our friends in the open source community provide some clear examples of this steady state interaction. Because they are frequently not paid, they focus on spare, feature sufficient code. Their benefit from Moore’s law is that as hardware improves their code commensurately improves. For example, a sophisticated commercial database with über algorithms which have significantly overcome many of the limitations of previous generations of hardware benefits less from hardware improvement than simpler algorithms. Hence, the simpler code, being accelerated by hardware relatively more than the sophisticated product, undermines the financial value of the sophisticated, commercial product. The rise of MySQL, which many database professionals disdain, is a good example of this effect.
At some point, a product reaches a point of diminishing returns on feature investments. Most economically important applications have long passed this point. Furthermore, most mature products have features that turned out not to be as valuable to customers as the authors expected. In other words, mature products have cruft. But because some customers actually use those features, the cruft cannot be excised. And finally, because hardware has improved so much faster than their business, customers can get by with much less capability than the software can provide. In other words, there are plenty of reasons not to upgrade when your system works. (The Oxford University Press is a good example.)
In other words, the race to add features in a mature market may actually hurt your product. Factoring your product to meet specific niches is frequently the path to follow.
In a race to fill an empty niche, the winner is frequently the one who can field enough new features fast enough to capture a large amount of market share. Since Joel focusses on emerging APIs being the battle for dominance in UI interaction, I think he is framing the niche based upon historical myopia - i.e. UI was the last battle and, hence, it is the next battle. I take issue with whether there is an empty UI niche to fill here. Many of those choices are constrained by the browsers. The battle is about mash-up APIs and that is starting to settle down via the OpenAJAX alliance. The webapp products I see are more about bringing network capabilities (mash-ups, etc.) to modest function productivity apps. In other words, it is about building a bi-directional web to increase organizational productivity. The personal productivity problem has been long solved and it is well past time that we actually refined the tools to express just the features we have found to be useful. For example, how many people use more word processing features than those provided by an email application on a regular basis? Web apps are for the ‘hoi polloi’ in a company. In other words, company and personal technology choices are now being made on obtaining value from the bulk of the users. The sophisticated users will end up buying different tools.
Platform Hiding Programming Languages:
The holy grail of commercial software developers is the programming language and environment that hides platform differences from the programmer while expressing platform advantages to the user. Both Java and Firefox/Mozilla have attempted to do this. And both have failed. Joel proposes that some mythical platform will emerge that will allow this to happen. He calls this NewSDK. There are, actually, several attempts to do this: Adobe’s AIR, Google’s GWT, Microsoft’s SilverLight. Of the three, AIR, née Flash, has the strongest position. Yet, while the jury is still out on any of these choices, the web, as it always does, is evolving underneath these efforts. For example, one of Flash’s strengths was its video capabilities (essentially H.263 with a Flash wrapper). But the next version will support H.264, the HD video encoder, that has much more uptake by the content community. Learning from the music industry and its dependence on Apple, the media content community does not want any vendor control over their future. H.264 will be where they are all going and will eventually become a part of the base browser. Now the question is, will the application development community embrace AIR? I expect that decision to be a business one and not determined by technology.
Unlike previous platform transitions, everyone has learned from the past. The platform choice is much more likely to be vendor neutral rather than vendor-philic.
Unifying Interaction APIs - The Case for NewSDK:
Unfortunately, while Joel spends the bulk of his argument here, because it depends upon willful, ego driven blindness at Google and other players, it is also his weakest argument. OpenAJAX, even though it is a standards organization, is exclusively about fragment/mash-up interoperability. All of the big players are there - Adobe, Eclipse, Google, IBM, Microsoft, Mozilla and Zimbra (now Yahoo). Apple and Amazon are notable by their absence. Will this interoperability process happen quickly? No. But then the magic NewSDK of Joel’s paper does not emerge quickly either.
I do want to address the conceit of this last section that the big players sipping their Googleccinos are going to allow someone to steal this out from under them. I don’t think this is going to happen. The data that people want to mash-up has, heretofore, been exclusively available from the big players - Amazon, Google, Microsoft and Yahoo. These people watch their business like hawks. Every click-through is measured and categorized. In other words, this is about much more than the APIs - it is about access to the data. Joel’s model does not even acknowledge this difference between now and his historically analogous analysis. This has a huge stickiness that a mere API cannot overcome. And since they control the data, they control the APIs to access the data. Furthermore, the API challenges have already occurred and brought to a standards ‘activity’ with all of the delaying tactics that entails. These standards ‘clash of will’ really preclude small players from getting any leverage. NewSDK doesn’t stand a chance.
What I think will happen:
Having dispensed with Joel’s paper, allow me to promulgate my own view.
The battle is about keeping the browser open and evolving. This means that Firefox/Mozilla and Safari/KHTML have to keep growing and innovating. Firefox with its Google search bar revenue and Apple with its new found market share in PCs and phones can stay in this game a long time. (By the way, Apple gets about $20 million a year from their Google search bar. In other words, the Safari team is already self-funding.) I have no worries here.
NewSDK is about 2 things - good UI and good interoperability. The UI for many applications is already quite good. Google Docs and Zimbra’s apps are examples of good UIs created with today’s AJAX technology. It will only get better. Interoperability is being handled by OpenAJAX and market realities. I have no worries here.
JavaScript. Ahh… JavaScript. I have worries about JavaScript. JavaScript has had some very impressive capabilities on display since around 1999. The first JavaScript desktop libraries were being deployed by startup companies in 1999. I saw multiple sophisticated libraries being offered for sale or soliciting investment. Yet performance has not been one of its strong points. Building on long experience with language interpreters, the industry is focussing on interactively compiling JavaScript. These efforts may be successful. I think there is an easier way. Multi-core processors are being deployed on every computer sold today. (Heck, even the iPhone has upwards of 6 processors.) But my multi-core laptop is now twice as idle as it was before. In other words, the second processor is free and idle. The browser/JavaScript folks need to focus on how to multiply performance by exploiting this ‘free’ resource. At minimum, the compiler needs to run in a separate thread. The second thing that we need to do is simplify the interpreter so that it can run out of the cache memory on these processors. Safari has a fast JavaScript yet it’s interpreter is simpler than the Firefox interpreter. Microsoft’s JScript is, judging by it’s performance, similarly complex. Adobe and Mozilla are collaborating on bringing the Adobe ActionScript engine to Firefox. While I think it’s complex structure will result in slower execution on modern AJAX applications, I would like to be happily surprised Mozilla/Adobe. Safari keeps it’s interpreter small and it, hence, disproportionately benefits from Moore’s law performance improvements. They now need to figure out how to simply exploit the extra processor. I see challenges here for the browser community but I also see them trying to rise to the occasion. Perhaps my worries are unnecessary.
Summary:
Back in 1995 on Pearl Harbor Day, Bill Gates raised an alarm inside Microsoft about the internet and tried to turn the ship of state. He succeeded in killing Netscape and Navigator. But the industry learns and exploited Netscape’s last gift to the internet - Mozilla. We now have a vendor neutral web. That web preserves many billions of dollars of business. There are entrenched interests defending their bottom line. This battle will be very interesting to watch but it most definitely is not going to turn out like the PC business. The internet has changed everything.
