As Linux moves further into the enterprise, how can its core strength of collaborative development be maintained? Helen Beckett explains why firms are having to become familiar with a new way of working.
Open source software is bringing a collaboration model for software development and usage into the mainstream. However, it is unlikely that large corporations, with their unwavering focus on the bottom line, will be able to work co-operatively all the time.
Thomas Murphy, senior program director of research services at Meta Group, anticipates that the distinct boundaries between the purists who advocate that software and algorithms are open access "tools", and the closed communities that buy software and structured support, will start to mutate.
"On the supplier side, companies such as IBM have shown that it is possible to build open source assets and also retain proprietary communities," Murphy says.
"With Eclipse, a limited base IDE was placed into open source and the firm got a set of partner commitments for plug-ins. It has been used as a weapon to innovate in Java without going through the Java Community Process. So in many ways you could say this is a subversive use of open source," he says.
In the same way, he adds, it is likely that large enterprises will only belong to open communities when it suits them.
Nikos Drakos, a research director with analyst firm Gartner, confirms that some kind of open source software is used within every sizeable organisation. Many blue chip companies have approached him seeking advice on whether and how to participate in the proliferating open source foundations.
"A lot of our customers want to know how to systemise the software they use and to manage any new risks that usage or participation in these groups may bring," he says.
"There is a degree of confusion throughout every level of the enterprise in how to deal with not-for profit companies and their new modes of operation. People from procurement departments have even asked how they raise a purchase order," says Drakos.
However, there are vast differences in the rules that different branches of the open source movement apply. Users need to be aware of the software licence they intend to use or modify, says Ronan Miles, chairman of the Oracle Users' Association.
"The issue of whether a firm should participate in a collaborative development is trivial compared to the 'gotcha' clause contained in some of these licences," he says.
Miles recalls his own experience of developing a plug-in for an open source application that was not a regular feature of Oracle software. The GNU General Public Licence (GPL) would have forced him to reveal the source code of the modification.
"The difficulty for users is differentiating between Apache and Openware software, which comes with no strings attached, and others, such as the GPL licence, that come with stringent conditions," he says.
Miles recommends donating in-house software to the open source community once the financial advantage has been milked for six months or so. Miles quotes from Hewlett-Packard's research, which found that 50% of the return from a new software product is derived in the first six months after it goes to market. "Beyond that, it makes sense to hand it over to a virtual pool of developers to shoulder the maintenance burden," says Miles.
A further benefit has been experienced first hand by Stephen Way, IT manager of Johnson Matthey and executive council member of the IBM Computer Users' Association. "The incentive [to participate] is that of training and advancing development staff," he says.
"Johnson Matthey staff have gained prestige and access to a community - and it is no coincidence that the level of churn in development staff has reduced," he adds.
Way has also witnessed improvements in performance. "It has made our development team quicker to react to come up with innovative solutions. They can search code databases and find sensible answers," he says.
However, Way is aware of the wider implications for the company of these collaborative efforts and of the boundaries that must be put in place. "Firms always decide not to put a key line of business application out in open source, particularly if it is bespoke. You have to draw the line somewhere and participation is not all or nothing," he says.
Drakos says the issue of employees working on a shared project could put them in conflict with their own company, which may dictate that any product or intellectual capital created during company time therefore belongs to the company.
This hard-line attitude to intellectual property would prohibit many multinationals from participating in software communities, says Murphy. "Essentially, it means you are constrained from working on anything in open source or contributing something back to the community," he says.
"I think for most firms open source is about licence cost and not being locked to a supplier. However, the supplier lock can still exist, especially if the product comes from a supplier, which is very different from Apache or Perl."
While enterprises sit on the fence or work out how to manage participation, the open source foundations continue to increase their influence over software development.
As Siobhan O'Mahony, Harvard Business School professor, notes in her paper, 'The organisational model for open source', "When a successful entrepreneur with every possible advantage chooses to found a non-profit organisation instead of a firm because it is more likely to lead to success, what can be inferred about the state of the software market?"
This article is part of Computer Weekly's Special Report on Linux produced in association with Novell