Google Acquires Writely: The Q&A

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

I can’t remember when I first came across Writely, but I can tell you that I started to use it more often after being reminded of the service in this post from MIT’s Al Essa. Ironically, I found myself somewhat reluctant to let go of Open Office for such tasks simply because that’s what I’m used to; I say ironically because this is precisely the same problem Open Office itself faces in trying to unseat its Microsoft counterpart.

Anyhow, as probably everyone is aware of by now, Google – going against the Not Invented Here reputation they have in some quarters – acquired Writely yesterday. This is interesting to me on several levels, so I thought I’d do a quick Q&A.

Q: Ok, let’s start with a bit of background on Writely. What’s your experience with the tool or company?
A: Unlike some of the folks behind other online Software-as-a-Service (SaaS) tools, I have never spoken to the folks behind Writely. I’ve used it for a little while, though not extensively. A couple of things I’ve tried it for:

  1. Helping brush up a friend of mine’s resume; this was far easier than shooting Word documents back and forth via email
  2. Trying to review a design requirements document from the same friend; it gagged on the > 3 MB file
  3. Producing an outline for an upcoming project; it was more than adequate for this task
  4. Reviewing a publication authored by one of my colleagues and edited by the other; Writely

As the above tasks indicate, Writely is a very capable tool for the type of light editing and authoring that comprises the majority of necessary word processing work. It falls down on highly complex or abnormally large documents, but for an application positioned as Writely is that’s probably acceptable – for now.

Perhaps most importantly, Writely just works – the latency, in my limited experience anyhow, is perfectly acceptable.

Q: What are ‘levels’ that you mentioned earlier – why is this acquisition interesting?
A: There are multiple angles to consider, among them: the emerging potential for a GOffice offering, the broader implications for Web 2.0 firms, the MacArthur-esque island hopping/innovation potential here, and lastly, what Simon said: that Google now has an ODF offering.

Q: Let’s tackle those in order – what do you think a GOffice would look like?
A: Here’s what I said back in June about that possibility:

Might we be looking at an end around towards Google based office services?…

So is it possible to envision a scenario in which Google decides to implement the following:

1. Basic calendaring system as you’d find in Yahoo Mail (only it’s actually usable given the performance)
2. POP/IMAP access for clients
3. Forwarding/domain services

and we see SMBs start to consider it? I think so.

If we’re to believe TechCrunch, #1 is on the way. #2 they had a long while ago. And #3? That’s in beta.

Now add to that Writely, which presumably could be integrated nicely into an office “suite” – and I use the term loosely – that would offer the majority of the features that most of us would ever need. As a service. A cross-platform service. Google could offer a truly usable email, instant messaging, calendaring and word processing functionality over the operating system independent network.

Would this obviate the need for something like Microsoft Office or Open Office? Of course not. It doesn’t include spreadsheeting (though there are multiple players that could be acquired there – iRows or Jot Tracker among them) or presentation capabilities, for one, and more importantly it doesn’t match Microsoft’s offering in particular feature for feature. Nor does it aspire to. But of course that’s part of the point.

Q: What do you mean that’s part of the point?
A: It comes back to the question of innovation. Many believe that Microsoft has overdelivered innovation to its Office customers, which is why many feel a distinct lack of motivation to upgrade. Friend of RedMonk Stephe Walli puts it best here:

The interesting thing is the dilemma [Microsoft] faces. They have to continue to deliver new product releases with new features and functions. That’s what Wall Street rewards them for doing. And the incumbent is even brilliantly creating new innovations in the space and could be working feverishly to deliver them. But the bulk of their customers are over served. They can’t eat the last round of innovations. Why would they want to pay for the next round? Remember, economically, innovation is a supply side activity — customers just want to buy solutions and they don’t want to buy things they don’t use regardless of how innovative they might indeed be.

Microsoft has continued to pack features into Office at steady rate over the years, raising questions of customer appetite for said features. How many of us truly use even 75% of what Microsoft Word, as an example, offers us? My argument is few, hence the relevance of less functional but potentially more usable packages like Writely. That’s part of it. But there’s also the question of where to innovate.

Q: Where to innovate? What do you mean?
A: Well, as I discussed in RedMonk’s inaugural podcast (will be up soon and I’ll point to it) there are those who’d contend that trying to match Microsoft feature by feature, as Open Office sometimes does, is more or less a losing proposition. Another Friend of RedMonk, Ubuntu’s Jeff Waugh, for example, said the following in making the case for GNOME Office:

OpenOffice.org is not aggressively competitive with Microsoft Office – it’s playing to match the feature matrix instead of leapfrogging and defining new ground to fight on. That is not a winning strategy, particularly when the stakes involve the future of Software Freedom in the hands of users around the world.

Whether or not you agree with the concept of (yet) another office suite, the point around innovation is well taken. As MacArthur proved during World War II, sometimes the best strategy is not competing head on, but by bypassing the argument altogether.

Thus Writely doesn’t try and compete with Microsoft by having, say, mail merge capabilities, but rather adds something that Office doesn’t (currently) have – online collaborative editing. Google’s done this effectively before with its Gmail, although in its aggressive reconsideration of application user interfaces they can occasionally go too far, as they have – IMO – with Google Reader which I won’t use (unlike a couple of folks from the Denver Tech Meetup last night).

Q: So these have been mainly specific considerations with respect to Writely’s application area – office type functionality. What do you think this acquisition can teach us about the likelihood of other Web 2.0ish acquisitions?
A: Well, it should first be noted of course that the acquisition of these or similar firms is de rigeur in this industry. As I discussed with one reporter today, startups can in some ways be seen as the outsourcing of innovation by larger firms. Here’s how Paul Graham put it:

In many businesses, it just makes more sense for companies to get technology by buying startups rather than developing it in house. You pay more, but there is less risk, and risk is what big companies don’t want. It makes the guys developing the technology more accountable, because they only get paid if they build the winner. And you end up with better technology, created faster, because things are made in the innovative atmosphere of startups instead of the bureaucratic atmosphere of big companies.

How does this apply to Writely? It’s a bit unclear.

As James noted on today’s podcast, at least from appearances Writely is an ASP.net app (which perhaps gives credence to Tim’s point here – and to the claims I’ve heard from the Mono folks periodically), which doesn’t seem to fit Google’s overall language/platform strategy.

Throw in the fact that I’ve been told by folks who know that Google is not particularly fond of paying for technology – they’d rather buy people, with obvious exceptions like Pyra or, more recently, MeasureMap – and it’s apparent that Writely had something Google liked. Which piece that is is open for debate.

Q: But what does this mean for Writely-like startups?
A: Perhaps nothing, it’s difficult to say. But a point that I’ve made many times in the past is that scalability, while never easy, is particularly challenging for smaller startups. SaaS in that fashion is both blessing and curse: the good news is that you have a potentially infinite customer base, and the bad news is that…you guessed it…you have a potentially infinite customer base.

And while Google’s not perfect with respect to scalability, as the occasional Gmail outages indicate (and as Cote notes, it’s interesting that post acquisition Writely has closed its doors – perhaps to avoid a Google Analytics like crash), they are certainly more resources at their disposal than does Writely, or virtually any other startup. Because while open source can compress the total cost of software, it does little or nothing to lessen the outlay for hardware, networking, bandwidth, etc.

So what does it mean? Certainly not that every Web 2.0 startup must flip to be successful. But definitely that that remains a very viable (and usually attractive) prospect.

Q: Ok, last point – ODF. What does this mean for that standard?
A: As Bob Sutor noted in November, Writely was one of the first services out of the gate to support the Open Document Format – alongside, of course, Microsoft’s Office format. That was interesting, as has been Google’s subtle but documented interest in the Open Office.org project. But now, as Simon noted – Google will actually be shipping an ODF compliant editor. One that, presumably, will ultimately be available for anyone and everyone.

Does that make a difference in the standard? Opinions on the OO.o listserv differ, but for my money it does. What the ODF crowd could use more than anything else is a growing body of documentation created and saved to the ODF format; Writely, if nothing else, could provide that. So while this move certainly does little for the fortunes of ODF within the enterprise, it’s not just another implementation of the standard – it’s one that may actually see a sizable audience. Think volume.

Q: Any other parting thoughts?
A: Just that I’d love to see Writely continue to innovate in different directions; don’t try and be Word. Leave that to other projects; I’d much prefer to begin to see things like wiki features make their way into the package.


  1. RedMonk Radio Episode 01 – The Dread Red Stripe, Writely, Web 2.0 Business Models

    I managed to pin Steve and James down for an hour, at the same time, last Friday to record our first podcast episode. The topic: Google’s acquisition of Writely. There’s also some good discussion about business models for smaller, Web…

  2. Web 2.0 IDE’s and Constraint-based Design

    James sent over a post from John Montgomery wondering out-loud what a web based IDE would look like, or if it’s even possible and/or desirable. I know: it sounds crazy to all us developer types out there. The web is…

  3. I heard something interesting the other day. From a veteran OpenOffice.org on Windows 2K user no less. It went something like this, “Oh, i get it now. gWritely is what’s on the other side of gDrive. It’s what happens to an ODF file when i’m working the Internet”.

    Maybe i would amend that to say that for many of us, gWritely is the network side of OpenOffice.org. Many of the proposals and discussions that led to the recent initiation of the OASIS ODF Metadata Sub Committee were collaboratively thrashed at Writely. Not just because we believe in eating our own dog food (although we do). Writely is an excellent collaboration tool.

    The one thing i would add to your prescient analysis Stephen is that the gWritely-ODF-gDrive pipeline does two things not mentioned in your Q&A.

    First, the gPipeline is sure to change how googlers mesh their local information with the Google mankind information motherload. I continue to be amazed that Google does a better job managing my information than anything Microsoft (or anyone else for that matter) ever provided me. Now, with the gPipeline, they are going to dramatically extend what i do with the information they manage for me.

    The second point is that the gPipeline is a dramatic outsourcing of Google”s core services. In the future, googlers will be doing much of the work that makes Google information services so valuable. How’s that you ask? Google’s quest is that of organizing mankind’s information and making it universally accessible and useful. To do this they have built a massive computational power plant, stoked it with advanced algorithms designed to provide structure where non exists, and unleashed their reach over the global infogrid.

    To leverage the value of this equation, one has only to increase the value of any of the three components of power, reach, and structure. Google continues to pour cpu and storage resources into the computational power plant. What gDrive does is wire in local computational power. By providing the information that flows through the pipeline with collaborative tools like gWritely, Google increases and accelerates the flow of information over the Open Internet. Their reach and use of the Open Internet is extended every time a new gDrive portal is opened up, and participation in the Google information stream increases. The last factor though, “structured information”, will have the most impact.

    The infamous Google algorithms are a blunt instrument designed for a time when the language of the Open Internet was either unstructured HTML, or came from secretly structured black box data info stores and silos (or what has otherwise been called “the dark web”). The only way for Google to organize this information was to impose a structure using algorithms designed to guess at meaning and understanding. The document container with a URL address and an algorithmic bill of laden describing the contents was the best anyone could do. Google mastered the blunt instrument approach in part through their mastery of Linux clustering of commodity components resulting in the most cost efficient power plant assembled, and, in the rocket science of advanced algorithms.

    That was then and this is now. In 1998 the W3C released the XML 1.0 specification, and two very different branches of structured information activity took off. One branch was based on the proliferation of XML schema’s enabling black box systems to exchange information, broadcast information services, and digitally join collaborative information and business processes. XML in this sense became a common language for shared business processes involving disparate back end business processing systems. Here the amazing transformational qualities of XML structured information were of such value.

    The other branch was that of XML file formats. After an initial sprawl where every information discipline and domain set out to have their own XML language, we are now coming back down to earth, to value what Tim Bray has called “the big five”. Having a specific XML schema to define each and every shared business processes makes sense in that the quality of transformation and interoperability with black box systems largely depends on the depth of details defining the fidelity of these digital handshakes. But having hundreds of XML languages complicates, compromises and clogs the very same transformation and interoperability capabilities that should otherwise be the hallmark of an XML ready infrastructure.

    The “structure” issue is further complicated in that even Tim’s “big five” XML languages differ in the quality of structure available. There is simple “self describing” metadata, and there is the semantic metadata process. Since few people are watching the OASIS ODF Metadata work, most observers are unaware that ODF is about to bridge XML and RDF, and become an important gateway for Sir Timothy’s Semantic Web. ODF will be positioned to enable information consumers and workers a means of interacting with vast volumes of information, initiating the process of provisioning and building in semantic structuring.

    If all ODF was doing was to provide an enhanced metadata model, Google would benefit in that googlers would be goosing the effectiveness of the famed search and sort algorithmic engine by feeding it better information about the documents information. The gPipeline becomes an outsourcing not of algorithmic development, but algorithmic effectiveness, with googlers providing the a knowledge based structuring beyond and above the reach of the algorithms. To get there though, googlers need an enhanced metadata model at the XML file format level, and, they need a user interface layer enabling them to do conceptual and ontology based tagging.

    The ODF XML::RDF bridge will enable armies of googlers to fill the gPipeline with a semantic structuring connecting specific ontologies and business process vocabularies to information objects within the document model. This will be the beginning of the end for the “contained” document model that now populates a Google search. The end of the document model, where the container is the discrete component will usher in the beginning of a data object model where the conceptual and data objects within the container are the most discreetly defined and re usable components. Enter a conceptual object model where information objects are tagged and connected via conceptual or ontological relationships exposed as metadata.

    The blunt instrument Google now uses to hammer structure into our flows of unstructured information will eventually be replaced by the high fidelity fine tuning of semantic based conceptual searches. Instead of returning pages listing thousands of documents that may or may not contain the information we seek, a semantic Google search would return exactly the information objects were looking for. We would be looking at a list of paragraphs, photos, drawings, bulleted lists, charts, and other document objects exactly related to the concept we’re researching, er “googling”.

    I’m not saying that the famed Google algorithms have hit the wall. It’s just that Google has amassed all this computational power and maybe it’s time to fully engage the hordes of googlers currently feeding off the machine in the exciting process of feeding the machine. I do believe the hordes can offer a quality of information structuring that will push the Google business objectives of organizing all the information to levels beyond that which is immediately achievable by algorithmic wonders. The trick is giving googlers the information service tools they need to fill that gPipeline with semantic quality information.

    Of course for me the most important thing about the Google acquisition of Writely is that it shouts to the world that ODF is an Internet ready XML file format. Yes, it’s great that Writely brings ODF XML structuring power to Wiki and Blogware collaborative computing. I think though that this magic will be dwarfed by the unification factor made possible with a Writely moving into the hands of a Google.

    OpenDocument has sharp elbows, and is carving out territory in key information system domains such as desktop productivity, publishing and content management, Service Oriented Architectures, and now, the Open Internet. With this single acquisition, Google moves further into these four critical domains and has to be considered an information service provider to watch in that they are able to reach across these domains with an information unification factor and service that stands alone.

    This observation brings up another comment i have. Whatever competition Google might have across these information domains is likely to present itself as either Software as a Package, Software as a System or, SaaS, “Software as a Service”. That’s not what Google is about. You might call Writely a SaaS implementation, or refer to OpenOffice.org as Software as a Package. But that doesn’t do justice to what Google is doing. IMHO, Google is a carrier of information freight. They move digital information. The logistics of this process involve transport like concerns such as volume management, acceleration, handling, timely delivery, and conveniently automated customer service. The software in this system isn’t the service. Information organization and usefulness is the service.

    The reason this point is important is that where Google works information, the competition for the most part works software. If your focus is software, it’s expected that information will be bound in different ways to the software services. If your focus is information though, software becomes just another tool of usefulness.

    Let’s take this further. To be useful as a tool, the software can’t be bound or tied to the information. You wouldn’t tie a hammer to a nail or a screw driver to a screw. The simple truth is that information that is tied to software has limited use. Fine for client/server and personal computing, but a killer in the digital civilization that is the Open Internet.

    The integrity of the complete independence between software and information becomes the essence of acceleration and global volume management. When software does bind information, the movement of the information is compromised, burdened, and slowed. All of which would be a killer to the Google service. Maybe that’s why Google defines their options as either “services” or “tools”? Capice?

    Some point out that gWritely validates the Microsoft Live vision. Even though gWritely will likely be able to work with all sorts of file formats, MS binary and MSECMAXML included, the trend will be for information consumers and workers to focus on Internet ready formats that can cross over into other important information domains. It is here that the differences between MS Live and Google will become most visible.

    HTML, XHTML and ODF are application and platform independent. ODF is a wrapper of Open XML (and in the future RDF) technologies, creating dependencies based on open Internet standards. So this works well for the Google business model where the clean clear openness of the Open Internet is essential to the Google purpose of organizing mankind’s information and making it useful.

    MSECMAXML on the other hand stands in sharp contrast to this independence, and can best be described as an XML wrapper of Windows application and platform dependencies; some of which go as far back Windows 3.1 (wmf), and as far forward as the yet to be released MS Vista – WinFX system dependencies. Since Microsoft Windows is a carrier of software, this model works well for them. It continues a long tradition. What it doesn’t do though is advantage the Open Internet. MS Live will be able to extend the richness of the XP-Vista MS Office 12 software into the age of collaborative computing as SaaS. But it will never have the acceleration and global reach of Google information services. Google understands the “Internet” value of uncoupling information from software, and that this is entirely in line with the Google business model. This same value is completely adverse to the Microsoft business model where continued profitability is in binding information to software.

    For sure we’ve had this conversation before. This time however the context is that of Google and Microsoft where things shake out a bit differently. MSECMAXML has yet to make it to the Internet. With the mess of systems dependencies clogging up the specification, i wonder if MSECMAXML will ever be able to make the leap to RDF and the Semantic Web? There is zero probability of MS embracing ODF, or in giving up their traditions of binding information to software, or enabling Google or anyone else the ODF ecosystem to perfect some measure of transformation or interoperability (however meager it might be) between ODF and MSECMAXML.

    It’s great to have you back on the Q&A. Nobody interviews themselves as thoroughly and informative as you do Stephen. Come to think of it, are you the only one who does self interviews? Hummm 🙂


  4. wow – thanks for that, as always, Gary. insightful stuff indeed.

  5. The thing I wondered is: why did they buy a company whose software is written in .NET? I know there is precedent for that (Orkut, for example), but won’t it present hosting issues for them? Certainly part of Google’s ability to provide quality SaaS is to leverage their infrastructure–so do you think they’ll be porting it to run on the Googleplex, or do you think they’ll be hosting it using a different OS than their own stuff? Or renting hosting from someone else?

  6. Dan: short answer is, i don’t know, and it raised a few eyebrows around here, that’s for sure. out of curiosity, wasn’t Orkut a 20% time project?

    one reasonable line of speculation is that they were after primarily the front end, Ajax/javascript interface rather than the platform code.

    but there is certainly value in the PDF/ODF/.DOC translation capabilities Writely developed. Google could duplicate them, you’d expect, but why bother.

    anyway, with respect to your SaaS and infrastructure questions about the implications of running a .NET application on their Linux based architecture, i’m very curious to see whether or not they run Writely on top of Mono.

  7. BEA Analyst Summit 2006: Mashups, Composite Apps, Consumer Tech, and Stopping Brutus

    As seems to be the trend with me going to analyst conferences, I wrastle for some time with many drafts and snarky write-ups about my thoughts. In the end, taking a wider, industry view, as reflected by the company at…

Leave a Reply

Your email address will not be published. Required fields are marked *