The strange story of etherpad

First, we knew etherpad was more than a toy. We knew people were using it for real work. We had paying customers and thousands of dollars a month in revenue. (Not a lot of revenue, but decent evidence that etherpad was more than a toy).

Second, the relationship between etherpad and appjet is much different from how you characterize it. AppJet was a failing idea. We had like no users. We had spent over a year building this developer platform and we had practically zero developers actually using it. It clearly wasn't working. We were ecstatic when etherpad took off. After etherpad took off, we shut down appjet.com and focused our entire company on etherpad. appjet.com redirected to etherpad.com. It felt great to have a product that people were actually using!

Third, we never thought the Wave product was better than the etherpad product. However, the Wave vision was pretty awesome. Lars' narrative excited a lot of people when he delivered the announcement at Google IO '09. When we met with him, we were dazzled by his vision and the team's optimism. Perhaps we were naive.

The decision to sell to Google was one of the toughest decisions I and my cofounders ever had to wrestle with in our lives. We were excited by the Wave vision though we saw the flaws in the product. The Wave team told us about how they wanted our help making wave simpler and more like etherpad, and we thought we could help with that, though in the end we were unsuccessful at making wave simpler. We were scared of Google as a competitor: they had more engineers and more money behind this project, yet they were running it much more like an independent startup than a normal big-company department. The Wave office was in Australia and had almost total autonomy. And finally, after 1.5 years of being on the brink of failure with AppJet, it was tempting to be able to declare our endeavor a success and provide a decent return to all our investors who had risked their money on us.

In the end, our decision to join Wave did not work out as we had hoped. The biggest lessons learned were that having more engineers and money behind a project can actually be more harmful than helpful, so we were wrong to be scared of Wave as a competitor for this reason. It seems obvious in hindsight, but at the time it wasn't. Second, I totally underestimated how hard it would be to iterate on the Wave codebase. I was used to rewriting major portions of software in a single all-nighter. Because of the software development process Wave was using, it was practically impossible to iterate on the product. I should have done more diligence on their specific software engineering processes, but instead I assumed because they seemed to be operating like a startup, that they would be able to iterate like a startup. A lot of the product problems were known to the whole Wave team, but we were crippled by a large complex codebase built on poor technical choices and a cumbersome engineering process that prevented fast iteration.

I'm grateful for the many lessons learned through the whole experience. And I'm hopeful that the same software engineering and product skills that produced etherpad, combined with the many valuable lessons learned through the Google acquisition, will be able to produce even better products in the future. My cofounder David Greenspan and I have both left Google, so we are not, as you say, stuck in the vortex.

If you have more specific questions, I'd be happy to provide additional clarification.

Right. Real-time remote collaboration is novel enough to be able to say that not only interfaces need to be developed for it but also behaviours, etiquette, metaphors -- culture. You could see this with Wave. They were so desperate to hold peoples' attention that they came up with all these new and slightly silly words to help people conceptualise what it was they were suddenly able to 'do'. Too much. Too soon. Too not-for-you-to-determine.

Meanwhile an idea that anyone on the street can easily formulate (shared text editing) is still not widely available in a usable form. It's like promoting the Twitter API and ushering everyone into a new world where everything is a tweet and a tweet is everything, before you have a working tool for personal subscription-based SMS distribution. All these other 'features'... they're not. They're proposed desirable activities. Whether or not they're actually desirable is a cultural development, not a software development. Until people begin to take living, multi-author, simple documents for granted on a large scale, it's really too soon to say if it's a good thing that Bob can embed a sudoku game in the agenda draft or whether a poll and comment thread is a good way to decide where to have coffee or just a bit weird actually.

- worse features than the leading products (Google Wave, Word etc)

- simpler, more convenient, cheaper, for a new use

The typical thing to do with such a disruption is to find the customers who value it (typically, enabling them to do something they couldn't do before but want to - "target non-consumption", or "non-consuming contexts"), and make a business out of it (i.e. a low-cost business model). Then, keep improving it til it has all the features of Word etc, but retains its special new qualities... thereby replacing Word.

So... who would really need etherpad? What situation would they be in? What do they need to do? It can be helpful to imagine less skilled people than you'd normally think of; or that the nature of the task means they can't afford the time for complex setup; or that they are poor. i.e. something prevents them from using Word. Maybe, a mobile app? And I understand that groupware had a lot of promise, but didn't really take off... maybe find where it did work (in large organizations) and transfer it to small (poorer) organizations.

We were all working remotely, and we'd hop on the phone together and gather around an Etherpad and it was so easy to tell what everyone was doing (as opposed to Google Docs which had a major delay in updating the screen at that time). I'm glad to see that it lives on at hackpad and PiratePad.

Another former etherpad employee here. I just wanted to point out that contrary to the comment above, there's a fair bit of active open-source development on etherpad these days, though the folks there could always use more help. Head over to https://github.com/ether/pad and pitch in!

The UI for sharing a document (especially with users outside @gmail.com) is too complicated for mere mortals, such as me, to make work. I'm told it can be done, but it's as good as missing.

Really? Is hitting "share" and then setting the permissions to "Anyone with the link" that baffling?

http://www.subethaedit.net/

A collaborative code editor for mac.

Maybe I missed his quotes from insiders on the deal or on the current thinking of the AppJet folks. When I see this kind of thing, it makes me wonder if this whole thing is speculation that is presented more along the lines of a "What really happened" or "behind the scenes" type of thing:

"But, you see, I don't believe that's what happened. I think what happened is much more strange. I think the people who made etherpad really believed Google Wave was better, and they still do. That's what fascinates me."

He goes on to say that his research uncovered this whole thing ("See, upon further investigation, I learned that etherpad was never meant to be a real product - it was an example product."). Does he ever cite his sources? Or is the source just the comments in the HN post?

Here is how I used it to cover the startupbus: http://www.mindwallet.com/?ItemKey=787541c7-0860-41ea-a21a-2...

You probably won't use it. No one else does. :-(