Why Google Apps Fail
July 15th, 2008
Google Apps is(are) the new MS Office complete with spreadsheet, slide presenter, database, and word processor. They all suck. Commonly cited reasons for failure are that the browser is not an OS, Javascript lacks support for concurrency, Javascript is slow, businesses are slow to adapt to new technology, community authorship is already solved by VCS and wikis, etc. Here’s the real reason they fail: fighting the last war. Word processors and spreadsheets are generic, where “generic” carries the same negative connotation as when applied to performance art.
Google shouldn’t be trying to make generic apps easier to use on the web. Email, IRC, IM, wikis, forums, and social bookmarking have an evolved interface balancing generality with complexity. They are also not stand alone programs that can have the network part removed like a word processor. Even if all the technical browser/script problems are solved, what will Google Apps offer other than a plethora of features bolted on to something resembling a wiki? It’s generic.
Features can increase generality, but at some level of generality the competing technology becomes Sqlite, Linux, or Java; not MS Word. I’ve witnessed the humor of a Salesforce tech-support conference call. My client was using a form that posted to Salesforce and was trying to add some work-flow features on the Salesforce end. What I heard astounded me, the client was getting a lesson in scripting from the tech. I left the call early, glad my part was limited to creating the form. A solution can go in two directions as it becomes more general; more abstract, or more complex. MS Word and Powerpoint embrace complexity. Programming languages lean toward abstraction. Either way, generic solutions are always harder to use.
The MS Office suite thrived because it made it easy to share. Embrace, extend, extinguish. One app to open them all! The complexity was necessary for generality, and generality was necessary for sharing. On the isolated PC there wasn’t room for a special version of Powerpoint for teaching with another for pitching sales. Word had to handle letters, resumes, and instruction manuals, in formats including HTML, text, and binary. It had to interface with Access and embed Excel documents, and each of those programs had to share well with others in the suite. It was a very capable one-size-fits-all solution that was very complex as a result.
With the web offering effectively unlimited storage on top of easy distribution and sharing, there is no longer a need for one-size-fits-all suites. New apps can depart from the generic view of the suite and approach problems directly. There should not be a Powerpoint of the Web . Instead, applications should specialize so that one for e.g. teaching aircraft systems or training sales reps will bundle a tailored likeness of Powerpoint. Slides in this new hypothetical software might pull facts from manuals or link to simulations, each of which is another specialized application, reiterating the importance of sharing. Thus, The Web
Google Apps solve the problem of sharing by offering a uniform API (so 1990), on the web (so 2000). In contrast the new application suite will have as many APIs as there are applications, and as many applications as there are problems to solve. Google Apps are generic and lame.
on November 10th, 2008 at 04:48 PM
Web apps are kind of the lowest common denominator when it comes to specializing or fancy user interfaces no? But the also serve the needs of people that are not specialists. They are also low cost to operate, serving the needs of those without money or without computers of their own. Just a couple quick thoughts. Plus would you really want to not have google apps around at all? and if google wasn’t doing those “generic” apps, what company or open source group would do them better (while still being free)?
on November 30th, 2008 at 09:57 AM
While I agree that more specialized webapps are much better at performing that specific task you need, there are a couple of problems that become obvious once you replace your generic software with thin-client specialized software.
1) Interoperability becomes a huge issue. Some webapps offer great REST interfaces to integrate with and share your data, however security and the actual conversation’s are not standardized and I’m not sure they ever will be (think ESB). You really do need to move spreadsheet data into a word processing document sometimes. If you use a specialized application to manage a specific type of spreadsheet it may be far more efficient, but it also means you need to worry about how you get data in and out of it to other specialized applications built by other companies, and how secure that integration is. Far from solved.
2) Lack of single sign on. How many usernames and passwords does the typical office employee really want to maintain. This needs to happen soon, but every attempt at a solution has either had ridiculous lock-in (MS, Google) or low adoption beyond tech circles (OpenID).
I consider myself an early adopter of the light and specialized web services. I never use office or any online office offerings anymore and haven’t for years. But I’m a coder and definitely not the typical office application user.
I don’t think your typical enterprise will be ready for a while, and definitely not until some interop and security issues are resolved. Small companies and startups are all over it, but even so, most still have employees with MS office installed.