I'll continue one argument I was having with Jon in the open, just to see what happens. The premise: Open collaboration can relentlessly commoditize things that require a lot of work -- like deep integration -- just because it can mobilize the resources.
My response: In my experience, that hasn't been the case. In fact, the "open collaboration" model tends to leave things at the "good enough" point too often. Look at most open source software efforts: very few large-scale projects get beyond looking like bunches of different applications created by different people. Nearly none actually demonstrate things like common user experience paradigms, consistent APIs, or uniform management.
But that got me to thinking, because it's unfair to paint every open collaboration project with the same brush. I'd actually say that "open collaboration" falls into four broad categories:
Cloners, e.g. LinuxWhen developers see a feature or an application that looks interesting one of the avenues they explore is to copy as closely as possible the interesting thing (and typically to make the source code available).
Standards-Built, e.g. ApacheApache was created by members of the IETF mostly as an implementation of the HTTP specification to verify that HTTP was, in fact, implementable and to create an implementation with which to test compatibility. There are many examples of this kind of cooperative development to create a reference implementation.
Competitive Devaluation, e.g. EclipseCompanies like Microsoft and Macromedia have some substantial advantages over IBM in the development tools area and IBM, despite many attempts and acquisitions, was never able to create a compelling-enough product to compete with these companies while still charging for its software. So it created a development tool shell and released it under an Open Source license and encouraged a community to grow around it, attempting to unify the development tools segment.
Invention, e.g. PerlNot quite like anything that came before, though clearly anchored in a combination of a more powerful shell environment and the C programming language. There are lots of examples, though few as notable (and universal) as Perl.
What's interesting to me about these four categories is that the first and third draw a lot of press, but are (to me, anyway) far less interesting than the second and fourth.
What's also interesting is that the world of this software still has way too many sharp edges where one thing ends and another begins. I don't think that collaborative development will fix the sharp edges -- after all, these are the folks who let sed and awk have really different syntaxes from each other and from their shells because it was enough that it worked.
There aren't that many brain surgeons around to rationalize different pieces of software, and at some point companies are going to get sick of having to spend time training people to manage and program to different systems that are simply arbitrarily different.