There's an ancient, but still thoughtful and correct, article called The Rise of the Stupid Networks which details why stupid networks are better than smart ones.
It basically says:
If you build intelligence into your networks you are optimising them for a single purpose at the expense of their flexibility. Any gains you make from this optimisation will be overtaken by general gains in the medium term, leaving you behind in the long term as unexpected uses are found for more general networks.
The examples in the article are the phone networks (optimised for voice) and the data networks (not as good with voice at the time, nowadays just as good at voice and far more useful in ways that were never originally imagined). However, if we change 'network' to 'conduit', and think of it as anything that carries data between two places, it becomes more generally applicable.
I was reading Clay Shirky's article Given enough eyeballs are features shallow too? which says that if enough people use a piece of software, one of them will have an amazing idea that will make the software indispensable, and that thinking of the idea is actually frequently harder than implementing it (true in many situations - take Bayesian filtering as an example, someone published an article on using Bayesian filtering to spot spam, 6 months later there are at least a dozen different completed projects which implement this).
Putting these two ideas together, I realised that what we need is stupid software - software that's incredible simple, that basically gets the data from A to B, but allows other people to slot their ideas on top of it. Some of the first programs to do this were games - Doom had editors that allowed people to modify some parts of it, but Quake allowed people to completely modify the game beyond recognition. Nowadays many erstwhile game companies sell what are basically engines and tech demos (see Quake 3 for a perfect example) for others to build their own games on top of.
But what really clinched it for me was the decision by the Mozilla creators to take their massive, monobloc web-browser/mail client/chat program/kitchen sink and split it into much smaller programs that focus on a single task. Not only that, but they simplifed the interfaces significantly and hid everything possible from the users except for what they needed to see. Which isn't the important bit. The important bit is that they made ie supremely easy to write extensions. This means that you've got a stupid program (actually, a very smart program, but it needs to be to pretend to be as basic as web browsers seem to be) that acts as a lowest common denominator for anyone to add their cool idea on top of.
In these days of increasingly open source software, the programs that get the most support will be the ones that allow programmers to scratch their itch the easiest, the ones that are designed from the ground to allow you to build on them. The ones which are, if I may, that are the stupidest.
I emailed Clay Shirky with this idea and he responded that the idea was even more flexible: protocols are another concept that can be thought of as a conduit. Thinking about it, a simple, extendable protocol is worth 1000 complex, specialised ones. There's a big fuss about weblogs and syndication at the moment - the idea is finally taking hold, largely because with RSS it's fairly easy to publish journal entries,news stories,comics, etc. in a manner that anyone can read with their choice of reader. The Echo project plans to supersede RSS, and it's because they are doing this because have found the protocol hard to extend, and not simple enough (or rather, so simply specified that it can be interpreted in many ways, so that interoperability suffers).
Of course, some systems are externally extendable - most of us use SMTP and POP3 for our email, but the range of different programs that are used to access it is huge. By having a standard transmission protocol, we've allowed developers to concentrate on scratching their itch on the way that the results are displayed and organised it. A complex system that defined the way that email should be treated at all levels would be much harder to extend, and so much less likely to be widely taken up.
There are many examples of simple, generalised, extendable systems being massively successful, from HTML to TCP/IP, to PCs themselves. In almost every situation, the one that does a simple job that leaves the door open for later extension and improvement has been more successful.