Yesterday I was a bit hard on Ray, but only about baseball. I want to be clear about the fact that he's still one of the people in the industry that I hold at the highest level of respect. And to make that point, I'll reproduce a comment that I just made over on Ed's blog. James Governor, surely one of the better analysts in the business, had posted a comment about replication conflicts in Notes and what he wrote really surprised me. Here are the relevant parts.
i guess I have a contrarian view on this.
my first experience of Notes replication was back in 1995. it sucked. the content locking was non-existent. basically if you opened a file someone else was working on it just created a new copy and you had to deal with it. so much for locking and management.
imagine my surprise then when i first tried Groove just after its launch, and discovered exactly the same bug. where was the version control?... [snip]
maybe its unfair to judge Ozzie on this one factor, but he was the uberarchitect in both cases, and content locking and replication does seem a rather critical function in a "collaboration platform". i am more than willing to be convinced otherwise, but it has always seemed an important point to me. Lotus became more interesting when rearchitected as a fundamentally-based server platform.
Yes, James, it's definitely unfair to judge Ray on this one factor. Even if he were wrong it would be unfair, but he wasn't wrong. Here's the response to James that I posted on Ed's site (very slightly edited here, mostly for form not content.):
One needs to have a sense of history to appreciate replication conflicts. Ray and his colleagues at Iris made a lot of brilliant compromises just in order to make it possible to have a product at all. I worked at one of the large mini-computer companies at that time, and collectively the offerings from DEC, Data General and Wang -- along with IBM's PROFS -- defined what was then called the Integrated Office Systems market. I was part of an architectural team that set out on the course of building a client-server system, and we were unwilling to make the kinds of compromises that Lotus did. We wanted locking. We wanted a consistent security model top-to-bottom. We wanted (believe it or not!) an abstract object model for structured and unstructured data that would run on top of any relational database! We didn't compromise and we didn't ship product. Ray did compromise, and Lotus Notes became synonymous with collaboration.
The very thing James dislikes was one of the most brilliant things Ozzie did. By realizing that conflicts are the relatively rare exception case, and by not building an architecture that depended on a complex and (with the technology of the late 80s) inherently unreliable locking scheme, he made collaboration possible. Back then, a globally connected always-on corporate network was the exception, not the rule. Even in 1995, locking simply could not be considered a pre-requisite to collaboration when users were dialing in from 486 laptops with 14.4K modems, and the biggest servers only handled a few hundred users and in many cases talked to each other using 28.8K modems over switched long-distance phone lines. Without the architectural provision for creating and managing replication conflicts when they happened, Notes could not have existed and collaboration simply could not have gotten a foothold in business computing.
Note that this in no way diminishes my respect for James. I don't think he's really unaware of the history behind Notes replication, He's just being something of a purist. With today's connectivity and technology replication conflicts do seem like a bug rather than a feature. Current versions of Notes do, in fact, have support for locking -- but it's not automatic, and when disconnected replicas are involved the best that one can do is get a "provisional lock", so the replication conflict lives on. It will continue to live on as long as there is support in Notes and Domino for disconnected use.
At the very first Lotusphere (or maybe the second, but I think it was the first), Ray gave a speech that I still remember in considerable detail. He talked about "the socket", and he wasn't talking about the abstractiion that the Berkeley Unix guys invented and every TCP/IP programmer knows about. He was talking about ubuiquitous worldwide always-on networking. The socket would be there in the armrest of your airline seat. It would be in the coffee shop. It would be in your home. It would be in your car. You could, and would, always plug in. You would never have to do your work disconnected. Ray foresaw office networks in the early 80s, and in the early 90s he foresaw networks everywhere. It took ten years for Ray's vision for office networks to become widespread reality, and it's taking a little longer for his vision of the socket -- mutated into ubiquitous wireless -- to come to fruition. We're getting pretty close with the technology, but there's still a few more years to go on it, and probably a few more still for the business models to shake out. For example, just last week I was in a hotel where I had wired broadband in my room, but I couldn't actually do the work I neeeded to do because the system wouldn't let both my laptop and the virtual machine where I was doing the work on share a single connection -- an artifficial technological limitation put in place for economic reasons. Once we get there, a few years from now, then the more pure approach to collaboration that James has in mind will be possible all the time, and the replication conflict will truly be obsolete.
Until then, Ray's solution is still a big part of what makes collaboration possible. It's a feature, not a bug, and even when it's no longer a necessary feature we should remember it for two reasons. First, because it helped make our industry what it is, and secondly because it's a great example of an important general design principle: if human life or massive amounts of money are not at risk, then a product that works perfectly 99.9% of the time and makes it's failures readily apparent and easily repairable in the 0.1% case is superior to a product that works 100% of the time but doesn't ship or can't be operated economically.
1. james governor11/17/2005 10:27:26 AM
ah good stuff. kind of hoisting me with my own petard too. i mean - how often have I argued blogs and wikis are an issue for Lotus as a collaboration platform - and here i was, getting caught out calling for a heavyweight replication and locking service....
my basic concern was management overheads associated with replication sprawl. but of course if users, the database creators, are in control, well that's just the way it is.
2. Ben Langhinrichs11/17/2005 10:33:32 AM
Excellent post, Rich!
3. Richard Schwartz11/17/2005 11:11:24 AM
@James: Thanks, and good point. I wasn't even thinking along those lines.