I'm thinking of the whole Apache Open-Office fiasco, among other things. Looking at their list of projects sorted by number of committers[0], event at the top I don't get the idea that most of those have a lot of momentum.
Do I just have a completely wrong impression? I'm curious if there's something to learn from this.
You have a completely wrong impression.
Projects in the wild die all the time, and the process is not necessarily neat and tidy.
At the ASF, projects must be actively retired, and there are a sequence of actions which must be taken to move the project into the "Attic". Retirement gives all stakeholders a defined close of business.
All software projects have a life cycle. What is notable about ASF projects is that the end of the life cycle is comparatively orderly.
I wish the Wave folks well as they move on to whatever's next for them.
You hear more about the ASF retiring projects because the ASF has a whole process around it that's publicized.
You don't hear too much about some one-man project that stops updating its GitHub all of a sudden. You hear about ASF projects dying becuase the ASF wants people to hear about it.
1: https://projects.apache.org/project.html?trafficserver-traff...
There's counter-examples but even they have me worried. Airflow, originating from AirBNB, is now Apache Airflow: https://github.com/apache/incubator-airflow -- And I've been super hesitant to throw weight at it because of that, even though it looks actively maintained.
The branching comments, embedded documents, and ability to create mini applets were the big selling points. But the feature were never well explained and internal implementation was a nightmare. As people could still hook in Jabber with client it was also creating issues with spamming and hacking.
They made many of the components needed to create an open source federated social networking system where separate implementations could interact with each other. So for example your user on your company's twitter/fb hybrid could have threaded conversations with other users across other organisation's fb clones (obviously with access control).
This could have been exactly the killer functionality to topple centralised proprietary Twitter and Facebook. Google should have thrown everything into it, could have turned out as impactful as hypertext.
"Over the years, I've become convinced that the BSD license is great for code you don't care about" -- Linus Torvalds
https://www.cio.com/article/3112582/linux/linus-torvalds-say...
It really was a Frankenstein; I distinctly remember threaded conversations that wouldn't collapse, weird and inconsistent results when contributing to the same "wave," and an interface that was honestly pretty awful (not to mention cramped on the screens of yesteryear). There's more: Google wanted to create a protocol but the tech was invite-only (???), it wanted to replace email but no one else adopted it. The whole thing made no sense.
But after watching the Google I/O talk, I was enthralled. I thought to myself "I bet I could build that!" And really, even if Google Wave failed horribly, it did contribute to the "real-time" web we all enjoy today.
Email is the ultimate killer app and ultimate whipping boy.
The UI was a GWT app written in Java and compiled to JavaScript which suffered from inexplicable UI hangs and all kinds of weird bugs in every corner case (it would e.g. get stuck in states requiring a page reload to fix).
The “communication protocol” was opaque binary blobs of GWT stuff wrapped up in Jabber/XMPP (XML) but without really using most Jabber features. Basically not a designed protocol at all, just the most ad-hoc thing slapped together overnight, with XMPP used as marketing (because that’s “open”).
The server was some closed source thing only hosted by Google.
The original marketing claim was that this was all “open” and “federated” but it was not possible to run a third-party server, and it was not possible to implement a different front-end since the whole thing was coupled tightly to the GWT front end they had.
The big innovation was supposed to be that some fancy “operational transformation” magic would merge different users’ diffs so that everything could be edited collaboratively in real time without conflicts and with minimal bandwidth, but in practice what that meant was they just sent the full content of every message on every keystroke (where “full content” here includes a massive amount of protocol overhead wrapping the messages) – maybe the fancy diff research stuff was intended for some future update that never made it.
The front end really started falling apart horribly (slowing down to the point of being unusable) under any kind of larger group, because it hadn’t been architected to keep up with the load. From what I remember it mostly worked with about 2–10 people communicating in a group, and became entirely unusable with 50+ in a group.
Disclaimer: I was never a Wave expert, just some guy who tried to read their docs and play with their technology and ended up laughing and sadly shaking my head all the way through, and it’s been a decade now. Some of my recollection could be slightly off.
So, the same reason Slack is now failing miserably I guess?
In other words, it was Lotus Notes 2.0.
One of these days, someone's gotta make a Lotus Notes 3.0 that actually makes good on the original premise, without screwing it up by adding too much other stuff (like Lotus+IBM did) or by forgetting what the problem being solved is (like Google did.)
The original premise is pretty cool, once you see through to it. Notes did two important things:
1. Notes takes email message bodies and turns them into, essentially, the initial response-bodies of (gradually-enhanced) HTML5 web-applications. Each message body contains a common "program"—which may or may not require any bandwidth to deliver, depending on whether the receiving server already has other copies of it—and then, along with that program, it contains some initialization data customized for the recipient (like the initial response-body HTML in a gradually-enhanced webapp.) Your mail-reader becomes equivalent to a modern web browser (i.e. it's a zero-install application sandbox), except that there are no URLs—instead, you get pushed new pages [or new versions of pages] by other people, and then they stick around in your "cache" (your inbox) until you delete them.
2. Notes then gives those little email applets persistent "cloud" storage, in the form of Firebase-like synchronization to tiny per-applet databases that live on—or next to—the message author's IMAP server. (Notes' applet database server is called Domino, but it was essentially just Firebase's API backed by a bunch of BDB DB files on a disk—usually on the same machine that the IMAP mbox files were held on.)
Together, that meant that you had a federated, vendor-neutral method of composing little applications like straw polls of what to get for lunch, or interactive infographics with live source data. Each applet's program would travel around by regular email; and each applet's data would be canonically on the applet-author's mail-server, but would be synced with anyone any time they opened the applet message. And then, along with that, you also get federated, vendor-neutral, PKI-keypair-based ACLs giving identity to every read or write, enforced by the applet DB server, that applet authoring software could then turn into simple access control settings for each Firebase-like object type.
Wave took the whole distributed infrastructure of Notes and puts it into Google's cloud, but without any of the federated/vendor-neutral/client-synced stuff that was the whole point of the design. You got the same essential architecture (applets live inside messages; applets get shared cloud backend storage; the system syncs the state of "your" applets to local storage), but you no longer got any advantage from it: since you were talking to a cloud that could run arbitrary compute anyway, anyone in an enterprise who wanted to "author an applet" could just write (or rely on authoring software to generate) a little Google App Engine app, which would store its data in Google Cloud Datastore and use GSuite OAuth for login. All the same benefits, but now it's just a web-page. Open it in a tab, bookmark it, whatever. No need to push the app; just email people a link to it.
The federation protocol is described in http://googlecode.blogspot.com/2009/05/hello-world-meet-goog...
Syncing is described in https://svn.apache.org/repos/asf/incubator/wave/whitepapers/...
It was also every bit as buggy and confusing as Lotus Notes.
Wave helped sour me to hyped ideas. Reader made me bitter to even attempted google+. To the point that i forget google+ still exists quite commonly. I almost feel guilty that I don't know more about it.
(Which makes it all the more appropriately ironic that it had a bunch of Firefly references and easter eggs inside. It's like they knew.)
Anyway, I'm pouring one out for Wave tonight.
- That communication could be both synchronous (like chat) and asynchronous (like email) and you could use whichever worked best for you at the time. You could even switch in the middle of a thread- maybe it stared out asynchronous, but then both people were online and decided to have a conversation.
- Threads were a better way of breaking up topics than channels
- The ability to post a document and then have people comment on it let you basically incorporate Google Docs-style document revision into your chat application, but like the other comment says, the comments were a first-class citizen of the interface, rather than bubbles that are totally out of context
- I like real-time chats, where you could see the individual characters the other person was typing. This, admittedly, is an aesthetic preference I know not everyone shares.
I also like that comments were a first-class citizen; part of the document. You could have an in-line conversation about a paragraph, then distill the results into the text and delete the conversation. Comments weren't another "mode" like they are in Google Docs; they were just document bubbles nested in a parent document bubble.
I've apparently flip-flopped on this; looking at a post I wrote at the time, I thought it felt wrong to delete comments.
Also, somewhere in there is a quote by the project lead that I still remember today, something like this: "There aren't many companies that can afford to mess up a demo. [pause] We're not one of them." The last part sounded like a panicked attempt to backpedal on what he just said.
My organisation desperately wanted to use this, but since invites were limited and rolled out slowly, we couldn't, since you can't have half of the org using a collaboration tool like this. So the initial buzz about this was killed quickly when no-one could use it for any serious work, then once it was generally available, people had lost interest. Google has a habit of botching roll-outs like this.
Google Docs in its current form has a lot of features that were in Wave, and people seem to like and use that.
They should be commended for ushering in a new vision for what the web could do. So much tech in there that is now considered standard.
As a product, it didn't fit a real purpose and was trying to do to much, but it should be remembered for opening our eyes to what was possible.
Tonight I'll raise a drink to all those who committed time to Wave and showed us the way (and I'm in Bondi, if anyone is around and wants to meet-up).
"Google Wave Drips With Ambition. A New Communication Platform For A New Web."
https://news.ycombinator.com/item?id=630427
Top comment starts out
> "This is silly, it doesn't account for the many, many axes of communication."
what was smooth you ask? I never had issues, I even played people in some of the games they had to great enjoyment (was never able to get this on my WIAB)
I joined Apache Wave with great excitement when it first was accepted and yet disappointed in my inability to contribute. I am not a software engineer but I tried multiple times with different IDs and the response was (paraphrasing) go check this site and pick something to work on.
as the years went on multiple attempts were made to retire Apache Wave with last minute efforts by multiple people trying to keep it going. I knew this day would come and it is still sad to see.
I am not sure if there was a better 'onboarding' for noobs available if I would have done much but I think many open source projects may fair better if their barrier to entry for them were clearer
This is the way Wave ends,
Not with a bang but a whimper.
But that's how the world goes sometimes.
git clone http://git-wip-us.apache.org/repos/asf/incubator-wave-android.git
git clone http://git-wip-us.apache.org/repos/asf/incubator-wave-docs.git
git clone http://git-wip-us.apache.org/repos/asf/incubator-wave.git
Wave is one of those things that everyone raves about but has never used.
It was really cool stuff.
Fundamentally, there was no way to persist the data. The open-source version was little more than a demo.
At that point I realized it was mostly hot air, said so at the wave meet up I was going to, and then stopped paying attention.
I missed the entire wave thing. Don't know how or why. But I just missed it. And I never ever miss these kind of things. My job at the time was consulting and advising startups and I just looked silly when "wave" came up in a meeting and I had no idea what it was.
I remember the CEO saying "You didn't see the video of the developers cheering with their laptops above their head?" ... which I did not.
It's one of those things that comes back to haunt me when I can't sleep. You know, one of those awkward social interactions that nobody but yourself remembers.
So good bye Wave. Bane of my existence.