Ray Ozzie [IMHO but IANAL] effectively demonstrates that 1993-vintage Lotus Notes had "prior art" that -- in a rational world -- would invalidate the Eolas patent on embedded hypermedia. This patent has resulted in a large judgment against Microsoft and raised the very real possibility that the Web browser as we know it must change drastically or infringe on the patent. Jon Udell suggests that this may be the most influential weblog entry of all time. We shall see about that, but it does have one of the most intriguing tidbits I've come across in awhile:

In 1993 or thereabouts, we saw the emergence of TCP/IP, HTML, HTTP, Mosaic and the Web. From our perspective, all of these were simplistic emulations of a tiny subset of what we'd been doing in Notes for years. TCP/IP instead of Netbeui or IPX/SPX, HTML instead of CD [Lotus Notes "compound document" ] records, HTTP instead of the Notes client/server protocols, httpd instead of a Notes server. And we were many years ahead in other ways: embedded compound objects, security, composition of documents as opposed to just "browsing" them, and a sophisticated development environment. I am quite embarassed to say that we frankly didn?t "get" what was so innovative about this newfangled "Web" thing, given the capabilities of what had already been built.

So why did the "simplistic subset" succeed so much more dramatically than Notes? Uhh, probably mainly because it is a simplistic subset! Consider the argument of Clay Shirky

The very weaknesses that make the Web so infuriating to serious practitioners also make it possible in the first place. In fact, had the Web been a strong and well-designed entity from its inception, it would have gone nowhere... Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen.

Put differently, the Web succeeded because it hit the famous "80/20 point" -- it gave most of what other solutions offered, but at a much lower cost and complexity.

Joel Spolsky has a rather different take on this.

A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it's never the same 20%. Everybody uses a different set of features.

So, the 80/20 rule rules sometimes, but not always. Obviously, it doesn't rule when different groups need a different subset of the features. More generally, it doesn't appear to rule at the application level -- the masses seem willing to keep pour money into Microsoft's jaws to get the latest version of Office, when far fewer than 20% use features that weren't in Office 97. OpenOffice, which appears to be at about the Office 97 level of functionality and is free, has a miniscule market share. (I'm part of it, so don't flame me!). A few hypotheses:

• Minimalism ( fundamental simplicity) matters more at the infrastructure level, where it really really matters how universally something is adopted, how reliable it is, and how well it performs.
• Minimalism ( fundamental simplicity) matters more when standards are involved.
• Ease of use (simplicity of operation) is obviously critical when you are dealing with a large, relatively unsophisticated audience. The early Web didn't have to worry about this, and by the time it took off it had a "cool factor" that overcame a lot of resistance. One can't count on that happening again anytime soon!
• "Good" software, at both the infrastructure and UI levels, manages to maintain the "illusion of simplicity" by hiding the ugly details while still providing most of the functionality that one immersed in the details can employ. That's hard. Office 2003 is just starting to approach this.
• Beware of the argument that complexity isn't a problem so long as it is hidden. True enough, in the abstract, but only if it is the detail being hidden and not the complex concepts that an API or GUI is simply ignoring. For example, XSLT is a powerful tool in expert hands, but AFAIK none of the GUI stylesheet generators go much beyond the basics. The same is often said of IDEs.