From: Linda (joelinda1@home.com)
Date: Sat May 27 2000 - 05:35:23 PDT
[Adam - more on open-source ....
--Linda]
http://gartner12.gartnerweb.com/public/static/hotc/hc00088469.html
Debunking Open-Source Myths: Development and Support
N. Drakos
We critically examine some common development and support misconceptions
around OSS.
Core Topic
Internet Integrative View and Summary ~ Electronic Workplace
Key Issue
What key trends will affect the role of the Internet over the next five
years?
Many enterprises are apprehensive about introducing or "officially"
encouraging the use of OSS, such as Linux, Apache or PERL (see Note 1),
in their IT environments. Much of this apprehension is due to common
misconceptions about open-source development and support issues (see
Research Note TU-09-4036 for a discussion about the myths surrounding
the origins of OSS and the players associated with it).
Note 1
Open-Source Software: Definition
OSS in this context is software that meets the open-source definition as
laid out by the Open Source Initiative (see www.opensource.org). The
main conditions for qualification as OSS are that the product must be
free to redistribute, source code must be available, and that
modifications and derivative works must be allowed.
Myth 1: Nobody controls development. Invariably, OSS products are
tightly controlled either by a single individual or a small developer
group. For example, Linus Torvalds has the final say on Linux kernel
development, while different aspects of technical development are
"owned" by around 100 individuals who, in turn, consolidate the
contributions from developers at large. Apache is run by the fiercely
meritocratic Apache Group, and PERL is controlled by Larry Wall.
Myth 2: Anyone can change the software, which eventually becomes
unstable. Changing OSS for one's own use is always possible. However,
adding such changes to the "official" distribution or convincing the
user community to switch to a new distribution is quite a different
proposition. With most OSS projects, only a few individuals have the
necessary access rights to integrate code from third parties or to
release new versions. Another element of quality control rests with the
frequency of interim releases, which encourages parallel debugging
within the user community. Major releases that are known to be stable
are usually distinguished from newer, but less well-tested, versions.
Enterprises should recognize these distinctions and make informed
decisions based on the trade-off between more
functionality and stability.
Myth 3: When the lead developer leaves, the project dies. The chance of
a popular OSS product continuing to be supported after the departure of
key individuals is much better than the survival of a proprietary
product after the demise, acquisition or change in the product strategy
of a commercial vendor. The availability of the source code ensures that
there are no licensing restrictions for anyone wishing to pick up from
where others have left off. The best-known example of this is Apache.
The Apache group was formed by users of the popular NCSA Web server when
the NCSA team left en masse to form Netscape (now part of AOL). The
Apache Web server started life as a set of "patch" files for the NCSA
Web server (hence its name — Apache stands for "A Patchy Server"). The
speed of innovation within each OSS project depends on the developers
reaching a critical mass, which allows the development process to
benefit from "network effects."
Myth 4: There is no one to turn to for support. An important consequence
of unrestricted access to the source code and documentation is that it
reduces significantly the barriers to entry for commercial organizations
with a service and support model. Commercial support, including 24x7
telephone hot lines, is available for all the popular OSS products
(e.g., Linux, Apache, PERL, TCL, Sendmail and Bind). For lesser-known
products, support is usually available through alternative means —
developer mailing lists, Usenet newsgroups or peer user groups. This
type of support, however, is much less acceptable to corporate users,
who are looking for accountability as well as maintenance and technical
support. This will remain the primary challenge for vendors supporting
OSS products as they make the transition from their traditional user
base (developer, educational and research environments) toward
mainstream IT.
Myth 5: OSS projects will eventually splinter — like Unix. Although
uncommon, it is possible for anyone to create and distribute their own
version of an OSS product (thus creating a "fork" in the source code).
If a new version offers genuine advantages that are attractive to users,
there is nothing to stop the original developers eventually copying the
changes and "healing the split." In another scenario, the "official"
release might fall into disrepair and in this case the availability of a
new rival version would be welcome. In both scenarios, the beneficiary
is the end user. With OSS — and this is the crucial difference with the
story of Unix — no entity can retain a competitive advantage from a
split in the source code. This is because any modifications would also
have to be released under an open-source
license as freely available code.
Key Facts:
OSS products are invariably controlled either by a single
individual or a small developer group.
The dependence on key individuals is greatly diminished because of
source-code availability.
Commercial support is available for many open-source products.
Source-code availability reduces the risk of splintering and
Balkanization.
Acronym Key
24x7 24 hours a day, seven days a week
AOL America Online
NCSA National Center for Supercomputer Applications
OSS Open-source software
PERL Practical Extraction Report Language
Bottom Line: Contrary to common perceptions, OSS development is often
tightly controlled. In addition, the availability of the source code and
the requirement to share modifications promote longer-term viability,
reduce the entry barriers for those offering services and support, and
discourage Balkanization. We recommend that IS organizations that
currently exclude all OSS from their acquisition plans should reexamine
this policy.
This archive was generated by hypermail 2b29 : Sat May 27 2000 - 05:33:32 PDT