In a report from a developer meeting, Nokia officials said they're moving to Maemo Linux as the OS for their high-end smartphones. That resulted in an entertaining little obituary in the Register by Andrew Orlowski (link). But then later in the day Nokia clarified that "we remain firmly committed to Symbian as our smartphone platform of choice" (link). That in turn led to a lively online debate about what Nokia actually said, and the challenges that Finnish people face when speaking English (check the comments here).
It's just one more chapter in the long and exquisitely awkward saga of Nokia and Symbian. From the outside I can't tell exactly what's going on at Nokia, and it's possible that Nokia itself doesn't know. It's a very large company, and various groups there can have conflicting agendas.
But I can't believe that there would be all of these repeated reports, leaks, and artfully-worded partial denials unless Nokia were de-emphasizing Symbian in the long run. The most prominent theory, which I believe based on things I hear through back channels, is that Nokia does indeed intend to move to Maemo at the high end. And, as we all know, in computing whatever's at the high end eventually ends up in the mainstream.
I'm sure Nokia has valid technical reasons for moving to another OS. Nokia has said that there are some things it wants to do with its smartphones that Symbian OS can't support. But still the change worries me. Nokia's biggest problem in the smartphone market isn't the OS it uses, it's the user experience and services layer in its smartphones. Moving to a new OS does almost nothing to fix that. It does force a lot of engineers to work on writing a lot of low-level infrastructure code that won't create visible value for users. It also forces Nokia to maintain two separate code bases, which will chew up even more engineers.
All of that investment could have gone into crafting some great solutions, the things that are the only way to pull customers away from Apple and RIM. At a minimum, it's a terrible shame that Nokia spent so much time and money on an OS that couldn't take it into the future.
(By the way, this focus on the OS doesn't apply only to Nokia. I hear a lot of buzz from operators and handset companies who believe that if they just pick the right OS they'll automatically end up with great smartphones. Android is the latest white knight for most of them, but of course Nokia's not going to depend on a technology from Google.)
There's an old joke in the tech industry about rearranging deck chairs on the Titanic. I don't think that applies to Nokia because they haven't hit an iceberg by any means. But I do have a mental picture of a sweet old lady who spends all her time every day cleaning the bathroom while the food is spoiling in the refrigerator.
Affichage des articles dont le libellé est platforms. Afficher tous les articles
Affichage des articles dont le libellé est platforms. Afficher tous les articles
jeudi 19 novembre 2009
dimanche 10 mai 2009
A quick history of software platforms: How we got here, and where we're going
Intuit and Stanford recently asked me to give talks on computer platforms and what makes them successful. (By platforms I mean software with APIs that third party developers can write apps on top of; Windows and Macintosh are both platforms, as is Java.) Platforms are a hot topic in Silicon Valley these days. The success of the iPhone app store in mobile, and Facebook on the web, have forcefully reminded people that you can grow a tech business more quickly if you get third party developers to help you. Almost every tech company I work with is trying to expose some sort of API or platform offering in its products.
To explain how software platforms work today, I thought it'd be good to start with their history. But I wasn't sure about many of the details myself, so I ended up doing some research. The information was surprisingly hard to find, and also pretty controversial -- for every person who claims to be the first to have done something in computing, there's someone else who begs to differ. I did my best to sort through all the claims. The picture that developed makes an interesting story, but also has some very important lessons about where the industry might go next.
Fair warning: this is a long post. But I hope you'll feel that the destination is worth the trip.
Here's what I found:
Hardware memory, software amnesia
The computer industry is often criticized for its failure to remember its own history. Supposedly we're so focused on the new thing that we forget what's come before.
In reality, though, we're actually fairly good at remembering a lot of our hardware history (for example, Apple fans are celebrating the 25th anniversary of the Macintosh this year). There's passionate controversy over what was the first computer -- was it Konrad Zuse's Z1 (link), Tommy Flowers' Colossus (link), etc. The answer depends in part on your definition of the word "computer." But it's a well-documented disagreement, and you can find a lot of information about it online, including a cool timeline at the Computer History Museum (link).
The machine most commonly cited as the first fully programmable general-purpose electronic computer was ENIAC, the Electronic Numerical Integrator And Computer. It was completed in 1946 (link).
Here's ENIAC (well, part of it, anyway)
You can find lots of histories of ENIAC online (link). There are multiple simulators of it on the web (link), and the engineering school at the University of Pennsylvania even has an ENIAC museum online (link).
But when it comes to software, our memories are much hazier. For example, I doubt there will be a 25th anniversary celebration in 2010 for Aldus PageMaker, the program that did more than any other to make Macintosh successful. And about a day after I post this article -- May 12, 2009 -- will be the 30th anniversary of the introduction of Visicalc, the first spreadsheet program. Anyone planning a parade?
Today we take it for granted that you can use a computer for a variety of business or personal tasks, but it didn't always work that way. ENIAC and Colossus were government-funded tools for solving military and scientific problems. The US Army funded ENIAC, and in addition to calculating artillery tables, it was also used for tasks like weather prediction, wind tunnel design, and atomic energy calculations.
These nice ladies are programming ENIAC, by moving cables around.
How did we end up using computers for other purposes? The UPenn site says only, "it is recalled that no electronic computers were being applied to commercial problems until about 1951."
Yeah, "it is recalled." This is where I had to start digging. Once again there are disputes (link), but you can make a very good case that business computing started in the UK, and it involved something called a Swiss roll.
The first business computer
I had never heard of Joseph Lyons & Company, but in the 1950s they ran a chain of tea shops in the UK. I have to pause here for a second and explain what the term "tea shop" means. It's not a shop where you can buy bags of tea (which is what I assumed). Instead, it is what Americans call a coffee shop -- a fixed-menu restaurant that people would come to when they wanted to have a quick meal, snack, or meeting. The closest equivalent in the US these days is probably Denny's.
In the 1950s, Lyons had the biggest network of tea shops in the UK. It employed 30,000 people and served 150 million meals a year. The company sold 36 miles of Swiss roll a day (link).
(In case you're wondering, Swiss roll is a flat sponge cake rolled around a filling. Americans call it jelly roll. In India, it's called jam roll. In Sweden, rulltårta. In Japan, "roll cake." But in Spain, for some reason it's called brazo de gitano (gypsy's arm). Don't ask me why. [link] )
A Swiss roll made and photographed by Musical Linguist on 25 June 2006
Like every other company of its day, everything at Lyons was run on paper -- tallying 150 million receipts, calculating payroll, managing taxes, and even figuring out how many miles of Swiss roll you need to make for tomorrow's customers. All of that by hand with adding machines. It was an incredibly expensive and error-prone way of running a business, but it was the best anyone could do at the time.
When the people at Lyons first heard about these new computer thingies, they wanted one immediately to help run the business. But there wasn't any way to buy one. So they donated $5,000 (about $50k today) to Cambridge University to create a modified version of a computer that Cambridge had been working on.
The result was called LEO (Lyons Electronic Computer), and when it started regular operations on November 17, 1951, it was the world's first business computer. It occupied 5,000 square feet of floor space (about 500 square meters), and its 4k memory unit weighed half a ton because it was full of mercury. LEO's lead programmer was David Caminer, who is generally credited as either the world's first business software programmer or the first systems analyst. LEO's software let it handle -- guess what -- the same sorts of tasks we handle on business computers today: payroll, inventory, financials, and so on. It cut the time to calculate one employee's wages from eight minutes to 1.5 seconds (link).
David Caminer
Pause for a moment and think about the courage and vision it took for Lyons -- a catering company -- to build its own computer. There was no guarantee the process would succeed, and indeed the process took two years, with plenty of setbacks along the way.
But LEO was eventually a big success, and Lyons eventually spun it out as a separate computing subsidiary. Caminer went on to have a distinguished career in computing. He died in 2008, unfortunately, so we just missed our opportunity to say thanks to him. If you want to read more about LEO, Caminer co-wrote a book about it (link). Naturally, it's out of print, and the cheapest used copy when I looked it up was $75.
What is software, anyway?
One interesting aspect of LEO is that although Caminer and his team wrote software for it, that software was not available separately from the computer. That's the way the computing industry worked throughout the 1950s. For example, if you bought an IBM computer there was a set of standard IBM programs that ran on it.
In fact, the term "software" didn't even exist until it was popularized by John Tukey in 1958, more than ten years after ENIAC began operation (link). He wrote:
So the whole idea of software as a separate entity, a concept that we take for granted today, did not exist at the beginning of computing. The concept of making computers reprogrammable came along quite early, but it took a couple of decades for software to fully separate itself from hardware as its own distinct discipline.
John Tukey
(Naturally, there's some dispute about whether Tukey was the first to use the term "software." You can read about it here.)
Tukey was an interesting guy. He also created the term "bit," helped design the U-2 spy plane, and did a lot of other fascinating things (link).
If you want to read more about the history of software technologies, there's an essay here. And the best (and just about only) book on the history of the software industry is here.
Software as a business
Once we got the idea of software into our heads as a separate discipline, the next milestone in platform history was the creation of the first independent computer program, the first one you could buy separately from the hardware. As far as I can tell, that idea didn't just spring into being all at once; it emerged as a slow-motion avalanche over a period of 15 years.
Computer Usage Corporation, founded in 1955, is often cited as the first computer software company. It focused on custom programming services (link). Another very early custom programming company was CEIR, founded in 1954 (link). After them, a number of other custom programming firms sprang up. Sometime between 1962 and 1965, California Analysis Center, Inc. started selling a proprietary version of the Simscript programming language as a standalone product (the Computer History Museum says it was 1962 here, but CACI's own website says 1965 here). The 1962 date is the earliest I can find for any sort of independent software product. To my amazement, CACI is still selling Simscript today (link).
Several other programming languages and compilers came to market in the early 1960s, but there's disagreement over how much they actually sold, or whether they were really managed as independent products (link). A file management program called Mark IV, by Informatics, is credited as the first independent software product to generate more than a million dollars revenue. It was published in 1967 (link). That year also saw the first publication of the International Computer Programs Quarterly, the first commercial software catalog, which helped small software companies get to market at low cost (link). Think of it as a paper version of the iPhone App Store.
But if you want to find the first snowball that started the commercial software avalanche, I think it was tossed in 1964 when a contract programming company called Advanced Data Research was jerked around on a business deal by RCA.
The first commercial software product
In the mid-1960s, a cottage industry of contract programming firms did custom software development. When a new mainframe was in the works, its manufacturer would sometimes hire these firms to create software to offer with it. Computer owners could also hire those development houses to write create custom software for them. The idea of off-the-shelf software didn't exist; you got it for free with your computer, had it written for you, or developed it yourself.
RCA, which at the time was a promising mainframe company, approached ADR asking them to create a program to draw flow charts of computer programs (the flow charts were used for documentation and debugging). That may not sound like a big deal today, but in the early days of computing the industry didn't have the sort of automated debugging tools it has today. A flowchart was very useful to help maintain and document a custom software program after the project was finished.
So ADR created a proposal and submitted it to RCA. Fortunately for the computer industry, RCA turned it down, as did every other mainframe company. But ADR believed in its concept, so it decided on its own to develop the product anyway. It spent over $5,000 (about $35k in today's money) and half a man-year on the project.
But RCA was not impressed. Once again they said no.
Now ADR had a sunk cost. In business school they teach you to walk away from those, but in real life companies hate to admit they made a mistake. So ADR decided to try marketing the software on its own. They named it Autoflow, and wrote a letter to all 100 RCA mainframe owners offering them the program for $2,400 on a three year lease. It was three milestones in one: the first commercial software program, the first subscription software, and the first junk mail urging you to buy a software program.
ADR sold two licenses.
That may not sound like much, but somebody at ADR did the math -- if we sold two copies to 100 RCA customers, what would happen if we offered our software to IBM's much larger installed base? So ADR ported Autoflow to IBM mainframes. In the second half of the1960s it sold more than a thousand licenses of Autoflow, and created a portfolio of other independent software programs for IBM systems.
IBM was not pleased. Nobody was supposed to mess with the IBM customer base; that might weaken IBM's control over its customers. The company created its own flow charting software, which it gave away for free to its customers, and started to copy ADR's other programs as well. This became a huge competitive problem for ADR -- even if its software worked better than IBM's, it was hard to compete with free. IBM was also able to freeze the market for ADR by promising that it would in the future offer a free version of something ADR was currently selling. Customers would delay ADR purchases until they could evaluate the IBM product.
ADR and other fledgling software companies complained to the US government. In 1969, the Justice Department, ADR, and several others filed antitrust suits against IBM. ADR collected $2 million in penalties, and IBM agreed to stop bundling free software with its computers.
And thus the independent software industry was born.
Martin Goetz (above) was the product manager of Autoflow. I wrote to him and asked for his take on which was the first software product. Here's his reply:
I think that's the right way to look at it: Autoflow was the first software product to be commercially marketed, which is why I call it the snowball that started the avalanche. Informatics' Mark IV also played an important role because its financial success validated the market -- reportedly it was the top-selling software product for the next 15 years (link).
Goetz says Mike Guzik was the lead programmer on Autoflow (link), and he cites ADR President Dick Jones as a strong supporter of the idea (link). I think we should credit Goetz and Guzik as the creators of the first commercial software application, although neither of them has an entry in Wikipedia.
Incidentally, Goetz also holds the first software patent:
Computerworld, June 1968
That has to be one of the most visionary headlines in the history of the computer press: "Full Implications Are Not Yet Known." Here we are 41 years later, and it's still accurate.
Goetz was named the "Father of Third-Party Software" by mainframezone.com (link) and there's a very interesting interview with him here. You can find a much longer interview here and his memoirs are here.
Advocates of open source software will probably view Goetz as a bad guy, since he helped make software a for-profit industry. But he has some pretty strong opinions about the poor quality and slow innovations that happened in software when it was only free. In particular, he says that a completely free software industry was not responsive to the needs of users (link).
An amusing anecdote complaining about Goetz, apparently written by a former ADR employee, is here. I can't verify the anecdote, but if nothing else it shows that ADR was also a pioneer in the practice of engineers making catty comments about product managers.
(I should add that there are some different interpretations of the effect of IBM's unbundling decision. One is in a very interesting interview with the creator of the ICP catalog here.)
The rise of the third party application platform
The next evolutionary step was for computer companies to see their products as development platforms -- for them to actively encourage software developers rather than viewing them as a nuisance. I haven't been able to figure out when in the 1970s this change in perspective happened (please post a comment if you know the history). It may have happened in the era of minicomputers, or it may have been a PC thing. Definitely Dan Bricklin and Bob Frankston's VisiCalc, the world's first spreadsheet program, played a role when it came to market for the Apple II in 1979. It was so revolutionary that reviewers at the time didn't know how to describe it. They just said it was a way to make the computer do things you want it to do, without writing your own program. VisiCalc established the idea of the "killer app," a software program so popular that it drove demand for the underlying hardware.
By the early 1980s, software developers were being actively courted by computer manufacturers. Apple had a developer recruitment team for the Macintosh, and apparently coined the term "software evangelism." That's where Guy Kawasaki cut his eyeteeth, although he wasn't the first evangelist. As he puts it:
I happen to know that Guy did a bit of the work too.
The other critical change in the 1980s was the separation of the OS from the underlying hardware. Most of the new PC software platforms had been tied to hardware, just like traditional computers. For example, you had to buy a Macintosh in order to run Mac software, or an Amiga in order to use Amiga apps. But then IBM created the PC, and through a series of business blunders allowed Microsoft to separately sell the DOS operating system used on its hardware. IBM's brand and marketing power established the PC as a standard, but the company enabled Microsoft and Intel to create a "clone" hardware market, and eventually drive IBM out of the PC business.
So now there were three layers in the industry -- the application was independent of the OS, and the leading OS was independent of the hardware.
The network strikes back
That's where the situation sat until the late 1990s, when Java and web browsers threatened to create another layer in the architecture by separating software applications from the OS. The theory was that instead of writing programs that depended on Windows, programmers could create code that worked on Java, or on the Netscape browser.
Microsoft fought back very aggressively, killing Netscape by giving away Internet Explorer, and crippling Java on the PC. Looking back, it was an impressive use of business muscle, worthy of Microsoft's tutor IBM.
But it was also a pyrrhic victory. Microsoft's actions in the 1990s forced software innovation completely off the PC platform, because investors were afraid that new software apps would just get cannibalized by Microsoft. Instead software innovation moved onto the web, where Microsoft had virtually no control. That's one of several reasons why the next generation of software is being written as web apps.
And that's where we are today.
Where we go next
As I said at the start of the post, I think all of this history is fun in its own right. I also wanted to take this opportunity to thank some of the people who built the tech industry into the fun place it is today.
But understanding computing history is also very important because, if you look across the sweep of it from the 1940s to today, it's much easier to see where we might go next.
Here's what I think that long perspective shows us: The history of software is a history of disaggregation. First the application software gets separated from the hardware, then the OS gets separated from the hardware, and so on.
I think disaggregation is a natural outcome of the maturation of the industry, because multiple companies can move faster than a single one. At the start you need everything coordinated together to make sure the whole thing will work. But over time, no single company can pursue all of the innovation possibilities, so you get a backlog of potential creativity that can happen only if control over the architecture is broken into pieces.
For example, most of the interesting innovation in applications happened only after they were separated from the hardware.
But as the industry continues to grow, each of the pieces becomes its own stodgy monolith, and eventually another subdivision happens.
The fastest growth and the easiest innovation has generally happened at the leading edge of disaggregation, because each change creates new business opportunities.
That doesn't mean that old school companies are dead. IBM still sells mainframes, and Apple still makes PCs bundled with an OS. But to succeed in an old paradigm you have to execute extremely well, and it's much harder to grow explosively. The easiest progress is made at the leading edge.
A common thread among the people working at the leading edge of disaggregation is their excitement as they recognize the opportunities created by the change:
That's Walter Bauer, cofounder of Informatics, talking about the birth of the independent software industry in the 1960s (link). But you could find similar sentiments from the people who built the first computers, or the first Mac programmers, or the first web app developers. The leading edge of disaggregation is where the action is; it's where the fun happens.
So, if you're looking to succeed in the software industry, it's extremely important to figure out what's going to get disaggregated next. Which brings us to the point of this article.
Say hello to the metaplatform
Sun's rallying cry in the 1990s was, "the network is the computer" (link). It was an excellent insight that pointed to the emerging importance of the Internet, but most of the industry misread what it meant. We looked at the architecture of the thing we knew best, the PC, and tried to map it directly to the network. So servers would replace the PC hardware, and software on those servers would replace Windows. The PC itself would be reduced to light client, a screen connected to a wire.
What we expected
But instead of a new OS on the network replacing the OS on the PC, what we're seeing is the breakdown of the OS into component parts that live everywhere, on both the client and the server.
In other words, the OS is the next thing that gets disaggregated.
What's actually happening
People have been talking about elements of this change for years, but like the proverbial blind men feeling bits of the elephant, we've talked about individual pieces of it, with each of us assuming that the piece in front of us was the most important. So people producing software layers like Java and Flash say that they are separating the APIs on the device from the underlying OS. And the advocates of cloud computing say they're creating a software services architecture that runs on servers. But in reality we're doing both of those things, and a lot more. The OS is dissolving into a soup of resources distributed across both the network and the local device, with the application in the middle calling on both as appropriate. We need to get off the idea that the network or the client will be dominant; they're both supporting elements in something larger.
You can see this process operating in the evolution of web applications. The first web app companies tried to make applications that were entirely light client, but they didn't work particularly well -- they were slow, and their user interfaces were too limited. Web apps took off only when they adopted an approach in which the platform was split between the PC and the network -- the user interface ran locally through the browser, while back-end calculation and data storage was done on the network.
Mobile computing reinforces the need for this sort of hybrid architecture. Wireless broadband has important limitations that make pure light client computing extremely problematic. Wireless networks are relatively slow compared to wired networks, there's high latency on them, coverage is inconsistent, heavy communication drains device batteries rapidly, bandwidth is expensive, and most importantly, total wireless bandwidth is limited. The most effective mobile application are and will continue to be hybrids of local and network resources, like RIM's e-mail solution.
Companies entering the mobile market often ask me which mobile operating systems are going to win long term. I think that's the wrong question. What we're seeing is the gradual evolution of a super-OS that includes both the network and the device.
Like software developers before the word "software" was invented, we don't have a name for this new thing, and so we have trouble talking about it. It's not just the Network or the Cloud, because those terms are usually understood not to include the software on the client computer. And it's certainly not just the local APIs on the client device.
I'm calling it the "metaplatform" because it subsumes all other platforms. No single company controls the metaplatform. Google obviously contributes a lot to it, as does Amazon Web Services, as does Microsoft. But they're only fragments of the picture. There are thousands of other contributors to the metaplatform, in areas ranging from mapping to graphics to identity.
There's still a lot of work that needs to be done on the metaplatform, especially in the mobile space. But already it's evolving faster than any single company could move it, because the work is divided across so many companies, and because there's competition driving innovation at almost every point in the architecture. Although the metaplatform isn't necessarily elegant (because it's poorly coordinated), what it lacks in beauty it more than makes up for in rate of change and versatility.
New opportunities
The metaplatform helps to solve some computing problems, but creates others. For example, a recurring problem for software in the OS era has been compatibility. Old data files, even when perfectly preserved, can become unreadable if the hardware and software that created them is no longer available. A lot of software is very dependent not just on the hardware, but on the particular version of the OS it's running on. (If you want to see that effect in action, try running a ten-year-old Windows game on a new PC. It may work, it may refuse to run at all -- or it may freeze right when you're about to defeat the boss bad guy.)
The metaplatform is helping to resolve some compatibility problems, through emulators available online. But more importantly, web apps on a PC are less vulnerable to PC-style compatibility breakdowns because PC browsers are relatively standardized, and much of the OS code the web app relies on lives on the same server as the app itself, so they are less likely to get out of sync.
But metaplatform-based software is uniquely vulnerable to a new set of problems. When a user's data is stored on a web app company's server 3,000 miles away, what happens if that company goes out of business or just decides to stop maintaining the product?
Another problem experienced by any website using plug-ins is component breakage. If you've incorporated external web services into your site, the site will break if any of those services stops working. This can happen without warning. On my own weblog, the load time for the site suddenly became ridiculously long. It took me weeks to realize that a user-tracking service I'd once signed up for had gone out of business without telling anyone. My site stopped loading while it tried helplessly to connect to a tracking site that no longer existed.
An old software application from the OS era has some hope of revival if you have a copy of the CD, because all the code that made up the app is together in one place. But an old, broken web app will be almost irretrievably dead, because huge chunks of its code will be missing.
Problems like these are just starting to emerge, but as the metaplatform grows and ages they'll become much more prominent. We don't have any systematic ways to deal with problems like these today -- which means they're a business opportunity for the next crop of software entrepreneurs.
What the metaplatform means to you
Much of the discussion in this post is pretty theoretical. But I think it has important practical implications. Here are a few specifics to think about:
If you're a computer user (and if you're reading this, you must be), keep in mind that the most interesting new software innovations are likely to come from companies that consciously work the metaplatform. If you want to be at the leading edge of software innovation, you should keep yourself open to experimenting with new web applications and plug-ins, and make sure your browser doesn't artificially cut you off from some technologies. This is especially true for mobile devices. The iPhone today gives (in my opinion) the best overall mobile browsing and app discovery experience, but you pay a price for it -- you're cut off from some web technologies (Flash, Java) and your choice of applications is limited by the Apple app police. You pay a serious price for the superior user experience of the iPhone. That price is worth paying today, but in the future I hope there will be mobile devices that are as satisfying as the iPhone but less controlled. Actually, I'm sure that will happen over time. But "over time" can sometimes mean a long time in the future. You can help the process along with what you buy and by the feedback you give to device manufacturers.
Are you working at an OS company? If so, you probably measure success by the number of devices your software controls. You need to rethink that viewpoint. The OS is going to be less and less of a technology control point in the future. It will become commodity plumbing underneath the metaplatform, limiting your ability to charge a lot of money for it. So at a minimum, you need to plan for cost control.
But you should also be asking if plumbing is the right place for your company's creativity in the long term. There will be much more profit opportunity in contributing to the metaplatform by creating APIs and developer functionality that can be used across different operating systems. OS companies have many of the assets needed to build those components of the metaplatform. A successful OS can be a great launching point for technologies that run across platforms, because you already have a big installed base that you can use to jump-start the technology's adoption.
Are you at an application company? Many successful app vendors are trying to create APIs that will enable other developers to extend their products. This is the right idea, but the implementation is often off-target. Many of the app companies I talk to are trying to make their APIs into the business equivalent of an operating system, with developers coming to them and living entirely within their private ecosystem. A warning sign is when a company uses a phrase like, "(insert company name) developer network" to describe its offering.
The wave of the future is not turning an application inward into its own little walled garden; it's opening the application outward so it can be mixed and matched with other functionality in the metaplatform. If you have the best drawing program in the industry, you should be asking how you can also become the best drawing module in the metaplatform. Get used to being a component in addition to a standalone product. You lose some identity in the process, but gain greater opportunities to grow.
And besides, if you don't do it, you'll be vulnerable to someone else doing it and taking your place.
If you're a computing student, or a computing veteran looking to create a new product, think about what role you can play in the metaplatform, and what customer problems you can solve with this new tool. There will be big market openings in both products for users and companies, and infrastructure for other developers in the ecosystem (billing, rights management, security, etc).
As in previous generations of software, the answers are not immediately obvious, and the people who figure them out first will have huge opportunities to do something impactful. Like Caminer, Goetz, Bauer, Bricklin, and Frankston, you're on an enormous beach with a trowel and bucket, and you have a chance to shape the next generation of computing.
Have fun.
====
I'd like to thank Eugene Miya of NASA Ames and Martin Goetz for helping with the research that contributed to this article. They're not responsible for any errors I made, but they definitely corrected some.
I'm sure there are folks out there who have additional information on the history I wrote about here. If you have anything to add (or correct) please post a comment.
To explain how software platforms work today, I thought it'd be good to start with their history. But I wasn't sure about many of the details myself, so I ended up doing some research. The information was surprisingly hard to find, and also pretty controversial -- for every person who claims to be the first to have done something in computing, there's someone else who begs to differ. I did my best to sort through all the claims. The picture that developed makes an interesting story, but also has some very important lessons about where the industry might go next.
Fair warning: this is a long post. But I hope you'll feel that the destination is worth the trip.
Here's what I found:
Hardware memory, software amnesia
The computer industry is often criticized for its failure to remember its own history. Supposedly we're so focused on the new thing that we forget what's come before.
In reality, though, we're actually fairly good at remembering a lot of our hardware history (for example, Apple fans are celebrating the 25th anniversary of the Macintosh this year). There's passionate controversy over what was the first computer -- was it Konrad Zuse's Z1 (link), Tommy Flowers' Colossus (link), etc. The answer depends in part on your definition of the word "computer." But it's a well-documented disagreement, and you can find a lot of information about it online, including a cool timeline at the Computer History Museum (link).
The machine most commonly cited as the first fully programmable general-purpose electronic computer was ENIAC, the Electronic Numerical Integrator And Computer. It was completed in 1946 (link).
Here's ENIAC (well, part of it, anyway)
You can find lots of histories of ENIAC online (link). There are multiple simulators of it on the web (link), and the engineering school at the University of Pennsylvania even has an ENIAC museum online (link).
But when it comes to software, our memories are much hazier. For example, I doubt there will be a 25th anniversary celebration in 2010 for Aldus PageMaker, the program that did more than any other to make Macintosh successful. And about a day after I post this article -- May 12, 2009 -- will be the 30th anniversary of the introduction of Visicalc, the first spreadsheet program. Anyone planning a parade?
Today we take it for granted that you can use a computer for a variety of business or personal tasks, but it didn't always work that way. ENIAC and Colossus were government-funded tools for solving military and scientific problems. The US Army funded ENIAC, and in addition to calculating artillery tables, it was also used for tasks like weather prediction, wind tunnel design, and atomic energy calculations.
These nice ladies are programming ENIAC, by moving cables around.
How did we end up using computers for other purposes? The UPenn site says only, "it is recalled that no electronic computers were being applied to commercial problems until about 1951."
Yeah, "it is recalled." This is where I had to start digging. Once again there are disputes (link), but you can make a very good case that business computing started in the UK, and it involved something called a Swiss roll.
The first business computer
I had never heard of Joseph Lyons & Company, but in the 1950s they ran a chain of tea shops in the UK. I have to pause here for a second and explain what the term "tea shop" means. It's not a shop where you can buy bags of tea (which is what I assumed). Instead, it is what Americans call a coffee shop -- a fixed-menu restaurant that people would come to when they wanted to have a quick meal, snack, or meeting. The closest equivalent in the US these days is probably Denny's.
In the 1950s, Lyons had the biggest network of tea shops in the UK. It employed 30,000 people and served 150 million meals a year. The company sold 36 miles of Swiss roll a day (link).
(In case you're wondering, Swiss roll is a flat sponge cake rolled around a filling. Americans call it jelly roll. In India, it's called jam roll. In Sweden, rulltårta. In Japan, "roll cake." But in Spain, for some reason it's called brazo de gitano (gypsy's arm). Don't ask me why. [link] )
A Swiss roll made and photographed by Musical Linguist on 25 June 2006
Like every other company of its day, everything at Lyons was run on paper -- tallying 150 million receipts, calculating payroll, managing taxes, and even figuring out how many miles of Swiss roll you need to make for tomorrow's customers. All of that by hand with adding machines. It was an incredibly expensive and error-prone way of running a business, but it was the best anyone could do at the time.
When the people at Lyons first heard about these new computer thingies, they wanted one immediately to help run the business. But there wasn't any way to buy one. So they donated $5,000 (about $50k today) to Cambridge University to create a modified version of a computer that Cambridge had been working on.
The result was called LEO (Lyons Electronic Computer), and when it started regular operations on November 17, 1951, it was the world's first business computer. It occupied 5,000 square feet of floor space (about 500 square meters), and its 4k memory unit weighed half a ton because it was full of mercury. LEO's lead programmer was David Caminer, who is generally credited as either the world's first business software programmer or the first systems analyst. LEO's software let it handle -- guess what -- the same sorts of tasks we handle on business computers today: payroll, inventory, financials, and so on. It cut the time to calculate one employee's wages from eight minutes to 1.5 seconds (link).
David Caminer
Pause for a moment and think about the courage and vision it took for Lyons -- a catering company -- to build its own computer. There was no guarantee the process would succeed, and indeed the process took two years, with plenty of setbacks along the way.
But LEO was eventually a big success, and Lyons eventually spun it out as a separate computing subsidiary. Caminer went on to have a distinguished career in computing. He died in 2008, unfortunately, so we just missed our opportunity to say thanks to him. If you want to read more about LEO, Caminer co-wrote a book about it (link). Naturally, it's out of print, and the cheapest used copy when I looked it up was $75.
What is software, anyway?
One interesting aspect of LEO is that although Caminer and his team wrote software for it, that software was not available separately from the computer. That's the way the computing industry worked throughout the 1950s. For example, if you bought an IBM computer there was a set of standard IBM programs that ran on it.
In fact, the term "software" didn't even exist until it was popularized by John Tukey in 1958, more than ten years after ENIAC began operation (link). He wrote:
Today the "software" comprising the carefully planned interpretive routines, compilers, and other aspects of automative programming are at least as important to the modern electronic calculator as its "hardware" of tubes, transistors, wires, tapes and the like.
So the whole idea of software as a separate entity, a concept that we take for granted today, did not exist at the beginning of computing. The concept of making computers reprogrammable came along quite early, but it took a couple of decades for software to fully separate itself from hardware as its own distinct discipline.
John Tukey
(Naturally, there's some dispute about whether Tukey was the first to use the term "software." You can read about it here.)
Tukey was an interesting guy. He also created the term "bit," helped design the U-2 spy plane, and did a lot of other fascinating things (link).
If you want to read more about the history of software technologies, there's an essay here. And the best (and just about only) book on the history of the software industry is here.
Software as a business
Once we got the idea of software into our heads as a separate discipline, the next milestone in platform history was the creation of the first independent computer program, the first one you could buy separately from the hardware. As far as I can tell, that idea didn't just spring into being all at once; it emerged as a slow-motion avalanche over a period of 15 years.
Computer Usage Corporation, founded in 1955, is often cited as the first computer software company. It focused on custom programming services (link). Another very early custom programming company was CEIR, founded in 1954 (link). After them, a number of other custom programming firms sprang up. Sometime between 1962 and 1965, California Analysis Center, Inc. started selling a proprietary version of the Simscript programming language as a standalone product (the Computer History Museum says it was 1962 here, but CACI's own website says 1965 here). The 1962 date is the earliest I can find for any sort of independent software product. To my amazement, CACI is still selling Simscript today (link).
Several other programming languages and compilers came to market in the early 1960s, but there's disagreement over how much they actually sold, or whether they were really managed as independent products (link). A file management program called Mark IV, by Informatics, is credited as the first independent software product to generate more than a million dollars revenue. It was published in 1967 (link). That year also saw the first publication of the International Computer Programs Quarterly, the first commercial software catalog, which helped small software companies get to market at low cost (link). Think of it as a paper version of the iPhone App Store.
But if you want to find the first snowball that started the commercial software avalanche, I think it was tossed in 1964 when a contract programming company called Advanced Data Research was jerked around on a business deal by RCA.
The first commercial software product
In the mid-1960s, a cottage industry of contract programming firms did custom software development. When a new mainframe was in the works, its manufacturer would sometimes hire these firms to create software to offer with it. Computer owners could also hire those development houses to write create custom software for them. The idea of off-the-shelf software didn't exist; you got it for free with your computer, had it written for you, or developed it yourself.
RCA, which at the time was a promising mainframe company, approached ADR asking them to create a program to draw flow charts of computer programs (the flow charts were used for documentation and debugging). That may not sound like a big deal today, but in the early days of computing the industry didn't have the sort of automated debugging tools it has today. A flowchart was very useful to help maintain and document a custom software program after the project was finished.
So ADR created a proposal and submitted it to RCA. Fortunately for the computer industry, RCA turned it down, as did every other mainframe company. But ADR believed in its concept, so it decided on its own to develop the product anyway. It spent over $5,000 (about $35k in today's money) and half a man-year on the project.
But RCA was not impressed. Once again they said no.
Now ADR had a sunk cost. In business school they teach you to walk away from those, but in real life companies hate to admit they made a mistake. So ADR decided to try marketing the software on its own. They named it Autoflow, and wrote a letter to all 100 RCA mainframe owners offering them the program for $2,400 on a three year lease. It was three milestones in one: the first commercial software program, the first subscription software, and the first junk mail urging you to buy a software program.
ADR sold two licenses.
That may not sound like much, but somebody at ADR did the math -- if we sold two copies to 100 RCA customers, what would happen if we offered our software to IBM's much larger installed base? So ADR ported Autoflow to IBM mainframes. In the second half of the1960s it sold more than a thousand licenses of Autoflow, and created a portfolio of other independent software programs for IBM systems.
IBM was not pleased. Nobody was supposed to mess with the IBM customer base; that might weaken IBM's control over its customers. The company created its own flow charting software, which it gave away for free to its customers, and started to copy ADR's other programs as well. This became a huge competitive problem for ADR -- even if its software worked better than IBM's, it was hard to compete with free. IBM was also able to freeze the market for ADR by promising that it would in the future offer a free version of something ADR was currently selling. Customers would delay ADR purchases until they could evaluate the IBM product.
ADR and other fledgling software companies complained to the US government. In 1969, the Justice Department, ADR, and several others filed antitrust suits against IBM. ADR collected $2 million in penalties, and IBM agreed to stop bundling free software with its computers.
And thus the independent software industry was born.
Martin Goetz (above) was the product manager of Autoflow. I wrote to him and asked for his take on which was the first software product. Here's his reply:
Autoflow was recognized as the first software product to be commercially marketed. Starting in 1964, ADR licensed its products nationally and through ads in all the major computer publications, started investing in the development of other products and became known as a software products company.
I think that's the right way to look at it: Autoflow was the first software product to be commercially marketed, which is why I call it the snowball that started the avalanche. Informatics' Mark IV also played an important role because its financial success validated the market -- reportedly it was the top-selling software product for the next 15 years (link).
Goetz says Mike Guzik was the lead programmer on Autoflow (link), and he cites ADR President Dick Jones as a strong supporter of the idea (link). I think we should credit Goetz and Guzik as the creators of the first commercial software application, although neither of them has an entry in Wikipedia.
Incidentally, Goetz also holds the first software patent:
Computerworld, June 1968
That has to be one of the most visionary headlines in the history of the computer press: "Full Implications Are Not Yet Known." Here we are 41 years later, and it's still accurate.
Goetz was named the "Father of Third-Party Software" by mainframezone.com (link) and there's a very interesting interview with him here. You can find a much longer interview here and his memoirs are here.
Advocates of open source software will probably view Goetz as a bad guy, since he helped make software a for-profit industry. But he has some pretty strong opinions about the poor quality and slow innovations that happened in software when it was only free. In particular, he says that a completely free software industry was not responsive to the needs of users (link).
An amusing anecdote complaining about Goetz, apparently written by a former ADR employee, is here. I can't verify the anecdote, but if nothing else it shows that ADR was also a pioneer in the practice of engineers making catty comments about product managers.
(I should add that there are some different interpretations of the effect of IBM's unbundling decision. One is in a very interesting interview with the creator of the ICP catalog here.)
The rise of the third party application platform
The next evolutionary step was for computer companies to see their products as development platforms -- for them to actively encourage software developers rather than viewing them as a nuisance. I haven't been able to figure out when in the 1970s this change in perspective happened (please post a comment if you know the history). It may have happened in the era of minicomputers, or it may have been a PC thing. Definitely Dan Bricklin and Bob Frankston's VisiCalc, the world's first spreadsheet program, played a role when it came to market for the Apple II in 1979. It was so revolutionary that reviewers at the time didn't know how to describe it. They just said it was a way to make the computer do things you want it to do, without writing your own program. VisiCalc established the idea of the "killer app," a software program so popular that it drove demand for the underlying hardware.
"Visicalc could some day become the software tail that wags (and sells) the personal computer dog."
--Ben Rosen, co-founder of Compaq, reviewing VisiCalc when we was still an analyst with Morgan Stanley. Nice call, Ben. (Link)
By the early 1980s, software developers were being actively courted by computer manufacturers. Apple had a developer recruitment team for the Macintosh, and apparently coined the term "software evangelism." That's where Guy Kawasaki cut his eyeteeth, although he wasn't the first evangelist. As he puts it:
"Mike Boich started evangelism and hired me, and Alain Rossman worked with me as a software evangelist. Essentially, Mike started evangelism, Alain did the work, and I took the credit." (Link)
I happen to know that Guy did a bit of the work too.
The other critical change in the 1980s was the separation of the OS from the underlying hardware. Most of the new PC software platforms had been tied to hardware, just like traditional computers. For example, you had to buy a Macintosh in order to run Mac software, or an Amiga in order to use Amiga apps. But then IBM created the PC, and through a series of business blunders allowed Microsoft to separately sell the DOS operating system used on its hardware. IBM's brand and marketing power established the PC as a standard, but the company enabled Microsoft and Intel to create a "clone" hardware market, and eventually drive IBM out of the PC business.
So now there were three layers in the industry -- the application was independent of the OS, and the leading OS was independent of the hardware.
The network strikes back
That's where the situation sat until the late 1990s, when Java and web browsers threatened to create another layer in the architecture by separating software applications from the OS. The theory was that instead of writing programs that depended on Windows, programmers could create code that worked on Java, or on the Netscape browser.
Microsoft fought back very aggressively, killing Netscape by giving away Internet Explorer, and crippling Java on the PC. Looking back, it was an impressive use of business muscle, worthy of Microsoft's tutor IBM.
But it was also a pyrrhic victory. Microsoft's actions in the 1990s forced software innovation completely off the PC platform, because investors were afraid that new software apps would just get cannibalized by Microsoft. Instead software innovation moved onto the web, where Microsoft had virtually no control. That's one of several reasons why the next generation of software is being written as web apps.
And that's where we are today.
Where we go next
As I said at the start of the post, I think all of this history is fun in its own right. I also wanted to take this opportunity to thank some of the people who built the tech industry into the fun place it is today.
But understanding computing history is also very important because, if you look across the sweep of it from the 1940s to today, it's much easier to see where we might go next.
Here's what I think that long perspective shows us: The history of software is a history of disaggregation. First the application software gets separated from the hardware, then the OS gets separated from the hardware, and so on.
I think disaggregation is a natural outcome of the maturation of the industry, because multiple companies can move faster than a single one. At the start you need everything coordinated together to make sure the whole thing will work. But over time, no single company can pursue all of the innovation possibilities, so you get a backlog of potential creativity that can happen only if control over the architecture is broken into pieces.
For example, most of the interesting innovation in applications happened only after they were separated from the hardware.
But as the industry continues to grow, each of the pieces becomes its own stodgy monolith, and eventually another subdivision happens.
The fastest growth and the easiest innovation has generally happened at the leading edge of disaggregation, because each change creates new business opportunities.
That doesn't mean that old school companies are dead. IBM still sells mainframes, and Apple still makes PCs bundled with an OS. But to succeed in an old paradigm you have to execute extremely well, and it's much harder to grow explosively. The easiest progress is made at the leading edge.
A common thread among the people working at the leading edge of disaggregation is their excitement as they recognize the opportunities created by the change:
"There was a tremendous euphoria of success. You couldn't lose. All you needed was a group of highly technical people who could create a software product and that was it. And to some degree there was some truth to that. Because you didn't have to be good sales people. You didn't have to worry about the competition. For years I used the aphorism that we were like little boys on the beach each with our sand piles. There was plenty of sand to put in our buckets. We didn't have to edge out the other little boy to get all the sand we needed. We were limited by the size of our pail and our little shovels but not by the amount of the beach that was there or the fact that there was another little boy there with his pail."
That's Walter Bauer, cofounder of Informatics, talking about the birth of the independent software industry in the 1960s (link). But you could find similar sentiments from the people who built the first computers, or the first Mac programmers, or the first web app developers. The leading edge of disaggregation is where the action is; it's where the fun happens.
So, if you're looking to succeed in the software industry, it's extremely important to figure out what's going to get disaggregated next. Which brings us to the point of this article.
Say hello to the metaplatform
Sun's rallying cry in the 1990s was, "the network is the computer" (link). It was an excellent insight that pointed to the emerging importance of the Internet, but most of the industry misread what it meant. We looked at the architecture of the thing we knew best, the PC, and tried to map it directly to the network. So servers would replace the PC hardware, and software on those servers would replace Windows. The PC itself would be reduced to light client, a screen connected to a wire.
What we expected
But instead of a new OS on the network replacing the OS on the PC, what we're seeing is the breakdown of the OS into component parts that live everywhere, on both the client and the server.
In other words, the OS is the next thing that gets disaggregated.
What's actually happening
People have been talking about elements of this change for years, but like the proverbial blind men feeling bits of the elephant, we've talked about individual pieces of it, with each of us assuming that the piece in front of us was the most important. So people producing software layers like Java and Flash say that they are separating the APIs on the device from the underlying OS. And the advocates of cloud computing say they're creating a software services architecture that runs on servers. But in reality we're doing both of those things, and a lot more. The OS is dissolving into a soup of resources distributed across both the network and the local device, with the application in the middle calling on both as appropriate. We need to get off the idea that the network or the client will be dominant; they're both supporting elements in something larger.
You can see this process operating in the evolution of web applications. The first web app companies tried to make applications that were entirely light client, but they didn't work particularly well -- they were slow, and their user interfaces were too limited. Web apps took off only when they adopted an approach in which the platform was split between the PC and the network -- the user interface ran locally through the browser, while back-end calculation and data storage was done on the network.
Mobile computing reinforces the need for this sort of hybrid architecture. Wireless broadband has important limitations that make pure light client computing extremely problematic. Wireless networks are relatively slow compared to wired networks, there's high latency on them, coverage is inconsistent, heavy communication drains device batteries rapidly, bandwidth is expensive, and most importantly, total wireless bandwidth is limited. The most effective mobile application are and will continue to be hybrids of local and network resources, like RIM's e-mail solution.
Companies entering the mobile market often ask me which mobile operating systems are going to win long term. I think that's the wrong question. What we're seeing is the gradual evolution of a super-OS that includes both the network and the device.
Like software developers before the word "software" was invented, we don't have a name for this new thing, and so we have trouble talking about it. It's not just the Network or the Cloud, because those terms are usually understood not to include the software on the client computer. And it's certainly not just the local APIs on the client device.
I'm calling it the "metaplatform" because it subsumes all other platforms. No single company controls the metaplatform. Google obviously contributes a lot to it, as does Amazon Web Services, as does Microsoft. But they're only fragments of the picture. There are thousands of other contributors to the metaplatform, in areas ranging from mapping to graphics to identity.
There's still a lot of work that needs to be done on the metaplatform, especially in the mobile space. But already it's evolving faster than any single company could move it, because the work is divided across so many companies, and because there's competition driving innovation at almost every point in the architecture. Although the metaplatform isn't necessarily elegant (because it's poorly coordinated), what it lacks in beauty it more than makes up for in rate of change and versatility.
New opportunities
The metaplatform helps to solve some computing problems, but creates others. For example, a recurring problem for software in the OS era has been compatibility. Old data files, even when perfectly preserved, can become unreadable if the hardware and software that created them is no longer available. A lot of software is very dependent not just on the hardware, but on the particular version of the OS it's running on. (If you want to see that effect in action, try running a ten-year-old Windows game on a new PC. It may work, it may refuse to run at all -- or it may freeze right when you're about to defeat the boss bad guy.)
The metaplatform is helping to resolve some compatibility problems, through emulators available online. But more importantly, web apps on a PC are less vulnerable to PC-style compatibility breakdowns because PC browsers are relatively standardized, and much of the OS code the web app relies on lives on the same server as the app itself, so they are less likely to get out of sync.
But metaplatform-based software is uniquely vulnerable to a new set of problems. When a user's data is stored on a web app company's server 3,000 miles away, what happens if that company goes out of business or just decides to stop maintaining the product?
Another problem experienced by any website using plug-ins is component breakage. If you've incorporated external web services into your site, the site will break if any of those services stops working. This can happen without warning. On my own weblog, the load time for the site suddenly became ridiculously long. It took me weeks to realize that a user-tracking service I'd once signed up for had gone out of business without telling anyone. My site stopped loading while it tried helplessly to connect to a tracking site that no longer existed.
An old software application from the OS era has some hope of revival if you have a copy of the CD, because all the code that made up the app is together in one place. But an old, broken web app will be almost irretrievably dead, because huge chunks of its code will be missing.
Problems like these are just starting to emerge, but as the metaplatform grows and ages they'll become much more prominent. We don't have any systematic ways to deal with problems like these today -- which means they're a business opportunity for the next crop of software entrepreneurs.
What the metaplatform means to you
Much of the discussion in this post is pretty theoretical. But I think it has important practical implications. Here are a few specifics to think about:
If you're a computer user (and if you're reading this, you must be), keep in mind that the most interesting new software innovations are likely to come from companies that consciously work the metaplatform. If you want to be at the leading edge of software innovation, you should keep yourself open to experimenting with new web applications and plug-ins, and make sure your browser doesn't artificially cut you off from some technologies. This is especially true for mobile devices. The iPhone today gives (in my opinion) the best overall mobile browsing and app discovery experience, but you pay a price for it -- you're cut off from some web technologies (Flash, Java) and your choice of applications is limited by the Apple app police. You pay a serious price for the superior user experience of the iPhone. That price is worth paying today, but in the future I hope there will be mobile devices that are as satisfying as the iPhone but less controlled. Actually, I'm sure that will happen over time. But "over time" can sometimes mean a long time in the future. You can help the process along with what you buy and by the feedback you give to device manufacturers.
Are you working at an OS company? If so, you probably measure success by the number of devices your software controls. You need to rethink that viewpoint. The OS is going to be less and less of a technology control point in the future. It will become commodity plumbing underneath the metaplatform, limiting your ability to charge a lot of money for it. So at a minimum, you need to plan for cost control.
But you should also be asking if plumbing is the right place for your company's creativity in the long term. There will be much more profit opportunity in contributing to the metaplatform by creating APIs and developer functionality that can be used across different operating systems. OS companies have many of the assets needed to build those components of the metaplatform. A successful OS can be a great launching point for technologies that run across platforms, because you already have a big installed base that you can use to jump-start the technology's adoption.
Are you at an application company? Many successful app vendors are trying to create APIs that will enable other developers to extend their products. This is the right idea, but the implementation is often off-target. Many of the app companies I talk to are trying to make their APIs into the business equivalent of an operating system, with developers coming to them and living entirely within their private ecosystem. A warning sign is when a company uses a phrase like, "(insert company name) developer network" to describe its offering.
The wave of the future is not turning an application inward into its own little walled garden; it's opening the application outward so it can be mixed and matched with other functionality in the metaplatform. If you have the best drawing program in the industry, you should be asking how you can also become the best drawing module in the metaplatform. Get used to being a component in addition to a standalone product. You lose some identity in the process, but gain greater opportunities to grow.
And besides, if you don't do it, you'll be vulnerable to someone else doing it and taking your place.
If you're a computing student, or a computing veteran looking to create a new product, think about what role you can play in the metaplatform, and what customer problems you can solve with this new tool. There will be big market openings in both products for users and companies, and infrastructure for other developers in the ecosystem (billing, rights management, security, etc).
As in previous generations of software, the answers are not immediately obvious, and the people who figure them out first will have huge opportunities to do something impactful. Like Caminer, Goetz, Bauer, Bricklin, and Frankston, you're on an enormous beach with a trowel and bucket, and you have a chance to shape the next generation of computing.
Have fun.
====
I'd like to thank Eugene Miya of NASA Ames and Martin Goetz for helping with the research that contributed to this article. They're not responsible for any errors I made, but they definitely corrected some.
I'm sure there are folks out there who have additional information on the history I wrote about here. If you have anything to add (or correct) please post a comment.
mardi 4 mars 2008
Nokia and Microsoft, sittin' in a tree...
There's so much hype in the mobile industry that I'm always reluctant to use a word like "shocking," but nothing else fits Nokia's announcement today that it will support Microsoft Silverlight.
If you missed the press release (link), Nokia said that it's going to make Microsoft Silverlight available for all of its mobile platforms -- Series 40 (the low-end phone OS), S60 (the high-end OS), and its Maemo Internet tablet. (It's not clear if Silverlight will be bundled or just offered as a download.) Silverlight is a web app graphics and interface layer, intended to displace Adobe Flash.
The announcement was shocking for several reasons:
--Up until now, Nokia and Adobe had worked together closely. Nokia is one of the few companies paying to bundle Flash on its phones, and Nokia had featured Adobe prominently at some of its developer events in Silicon Valley. So the announcement I was expecting was that Nokia would bundle Air, the next evolution of Flash, rather than its competitor.
--Nokia has generally treated Microsoft as the spawn of the devil. The whole Symbian OS consortium was designed primarily as a way to prevent Microsoft from getting a controlling role in mobile software. Now Nokia gives Microsoft's software layer a huge boost?
--Although Microsoft had hinted vaguely about taking Silverlight mobile, it had given no definite plans at all. So this is a huge step forward for Silverlight.
--Just a few weeks ago, Nokia bought TrollTech and announced that its software was going to unify development across Series 40 and S60. Now Nokia endorses Silverlight, which will also run across Series 40 and S60. Which one are developers supposed to focus on?
What in the world is going on?
I don't know. Nobody from Nokia has explained it to me, so I have to read between the lines. Nokia says in the press release: "Nokia aims to support market leading and content rich internet application environments and to embrace and encourage open innovation. By working with Microsoft, we are creating terrific opportunities and additional choices for the development community." Okay, so I guess what they're saying is that they want to support every platform and development option out there. Presumably the benefit to them is that they can claim their phones support more software than anyone else.
I doubt that's the only motivation, though. By supporting numerous platforms, Nokia reduces the possibility that any one of them can dominate the market and push around Nokia. It also lets Nokia play the sides off against one another. I'm sure the threat of embracing Air made Microsoft give Nokia a very good deal on Silverlight, and no doubt Nokia will now use its Microsoft relationship to get business concessions from Adobe (assuming that Nokia still plans to work with Adobe at all; that's not entirely clear).
Anyway, I can sort of see how this all works for Nokia strategically, although it feels like Nokia is trying too hard to be clever. I'm not as clear on the benefits of all this for mobile developers and users. As was covered in last week's post on mobile apps (link), many developers view the proliferation of platforms as a problem, not a benefit. Microsoft itself said in the Nokia press release:
That's a pretty danged funny quote coming from a company that now offers at least four mobile platforms (two versions of Windows Mobile, Silverlight, Tablet PC, and does .Net CF count as a fifth?), in a press release from a company that apparently wants to support every platform available. If you really think platform confusion is a problem, guys, look in a mirror.
For users, the benefit of all this deal-making is unclear. We're stumbling into a world where you'll need to know details of which platforms are loaded on a particular phone in order to know which apps it can run. I can't think of a better way to discourage use of mobile applications.
If you missed the press release (link), Nokia said that it's going to make Microsoft Silverlight available for all of its mobile platforms -- Series 40 (the low-end phone OS), S60 (the high-end OS), and its Maemo Internet tablet. (It's not clear if Silverlight will be bundled or just offered as a download.) Silverlight is a web app graphics and interface layer, intended to displace Adobe Flash.
The announcement was shocking for several reasons:
--Up until now, Nokia and Adobe had worked together closely. Nokia is one of the few companies paying to bundle Flash on its phones, and Nokia had featured Adobe prominently at some of its developer events in Silicon Valley. So the announcement I was expecting was that Nokia would bundle Air, the next evolution of Flash, rather than its competitor.
--Nokia has generally treated Microsoft as the spawn of the devil. The whole Symbian OS consortium was designed primarily as a way to prevent Microsoft from getting a controlling role in mobile software. Now Nokia gives Microsoft's software layer a huge boost?
--Although Microsoft had hinted vaguely about taking Silverlight mobile, it had given no definite plans at all. So this is a huge step forward for Silverlight.
--Just a few weeks ago, Nokia bought TrollTech and announced that its software was going to unify development across Series 40 and S60. Now Nokia endorses Silverlight, which will also run across Series 40 and S60. Which one are developers supposed to focus on?
What in the world is going on?
I don't know. Nobody from Nokia has explained it to me, so I have to read between the lines. Nokia says in the press release: "Nokia aims to support market leading and content rich internet application environments and to embrace and encourage open innovation. By working with Microsoft, we are creating terrific opportunities and additional choices for the development community." Okay, so I guess what they're saying is that they want to support every platform and development option out there. Presumably the benefit to them is that they can claim their phones support more software than anyone else.
I doubt that's the only motivation, though. By supporting numerous platforms, Nokia reduces the possibility that any one of them can dominate the market and push around Nokia. It also lets Nokia play the sides off against one another. I'm sure the threat of embracing Air made Microsoft give Nokia a very good deal on Silverlight, and no doubt Nokia will now use its Microsoft relationship to get business concessions from Adobe (assuming that Nokia still plans to work with Adobe at all; that's not entirely clear).
Anyway, I can sort of see how this all works for Nokia strategically, although it feels like Nokia is trying too hard to be clever. I'm not as clear on the benefits of all this for mobile developers and users. As was covered in last week's post on mobile apps (link), many developers view the proliferation of platforms as a problem, not a benefit. Microsoft itself said in the Nokia press release:
"We want to make sure developers and designers don't have to constantly recreate the wheel and build different versions of applications and services for multiple operating systems, browsers and platforms."
That's a pretty danged funny quote coming from a company that now offers at least four mobile platforms (two versions of Windows Mobile, Silverlight, Tablet PC, and does .Net CF count as a fifth?), in a press release from a company that apparently wants to support every platform available. If you really think platform confusion is a problem, guys, look in a mirror.
For users, the benefit of all this deal-making is unclear. We're stumbling into a world where you'll need to know details of which platforms are loaded on a particular phone in order to know which apps it can run. I can't think of a better way to discourage use of mobile applications.
dimanche 24 février 2008
Mobile applications, RIP
Summary: The business of making native apps for mobile devices is dying, crushed by a fragmented market and restrictive business practices. The problems are so bad that the mobile web, despite its many technical drawbacks, is now a better way to deliver new functionality to mobiles. I think this will drive a rapid rise in mobile web development, largely replacing the mobile app business. This has huge implications for mobile operators, handset companies, developers, and users.
The decline of the mobile software industry
Mobile computing is different from PC computing.
For the last decade, that has been the fundamental rule of the mobile data industry. It was the central insight of Palm Computing's "Zen of Palm" philosophy. Psion came up with similar ideas, and you can hear echoes of them from every other successful mobile computing firm: Mobile computers are used differently from PCs, and therefore must be designed differently.
We all assumed this also meant mobile devices needed a whole mobile-specific software stack, including an operating system and APIs designed specifically for mobility, and native third-party applications created from the ground up for mobile usage.
That's what we all believe, but I'm starting to think we got it wrong.
Back in 1999 when I joined Palm, it seemed we had the whole mobile ecosystem nailed. The market was literally exploding, with the installed base of devices doubling every year, and an incredible range of creative and useful software popping up all over. In a 22-month period, the number of registered Palm developers increased from 3,000 to over 130,000. The PalmSource conference was swamped, with people spilling out into the halls, and David Pogue took center stage at the close of the conference to tell us how brilliant we all were.
It felt like we were at the leading edge of a revolution, but in hindsight it was more like the high water mark of a flash flood. In the years that followed, the energy and momentum gradually drained out of the mobile applications market.
The problem wasn't just limited to Palm; the level of developer activity and creativity that we saw in the glory days of Palm OS hasn't reappeared on any mobile platform since. In fact, as the market shifted from handhelds to smartphones, the situation for mobile app developers has become substantially worse.
That came home to me very forcefully a few days ago, when I got a call from Elia Freedman. Elia is CEO of Infinity Softworks, which makes vertical market software for mobile devices (tasks like real estate valuation and financial services). He was one of the leaders of the Palm software market, with a ten year history in mobile applications.
I eventually moved on from Palm, and Elia branched out into other platforms such as Blackberry. But we've kept in touch, and so he called recently to tell me that he had given up on his mobile applications business.
Elia gave me a long explanation of why. I can't reproduce it word for word (I couldn't write that fast), but I've summarized it with his permission here:
You can read more of Elia's commentary on his weblog (link).
Add it all up, and Elia can't make money in mobile applications any more. As he told me, "Mike, it's time for you to write the obituary for mobile apps." More on that later.
Although it's a very sad situation, if Elia's experience were an isolated story I'd probably just chalk it up to bad luck on the part of a single developer. But it mirrors what I've been hearing from a lot of mobile app developers on a lot of different operating systems for some time now. The combination of splintering platforms, shrinking distribution channels, and rising costs is making it harder and harder for a mobile application developer to succeed. Rather than getting better, the situation is getting worse.
I've always had faith that eventually we would solve these problems. We'd get the right OS vendor paired with a handset maker who understood the situation and an operator who was willing to give up some control, and a mobile platform would take off again. Maybe not Palm OS, but on somebody's platform we'd get it all right.
I don't believe that any more. I think it's too late.
The mistake we made
We told ourselves that the fundamental rule of our business was: Mobile is different. But we lost sight of an even more fundamental law that applies to any computing platform:
A platform that is technically flawed but has a good business model will always beat a platform that is elegant but has a poor business model.
Windows is the best example of inelegant tech paired with the right business model, but it has happened over and over again in the history of the tech world.
In the mobile world, what have we done? We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen.
But we never figured out how to help developers make money. In fact, we paired our elegant platforms with a developer business model so deeply broken that it would take many years, and enormous political battles throughout the industry, to fix it -- if it can ever be fixed at all.
Meanwhile, there is now an alternative platform for mobile developers. It's horribly flawed technically, not at all optimized for mobile usage, and in fact was designed for a completely different form of computing. It would be hard to create a computing architecture more inappropriate for use over a cellular data network. But it has a business model that sweeps away all of the barriers in the mobile market. Mobile developers are starting to switch to it, a trickle that is soon going to grow. And this time I think the flash flood will last.
If you haven't figured it out yet, I'm talking about the Web. I think Web applications are going to destroy most native app development for mobiles. Not because the Web is a better technology for mobile, but because it has a better business model.
Think about it: If you're creating a website, you don't have to get permission from a carrier. You don't have to get anything certified by anyone. You don't have to beg for placement on the deck, and you don't have to pay half your revenue to a reseller. In fact, the operator, handset vendor, and OS vendor probably won't even be aware that you exist. It'll just be you and the user, communicating directly.
Until recently, a couple of barriers prevented this from working. The first was the absence of flat-rate data plans. They have been around for a while in the US, but in Europe they are only now appearing. Before flat-rate, users were very fearful of exploring the mobile web because they risked ending up with a thousand-Euro mobile bill. That fear is now receding. The second barrier was the extremely bad quality of mobile browsers. Many of them still stink, but the high quality of Apple's iPhone browser, coupled with Nokia's licensing of WebKit, points to a future in which most mobile browsers will be reasonably feature-complete. The market will force this -- mobile companies how have to ship a full browser in order to keep up with Apple, and operators have to give full access to it.
There are still huge problems with web apps on mobile, of course. Mobile web apps don't work when you're out of coverage, they're slow due to network latency, and they do not make efficient use of the wireless network. But I believe it will be easier to resolve or live with these technical drawbacks in the next few years than it will be to fix the fundamental structural and business problems in the native mobile app market.
In other words, app development on the mobile web sucks less than the alternative.
Here's a chart to help explain the situation. Imagine that we're giving a numerical score to a platform, rating its attractiveness to developers. Attractiveness is defined as the technical elegance of the platform multiplied by how easy it is for developers to make money from it. The attractiveness score for native mobile app development looks like this over time:
This is why mobile app developers are in trouble. Even though the base of smartphones has been growing, and the platforms themselves have become more powerful, the market barriers have been growing even faster. So attractiveness has been dropping.
Now add in mobile web development:
Based on what I'm hearing from mobile developers, the lines just crossed. The business advantages of mobile web development outweigh its technical limitations. More importantly, if you look at where the lines are going, the advantage of mobile web is going to grow rapidly in the future.
I'm not saying all native mobile development is dead. In fact, we're about to see the release of Apple's native development tools for the iPhone, and as Chris Dunphy just pointed out to me, they are sure to result in a surge of native development for that platform. But I think even a rapidly-growing base of iPhones can't compare to the weight of the whole mobile phone market getting onto a consistent base of browsers.
What it all means
If you're a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website. That's what Elia did, and he said it's amazing how much easier it is to get things done. Even mobile game developers, who you'd think would be the last to abandon native development, are looking at web distribution (link; thanks to Mike Rowehl for pointing it out).
See if you can create a dumbed-down version of your application that will run over the mobile web. If the answer is yes, do it. If the answer is no, try to figure out what technology changes would let you move to the web, and watch for those changes to happen.
There are exceptions to any rule, and I think it makes sense to keep doing native development if your app can't work effectively over the web, and it's a vertical application so popular that you can get about $50 or more in revenue per copy. In that situation, you probably have enough resources to stay native for the time being. But even you should be monitoring the situation to see when you can switch to the web, because it will cut your expenses.
If you're a mobile customer, make sure your next smartphone has a fully functional browser that can display standard web pages. And get the best deal you can on a flat-rate data plan; you'll need it.
If you're an operator or a handset vendor, get used to life as a dumb pipe. By trying to control your customers and make sure you extract most of the revenue from mobile data, all you've done is drive developers to the Web, which is even harder to control. You could have had a middle ground in which you and mobile developers worked together to share the profits, but instead you've handed the game to the Google crowd.
Congratulations.
Oh, about that obituary...
In loving memory of the mobile applications business. Adoring child of Java, Psion, Palm OS and Windows Mobile; doting parent of Symbian, Access Linux Platform, and S60; constant companion of Handango and Motricity. Scared the crap out of Microsoft in 2000. Passed away from strangulation at the hands of the mobile industry in 2008. Awaiting resurrection as a web service in 2009. In lieu of flowers, the family asks that you make a donation to the Yahoo takeover defense fund.
The decline of the mobile software industry
Mobile computing is different from PC computing.
For the last decade, that has been the fundamental rule of the mobile data industry. It was the central insight of Palm Computing's "Zen of Palm" philosophy. Psion came up with similar ideas, and you can hear echoes of them from every other successful mobile computing firm: Mobile computers are used differently from PCs, and therefore must be designed differently.
We all assumed this also meant mobile devices needed a whole mobile-specific software stack, including an operating system and APIs designed specifically for mobility, and native third-party applications created from the ground up for mobile usage.
That's what we all believe, but I'm starting to think we got it wrong.
Back in 1999 when I joined Palm, it seemed we had the whole mobile ecosystem nailed. The market was literally exploding, with the installed base of devices doubling every year, and an incredible range of creative and useful software popping up all over. In a 22-month period, the number of registered Palm developers increased from 3,000 to over 130,000. The PalmSource conference was swamped, with people spilling out into the halls, and David Pogue took center stage at the close of the conference to tell us how brilliant we all were.
It felt like we were at the leading edge of a revolution, but in hindsight it was more like the high water mark of a flash flood. In the years that followed, the energy and momentum gradually drained out of the mobile applications market.
The problem wasn't just limited to Palm; the level of developer activity and creativity that we saw in the glory days of Palm OS hasn't reappeared on any mobile platform since. In fact, as the market shifted from handhelds to smartphones, the situation for mobile app developers has become substantially worse.
That came home to me very forcefully a few days ago, when I got a call from Elia Freedman. Elia is CEO of Infinity Softworks, which makes vertical market software for mobile devices (tasks like real estate valuation and financial services). He was one of the leaders of the Palm software market, with a ten year history in mobile applications.
I eventually moved on from Palm, and Elia branched out into other platforms such as Blackberry. But we've kept in touch, and so he called recently to tell me that he had given up on his mobile applications business.
Elia gave me a long explanation of why. I can't reproduce it word for word (I couldn't write that fast), but I've summarized it with his permission here:
Two problems have caused a decline the mobile apps business over the last few years. First, the business has become tougher technologically. Second, marketing and sales have also become harder.
From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several -- two versions of Windows Mobile, Tablet PC, and so on. [Elia didn't mention it, but the fragmentation of Java makes this situation even worse.]
I call it three million platforms with a hundred users each (link).
The second technical issue is certification. The walls are being formed around devices in ways they never were before. Now I have to certify with both the OS and with each carrier, and it costs me thousands of dollars. So my costs are through the roof. On top of that, the adoption rate of mobile applications has gone down. So I have to pay more to sell less.
Then there's marketing. Here too there are two issues. The first is vertical marketing. Few mobile devices align with verticals, which makes it hard for a vertical application developer like us to partner with any particular device. For example, Palm even at its height had no more than 20% of real estate agents. To cover our development costs on 20% of target customer base, I had to charge more than the customers could pay. So I was forced to make my application work on more platforms, which pushed me back into the million platforms problem.
The other marketing problem is the disappearance of horizontal distribution. You used to have some resellers and free software sites on the web that promoted mobile shareware and commercial products at low or no charge. You could also work through the hardware vendors to get to customers. We were masters of this; at one point we were bundled on 85% of mobile computing devices. We had retail distribution too.
None of those avenues are available any more. Retail has gone away. The online resellers have gone from taking 20% of our revenue to taking 50-70%. The other day I went looking for the freeware sites where we used to promote, and they have disappeared. Hardware bundling has ended because carriers took that over and made it impossible for us to get on the device. Palm used to have a bonus CD and a flyer that they put in the box, where we could get promoted. The carriers shut down both of those. They do not care about vertical apps. It feels like they don't want any apps at all.
You can read more of Elia's commentary on his weblog (link).
Add it all up, and Elia can't make money in mobile applications any more. As he told me, "Mike, it's time for you to write the obituary for mobile apps." More on that later.
Although it's a very sad situation, if Elia's experience were an isolated story I'd probably just chalk it up to bad luck on the part of a single developer. But it mirrors what I've been hearing from a lot of mobile app developers on a lot of different operating systems for some time now. The combination of splintering platforms, shrinking distribution channels, and rising costs is making it harder and harder for a mobile application developer to succeed. Rather than getting better, the situation is getting worse.
I've always had faith that eventually we would solve these problems. We'd get the right OS vendor paired with a handset maker who understood the situation and an operator who was willing to give up some control, and a mobile platform would take off again. Maybe not Palm OS, but on somebody's platform we'd get it all right.
I don't believe that any more. I think it's too late.
The mistake we made
We told ourselves that the fundamental rule of our business was: Mobile is different. But we lost sight of an even more fundamental law that applies to any computing platform:
A platform that is technically flawed but has a good business model will always beat a platform that is elegant but has a poor business model.
Windows is the best example of inelegant tech paired with the right business model, but it has happened over and over again in the history of the tech world.
In the mobile world, what have we done? We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen.
But we never figured out how to help developers make money. In fact, we paired our elegant platforms with a developer business model so deeply broken that it would take many years, and enormous political battles throughout the industry, to fix it -- if it can ever be fixed at all.
Meanwhile, there is now an alternative platform for mobile developers. It's horribly flawed technically, not at all optimized for mobile usage, and in fact was designed for a completely different form of computing. It would be hard to create a computing architecture more inappropriate for use over a cellular data network. But it has a business model that sweeps away all of the barriers in the mobile market. Mobile developers are starting to switch to it, a trickle that is soon going to grow. And this time I think the flash flood will last.
If you haven't figured it out yet, I'm talking about the Web. I think Web applications are going to destroy most native app development for mobiles. Not because the Web is a better technology for mobile, but because it has a better business model.
Think about it: If you're creating a website, you don't have to get permission from a carrier. You don't have to get anything certified by anyone. You don't have to beg for placement on the deck, and you don't have to pay half your revenue to a reseller. In fact, the operator, handset vendor, and OS vendor probably won't even be aware that you exist. It'll just be you and the user, communicating directly.
Until recently, a couple of barriers prevented this from working. The first was the absence of flat-rate data plans. They have been around for a while in the US, but in Europe they are only now appearing. Before flat-rate, users were very fearful of exploring the mobile web because they risked ending up with a thousand-Euro mobile bill. That fear is now receding. The second barrier was the extremely bad quality of mobile browsers. Many of them still stink, but the high quality of Apple's iPhone browser, coupled with Nokia's licensing of WebKit, points to a future in which most mobile browsers will be reasonably feature-complete. The market will force this -- mobile companies how have to ship a full browser in order to keep up with Apple, and operators have to give full access to it.
There are still huge problems with web apps on mobile, of course. Mobile web apps don't work when you're out of coverage, they're slow due to network latency, and they do not make efficient use of the wireless network. But I believe it will be easier to resolve or live with these technical drawbacks in the next few years than it will be to fix the fundamental structural and business problems in the native mobile app market.
In other words, app development on the mobile web sucks less than the alternative.
Here's a chart to help explain the situation. Imagine that we're giving a numerical score to a platform, rating its attractiveness to developers. Attractiveness is defined as the technical elegance of the platform multiplied by how easy it is for developers to make money from it. The attractiveness score for native mobile app development looks like this over time:
This is why mobile app developers are in trouble. Even though the base of smartphones has been growing, and the platforms themselves have become more powerful, the market barriers have been growing even faster. So attractiveness has been dropping.
Now add in mobile web development:
Based on what I'm hearing from mobile developers, the lines just crossed. The business advantages of mobile web development outweigh its technical limitations. More importantly, if you look at where the lines are going, the advantage of mobile web is going to grow rapidly in the future.
I'm not saying all native mobile development is dead. In fact, we're about to see the release of Apple's native development tools for the iPhone, and as Chris Dunphy just pointed out to me, they are sure to result in a surge of native development for that platform. But I think even a rapidly-growing base of iPhones can't compare to the weight of the whole mobile phone market getting onto a consistent base of browsers.
What it all means
If you're a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website. That's what Elia did, and he said it's amazing how much easier it is to get things done. Even mobile game developers, who you'd think would be the last to abandon native development, are looking at web distribution (link; thanks to Mike Rowehl for pointing it out).
See if you can create a dumbed-down version of your application that will run over the mobile web. If the answer is yes, do it. If the answer is no, try to figure out what technology changes would let you move to the web, and watch for those changes to happen.
There are exceptions to any rule, and I think it makes sense to keep doing native development if your app can't work effectively over the web, and it's a vertical application so popular that you can get about $50 or more in revenue per copy. In that situation, you probably have enough resources to stay native for the time being. But even you should be monitoring the situation to see when you can switch to the web, because it will cut your expenses.
If you're a mobile customer, make sure your next smartphone has a fully functional browser that can display standard web pages. And get the best deal you can on a flat-rate data plan; you'll need it.
If you're an operator or a handset vendor, get used to life as a dumb pipe. By trying to control your customers and make sure you extract most of the revenue from mobile data, all you've done is drive developers to the Web, which is even harder to control. You could have had a middle ground in which you and mobile developers worked together to share the profits, but instead you've handed the game to the Google crowd.
Congratulations.
Oh, about that obituary...
In loving memory of the mobile applications business. Adoring child of Java, Psion, Palm OS and Windows Mobile; doting parent of Symbian, Access Linux Platform, and S60; constant companion of Handango and Motricity. Scared the crap out of Microsoft in 2000. Passed away from strangulation at the hands of the mobile industry in 2008. Awaiting resurrection as a web service in 2009. In lieu of flowers, the family asks that you make a donation to the Yahoo takeover defense fund.
lundi 5 novembre 2007
Google, the OS company
The bottom line: Google is now an OS company.
The fact that Google's recently-announced OS products are aimed at mobile devices and social networking sites is interesting, and I'll talk about the impact of that below. But it's secondary. I think the big, really important change is that Google has now jumped with both feet into the middle of the operating system world. That potentially has huge implications for the industry.
The impact will depend a lot on how Google follows up. If it pours substantial energy and resources into its OS offerings, it will be extremely bad news for Microsoft and other companies trying to charge money for their own platforms. On the other hand, if Google doesn't make a serious long-term commitment, it will embarrass itself deeply. This isn't like launching a new web application -- an OS has to be complete, and it has to work properly in version 1, or there won't be a version 2.
What they announced
It's kind of ironic. For years after Google became a prominent web company, people speculated about whether or when it would create its own OS. The logic was that Microsoft has its own OS, and Google was challenging Microsoft, so Google would create its own OS too. But then as the years went by and it didn't happen, people moved on to other subjects. The speculation died out. But one of my rules about the tech industry is that "obvious" things happen only after everyone in the industry has written them off. So I guess Google was due.
The company has been creeping toward the OS space for a while. Google Gadgets is an API to create small applications that run in web pages, and Google Gears is code that lets web apps run offline, making it easier for them to challenge desktop applications. But they were both relatively low-profile (or as low profile as anything Google ever does). But in the last couple of weeks, Google made two much more assertive announcements:
--OpenSocial is an effort to create a shared platform for applications that can be embedded within social websites (link).
--The Open Handset Alliance is an effort to create a shared platform powering mobile devices (link).
Although they're aimed at very different parts of the industry, they're both efforts to create a standard platform where there was fragmentation; and they're both alliances of numerous companies, with Google providing most of the code and the marketing glue. I think there's a recurring theme here.
Details on the Open Handset Alliance
Open Social was covered very heavily when it was announced a couple of weeks ago, so I won't recap it all here. If you want more details, Marc Andreessen did an enthusiastic commentary about it on his weblog (link).
The OHA announcement was today, and I want to call out some highlights:
--It's built around a Linux implementation called Android. Android will be free of charge and open source, licensed under terms that allow companies to use it in products without contributing back any of their own code to the public. This will probably annoy a lot of open source fans, but it's important for adoption of the OS, as many companies thinking about working with Linux worry that they will accidentally obligate themselves to give away their own source code.
--Google is creating a suite of applications that will be bundled with Android, but they can be replaced freely by companies that want to bundle other apps, according to Michael Gartenberg (link). There is a lot of speculation, though, that if you bundle the Google apps you'll get a subsidy from Google. The folks over at Skydeck estimate the subsidy could be about $50 per device (link). That might not sound like huge money to you and me, but keep in mind that mobile phone companies routinely turn backflips to squeeze 25 cents out of the cost of a phone. When you sell millions of phones a year, it adds up.
--A huge list of companies participated in the announcement. That's not as impressive as it sounds; when you have a well-known brand, a lot of companies will do a joint press release with you just for the publicity value. But a few stood out:
Hardware vendors. Samsung, Motorola, LG, and HTC all endorsed the OS. HTC and LG gave particularly enthusiastic quotes. The first three companies have all been playing with Linux for some time, so I wasn't surprised. But HTC is another matter -- it is the most innovative Windows Mobile licensee, and Microsoft must be very disturbed to see it blowing kisses at Google.
(A side comment on Motorola: For a company that said it wanted to consolidate down on a small number of platforms, Motorola is behaving strangely -- it jumped all over Symbian a couple of weeks ago, and now is supporting Android as well. I think it has now endorsed more mobile operating systems than any other handset vendor.)
Operators. Participants in the announcement included NTT DoCoMo (a long-time Linux lover), KDDI, China Mobile, T-Mobile, Telecom Italia, Telefonica, and Sprint. That's a very nice geographic spread, and ensures enough operator interest to make the handset vendors invest.
--Google claims all Android applications will have the same level of access to data on the phone. That's pretty interesting -- most smartphone platforms have been moving toward a multiple-level approach in which you need more rigorous security certification in order to access some features of the phone. I'll be interested to see how the security model on Android works.
--We'll get technical information on the OS November 12, and the first phones based on Android should ship in the second half of 2008.
--Although Android's first focus is mobile phones, the New York Times reports that it can be used in other consumer devices as well (link).
What it means to the mobile industry
It all depends on the quality of Google's work and the depth of its commitment. If Android has technical or performance problems, it could sink like a stone. If it doesn't have enough drivers or has poor technical support, the handset vendors will avoid it. If the developers can't create good applications, users won't want it. This is a very different business for Google -- handset vendors and operators will not tolerate the sloppy, indifferent technical support that Google provides for its consumer web apps.
If, on the other hand, Google's platform really works and the company invests in it, I think it could have some very important impacts.
Impact on Windows Mobile: Ugliness. The handset companies endorsing Android are also Microsoft's most prominent mobile licensees. I doubt any of them are planning to completely abandon Microsoft (they don't want to be captive to any single OS vendor), but any effort they put into Android is effort that doesn't go into Windows Mobile. So this is ominous.
The whole mobile thing just hasn't worked out the way Microsoft planned. First it couldn't get the big handset brands to license its software, so it focused on signing phone clone vendors in Asia, thinking it could use them to pull down the big guys. But Nokia and the other big brands used their volume and manufacturing skill to beat the daylights out of the small cloners.
Now Google is coming after the market with an OS that's completely free, and may even be subsidized. This will put huge financial pressure on not just Windows Mobile, but all of Windows CE. Even if Microsoft can hold share, its prospects of ever making good money in the sub-PC space look increasingly remote.
Impact on Access: Ugly ugliness. How do you sell your own version of Linux when the world's biggest Internet company is giving one away? I don't know.
Impact on Symbian: Hard to judge. Symbian is the preferred OS of Nokia. As long as Nokia continues to use Symbian, it stays in business. The question is how much it'll grow. After years of painful effort, Symbian just managed to get increased endorsements from Motorola and Samsung. Now Google is messing with both of them. Japan has been a very important growth market for Symbian, now Android is endorsed by both DoCoMo and KDDI. All of that must feel very uncomfortable. If nothing else, it's likely to produce pressure on Symbian to lower its prices. And Symbian should be asking what happens if Android turns out to be everything Google promises -- a free OS that lets handset vendors create great phones easily. It's not fun competing against a free product that's been subsidized by one of the richest companies in the world (just ask Netscape).
Maybe if Symbian agrees to enable Google services on its platform it can get the same subsidies as Android does. It's worth asking. If not, maybe Symbian should be looking for other places where it can add value in the mobile ecosystem.
Impact on mobile developers: Potentially great. Mobile developers have suffered terribly from two things: They have to work through operators to get their applications to market, and they have to rewrite their applications dozens of times for different phones. If Android produces a single consistent Java environment for mobile applications, that would be a big win. And if it can open up the distribution channels for mobile apps, that would be great as well. We don't have enough details to judge either outcome yet, and the app distribution one depends on business arrangements that may be outside Google's control.
Impact on Apple, RIM, and Palm: Probably none at all. A lot of the coverage of Android is positioning it as some sort of challenger to iPhone and RIM.
I don't buy it.
Apple, RIM, and Palm all make integrated systems in which the software and hardware are coordinated together to solve a user problem. Android, by contrast, is only an operating system. It's plumbing, not the whole house. Unless Google's handset licensees magically develop the ability to design for users -- a feat equivalent to a giraffe sprouting wings -- their products won't be any better as systems solutions than they are today. The OS hasn't been the thing holding them back, and changing OS won't alter the situation.
Android puts interesting financial pressure on Microsoft, but it doesn't directly solve any compelling user problems. If it eventually drives a great base of mobile applications, that might eventually be attractive to some users. But in that case the systems vendors could just add a copy of Google's application runtime (it's open source, they can grab it anytime they want). Or they could host their devices on Google's plumbing. Palm and RIM might both benefit if they could transfer engineers away from core OS and toward adding value that's visible to users.
Impact on the tech industry: This isn't just about mobile phones
I have no access to Google's internal thinking, but even if it sincerely believes it's only doing a mobile phone OS, I don't think it can or will stop there. Technology products often develop a momentum of their own, no matter what was intended at the start. The lines between the computing and mobile worlds are breaking down already, and if Google creates an attractive software platform that's free of charge, that platform will inevitably get sucked into other types of devices. I'm not saying that Android is going to end up in PCs, but if it's functional and well supported I think it could end up running on just about everything else that has a screen.
Besides, if you look across all of the recent Google announcements, I think it's clear that Google has a larger agenda: It wants to break down walled gardens, because they interfere with Google's ability to deliver its services. It has even developed a standard methodology for attacking them: Create a consortium so you don't look like a bully, and fund an "open" alternative to whatever is in the way. They are doing it to Facebook, and they're doing it to Windows Mobile. Google doesn't even have to make money from the consortium, as long as it clears the ground for its services to grow.
Take a lesson from evolutionary history. The most successful animals are not those that adapt to the environment; they are the ones that reshape the environment to match their needs. I think that's what Google is doing. It's going to use open source and alliances to suck the profitability out of anybody who creates a proprietary island that it can't target.
It'll be interesting to see if and how Google applies this principle to the upcoming frequency auction in the US.
Or to anyone else who gets in its way.
The fact that Google's recently-announced OS products are aimed at mobile devices and social networking sites is interesting, and I'll talk about the impact of that below. But it's secondary. I think the big, really important change is that Google has now jumped with both feet into the middle of the operating system world. That potentially has huge implications for the industry.
The impact will depend a lot on how Google follows up. If it pours substantial energy and resources into its OS offerings, it will be extremely bad news for Microsoft and other companies trying to charge money for their own platforms. On the other hand, if Google doesn't make a serious long-term commitment, it will embarrass itself deeply. This isn't like launching a new web application -- an OS has to be complete, and it has to work properly in version 1, or there won't be a version 2.
What they announced
It's kind of ironic. For years after Google became a prominent web company, people speculated about whether or when it would create its own OS. The logic was that Microsoft has its own OS, and Google was challenging Microsoft, so Google would create its own OS too. But then as the years went by and it didn't happen, people moved on to other subjects. The speculation died out. But one of my rules about the tech industry is that "obvious" things happen only after everyone in the industry has written them off. So I guess Google was due.
The company has been creeping toward the OS space for a while. Google Gadgets is an API to create small applications that run in web pages, and Google Gears is code that lets web apps run offline, making it easier for them to challenge desktop applications. But they were both relatively low-profile (or as low profile as anything Google ever does). But in the last couple of weeks, Google made two much more assertive announcements:
--OpenSocial is an effort to create a shared platform for applications that can be embedded within social websites (link).
--The Open Handset Alliance is an effort to create a shared platform powering mobile devices (link).
Although they're aimed at very different parts of the industry, they're both efforts to create a standard platform where there was fragmentation; and they're both alliances of numerous companies, with Google providing most of the code and the marketing glue. I think there's a recurring theme here.
Details on the Open Handset Alliance
Open Social was covered very heavily when it was announced a couple of weeks ago, so I won't recap it all here. If you want more details, Marc Andreessen did an enthusiastic commentary about it on his weblog (link).
The OHA announcement was today, and I want to call out some highlights:
--It's built around a Linux implementation called Android. Android will be free of charge and open source, licensed under terms that allow companies to use it in products without contributing back any of their own code to the public. This will probably annoy a lot of open source fans, but it's important for adoption of the OS, as many companies thinking about working with Linux worry that they will accidentally obligate themselves to give away their own source code.
--Google is creating a suite of applications that will be bundled with Android, but they can be replaced freely by companies that want to bundle other apps, according to Michael Gartenberg (link). There is a lot of speculation, though, that if you bundle the Google apps you'll get a subsidy from Google. The folks over at Skydeck estimate the subsidy could be about $50 per device (link). That might not sound like huge money to you and me, but keep in mind that mobile phone companies routinely turn backflips to squeeze 25 cents out of the cost of a phone. When you sell millions of phones a year, it adds up.
--A huge list of companies participated in the announcement. That's not as impressive as it sounds; when you have a well-known brand, a lot of companies will do a joint press release with you just for the publicity value. But a few stood out:
Hardware vendors. Samsung, Motorola, LG, and HTC all endorsed the OS. HTC and LG gave particularly enthusiastic quotes. The first three companies have all been playing with Linux for some time, so I wasn't surprised. But HTC is another matter -- it is the most innovative Windows Mobile licensee, and Microsoft must be very disturbed to see it blowing kisses at Google.
(A side comment on Motorola: For a company that said it wanted to consolidate down on a small number of platforms, Motorola is behaving strangely -- it jumped all over Symbian a couple of weeks ago, and now is supporting Android as well. I think it has now endorsed more mobile operating systems than any other handset vendor.)
Operators. Participants in the announcement included NTT DoCoMo (a long-time Linux lover), KDDI, China Mobile, T-Mobile, Telecom Italia, Telefonica, and Sprint. That's a very nice geographic spread, and ensures enough operator interest to make the handset vendors invest.
--Google claims all Android applications will have the same level of access to data on the phone. That's pretty interesting -- most smartphone platforms have been moving toward a multiple-level approach in which you need more rigorous security certification in order to access some features of the phone. I'll be interested to see how the security model on Android works.
--We'll get technical information on the OS November 12, and the first phones based on Android should ship in the second half of 2008.
--Although Android's first focus is mobile phones, the New York Times reports that it can be used in other consumer devices as well (link).
What it means to the mobile industry
It all depends on the quality of Google's work and the depth of its commitment. If Android has technical or performance problems, it could sink like a stone. If it doesn't have enough drivers or has poor technical support, the handset vendors will avoid it. If the developers can't create good applications, users won't want it. This is a very different business for Google -- handset vendors and operators will not tolerate the sloppy, indifferent technical support that Google provides for its consumer web apps.
If, on the other hand, Google's platform really works and the company invests in it, I think it could have some very important impacts.
Impact on Windows Mobile: Ugliness. The handset companies endorsing Android are also Microsoft's most prominent mobile licensees. I doubt any of them are planning to completely abandon Microsoft (they don't want to be captive to any single OS vendor), but any effort they put into Android is effort that doesn't go into Windows Mobile. So this is ominous.
The whole mobile thing just hasn't worked out the way Microsoft planned. First it couldn't get the big handset brands to license its software, so it focused on signing phone clone vendors in Asia, thinking it could use them to pull down the big guys. But Nokia and the other big brands used their volume and manufacturing skill to beat the daylights out of the small cloners.
Now Google is coming after the market with an OS that's completely free, and may even be subsidized. This will put huge financial pressure on not just Windows Mobile, but all of Windows CE. Even if Microsoft can hold share, its prospects of ever making good money in the sub-PC space look increasingly remote.
Impact on Access: Ugly ugliness. How do you sell your own version of Linux when the world's biggest Internet company is giving one away? I don't know.
Impact on Symbian: Hard to judge. Symbian is the preferred OS of Nokia. As long as Nokia continues to use Symbian, it stays in business. The question is how much it'll grow. After years of painful effort, Symbian just managed to get increased endorsements from Motorola and Samsung. Now Google is messing with both of them. Japan has been a very important growth market for Symbian, now Android is endorsed by both DoCoMo and KDDI. All of that must feel very uncomfortable. If nothing else, it's likely to produce pressure on Symbian to lower its prices. And Symbian should be asking what happens if Android turns out to be everything Google promises -- a free OS that lets handset vendors create great phones easily. It's not fun competing against a free product that's been subsidized by one of the richest companies in the world (just ask Netscape).
Maybe if Symbian agrees to enable Google services on its platform it can get the same subsidies as Android does. It's worth asking. If not, maybe Symbian should be looking for other places where it can add value in the mobile ecosystem.
Impact on mobile developers: Potentially great. Mobile developers have suffered terribly from two things: They have to work through operators to get their applications to market, and they have to rewrite their applications dozens of times for different phones. If Android produces a single consistent Java environment for mobile applications, that would be a big win. And if it can open up the distribution channels for mobile apps, that would be great as well. We don't have enough details to judge either outcome yet, and the app distribution one depends on business arrangements that may be outside Google's control.
Impact on Apple, RIM, and Palm: Probably none at all. A lot of the coverage of Android is positioning it as some sort of challenger to iPhone and RIM.
I don't buy it.
Apple, RIM, and Palm all make integrated systems in which the software and hardware are coordinated together to solve a user problem. Android, by contrast, is only an operating system. It's plumbing, not the whole house. Unless Google's handset licensees magically develop the ability to design for users -- a feat equivalent to a giraffe sprouting wings -- their products won't be any better as systems solutions than they are today. The OS hasn't been the thing holding them back, and changing OS won't alter the situation.
Android puts interesting financial pressure on Microsoft, but it doesn't directly solve any compelling user problems. If it eventually drives a great base of mobile applications, that might eventually be attractive to some users. But in that case the systems vendors could just add a copy of Google's application runtime (it's open source, they can grab it anytime they want). Or they could host their devices on Google's plumbing. Palm and RIM might both benefit if they could transfer engineers away from core OS and toward adding value that's visible to users.
Impact on the tech industry: This isn't just about mobile phones
I have no access to Google's internal thinking, but even if it sincerely believes it's only doing a mobile phone OS, I don't think it can or will stop there. Technology products often develop a momentum of their own, no matter what was intended at the start. The lines between the computing and mobile worlds are breaking down already, and if Google creates an attractive software platform that's free of charge, that platform will inevitably get sucked into other types of devices. I'm not saying that Android is going to end up in PCs, but if it's functional and well supported I think it could end up running on just about everything else that has a screen.
Besides, if you look across all of the recent Google announcements, I think it's clear that Google has a larger agenda: It wants to break down walled gardens, because they interfere with Google's ability to deliver its services. It has even developed a standard methodology for attacking them: Create a consortium so you don't look like a bully, and fund an "open" alternative to whatever is in the way. They are doing it to Facebook, and they're doing it to Windows Mobile. Google doesn't even have to make money from the consortium, as long as it clears the ground for its services to grow.
Take a lesson from evolutionary history. The most successful animals are not those that adapt to the environment; they are the ones that reshape the environment to match their needs. I think that's what Google is doing. It's going to use open source and alliances to suck the profitability out of anybody who creates a proprietary island that it can't target.
It'll be interesting to see if and how Google applies this principle to the upcoming frequency auction in the US.
Or to anyone else who gets in its way.
mercredi 4 juillet 2007
Why is Apple porting its browser to Windows? To take over the world, of course.
There are so many interesting things going on in the industry that it's frustrating, because I don't have time to write about them all.
Jerry Yang is now in charge at Yahoo, which in my opinion means a lot because a founder is often much more willing to revisit old assumptions and make radical changes than is someone who came in after the fact. (I know the stereotype is that founders resist change, but I've found that the exact opposite is often true, especially if the founder is moving up after spending time lower in the management chain.)
Google bought Grand Central, which underlines their interest in providing client software for mobile phones. It's a significant change for Google because up to now they have focused mostly on providing mobile versions of their existing web apps, like Maps. Grand Central is different; it's a call management system that embeds Google deeply in the life of a mobile user. It implies a much tighter relationship between Google and the user than most other Google products, and it's not something that you can easily monetize through advertising -- which makes me wonder whether Google is planning to run it standalone or integrate it into something bigger.
But the strangest recent development was Apple's decision to port its Safari web browser to Windows.
It is not easy to port a browser to a new platform. There's a huge amount of programming involved -- to do the actual port, to debug it, and to maintain and upgrade the code as people identify small incompatibilities and ask for new features. I lived through PalmSource's effort to get a good browser for Palm OS, and talked with the Be veterans about their browser work. The quick summary: it's a huge pain in the butt.
What's Apple hoping to get? The engineers at Apple who are spending their time on Safari for Windows could be creating new features for the iPhone, or helping to finish the next version of Mac OS X. Although Apple is rich enough to hire a lot of engineers, the supply of really good ones is limited, so Apple's definitely paying a price to do the port. And for what? To get people to use an alternate browser, you have to give it away for free. So there's no immediate benefit to doing the port.
A lot of Apple enthusiast sites have asked what's going on, but I'm not persuaded by most of the answers they came up with. For example, a site called Apple Matters gave four possible motivations: for bragging rights, to show Windows users what it's like to use a Mac, to give iPhone website developers a tool to test their sites, and to get revenue from search referrals to Yahoo and Google (link).
Apple Matters seems like a very good site, and to give them credit, even they were skeptical about some of the possible explanations. None of them work for me. Apple doesn't need more bragging rights, a browser is a very awkward way to show off the Mac UI, iPhone developers can buy an iPhone to test their sites, and the search referral fees from Yahoo and Google can't be all that big or everyone would be writing browsers.
I think the motivation runs deeper. It turns out that Apple didn't just port the browser to Windows; it ported the browser, the underlying Web rendering engine, and the Mac OS X programming frameworks that the browser relies on. In other words, Apple ported an entire OS layer onto Windows, and the browser is riding on top of that (link).
Now that's interesting. Apple is backing into the cross-platform OS layer business. Maybe the OS layer is just a convenient way to do the browser port. Or maybe the browser is just a trojan horse to get the OS layer on a lot more systems.
Add to this situation Apple's other recent strange announcement -- that it's "enabling" iPhone applications development by supporting Ajax web software on the iPhone. The problem with Ajax/Web2 applications is that they rely on a constant network connection in order to work. They're just thin clients to a server on the Web. Considering the iPhone's lack of true 3G connection speed, and AT&T/Cingular's well-documented data coverage limitations, Ajax-style development is about the worst thing you could do on the iPhone. What the developers wanted was the ability to create native Mac OS X applications, and Apple blew them off.
Why piss off the developers, and why put such a huge handicap on people supporting your critical new product?
Maybe the iPhone is so screwed up internally that it can't support third party apps. Sure, and maybe Apple wants to port Safari to Windows just for ego.
If you want a single idea that explains both actions, it's this: Apple realizes that in the long term, the development platform that matters is not the OS on the hardware, but the software layer that the web apps run on (I believe that; you can read more here). Apple realizes that this layer will eventually become good enough to displace native personal computer apps. Web apps then become both an opportunity and a challenge for Apple. The opportunity is that they're a way to take down Microsoft. The challenge is that the same process that obsoletes Windows obsoletes other PC operating systems, including Mac OS.
This makes it vital for Apple to create its own Web apps layer, so it can control its own destiny and increase its power. That goal would be so important that Apple would be willing to handicap iPhone apps development in the short term in order to make developers focus on the web apps platform in the long term.
If that's Apple's thinking, then the next thing to watch for will be Apple gradually adding more features to its OS layer, in the guise of browser APIs and feature enhancements. Those features will be deployed at the same time on the Mac, the iPhone, and Windows Safari. And Apple will start evangelizing web app developers to use them.
The war to come. This could set up a brutal competition in software layers, between Adobe Apollo, Microsoft Silverlight, Sun's revised Java, Firefox's platform, and Apple. Google fits in there somewhere as well, but it's not clear if they'll try to create their own platform or work with several other players.
I think this is where the most interesting action's going to be in applications development in the next few years. Stay tuned.
Jerry Yang is now in charge at Yahoo, which in my opinion means a lot because a founder is often much more willing to revisit old assumptions and make radical changes than is someone who came in after the fact. (I know the stereotype is that founders resist change, but I've found that the exact opposite is often true, especially if the founder is moving up after spending time lower in the management chain.)
Google bought Grand Central, which underlines their interest in providing client software for mobile phones. It's a significant change for Google because up to now they have focused mostly on providing mobile versions of their existing web apps, like Maps. Grand Central is different; it's a call management system that embeds Google deeply in the life of a mobile user. It implies a much tighter relationship between Google and the user than most other Google products, and it's not something that you can easily monetize through advertising -- which makes me wonder whether Google is planning to run it standalone or integrate it into something bigger.
But the strangest recent development was Apple's decision to port its Safari web browser to Windows.
It is not easy to port a browser to a new platform. There's a huge amount of programming involved -- to do the actual port, to debug it, and to maintain and upgrade the code as people identify small incompatibilities and ask for new features. I lived through PalmSource's effort to get a good browser for Palm OS, and talked with the Be veterans about their browser work. The quick summary: it's a huge pain in the butt.
What's Apple hoping to get? The engineers at Apple who are spending their time on Safari for Windows could be creating new features for the iPhone, or helping to finish the next version of Mac OS X. Although Apple is rich enough to hire a lot of engineers, the supply of really good ones is limited, so Apple's definitely paying a price to do the port. And for what? To get people to use an alternate browser, you have to give it away for free. So there's no immediate benefit to doing the port.
A lot of Apple enthusiast sites have asked what's going on, but I'm not persuaded by most of the answers they came up with. For example, a site called Apple Matters gave four possible motivations: for bragging rights, to show Windows users what it's like to use a Mac, to give iPhone website developers a tool to test their sites, and to get revenue from search referrals to Yahoo and Google (link).
Apple Matters seems like a very good site, and to give them credit, even they were skeptical about some of the possible explanations. None of them work for me. Apple doesn't need more bragging rights, a browser is a very awkward way to show off the Mac UI, iPhone developers can buy an iPhone to test their sites, and the search referral fees from Yahoo and Google can't be all that big or everyone would be writing browsers.
I think the motivation runs deeper. It turns out that Apple didn't just port the browser to Windows; it ported the browser, the underlying Web rendering engine, and the Mac OS X programming frameworks that the browser relies on. In other words, Apple ported an entire OS layer onto Windows, and the browser is riding on top of that (link).
Now that's interesting. Apple is backing into the cross-platform OS layer business. Maybe the OS layer is just a convenient way to do the browser port. Or maybe the browser is just a trojan horse to get the OS layer on a lot more systems.
Add to this situation Apple's other recent strange announcement -- that it's "enabling" iPhone applications development by supporting Ajax web software on the iPhone. The problem with Ajax/Web2 applications is that they rely on a constant network connection in order to work. They're just thin clients to a server on the Web. Considering the iPhone's lack of true 3G connection speed, and AT&T/Cingular's well-documented data coverage limitations, Ajax-style development is about the worst thing you could do on the iPhone. What the developers wanted was the ability to create native Mac OS X applications, and Apple blew them off.
Why piss off the developers, and why put such a huge handicap on people supporting your critical new product?
Maybe the iPhone is so screwed up internally that it can't support third party apps. Sure, and maybe Apple wants to port Safari to Windows just for ego.
If you want a single idea that explains both actions, it's this: Apple realizes that in the long term, the development platform that matters is not the OS on the hardware, but the software layer that the web apps run on (I believe that; you can read more here). Apple realizes that this layer will eventually become good enough to displace native personal computer apps. Web apps then become both an opportunity and a challenge for Apple. The opportunity is that they're a way to take down Microsoft. The challenge is that the same process that obsoletes Windows obsoletes other PC operating systems, including Mac OS.
This makes it vital for Apple to create its own Web apps layer, so it can control its own destiny and increase its power. That goal would be so important that Apple would be willing to handicap iPhone apps development in the short term in order to make developers focus on the web apps platform in the long term.
If that's Apple's thinking, then the next thing to watch for will be Apple gradually adding more features to its OS layer, in the guise of browser APIs and feature enhancements. Those features will be deployed at the same time on the Mac, the iPhone, and Windows Safari. And Apple will start evangelizing web app developers to use them.
The war to come. This could set up a brutal competition in software layers, between Adobe Apollo, Microsoft Silverlight, Sun's revised Java, Firefox's platform, and Apple. Google fits in there somewhere as well, but it's not clear if they'll try to create their own platform or work with several other players.
I think this is where the most interesting action's going to be in applications development in the next few years. Stay tuned.
jeudi 22 février 2007
The people who say Web 2.0 apps are garbage are completely right -- and utterly wrong
The backlash against "Web 2.0" has been underway for some time now, with many very insightful analysts and reporters pointing out the surplus of overlapping products, the uncertain business models, and the relentless hype. I think many of those critiques are right on -- a lot of the Web 2.0 companies are pointless and won't ever make money. Maybe even most of them.
But that's not the whole story. When you step back from the individual trees and look at the forest, I think the things happening in web apps today are really and truly revolutionary. If anything, the changes are a lot more profound than most people realize. And I believe they're just getting started.
As I've mentioned in other posts, the Web isn't just a place for publishing content, it's also rapidly maturing as a platform for developing new software applications. (Quick definition: in Silicon Valley-speak, a platform is a technology on top of which people build other products. Windows is a platform, as is Linux.) To me, the most important thing about the Web 2.0 sites is that they blur the distinctions between web pages and applications. Most of them don't just present information, they also let you create or manipulate it, as would a software program on your PC. Google Maps isn't just a website, it's an application for searching maps. Ten years ago, you would have bought it on a CD-ROM and installed it on your PC.
Participating in the blossoming of a new software platform is one of the most exciting things you can do in the tech industry. I've been lucky enough to be in on it twice now (Macintosh and Palm OS), and it's great because you get to work with a lot of smart developers who produce cool and surprising stuff. The excitement is infectious (thus the hype about Web 2.0).
But despite the attention people put on platforms, the way a new platform develops is not well understood in the tech industry. I think that's why people are getting confused about the fate of the Web 2.0 companies.
For example, here's a quiz -- do you know what the following names have in common? (No fair using Wikipedia; you have to do this on your own.)
Paladin
Ann Arbor
Cricket
Aldus
Silicon Beach
T/Maker
Living Videotext
If you said they're some of the most prominent early software developers* for the Macintosh, you're half right. The other thing they all have in common is that they're long gone -- out of business, sold off, or just plain faded away. In fact, other than Adobe and Microsoft, virtually none of the prominent early Mac developers are still independent businesses.
The melancholy fact is that the vast majority of the early developers on any platform fail.
This carnage of the early developers happens because a new platform is by definition unexplored territory. The developers are basically trying a series of experiments to see which types of applications will sell well. Their hit rate is better than playing the lottery, which is why VCs are willing to fund them, but inevitably most of the experiments fail.
That doesn't make the platform a failure, and it doesn't mean the applications were a waste. The successful experiments make a ton of money, more than enough to make up for the failures. And even the applications that don't survive long term often teach us new concepts and business models.
I think the same sort of shakeout is going to happen with the current crop of web apps. Most of them will eventually die or get merged into other things. That's no big deal, it's how a platform works. What matters is what we're learning through this Darwinian process. And from that viewpoint, the Web applications world is shaping up as a stunning success.
I think the three most important developments we're seeing in the web apps world are:
1. We're learning how to create new communities rapidly and focus them on useful tasks.
2. The Web is spawning new forms of media at an unprecedented rate.
3. The Web apps platform is starting to evolve exponentially.
I know the Web apps world is overhyped, so I say this very carefully and very sincerely: I think any one of those trends would be enough to drive major changes in the tech industry and the world beyond. The fact that all three are happening at once is, to me, quite remarkable, and I think it's going to have an enormous effect on our lives in the next 20 years.
I want to talk about each one of the trends, and then wrap up with some comments on overall implications and what to watch for next. Unfortunately, this post started to get waaay too long, so I'm going to do it in stages. I'll start with communities in the next post.
In the meantime, here's an example of what happens when somebody starts to sense what's happening in web apps. This is from Mike Rowehl, a software developer in the mobile phone industry, commenting on what he saw at the 3GSM telephony conference in February 2007:
Mike, you ain't seen nothing yet.
__________
*Here's a key to those old Mac developers. Even though the firms and most of the products disappeared, many of the product concepts, and the people, went on to great success. I expect the same thing to happen in web apps.
Cricket Software. Creator of a series of Mac graphics programs, including Cricket Graph, Cricket Draw, and Cricket Presents (one of the first presentation programs -- a category that Apple called "Desktop Presentations" in an effort to duplicate the desktop publishing phenomenon). Cricket was run by Jim Rafferty, a really nice guy who went on to found and co-found several other companies. I couldn't figure out what he's doing now; please post a comment if you know.
Paladin Software was creator of Crunch, a Macintosh spreadsheet program that went head to head with Excel and lost. I thought Crunch was much easier to use than Excel, with an innovative icon bar for commonly used functions. Microsoft kind of borrowed that feature later (check the screenshots here).
Aldus. Creator of PageMaker. Adobe gets the credit today for driving desktop publishing, but PageMaker was the greatest page layout product of its time, easy to use and very powerful. I believe it was the program most responsible for making the Mac a commercial success. Aldus was run by Paul Brainerd, an extremely nice guy who told his company to respond to requests from small software developers like me. Thanks, Paul! He's now a philanthropist.
Ann Arbor Softworks developed FullWrite, which claimed to be the first fully WYSIWYG word processor, and which was also one of the most notoriously prolonged instances of vaporware in computing history.
T/Maker was one of the early developers of Macintosh desktop publishing software. Heidi Roizen, CEO of the company during its Macintosh days, was a deeply respected Macintosh software entrepreneur, and later became VP of the developer relations team at Apple. She's now a venture capitalist.
Living Videotext. Produced the ThinkTank and More outliners. Run by a guy named Dave Winer. And yeah, he was just as outspoken back then.
Silicon Beach Software. Mention "Silicon Beach" to an old-time Mac user and they'll probably just sigh. The company was responsible for many of the most creative Mac programs of its time, including a game called Dark Castle and SuperCard, an early hypertext development environment that extended Apple's HyperCard in wonderful ways. Some Silicon Beach veterans later founded Back to the Beach Software, whose name is a tribute to Silicon Beach.
But that's not the whole story. When you step back from the individual trees and look at the forest, I think the things happening in web apps today are really and truly revolutionary. If anything, the changes are a lot more profound than most people realize. And I believe they're just getting started.
As I've mentioned in other posts, the Web isn't just a place for publishing content, it's also rapidly maturing as a platform for developing new software applications. (Quick definition: in Silicon Valley-speak, a platform is a technology on top of which people build other products. Windows is a platform, as is Linux.) To me, the most important thing about the Web 2.0 sites is that they blur the distinctions between web pages and applications. Most of them don't just present information, they also let you create or manipulate it, as would a software program on your PC. Google Maps isn't just a website, it's an application for searching maps. Ten years ago, you would have bought it on a CD-ROM and installed it on your PC.
Participating in the blossoming of a new software platform is one of the most exciting things you can do in the tech industry. I've been lucky enough to be in on it twice now (Macintosh and Palm OS), and it's great because you get to work with a lot of smart developers who produce cool and surprising stuff. The excitement is infectious (thus the hype about Web 2.0).
But despite the attention people put on platforms, the way a new platform develops is not well understood in the tech industry. I think that's why people are getting confused about the fate of the Web 2.0 companies.
For example, here's a quiz -- do you know what the following names have in common? (No fair using Wikipedia; you have to do this on your own.)
Paladin
Ann Arbor
Cricket
Aldus
Silicon Beach
T/Maker
Living Videotext
If you said they're some of the most prominent early software developers* for the Macintosh, you're half right. The other thing they all have in common is that they're long gone -- out of business, sold off, or just plain faded away. In fact, other than Adobe and Microsoft, virtually none of the prominent early Mac developers are still independent businesses.
The melancholy fact is that the vast majority of the early developers on any platform fail.
This carnage of the early developers happens because a new platform is by definition unexplored territory. The developers are basically trying a series of experiments to see which types of applications will sell well. Their hit rate is better than playing the lottery, which is why VCs are willing to fund them, but inevitably most of the experiments fail.
That doesn't make the platform a failure, and it doesn't mean the applications were a waste. The successful experiments make a ton of money, more than enough to make up for the failures. And even the applications that don't survive long term often teach us new concepts and business models.
I think the same sort of shakeout is going to happen with the current crop of web apps. Most of them will eventually die or get merged into other things. That's no big deal, it's how a platform works. What matters is what we're learning through this Darwinian process. And from that viewpoint, the Web applications world is shaping up as a stunning success.
I think the three most important developments we're seeing in the web apps world are:
1. We're learning how to create new communities rapidly and focus them on useful tasks.
2. The Web is spawning new forms of media at an unprecedented rate.
3. The Web apps platform is starting to evolve exponentially.
I know the Web apps world is overhyped, so I say this very carefully and very sincerely: I think any one of those trends would be enough to drive major changes in the tech industry and the world beyond. The fact that all three are happening at once is, to me, quite remarkable, and I think it's going to have an enormous effect on our lives in the next 20 years.
I want to talk about each one of the trends, and then wrap up with some comments on overall implications and what to watch for next. Unfortunately, this post started to get waaay too long, so I'm going to do it in stages. I'll start with communities in the next post.
In the meantime, here's an example of what happens when somebody starts to sense what's happening in web apps. This is from Mike Rowehl, a software developer in the mobile phone industry, commenting on what he saw at the 3GSM telephony conference in February 2007:
"I was forced to realize that the mobile world won’t end up changing the online world like I had assumed it would. It really looks like the innovation is going to flow the other way around. People who are already working in mobile have had all semblance of initiative and innovation beaten out of them. You can lay a new business model down in front of them and explain in detail how it works, and generally they aren’t able to grasp it unless it looks enough like something they already know. However, people coming from the online world and looking to expand into mobile generally are accustomed to a shifting environment and taking in new opportunities and integrating them into their mental framework.... The stage should be set for mobile to completely subsume the online world. But instead it’s the people from the online world staggering out into the sun and realizing there’s no one trying to grab the potential of the new medium and just picking up the pieces waiting for them."
Mike, you ain't seen nothing yet.
__________
*Here's a key to those old Mac developers. Even though the firms and most of the products disappeared, many of the product concepts, and the people, went on to great success. I expect the same thing to happen in web apps.
Cricket Software. Creator of a series of Mac graphics programs, including Cricket Graph, Cricket Draw, and Cricket Presents (one of the first presentation programs -- a category that Apple called "Desktop Presentations" in an effort to duplicate the desktop publishing phenomenon). Cricket was run by Jim Rafferty, a really nice guy who went on to found and co-found several other companies. I couldn't figure out what he's doing now; please post a comment if you know.
Paladin Software was creator of Crunch, a Macintosh spreadsheet program that went head to head with Excel and lost. I thought Crunch was much easier to use than Excel, with an innovative icon bar for commonly used functions. Microsoft kind of borrowed that feature later (check the screenshots here).
Aldus. Creator of PageMaker. Adobe gets the credit today for driving desktop publishing, but PageMaker was the greatest page layout product of its time, easy to use and very powerful. I believe it was the program most responsible for making the Mac a commercial success. Aldus was run by Paul Brainerd, an extremely nice guy who told his company to respond to requests from small software developers like me. Thanks, Paul! He's now a philanthropist.
Ann Arbor Softworks developed FullWrite, which claimed to be the first fully WYSIWYG word processor, and which was also one of the most notoriously prolonged instances of vaporware in computing history.
T/Maker was one of the early developers of Macintosh desktop publishing software. Heidi Roizen, CEO of the company during its Macintosh days, was a deeply respected Macintosh software entrepreneur, and later became VP of the developer relations team at Apple. She's now a venture capitalist.
Living Videotext. Produced the ThinkTank and More outliners. Run by a guy named Dave Winer. And yeah, he was just as outspoken back then.
Silicon Beach Software. Mention "Silicon Beach" to an old-time Mac user and they'll probably just sigh. The company was responsible for many of the most creative Mac programs of its time, including a game called Dark Castle and SuperCard, an early hypertext development environment that extended Apple's HyperCard in wonderful ways. Some Silicon Beach veterans later founded Back to the Beach Software, whose name is a tribute to Silicon Beach.
Inscription à :
Articles (Atom)