The #6 Reason that Sun has Set: Diddling with the Desktop

One of the most telling moments in my tenure at Sun happened when I was attending a quarterly sales training at JavaSoft back in the fall of 1999. Myself and the other members of the JavaSoft sales team had gathered to hear from our venerable marketing organization about what technologies we would have at our disposal to try to make our $100m Java licensing quota for that fiscal year. We all knew that the real money makers for the Java technology licensing business were going to be on devices (Java Micro Edition and its predecessors, PersonalJava and EmbeddedJava) and on big, enterprise-class servers (the Java Enterprise Edition technologies for application servers and content delivery systems). But personally, I was curious to hear about our plans for the desktop/web technology, a.k.a. Java Standard Edition. You know, the technology that basically launched the Java phenomena just a few short years earlier and had garnered all the developer interest and buzz amongst the industry pundits? The one that was going to give Microsoft's monopoly a good old fashioned butt-kicking? Would we actually, finally have a plan to eek some sort of revenue from Java SE? And if so, how? Maybe an App Store?

I was floored when the very first thing out of the mouth of our Marketing Director during her presentation of the roadmap for Java SE was "Microsoft has won the desktop". I was floored not because I had never heard this statement before or even because I thought it was in error, but rather because it seemed like a rather silly place to start from. Of course Microsoft had won the desktop - making this statement was as useless as stating that IBM had won the mainframe market. It was the biggest "no duh" moment I'd ever experienced. But at that time, Sun was not supposed to be about who had "won" a market - it was supposed to be about how Sun would challenge the winner and kick their butt. Clearly, something was happening to our competitive spirit.

As the presentation continued, we were told the "desktop" strategy for Java was to focus on having developers target Java EE, using server-side technologies such as Enterprise Java Beans, Java Servlets and Java Server Pages, to simply deliver standard HTML to the browser for the user interface. "Sun's not abandoning Java SE" we were told because it was the "foundation of Java EE" and "very important to developers". But "Rich User Interface" applications (like anything that used graphics, animation, video/audio, etc.) were not important to Sun's "customers" - i.e. those companies who bought big servers from Sun to handle large, mission critical applications for their enterprise - and so would not be the focus of our technology development. Besides, with the legal hassles facing us with the Microsoft breach of contract lawsuit and the difficulties in getting the Java Plug-In distributed and working, desktop developers were complaining it was too hard to write meaningful desktop apps in Java (our own internal development efforts being a prime example - any ex-Sun folks remember SunTEA?). "Rich User Interfaces" for Java were all going to have to be for smaller devices running Java ME - the idea being that Sun could do an "end run" around the desktop by embracing the "next wave" (more on that later).

The good news is that, over time, Sun did eventually focus on desktop "Rich User Interface" technologies like Java 2D, Java 3D, Java Web Start, Java FX, etc., but it took time. Too much time. By the time we delivered on the best of our desktop technology, Macromedia/Adobe Flash and browser-based enhanced HTML interfaces like AJAX had run away with most of the web/desktop developer mindshare. And Microsoft was not far behind with Silverlight, to say nothing of where Apple has landed with the iPhone/iPad and where Google is headed with Android (notice their moves on devices, but also on the desktop).

The experience with Java SE was really part of a larger identity crisis facing Sun in the late 90's and early 2000's. Our revenue all came from the "big iron" of the datacenter, but all our media buzz and developer traction came from our "cool" technologies like Java and Jini. Time and time again, Sun flirted with cool desktop technologies, only to eventually either abandon or subvert them as they strayed too far from Sun's core business - enterprise servers. And Sun never came at these technologies as a business, but rather as a marketing program to keep people talking about Sun while we tried to sell them enterprise servers. The idea that you can make money off the client was never seriously considered - clients were just there to drive transactions for servers.

It's easy to understand why most of our development efforts needed to go where the overwhelming majority of our revenue came from, but the harder lesson was to realize that even for our server business, the developer drove demand and the desktop drove the developer. Sun's abandonment of our desktop workstation business left a hole not only for desktop developers, but also for our ability to get early market validation of Solaris on SPARC processors, something that has impacted efforts on server development. In the end, the lack of a compelling desktop stifled Sun's ability to diversify its business and allowed competitors to monetize where Sun failed to do so. When hard times hit both Sun and Sun's customers in 2001-2003, we had nowhere to go but to double-down on the business that was in trouble. This is classic "Innovator's Dilemma" and, in a classic response, Sun failed to re-think its business model and products to adapt.

Was there ever really a business for Java SE, Applets, StarOffice productivity tools, thin clients or any of the other desktop products or technologies Sun has recently provided? The question, unfortunately, remains unanswered. It is not clear that under Oracle there will be a resurgence of desktop technologies or simply a token investment to appease loyal Sun customers and not much else. But with a stronger and earlier focus on desktops in general and Java SE in particular, I believe Sun would have been positioned to make many of the product moves that have helped turn around Apple, at least in terms of applications, games, media and online services (we would have had to partner for the actual consumer devices). Many in the media criticized Sun for investing too much in desktop technologies that seemed to have no place in Sun's product portfolio. I believe we invested too little too late.

The #7 Reason that Sun is Setting: Running away from Linux

There has been much written about Sun and its various responses to the Linux market phenomena over the past decade or so. Clearly, Linux was one of the primary challenges to Sun's traditional product offering of proprietary Unix systems on proprietary hardware. Sun had built up the Solaris market by competing toe-to-toe with IBM's AIX and HP's HP-UX (as well as a host of other Unix variants) and the strategy that had always worked for Sun was that of "the best defense is a good offense".

The problem with the Linux phenomena, however, was that it was incubated in the same primordial soup that gave rise to Solaris (and its direct ancestor, BSD). Specifically, both Solaris and Linux were born from a "free and open" backlash against proprietary Unix offerings from the primary players of the day. Since Sun had grown up as the David against the Goliaths of DEC, IBM and AT&T, it put the company in an awkward position to have to defend itself as a Goliath against the up and coming David that was Linux. And it didn't help that Sun's traditional competitors were investing in Linux and using it to attack Sun's install base of customers.

All of these factors, along with the fact that many (perhaps most) of Sun's own developers were at least fans (if not out-right supporters) of the Linux phenomena, resulted in constant tension in Sun's strategic plans. To embrace Linux was to feed the growing monster nibbling away at the low end of the market, while ignoring it made Sun look out of touch with a significant trend in the industry. Internally, pro-Linux camps were sprouting up and taking on the traditional Solaris establishment, much to the chagrin of the Solaris development team. After a prolonged internal battle, the Solaris establishment won out, but not without having to dedicate itself to a Linux lifestyle. Such was the birth, in 2005, of OpenSolaris.org. But up until that point, Sun's primary strategy with regard to Linux was largely to run away from it and hope it would go away.

Let's not forget that long before OpenSolaris, Sun had invested in porting and supporting Solaris on x86 (Intel and AMD) platforms, having acquired the Intel/Unix assets of Eastman Kodak (Interactive Systems) in 1991. But Sun really wanted to keep Solaris x86 in as small a box as possible. The real focus was on providing a developer playground where development could incubate while allowing for fast and easy recompilation for deployment on SPARC. Very few people, especially inside Sun, really considered Solaris x86 as a deployment platform until Sun itself launched x86-based products in 2002 and by then, some would say, it was really too late.

By the time OpenSolaris was a reality three years later in 2005, the Linux phenomena was already entrenched in the market, even in some of Sun's previously unassailable markets such as telco and financial services. With OpenSolaris, Sun's strategy was to market Solaris x86 as a better Linux and try to blunt all the market momentum that was moving away from Sun's core hardware systems (both SPARC and x86). OpenSolaris, the thinking went, had all the open source benefits of Linux, but the both the superior reliability that comes with decades of mission critical deployments and valuable new features like ZFS and DTrace that would take the Linux world years to emulate. In truth, Solaris x86 really was a "better Linux" and it should have pushed Linux back into the primordial soup from whence it came and re-established Sun as the King of the Enterprise. But it didn't.

I like to imagine a different history. I like to imagine that Sun created a robust market for Solaris x86 back around 1999 (we in the Software OEM team were pushing for this at the time) and went whole-heartedly after the Windows NT/Novell Netware market with Solaris. I like to imagine that by doing so, we completely sucked the air out of the nascent Linux market and established ourselves as the alternative to Windows in the PC server space. And I like to imagine that all of the innovations we introduced in Solaris worked either better or exclusively on SPARC hardware. It's not that hard to imagine, is it? And imagine if Sun had used Solaris x86 to promote Sun's growth in the low-end x86 market - not necessarily to replace SPARC, but to augment Sun and Solaris.

Barring an investment in Solaris x86, the only real alternative for Sun (circa 2000-2001) would have been to create our own distribution of Linux (which was tried as part of the Cobalt acquisition and the short-lived Sun Linux 5.0 distribution). A robust Linux distribution from Sun was one of Red Hat's (and later Novell's) marketing nightmares. They told me as much. As one of the sole IP-clean owners of Unix copyrights and patents, Sun was uniquely positioned not only to create such a thing but to defend it against legal challenges from within and without the Linux community.

There were many at Sun who believed in the Solaris x86 and/or Linux vision, but in the internal Sun Linux wars, they did not prevail. The rest, as they say, is history.

The #8 Reason that Sun is Setting: Fumbling Jini

Originally posted in May 2009...

Just an aside...

Before I go any further, let me just admit up front that I have a specific software bias in my perspective. Most bean-counter analysts will rightly say that the primary reason for Sun to be setting is that we didn't keep our stock price up and that we could have through a variety of financial measures, most notably more lay-offs. But in my opinion, the ability to keep the stock price up is directly related to how a company exploits all its market advantages over time, and I believe that the primary failures for Sun are in the areas of exploiting its software assets, not in a lack of aggressive job cuts.

Building to the "Next Big Thing"

When I joined Sun in January of 1997, Java technology had already transformed Sun from a technical workstation and server company into a software powerhouse. The 1997 JavaONE conference was the largest software developer conference ever held at the time. And Sun was charting an aggressive course for the technology, introducing Java Beans, JDBC, Abstract Windowing Toolkit (AWT), PersonalJava, EmbeddedJava, JavaCard, Enterprise Java Beans, Java Naming and Directory Interfaces, and on and on. And we quietly introduced something called Remote Method Invocation, or RMI. Interestingly, RMI, (along with another interface called Java Native Interface, or JNI), was one of the two aspects of Java 1.1 that Microsoft found so threatening that they refused to implement them in their Java 1.1.4 runtime, causing Sun to sue Microsoft over breach of contract.

RMI is actually a relatively innocuous technology that allows the Java software components (called "objects") in one Java environment (called a "virtual machine", or VM) to talk to Java objects running in another VM. This type of process enables something called "distributed computing", a concept that had been around for years in various forms (some of the more common ones were Common Object Request Broker Architecture, or CORBA, and Microsoft's own Component Object Model Plus, or COM+). Distributed computing enabled software systems to become distributed around a network and still cooperate in solving a given compute task. RMI introduced a Java-specific way to accomplish this and it turns out that by having the same type of objects on both sides of a distributed computing model, the whole process became much simpler and more powerful (CORBA and COM+ allowed objects of different types, like Visual Basic and COBOL, to talk to one another and required a complex set of request brokers and foreknowledge of the application in order to work). What was needed was some form of dynamic finding service where Java objects could register themselves and, using Java-specific capabilities like Reflection and Introspection, determine how to interact with one another at run-time.

Jini Jumps out of the Wrong Bottle

In 1998, Sun introduced something we called Jini. According to and interview with Bill Joy in Wired Magazine, "The Net made it possible. Java made it doable. Jini might just make it happen". What was "it"? It was the idea that the Network really could become the Computer, making Sun's long quoted catch phrase a reality. It was the idea that if every computing device in a network could run Java and RMI, then creating networks of applications that could easily describe themselves, broadcast their capabilities to the network and join up with other devices to create distributed compute networks would be greatly simplified. And by doing it all in Java, it could be programmatic and automated. Jini was the architecture that made the value of Java running everywhere leveragable. And don't forget that Bill Joy was Sun's resident genius and a strong proponent of both the idea of Jini and its development.

So what happened? How could a technology that was the brain child of Sun's resident genius and part of what Microsoft considered to be such a threat end up as a barely noticed project run by Apache? One obvious answer is that, like so many Sun products and technologies, it was a solution looking for a problem. Another obvious answer is that it was a technology that was simply ahead of its time. The real problem was that the engineers had built this technology using the latest Java platform (a beta of what would become Java 2 Standard Edition version 1.2) and had incorporated specific changes into J2SE 1.2 to support the Jini requirements. When launched, Jini could not run in anything smaller than a device with 64MB of memory and a Pentium-class processor (the minimum requirements for J2SE 1.2). Meanwhile, Marketing and PR were off describing uses of the technology that were all about small devices (cameras, printers, cell phones, etc.) that were completely unable to run RMI, nonetheless the Jini which was built on it. And to further complicate things, once this misalignment was identified, no consensus formed on how to solve it - should we abandon Jini in devices? Should we re-target Jini at servers and desktops? Should we re-architect Jini so it would work in a smaller memory footprint and processing power? (no small technical feat, I assure you). In the end, we did a little of everything and ended up confusing ourselves and everyone else about what Jini, the heir apparent to Java, was supposed to be.

Jini's Lasting Legacy

None of this was in-and-of itself devastating for Sun. Misalignment between engineering and marketing is commonplace throughout the technology industry. But Jini was no ordinary technology - it was being positioned as the "future of Java", the logical extension to the incredible network of Java-enabled devices that Sun and its partners had created. It was over-hyped for sure, but we didn't seem to realize or care that a vast amount of our reputation as a software innovator was getting wrapped up in Jini and that developers were starting to ponder if Sun was really up to continuing to lead them into new and wonderful markets or down some poorly thought out road to nowhere. In short, we were losing our software mojo.

Jini should have been first-and-foremost about distributed computing. This means big enterprise servers running networked, Internet-scale applications that could dynamically configure themselves and recover from unexpected outages. But ultimately, Sun never really delivered any commercial value with Jini. And we went on to market other "cool" four-lettered "J" technologies like JXTA and Jiro that also never caught on in the market. And worse still, we left the door so wide open on distributed computing that Microsoft and others were able to walk through it with "Web Services" and the associated complexity along with it (Jini could have solved all the problems currently encountered and would have locked alternative languages like Microsoft's C# out of the distributed computing market, to Sun's advantage).

Jini still has a loyal following and there have been some commercial successes based on Jini. But the promise of Jini when it was announced was that Sun would continue to innovate and drive the technology in new and unique directions, enabling things that had not been dreamed of before. Instead, Jini marked the beginning of an era in Java development characterized more by the Java Community Process and the JSRs and Executive Committees that spew forth from there. In short, the failure of Jini marked the end of Sun's vision leadership in software technologies.

The #9 Reason that Sun is Setting: Messing with the Java Brand

Originally posted in April of 2009...

Much has been said and will be said about how Sun "blew it" with Java - mostly around the lack of contribution by the technology to Sun's bottom line. But this #9 reason for the Setting Sun is not so much about lack of Java revenue (that's actually a rather complicated story), but rather about the numerous attempts by well-meaning marketing folks at Sun to try exploit the value of the Java brand itself and how that ultimately reduced the very value they tried to exploit. To some degree, this is as much about the lack of value in the Sun brand (at least outside our loyal customer base) as it is about Java. After all, if we had sufficient value in the Sun brand there would be no need to try to leverage the Java brand in other areas. But I believe our attempts to leverage the hard-fought value of the Java brand ultimately back-fired, diminishing both the Sun brand and the Java brand.

In the earlier days of Java, the technology was managed by an independent "operating company" called JavaSoft, with its own marketing, sales, products and brand management. There were numerous discussions and debates within JavaSoft about the use of the Java brand and for the most part there was a strong focus on associating the brand with the promise of the technology - that old idea of "write once, run anywhere". There were several brand campaigns around Java - there was the concept of "Java Compatible" for licensees of the technology, "100% Pure Java" for application providers, "Java Powered" for devices, etc. - some of which were very successful, others were branding duds. But there was always a careful consideration of the term "Java" and how we would allow it to be used - both internally and externally.

Fast forward to around 2003 and Sun is struggling to regain its former dot-com glory. We're coming off the painful Netscape-AOL alliance (more on that later) and we're struggling to find a way to express our remarkably robust software assets through a brand. We'd abandoned the confused "iPlanet" brand (which suffered from under-promotion and a "who's your daddy" syndrome between Sun and AOL) and were struggling with the equally confusing and under-promoted "Sun ONE" brand. We were also in one of our many post-dot-com-bubble austerity programs, so heavy investment in any brand was not likely to get funded. I can only assume that the branding discussion (which I was not part of) went something like this:

What's the answer to our branding problem? Java! It's already one of the most recognizable brands in the world and we own it outright. Confused about what Sun ONE Application Server is? Call it the Java Application Server and problem solved! Well, wait - not quite. We can't really call it Java Application Server - that's already an industry standard term for Java EE implementations like IBM's Websphere and BEA's Weblogic and we don't want to further promote them. So let's call it Sun Java Application Server! Wait - hold on. That's likely to get confused with Sun's Java Application Server, which isn't very "brandy" and would be like saying "Sun's Operating System" for Solaris. Not good. Okay - how about Sun Java System Application Server! Yeah! That means it's not just an Application Server, but it is part of a system! Great! All our software is part of a "system"! Now we have a convention for all our software assets! The Sun Java System (fill in your product function here)!

This lead to a proliferation of product names like Sun Java System Access Manager, Sun Java System Identity Manager, Sun Java System Directory Proxy Server, Sun Java System Web Proxy Server and on and on. The problem was not only was this a messy and cumbersome branding campaign, it was diluting the Java brand both within it's own convoluted convention and the broader technology market. Did Sun Java System Web Proxy Server have any Java in it at all? Did it manage the proxies of a Java web server or any web server? And if Sun was not going to use the Java brand to describe Java technologies, why would anyone else? The net effect of this ill-fated campaign was to make Java more about Sun's weakening grasp on its core software portfolio and less about the benefits of modern object-oriented, network-centric computing. It was a double-declining depreciation of the core value of Java.

And the two insults added to the injury were the ill-fated Sun Java Desktop System (which I had a hand in creating, but not in naming) and the changing of our stock symbol to JAVA. The former was no more about Java than is Mac OS X (which, like JDS, contains a Java SE runtime). The latter was a sad attempt to make Sun's stock more recognizable on Wall Street, as if that's what we created the Java brand for.

Fortunately, the value of Java as a technology was not irreparably damaged and there is still enough value to in the brand to cause Larry Ellison to declare that Java is the the single most important software asset we have ever acquired. That's why I rank this is my #9 reason for the Setting Sun and not something much higher.

The #10 Reason Sun is Setting: We Failed to Understand the x86 Market

Originally posted in April of 2009...

It often gets mentioned by the press and certain analysts that Sun didn't get into the x86 market soon enough, or strong enough, or didn't drop SPARC when it should have, or some other such criticism. I believe Sun entered the x86 server market when it had to (our first foray into the server market was the oft-lamented LX50 server back in 2002) and has done a decent job (with the help of Andy Bechtolsheim) at differentiating our offerings while maintaining a competitive price (although margins are another matter altogether).

The problem is we didn't understand the x86 market. We approached the market in the only way we knew how - as an extension of our high-end, low-volume, high-value approach to network computing. And not just in terms of product features and capabilities, but in terms of sales, partnerships, channel programs and supply chain management. We've been improving over the years, but we still have a channel strategy that leverages our traditional partners and programs and does not effectively take our volume products to volume customers.

Our other mistake was to allow our strategy for proliferating Solaris on x86 to overshadow our need to drive volume for our x86 business. Although Sun has been offering Linux on our x86 systems since 2003 and has recently entered into OEM agreements with both Microsoft and VMWare, our focus as a company has been exclusively on Solaris. It is the only OS we pre-install on our hardware. The key to gaining momentum in the channel is to provide the environments that customers want, which for x86 is still predominantly Linux and Windows. We needed to focus on Solaris, but in the area of ISV recruitment and creating solutions that uniquely leverage Solaris and add value to customers, thereby creating demand. By failing to promote other OS offerings and solutions within the channel, we became a niche player in their mind and ultimately became an after thought in their sales to end users. Volume drives the channel, the channel drives volume and volume is the only way to make money in the x86 market.

We've been getting smarter about this lately and over time we would have eventually gotten this right. And we've made progress on the Solaris side, so overall this was not going to bankrupt the company. But it has stunted one of the key growth markets for us and helped to keep us in the "expensive, proprietary system" box that our competitors painted for us, so it has contributed to our lackluster stock performance. For this and other reasons, it is my #10 Reason for Sun to be Setting.

The End of an Icon - revisited

Sun is now history and it's a new day at the combined "Sun-Oracle". Thankfully, I have a position in the new organization and look forward to contributing to the combined company for at least the foreseeable future. My heart goes out to all those who were not so lucky.

Back in April of 2009, when the proposed acquisition was first announced, I had this to say:

"Having worked for the Corporate Development group at Sun for the past 3 1/2 years, I've had to be very careful about what I posted on a public blog. I felt it was better to be safe than sorry, so I've left it to the many other prolific bloggers at Sun to tell our story.

But with the recent announcement that Sun will become part of Oracle, I feel able for the first time to talk about how we got here. Not about the Oracle acquisition itself, but rather how we as a company came to the point where seeking an acquirer was the best way forward. Granted, 2009 is one of the most challenging years in decades and many companies are struggling, but when I joined Sun in 1997, we had the technology world by the tail and were poised to become as influential and lucrative as our more famous rivals (Microsoft, IBM, Intel, HP and even Oracle). So as excited as I am about becoming part of Oracle (there were many far worse options in my opinion), it still feels a little anti-climatic.

So as a sort of "post mortem" on the company, I'd like to examine where I think Sun really missed its opportunities. Some things are only obvious in hind sight, but many of these things are things I've spent my career at Sun advocating and attempting to drive forward. Maybe this is a bit of sour grapes on my part, but mostly this is just an attempt to say externally some of what I've been saying internally at Sun for most of my tenure, now that our future as a Corporation is moving out of our hands.

I will call this my "Top 10 Reasons Sun is Setting". In typical Top 10 fashion, I will start with the #10 Reason Sun is Setting and work my way up to the #1 reason. I know there is a lot of opinion on this topic out there, so feel free to comment as you see fit. I think we may all find this cathartic."

In the course of outlining these "top 10 reasons", I responded to several comments that had been made on what I posted. It was some of those responses to comments that contained what might have been considered "forward looking statements" and I was advised by Sun management to delete my responses to comments. Not wanting to put myself or the company at risk, I voluntarily removed all of my "top 10" posts, promising myself to re-post them once the acquisition closed (not knowing that would be 9 long months later).

What I didn't anticipate was that the deletion of my posts would garner more attention than my posts themselves. So with the added attention, I decided that when I did repost reasons #8 through #10, I would do so on my private blog so as not to garner more attention than is warranted.

So I will now repost those original 3 reasons here and continue to add the other 7 reasons as time allows. As before, please feel free to comment and I will respond freely now that the acquisition is closed and I can do so without fear of overstepping my bounds.

Ten reasons why Mike Elgan's "10 Reasons" are wrong

Mike Elgan of Datamation posted "10 Reasons Why Chrome OS Is No 'Windows Killer'". Although I tend to agree that Chrome OS is not going to put Windows out of business, Mike's reasoning is highly suspect.

Reason #1, "People Don't Prefer Online Apps". This is incredibly naive given that Mike's focus is on MS Office vs. Google Docs. It is true that people are not flocking to Google Docs, but this is not an "online vs. desktop" question, it's really a testament to the power of the MS monopoly. People are also not flocking to OpenOffice or other desktop apps that provide an alternative to MS Office either, and that is because MS makes it extremely difficult to create bi-directional sharing of documents with other apps (note the on-going file format wars of OOXML vs. ODF). If it were not for the lock-in of the file format, online versions of office productivity would be the norm, not the exception, due to the superiority of having ubiquitous access to your files (no more synching work-to-home or desktop-to-laptop) and the improved ability to collaborate. This also misses the point that Chrome OS is likely to be a hybrid, allowing desktop performance and features and online capabilities and benefits simultaneously. If you want to see people "flocking" to online apps, look no further than Facebook.

Reason #2, "People Don't Prefer Google Chrome". Again, Mike is missing the point. Browsers are becoming ubiquitous in terms of their ability to faithfully render almost all of the web content out there. IE continues to be dominant on Windows, but alternatives exist not just on desktops, but on video games consoles (Opera in Nintendo Wii and Firefox in PS3), phones (Opera, Safari, FourthPass and numerous others) and even television sets and other appliances. The Chrome browser does not need a significant market share on the desktop to be successful, it just needs to be able to render web content faithfully.

Reason #3, "'Network Computers' Tend to Fail". Mike offers as his only evidence to this statement that although several attempts have been made to market computers that get their apps from the network, "none has made even a dent in the concept of a personal computer running local apps". Although his support for this statement is weak, for the most part I agree that 'Network Computers' have not displaced the PC, especially for home users. It's just that this has little to do with the the superiority of the PC/local app model and much to do with the lack of ubiquitous, reliable networks. At least in the US, cellular networks are slow and coverage is spotty, Wi-Fi "hot spots" are often few and far between and we are only just getting to the point where airline passengers have access to the Internet while in the air. These limitation are death for devices that require the network to function. Think of it this way - if the network were as ubiquitous and reliable to access as is the disk drive on a traditional PC or laptop, why would anyone want to store anything on a device that could experience a fatal disk crash or be lost or stolen?

more to come...