> It was a schizophrenic product that couldn't decide whether it was a developer platform or replacement for email.

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.