Do We Need To Stifle Creativity of OSS Developers?

I first met Pierre Fricke in late 1998 or early 1999 when he was working for IBM. He was one of four people charged by IBM to research and evaluate the strategic implications of open source software for IBM's business. Because I was a founder of the world's first open source company, he was keen to understand what I saw back in 1989, what I saw looking to 1999 and beyond, and whether our experience (which earned upwards of $24M of revenue in 1999) could possibly inform the strategy for a company more than 1000x our size. My advice at the time was this: if IBM never recognized a penny of open source revenue, open source could still greatly benefit IBM by streamlining and standardizing four completely disparate hardware lines: the S/390 mainframe, the AS/400, the RS/6000 Unix workstations and servers, and the commodity PC business. I suggested that the efficiencies gained through such standardization would enable IBM to become a far more innovative company, while giving customers both more and better choices across the IBM brands. The fact that IBM later rationalized their hardware offerings of zSeries, iSeries, pSeries, and xSeries with Linux as the common denominator does not mean that IBM took my advice. But it does mean that something Pierre wrote in his report made it to the top. Pierre now works for JBoss, a division of Red Hat, as do I (through the acquisition of Cygnus in 2000). And with those disclosures out of the way, let me steer you to a blog posting that speaks for itself: [We] need to stifle creativity in the open source community and control these standards -- A Proprietary Software Vendor. Do you agree?


Creating Software is one of the most creative activities that humans undertake. The main limitation in software is the Human Imagination, and the limits on that are all self imposed. Through the Software Engineering model we see a linear, sequential model of Software Development, something that drastically reduces our ability to create really great software. Through the application of creativity, it is possible to create truly great software. The only problem is that doing so requires that developers have the freedom to explore different designs, and the ability to choose the design that most closely matches the spirit of the requirements rather than the letter of the requirements documents. btw. Thanks Michael for the link to the Pierre great article. My blog: Tom

I agree with the proprietary guy, but only up to a point. However you want to characterize or theorize about it, open source's explosion into the markets is leaving behind a trail of lots and lots of installed systems, based on many-million-lines-of-code software stacks, huge numbers of which are not based on lines of development that promise any kind of long term stability or commoditization. Legacy-wise, open source has so far succeeded in creating is own variations on the Cobol crisis. This is going to start getting expensive to fix. I (generously?) take that to be the point of saying we need to stifle open source creativity. -t

It is true that there is a *lot* of abandonware out there in the open source world. BUt most abandonware occurs because there was insufficient developer community after a period of time. I know-- I have abandoned large projects after substantial time frames simply because the code was not maintainable and the community was too small for me to justify continued maintenance beyond what people were paying me to do. However, the solution is to be more selective regarding open source software and review the community before committing to using it in an organization. In short I favor a user-side solution rather than a developer-side solution. A secondary solution should be the issue of collaboration between projects. building common librries across projects where larger developer communities, etc. can work together provides for the same sort of vendor-driven standards.