You know... open sourcing a product (especially a huge, enterprise-critical software product) is not always a good idea.

First of all, many governments, big banks, multinational corporations, and medium-sized businesses rely on Notes/Domino to orchestrate their mission-critical internal email and messaging systems, as well as to control millions of dollars of their sales and revenue as it courses through databases and web apps. Open sourcing that infrastructure would make it a very, VERY appealing target for hackers and security exploits. Especially since one of the recognized benefits of N/D is that it is generally considered a mature, secure, enterprise-quality product (albeit somewhat finicky in the UI). It is, after all, much harder to hack a complicated, obscure black box than a complicated transparent one.

So now imagine you're a government or a big bank and you just shelled out all this money for Notes and Domino to control your company, and now some guy comes along and says -- "Hey! Our user experience could be somewhat better if we just gave everyone in the world the source code this mission critical database, email, and workflow system we all use! Lets do this guys!" ... Riiight. Who wins here?

Second... Notes/Domino does all it does on even low-end hardware because its source is written in carefully orchestrated C, C++, and assembler (along with some Java). It is highly optimized and complex code crafted by some of the best minds in the early IT industry. Once you've seen it, you'll realize what a really REALLY bad idea it would be to allow neophytes (that don't have the brain trust of the rest of the Lotus organization to leverage) to modify the code. This is not written overnight Java or VB code we're talking about. N/D code can border in complexity to OS code. Do you REALLY want your sysadmin getting bold one day, taking out his wrench and hacksaw, and saying... "awww, heck, I can fix this one MYSELF!" and now you have a broken IBM support contract and very likely subtle timing and data corruption errors in your enterprise databases and workflow.

Again... who really wins? Is it really the customer? After all, they're really the ones that matter. There are those of us that keep that in mind.

From working on both academic and enterprise software designed specifically to scale, these are four things I've noticed are incredibly important to scalability:

Languages - I recently saw a multi-million dollar product fail because of performance problems. A large part of it was that they wanted to build performance-critical enterprise server software, but wrote it mostly in a language that emphasized abstraction over performance, and was designed for portability, not performance. The language, of course, was Java. Before I get flamed about Java, the issue was not Java itself and alone, but part of it was indeed using a language not specifically designed for a key project objective: performance. The abstraction, I would argue, did the project worse than all the other peformance issues associated with bytecode however. Relevant books on this subject are everywhere.

Libraries - Using other people's code (e.g. search software, DB apps, etc.) will always introduce scalability weaknesses and performance costs in expected and unexpected places. Haphazardly choosing what software to get in bed to can come back to bite you later. It is an occupational hazard, and each database product and framework and even hardware configuration has its own pitfalls. Many IT book on enterprise performance or even whitepapers and academic papers can provide more information.

Abstraction - There is no free lunch. When you make things easier to code, you typically incure some performance penalty somewhere. In C++, Java, and most other high level languages, the sheer notion of modularity and abstraction eventually add so much hidden knowledge and code that developers either lose track of what subtle costs everything is incurring, or are suddenly put in a position where they can't go back and rewrite everything. Sometimes it is better to write a clean, low-level API and limit the abstraction eyecandy or it will come back to bite you. On the other hand, sometimes a poor low-level API is worse than a cleanly abstracted high-level API. In practive, few complex and performance-oriented systems are architected in very high level languages however. I have seen few books on this subject, and it is pure software engineering. Design patterns might help, however.

Audience - Both clientelle and developer audiences make a big difference. Give an idiot a hammer with no instructions... and you get the point. Make sure your developers know what they're doing and what priorities are, and also design your interfaces and manuals in such a way as to keep scalability in mind. Why have a script perform a hundred macro operations when a well-designed API could provide better performance with a single call? This entails both HCI and project development experience.

Wish I could suggest more books, but there's just too many.