The End of the Web? Don’t Bet on It. Here’s Why

Fred Wilson recently posted a great video on his blog with the CEO of Forrester Research, George Colony. The money slide is the graphic below.

The chart shows three scarce resources and their improvements over time. The top line is available storage (S), the middle line represents processing power (following Moore’s law) or (P) and the bottom line is the Network (N).

In it he asserts that the web is dying and in its ashes will see the rise of the “App Internet.” The App Internet is different than the HTML Internet (aka The Web, WWW and in the mobile arena “The Mobile Internet” or short-hand HTML5) because the “presentation layer” and “client side” functionality are defined by applications that run on your mobile device and connect into the open Internet back-end to exchange information with other web services.

He’s right about this. But only temporarily in my view. And while the App Internet is currently more powerful than the Mobile Internet it has fundamental flaws. It isn’t open in either its standards or in the way that applications are marketed and distributed. I will cover this in my post.

Colony’s presentation is intriguing (and worth a watch if you have a few minutes) because I love to see when informed people make arguments that are different than you ordinarily hear (and different from my own views). In the end, my bet is that George’s bets will largely prove wrong. This blog post lays out my case. If anybody from Forrester reads this I hope they won’t see it as an attack on George’s presentation, which I found enlightening, well argued and interesting. My views are just a data point in the debate.

In the end, Seth Godin’s comments on Fred’s blog post said it best:

“His black swan is showing.

The problem with just about every prediction made by industry firms like Forrester (all the way back to 1985 when these firms said that the Commodore 64 was going to change the world–until the VCR interrupted to become the next big thing) is that they are based on sophisticated analysis of what’s in the rear-view mirror. 

A tough way to drive.

The trends are legit, but we have no idea what unexpected breakthrough in human interaction is going to change everything.”

In other words, nobody can really assert authoritatively what the future of tech or the Internet will hold. I have some educated guesses.

George’s Arguments

1. The web is dying and will be replaced by “the App Internet.” He says that since storage & processing are growing at a much more rapid rate than the network we’ll be at a point where not having apps on devices will greatly under utilize the power of the devices in our hands. In other words, our mobile devices are all powerful and the network that they connect into sucks.

2. Social networking is peaking. He cites that we have reaching a saturation of social networking in which nearly everybody is already using social networks (85+% in most developed countries and in urban environments in the developing world) and the amount of time dedicated to social activities already exceeds many other important tasks such as exercise and is even approaching the same amount of time we dedicate to child care. He argues for a world he calls POSO (post social) in which we will only use social applications which drastically cut down our time involvement and/or increase our productivity.

3. Social media will be pervasive in the enterprise and is primarily driving by customer interactions. He shows data that the overwhelming majority of major enterprise in the US is currently adopting or looking to adopt social networking technology. When asked what their objectives are they cite some form of “improving customer communications” by a long margin.

A (Very) Brief (and Selective) History in Computing
To understand my perspective you have to rewind to the late 80′s / early 90′s in business computing. As a software developer I wrote code on what was called a “dumb terminal” because it literally had no processing capability. It is the opposite of the world that Colony describes. The local computer had no processing capability, the network did its job and the central computer was the master.

We wrote programs that existed solely on a centralized computer (a mainframe), all of our data was stored centrally and all processing was centralized. When we wanted to compile our programs (turning human programming language into an executable file that the computer can read) we had to submit them to the mainframe and wait for them to be processed in sequence along with everybody else’s code.

In busy times compiling a program could take more than an hour, so we obviously didn’t submit often and if our program had errors and was unable to compile it was devastating. Things got so bad on one project that we ended up doing split shifts with teams of people programming from 8pm-6am and the next team arriving at 8am.

Throughout the 90′s the PC became much more popular in corporate environments, so companies began to replace dumb terminals with PCs. We ran software on the PCs called “terminal emulation” that allowed us to act like a dumb terminal to interact with mainframes and to act like a PC (with word processing, spreadsheets, etc. the rest of the time.

In this era the computing model known as “client / server computing” was popularized. What this model said was that since we now had really powerful processing on our desktops we should split the computing responsibilities between the PC (the client) and the mainframe (the server). Initially the computer did basic functions like “screen validation” (making sure that you didn’t enter non-sensical data into fields, for example) and could take over functions like compiling your software code so you could check for errors before submitting it to the mainframe.

Over time the PCs began to do more and more. They took over the “presentation layer” of computing. As a society we got used to the windows metaphor of computing. So suddenly we had “drop down” boxes that gave us multiple choice selection of data, we had dialog boxes that would prompt us with “Are you sure you want to proceed? Y/N.” This initially took on what was called “thin clients” because the server did most of the work.

The more the processors on our PC improved, the more we expected our PCs to do and everybody gushed about this new era where we had much better user interfaces and we had way more individual device power. Centralized computing was giving way to smart, distributed devices.

Sound familiar?

It was wonderful. For 5 minutes. Then the unintended consequences started cropping up.

  • How much data was acceptable to sit on local devices? Few had considered what happened in a world in which the data was distributed. Suddenly you had security risks, confidentiality problems, privacy concerns (think about your medical records being distributed), etc.
  • What happened when you submitted a processing request to a central server (think, I’d like to transfer money from my bank to yours) but the transaction didn’t complete? You could be in a situation where your local computer had assumed the money was transferred and it wasn’t. We had to develop whole frameworks of “middleware” to deal with this problem. We had to come up with “two phase commits” and “rollbacks” and other data tricks to keep our devices in sync.
  • We started to realize that that most expensive part of computing was actually manpower. Manpower to develop all of these applications, manpower to maintain them, and manpower to deal with all of these devices, which added great complexity to our IT environments. For example, on any software upgrade for a typical client/server enterprise package it would take up to 50% of the overall development budgets to deal with testing the software in heterogenous environments.

So having powerful devices with decentralized computing is not always a panacea.

Enter the World Wide Web (WWW).

As George appropriately describes in his video, the Internet and the Web are two different, but related things. The Internet represents what you might think of as “plumbing.” It defines how data gets moved around on networks, how files get located, how files get transfered between devices, how packets of data get sent via routers, etc. The WWW is the presentation layer. It’s central standard was HTML (hyper text markup language) that described how we would show data on computer screens.

When web browsers (the programs that can read and interpret HTML) were popularized they were “dumb.” It was literally like returning to the old days of computing. On the Web almost all of the processing was centralized and your browser was your input / output device. As an example of how dumb they were (for those that don’t remember) whenever you changed one field in a browser-designed program the entire screen had to refresh. It was a terrible user experience.

But for software developers like my company the web was a blessing. We were able to crank out software code at a much greater pace than was ever possible for. We designed our code and tested it in a Firefox browser and once we had working code we then had to figure out how to make the clunky Internet Explorer work. But the heterogenous environment was practically eliminated. We didn’t have to worry about which computer you were on. we didn’t have to support 3 database types, worry about network configurations, etc.

We flirted for a brief period with building some client-side applications (mostly for offline use) but abandoned those efforts when we realized how much overhead it took to maintain – especially as we release new versions of our code and had to always keep the local, offline software in sync with our releases.

We adopted an ethos that all of our development would be web only and that eventually browsers would become more powerful and make the user experience much better. And that’s what happened. A series of standards emerged known as “AJAX” (asynchronous javascript and xml) that gave the web-based designer much more control over the browser. Suddenly you could update small portions of the browser without refreshing the whole screen.

AJAX was one of the major drivers of the “dot com renaissance” that became known as Web 2.0. As people realized streamlining client-side development really matters to cost-effectively build software, new tool sets emerged to streamline the process. Libraries like jQuery have emerged that lower the effort to build front-end code.

Web & Social Change the Landscape of the Web

Prior to the popularization of smart phones and Facebook we were in a pretty good place on the Web. The one big concern many people had was how to constrain the total dominance of Google. Every startup (every company, really) was beholden to the traffic god that was Google search. One change in Google’s algorithm and whole businesses could be wiped out as chronicled in this excellent book by John Battelle called The Search.

The growth of social networking (er, the growth of Facebook) along with the growth of the iPhone have changed the landscape dramatically.

In this chart from Silicon Alley Insider you can see the first major trend to affect the open Web – the growth of Facebook. And Facebook’s popularity has only increased in the past year.

Why does the rise of Facebook affect the web? Because it isn’t a part of the open WWW. Facebook exists behind a walled garden. You need to log in to use it. Content or software developers who want to build products that work in Facebook have got to develop inside of Facebook’s framework rather than working on open, Internet standards.

Brands, celebrities and even individuals like you who produce information inside this walled garden are subject to the rules & conditions set upon you by a private company – Facebook. This isn’t a case against Facebook, it’s just a statement of fact.

As more people consume Facebook pages, less people are consuming open Web pages.

I wrote about this previously here and spoke about it on YouTube with Howard Lindzon here & here. (if you’re not that familiar with the topic it’s worth a 20-minute watch)

Is the App Emerging as the Winner?
The App Internet had a clear advantage in the past few years. Why? Because the mobile devices had a series of new features for which mobile browsers were not optimized. Examples include the camera, GPS, the accelerometer and the small screen sizes.

And importantly when developing games that require high-end graphics to handle game play you need to make use of the iPhone’s PowerVR GPU (graphics processing unit).

So Apps were inherently more powerful than browser-based applications.

It also had two other huge advantages.

1. Apple had a mechanism for charging users for apps and because most people already had an iTunes account it was simply 1-click to purchase an item. This meant that small teams could create games and make real revenue whereas on the Web this was much harder because you either had to build (or license) your own billing infrastructure, convince consumers to get out their credit cards (which they don’t like to do) or you had to sell enough advertising to make it worth offering your product.

2. Apple had a store. For early game developers this made it easier for your application to be found on the limited “shelves” in the iPhone App Store. Now that there are MANY more apps out there – this isn’t such an easy game. But in the early days the App Store was very appealing to new entrants.

Round 1 clearly goes to the App Internet.

Will the App Metaphor Hold for Mobile?
This is where my disagreement with many starts. I think the allure of Round 1 has convinced people that in mobile, apps are better. I’m not so sure.

1. Workarounds are developed. The surest sign of a market inefficiency is when solutions emerge to help developers get around the bottlenecks of platform development. This is what is happening in mobile. Developers are now able to build apps in native languages such as Javascript or HTML5 that can run in multiple platforms.

There are companies that develop “wrappers” that in essence handle all of the functionality needed to control each individual device that “abstracts” the programmer from having to build in device specific code. Some of the companies that do this include PhoneGap, Appcelerator, Strobe and RhoMobile.

2. Browsers will catch up. Just as in the first round of the web when everybody complained that web browsers weren’t powerful enough to build applications on, many of us believed that open systems would win. Eventually standards will emerge that will make it easier to build natively into browsers. Effectively either the wrapper developers become browsers or the browsers build wrappers or the two groups merge.

Also note that AJAX finally took off when Google open-sourced a bunch of its internally built AJAX frameworks. I wouldn’t be surprised if big innovations from Facebook and others in the mobile web eventually see there way into open-source mobile initiatives.

3. The costs of multi-platform development are too expensive. The costs for developers to build for multiple platforms is too great, the gatekeepers are too powerful and the outcomes ultimately limit innovation as happens in any system when a few players are a choke hold on distribution.

If you want to do a deeper dive on why I believe this is bad overall for the system despite the short-term allure of iPhone’s beautiful products please see my post “App is Crap, why Apple is bad for your health.” And before Fanboys slam me, please note that I own 3 Mac laptops, 2 iPads, 5 iPod devices & Apple TV. I love the products. That doesn’t mean I think it’s great for our future as an industry to have a close distribution system.

4. Distribution becomes a stranglehold. Fred Wilson talks about this in his “mobile gatekeepers” post. The early allure of empty shelves in the App Store is making way to the over-crowded shelve (currently tallied at more than 500,000 SKUs). This leads to all sorts of games by developers to get into the rankings, most of which favor companies with more cash.

Also, whenever we see distribution strangleholds we tend to see slower innovation and more resistance by the distributor to change. Think about the following examples:

  • mobile phone companies who controlled our crappy phones prior to the iPhone breaking that hegemony
  • cable & satellite companies who have controlled our paid TV through set-top boxes that make it impossible for innovation on the TV set
  • radio stations that controlled the music we listened to until music could achieve wider distribution on the Internet

Choke points are never good for innovation.

5. Data, data, data. Just as when we first went from mainframe computing to client-server computing we forgot that data leakage and data management across multiple devices is a big issue. The App Internet creates the potential for many more data issues. That doesn’t mean they can’t be solved, but it’s not as easy as saying, “powerful apps on our mobile devices is the best answer.” More power, more distribution = more data problems.

6. TCO. There is an acronym we use in computing called TCO or Total Cost of Ownership. It is often used in ROI calculation on projects to estimate a build vs. buy decision. Often people who build apps internally at their company calculate only the costs of the initial build rather than the total costs of maintenance of the project. Maintenance often greatly exceeds the development costs when you consider both human costs of maintenance plus the loss of productivity of not having an app that innovates as fast as the market solutions do.

I think there’s a TCO argument to be made against the proliferation of the App Internet. The more companies build their own apps, the more maintenance work they’ll need to do, the more employees they’ll need to maintain their apps and the further the innovation drain. I know this is a harder concept to quantify and intellectualize but I’ve seen it first hand in 20 years of working with large corporation on “legacy” IT projects. The App Internet opens the door to many more legacy apps.

This argument never features into any young developers mind because it takes years to see the decaying effect of legacy infrastructure in corporations (plus, many app developers prefer the sexy world of consumer apps).

To be clear … I think that the App Internet won’t disappear overnight. I also think certain apps will always be more effective built natively. But the same is true of today’s non-mobile computing. Still, most apps need not exist. Long live the Mobile Web.

And What about Colony’s Assertions about Social?
I’m going to save that for a future post. Coming soon.

Postscript:

“If I had more time, I would have written a shorter letter.”

Marcus T Cicero

Sorry for the uber long post. Given more time I could make it concise. And I’d have fewer typos. But I valued getting my ideas out there. If you think there are any inaccuracies I’d be glad to meet you in the comments section and I’ll gladly amend any mistakes (rather than differences of opinion)

(Cross-posted @ Both Sides of the Table)

LinkedIn TwitterFacebook
2x startup Founder & CEO who has gone to the Dark Side of VC. His first company, BuildOnline was sold in 2005, his second, Koral was acquired by Salesforce.com and became known as Salesforce Content, while Mark served as VP Product Management. In 2007 Mark joined GRP Partners in 2007 as a General Partner.  He focuses on early-stage technology companies, usually looking at Series A investment, and blogs at the aptly titled Both Sides of the Table.