7th October, 2003 
Why Open Source might be doomed - a dialogue with Megan McArdle

This was a short on-line dialogue with Megan McArdle discussing her article on why open source might be doomed as it appeared at Tech Central Station.  
  
There are many things that require response in this article. I believe it was written not out of malice but without some understanding of the reason that free software and open source evolved.

It has never been the goal to copy existing works line for line and make it "free" for everyone. The driving passion for most of us is to write software that works the way we want it to work. We write because we have a belief we can write it better. Commercial software is constrained by budgets and market-driven deadlines. If you read "Peopleware" by Tom DeMarco and Tom Lister you'll get an idea of the issues for developing software in a commercial environment. You'll see phrases like "quality - if time permits" and "we haven't got time to think about this job, only to do it". That is the constraint that developers have fought against.

Open source and free software (open software) development evolved from an existing mode of development - skunkworks projects. These projects were hidden away from upper management because the belief of the development team was so strong that they defied the management decision to kill the projects. These beliefs also drove us to develop these projects by even committing our own leisure time. So this stuff on open software hasn't emerged full blown and without precedent.

However, the corporatisation of research and development from the mid-eighties has killed real innovation. Short term gains, with a yearly and more usually a quarterly focus have allowed only the low hanging research and development fruit to be reaped. Look at the contributions of Bell Labs to technology and compare it to the contributions of the corporatised Lucent. That's corporate reality. And the tight fiscal control imposed since the eighties has driven skunkworks from the corporate world into the wilderness - it is what most people call the FLOSS world.

Things perhaps evolve at a slower pace in the open software environment, but more effort is spent in getting the engineering right. There are no pressures for corporate deadlines and there is no pressure to cut corners. There is a strong effort to get it right and a belief that the finished product is going to be better than a commercial product. This to a large extent also means that developers are less inclined to want code tainted by commercially cut code mainly because of the in-grained belief system and mind set of these developers. Given specifications we might develop similar implementations. However, appropriating proprietary code is not even a consideration for the vast majority of open source and free software developers.

The current UNIX/SCO dilemma exists because of the cross-pollination of code and the availability of publicly released code. For the record, UNIX is both a trademark and a brand, neither of which is owned by SCO. The Open Group own the UNIX trademark and are the maintainers of the Single UNIX Specification. Any UNIX-like implementation that passes the certification tests for the Single UNIX Specification can use the UNIX brand for their product. The specification allows developers to produce specification-compliant systems. And the public release of code, even by SCO itself has contributed to this deluge of UNIX-compliant code. There has never been any malicious intent to use proprietary code. The collaborative and open practices for open software development has made the code implementation process transparent and available for the public record. This makes it uniquely different to proprietary coding practices and allows immediate scrutiny by any viewer, including proprietary development houses.

The code that SCO has so far highlighted does not indicate any breakthrough advances that greatly benefit the Linux product. Further the code in question related to a very specific hardware platform - the ia64 (Itanium 64-bit processor) and to performance improvements related to this development. This work was contributed to by SCO in various ways and in various incarnations. For further background, I would suggest looking at the Trillian project and the Monterey project to see the tangled developments between SCO, Caldera, IBM and SGI. Information on these are available publicly and on-line. So there are a number of layers of deception about the claims and SCO has not helped itself by contributing to the releases of code, tainting any work in the areas in question. However, this is merely an aside in addressing the misconception that open software developers are somehow actively looking to misappropriate code at every opportunity. Sheer self-belief and weight of numbers will suffice in developing good software implementations.

The developers have a belief that they can produce a better computing system. Whether or not the business world adopt open software is really a side issue. The banner against commercial competitors may be taken up by business advocates or by the services organisations but for the rest of us as open software developers, we built software because we didn't like what was available commercially. Free software is about freedom of choice.

Finally, I think the comparison to car dealerships is a poor one. Open software development should not be likened to the car dealerships because they represent the producer or manufacturer. The car dealerships are analogous with Red Hat, IBM, HP, SGI and SuSE. This middle-tier provides services to the customer. They are the value-add. As many people are at pains to point out, open software developers cannot provide guarantees on support. However, organisations with good service arms can provide service guarantees and they avoid the costly investment in research and development by using open software products. They might help seed or help better engineer the open software products as evidenced by IBM's efforts, but at nowhere near the same cash burn rate as internal product might.


MM: Believe me, JonB, I was not meaningfully attempting to compare Linux with a car dealership, except in the sense that things can have qualities that are non-obvious because they aren't valuable to you, but are nonetheless critical. Nor am I trying to make any sort of comment about how open source works, or why people develop it. I'm looking at it from a market perspective: will it be adopted, or not?


Analysing whether the business market will adopt or will not adopt open software is fine. But don't assign to the open software movement any ambition other than a desire to build better software. As developers, we can build alternative software if we don't like what we have to use now, whatever the personal reasons. That is what has been done. Whether the business market wants to use the products created is a question for the business market.

But from a market perspective, I believe the beneficiaries will be service organisations. It is the "dealerships" that become the important value add. This is the area in which IBM is focusing. It makes sense of the acquisition of Price Waterhouse Coopers. The integration of products into a coherent business framework, the delivery to the corporate customer of a custom business solution are areas into which the open software developer does not venture. The software components themselves are just a part of the solution and open software initiatives have commoditized certain components.

SCO for want of a better description, has failed in the value chain as a reseller and failed as a value-added service provider, against competition such as Red Hat, SuSE and IBM. They are now trying to return to an OS market where there is not much competition, with few OS providers and where the OS is therefore of high value. It is doubtful that they will be able to reverse the progress of the past 12 years. Even in the unlikely event that SCO should succeed in their suit against IBM, there is an alternative to Linux in BSD. And SCO rely on many pieces of open software including compilers and development tools, and the Samba technology, to name but a few of their dependencies. So their victory may limit their own on-going capability to establish new future business. But that is quite beside the discussion at hand.

For what it is worth, I believe the next strategic battle will be over the business service infrastructure. It will be about the ability to quickly deploy business solutions that are aligned with each company's unique and changing value proposition to their customers, and about enhancing that proposition. This will firstly be the choice between the J2EE framework and the ability to connect with many open standards based business infrastructure; or Microsoft and its proprietary .NET framework. Secondly it will be about the service personnel who can achieve the delivery of this to the business plans.

The OS in an open standards world can be replaced by another standards compliant OS. It is of little moment in the value chain. In a sense, open standards lead to open software and interchangeability of components. There is a limit on product differentiation for components and this acts to drive the perceived market value of the component down. Therefore, the OS market itself should not be the burning strategic desire of any IT company with an expectation for any significant future business in an open standards world. But that, I believe, is a topic for another time.