Introduction by the author, Carlo Daffara

May I request your input? This article is part of our research in the EU project FLOSSMETRICS, where we are preparing a guide for helping small and medium-sized enterprises on the adoption of free/libre/open source software (FLOSS).
As the first version of the guide will be ready soon, I would ask my fellow Groklawers for suggestions on what additional aspects you would like to see in the guide, as the results will be freely published under a CC-attribution-share-alike, allowing also for commercial use. We already have planned chapters on software selection, adoption methodologies (especially for the smaller companies), guidelines for contributing code to FLOSS projects, interaction with public administrations, and an initial selection of 50-60 interesting packages for SMEs. I welcome suggestions on additional topics, and of course criticisms and corrections.

* * *

10 Myths About Open Source Software Answered

In
1999, Tim O'Reilly, founder of a popular open source-oriented
publishing house, gave a keynote speech to an audience of Fortune 500
executives called "Ten Myths about Open Source Software".
As those myths are still perceived as true today by some, as shown by recent reports1, and are still perceived as a barrier
towards FLOSS adoption, we will try to provide here some pragmatic
answers:

Myth #1: It's a
Linux-vs-Windows thing.

Recent debates about FLOSS continue to be focused on an
all-or-nothing perception; that, for example, to introduce FLOSS in a
company, a full software migration is required. This, and the fact
that there is limited knowledge of FLOSS projects outside of a very
widely known ones (like Linux, Apache, OpenOffice.org), has created the
perception that most of FLOSS is designed and directed as a direct
competitor of Microsoft's own products. The reality is that there is
an enormous number of active projects in practically every field of
IT, including business-specific ones like ERP systems, and most of
these projects are cross-platform, and can be executed on Microsoft
Windows, Apple's OSX (which is itself based on more than 300 open
source projects) or Linux. (For an estimate of the size of the FLOSS
project panorama, see Estimating the number of active and stable FLOSS projects).

Myth #2: FLOSS is not reliable or supported.

This myth is based on a common perception that FLOSS is
exclusively developed by volunteers in a non-coordinated or
unstructured way. There are many errors in this view:

The volunteer perception: While volunteer contributions are a
significant part (and sometimes the majority) of large-scale
projects, around 50% of developers have received a financial
compensation for working on FLOSS projects, either directly paid to
improve the projects or paid to support them. This has been shown in
recent studies2
and can be inferred directly by the fact that in the software
industry at large, 68% of software products include directly
FLOSS-derived code.

Paid programmers are better: Even for the percentage of
contributions that do come from volunteers, it is commonly
perceived that those should be of inferior quality, as there is no
financial incentive to produce quality software. This ignores the
fact that intrinsic incentives are in many cases more effective than
monetary compensation, and the fact that sometimes users are
interested in improving the software that they are using3.
This second effect, called user-driven innovation, has been shown in
past research to be a significant force. For example, around 25% of
innovations in fields like software security, printed circuit boards
CAD systems, and library software were designed and introduced by
advanced users. The same effect provides a fundamental design
feedback, as a large project collects both good and bad experiences in
using the software (for example, the Ubuntu Linux "Testimonial
and Experiences page" that allows for a form of user-driven
"steering" of the project and the identification of
trouble points.

There is no support: Most large scale project do have
companies that provide paid-for support, in a way similar to that of
proprietary software companies. The availability of the source code
and the modification rights gives also the additional advantage that
support can be obtained even for projects that are no longer active,
in stark difference with proprietary software where no code escrow
clause was included in the acquisition contract.

FLOSS is inherently unreliable: Many believe that FLOSS is inherently of lesser
quality when compared to proprietary software. The reality is that
most FLOSS projects are controlled with at least a semi-strict
structure, and only very modular projects are inherently
"bazaar-style" and allow for large scale internal
decoupling. In any case, the impact of FLOSS-style development has
been assessed in several research papers, and for example in a
software engineering article we found4:

"The hypothesis that open-source software fosters more
creativity is supported by our analysis. The growing rate, or the
number of functions added, was greater in the open-source projects
than in the closed-source projects. This indicates that the
open-source approach may be able to provide more features over time
than by using the closed-source approach. Practitioners interested
in capturing market share by providing additional features should
look to the open-source methodology as a method to achieve this. In
terms of defects, our analysis finds that the changing rate or the
functions modified as a percentage of the total functions is higher
in open-source projects than in closed-source projects. This
supports the hypothesis that defects may be found and fixed more
quickly in open-source projects than in closed-source projects and
may be an added benefit for using the open-source development
model."

This is consistent with results from vendors of
software defect identification tools like Reasoning, that found that
while the bug density ratio in initial project releases is on par
with proprietary developments, it improves rapidly and for some
projects defect densities have been found to be significantly lower
than that of the average proprietary code. For example, Reasoning
found in a study of MySQL:

"At
a defect density of 0.09 defects per KLOC, the version of MySQL we
inspected has a defect density that is about six times lower than
the average of comparable proprietary projects.”

This was confirmed by other studies like the reports from Coverity.

The fact that FLOSS is overall reliable can be inferred by surveys
like the already mentioned CIO Insight survey, where 79% of
respondents answered positively to the question "My company's
experience with open source products other than Linux has been so
good we plan to expand their use".

Myth #3: Big companies don't use Open Source
software.

This is the easiest myth to dispel: Apart from the large IT companies that
are actively promoting Open Source software like IBM, HP, Sun, and
Oracle, about 86% of Fortune 1000 companies are deploying or testing
FLOSS, and a similar measure is found in Europe5.
Of those, 35% or more are deploying more than 20% of their systems as
FLOSS, and 11% of companies report more than 20% of their
applications as being Open Source software. While usage in server-centric
and IT infrastructure is more common, around 26% of large companies
are mentioning the use of Linux on the desktop, and a much larger
percentage are reporting the use of other FLOSS like OpenOffice.org
and Firefox on Microsoft Windows desktops. A curious fact that is also evident
from other surveys is that many companies and public administrations
are not aware of their internal use of FLOSS, sometimes for simple
ignorance of the licensing terms and sometimes because the product is
offered or embedded in what seems a traditional proprietary offering
(for example, many security and networking products use FLOSS
internally).

Myth #4: Open Source software is hostile to
intellectual property.

There are several aspects to this myth:

The GPL license is "viral": The most widely used
license does have a specific clause that when a software product
that is derived from GPL software code is redistributed, the entire
product must be distributed under the same license. This has
prompted some to claim that the "viral aspect of the
G.P.L. poses a threat to the intellectual property of any
organization making use of it". The reality is that for most
scenarios, this clause simply provides a way to prevent
appropriation of code without giving back contributions or credit,
and this is also one of the reasons why many developers *prefer* the
GPL to other licenses. Simple *use* of Open Source software in itself
does not require any change to the license of internally developed
software, and most companies routinely run proprietary software on
top of GPL-licensed code like the Linux kernel.

The Free Software community steals the
intellectual property of other companies: This is the byproduct
mainly of litigation by the SCO Group company that in 2003 claimed
that IBM improperly included copyrighted material in the Linux
kernel. In the original claim, it was alleged that IBM "put
SCO’s confidential and proprietary information into Linux, the
free operating system" and that within the kernel several
million lines of code were taken from SCO's Unix source code. However, the public was not told where that allegedly infringing code was found, nor were requests from the community for that information answered. Now,
four years later, no millions of lines of code have materialized in the litigation, and the court in August of 2007 found that the UNIX and Unixware copyrights SCO claimed to have obtained in 1995 in fact did not transfer to SCO from Novell. Even if the copyrights belonged to SCO, there are
less than 300 lines of code at issue in that case in the end, and it's mostly standard interface code that many believe would be found to have no copyright protection no matter who owns it. That's 300 lines of code out of more than 6 million lines of code in the Linux kernel.

Subsequently,
Microsoft issued similar allegations, only regarding patents, with Microsoft's CEO Steve
Ballmer claiming that Linux "uses our patented
intellectual property". However, once again, no specificity was provided. (See also
Craig Mundie, Microsoft's vice president, speech at
New York University's Stern school of Business in 2001, where he said that releasing source code into the public domain is "unhealthy", causes security risks and "as history has shown, while this type of model may have a place, it isn't successful in building a mass market and making powerful, easy-to-use software broadly accessible to consumers".
Bill Gates said that the
GPL "makes it impossible for a commercial company to use any of
that work or build on any of that work", and Steve Ballmer famously said:
"Linux is a cancer that attaches itself in an intellectual
property sense to everything it touches ... if you use any
open-source software, you have to make the rest of your software
open source".)

The
reality is that structured FLOSS projects do have a strict patch
acceptance policy, and as an example the Eclipse project has a
strict due diligence process, that covers external contributions,
code rights assignments, code review and license compatibility. The
Eclipse foundation also uses automated tools to check for code
copying, keyword scanning for words with legal significance and a
controlled release review prior to updating the code. Similar
processes are in place in other FLOSS projects6

Myth #5: Open source software is all about
licenses.

While FLOSS as a definition covers principally the licensing
regime, by extension the "openness" of the code introduces
the possibility of sharing development efforts among different
groups, in a way similar to those of the early user groups of the
sixties. In this sense, Eric Raymond introduced in his seminal paper
"The Cathedral and the Bazaar" the concept of shared
development, contrasting this "bazaar" style where every
developer is free to choose on what part of the code to work, in
contrast to the "cathedral" or formalized development
approach that is rigid and structured.

While the concept took hold quickly, the reality is that
collaboratively developed projects tend to be executed in a continuum
between cathedral and bazaar. For example, for most projects there is
a formal structure (with many sub-projects, more open to external
contributions) while other are strictly formal (for example, projects
that use FLOSS code for use in a certified environment like avionics
or safety-critical systems). The important point raised by Raymond is
the fact that both coding and ancillary activities like bug fixing
and production of documentation can be shared in a large community,
creating in a sense "virtual software houses" that in a
voluntary way provide effort and resources. This helps also in
the leverage of a large community of expert users, that can
contribute back in a significant way, as shown in the articles from
Von Hippel.

When such collaboration takes place, it may be not only in the
form of source code, as for example7:

"In the year 2000, fifty outside contributors to Open Cascade
provided various kinds of assistance: transferring software to other
systems (IRIX 64 bits, Alpha OSF), correcting defects (memory leaks…)
and translating the tutorial into Spanish, etc. Currently, there are
seventy active contributors and the objective is to reach one
hundred. These outside contributions are significant. Open Cascade
estimates that they represent about 20% of the value of the
software."

Open Cascade is a complex and sophisticated toolkit
for the creation of 3D CAD/CAM systems.

A similar view has been presented in a presentation by Aaron Seigo at
the Akademy KDE conference in 2006, where he presented the areas where
volunteers collectively contribute to KDE:

Artwork

Documentation

Human-computer interaction

Marketing

Quality Assurance

Software Development

Translation

If overall software suitability to the task is considered, it is
clear that non-code contributions are as important as source code;
for example, translations, documentation and overall quality are
vital for the software to be adopted by end-users worldwide.

This form of collaboration can happen even between competing
companies; for example, notices of potential security vulnerabilities
are commonly shared among different competing Linux vendors. As an
example, Mark Cox of Red Hat (a widely used distribution of Linux)
analyzed the results of two years of incident responses, and provided
the sources for the information, and found that the largest source of
vulnerability disclosure was the group of peer FLOSS distributors.

Myth #6: If I give away my software to the Open
Source community, thousands of developers will suddenly start working
for me for nothing.

There is no guarantee that simply "dumping" source code
on the community will make a FLOSS project appear, and there have been
several examples of such behavior to be viewed even negatively, because the
community may see this as "garbage dumping" of code. The reality
is that for a collaborative community to form, there must be first of all a
good communication and interaction strategy and effort in place as a
basic requisite. Also, investing in community creation and
dissemination efforts does also increase the probability of a
bidirectional effort sharing. It is important to mention that surveys
like OSSWatch or CIO Insight found a significant proportion of
companies and public administrations (between 14% and 25%) contribute
back patches or participate actively in FLOSS communities.

Myth #7: Open source software only matters to
programmers, since most users never look under the hood anyway.

The fact that most users are not interested in the source code
does not imply that having the source code available in itself is
useless. Several positive aspects can be identified:

The availability of the code allows the end user to
pay someone for modifications or ongoing maintenance
even if the original FLOSS project disappears or becomes inactive.

"Under the hood" there is not only code, but much
non-code artifacts that are vital to a project, like translations,
documentation, examples and much more. Many users can contribute in
such aspects even as non-programmers.

For some projects, having the code available allows for a
significant cost reduction or dramatically increases the flexibility
of the offered solution. For example, in a project called MuleSource
(a sophisticated middleware system) it was found that 64% of users
perform at least one source code modification.

The important difference with the proprietary world (when
sometimes code can be evaluated, but not changed or modified in any
way) is that the code is not just a way to reassure buyers in case of
bankruptcy of the vendor, but a real and living element. One can
conclude that for the non-developing users the availability of source
code is a form of "insurance policy", while for advanced
users and developers the availability of code allows for deep
customization and adaptation.

Myth #8: There is no money to be made on Free
Software.

Even many researchers have proclaimed in one way or another that
the freely available nature of the code precludes any potential
commercial exploitation. For example8:
"The GPL effectively prevents profit-making firms from using any
of the code since all derivative products must also be distributed
under the GPL license". This of course collides with the
economic results obtained by companies like HP (that in 2003 reported
more than $2.5B in Linux-related revenues), or the $400M revenues
reported in 2006 by Red Hat. In an economic analysis by Gosh it is
evaluated that:

Defined broadly, FLOSS-related services could reach a 32%
share of all IT services by 2010, and the FLOSS-related share of the
economy could reach 4% of European GDP by 2010.

FLOSS directly supports the 29% share of software that is
developed in-house in the EU (43% in the U.S.).

FLOSS potentially saves industry over 36% in software R&D
investment that can result in increased profits or be more usefully
spent in further innovation.

The notional value of Europe’s investment in FLOSS software
today is Euro 22 billion (36 billion in the US) representing 20.5%
of total software investment (20% in the US).

This directly translates in a significant market (that is
difficult to measure, when -- as most consultants do -- evaluated
only through licensing sales in the server market).

Myth #9: The Open Source movement isn't
sustainable, since people will stop developing free software once
they see others making lots of money from their efforts.

This is connected to the view of myth #2, the idea that FLOSS is
developed by volunteers, and that companies can only profit in a
parasitic way from the code that is developed for free. As discussed
in that part, the reality is that in most projects companies and
volunteers participate in a collaborative and non-competitive way;
also, the most widely used license (the GPL) forces companies to
reciprocate their efforts by making dissemination of the source code
mandatory whenever there is dissemination of code derived from GPL
projects.

Myth #10: Open Source is playing catch-up to
Microsoft and the commercial world.

The concept of software innovation is really rooted in two
different aspects: technical innovation and field innovation. While
technical innovation is mostly invisible to the user, "field
innovation" (for example a new kind of application) is highly
visible, and the perception is widespread that most FLOSS software
is more or less a copy of some other desktop-oriented proprietary
application.

The reality is that most proprietary software is non-innovative in
this aspect too; and that while very few examples of new concepts
(like Dan Bricklin's spreadsheet idea) can be found, most
applications are matched to the tasks that people perform daily, and
as such there is a strong disincentive to innovate away from familiarity. A study of 500
sourceforge projects9
found that from a field innovation point of view, around 12% of the
projects sampled were considered innovative, a percentage that is
comparable to that of the proprietary software market. As for
technical innovativeness, the already cited study by Succi, Paulson
and Eberlein found that "The hypothesis that open-source
software fosters more creativity is supported by our analysis. The
growing rate, or the number of functions added, was greater in the
open-source projects than in the closed-source projects. This
indicates that the open-source approach may be able to provide more
features over time than by using the closed-source approach."
So, both from a technical and field point of view, FLOSS is on a par
or better than proprietary software.

*
Since 1999, Carlo Daffara has been the Italian representative to the European Working Group on Libre Software, the first IST-supported working group to deal with Open Source and Free/Libre Software. The group was created at the initiative of the Information Society Directorate General to analyze FOSS, create a set of recommendations, and write a paper to be presented to the Commission.

He coedited with Jesus Gonzale Barahona the resulting white paper [PDF], presented at IST99 in Helsinki. Since 2000, he has been a member of the Internet Society (ISOC) working group on public software as part of the group committee, and contributed to the Open Source part of the article presented by ISOC to UNESCO on global trends for universal access to information resources.