Another reply on the trouble with OS

Member reply: John McCreesh MBCS replies to the issues raised in 'The trouble with open source'.

This article caused some comment among those familiar with open source software.

It raised what it stated were a number of issues with open source, and came to the conclusion that the widespread adoption of open source, particularly in the public sector, poses a threat to indigenous software industries.

It argued that this threat merited a government investigation - serious charges indeed.

It opens with an historical inaccuracy: 'From its humble origins in the "hacker" culture of US computer science laboratories in the 1970s...' In fact, open source is as old as computing itself.

One well-documented commercial example dates back to August 1955, when IBM encouraged buyers of its new 704 computer to share source code.

The practice was adopted eagerly by the seventeen organisations involved and saved them around $1.5 million of programming costs in its first year. 

The same desire to drive up quality and reduce costs is as relevant today as it was fifty years ago.

The article is correct that much open source software in recent years was written by the proverbial hacker in the bedroom. However, what is interesting is how the wheel is coming full circle. It is increasingly common now for developers in the core open source projects to be funded by commercial organisations.

For example, the vast majority of code being committed to the main open source operating system, Linux, is now created by commercially-funded developers.

The same is true for the majority of developers for the leading open source office suite,, who come from companies like Sun Microsystems, Novell, and RedHat.

These developers are not funded out of altruism - their sponsors know there is a sound business case behind their investment.

To explain this development, it's useful to recall the 'IT doesn't matter' controversy sparked by the eponymous article in the Harvard Business Review.

Its author, Nicholas G. Carr, contended that much of IT was rapidly turning into a utility. What business was going to gain dramatic competitive advantage by upgrading to a new version of its word processor? or its email system? or its web servers? or its desktop operating system?

To take this further, what proportion of its staff actually use more than a few percent of the functionality in its current spreadsheet package?

As Carr put it: 'Think of Microsoft Office. No company gains an edge by buying a license to use Office - it's a commodity input shared by most companies. For Microsoft, however, Office is anything but a commodity.

Through various means - control of the PC desktop, manipulation of standards and compatibility, network effects, and high user switching costs - Microsoft has been able to continue to sell Office at a premium price and earn enormous profits from what is now a mundane product.'

In this situation, it makes complete business sense to migrate to an open source alternative. Financing some developers to work within an open source project is an extremely cost-effective route to guarantee the future support and development of the product and influence its future direction.

Returning to the article - it is correct in stating that there also many professionals with 'day jobs' in the IT industry who also work on open source projects in their free time.

It claims these individuals 'may be unwittingly engaged in illegal activity by stealing their employer's IP' (intellectual property).

This is a wonderfully big-brother view of the world, where wage slaves have sold themselves so completely that even their leisure time thoughts, unrelated to work, are no longer their own.

This must be a revelation to the numbers of journalists - and even academics - sitting writing books at home in the hope of modest remuneration.

It is worth exploring why so many IT professionals do choose to work on open source projects in their own time.

Open source communities are marked by a passion for their work, and produce code at a rate and quality that many commercial development shops would die for.

In larger projects, teams span continents, languages, and time zones, and using only simple tools manage to build close-knit and highly productive communities over the internet, without any of the advantages of their commercial counterparts (video conferencing, regular air travel for face to face meetings and so on).

There is a serious issue here for commercial IT shops - can they manage to create the kind of productive, creative communities that open source projects achieve? Or do their developers pin up Dilbert cartoons in their cubicles because they recognise Scott Adams' world in their workplace?

Are the developers' technical skills mentored, recognised and rewarded by their peers, or are they 'line managed' by Dilbertian pointy-headed bosses? Do they get instant feedback from users about what works and what doesn't, or is their only contact with the outside world through an impersonal trail of business analysts, requirements capturers, designers, and analysts via some impenetrable CMMI 'traceability matrix'?

The article also castigates the open-source development process because 'good software needs a designer (or software architect in the current industry jargon) with a clear design concept which must be adhered to rigorously' - 'conceptual integrity'.

This may hold true - just - for student projects, but in the world outside academia, typical systems are a combination of package software, bespoke coding, various applications built to different standards and acquired through mergers and acquisitions... not a pretty sight for purists, and 'conceptual integrity' is a bit short on the ground, but these are the systems which store the article author's finances, collect his taxes, manages his health records, and generally run the world in which he lives.

Good open source code is designed to be understood and maintained readily by others, and is capable of rapid evolution at the hands of multiple developers.

This evolutionary property turns out to be more useful in the real world than conformance to a theoretical 'intelligent design' process.

The author moves on to even more uncertain ground when he accuses open source developers of not being 'professional' (not defined). It would be interesting to see the widespread practice of accepting software without access to source code being tested in the courts as part of a professional misconduct case.

Taking an analogy: Joe Public would be considered unprofessional, not to say naive, if he bought a car with the bonnet welded shut, and where the conditions of sale stated that attempting to open the bonnet for inspection or maintenance would land him in court for violating the manufacturer's intellectual property. And yet this is a reasonable analogy for what IT purchasers are doing by accepting the historical anomaly of closed-source licensing.

This is not to argue that Joe Public should be forced to conduct a source code inspection of shrink-wrapped software before having to compile it on his home PC. However, it is strange that a historical quirk that separated source code from executables has become an accepted way of doing business in the IT industry.

An example only too familiar in IT shops: during that final dash to get the new software in before the board deadline, testing reveals that the bug fixed in version 2.3.21 has mysteriously reappeared in the latest 2.3.26 version.

The supplier swears their source code management system is flawless - but a quick run through the source code would be a better quality check than any number of CMMI certificates on the supplier's wall. How 'professional' is it to accept software blindfolded by a secret-source contract?

The article also raises the old chestnut of there being a lack of imagination and innovation in open source projects. I wonder whether the author has ever actually used any open source products, or watched open source code develop for evidence of creative imagination at work?

Open source projects had the imagination to develop the tools which today power the internet. Recent previews of Microsoft's Internet Explorer 7 browser have commented on how the commercial product is playing catch-up with features introduced by open source browsers like the Mozilla project's Firefox.

The open source 2.0 office productivity suite is the first software product in the world to use OpenDocument formats. It has also been able to create pdf files since version 1.0, a feature which Microsoft has only just announced it will provide in a future release of its Office suite.

In fact, the charge of lack of imagination sticks much more readily to commercial software giants such as Microsoft, who did not invent any of their major products (windowing, spreadsheet, word processor, email client, web browser…).

Where closed-source companies do excel is in imaginative marketing, using monopoly profits to consolidate their position within the IT industry.

Dilbert is popular with IT folk because many people find echoes of his cartoon world in their own workplace. His neighbour on the back page of Computer Weekly, C.P. Bound, also raises a smile, because the excesses of IT corporate hospitality this fictional character enjoys are also uncomfortably close to the truth.

It's easy to find out the latest about commercial products over complementary drinks at Wimbledon - finding out about the open source equivalents requires effort. This is where professional bodies like BCS have an important role to play.

It's pleasing to see that the author acknowledges that open source does have a role within his own world of academia. However, what is open source for the university goose should also be open source for the public sector gander.

The public sector in the UK has historically been built on principles of professionalism and an ethos of cooperation in the service of the public.

This ethos fits more comfortably with the open source development process than with the present methods of secret-source commercial development, which recent experience has shown are fundamentally broken in the UK public sector.

Large sections of the public sector operate fundamentally similar business processes, whether it's collecting revenues, processing planning applications, booking hospital appointments, scheduling classroom timetables, reserving library books, and so on.

Acquiring software piecemeal from a variety of different commercial software vendors on a secret-source basis is inherently wasteful, with the same code being written many times over.

Enforcing a central purchasing model from a single supplier is equally flawed: the distance from the end users increases exponentially with the size of the contract; the contracts become so arcane that the list of potential suppliers becomes the list of the usual suspects, charging vast daily rates and doing nothing to generate an indigenous software industry.

Consider the alternative of an open source approach, where cooperative development can be spread across multiple organizations, but all closed to real end users.

Developers could be based either in-house, or in local software houses, undertaking real end-to-end development work, rather than tailoring software from the other side of the globe (the 'McJobs' of the IT profession).

Open sourcing of the code ensures that the public investment remains public property. Far from being the end of the world as we know it, adopting the open source development process could be the saviour of public sector IT, as well as working wonders for the local UK software industry.

Like the writer of the article, I too would like to end with a call for the government to investigate: however, the investigation should be aimed at exploring the long-term benefits that open source methodologies could bring to the UK, through reducing the costs of acquiring and running utility software, reducing the failure rate of public sector IT projects, and boosting the UK software industry through the creation of real jobs in IT.

I would also call on the government and BCS to continue to provide impartial and balanced information about the range of open source software, so that IT decision makers can make informed decisions for their organisations.

Microsoft has announced it will spend $300m in marketing (marketing, not developing) its Office product for fiscal 2006 and will expand the number of field sales people from 450 to more than 1,000.

Its open source equivalent - the project - has no marketing budget, yet independent reviews state the new 2.0 ' swift, smooth, and highly compatible with Office documents. Even better, it has plenty of features that you can't find in MS Office itself.'
I would ask all readers of ITNOW - are you as familiar with 2.0 as you are with Microsoft Office? Have you evaluated them both for your organisation?

I rest my case.

further reading

September 2005