What I’d like to see happen is genuine open-source innovation. But I’m afraid this cannot happen, because real innovation requires a lot of money, and corporations remain the best way to fund such innovation, in general with high hopes to make even more money in return.
“There’s an argument commonly heard these days that open-source software is all very well for infrastructure or commodity software where the requirements are well-established, but that it can’t really innovate. I laugh when I hear this, because I remember when the common wisdom was exactly the opposite — that we hackers were great for exploratory, cutting-edge stuff but couldn’t deliver reliable product.
How quickly people forget. We built the World Wide Web, fer cripessakes! The original browser and the original webservers were built by a hacker at CERN, not in some closed-door corporate shop. Before that, years before we got Linux and our own T-shirts, people who would later identify their own behavior correctly as open-source hacking built the Internet.
It seems to me that bringing the Internet and the World Wide Web into being ought to count as enough “innovation” for any one geological era. But it didn’t start or stop there. Nobody even conceived of cross-platform graphics engines before the X window system. The entire group of modern scripting languages descends from open-source Perl, and almost all draw critical strengths and innovative drive from the size and diversity of their open-source communities.
Even in user-interface design, much of the most innovative work going on today is in open source. Consider for example the Facades system. Or just the astonishing, eye-popping visual experimentalism of Compiz/Fusion under Linux.
It’s actually corporations who have trouble innovating. Innovation is too disruptive of established business models and practices; it’s risky, and it involves coping with those annoying prima donnas at the R&D lab. Consequently, even well-intentioned big companies like Xerox that are smart enough to fund real research centers like Xerox PARC often reject the truly groundbreaking ideas from their own researchers. Today you’d be extremely hard pressed to find any of the really cool ideas from Microsoft R&D being deployed in actual Microsoft products.
The process of innovation and deployment in open source is of course not friction-free, but it certainly looks that way when compared to the corporate world. One of my favorite current examples is the way Guido van Rossum and the Python community are gearing up to re-invent their language for its 3.0 release. Their “Python Enhancement Proposal” process for fostering and filtering novel ideas by individual contributors repays careful study; like the Internet RFC process (on which it’s clearly modeled) it produces a combination of innovative pace and successful deployment that even Bell Labs in its heyday could not have dreamed of sustaining.
de Dinechin, and people like him, have a simple and linear model of how innovation works. Pay a bright guy like de Dinechin, stand back, and watch the brilliant stuff come out and change the world. In this model, if you don’t pay bright guys like de Dinechin, innovative stuff doesn’t come out because they’re too busy grinding out COBOL or something so they can eat — no world-changes, so sad.
This model is very appealing to people like de Dinechin, who have an understandably strong desire to be paid for being smart and creative. Heck, it appeals to me for exactly the same reason. Unfortunately, and unlike de Dinechin, I know that it is seriously false-to-fact.
I have a very different model of how innovation, at least in software, actually works. One of its premises can be expressed by what I shall now dub the Iron Law of Software R&D: If you are a programmer developing innovative software, the odds that you will be permitted to finish it and it will actually be deplayed are, other things being equal, inversely proportional to the product of your depth of innovation and your job security.
That is, the cushier your corporate sinecure is, the less likely it is that you will make a difference. The more innovative your software is, the less likely it is that you will actually be supported all the way to deployment.
The reason for this is dead simple. Corporations exist to mitigate investment risk. The large and more stable a corporation is, the more resistant it is to disruption in its practices and business model including the unvoidable short-term disruptions from what might be long-term innovative gain.
Net-present-value accounting therefore almost always leads to the conclusion that innovation is a mistake..”
This is just an excerpt, the full argumentation is here.