Apache Wave
incubator.apache.org
incubator.apache.org
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)...
Editing existing conversations: http://imgur.com/a/GtGY6 Inline replying: http://imgur.com/a/Dkefp
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.
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.
That meant, we couldn't use it at work. And of discussion.
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).
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.
GWT should be just a pretty simple client that crosscompiles nicely to browser specific, very optimised, js.
I actually use Slack via an IRC client sometimes and there are a lot of benefits.
I don't think it's got much to do with Wave at all, but it's seriously awesome for many use cases.
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.)
(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.
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.
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.
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.
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?
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.
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.
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.
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.
Not true; arwave.org (see vids) Sadly on hold till apache gets a client protocal
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.
It's a great shame to see this dead
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.
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.
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.
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).
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.
It seemed to be a heavy user of memory iirc?
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.
Was Wave better for this use-case than a wiki?
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 never understood why, beta or not, anyone would release a collaboration tool without the ability to invite collaborators.
https://www.youtube.com/watch?v=v_UyVmITiYQ
I agree that the invite only really slowed it down.
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 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.
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.
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.
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.
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.
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.
Feel free to ask me any other questions...
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?
Still, it moves on.
Yeah, for a typical Google idea of interfacing -- you can't get Google groups as usenet, but you can get usenet as Google groups (the web front-end).
1) They have an interface to usenet so an interface via Wave wasn't (strictly speaking) necessary.
2) Such an interface could have been added later via gadgets and bots, rather than one singular hardcoded method.
Wave had amazing technology and perhaps a "before it's time" communication model, but it needed a better narrative or training step.
Have you seen/tried Discourse[1]? They do try to solve them.