What Dya Mean Free Software - Open Source

What d’ya mean, free software?
a review of Open Source, the Pros and Cons
Author: R. Bloor & P. Williams

Published: June 2005
What is Open Source?

The following explanation of Open Source and where it can be used is a distilla-
tion of, and extension to, presentations and viewpoints given at the Open Source
Forum held in London in December 2004 and hosted by Bloor Research.
The Origins of Open Source

Open Source began life as a way of collaborative working. It had its origins in the
computer science labs at US universities (Stanford, Berkeley, Carnegie Mellon, and
Massachusetts Institute of Technology (MIT)) where small communities of pro-
grammers shared each others’ source code. It became a ‘movement’ when Richard
Stallman of MIT conceived a practical plan to formalize the way to share source
code. His idea was that every user of shared software should have the right to:
• Run the software for any purpose
• Modify the software
• Redistribute the software
• Distribute the modified version of the software so others could benefit from
the changes
Stallman embarked on a project of his own, the GNU project, whose aim was to
develop a UNIX-compatible operating system which would be distributed freely.
(The acronym GNU stands, somewhat unhelpfully, for GNU’s Not UNIX.) In
1985, Stallman formed the Free Software Foundation (FSF), to support the work
being done on GNU. Other free software initiatives also existed—the X-Windows
system, Perl, BSD UNIX are examples of what they produced—but Stallman’s
initiative was the most important as it gave rise to the GPL, the GNU General
Public License, which became the model software licence for the distribution of
Open Source software.
The most important aspect of the GPL is that it restricts commercial exploitation
of the source code by others, particularly proprietary software vendors, by insist-
ing that amendments to the software must also be distributed freely under the
GPL.
In 1991 Stallman’s extensive work on GNU was merged with the work of Linus
Torvalds who had written a UNIX-like kernel (called Linux) for running on Intel
hardware. Combining the two resulted in a fully-fledged operating system, which
then evolved under the Linux name.
In 1997, Eric Raymond published an important paper entitled The Cathedral and
The Bazaar (copies of which can be obtained from http://www.free-soft.org/lit-
erature/papers/esr/cathedral-bazaar/). In the paper, Raymond argues that open
source licences lead to higher quality and less expensive software. But the main
Page © Bloor Research 2005

body of the paper compares the two distinct software development models that
give rise to the name of the paper:
• The Cathedral model—where source code is confined to an exclusive group

of developers between new releases (even if it is made available on release).
• The Bazaar model—where source code is developed over the Internet in full
view of anyone who wants to see it. (This development method was invented
by Linus Torvalds in developing the Linux kernel.)
Raymond argues that the Bazaar model is superior, leading to fewer bugs. The
Cathedral model, in its most constrained form, is the method by which propri-
etary software is developed—with source code never being made available beyond
a small group. Advocates of Open Source and users of Open Source products
tend to agree that: the incidence of bugs is lower with the Bazaar style of develop-
ment. But, as far as we are aware, there have been no comprehensive studies to
demonstrate this.
The Cathedral and the Bazaar remains a highly influential work in promoting
and encouraging the Open Source style of software development, and has inspired
many software developers to get involved with Open Source projects.
Shortly after this paper’s publication, Eric Raymond, Bruce Perens, and Tim
O’Reilly formed the Open Source Initiative. This had two goals: i) to promote
the benefits of Open Source to the business community, and ii) to certify that the
specific free/open source licences that had evolved were consistent with their ‘open
source definition.’
It may be that their evangelism paid off, or perhaps it was that the growth of
Open Source had in any case reached its ‘tipping point’, because it was not long
after that major software vendors, including Oracle, Borland and IBM, began to
actively support Linux and also the Open Source Apache web server software.
Open Source is not a Brand

For the purposes of this paper, we define Open Source in the following way:
“An Open Source product is software which is provided along with its source
code and which is subject to a licence of permission for its usage”
This is the thinnest of definitions, and yet it is hard to be more specific because
providing source code along with a software product can occur in a wide variety
of ways. There are, for example, a large number of programs distributed as ‘Open
Source’ that are developed by researchers in universities. Often these are simply
placed in the public domain, after which no further development takes place.
Other products, which were once proprietary and developed in a closed environ-
ment, have since been issued under an Open Source licence (Ingres from CA is
one example).
© Bloor Research 2005 Page

An Open Source product may be robust or it may be buggy. It may be well sup-
ported or it may not. Development may be in full public view (as in the Bazaar
style) but that is not always the case. The licence may be the GPL but is frequently
another licence that is written slightly differently.
There are also many examples of source code being made available from outside
the Open Source community. One example is that Microsoft provides millions
of lines of source code for its Windows development environments to facilitate
development of applications. This code is free and without restrictions to develop-
ers using Microsoft development tools. Other tools vendors also provide source
code on a similar basis.
So attaching the term ‘Open Source’ to a software product guarantees very little.
But it is important to reiterate what it does guarantee, which is: i) the source code
is available along with the product and ii) there is a user licence that restricts com-
mercial exploitation of this source code by others.
Linux is an example of an Open Source product—the best-known example of

all—but it is an operating system so is very untypical. (Linux is discussed sepa-
rately in the next section.)
The primary web site for Open Source projects is Sourceforge.Net. It provides
free hosting and other services to Open Source projects. Currently there are nearly
1,000,000 registered users of this site (most of whom are developers). It acts as
a source code repository for over 90,000 separate Open Source projects, cover-
ing a broad spectrum including: Business Software, Communications, Database,
Desktop, Education, Games, Internet, Multimedia, Office Software, Printing,
Scientific, Security and Software Development Tools.
Open Source products can usually be obtained free of charge, but even this is
not guaranteed. Nothing within the GPL or most other Open Source contracts
actually restricts the sale of Open Source products. Typically revenues come from
distribution and support rather than directly from a software purchase price. Red
Hat and Novell, for example, garner significant revenues from the distribution of
their Open Source products. Where support services are provided along with the
software, the cost cannot be guaranteed to be less than proprietary alternatives.
On the other hand, it is normal to find downloading and copying of the software
itself to further systems without infringing any licence restrictions when it is free
of charge. This process may not be accompanied by (or even require) any form of
registration. This actually means true figures for deployments for popular Open
Source products such as the Apache web server and some Linux operating system
distributions may be greatly underestimated and, thus, market share statistics are
skewed in favour of proprietary competitors. Evidence of this is that companies
doing thorough internal audits of their computer systems invariably discover a
number of unreported Linux and other Open Source deployments.
So, for all the reasons given, the term ‘Open Source’ cannot be viewed as a brand
in any meaningful way. Some Open Source product names (Linux, Apache, Samba,
MySQL, Ingres and others) do have genuine brand value because they now have

established reputations as products. But the fact that they are Open Source prod-
ucts is nothing more than an attribute they share. In fact, many Open Source
products will never acquire a brand value, just as many proprietary software prod-
ucts never have done and never will.
The Linux dynamic

It is important to understand the position of Linux in respect of Open Source. The
Linux operating system (OS) is a hugely successful Open Source initiative and, in
recent years, its take-up has become a phenomenon in many distinct markets:
• In the server market it has had the second largest market share since 1999
and, according to recent IDC figures, it is growing at 63.1% year-over-year
in terms of server revenues or 52.5% in terms of units shipped. In this mar-
ket, Microsoft Windows may still have a significantly higher market share
but has lower growth.
• Related to the server market is the ‘black box’ appliance market (networked
attached devices). This is dominated by Linux with a multitude of devices
running Linux; security devices, system management devices, storage de-
vices, and so on.
• Linux dominates the supercomputer market. More than half of the top 500
supercomputers now run Linux, usually in the form of huge Intel processor
clusters.
• In the desktop market dominated by Microsoft, Linux has only a tiny share
(around 3%), yet even this places it at number two and growing. It is also
being deployed extensively as a thin client and is gaining some traction on
the desktop in the small and medium business (SMB) market.
• In the mobile phone market Linux has a small presence. Motorola moved
to Linux in 2003 for its handsets and NTT DoCoMo did so in 2004. But
the overlap between the mobile and PDA (handheld) markets is heightening
competition all-round, with Symbian as the commonest mobile OS and pro-
prietary OSs led by Microsoft on PDAs all well entrenched.
• Linux has a growing presence in the embedded market, where the dominant
vendor, Wind River, has switched from its own OS to partner Red Hat on
Linux. The projected Linux growth here is 61% pa (according to IDC).
• In the consumer market Linux has a growing presence, being used in con-
sumer appliances such as the TiVo and set top boxes. All the major consumer
electronics companies belong to the Consumer Electronics Linux Forum
(CELF) and are likely to use Linux in future consumer devices.
In summary, Linux is growing its presence and share in all of these markets. This
would appear to be a testament to it being a reliable and efficient core OS software
that can be adapted to many different needs.

Linux is not the only Open Source OS. Historically, BSD UNIX, a version of
UNIX that was developed by the University of California at Berkeley, was the best
known. BSD UNIX could still be viewed as a competitor to Linux in the appli-
ances market, where it is also commonly used, but it has a very low market share
in the server market. For further details go to: www.freebsd.org.
A sign of the impact of Linux is Sun Microsystems’ recently announced intention

to release all or part of its flagship Solaris (UNIX) server OS as a free Open Source
product. But since Solaris has UNIX rather than Linux at its core, with the SCO
Group owning some rights to UNIX, there are potentially both legal and practical
hurdles for Sun to jump.
As previous stated, Linux is not a typical Open Source product. In fact, even for
servers, there are multiple different distributions of Linux from different sources,
each of which amounts to a separate product. What these share is a common
kernel (sometimes slightly modified) and programs written to run on Linux will
usually run on each of these Linux ‘flavours’ without any modification of source
code.
Considered as one, Linux is indisputably the leading Open Source product and
the de facto Open Source operating platform.
The appeal of Linux

Much of the appeal of Linux has little to do with the fact that it is an Open Source
product. Its users champion it as a stable, multi-user, multitasking operating system
that is versatile and well supported. They will also point to it providing a rich
application environment with complementary supporting software, and that it
is standards compliant. It has also proven highly portable, having been ported to
over 80 different environments. None of these qualities are necessarily unique to
Open Source.
Conversely, some of its appeal is specifically because it is Open Source. Linux has
prospered as a device platform precisely because the source is freely available with
no licence fee for its usage. So, for instance, for a vendor who needs to choose a
platform for a mobile phone, network appliance or consumer device, there are
compelling advantages. There is no need to negotiate with a supplier on usage.
Source code can be tailored and added to, to meet special needs, cut down in size
by removing unused portions where space is critical, or performance-optimised to
achieve high throughput.
Widely respected support companies such as Red Hat and Novell (SuSE) offer
direct support for specific Linux server distributions. These have the backing of
major commercial companies such as Hewlett-Packard (HP), IBM and Compu-
ter Associates (CA), who actively promote Linux use, provide their own Linux
support and employ developer staff who make regular contributions to Linux
source code. This strong level of vendor backing has ensured a de facto marketing
push for Linux.

Perhaps most important, Linux has generated, or is generating, software ecosys-

tems around it that include many other Open Source products—the best known
being the fairly mature Linux server ecosystem and the fast-evolving Linux desk-
top ecosystem.
Linux negatives
Little can be deduced about the issues surrounding the use of any particular pro-
prietary OS product by comparing it directly with Linux. But it is worth noting
here some factors concerning Linux that derive from its Open Source nature.
These may be seen as negative compared with proprietary alternatives.
Security
It is difficult to judge between Windows and Linux as to which OS is more secure.
Most of the well-publicised security attacks from hackers in the last few years
(worms, viruses, trojan horses and the like) have been directed at Windows but
this may be primarily because of its prevalence. With the increase in the popularity
of Linux on the server, the security attacks upon it are increasing. It may now be
classified as presenting an equivalent risk to Windows.
Government security agencies across the world have adopted Linux as a key plat-
form for internal use. Because the source code is available, it puts them in control
of security vulnerabilities and they have the skills to ensure that their systems are
more or less bullet proof. So this can be viewed as a plus for the Open Source
model but it cuts no ice with the vast majority of Linux users who have no interest
in the source code but still want good protection.
Likewise, developers of any product can be pretty much guaranteed to introduce

security vulnerabilities. But again, the Open Source review process has apparently
ensured good coding practice, and the highly active Linux support community
will usually pounce on and patch any vulnerability quickly—and usually before it
is exploited by a hacker.
But, here is where Linux may begin to flounder versus its proprietary competitors,
especially Windows. While a security vulnerability may be found and a patch for
it released quickly, users are often slow to install the patch and so remain vulner-
able to attacks—and indeed may experience them—before any attention is given
to implementing the patch.
For example, the SQL Slammer worm infected a large number of Windows users
even though a preventive patch had been released for it several months before the
worm was released onto the Internet.
Here, Linux has an additional problem. There are a variety of different Linux
distributions—with, currently, no standardised procedures for applying patches.
This choice is in fact an inherent feature of Open Source. As the Linux security
issue escalates, and we expect it to, the likelihood is that this will be addressed and
resolved.

Technically, this problem is not the fault of either OS, but rather end-users bring-
ing it on themselves by their slowness. In their defence, small companies in par-
ticular do not have the resources to continually update their systems and this
means they want the slickest and easiest way of applying changes.
One factor confusing the debate as to which is more secure is that a mixed environ-
ment exists in many companies—where Windows desktops are predominant but
the server is Linux (or, indeed, one of the UNIX flavours). Viruses that have in
the past attacked Linux as well as Windows systems have often been introduced
via these desktops, for instance by users opening email attachments that then
propagate their data corruption. So an unanswered question is: what will happen
to virus penetration when full Linux desktop deployments become common?
This also highlights the fact that a mixed environment presents potentially greater
security problems. So, for instance, patches will need to be applied to both Windows
and Linux when both are present.
A recent study by a London-based security firm, mi2g, analysed 235,000 security

attacks between November 2003 and October 2004. It rated Apple’s OS X and
BSD UNIX as far more secure than both Linux and Windows. It also rated Linux
as more vulnerable than Windows.
Linux distributions
With most Open Source products there is likely to be only ‘one version of the
truth’ in respect of the version of the product and other software that normally
accompanies it. As already mentioned, for Linux there are several different distri-
butions from different organisations, including: Debian GNU/Linux, Mandrake
Linux, RedHat, Slackware and SuSE Linux (from Novell). This has probably hap-
pened because it could but it creates some confusion among potential Linux users,
especially since it is easy to find different Linux commentators insisting that this
or that particular distribution is superior to others.
The danger for an organisation is that a kind of Linux anarchy can break out, with
different flavours of Linux running in different areas of the business. The obvious
antidote to this situation, for corporate users, is to impose standardisation on a
single Linux distribution and stick with it—and likewise to standardise on a sup-
port arrangement.
The commercialisation of Open Source

Proprietary software products are created by software companies and directly mar-
keted to the IT user community. The commercial software model implies (but
does not guarantee) a whole series of business processes and activities, including:
• Marketing to create awareness of the product, including advertising, demon-

stration software, analyst reports, case studies and customer reference lists.
• The maintenance of a product roadmap and regular upgrades to the product,

expanding and enhancing its capabilities and removing known weaknesses.

• The creation of a formal support operation, usually coming with customer

options to provide them with their preferred level of support.
There are other points of difference, but the above are probably the most important.
Note, though, that Open Source products may also have these business processes.
It is particularly notable, for example, that there is a good deal of marketing
activity surrounding Linux (including the fact that it has Tux the Penguin as its
logo), that it has a product roadmap, with distributions providing new releases
with a variety of options to purchase any level of support needed.
The same cannot be said of all Open Source products. Because Open Source
licence fees are low or non-existent, companies that run a business around Open
Source focus on providing services to users. Only if the user base grows to a sig-
nificant size is this likely to lead to long-term commercial success and even then,
the company involved is unlikely to exhibit the rapid growth that often happens
with proprietary products.
There are examples of successful Open Source companies—such as Red Hat,

JBoss and MySQL—while others have struggled. For many businesses the long-
term viability of the vendor is important to ensure product longevity, so this is a
natural consideration when considering Open Source.
It should by now be clear that Open Source is not a passing fad, but a genuine
commercial movement that is unlikely to go away. Conversely, despite the ideal-
istic hopes of some Open Source proponents, it is also unlikely that proprietary
software will disappear.
In fact, as we move to a world where a good deal of software will be sold as a serv-
ice the end-user is likely to have less interest in whether he is using Open Source,
closed source proprietary or a mix of the two. As a business model, ‘software as a
service’ has very little to do with this. The customer simply pays to use the capabil-
ity provided. Such customers may have no interest at all in the source code.

The Open Source licence and legal issues

The GPL
The most important point to note about the GPL is that it is not a commercial
contract. It is really a generally applicable ‘permission’ to use a copyrighted soft-
ware product.
The practice of granting permission to use copyrighted material is well established

in law over many years. For example, writers will sometimes give permission for
their written works to be used without any fee, but will normally attach condi-
tions such as: proper attribution is given and the work is not altered in any way.
The GPL is the same kind of usage licence—for the use of the source code of the
product it covers—and it has conditions attached to it. The most important caveat
with the GPL is that:
If the licensee uses the source code to produce a software product, then that
product too must be issued under the GPL.
In practice this means that if the user enhances the source code and distributes
it, any enhancements made by the licensee to the source code may ultimately
be added to the original product. The GPL was designed specifically to enable
software to be distributed with the source code. The condition that was added
prevents others from violating the copyright and encourages those who do change
the source code to add value to the associated product.
The GPL does not prevent the software it covers from being distributed for a fee.
Neither does it prevent a software company from building complementary prod-
ucts and distributing such products for a fee under a commercial contract. How-
ever, by its nature, it limits commercial exploitation of products that are issued
under it, as most products issued under the GPL are available at no charge from
one or more sources. So companies wanting to profit from Open Source software
need to find other ways to add value.
Software contracts
Some companies accept the GPL as the only licence they need to run Open Source
software. It simplifies administrative activity, as it eliminates some of the compli-
cations of commercial software contracts and licences. With the GPL, there are
no stipulations as to the number of users or how many servers the software may
run on, or any other such constraints. Therefore there is no need to maintain a
register of users or machines or check actual usage against the stipulations of the
licence but the GPL provides no guarantee of support for the software, nor any
commitment to produce regular upgrades to the software. The GPL is not a soft-
ware contract. Even though, for example, it is possible to get Linux support via
the Internet and frequent upgrades are available, the GPL provides no guarantee
that this will always be so.

SCO v IBM
Irrespective of the legal merits, the SCO legal actions against IBM, Novell and
Linux users AutoZone and DaimlerChrysler in respect of Linux, are important
because they have focused attention on the legal issues of Open Source.
SCO’s accusations against IBM are twofold: i) that IBM donated copyrighted
code from UNIX System V (to which SCO claims ownership) to be included
in Linux source and ii) that IBM donated code from its AIX version of UNIX
to Linux source when it had no rights to do so because, allegedly, its contract
with SCO also covered extensions and enhancements to the code base of UNIX
System V.
The case was further complicated by the fact that Novell claimed that it had re-
tained rights to UNIX System V code when it sold it to SCO and that it therefore
had the right to permit IBM to do what it pleased with the code.
SCO also sued two Linux users, AutoZone and DaimlerChrysler. The case against
DaimlerChrysler was resolved with DaimlerChrysler victorious, but the case against
AutoZone is pending, waiting for the action against IBM to be resolved. However
SCO did not sue any of the authors of Linux and has raised no action against
OSDL (the Open Source Development Lab), which controls the Linux source.
IBM counter-sued on a number of points, notably accusing SCO of having

distributed Linux itself under the GPL, after it brought the action, and being
in violation of the Linux GPL. As SCO was selling a ‘SCO Linux Licence’, to
‘indemnify’ Linux users, IBM claimed that SCO was violating the GPL and thus
violating Linux copyright.
From a legal perspective, the cases are complex and it will not be possible to
deduce whether there is any significant legal risk to Linux users until the cases
have been resolved. However, legal opinion (on the Internet) seems to suggest
that the cases against Linux users are doubtful, as there is no precedent. The
case against IBM hinges on what IBM’s contract with SCO actually is and what
rights it covers.
The SCO action prompted the Open Source Development Lab (OSDL), which
manages the development of Linux, to implement a formal audit trail to keep
track of all source code donations in an effort to fully document all code dona-
tions. This can be viewed as a welcome development.
The idea that an Open Source product may violate the source code copyright of a
software vendor may seem strange. With Open Source, the source is there for all
to examine and any Open Source organisation would promptly remove any illicitly
donated code as soon as its existence were pointed out. Open Source ought thus
to be less likely to be subject to copyright theft than proprietary software where
the source is not visible.
One sometimes hears gossip that source code has been stolen from one software
vendor and used by another, but since the source code for commercial products
© Bloor Research 2005 Page 10

is rarely if ever published, it is difficult to know the truth of such rumours. Few
legal actions arise.
The legal, compliance and governance risks of Open Source

SCO has not performed well in its major lines of business since launching its legal
cases and it is difficult to conclude that it was a wise business direction for SCO to
take—although SCO’s Intel-based UnixWare sales were clearly in decline anyway
because of competition from Linux. It now looks as though SCO will be lucky to
survive unless it is victorious to some degree in the courts.
Nevertheless, the SCO action has, in our view, had a positive effect on the Open
Source movement, because it has focused attention on legal aspects relating to the
use of Open Source.
There are two risks that have come to the fore, which are, incidentally, risks that
relate to the use of all software:
a) That a software product may infringe copyright.
b) That a software product may violate a patent
The first risk, as we have noted, is low in respect of Open Source, because the
source code is open and the natural path for any vendor to take (as opposed to the
path that SCO took) in the event of copyright violation, is to request the develop-
ers to remove the offending code.
The second risk is significantly greater. Software developers never do a search

of software patents before they develop code. Where companies have registered
patents, they will normally take legal action to protect their intellectual property
when they believe it has been violated. Many software companies get embroiled in
such legal actions, most of which are settled out of court. Thus far, to our knowl-
edge, no action has ever been taken against any Open Source products—but there
is no reason why such actions could not arise.
In August, 2004, following an analysis of Linux, Open Source Risk Manage-

ment (OSRM) produced a report which stated that Linux potentially infringed
283 separate software patents (over 60 of which were held by IBM). It is likely
that other Open Source products also violate registered patents. From a practical
perspective, a patent is not fully established until its validity has been tested in a
court of law, as there are reasons why a registered patent may be invalid (such as
“prior art”, where someone used the design or idea previously but never registered
a patent).
In the case of proprietary software the software contract will normally indemnify
the user against any such actions. The software vendor does this by contracting
to assume direct liability for any such infringement, litigate the case and pay
damages if it loses. Alternatively it may contract to help any accused company liti-
gate the case, offering resources and/or funds to assist. However, neither outcome
Page 11 © Bloor Research 2005

is likely to occur since the offended party will sue the software vendor rather
than the user. The situation with Open Source is different because the offended
party is unlikely to sue the Open Source development project. The lawyers are
far more likely to ‘follow the money’ and sue a large and wealthy user of the
product.
It is clear from the wide proliferation of Linux and other Open Source prod-
ucts that there are thousands of organisations that are happy to assume this
risk without the protection of a commercial contract or, alternatively, are una-
ware that there is any risk. However there are many businesses and organisa-
tions—and this varies from country to country—that cannot afford to ignore
such risks. Some organisations are required by local law, obliged by industry
best practices or have implemented a company policy that mandates indemni-
fication against such risks. Common industry sectors where this is the case are:
health, finance and financial services, legal and government.
There is also the risk for all organisations of the unintended abuse of Open Source.
Because there is now so much Open Source code (hundreds of millions of lines of
code) available, there is a possibility that development work, either outsourced or
built within the organisation, could embody code stolen from some Open Source
product, exposing the organisation to a mild legal risk—if the use of the code vio-
lates the Open Source licence. We are aware of situations where this has occurred
and been discovered. There have been no legal implications but there could be if
the software being developed were eventually sold to others.
Open Source contracts and indemnification

Following the launch of the SCO case, HP was quick to offer legal indemnity in
the Linux contracts it provided and Novell quickly followed. Red Hat offered a
warranty. IBM, the focus of the SCO legal case, took the view that indemnifica-
tion of Linux was unnecessary (at that time)—possibly because it saw itself as
fighting the battle on behalf of Linux users in the courts anyway.
The provisions of these Open Source contracts are likely to change with time, as
do all software contracts, and will vary from country to country just as commer-
cial law varies from country to country. But it has become clear that many large
organisations want or need commercial contracts for Open Source products. So
the market is now providing them.
In our view the commercial interests of too many IT vendors are now tied to
Open Source products for indemnification to remain an issue once the SCO v
IBM case has been resolved. A commercial arrangement that satisfies all IT users
will be available. However, such indemnification will bear a cost.
It is also interesting to note here that all software providers (proprietary or oth-
erwise) offer little effective legal protection against defects in their software. This
ought to be a far larger issue in software usage than indemnification, but it has
not been so, so far.

Compliance and governance

The pressure on IT both from government regulation and from industry sector
compliance initiatives has increased dramatically in recent years, especially in the
US. This is partly due to IT security emerging as a major problem because of what
connectivity to the Internet may deliver, and partly due to IT becoming more
integral to nearly every business as time passes. One consequence of this is a focus
on the governance of IT and the implementation of best practices in many areas.
Irrespective of whether the pressure comes from industry regulation or senior

management, Open Source products will need to comply with local policy and
fall in line with commercial best practice. The likelihood in the medium term is
that companies will be responsible (to their shareholders via an annual audit) for
responsible IT governance. It is thus probable that large organisations, at least,
will need to have formal legal contracts that cover their use of Open Source prod-
ucts along with formal support arrangements to ensure an adequate level of sup-
port. Our expectation is that these will turn out to be unavoidable costs of Open
Source and proprietary software alike.
Naturally, which products will require what kind of coverage will depend on how
central the use of such products is to an organisation.

The corporate use of Open Source products

The common barriers to Open Source adoption
In this part of the paper we focus on the practical use of Open Source products,
beginning with the barriers to adoption. Unsurprisingly, many of the barriers
to adoption are the same for both Open Source and proprietary software. These
‘common barriers’ are as follows:
a) Inertia: Many sites, for conservative reasons, do not adopt a new technology
until they find compelling reasons for doing so. Thus, a number of IT sites
have found no irresistible need to be involved with any Open Source prod-
ucts.
b) Cost of change: The cost of adopting any new software product is never zero,
even if there is no licence fee. Consideration of the likely cost is thus a barrier
to Open Source adoption. We consider this in more detail later.
c) Strategic: Many IT sites pursue a policy of standardisation to specific plat-

forms, databases, development software and so on. This ensures some prod-
ucts are excluded from even being considered in some contexts. To this can
be added the fact that the longevity of a product is a concern for large IT
shops. Thus a specific product might be ignored because “it doesn’t look as
though it will be around in 5 years time”. (Note: This is a two-edged sword
since it may also be that the incumbent software is too long-in-the-tooth
with inflexibility to satisfactorily meet future needs.)
d) Standards compliance: The product may not abide by the local standards
that the organisation has mandated for this particular type of product.
e) The availability of complementary software: We have moved into a world

where software integration is a significant issue. The adoption of any plat-
form (such as Linux) is thus dependent on the availability of an appropriate
software stack (such as security software and system management). This is
true to a lesser extent for other products such as databases and application
servers.
Specific Open Source issues

We see the following issues, many of which we have already touched on, as
particular to Open Source. Our advice is that organisations considering the
use of Open Source products consider each of them when evaluating a product
for use.
a) Legal concerns—indemnification: Our view is that the legal issues of Open

Source have been overblown. Organisations that feel they need indemnifi-
cation, or are obliged to have it, should simply consider it a cost of Open
Source adoption.

b) Legal concerns—source code usage: Unfortunately there are a multitude of

different Open Source contracts other than the GPL, so no definitive state-
ment can be made here. As such, potential users who intend to change the
source code of an Open Source product need to read the licence and under-
stand whether its stipulations impact on its intended use of the code.
c) Longevity: It is worth noting that the longevity of some established Open

Source products (Linux, Apache, Samba, and so on) is a given. The early
adoption of new Open Source products is, in our view, just as risky as the
early adoption of any other infant technology. A good litmus test for Open
Source products is whether they have the backing of any major vendor (such
as HP, IBM, CA or Oracle)
d) Product roadmap: The more established Open Source products do provide

a product roadmap just as commercial vendors do. However, this is rarely
the case with lesser products. Knowing the intended direction of a product is
clearly important to many users.
e) Marketing: Although there are now many exceptions, as Open Source increas-
ingly imitates or becomes commercial software, the marketing of Open
Source products is generally weak—often confined to a combination of web
sites and word of mouth/viral marketing. This is partly because develop-
ment is often controlled by not-for-profit organisations with small budgets.
A consequence is that assessing the merits of an Open Source product by
familiar mechanisms such as attending shows or webinars, reading marketing
brochures, surveying customer lists, reading analyst reports and so on, may
not be an option.
f) Sales process: With most Open Source products, especially those that are free,
there is no established sales process (obviously). This leaves potential users to
ferret out information (about support, training, compatibility issues, and so
on) without carrying out a dialogue with any devoted sales individual.
The advantages of Open Source

Open Source advocates usually insist that cost is the major advantage of Open
Source, citing various studies and user experiences, while its opponents claim
otherwise. We prefer to treat this as a point of debate, because of the many dif-
ferent contexts in which Open Source products may be used. In our view, it is
too simplistic to say that Open Source is less expensive than proprietary options
simply because there is no licence fee.
Aside from this, there are, in our view, some distinct advantages to Open Source
products. We believe they are as follows:
a) Transparency and responsiveness: The Open Source development process

is transparent, and in general (although there are exceptions) Open Source
developers are very responsive to user requests. This may lead to more appro-
priate features being included—and more quickly.

b) Informal support: Most Open Source products are surrounded by a re-

sponsive informal web-based support network. This is not, in our view, an
acceptable substitute for formal support but it is a welcome bonus for these
products.
c) Software quality: Our own experience bears out the proposition of Eric Ray-
mond, that the ‘Bazaar’ development methodology produces high quality
software.
d) An Open Source stack: A stack of Open Source products, which are com-
plementary and integrate well, has now emerged (on the server). The col-
laboration between providers of different components usually means that
integration is superior to a varied stack of proprietary products.
The cost of Open Source

There have been many different studies that compare the costs of Open Source
with the costs of proprietary computing. Many of these have been direct cost
comparisons between Windows and Linux, with estimates of the TCO imply-
ing that one or other option is less expensive. To our knowledge two types of
study have been done; general studies which try to compare overall costs and
specific studies which are in effect case studies, where one product has replaced
another for a specific purpose, such as running an email service or running a
web site.
The general studies suffer from the problem that the results will depend on what is
included and excluded, while some factors such as relative costs for staff is a mov-
ing target and others are subjective. They are also difficult to apply directly to any
one company’s specific situation, since all are different.
Case studies are most useful when they are evaluations that have a similar require-
ment to the company who is interested.
Readers will be able to find both these types of studies on the Internet with little
difficulty—but there will also be many detractors who argue with their results.
In our view, a more rational way of considering the question of Open Source costs
is to consider the adoption process.
The adoption process

It is important to think in terms of the big picture. It is now the case that most
sizable IT sites have a mix of Windows servers, Linux servers, UNIX servers and
often more besides.
But let us first consider the situation where Linux has never previously been
used. In such a site a migration to Linux will involve all the usual migration/
adoption costs, with the possible exception of licence costs. The following list
still applies:

Installation costs, system management costs, direct support costs, training costs,
consultancy costs, recruitment costs (for staff with the appropriate skills), security
costs and other integration costs (including possibly the purchase of non-Open
Source support products).
Cost savings will be made only where these costs are lower than the equivalent
costs for Windows (or UNIX or whatever alternative platform is being consid-
ered). In most situations that is very unlikely to be the case, simply because system
management costs, training costs, consultancy costs and recruitment costs will
inevitably be higher (perhaps much higher) in adopting a new platform than stay-
ing with the same one.
If this were the only consideration for adopting a new platform then, of course,
no new platform would ever get traction. (It is generally true that new platforms
rarely emerge for this very reason. The only two really successful ones to have
emerged in the server space in the last 15 years are Linux and Windows.)
However, the adoption of a new platform by an IT department is usually applica-

tion driven—with the company adopting the platform as a consequence of need-
ing a specific application that only runs on that platform. An extra catalyst is
sometimes that an upgrade is required for the existing platform, which could itself
be expensive, particularly if some hardware upgrading is also needed as a result.
(Thus, moving to Linux might avoid hardware upgrade costs.)
Linux also has a common extra route of access. It frequently occurs that an engi-
neer in the IT department sets up a Linux server (often with other Open Source
products) using old hardware as a ‘quick and dirty’ solution to a particular prob-
lem. In well managed IT environments, covert adoption of Linux should not
occur in this manner because such implementations almost certainly violate IT
policy, but it happens anyway.
Once an IT department has accepted the use of a particular platform, there are,
or should be, guidelines established as to where it will be used. In the normal
course of technology evolution IT departments will tend to focus on only a few
platforms for general usage—often as a tactic for keeping suppliers in competition
(e.g. “We have Windows and Linux so we have price negotiation leverage over our
suppliers.”)
Once an IT department is in this position, it can examine and define its own total
cost of ownership (TCO) from its own experience for any given platform, then
choose which platform to focus on or to emphasise. Thus, in reality, external mar-
keting studies that claim differences in TCO between one platform and another
are unlikely to play any significant part. The role of such studies is more about
attracting customers into or away from becoming adopters.
Further expansion in the use of any particular platform is likely to happen on an

application-by-application basis. Say, for example, the email system is being re-
viewed in an effort to see if costs can be cut. In such circumstances, options using
both platforms will be evaluated and costed, but the general costs to the whole
installation will probably not be part of the equation.

Open Source adoption by stack

Much of the above discussion relates primarily to Linux as a platform. We should
note however that many Open Source server products run on Windows and
UNIX platforms. We have already referred to the fact that there are many comple-
mentary Open Source products, indeed that a fairly comprehensive Open Source
stack (OS, web server, file server, database, middleware) is emerging.
Some companies may choose to adopt some or all of this stack, and may even
choose not to run it on Linux. The act of adopting such a stack is clearly different
to the adoption of the Linux platform. However the adoption issues are the same
as we listed above:
Installation costs, system management costs, direct support costs, training costs,
consultancy costs, recruitment costs (for staff with the appropriate skills), secu-
rity costs and other integration costs (including possibly the purchase of non-
Open Source support products).
We note here that the decision to adopt such a stack for in-house development
or fundamental operational infrastructure is a strategic one—just as strategic as
the decision to deal with a primary vendor such as Microsoft, IBM, HP, Oracle,
and the like—although it may not seem to be so. In such situations it is the
full cost of the stack that matters. Companies adopting such a stack will rightly
prefer to take support services (from maintenance through to consultancy) from
a single source.
Open Source adoption by product

Finally we can consider Open Source adoption on a product basis. Here the
consideration is simple because there is very little difference between an Open
Source product and a proprietary product, so the usual product selection criteria
apply—including quality of offering, support, skills, manageability and consul-
tancy assistance.
The desktop, as distinct from the server

It is indisputably the case that Open Source is far more mature on the server.
The same adoption drivers exist, but the major Open Source desktop applica-
tions (office software, email, browsing) are less mature than the server products
in most instances, and the adoption costs are likely to be higher because they will
involve a significant amount of user training (which is not the case in adopting
most server software).
While Open Source enthusiasts often recommend the use of OpenOffice, the
current reality is that adopting this software for power PC users undoubtedly has
a high cost because of the complex use made of some office products (particularly
Microsoft Excel) in many organisations. In our view, the Open Source desktop
still has a way to go before it becomes a compelling proposition for many.
However, there are other ways that adoption of Open Source on the desktop oc-
curs. The popular Open Source browser (Mozilla Firefox) gained traction because

it was quick to deliver compelling features (tabbed browsing, pop-up blocking

and so on). It runs on Windows as well as Linux. Many PCs within organisa-
tions are not extensively used, so some organisations have deployed Open Source
configurations to replace some of their PC population, using the old PCs as
thin clients that run little more than a browser and email. In such circumstances,
which particular desktop OS is best to use comes down to manageability, more
than anything else.
In our view, there is not, at the moment, a complete Open Source stack for the
desktop, but we do not expect it to be long before one emerges to gain some popu-
larity. When it does, we expect a level of adoption of such a desktop to occur with-
in organisations in an effort to provide bargaining leverage against Microsoft. In
all probability this will happen through low end PCs, rather than executive laptops
and powerful PC configurations. This, in turn, will lead to familiarisation with
some Open Source products and the consequent removal of some user inertia.

Contributors to the Bloor Research Open Source event

JBoss
JBoss is the provider and supporter of the JBoss Enterprise Middleware System,
which is becoming a popular Open Source product/platform with multiple com-
ponents. More than 5 million copies of the source have been downloaded. The
company claims that its product is used by over 250,000 developers. The core
team of developers includes over 30 JBoss employees, but product development
has involved over 500 contributors since development began.
Based on a TogetherSoft User Survey, JBoss claims to have 40% market share.
According to a BZ Research survey it has 27% market share in terms of produc-
tion systems (Sun/TMC Survey gives a figure of 19%). According to a Forrester
Total Economic Impact Analysis it delivers an ROI of 271%.
It can legitimately claim to be one of the Open Source successes.
JBoss customers
The JBoss customer list includes many companies that run mission critical ap-
plications using JBoss Open Source products. Examples include DGI (the French
Inland Revenue Service), La Quinta Hotels, NLG, Acxiom, and Nielsen Media
Research
Professional Open Source

JBoss is keen to promote the idea of Professional Open Source. Its view is that the
first generation of commercial Open Source products were based on the simple
business model of packaging source code and offering an unsophisticated level
of support. It characterises itself as one of the second generation of Open Source
businesses, which have grown up since 2000, which it describes as “Professional
Open Source”.
Summarised, the characteristics that distinguish “Professional Open Source” com-

panies are:
• Vendor/provider is financially sound, has professional management and pro-

vides professional marketing and productisation (including a product road-
map and product release schedule).
• Provides full software support including 24x7 coverage and also indemni-
fication.
• Provides professional training and services.
• Has an active channel partner program to create commercial channels to

customers. (Open Source itself is a powerful viral channel).
• Full (and transparent) methodology for Open Source development, involving a

core team of developers, a development community, customers and partners.

• Commitment to industry standards.
• The product has been implemented successfully in enterprise environments.
In other words, Professional Open Source is a natural commercial evolution of the

first generation of Open Source products.
Hewlett-Packard
Hewlett-Packard (HP) is the world’s number one Linux server supplier both in
terms of shipments and revenue, describing its Open Source business as $2.5
billion and growing. Thus it is very committed to Linux and Open Source in a
number of ways, while also maintaining strong support for Microsoft Windows
and its own proprietary operating environments.
One of the key concerns with the Linux environment when compared with
Windows is that, whereas Windows has a very integrated middleware stack, the
Open Source middleware that sits on Linux comes from a variety of third parties.
HP has addressed this head-on at the server level by defining Linux Reference
Architectures (LRAs). These consist of HP server and storage hardware, plus a
set of one or more software products for which HP provides full testing to ensure
compatibility. It then offers full 24x7 support for all the products included in the
reference architecture.
HP’s stated purpose in doing this is to make deploying Linux-based systems as

risk-free as possible. It directly addresses the concerns expressed in a Forrester
Research 2003 survey of 50 $1billion+ companies using Linux. They were asked
what stopped people deploying Linux. 46% raised lack of support as a problem
with 32% citing product immaturity.
An LRA starts with an Open Source foundation, built on either Red Hat or
SuSE Linux distributions plus specific agents, drivers and kernel features. The
next level ‘approved’ management and availability tools are so far only those
from HP including HP OpenView, while VERITAS NetBackup is the backup
software.
At the top of the stack is a mix of Open Source and proprietary middleware from
partners—which HP splits into ‘solution applications’ (currently BEA WebLogic,
Oracle, MySQL and JBoss) and ‘workload-specific software’ (Tomcat, Jabber and
OpenLDAP).
This list of supported products can grow, and HP offers indemnification for us-
ers of an LRA, allowing them to focus on Linux usage rather than on litigation
protection.
HP is a sponsor of a number of Open Source bodies—Linux International, the

FSF, the Free Standards Group, the Open Source Software Institute and the
OSDL. It also provides dedicated personnel or support to Open Source projects

such as the Linux kernel, Eclipse development environment, Samba and Apache,
and project leadership for Debian Linux.
In providing a Linux Reference Architecture, HP is delivering important added

value to those that wish to consider Open Source options for mission critical us-
age. It gives the customer a reason for confidence in the Open Source software
and a single point of complaint in the event that the reference architecture fails
to deliver.
Computer Associates
Computer Associates (CA) is one of the world’s largest software companies and
very long-established. When Open Source products began to gain traction in
the software market, it had to consider carefully the impact on its business, and
inevitably took a very hard-headed look. Licence and support revenues were
likely to be negatively impacted in the medium term and, in many respects,
Linux was just another operating system to support. It had come to use Open
Source quite extensively internally but nevertheless exclusively used what CA
calls a “closed innovation model” for the applications it sold and supported.
However, CA realised it could lose out on some important opportunities by
holding rigidly to this.
CA’s own survey of some 400 large companies revealed that a major migration
to Linux was occurring from both UNIX (20%) and Windows (25%), but most
startling to the company was that 0% (zero) said they had no plans whatsoever to
move to Linux.
It has now settled on a pragmatic approach, embracing Open Source where it sees
genuine benefits for its customers and commercial means of supporting its use,
while also maintaining closed source development for most of its products.
The most notable example of its move towards Open Source was CA’s surprise re-
lease to Open Source early in 2004 of the latest version of its well-respected Ingres
database. Ingres is unusual in that it sits as the enabling technology for many of
CA’s other software applications as well as having a long established user-base. So
CA already had the Ingres enterprise support infrastructure in place—but Ingres
was attracting very little new commercial usage as either a mission critical database
or a general purpose database.
Benefits that CA envisages in moving any of its products to Open Source include
achieving a shorter time to market for innovations than could be typically achieved
using the closed innovation approach. The combination of internal and external
development could also reduce the research and development (R&D) costs, in
turn generating more profits.
CA also believes external ideas to be healthy in enriching a product, with the

tendency for the software to take on board the right features for users when the de-
velopment process is open. These are potential benefits for any high-profile Open
Source software, which counter the likely loss of product licence revenues.

Validating its approach, CA found that Ingres had attracted more interest from
both existing and new clients in the six months after the move than in the whole
of the previous year and expects increased revenue in the future.
Other Open Source activities by CA include assisting in the formation of the Open
Source Plone Software Foundation for creating high quality software for content
management. This has a board of nine directors including two from CA. The com-
pany intends to expand its work with software foundations. This should serve to
help plug gaps in the portfolio of enterprise-quality Open Source software.
OpenForum Europe
As has been identified, Open Source is not a brand so has fragmented—and in
some cases non-existent—marketing for its software products. OpenForum Eu-
rope was formed as a not-for-profit organisation to provide a voice for Open
Source where none existed, especially within some European governments but
also for business in general. Members are drawn from user and supplier com-
munities.
Despite its stated mission, the organisation insists it is not against any one com-
pany, but rather it is in favour of a business model that is more effective, providing
more choice and real competition—which should in turn lead to lower total cost
of ownership (TCO).
According to OpenForum Europe, open standards is what is most important, so

that software can co-exist and interoperate; businesses that do not go (or go back)
to an open standards strategy are failing in their IT strategy. This is because a
monopoly position rarely works well in extending performance and (especially in
government) proprietary formats can get in the way of sharing information across
departments. Open Source, by its very nature, operates in accordance with open
standards, so the two are closely connected.
However, OpenForum Europe sees Linux on the server as now well accepted,
with Open Source software happily co-existing with proprietary applications. But
the situation on the desktop is much closer to being a monopoly and so more
difficult to address.
OpenForum Europe has reported some dramatic Open Source desktop success-
es. One, from a hospital in the Republic of Ireland switched from Windows to
thin clients on the desktop. Its TCO estimate for five years was €369,000 versus
€8,450,000 by staying with its existing supplier and having to upgrade to more
expensive hardware—a saving of over 95%.
In fact, OpenForum Europe favours a move to thin client as a separate desktop

strategy, for instance using the Linux Terminal Server Project (LTSP). This ena-
bles re-use of otherwise obsolete hardware or new hardware costing much less than
‘fat client’ PCs. Other cost and environmental benefits are lower heat, power and
air conditioning needs. Greater hardware longevity also reduces disposal—now a
critical issue under the new WEEE legislation.

OpenForum Europe’s experience is also that moving to Open Source on the

desktop requires extra investment in planning, including detailed consideration
of migration and interoperability issues, (re-)training of users and development
skills. Typically some ‘power’ users of Microsoft Office products cannot as yet
easily migrate to OpenOffice for instance, where the Open Source office suite still
lacks some functionality. But these users can be served by a dual-boot capability.
In summary, OpenForum Europe believes that organisations should recognise

where there is any lock-in and start planning to remove it in favour of open stand-
ards. Choice is emerging for desktop users, but migration decisions should be
based on the specific organisation’s requirement.
Note: Input was invited but not received from Microsoft and IBM.

Copyright & Disclaimer
This document is subject to copyright. No part of this publication may be repro-
duced by any method whatsoever without the prior consent of Bloor Research.
Due to the nature of this material, numerous hardware and software products
have been mentioned by name. In the majority, if not all, of the cases, these
product names are claimed as trademarks by the companies that manufacture the
products. It is not Bloor Research’s intent to claim these names or trademarks as
our own.
Whilst every care has been taken in the preparation of this document to ensure
that the information is correct, the publishers cannot accept responsibility for any
errors or omissions.
Suite 4, Town Hall, 86 Watling Street East
TOWCESTER, Northamptonshire, NN12 6BS, United Kingdom
Tel: +44 (0)870 345 9911 – Fax: +44 (0)870 345 9922
Web: www.bloor-research.com – email: info@bloor-research.com

What Dya Mean Free Software - Open Source

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

What Dya Mean Free Software - Open Source

Загружено:

Авторское право:

Доступные форматы

What d’ya mean, free software?

a review of Open Source, the Pros and Cons

Author: R. Bloor & P. Williams

What is Open Source?

The Origins of Open Source

• Run the software for any purpose

• Modify the software

• Redistribute the software

Page  © Bloor Research 2005

• The Cathedral model—where source code is confined to an exclusive group

Open Source is not a Brand

© Bloor Research 2005 Page 

Linux is an example of an Open Source product—the best-known example of

Page  © Bloor Research 2005

The Linux dynamic

© Bloor Research 2005 Page 

A sign of the impact of Linux is Sun Microsystems’ recently announced intention

The appeal of Linux

Page  © Bloor Research 2005

Perhaps most important, Linux has generated, or is generating, software ecosys-

Likewise, developers of any product can be pretty much guaranteed to introduce

© Bloor Research 2005 Page 

A recent study by a London-based security firm, mi2g, analysed 235,000 security

The commercialisation of Open Source

• Marketing to create awareness of the product, including advertising, demon-

• The maintenance of a product roadmap and regular upgrades to the product,

Page  © Bloor Research 2005

• The creation of a formal support operation, usually coming with customer

There are examples of successful Open Source companies—such as Red Hat,

© Bloor Research 2005 Page 

The Open Source licence and legal issues

The practice of granting permission to use copyrighted material is well established

Page  © Bloor Research 2005

IBM counter-sued on a number of points, notably accusing SCO of having

© Bloor Research 2005 Page 10

The legal, compliance and governance risks of Open Source

a) That a software product may infringe copyright.

b) That a software product may violate a patent

The second risk is significantly greater. Software developers never do a search

In August, 2004, following an analysis of Linux, Open Source Risk Manage-

Page 11 © Bloor Research 2005

Open Source contracts and indemnification

© Bloor Research 2005 Page 12

Compliance and governance

Irrespective of whether the pressure comes from industry regulation or senior

Page 13 © Bloor Research 2005

The corporate use of Open Source products

c) Strategic: Many IT sites pursue a policy of standardisation to specific plat-

e) The availability of complementary software: We have moved into a world

Specific Open Source issues

a) Legal concerns—indemnification: Our view is that the legal issues of Open

© Bloor Research 2005 Page 14

b) Legal concerns—source code usage: Unfortunately there are a multitude of

c) Longevity: It is worth noting that the longevity of some established Open

d) Product roadmap: The more established Open Source products do provide

The advantages of Open Source

a) Transparency and responsiveness: The Open Source development process

Page 15 © Bloor Research 2005

b) Informal support: Most Open Source products are surrounded by a re-

The cost of Open Source

The adoption process

© Bloor Research 2005 Page 16

However, the adoption of a new platform by an IT department is usually applica-

Page © Bloor Research 2005

© Bloor Research 2005 Page

Page © Bloor Research 2005

© Bloor Research 2005 Page

Page © Bloor Research 2005

© Bloor Research 2005 Page

Page © Bloor Research 2005

© Bloor Research 2005 Page

Page © Bloor Research 2005