Hacker News new | comments | show | ask | jobs | submit login

Cofounder and former CEO of EtherPad here. I appreciate your kind words about our product. Allow me to clarify some aspects of the story.

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.




Great explanation, Aaron, I agree 100%.

It's great to hear how much the product was/is loved!

Note that Wave's editor and OT really blew us away -- all of our "unique technology" was matched or exceeded in sophistication by Wave's! You could argue that given Wave's subsequent failure, we overestimated the importance of tech, but I'm inclined to think the tech is indeed a sticking point, given that no one else has matched it to this day.

An EtherPad successor would require a combination of the "simple" UX everyone loves with good tech and a business model. Somebody do it! I'm happy to share how EtherPad works.


Thank you very much. I'm curious about the engineering process slowing development down, if you're able to comment on that. I've heard before that Google's need to build for scale from the start can occasionally be an impediment to rapid development, but this is the first I can recall hearing that their process slows things down.


Etherpad is now opensource and Apache licensed. This seems to mean you could actually just pick up where you left off and start building the product again. Any plans for this or anything similar?


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

Can you tell us more about "the software development process Wave was using" and how it made it "practically impossible to iterate on the product"? It's always good to know what to watch out for.


I liked this quote: "we were crippled by a large complex codebase".

I think a lot of developers don't realize how introducing complexity hurts you in the long run.


> 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.

This is the first time I've personally read a case that specifically supports Paul Graham's tenet that big companies can't iterate like a start-up. I've experienced it outside tech, but it seems striking to me that even Google struggles here. Thank you.

Have you written a formal lessons-learned on this aspect of the acquisition process? How would you evaluate those elements? How could you have side stepped them or mitigated against their consequences (please blue sky this, eg, could you have asked to continue etherpad in-house, the way ChromeOS is sort of competing with Android?)


AppJet had so many great ideas; it's a shame you had to abandon it. Hosted server-side javascript with a web-based IDE is still a good idea.


NodeJS, github and the Cloud9ide (powered by ACE editor) is a pretty good ecosystem for this. You can run it on Joyent's no.de hosting or EC2 (or the many other NodeJS hosting services springing up).


The human factor is the most difficult integration task. Therefore, the respective leadership needs to be equip to handle the task. The due diligence should have given you the data you needed to plan it out and then you just needed to execute. What's the problem? Obviously, people are not so easy and not so predictable. So then why is it not so high on the priority list of things to address in the process?

As technologists (and those in the technology vortex), somehow it's assumed that smart people will just deal with it, do the right thing, or whatever? Whatever it is, the fact is... processes, tools, yadda yadda vortex... in the final analysis, management (both sides) failed. Now, that's not being judgmental, that is a fact, sorry. This happens all too often.


It's great to hear the inside story from someone that was there, and some great advice for anyone in a similar position.

I'm not (yet!) an entrepreneur, but I imagine I'd have done exactly the same in your situation.

I hope you made fortunes and good luck in your future endeavours.


Where are you and David now?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: