The crucial tactical error the Wave project made was not integrating with existing systems like email and chat. This forced people to either jump fully onboard with Wave or ignore it. Predictably, when faced with an ultimatum like that, everyone just kept using email (and IRC and wikis). If the Wave team had instead spent a fraction of their development efforts on seamless integration with email, IRC, and other relevant protocols, even at the cost of some simplification of Wave itself, the project might very well have been a success and more advanced features could have been added later once adoption picked up.
I think the invite only beta hurt it more. I got in from a random redditor, but no one else I knew was in it, so I played with it for 5 minutes and then forgot about it.
Spot on. When GMail was still in Beta, and you didn't know anybody else on it, at least you could still send and receive email with the rest of the world.
also gmail gave you 5 or more invites so you could invite your friends. Wave should have done the same. It would have allowed small social networks of people to play with it together.
As I recall, I had several invites when I got in. The problem was that those invites went into a queue, they were a lie. With gmail (at least when I got to it), my invites were sent out immediately and the recipient could start using gmail that day. With Wave, my invites were queued and when Google felt it was time they'd send it out. This could be days or, in at least one case for me, weeks later. By the time I got enough people in to give it a shot, only myself and the most recent were interested in trying it.
Well, even though many if not most of my friends ended up with an invite (and we made active use of Wave), that didn't make it a success: the client was just too slow and laggy. It basically only worked in chrome, and poorly there. Large threads were simply unusable.
I don't think the closed beta-ness of wave really hurt it. If wave had actually worked well, then maybe there'd have been a point where it was worth opening up to many users - but wave never got there, so it's a moot point.
This is very true for a collaboration platform. I wanted to use this for school to collaborate with the groups there. If 1 person of the group did not have Wave, we couldn't use it.
In my experience, Google+ is a great place to find passionate communities of small niches. Tabletop role-playing games, for example, have thoroughly adopted G+.
Google+ falls down for mainstream users, though, which is where the "no one here" perception comes from.
If memory serves, Google Wave was the same way: great for the people who used it, but the value wasn't perceived by the majority.
From my standpoint, I would have used Wave in a heartbeat in my work environment, but there was literally no way to prevent any user in a Wave from adding Public whenever they felt like it.
That meant, we couldn't use it at work. And of discussion.
This is specific, believable and (most importantly) falsifiable advice. Hopefully Apache Wave developers will consider this seriously and, after implementing email & chat integration, review post-implementation adoption rates
There has been some work on integrating Wave with email (initially as a way of using Wave as some mailing-list replacement tool). See WAVE-70 (https://issues.apache.org/jira/browse/WAVE-70).
Chat integration is arguably simpler - and Wave already understands XMPP (for federation), so it would be possibly to map Jabber -> Wave (say). How you would want to map from Wave -> Jabber is more complicated (as any blip at any point in the tree, can be edited at any time, by anybody)...
I'm pretty sure that the Wave project already spent all its credibility. When something is hyped that hard and fails that spectacularly, it doesn't tend to get a second chance.
This was not a crucial tactical error, it was a deliberate gamble.
Disruptive communication is hard, and they lost this gamble. That does not make it an error :)
(Snapchat, Whatsapp, etc, all are things int he "must fully jump onboard or ignore it", and they've done fine, because they are incremental improvements that are less disruptive).
The current Apache Wave code base is a vast complex tangle (GWT wasn't the right decision, I doubt web sockets was either), and there's virtually no life on the developer list.
To be in any way seriously useful, this should be reimplemented as from scratch with a strict separation of UI and wave server back end, with a massively simplified deployment process. (Go would be a good choice imho).
The ideas behind wave are interesting, but the technical debt that Google dumped out when they abandoned wave is so massive, I consider the current wave code base a completely lost cause.
Seriously; interested developers drop into the mailing list form time to time; look at the code base, then run screaming. The reports barely even get done.
I agree with this. I wanted to add OT to one of my projects and checked it out. Couldn't get the head or tail of the code. So opted for ShareJS instead.
GWT reduces complexity for this sort of thing imho - the complexity comes more from the way the client and server code are tied all together, the rather excessive abstractions and factory processes, and some legacy stuff.
GWT should be just a pretty simple client that crosscompiles nicely to browser specific, very optimised, js.
There's a team of us who got gifted a Slack instance, as we're building on the released assets and partial source code of Tiny Speck's previous project (an MMO called Glitch). It's seriously amazing, supporting us as a volunteer group brilliantly, with full searchable logs, long-form "devlog" posts, inline images, and integration with the other systems we use.
I don't think it's got much to do with Wave at all, but it's seriously awesome for many use cases.
You are correct that we have been incubating since 2010 - the community around it has changed quite a lot since then though...
There is no roadmap, as we do not (yet) have a large enough consistent amount of developer power to benefit from one. Most of the patches we receive are fixes/improvements that benefit the submitter (e.g. full text search, monogodb backend, etc.)
I agree, prior discussions on the mailing list have been unable to resolve this though. There are two directions in which to progress:
1) Convert the project to be primarily about the federation protocol (which was the original direction of FedOne), with the existing client being a 'demonstration' implementation of the protocol. This sets our market to be other developers.
2) Be client specific, extend the existing client, add mobile support etc. Setting our market to be users directly. 'The next communications platform'.
(2) is what we have been mostly doing for the last couple of years, but our Java6+GWT+Ant+Subversion (only recently switched to git) stack was failing to attract new developers. There were several calls to rewrite the entire thing in (say) javascript.
It seems pretty clear to me that option 1 is by far the better one. Open source projects are great at creating protocols.
However, they are exceedingly terrible at making consumer products. There's a lot of branding, marketing and design that goes into a successful consumer product. This is especially true for a product with network effects. Open source projects are bad at this for several reasons:
* People with these skills are simply not as likely to be involved in open source projects.
* Developers will create features that they want. This is great, but what a particular developer wants is not necessarily what is best for the project.
* Any one attempt at a consumer product will likely fail. The work you could have put into a protocol that would have made hundreds of consumer products easy to build has now been sunk into one, which may or may not succeed.
Also, specific implementations will become dated very quickly. Your stack sounds horrifying in this day and age. With server modules in a few different languages, and a minimal clientside library, there would have been hundreds of Wave variants at this point.
Rewriting the client sounds like an awful task, but it might be necessary. I think I liked wave, but really have no interest in trying to get that online. If it was a stack I knew ( Rails ) or a stack I knew would be nice to use ( Flask, Node ) I might be interested in getting a copy online and maybe contributing.
Just for curiosity's sake, let's say I wanted to write a REALLY bare-bones Wave client. Like, maybe just doing text-only waves, maybe not even real time. How hard would that be?
A client written for emacs in emacs lisp. I haven't looked at it in detail and it doesn't look like it's been touched in a while, but it may be a good place to start. I don't know if this was the same client, but during the initial Google I/O demo they had an example that I believe was using emacs. Timeline would fit with both when this was made and who made it.
I have been wanting to do this for ages...but without a established client/sever protocol its a nightmare.
And GWT is fine, I love GWT, but the current codebase has the current client and sever tied together you cant work on one without the other!
They badly need to separate them out, establishing a protocol in the process.
Back in 2009/10, we ran our startup primarily on Wave for several months. Several of us found it very useful; I thought it was a promising combination of email, Google Docs, and chat. On the other hand, the usability was horrible and it was ridiculously buggy; several people hated it with a passion.
I can see why Google gave up on it but it's disappointing that they haven't incorporated these ideas into other products. And it doesn't seem like Apache Wave ever gained enough momentum to move forward.
What other projects are looking at similar chat/email/collaborative editing hybrids?
I think Google did incorporate a lot of this functionality into Docs - multiple users editing the same doc at once is pretty close to the functionality I wanted from Wave, and I've used it multiple times to great effect.
Agreed that the collaborative editing from Docs is great, but I believe Docs already had that functionality before Wave.
The kinds of things I was thinking of is that there aren't any "subsections" in docs (comparable to Wave's replies); and Docs still isn't a "container" in the way that Wave was -- you can't embed a poll, for example.
My opinion of where Wave went wrong is that it was completely non-extensible past a couple of fairly limited extension points. You couldn't build brand new real-time applications on top of Wave.
What they should've done was simply expose their real-time technology stack, then let people create documents backed by whatever (sandboxed) Javascript they want. When you open a wave, the Wave client would download the relevant Javascript, then use that to generate the user interface for the document, while managing the complexities of operational transforms and federation itself.
Yes, pretty much, but that'd have to be combined with some sort of "sharing", "inbox" and/or "following" system like Wave came with. Perhaps email could be hacked into being that, but then we have the issue of "what happens when the service provider goes down" - Drive Realtime doesn't provide automatic saving of the Javascript that I can view and edit my document with, likely ending up relying on a third-party not to go down.
I suspect that it'd be "easy" to build an MVP of what I suggest on top of Google Drive and Google Drive Realtime, or even on top of some of Wave's internals.
I thought the server was open source running a documented protocol? I never got to close to it other than playing with the client. I recall considering installing the server - May be misremembering though....
There were two protocols. One used internally by the Google Wave server, and a federation protocol based on XMPP.
Extending waves could be done with gadgets and bots. Bots were essentially XMPP clients that could observe the wave and submit changes to it [1]. Gadgets had other utilities, like introducing features to a wave document. I can't remember any particularly interesting ones, but some simple ones would be dice rollers and polls.
[1] I played with a clojure REPL bot at one point, neat concept and I liked the idea for a collaborative way to teach someone how to program or pair program. I toyed for a time with exposing a common lisp REPL (I didn't get far) to create a collaborative worksheet-style interface. Since the underlying technology was language agnostic I thought it would have been neat as a way to integrate a number of different interactive languages.
The issue is that the protocol pretty much only let people implement feature-for-feature compatible Wave servers. It wouldn't be possible to extend it past that.
I used Wave quite a lot, it was great to arranging meet ups of groups of people as you could all have an active conversation and use the "Poll" widget to say if you where coming or not.
I also used it for other things, but organising groups of people was the main use. Once it was discontinued I tried to run the open source version, but it was never really that stable and in the end we swapped back to emails.
Yes, it was really great for organizing groups of people. My campus ACM chapter used it instead of email when we were setting up a new computer lab, and it was one of the best experiences I've had with a piece of collaboration software.
It's main problem for us was that large waves tended to get slow on our 2007-era entry level laptops, and nobody really wanted to maintain the wave by deleting unimportant chit-chat. Some sort of decay mechanism to hide old, irrelevant blips would have been nice.
I used Wave on a number of projects as well as some of the biggerish discussion "waves" back when it was still with Google.
For the projects, it was awesome. This was a long time ago, so I don't remember all the excruciating details, but it made coordination and collaboration on big documents pretty trivial. We also had some group messaging and file-storage accounts that went virtually unused because of Wave.
Our use-case was in writing large-ish documents (a few hundred pages each) as a committee. And it was pretty trivial to just create a wave for each section of each document, then use top level comments in the Wave for each subsection, and capture everybody's brainstorming for each section. It was like a living collaborative outline that eventually filled itself in and turned into a section. We used links off of the discussions into Google docs for collaborative editing of the documents and when we felt everything was good, somebody would simply go in and copy-paste all the text into master good doc for final cleanup.
Having worked on similar projects in the past, coordinating this kind of activity with email and word docs (or even google docs) is a huge PIA. When we decided to move it to Wave for a small trial (to figure out the workflow) it was pretty trivial and sort of worked naturally. There was a minimum of document syncing issues, or confusion about who said what in which meeting or email. The entire past history of discussion, with threading and everything was open for review. It was amazing despite many of the obvious issues with the Wave client.
The big discussion "groups" on the other hand were mess. It was impossible to find where new comments in old threads were posted, and once the conversations got big enough, the UI slowed to an unusable mess. Wave didn't last long enough for anybody to figure out how to deal with this.
Outside of those two use-cases I really didn't use Wave for much else. I suspect I would have found other uses as time went on if it had survived (and especially if it had flowered and federated).
I've thought long and hard about why Wave failed and it really does come down to 2 things:
- lack of focus
- poor user experience that never seemed to get any better
Wave tried really hard to be all things to everybody, with some really neat tech demos to show use cases (arranging a group meeting by embedding a poll and a map etc.). I think it was kind of like the C++ of communication mediums. It's sort of everything, but you can only realistically use some subset of the functionality in practice and the parts you don't use just end up seeming useless and weird.
On the user side, carving out just the functionality for your use-case was also hard. And the slow as syrup client really was a huge turn-off. Weird, non-standard scroll bars everywhere (which never got fixed and never worked like anybody expected), nobody liked real-time global echo as they typed (brought about by a confusion of how IM actually worked in practice), and way too many half-baked widgets and bots and things.
I think Wave should have simply focused on a few simple use-cases, nailed and refined those, then grown all the other awesome ideas organically so the user-community could start to slot those into their workflows.
Wave might have worked better if it was launched simply as a threaded messageboard with real-time replies showing up in a post. Users would have also needed 1 more layer of organizational abstraction, a "Wave container" to carve out different groups of Waves. In my use-case above we really needed to have a container for each document, with each Wave for each major section. But in the most general case, a "pg" type person could have created a "Hacker News" container, and each submission and comment history would have been the individual Waves.
When Wave launched, everything was a wave and there was no way to organize them, so people ended up using top-level comments in the waves as the "topic submissions" and the Waves went on for thousands of comments across dozens of topics before they started to break. It just wasn't a good organizational metaphor, but the system and the client didn't offer a good alternative.
Then the client was clunky and slow, nothing else on the web felt as slow even with such little graphical sparkle. It was basically a side-by-side email client by look, yet acted like it was folding proteins or mining bitcoin in some worker thread.
> The big discussion "groups" on the other hand were mess. It was impossible to find where new comments in old threads were posted
Funny, this is the exact same problem I see with google+.
We're using hangouts to do some cross-continent roleplaying sessions, and g+ is a natural fit for having a discussion group/notes -- unfortunately it has horrible mail notifications (you get a notification, but not the content of new comments) -- and is pretty buggy (with posts randomly disappearing when you're accessing g+ across devices).
Having a few parallels discussions is almost hopeless -- and this is just within one "community". I couldn't imagine using it for anything involving more than a handful of people.
I recently started using trello for RP group discussion notes stuff. It's amazing for this, and has well polished apps for phones and tablets too, so you can pull up your notes on an ipad in the middle of a session if need be.
This is very recent (last few months), and it's the first time ever using trello for any of us, so we don't really have a solid workflow yet, but we have lists for each character, and another for plot-points, etc.
We also have a "GM questions" list for things like "Can I use expansion ruleset X" or "I have an idea for a new Y for your approval" or "How do you house-rule Z"
We are just getting ready to startup a new game, and I've been quite impressed with how it works during startup. In a typical game I've played in the past, characters will get joint backstory when two players are informally talking about their character concepts. With this, players can draft their character concepts in a shared space and I've seen more joint-backstory than typical (though not quite as much as when all players lived on the same floor of a dormitory in college, but that's a level of intimacy most groups don't have).
For dedicated roleplaying, I really like Roll20. It's specifically designed for that, and I've used it for several different groups, both from the DM side and the player side.
Roll20 looks interesting, not sure how well it would work for our mix of "play-by-mail" and video sessions.
I'll have a look (and at Trello too) -- but I lean towards something I can self-host if I am to make the effort of dragging the rest of the group away from g+/hangouts in the first place.
roll20 is great for managing the actual sessions of any table-top oriented game, but I find external tools to still be useful for between-session stuff.
"Then the client was clunky and slow, nothing else on the web felt as slow even with such little graphical sparkle. It was basically a side-by-side email client by look, yet acted like it was folding proteins or mining bitcoin in some worker thread."
IIR it all written in Java then compiled to Javascript, I think using an old version of GWT. I was not a good showpiece for the technology. It was like stepping back in time to the early Java days with a pre-JIT JVM and slow computers.
> Our use-case was in writing large-ish documents (a few hundred pages each) as a committee. And it was pretty trivial to just create a wave for each section of each document, then use top level comments in the Wave for each subsection, and capture everybody's brainstorming for each section. It was like a living collaborative outline that eventually filled itself in and turned into a section. We used links off of the discussions into Google docs for collaborative editing of the documents and when we felt everything was good, somebody would simply go in and copy-paste all the text into master good doc for final cleanup.
I was a fan, and worked on a book project with a collaborator using it. The UI was a major obstacle, so slow and clunky, and I could never see what it was doing that required it to be so.
The concept of it, though, was awesome, and we still talk about as something we'd like to see work well. Maybe this version will go somewhere.
I created one of widgets that launched with Wave to use VOIP services to make a conference call from inside the gadget.
Part of me wished it stayed because I had a single letter user id.
Anyways, meeting minutes were something that it did well in my observation. Liveblogging was also interesting with it especially if you had maybe 2-3 editors and everyone else was view-only. Live tweeting events is rather feeble compared to what could have been done with Wave.
I remember when Google Wave was hyped up to the point where people were begging others for a beta invite. When I first got access, it seemed pretty interesting but oddly enough, nothing really motivated me to use it again.
That whole "begging for an invite" thing was, in my world, the reason we couldn't use Wave. When you have a project with 10 people, and 3 of them can't get on Wave... it's game over. Back to email/IM/whatever.
I never understood why, beta or not, anyone would release a collaboration tool without the ability to invite collaborators.
I mentioned this elsewhere, but invites were queued. You had 10 invites and you could send them all out the first day you got into Wave. But it might have been days or weeks later before their received their invitation. Mine came 2 weeks after a friend invited me. My sister's arrived a week or so after I invited her. This killed the momentum, it took too long to build up the social network which this system depended upon.
> Allthough Googles own server was never released as Open Source itself, they did release “FedOne” as a reference implementation of it. It was open source, and allowed people to both run and federate their own wave servers together. It did not connect to Googles main “wave.google.com” server, but did connect to a special “sandbox” server allowing testing of the protocol, server and clients.
What idiot greenlighted that feature? :P
"Yeah let's make a distributed social network but don't let them connect to the one EVERYONE IS ALREADY ON"
I remember back in the day people would kill for a Google Wave invite. It felt like all the cool kids were using it and if you weren't on it, you meant zero. When you actually got on it after reading all the praising reviews and begging for invites on googlewaveinvites.org or whatever shady site you stumbled upon, it was a massive anti climax. Sure, it looked really good but it felt so... I don't know... void?
I think we all just wanted to be part of the "Google Wave croud" and the hype was more of a focus than the actual product. Thinking about it, I don't even remember what Wave actually was or why Google dismissed it.
> Wave a real-time communication and collaboration tool.
Serious question: Am I a bad person for closing the tab as soon as I noticed that the first sentence is missing a verb?
Programming is all about details, and I guess I see it as a strong signal if a project can't get details right on their landing page.
On the other hand, maybe this unfairly biases me against projects maintained by non-native English speakers. And even among native speakers, perhaps I shouldn't be biased against people who choose to spend their time on pursuits other than writing perfect English.
You're not a bad person. Actually, I like that you question your decision, though that's probably confirmation bias because I use the exact opposite of your heuristic.
As I view it, any project has finite resources. You can spend them on your presentation or you can spend them on the product. Every hour that you're spending fixing typos on the website is an hour that you're not patching bugs in the code. Thus, when I encounter a beautiful, well written, well designed site, I mentally note that they've taken a lot of resources away from the product and caution myself accordingly.
Obviously my heuristic has a significant flaw - it assume that all projects have equal resources. A project with less resources can have lousy presentation and lousy code while a project with abundant resources can be exemplary in both categories. That's why I don't use it as my ONLY method of advising decisions.
However, your method also has a fatal flaw. Imagine that you're right and that the source base is an incoherent mess. It's pretty cheap to hire a couple of grad students to clean up the text on the page. They haven't done a damn thing to fix the mess in the code, but your heuristic now gives them an all clear.
> Obviously my heuristic has a significant flaw - it assume that
> all projects have equal resources.
Indeed. Perhaps my heuristic works for open-source projects because, if a project is "important" enough, some nutcase like me will come along and either complain about or fix their webpage. If the first sentence of their webpage has an obvious typo, that's a signal that maybe there aren't enough people who care about the project.
Strangely, every one of the links in the downloads page has 404'd for me. I was quite disappointed to see Wave die, since I think it was both incredibly forward looking on Google's part and, all things considered, immensely useful. I wish it could have become the email replacement it wanted to be. It suffered greatly, though, from higher latency, intermittent bugs, and lack of (very) widespread adoption.
Disclaimer: I work for Google, though did not at the announcement, nor cancellation, and my views are my own, etc. etc.
I managed to get into the beta, and was so excited about the prospect. I think one of the most serious problems at the time was scaling... A conversation with more than about 5 participants was just plain unusable due to how slow it was to update and display.
It has been five years, however, and computers have gotten much faster. I tried the test server, and while it has some display issues (flashing boxes during updates, etc.), it is very fast, and quite comfortable to use.
I think the only problem at this point is a social one... I can really only imagine two scenarios where this takes off. 1) The non-federation case gets incredibly compelling (e.g. if for internal company collaborated editing) and eventually there's so much use, people start setting up federation. 2) Niche (meaning targeted, not meaning inconsequential) federated use becomes common (e.g. if open source communities were to switch to this en masse in place of listserv), and people get so accustomed to using it that outside organizations start picking it up.
I'd love to see that happen, but at this point, I'm not holding my breath.
I would not be surprised to find out that many open source communities would love to switch to a better list software than Mailman. It would need to work well for the main list use case of course - so that switching would cost nothing and people could connect to the waves in their own time.
Sorry about the downloads page, you saw the page as prepared for an actual release - I have rolled it back to showing the last release candidate presented on the mailing list.
I liked Google Wave, and really liked being able to write software robots on AppEngine that joined waves like humans, and could read and write to waves. Potentially a nice platform to develop for, until Google Wave was cancelled.
I have run Apache Waves a few times, easy to set up and the simplified UI is very nice.
What I am missing from Apache Wave is a platform for writing software robots. Does anyone know of any useful options for this?
I always wondered why Wave was not intergrested with Usenet as could of brought usenet into the modern World interface/interaction wise. Beyond that it reminded me of many Web 2.0 Nortel project, great technicaly but pushing the resource boundaries of the time. Hence had its sluggish moments, as in on a fat pipe was great, but consumer pipes was meh.
Google has Google Groups which interfaces with usenet. Also, the nature of "waves" doesn't fit with threaded communication model of usenet. It can be made to work, but you'd need many waves/wavelets to accomplish that, and going back and editing previous stuffs would create a confusing set of messages on Usenet. Would you post those to usenet? Post it by replying with a diff? It'd require a very different model. Far easier to integrate standard web forums with usenet (which I, personally, think would be awesome) than what Wave had. It was really designed around a collaborative document model. Would've been awesome if the invite system hadn't been so clunky, and the year delay between announcement and when my friends finally got access just killed any momentum at the time (for me).
At Mindcamp in 2009 we had a session to try to figure out how/why to use Wave. We tried to use Wave to facilitate said conversation. In my opinion, it was a wash.
Wave had amazing technology and perhaps a "before it's time" communication model, but it needed a better narrative or training step.
