Google acquires AppJet/Etherpad
etherpad.com
etherpad.com
I was psyched when I first read the subject, since I figured they'd be lending Google Docs their awesome text editor. Instead they're going to Google Wave, where the interface blows. Etherpad's lightyears more useful, more flexible, and more valuable. Blah.
To the Etherpad guys: listen up! it goes like this, tonight, wherever you are, you're buying a round for everyone, capice?
Any big fish could have taken their client base without paying a dime; everyone from Skype to Computer Associates could have obsoleted them without even trying. Heck, Open Source IM packages like Pidgin could easily add a service like Etherpad and those boys would have labored for nothing.
If you don't like what I am saying, the next time you cash out, just know that I am just as happy for you :-)
I will have to repent and become a consumer activist: I will boycott products A/B tested on humans.
Etherpad ROCKED - I've spent a couple weeks now with Wave, used it for a bunch of projects, and every time I use it, I did so grudgingly, realizing that Etherpad was lighter, cleaner, and more elegant compared to Wave's all-in-one platform approach. Yes, it's true that I can insert YouTube Videos, Polling Systems, and even a freaking ChatServer into my WaveDocuments - but it always felt like more of a technology exercise than a useful use of an application.
Let's hope that the EtherPads can do for Wave, what the Mint Team will (hopefully) do for Intuit.
Game recognizes game, and right now I don't see much of it in this thread.
Any early-adopter of a start-up product accepts the risk that the company behind the product might be unsuccessful. Customers like that bet, in part, on the notion that despite the statistically long odds, the company is making every conceivable effort to stay alive and succeed.
The 'buyout-and-the-product-dies'-type exit introduces a sort of divided loyalty and misalignment between the goals of the founders and the goals of their customers - if you're unsuccessful you might fail and we might suffer an abrupt service termination but at the same time, if you're quite successful, we might also suffer an abrupt service termination.
These transactions trade on the goodwill of early adopters. And they make it harder for other startups as potential early adopters start to assume that it's better to wait for what Google releases instead of investing time in a product that will be scrapped either if the company fails or is successful and acquired.
I do not begrudge them making money at all. But one reason that they have "millions of dollars worth of Google stock" is because they offered a service that people adopted and paid for. I think they have more of an obligation to customers and users than the initial announcement indicated and I worry that not taking better care of customers in the transition makes it hard for other startups.
It now looks like Google has reconsidered the shutdown and EtherPad will be on-line until open sourced. http://etherpad.com/ep/blog/posts/etherpad-back-online-until...
Frameworks are pretty useless unless you have a killer app built on it.
But, the meat of Wave isn't XMPP, its the combination of Operational Transforms on a federated XMPP layer with a web interface. Each of these features is equally important, so don't overlook them. OT makes collaboration easy, the web interface is the easiest user experience, and XMPP lets you scale the backend.
This is why I hate XMPP. Over-engineered to the point of absurdity.
It really really sucks to see Google shutting down Etherpad though. We used it at Poll Everywhere quite a bit for collaborative coding, now we'll have to find something else. Any chance you could convince Google to keep Etherpad around in some form?
sigh Google kills another innovative product.
At JamLegend, Etherpad was the preferred tool for interviewing developers. Ccombined with video chat, we could meet anyone in the world.
It says it even works with Gobby.
If you want to go through several hours of compiling and several hundred megabytes of dependencies, with your fingers crossed that things won’t inexplicably break 3 hours in, feel free to try to install Gobby on a Mac. Personally, I’ll stick to SubEthaEdit, or whatever web-based editor, if I need collaboration.
* * *
I really think desktop collaborative editors should try to provide a web-based alternative front-end, for just this reason, that it’s nice for everyone to be able to contribute, and there’s no better way to ensure that than through the web.
Everytime I think about it, it seems like the perfect idea; save people the pain of setting up a server, hosting it, etc every time they want to make a web app.
Was it a bad implementation of this idea? Or was the idea just ahead of its time? Or was it something else?
Basically people aren't going to switch to a new way of doing text unless someone forces them. Only a very small minority of people use something like FreeMind or EverNote instead of Word as their primary writing tool, so how could appjet ever hope to get more than a tiny fraction of those people when their best functionality only works when you have multiple people?
The only way to get mass adoption would be to force people to use it, which is possible, but only if you design the company around that from the ground up. Which I don't think they were organized to do, at least as far as I can tell.
If Google wants to, they actually have the ability to force more people to use it. Not sure if that will happen, but I hope it does since I wish I were able to use it more myself.
I think there were two reasons it didn't succeed:
1. It's niche was razor-thin. It required some skill to use, but was so minimalistic that many programmers would prefer to take the extra time to set up a "real" server.
2. Too ahead of its time
I suspect tools like appjet will be commonplace in a couple of years. In fact, I wouldn't be surprised if the "Google Wave" thing is a ruse and that these guys are actually working on an online editor for Google App Engine... This could, in theory, turn Chrome OS into an awesome dev environment, no?
I know they were working on at least two of the four features I mentioned above before they decided to abandon AppJet in favor of EtherPad. Building their own app to prove their platform was a good idea, but I guess they just didn't have enough resources to work on the app and the platform at the same time.
I'm not sure what the AppJet guys would have considered success to be, but if they expected other companies to build commercial apps on top of their stuff I think they gave up too early.
Hopefully you can add that feature to Google Wave while you're there; It was by far my favorite aspect of Etherpad. Even thought I can copy and paste my Etherpads into G:Wave, I can't keep the history, so that'll be gone forever in March, it seems.
Does HN think this is still a viable idea if the Big G has entered the game as well?
I've been using it for my interview transcripts. With Etherpad, I can let 12 people on Mechanical Turk each transcribe a 5-minute section of my interview. And they can all be on at once and none of them needs and account.
I can even hit the play button and see how they work: http://mixergy.etherpad.com/ep/pad/view/23/latest
Frankly, the best alternative is to try to scrounge around for old EtherPad URLs and just reuse them until March. :(
Squad serves a great purpose for developers working together on code, but it isn't embedable, and doesn't do wysiwyg text formating. It's focused on syntax highlighting and opening and saving local files. So for some it may be an alternative, but not for everybody.
Goodbye Google, hello Google again.
What does that say about Google going the way of Microsoft or $any-other-big-company?
I kind of wish I'd got the private network edition and a handful of perpetual licenses before they pulled the plug though.
I also wish Microsoft had licensed Etherpad technology for use in Sharepoint - goodness knows, it could use the improvement. Google Wave must already have piles of web/ajax developers.
Edit: Parent formerly read: "...Seems like PR spin. Instead of shutting down a startup and going to work for big.co and risk being called out as a failure, work out a deal with big.co to 'aquire' the startup then shut it down. Maybe we need a new word for a talent acquisition, where the startup is shut down and just acquired as a more optimized way of hiring. ..."
Perhaps more a 'buy to kill potential competitor'?
Still sad to see Etherpad die :/
I am also curious about their distribution model (how do you provider a consistent experience if this is to run on multiple machines?) -- or lack thereof (do they use load balancer "magic" to ensure that all collaborating on a single specific session go to a single machine, potentially creating hot spots)?
(end of selfish rant, congrats btw)
I really hope EtherPad doesn't go the way of Jaiku. I really liked the product.
Does anyone have an old Etherpad that I can play with, or even just a video of how it's used?
"Edits to the document are represented as mathematical functions that can be applied in any order, and have other special properties that make this realtime."
Unfortunately I don't have the math background to really connect what that means.
--
Why does everyone assume google will destroy the clean interface of Etherpad? Why, instead do people think the Wave interface won't be customizable, since it is an open api?
http://code.google.com/apis/wave/guide.html
"""The Google Wave API is an open platform allowing developers to extend the functionality of Google Wave itself . . ."""
[Edit: Here is how I think it works, from my brief 2-day usage of it.
Comet: persistent connection between client and server.
First client connects to the server and creats a session. Server creates a "channel" with a file-handle/chan-id. Subsequent clients follow a URL to join the channel.
Without the live editing, you can see how any write in one client's textarea can be sent to the server and broadcast to all the channel members.
To allow for live editing, server keeps a "buffer" for the channel, initially empty.
All clients have onKeyPress or similar keylogging javascript event handler. A client might do internal buffering, say up to N characters or up to an X terminator (space maybe)
At the start, the server sends a test packet to each client and sees how long it takes, for timing purposes, call the time it takes to get a PONG response L for lag. So in the future, when a client sends a text snippet, it's timestamped, and the server subtracts the lag to get the actual sending time.
On the client side, display is refreshed after server response. When you type something, it's being rendered by the browser, but once your buffered input is sent, and the server responds, the display is refreshed by client-side javascript, which also keep an internal "document text model".
The server sends updates to your client's text model, and the view is rendered from this model. This allows the server to do all text-rearrangement on it side, so javascript isn't tasked with sorting time-stamped strings.
Along with timestamps, each text segment is also ID'ed by user, this allows the rendering engine to assign colors to the text.
Just wild speculation after giving this no more than 5 minutes of thought and another 10 to type it.
]