Thanks for writing this. I recently started an etherpad server at work, and while it's still going to take some time to gain traction, I figure it's way easier than sharing files on the network or teaching managers to use subversion.
- 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.
> So... who would really need etherpad? What situation would they be in?
Pirate Parties use etherpad (piratepad, to be precise) to collaboratively write press releases. When you have a team of people who need to collaborate to write a document quickly, it's by far the best solution.
Good article. I set up a private etherpad for myself, friends and family several months ago. Not too much use, but I keep it running. Probably the sweet spot is local copies running for individual workgroups and maintain index pads so people can find pads by category.
The facebook integration is worth 0 to me. I want to collaborate on text, not accidentally click my avatar and be taken to my profile page.
I think the facebook integration is a waste of your development time. If you keep it, keep it only for the easy population of pic+email+username. Also, get rid of login if the pad is truly open to everyone. I'll keep using one of those other etherpad instances, since there's not much facebook integration gives me over a stock instance.
Speaking as just one guy, "log in with $service" is a bigger pain than "Sign up and log in". Sometimes I don't have $service, or I have it but don't like using it, or I have it but I don't want whatever new random thing I'm trying out to have hooks into it. (Anyone else seen in their Twitter feed a bunch of app noise followed by an apology?)
I dropped GMail about a year and a half ago. If any services I was using required it to log in, I would have had to drop them, too. I think it's mostly because I know a lot of programmers, but I do know a large number of Facebook "conscientious objectors" (myself included) who can't log in to things that require Facebook.
It's really nice to have services like this self-contained (as long as it makes sense; Twitpic, for example, would be less useful if it had no hooks into Twitter). I can pick the service up and if I don't like it, put it back down. And if I drop some account elsewhere or just change accounts, nothing depends on me having it to log in.
Just putting myself on the list as yet another person who would be trying this out right now, but it requires a Facebook login, so I'm writing this comment instead. I don't use Facebook or Twitter, and I would not be pleased with creating a permanent link between my Google account, which is important to me, to some little application that I may forget about quickly.
I'd consider an OpenID login; I already have one on myopenid.com for Stack Overflow. But I don't like the idea of logging in to a service with any kind of identifiable "persona" where I don't have strong control over the connection. I don't trust Facebook, my Google account is too important to pollute it with random site logins, while I'm afraid a Twitter login would somehow end up giving permission to Twitter DM me, which I don't want.
Unfortunately, they aren't doing anything interesting.
With all respect, hackpad has a fraction of the features of the other etherpad forks (including the original etherpad). That's not necessarily a bad thing, but nor does it give me a reason to use it over say piratepad.
I'm trying to do something similar with outlines. It isn't so much a text editor as it is a social collection builder. I call it insanely organized social media. You can call it http://MindWallet.com .
It is mire than that. But you have to read past the first bullet and that is a problem. I'm still tring to figure out what it is myself and I use it constantly.
So, for the sake of potential future features that you think people might want, but haven't yet implemented, and don't really know for sure, you make it harder for people to use it now. For the sake of making it "future proof" you put hurdles in place to prevent people from using it now.
People using it now gives you a working group of testers for new features. Don't make it harder for them.
Actually, let me be more clear. One of the core features is that we let you post to facebook directly from mindwallet. We then need to read your stream to let you know when you have new comments. The fb post and comments are given an inherent context by were in your mindwallt you post from. This extends the life of your post beyond the usual temporal stream. The perms we ask for are:
1: email to establish ownership of your mw account.
2: post to wall to let you do so.
3: read stream to show you new comments
4: offline access to show others in context comments when they look at your mindwallet.
I think I can remove friend's stream for now, but that is the only unimplemented feature.
Mindwallet looks neat. Quick feedback: the +/- signs are too small and frustrate me when I want to expand/collapse. If you made that interaction easier the navigating would be a lot simpler.
I loved Etherpad! When I joined a startup back in 2009, I pushed hard for the team to keep our information together in Google Docs, but one of our non-technical leaders stumbled upon Etherpad and after trying to tear him away from it I finally came around and realized how incredibly beautifully simple and useful it was.
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.
This story will probably get lots of votes because so many of us loved etherpad. However, this isn't the "story of etherpad", is it? Isn't this more like "What some outsider thinks happened to the etherpad team"?
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?
First two sentences: I don't actually know this story - certainly no more of it than anyone who has read a few web pages. But luckily, I'm pretty good at making things up.
Google Wave wants me to live inside it: it's presumptuous. Etherpad is a tool I grab when I want, and put down when I'm done.
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.
I enjoyed this, but I think the author wants Google Docs to suck more than it really does in order to fit the narrative; I love google docs, even if it wasn't the first to get real time collaborative editing to work smoothly.
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?
This strikes me as very similar to how DropBox has gained so much traction in a crowded space. They give you a folder. That syncs. Simply and seamlessly. Sometimes success comes as much from what's missing as what's included. EhterPad is as close to a real whiteboard for remote collaborators as I've ever seen.
Sweet write-up, I've used Etherpad way more than I've used Google Docs/Google Wave, it's so quick and simple. Not having to sign in is one of the best features. My team of 4 people use it as a huge to-do list and basically it's evolved into our personal knowledgebase. I love it, I can't imagine working without it now.
I don't want to speak for the appjet/etherpad founders, but this story is very wrong about them. They certainly did not consider etherpad to be a "toy" -- it was their main focus for quite some time.
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.
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.
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.
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.
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).
> 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?)
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.
http://piratepad.net has, for better or for worse, also continued to do a large amount of development. They didn't go toward logins, more toward licensing content, tagging content (particularly by language), and showing how content links to other content. It is getting nearly wiki-like.
Loved the story, and also loved reading notes from Aaron and David. I would just like to say that I, for one, do want Microsoft Office on the web. I use Google Docs all the time whenever a client sends me something Excel or Word format and I need to work with it. I use Google Docs to create sets of user instructions and save them as PDF, to create quick diagrams, etc. Google Docs surely lacks many features required by a good word processor, but thus far I've been able to live without them, and live without installing an office suite at all.
Where's etherpad development now? Well, it seems to have stopped.
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!
71 comments
[ 2.4 ms ] story [ 129 ms ] thread- 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.
Pirate Parties use etherpad (piratepad, to be precise) to collaboratively write press releases. When you have a team of people who need to collaborate to write a document quickly, it's by far the best solution.
I have no facebook account, I don't want one and I certainly don't create one to use your version of etherpad. No offense, just think about it...
Would you login using a Gmail account? A Twitter account?
I think the facebook integration is a waste of your development time. If you keep it, keep it only for the easy population of pic+email+username. Also, get rid of login if the pad is truly open to everyone. I'll keep using one of those other etherpad instances, since there's not much facebook integration gives me over a stock instance.
Apologies if I was a bit harsh.
I dropped GMail about a year and a half ago. If any services I was using required it to log in, I would have had to drop them, too. I think it's mostly because I know a lot of programmers, but I do know a large number of Facebook "conscientious objectors" (myself included) who can't log in to things that require Facebook.
It's really nice to have services like this self-contained (as long as it makes sense; Twitpic, for example, would be less useful if it had no hooks into Twitter). I can pick the service up and if I don't like it, put it back down. And if I drop some account elsewhere or just change accounts, nothing depends on me having it to log in.
With all respect, hackpad has a fraction of the features of the other etherpad forks (including the original etherpad). That's not necessarily a bad thing, but nor does it give me a reason to use it over say piratepad.
I'll keep using one of the deployed clones.
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. :-(
"Organize your life in a todo list."
No thanks. I don't need that.
People using it now gives you a working group of testers for new features. Don't make it harder for them.
I think I can remove friend's stream for now, but that is the only unimplemented feature.
Maybe your description isn't empowered enough? "insanely cloud enabled agile social media experience" should appeal to just about everybody.
I'm adding twitter to the mix in the next releas...maybe that will help it live up to the name.
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.
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?
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.
And you forgot Python (for those of us that prefer spaces to parens).
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.
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.
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.
I think a lot of developers don't realize how introducing complexity hurts you in the long run.
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'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.
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?)
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.
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!