|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
An Annotated Webliography on Open Source Software Development
Problems
This Webliography contains the most relevant papers from my research
materials to my papers. See also Problems of Open
Source Software: (slightly skeptical) Annotated Chronicle.
See also:
Nikolai Bezroukov
Notes:
- Those pages are written by people for whom English is not a
native language. Some amount of grammar and spelling errors
should be expected.
- This is a Spartan WHYFF (We Help You For Free) site. It
cannot replace the best teachers and
the
best books.
- The site contain some obsolete pages as it develops like a
living tree... Some links on older pages
are broken. Please
try to use Google, Open directory, etc. to find a replacement link
(see
HOWTO search the WEB for details).
We would appreciate if you can
mail us a correct link.
|
|
A very interesting discussion of hijacking...
April 29. 2004 | Department of Economics, Università
Politecnica delle Marche, Ancona, Italy
The economics of information goods suggest
the need for institutional intervention to
address the problem of revenue extraction from investments in resources
characterized by high fixed costs of production and low marginal
costs of reproduction and distribution. Solutions to the appropriation issue, such as copyright, are supposed to
guarantee an incentive for innovative activities at the price of few vices marring
their rationale. In the
case of digital information resources, apart from conventional
inefficiencies, copyright
shows an extra vice since it might be used perversely as a tool to
hijack and privatise
collectively provided
open source and
open content knowledge
assemblages. Whilst the
impact of hijacking on
open source software
development may be uncertain or uneven,
some risks are clear in the case of
open content works. The
paper presents some evidence
of malicious effects of hijacking in the Internet search market by
discussing the case of
The Open Directory
Project. Furthermore, it calls for a wider use of novel institutional
remedies such as copyleft and Creative Commons licensing, built upon
the paradigm of
copyright customisation.
TASA 2003 Conference, University of New England, 4–6 December
2003
It appears to be very difficult to capture the
distinctness of open source software production in a general theoretical
framework. The only theoretical framework that compares alternative
modes of collective production is transaction cost theory, which is an
economic rather than sociological approach to the organization of work
and therefore tends to neglect the problem of coordination. This paper
describes open source software production in a sociological framework of
collective production, i.e. in a framework that emphasizes the actor
constellations and the systems of actions that characterize modes of
collective production. A generalized sociological description of open
source software production is derived from published empirical studies.
On the basis of this description, open source software production can be
compared to the known systems of collective production, namely markets,
organizations and networks. The comparisons reveal necessary conditions
for the functioning as well as specific advantages of producing
communities.
In the past there was not much of a commercial
edge to free software. Although many companies used Emacs and the GNU C/C++
compiler to develop their software, these were simply tools that were used to
develop products. No one was selling these tools directly. Even Cygnus (which
used to be named Cygnus Support) did not sell free software. They were
primarily involved with providing Free Software customization and maintenance
services. Free Software was truly a
Cathedral
creation, since the features and bug fixes that companies paid Cygnus for were
fed back into the free software base. Although the companies that used free
software for commercial purposes got something for free, they also gave
something back. The ideal of "giving back" to the free software community is a
strong one. For example, recently I have been using a free software tool named
ANTLR. While I have not contributed
software directly to ANTLR I have
published ANTLR examples
and notes to help other ANTLR users. I have spent many hours writing these Web
pages, but I view it as my way contributing to the ANTLR community.
... ... ...
The free software model seems to assume that
the cost of developing free software is zero. This works as long as you have
Richard Stallman and a bunch of University students doing the development
work. But this is hardly a general model.
Developing software is expensive.
Eric Raymond skips around this issue by pointing out that the development cost
is only a fraction of the lifetime maintenance and enhancement cost. While
this point is true, it does not change the fact that someone must develop the
software.
In a commercial setting the cost of developing
software is amortized over the profit expected from selling it. Maintenance
and enhancements are usually paid for via fees for new versions or from a
maintenance contract (usually ten to fifteen percent of the price of the
original software).
In the free software world new software is
given away, so that the community can maintain and enhance it. But how is the
cost of developing the software going to be recovered? If the cost of
developing the software is recovered through fees for maintenance and
enhancement consulting, it may be a long road to recovering the development
cost. Especially since your competitors can quickly learn the software and
provide the same services. In fact, since they don't have any pressure to
recover development costs, they can undercut the developer of the software.
All this sounds pretty academic perhaps. But
the real outcome of this is that companies like Cygnus and Red Hat don't do
much new open source software development. And when they do, they are
increasingly using contorted "licenses" to control the use of the software in
an attempt to maximize their fees.
Rather than being "a new paradigm" for
software development, the "free software movement" may be an anomaly. The
beginning of the end of this anomaly may Red Hat's IPO.
Locked into ideology and anti-Microsoft
fervor (which sadly is making more and more sense as time goes on), the
open source "movement" has historically ignored the substantial cost of
initial software development, documentation and quality control. This
may be starting to change. Chris Rasch, in his paper
The Wall Street Performer Protocol,
published in
First Monday, June 2001, provides an excellent
description of the costs of developing product quality software. Acknowledging
that software development entails substantial costs, he proposes a bond scheme
to pay for open source projects. For a variety of reasons, I find this
proposal improbable. However, the fact that software development costs are
actually acknowledged in an open source discussion is a step toward reality.
My many contributions to the computing
community has reaped very little personal benefit for myself. As I now
struggle to pay the bills I can not help but feel quite pissed off at the
state of affairs, for myself and the other authors who contributed massive
amounts of time and quality work [to the Linux Router Project], only to have
it whored by companies not willing to give back dime one to the people that
actually created what it is they sell. Acknowledgement and referral would
have at least been acceptable. Few companies do even that.
LRP == R.I.P.
(1997-2002), Dave Cinege, June 22, 2003,
Linux Router Project
See this
note at the end of the web page
I have spent twenty years developing my skills
as a software engineer. Even after all this time, I still read books on
software engineering, software project management and algorithms.
Developing software is hard. Debugging and testing software is hard. It takes
years to build the skills needed to develop large pieces of software. Many
software engineers never develop the skills needed to engineer large programs.
Their work consists of modifying and maintaining existing programs.
I believe in freedom. If people want to develop
free software that is sucked up by marketers and packagers and resold, without
giving the developers anything in return, they should certainly be free to do
so. But the software engineers should consider why they are working so hard
while the marketers collect the money. The marketers and managers are happy to
spout the free software line. They are getting something very valuable without
paying for it. The motto of the software packagers seems to be "Death to
Redmond and pass the stock options".
My choice is to not be exploited. I don't
hate Microsoft and I certainly don't dislike them enough to allow my work to
be given away free so that the marketers can take a few pennies out of Bill
Gates' pocket. With the publication of the source for the Bear Transfer
Program (my version of FTP), I will limit all of the software I publish to
non-commercial use. The authors of the
lcc C
compiler seem to have similar views. I have used
a modified version of their copyright for my software. The basic copyright is
shown below.
If you agree with the points I have made
above, you might want to consider using a copyright like mine. It will not
make much difference if I do it, but if lots of software engineers do it, we
really will have a free software movement. And if there is a movement,
the marketers and packagers will be forced to respect the copyright and will
not be able to use our work without giving anything back. Now all we need is a
song...
... ... ...
Things are Already
Starting to Change: Cygnus Goes Commercial
The business model for Cygnus has been
primarily that of a consulting company that leveraged the free software base
for contracts to maintain and extend the GNU and Cygnus developed software.
This was certianly a viable business model and Cygnus has modest success as a
public company (now owned by Red Hat).
Of course as a public company there is constant
pressure for profits and revinue growth. So free software is going through
strange contortions. One of the strangest is the clause included below for the
Cygwin package. Cygwin is Cygnus' port (and rewrite in some cases) of the bash
shell and the UNIX command line utilities (e.g., ls, find, make, etc...) for
Windows NT Win32. Those who follow the cash at Cygnus probably noticed that
there was a significant cost to developing Cygwin. But how could fees be
collected on this software, since it is open source? Well, how about this:
From
http://www.netsales.net/pk.wcgi/cygnus/offer
Cygwin for Windows NT provides a UNIX/Linux
shell and programming environment on the Windows platform. Cygwin includes
the Linux standard GNU tools for application development as well as a
collection of many useful Unix/Linux commands ported to Windows. The
collection of commands form the familiar UNIX/Linux shell environment on the
Windows platform. The standard UNIX/Linux libraries included with Cygwin are
shipped with a GPL license, encouraging further Open Source development on
the Windows platform. Note that only GPL'ed Open Source programs can be
created with Cygwin unless an additional commercial license is obtained from
Cygnus.
What this clause means is that if I put Cygwin
on my system so that I can use bash, and the UNIX command line
commands, like "ls", I can't use this environment to develop proprietary
software, unless I pay Cygnus a fee. This is nothing less than bizzare. It
basicly states that although the software is open source/free software, Cygnus
is placing a limit on its use. There is an "out" to this limit, however, which
is available for a fee from Cygnus.
This is bizarre because Cygnus is attempting to
place a limit on the user, even when there is no free software content in the
users product. For example, at one time the Bison parser generator could not
be used to develop proprietary software. In the case of Bison, there is a
kernel of free software source for the parser skeleton. Since this is included
in an application that uses a Bison created parser, the application is covered
by the "copyleft" and had to be open source as well. In contrast, the Cygwin
tools might be used while creating the application, but would never be part of
the application itself.
In making this claim, Cygnus has vastly
extended any common definition of open source/free software. The free software
foundation never placed such a limit on bash or any of the other UNIX
utilities. This "requirement" on Cygnus' part is totally unenforcable and
unreasonable. It is simply and attempt to make free software less open and to
assure Cygnus' ability to collect fees for the software they developed.
Perhaps we will see companies like Red Hat attempt to limit free Linux
distributions to open source/free software development only. All others pay a
fee.
It Used to be Free
Software, Now It Belongs to Cygnus
In the past people donated their work on Free
Software Foundation software to the FSF. All FSF software is explicitly open
source. People were willing to donate their work without pay because it
provided the community with open source software.
The Cygnus Java Compiler (GCJ) project
invites people to "contribute". But I was rather surprised to read the
Cygnus copyright assignment
that they ask people who work on their Java compiler to sign. As I read this
copyright, it assigns all rights to Cygnus without any guarantee that the work
of the software developer will be open source. The contract states that the
software belongs to Cygnus. There is no guarantee that Cygnus/Red Hat will not
try to restrict the use of the software as they have tried to do with Cygwin.
Never, ever, believe "trust us" vs. a written contract. The written contract
always wins.
The one thing that Cygnus and Red Hat have not
explained is why you should work on their software for free. Take a look at
the net worth of Red Hat's executive staff and ask yourself why you should
work for Cygnus without pay.
Sited from [Freedom
Can Be Slavery]. The quote belongs to Ian Kaplan:
This article discusses several serious Linux
application security flaws that can significantly compromise the system.
Commissar Eric Reymond's contention that the many eyes of the open source
community is questioned. Reviewing code, especially the uncommented code
that is so common in software bases, is tedious and just does not get done.
The article quotes Crispin Cowan, chief scientist at Linux maker WireX
Communications:
Yet, the "many eyes" theory, as it is
known in the open-source world, doesn't work so well in reality, said
WireX's Cowan.
"It does not assure that many eyes are
actually looking at the code," Cowan said. "In fact, it is likely that
'rock star' code that is hip to work on gets adequate attention, while the
other 90 percent languishes, in many cases never even seen by anyone but
the code's authors." And much of this unsexy code forms the foundation of
Linux.
Ted Lewis in his ``Binary Critic'' column in IEEE Computer [10]
voiced a rare criticism aimed at the open-source development process itself
(in particular the ``bazaar'' approach) and its ability to cope with its own
success. Specifically, Lewis thinks that as open-source projects' popularity
grows and they begin multiplying, the pool of talented programmers who devote
their free time to such projects will become increasingly scarce. Furthermore,
Lewis claims, as those projects mature, they will also grow in features and
complexity, eventually overwhelming the resources of their handful of core
developers and the capability of their typically ad-hoc organizational
structure to cope with those stresses. This sentiment is also echoed by
Microsoft: ``The biggest roadblock for open source software projects is
dealing with exponential growth and management costs as a project is scaled up
in terms of innovation and size'' [19].
ABSTRACT The ideology of open source software development
is spearheading a shift in the way we
approach the process of software development. Not only is it changing the
perception of costs associated with
projects, but also the management aspect of these development processes. The
management of open source
projects is very different from a traditional project due to the inherent
nature of the objectives, team structure
and the benefits involved. Several studies have examined various issues
related to the management of these
projects. However there is a lack of a study that puts together all the
findings so that the interrelationships
between these findings can be explored. This study tries to overcome this
shortcoming and present the findings
of other studies in a comprehensive manner and at the same time look at the
entire process from a bird' eye
point of view.
The Free Software Foundation was founded on the
appealingly utopian -- and perhaps quixotic -- notion that all information
should be shared. The Free Software ideology focuses largely on traditional
copyright, and what its adherents perceive as fundamental injustices contained
therein. In this idealistic view, any contract that prohibits the free sharing
of information forces the individual into an adversarial relationship with
others, and thus diminishes us all as people. More plainly, we can no longer
be friends when the law requires us to keep secrets. Good, useful thoughts --
with computer programs considered particularly functional concentrations of
such -- are imprisoned by copyright; the resulting unequal access, primarily
by those with money over those without, is fundamentally unjust.
Richard Stallman's Free Software Foundation seeks to
redress this injustice -- within the scope of the computing world, anyway --
by replacement of the standard copyright agreement with the "copyleft",
a somewhat romantic licensing scheme which, though it does not actually
prohibit sale of FSF software or its products, capably skewers the
monopolist's ambitions. It effectively guarantees that any programming project
having benefited from FSF technical leverage can never be considered
intellectual property.
Eric Raymond's Open Source Initiative (OSI), on the
other hand, is galvanized by the rather more utilitarian revelation that users
are much less clueless than previously imagined, and that enlistment of their
cooperation -- by allowing them to contribute to the ongoing process of
improving the software they use --results in much more useful, well-designed,
robust creations.
Though perhaps a less epic position than Stallman's
transcendentalism, it's nevertheless revolutionary in the software business.
Historically, source code is the jewel in the crown of intellectual property,
guarded at any cost. Source code theft has been at the center of any number of
high-profile Silicon Valley litigations. The newfangled notion of allowing
customers -- and competition -- free access to source is, to many software
industrialists, more than a little threatening.
A little over three weeks since the evil
attacks by left-wing Islamic terrorists murdered 6,000 human beings on
American soil, the American political left launches their assault on
democracy. Phil Donahue slithered under the doors of Good Morning America this
week screaming about American imperialism under Ronald Reagan was the cause of
the terror attack.
The "peace" protestors in DC, Austin and San
Francisco decried the inherent racism and inequities of the "corporatism"
forced evil people to murder while pleading for restraint and introspection
from the United States against the murderers. The Democrats in Congress have
begun to fight with the White House about how new anti-terrorism laws will
destroy America's civil liberties. In only three weeks, the pillar of unity
and patriotism that had brought both sides together begins to crumble.
Only three weeks! Wow, that's a full twenty
days longer than the Linux'cult allowed before they began their assault on
that evil imperial, corporate destroyer of civil liberties known as
Microsoft!
Linux'is relatively new to the IT scene, a
project begun ten years ago by Finnish programmer Linus Torvalds. Torvalds,
the son of socialist Finnish radio commentator Nils Torvalds who often sided
with Soviet leadership in world matters during the Cold War, was a computer
science student at a university in Helsinki. While at university, Torvalds
programmed on the school's expensive computers running the high-powered
Unix operating
system (OS) developed by Bell Labs scientists in the late 60s. Torvalds,
unable to afford the expensive Unix workstations for personal use, began to
reverse engineer the Unix OS for use on his inexpensive home computer.
Torvalds posted his Unix rip-off dubbed "Linux"
on the Internet in 1991 for free. True to his family's socialist radical
politics, Torvalds released his OS under the non-standard General Public
License (GPL) or "copyleft."Under
the GPL, programmers had the ability to download Torvalds' Linux, fix the bugs
in his program and give the improved program back to him to distribute to the
Linux community. GPL programs are essentially community property with no real
owners, but since Torvalds was the originator of the rip-off, it becomes his
personal rip-off to control as he wishes. In other words, Torvalds became the
dictatorial leader of the Linux cult with all decisions for the greater
community good going through him first, then doled out at his convenience.
Microsoft, unlike Linux, operated on the
capitalistic principle of charging for products that people will pay for.
Because many individuals and businesses liked Microsoft's products enough to
pay for them, Microsoft prospered. The GPL, unlike standard copyright laws,
stifled the ability for Torvalds and his followers to make money off of their
increasingly popular OS (Torvalds only fallback was to copyright the
Linux'name). By the late 90s, the free Linux'OS had found its way onto
millions of computers around the world, but the corporations that "distributed"Linux'(The
GPL does allow for corporations to charge distribution fees & costs of the
CD-ROMs, manuals, tech support for Linux) were all losing hundreds of millions
of dollars. Unable to make money off of the Linux'OS, the Linux'cult branded
Microsoft the "Great
Satan."The Linux'cult's newest jihad is to aid in the fight against
Microsoft begun by their competitors Netscape, Sun, and Oracle along with over
a dozen state attorney generals during their anti-trust litigation. The
Linux'cult, not unlike the global confederation of leftist zombies led by a
few radicals bent on the destruction of the United States, is a global
confederation of leftist zombies led by a few radicals bent on the destruction
of Microsoft.
Several stories on prior to September 11 on VA
Linux propaganda web site and geek nexus Slashdot (who offered the
advice: "Be incomprehensible. If they can't understand, they can't disagree"
at the bottom of their web page on October 4, 2001) reported that the European
Union would do all it could to destroy Microsoft if the US federal courts
owned by corporate America didn't have the guts. Such attacks ground to a halt
the day of the attack. By September 12th, cease fire ended between the
Linux'cult and their hated enemy. The Free Software Foundation's legal counsel
offered an anti-Microsoft/Bush/capitalism diatribe in
The
Nation while the bodies of capitalist pigs burned beneath the World Trade
Center. Ziff-Davis'
eWeek magazine accused Microsoft of "bullying" competitors and they were
the source of our "long national nightmare."A writer on NewsForge, another VA
Linux-owned propaganda site, noted that in light of the attacks the day
before, he did not feel like reporting on the "evils of Microsoft. I don't
want to complain about the misappropriation of public intellectual property by
private interests and their lawyers."
The assault was back up to full strength a week
later as InfoWorld's
The Gripe Line page was rife with Linux'cultists' outrageous claims that
Microsoft software will spy on you, keep you from upgrading your computer and
stifle the First Amendment. A paid Linux'cultist for tech publication ZDNet UK
issued a call to arms against the evil Microsoft Corporation saying:
"Microsoft's relationship to its users is that of the blue whale to krill. Our
only purpose is to breed, feed and get squeezed against its giant tongue until
every last drop of money is released."The rest is rehashed garbage about
Microsoft "bullying" competitors and being evil, but that's just the nature of
Linux'in general √ why be original when you can just share revolutionary
propaganda?
To be sure, Microsoft has a lot of money. What
the Linux' cult fails to understand is that Microsoft got that money because
there have been customers that paid Microsoft for their products. Microsoft
clawed their way to the top by smart business people and decisive action. The
Linux'cult just does not understand how business and capitalism works. They do
not understand that Microsoft has created a software product that the majority
of people have chosen to use. This majority does not want to be told what to
do by a tiny minority who claim to know exactly what the majority really wants
rather than what the majority has already chosen. The success and ubiquity of
Microsoft products is what fuels Linux'users' hatred for Microsoft. There is
no moral imperative for the majority of global computer users to change to
Linux'because Microsoft has been tagged as "evil"by a tiny majority. Mostly
because the majority knows that they are not evil just because they use
Microsoft Word rather than some clunky text editor in Linux≥.
It's funny, but the Linux' cult sound an awful
lot like the fanatics engaging in a jihad against the Great Satan called the
United States of America. No wonder Linux' cultists hate the idea that
American law enforcement is about to get tough on terrorism.
I did volunteer work for the Ralph Nader for
President campaign in 2000. As a result of this, my email address wound up on
many mailing lists, some interesting, some annoying. I get quite a bit of mail
from Socialists and Communists, an enemy-of-my-enemy sort of deal. And without
exception, they're all using tools of our corporate overlords, fattening the
bourgouisie wallets, both unintentionally and with full knowledge of doing so.
(And getting rather testy when this is pointed out to them...)
... ... ...
Other writers such as Nikolai Bezroukov[23]
have compared the hacker tribe to an academic community.
Starting around 1960, there are several works about the social configuration
of the scientific community, including those by Derek Price24 and Thomas
Kuhn[25], leading to Crane�s idea of the Invisible College26 described in
1972, and later a massive work published in 1988 by David Hull[27]. Finally,
Daniel Quinn has a theory about civilization in general that relates to our
subject because he feels that much that is wrong with society could be
improved by returning to "tribal" ways. By "tribal" he means relations
that emulate the tribe as an optimal economic unit rather than a return to
the hunter-gatherer lifestyle, as he explains in his book "Beyond
Civilization".
PDF
Table 1. Characteristics of selected open-source projects.
| Project |
|
Application Domain |
| Apache |
100
|
HTTP server |
| Linux |
800
|
Operating system |
| INN |
150
|
NNTP server |
| BIND |
150
|
DNS server |
| KDE |
250
|
Desktop environment |
| GNOME |
150
|
Desktop environment |
| Mozilla |
1500
|
Web browser |
| Perl |
150
|
Programming language |
| Python |
160
|
Programming language |
| Samba |
150
|
SMB Server |
Even if the current attention given to
open-source software by the media and commercial software companies proves to
be only a fad and it doesn't make the jump into the mainstream acceptance, I
believe that open-source software development is here to stay. While it may
not be the right development model for every software project, it is hard to
argue against its effectiveness in the case of Linux or Apache. James Sanders
[21]
makes a good point that as the software companies struggle to find a way to
meet the often conflicting requirements of developing software faster while
making it more robust, they might be forced to embrace alternative development
models. Using Linux as an example, open source gives a development model that
``creates a faster, leaner, and more reliable product than mainstream
competitors, and does so essentially for free'' (p. 89). In addition, it can
only be expected that new open-source projects will continue to be created and
bring forward innovative software ideas that would be too large for resources
of a single enthusiast, but generate enough interest in the Internet
programmers's community to carry their development forward.
What we should provide to these developers is
the tools and knowledge to better manage such projects, reduce the entry
barrier for those who want to join the development, and eliminate unnecessary
manual work. Clearly, better configuration management (CM) tools are necessary
--- drawbacks of CVS are well-known (e.g., [12],
and are only more obvious when the collaborating programmers are so widely
dispersed and loosely coordinated. Distributed CM systems, such as NUCM [25],
would make a better fit, including keeping parts of the development tree on
servers belonging to a subgroup of developers that temporarily branched off
for work on a new feature (or that, like Netscape in case of Mozilla, has a
proprietary version of the software). Announced and proposed changes could be
better managed through a mechanism like that described by Narayanaswamy and
Goldman [14]
instead of a mailing list, like that for Apache Web server. Similarly,
reviewing and testing patches would arguably be a lot easier if they were
accessed through, for example, a fine-grained revision control mechanism like
Historian [1],
than as email messages thrown in together with the rest of development-related
discussion.
Lastly, effective knowledge management is all
the more crucial in open-source development, where most developers won't ever
see each other face-to-face and discussion is for practical reasons almost
exclusively online and asynchronous. Furthermore, it should be made easier for
the new developers to join in and get acquainted with the design decisions and
the evolution of the code. Currently, this usually means going through the
archives of the project's mailing list. A possibly better approach is
suggested by Lougher and Rodden [11],
where maintenance-related discussion is (literally) centred on the affected
code; it could conceivably be extended to support the full development cycle
and include an overview of the temporal change of the program as well.
Through all of this, we should keep in mind the
specificities of open-source software development that make it different from,
for example, Internet-based development for a more monolithic entity, such as
a commercial software company. In particular, open-source software development
is extremely fluid: it depends on contributions from volunteers, whose
commitments, available time, or interests may easily change. Enacting a
traditional software process under these circumstances is much more difficult;
it could also be counterproductive, if the contributors perceive that they are
giving away their freedom. What is needed are the tools and techniques that
are flexible, complement the tools currently in use, and support the existing
open-source development model almost transparently.
Over the last few years, as the Open
Source/Free Software movement has become a constant in the business and
technology press, generating conferences, spawning academic investigations and
business ventures alike, one single question seems to have beguiled nearly
everyone: "how do you make money with free software?"
If the question isn't answered with a business
plan, it is inevitably directed towards some notion of "reputation". The
answer goes: Free Software programmers do what they love, for whatever reason,
and if they do it well enough they gain a reputation for being a good coder,
or at least a loud one. Throughout the discussions, reputation functions as a
kind of metaphorical substitute for money - it can spill over into real
economies, be converted via better jobs or consulting gigs, or be used to make
decisions about software projects or influence other coders. Like money, it is
a form of remuneration for work done, where the work done is measured solely
by the individual, each person his or her own price for creating something.
Unlike money, however, it is also often seen as a kind of property. Reputation
is communicated by naming, and the names that count are those of software
projects and the people who contribute to them. This sits uneasily beside the
knowledge that free software is in fact a kind of real (or legal) property
(i.e. copyrighted intellectual property). The existence of free software
relies on intellectual property and licensing law (Kelty, forthcoming; Lessig,
1999).
In considering the issue, most commentators
seem to have been led rather directly to similar questions about the sciences.
After all, this economy of reputation sounds extraordinairily familiar to most
participants [1]. In particular two claims are often
made: 1) That free software is somehow 'like' science, and therefore good;
and, 2) That free software is - like science - a well-functioning 'gift
economy' (a form of meta-market with its own currency) and that the currency
of payment in this economy is reputation. These claims usually serve the
purpose of countering the assumption that nothing good can come of system
where individuals are not paid to produce. The assumption it hides is that
science is naturally and essentially an open process - one in which truth
always prevails.
The balance of this paper examines these
claims, first through a brief tour of some works in the history and social
study of science that have encountered remarkably similar problems, and second
by comparing the two realms with respect to their "currencies" and
"intellectual property" both metaphorical and actual.
If this hypothesis is supported by future research, a
reinterpretation of the entire history of the free software movement will be
necessary. For this analysis suggests a starkly different logic to open source
development than is contained in most of the popular literature on the
subject. In particular, it offers support for the hypothesis that early
open source work thrived because its development took place in an immature and
publicly-subsidized market. While academics and researchers were no doubt
driven by a desire to "scratch an itch" and perform work they found
particularly stimulating, it is significant that they essentially performed
labor for which there was very little immediate private-market demand. Is
free software truly free? It may be something for which developed countries
have already paid: through early funding for academic research and
development, and support for public research at times when the market for
certain types of software was immature. It is hardly accidental that early
"hacker" communities emerged at organizations with the resources and will to
subsidize long-term development.
And although the role the United States government played in
supporting early development in the American hardware-computing industry is
generally recognized, its indirect contribution (and that of foreign
governments) to the success of open source projects is usually completely
overlooked in arguments which center on hacker ethics [43].
Part of this doubtless stems from the ideological biases of many commentators
on this issue, whose political preferences have tended towards the
libertarian. By portraying programmers as motivated primarily by cultural
factors, early theorists could not only treat early developers as
counterculture heroes in the cypherpunk tradition, but also paint the history
of the open source movement as an all-American story of Jeffersonian
independence. In one typical early interview, for instance, suggestions that
open source projects might be explicable as "project[s] subsidized by
government or academic" bodies were dismissed offhand by the interviewer.
This rejection of classical economic logic is all the more remarkable given
the overwhelming torrent of evidence that not only are many open source
projects begun in academic circles, but that the growth of Linux itself was
indirectly subsidized by the University of Helsinki [44].
It may be one of the odd ironies of computing history that the open source
movement has proven such fertile grounds for libertarian philosophizing.
A more profound consequence of treating open source
development from a classical perspective is the unexpected shadow it throws on
one of the most cherished pillars of modern political economy. In particular,
it opens the door to a devastating attack on the empirical validity of the
principle of creative destruction invoked by Joseph Schumpeter in his
opus Capitalism, Socialism and Democracy (1950). Here, Schumpeter does
not (as is often assumed) simply assert that innovative businesses cannibalize
their older counterparts. His argument is a more complex one about the process
of innovation itself. Contrasting market and state-led production systems,
Schumpeter argues that the process of innovation induced by market-systems is
inevitably the more socially beneficial because capitalism can be creative
in its ability to wring the last ounce of efficiency from industrial
processes. Defending capitalism against the socialist encroachment he believed
inevitable, Schumpeter pointed out that:
"Since we are dealing with a process whose every element
takes considerable time in revealing its true features and ultimate effects,
there is no point in appraising the performance of that process ex visu
of a given point in time; we must judge its performance over time, as it
unfolds through decades or centuries."
This point was intended in defense of the short-term market
inefficiencies Schumpeter recognized plagued American production in the 1940s.
His defense rested on the belief that these failures in themselves created the
long-term conditions necessary for efficient industrial development, by
creating the incentives for further technical innovation. If one accepts the
common view that open source software is more socially beneficial to society
than commercial software, being more likely to lead to innovation because of
its open and extensible nature, the success of projects like Linux in their
twenty year competition with commercial alternatives creates a daunting
empirical challenge to the Schumpeterian assumption that the efficiency of
production systems can be measured without reference to the social systems
that support them. If Raymond is right to conceptualize the dynamic of
the Bazaar model as inherently more equitable than the Cathedral model, this
criticism gains a moral edge as well. At least on first glance the historical
record seems to suggest that - over decades - certain kinds of state
intervention may in fact be socially desirable.
These questions are not merely academic: our understanding
of how open source development actually works has profound implications for
what kinds of corporate strategies and public policies firms and governments
should pursue over time. If this paper is correct in its underlying
conceptualization of developer motivations, projects such as Netscape's
Mozilla which seek to leverage competitive advantage from unpaid public
development are fool's errands - unlikely to create products which can be
successfully leveraged for private profitability. Competition in
service-provision should also grow progressively unprofitable as expertise on
open source products grows more publicly diffuse and Baumol's disease
kicks-in. If open source production is stimulated by differentials in real
income levels, corporate strategies that seek to ward-off open source
competitors by hiring or co-opting their developers are equally prone to
undermine themselves in the long-term, being fraught with moral hazard. By
increasing the benefits which accrue to free software developers, strategies
aimed at co-opting open source development will ironically serve only to
encourage further development. And counterintuitively, this model predicts
that periods of greatest prosperity in national software industries will
correspond with increased activity among developers abroad - exactly the trend
we seem to have observed. Will "hard times" in software industries reduce the
attractiveness of coding free software abroad?
Unevenly-enforced social policies on issues such as software
piracy and labor mobility become incredibly important areas of corporate
concern and public interest in this light. By mitigating global pressures for
wage convergence, diverging social policies on these issues can encourage open
source development even in developed market economies. Open source development
may be popular in Canada, Finland and the Netherlands as relative to their
neighbors, for instance, exactly because these countries are in many ways
satellite economies. Programmers in these nations are likely to be
well-aware of international income differentials, and frustrated by market
immobility as well. Will a strengthened Euro reduce incentives for open source
programming in Europe by reducing the variance in real income across Europe?
Will labor mobility across Europe lead to a "convergence" in open source
development as the common market becomes a truly continental one? In the case
of software piracy, the widespread availability of illegal software drives two
conflicting trends. Initially, high levels of piracy should reduce the
incentive developers have to build open source alternatives to commercial
products. As such, tolerating piracy may become a strategy of
self-preservation for certain commercial firms, especially those seeking to
establish their products as de facto market standards. Tacitly ignoring
piracy - for all of its lost revenue - may yet become one of Microsoft's
survival tactics, especially in countries like China which have yet to
socially institutionalize open-source development networks. Once open source
projects are well-established, however, high levels of piracy very clearly
undermine commercial software development. It most prominently lowers the
opportunity cost of coding free software over commercial applications, and
also ushers in the escalating benefits of free software development modeled by
Raymond and Ghosh.
Since theory informs us that public goods are always
under-provided in market systems (the free-riding problem), the success of
packages such as Linux in direct competition with market-driven alternatives
offers vindication for policies aimed at improving social welfare through
deliberate market distortion. Public policy may prove critical to the
continued success of the open source movement г especially in the more subdued
equity market following the recent economic downturn in the United States.
NASA's support for the MySQL project and the release of the Army-coded GIS
package GRASS under an open source license constitute two examples of "soft"
support. As market incentives for open source software production shrink,
"hard" support for programs such as higher education may be critical factors
to the extent that these types of interventions can discourage rent-seeking
behavior while encouraging individuals to invest time and effort in the
creation of public goods [45]. Any balanced evaluation
of the open source model must take these negative social costs into
consideration as well.
Given the tentative nature of this research, I feel it
vitally necessary to limit the scope of these conclusions. This paper is not
intended as a critique of sociological theories about how individuals
interact once they are in open source communities, but rather as an alternate
and hopefully more convincing explanation for why developers drift into
open source projects and cultures in the first place. Critics may be right to
question the universal applicability of these conclusions. It is possible that
the true significance of the open source movement is unlikely to be found in
the success or failure of any particular project, but in the ephiphenomenal
possibilities created the interaction of thousands of smaller, stand-alone
programs, application libraries and standards (Raymond's UNIX Gospel). And
since important software projects are clearly not restricted to the
upper left-hand quadrant on which this paper has focussed, it is possible that
a very important segment of the puzzle is missing from this analysis [46].
It is impossible to use this evidence to infer about causation in any quadrant
but the combination of "Anti-Proprietary" and "Highly-Complex" projects.
But given the tremendous importance of this debate, it is
vital not to dismiss without genuine thought and substantial reflection the
points political economists bring to bear on this issue. For it is equally
plausible that the benefits of the UNIX Gospel are over-exaggerated: possible
only in certain systems (such as command-line UNIX desktops) and in limited
circumstances (such as when inter-program communication can be handled through
character strings). And if the truly important projects in the open source
community are those most similar to the Linux and Gnome projects, which are
unique in creating (not exploiting) a framework on which further development
can be built, the insights political economists can shed on these movements
allow for a much more nuanced view of development than is made by advocates of
post-scarcity gift cultures. While this view may be less than wholly
optimistic in its hopes for man ever transcending industrial capitalism, it is
perhaps reassuring in concurring nonetheless with earlier critics that
regardless of how software is produced in the real world, its increasing
extensibility seems to be in the public interest and should be encouraged
where feasible.
The dust jacket
for Eric Raymond's open source manifesto The
Cathedral and the Bazaar makes this statement
clearly. It says: "…the development of the Linux operating system by a loose
confederation of thousands of programmers -- without central project
management or control -- turns on its head everything we thought we knew about
software project management. … It [open source] suggested a whole new way of
doing business, and the possibility of unprecedented shifts in the power
structures of the computer industry." This is not just marketing hype on a
book cover, Raymond expands the point inside: "… the Linux community seemed to
resemble a great babbling bazaar of differing agendas and approaches … out of
which a coherent and stable system could seemingly emerge only by a succession
of miracles." Other open source adherents make similar statements in
trumpeting the virtues of open source programming.
There is one
problem with the statement, open source projects manage themselves. It is not
true. This article shows open source projects are about as far as you can get
from self-organizing. In fact, these projects use strong central control,
which is crucial to their success. As evidence, I examine Raymond's fetchmail
project (which is the basis of The Cathedral and
the Bazaar ) and Linus Torvalds's work with
Linux. This article describes a clearer way to understand what happens on
successful open source projects and suggests limits on the growth of the open
source method.
(Note: This article addresses issues raised in the
essay titled
The Cathedral and the Bazaar
. The essay also is included in a
book
with the same title, which contains other essays as well.)
What Really Happened with fetchmail
The Cathedral and the Bazaar
revolves around Raymond's experience in creating a program called fetchmail by
the open source method. As he describes the software development process, he
annotates the story with lessons about open source programming and how well it
worked for him. One of Raymond's key points is that the normal functions of
management are not needed with open source development.
Raymond lists the responsibilities of traditional
software managers as: define
goals and keep everybody pointed in the same direction,
monitor the project and make
sure details don't get skipped, motivate
people to do boring but necessary work, organize
the deployment of people for best productivity, and
marshal resources needed to
sustain the project over a long period of time. Raymond then states that none
of these tasks are needed for open source projects. Unfortunately, the
majority of The Cathedral and the Bazaar
describes, in detail, how important these management functions are and how
Raymond performed them.
Eric Raymond decided what piece of software he would
use as a test for open source programming. He decided what features fetchmail
would have and would not. He generalized and simplified its design,
defining the software
project. Mr. Raymond guided the project over a considerable period of time,
remaining a constant as volunteers came and went. In other words, he
marshaled resources. He
surely was careful about source code control and build procedures (or his
releases would have been poor quality) so he
monitored the project. And, most significantly,
Raymond heaped praise on volunteers who helped him, which
motivated those people to
help some more. (In his essay, Raymond devotes considerable space to
describing how he and Torvalds motivate their helpers.) In short, fetchmail
made full use of traditional and effective management operations, except Eric
Raymond did all of them.
Another compelling (and often-quoted) section of
The Cathedral and the Bazaar
is the discussion about debugging. Raymond says: "Given enough eyeballs, all
bugs are shallow" and "Debugging is parallelizable." These assertions simply
are not true and are distortions of how the development of fetchmail
proceeded. It is true that many people, in parallel,
looked for bugs and proposed fixes.
But only one person (Raymond) actually made fixes, by
incorporating the proposed changes into the official code base. Debugging (the
process of fixing the program) was performed by one person, from suggestions
made by many people. If Raymond had blindly applied all proposed code changes,
without reading them and thinking about them, the result would have been
chaos. A rare bug can be fixed completely in isolation, with no effect on the
rest of the program.
Lessons from Linux
In a similar way, on an even larger scale, Linus
Torvalds pulled off a great feat of software engineering: he coordinated the
work of thousands of people to create a high-quality operating system.
Nevertheless, the basic method was the same Raymond used for fetchmail.
Torvalds was in charge of Linux. He made all major decisions, assigned
subsystems to a few trusted people (to organize
the work), resolved conflicts between competing
ideas, and inspired his followers.
Raymond provides evidence of Torvalds's control over
Linux when he describes the numbering system that Torvalds used for kernel
releases. When a significant set of new features was added to the code, the
release would be considered "major" and given a new whole number. (For
example, release 2.4 would lead to release 3.0.) When a smaller set of bug
fixes was added, the release would get just a new minor number. (For example,
release 2.4 would become 2.5.) But who made the decisions about when to
declare a major release or what fixes were minor? Torvalds. The Linux project
was (and still is) his show.
Further proof of Torvalds's key role is the fact the
development of Linux slowed to a crawl when Torvalds was distracted. The birth
of his daughter and his work at Transmeta corresponded precisely with a period
of slow progress for Linux. Why? The manager of Linux was busy with other
things. The project could not proceed efficiently without him.
Finally, there is a quote from Torvalds himself
during an interview with Bootnet.com. "Boot
: You've got a full slate of global developers who are working on Linux. Why
hasn't it developed into a state of chaos?
Torvalds : It's a chaos that has some external
constraints put on it. … the only entity that can really succeed in developing
Linux is the entity that is trusted to do the right thing. And as it stands
right now, I'm the only person/entity that has that degree of trust."
Open Source Revisited
So, if the open source model is not a bazaar, what
is it? To the certain consternation of Raymond and other open source
advocates, their bazaar is really a cathedral. The fetchmail and Linux
projects were built by single, strong architects with lots of help -- just
like the great cathedrals of Europe. Beautiful cathedrals were guided by one
person, over many years, with inexpensive help from legions of workers. Just
like open source software is. And, just as with open source software, the
builders of the cathedrals were motivated by religious fervor and a divine
goal. Back then, it was celebrating the glory of God, now it is toppling Bill
Gates. (Some people think these goals are not so different.)
The Joy of Unix by
Eugene Eric Kim (Linux Magazine, Nov. 1999). Pages 1 and 5 provide Joy's views
on the relationship between Unix and Linux as development projects (p. 1) and on
the current dominance of Sun's chief competitor Microsoft (p. 5).
"As one of the creators of Berkeley Unix, Bill Joy knows a thing or two
about developing and marketing a free operating system. Sun Microsystems'
chief scientist has survived the Unix wars and has watched both his company
and its chief competitor, Microsoft, grow from tiny start-ups to industry
giants. . . Joy recently accepted Linux Magazine's invitation to dinner, where
he gave Publisher Adam Goodman, Executive Editor Robert McMillan, and
Associate Editor Eugene Kim the lowdown on what Sun thinks of Linux and Open
Source"
An extensive analysis of user traffic on
Gnutella shows a significant amount of free riding in the system. By sampling
messages on the Gnutella network over a 24-hour period, we established that
almost 70% of Gnutella users share no files, and nearly 50% of all responses
are returned by the top 1% of sharing hosts. Furthermore, we found out that
free riding is distributed evenly between domains, so that no one group
contributes significantly more than others, and that peers that volunteer to
share files are not necessarily those who have desirable ones. We argue that
free riding leads to degradation of the system performance and adds
vulnerability to the system. If this trend continues copyright issues might
become moot compared to the possible collapse of such systems.
Based on interviews with dozens of software
engineers and managers in four countries – the U.S., Ireland, India and
Singapore – the study points out that the growth of a global infrastructure
has made it possible to "exploit globally the opportunities opened by the
digitalization of production and products."
Metiu and Kogut see the open source movement as a tremendous driver of
innovation. "The open development model opens up the ability to contribute to
innovation," they say. "It recognizes that the distribution of natural
intelligence does not correspond to the monopolization of innovation by the
richest firms or richest countries. It is this gap between the distribution of
ability and the distribution of opportunity that the web will force companies
to recognize and to realign their development strategies." In other words,
engineers in China, Israel or India who are unable or unwilling to move to
Silicon Valley or the Research Triangle need not be locked out of innovative
product development: They can play a vital role in the creation of new
products and services.
Metiu and Kogut contrast the open development model with another model of
software development, commonly used in the industry, which they call the
"global project model." Using this approach, software companies set up offices
around the world – paying close attention to the locations of their customers
– and then develop software wherever it suits them best to do so. This lets
the company take advantage of time zone and labor-cost differences to slash
software development costs. Example: Trintech, an Irish company that makes
electronic payments software, has offices in the U.S., Ireland, the U.K. and
Germany. The company organizes software development work in a way that lets it
expand the working day to 16 hours. Some Indian software firms, including Tata
Consultancy Services, Infosys and Wipro, boast that since programmers in the
U.S. can hand off tasks each evening to their colleagues halfway in India who
are just beginning their working day, they can achieve a "24-hour working
day."
The study points out that global sourcing today depends on three main
factors: The coordination of modularized tasks, communication and shared
context. All of these have limitations, though. First, coordination in
software across borders is particularly difficult when the task is creative.
Second, when software is developed internationally, problems can crop up in
transmitting certain kinds of knowledge. Third, a shared context limits
coordination across distances because people interpret the world in which they
live in different contexts.
Metiu and Kogut found that software firms typically outsource only routine
tasks to offshore sites and aim primarily at exploiting the low cost
advantage. For example, they looked at a large financial services division of
an American firm which did only simple sub-contracting work with Indian
software houses. They also studied another telecommunications company which
developed software offshore. When this company’s customers demanded features
embedded in software rather than in hardware, it was hesitant to commit to
outsourcing for strategic products.
However, their research also showed some positive developments which
encourage moves by companies towards greater innovation. For example, they
found that many offshore software firms like Infosys and Wipro want to be more
than just low-cost vendors. They wanted to take part in the innovation process
by developing their own products. The researchers believe that global
outsourcing will cause global capabilities and aspirations to converge.
A key question to the researchers was: Can companies develop a strategy in
which the distinction between onshore and offshore software development
merges? At Trintech, for example, the company has tried to make virtual
development of software possible by moving closer to its customers in Silicon
Valley. The company still has been unable to fully exploit the 24-hour global
sourcing cycle. While this model represents a radical departure from the early
days of software development, it still did not significantly enhance the scale
of innovation.
Kogut and Meitu note that customers also are realizing that even as costs
fall, innovations need not occur only in the richest markets. But how is this
possible when innovations are designed by the customer, closest to the market?
The researchers found that the market itself may move to where the software is
being developed. Case in point: Wipro in Bangalore had a customer located in
San Diego that requested the development of a software product where the
specifications were laid out, the architecture drawn up and the final product
shipped back to the customer. Wipro’s software team never met the customer.
So how can firms profit by this strategy? It is possible to do so by
shifting revenues from selling the software to the provision of services,
online support and training. Further, if companies are able to combine the
open source model with some proprietary software, as Netscape did with its Mozilla licensing policy, they can still maintain a competitive edge.
In all this, an important aspect that Metiu and Kogut studied was why
software engineers across the world would volunteer their time to develop free
software. Their conclusion: engineers intrinsically have a gift-giving
culture, and the motivations are also driven by norms of reciprocity,
reputation enhancement and by love of their work. They may also benefit
financially in the future. Vendors and engineers are increasingly asking to
move from a mere fee payment structure to a share of profits in the final
product.
Metiu and Kogut conclude that open development is a model that can be
transplanted from software to any field where tasks can be broken up into
modules and where a wide understanding of the common language and culture
exists. They add that "the promise of harnessing the intelligence in the
global community through web-supported innovations will be a key element in
the strategies of firms, as well as of public and creative institutions."
In its early days, Earth First! provided both focus and fuel
for the pent-up anger of the radical fringe in the American environmental
movement. Activists sought to protect old-growth forests by spiking the trees
and notifying the US Forest Service that the trees were to remain for the
continuing benefit of the public. When logging operations went ahead anyway,
protesters blockaded roads and U-locked themselves to heavy equipment,
treating angry loggers to classic songs like "Spike a Tree for Jesus" and "You
Can't Clear-Cut Your Way to Heaven." The media ate it up, raising public
awareness and making other environmental groups seem moderate.
Similarly, the FSF and the GNU Project have provided both
focus and fuel for the pent-up frustration of public-spirited hackers
worldwide. Free-software activists spike their software with the GPL to
protect it from proprietary exploitation and stage whimsical media events like
"Windows Refund Day" and the "Silicon Valley Tea Party" to draw attention to
their cause. Microsoft CD-ROMs have been launched on rockets, and Richard
Stallman treats would-be authors of proprietary software to performances of
the "Free Software Song."
Earth First! and the FSF are roughly analogous to each other
because they share the same No Compromise attitude. Both organizations promote
their causes by fostering a "holy war" mind-set.
But the battles they're waging differ fundamentally, so the
comparison between them is breaks down a bit when the impact of time
is taken into account. Earth's defenders find many of their victories to be
short-lived while the march of environmental damage continuously threatens the
web of life. But time is the ally of free-software crusaders. That's probably
why they're not noted for U-locking their heads to anything.
... ... ... ...
Approximating idealism
BSD developer Kirk McKusick probably expresses the feelings of many hackers,
including myself, when he says, "Ideally I would like all software to have the
GPL freedoms, but I don't think that's practical." Having been swept up by the
holy fire of free-software radicalism myself, I have found that it's part
rapture and part self-immolation.
One friend of mine who's a strong proponent of GPL for all
software also happens to be a dyed-in-the-wool-socialist. Meanwhile, I live in
a world of nonfree food, nonfree housing, nonfree health care, and a very weak
social safety net. It's relatively easy to go broke by making the world a
better place, and the starving-artist lifestyle doesn't much appeal to me.
No matter what anyone says, access to source code is always
an improvement over closed-source software. Once we all make that leap of
faith, the licensing model that best matches the needs of users and developers
ought to emerge over time.
The PostScript slides for my talk, "Systems Software Research is
Irrelevant" by Rob Pike may be found
here, or PDF
here.
[Jan 12, 2001] WashingtonPost.com:
Microsoft A la Hollywood
Nice parody. I especially like the statement "here is one segment of
American society that can't be bought and will not be silenced. That is
Hollywood." Is open source another Hollywood...
"...Thank goodness there is one segment of American society
that can't be bought and will not be silenced. That is Hollywood. The great
cause for which "Antitrust" sacrifices the lives of brilliant young software
developers is open-source code. Open-source crusaders believe that software
should not be copyrighted. They believe that universal freedom to use and
tinker with existing programs is the best way to promote future innovations.
But more than that: They believe the very concept of intellectual property
rights -- legal ownership of information in any form -- is downright immoral."
"As young Milo declares in the last line of the movie, as
the music swells (and if you're in any actual doubt about how this plot comes
out, stop reading here -- if you can read), "Human knowledge belongs to the
world!"
I've been covering technology news full-time for about five years now, and
concentrating almost entirely on Linux and Open Source for the last three.
Before I got heavily involved with the Internet I did over 10 years worth of
(print) free-lance investigative reporting and feature writing. I find that
online tech reporting in general is poor compared to most newspaper and
magazine journalism. Can it be improved? And, especially when it comes to
Linux and Open Source, does anyone really want quality journalism?
First, let me get "journalistic bias" out of the way: In my experience, the
only journalist a reader considers completely unbiased is one who agrees
totally with his or her point or view. So let's assume that, to most readers,
most journalists are biased in some way. I have often found myself accused of
bias in different directions by different readers of a single
article, so please excuse my cynicism on this topic. I come by it
honestly.
Now on to the meat: There is a tendency in all areas of journalism to spend
too much time covering what I call "manufactured news," a category in which I
place all press releases, political debates, press conferences, and statements
by official spokespeople of any kind, including the craggy-faced senior
firefighter every large fire department has around whose sole job is to look
good in front of a burned-out house on the nightly TV news.
Pumping out manufactured news is easy for reporters, most of whom aren't paid
nearly as much as programmers or sysadmins despite being under constant
deadline pressure, especially if they are writing for Internet media.
Corporate spokespeople are always happy to say something glowing about their
companies' products and services. Groups like the EFF and EPIC have agendas
they love to push, and sympathetic though you or I may be to those agendas
(note the bias here!) repeating their spokepeople's public statements is not
real reporting.
So
what is real reporting? In the case of advocacy groups, I believe the
most important coverage should be of the advocacy process itself, preferably
told from the point of view of people in the group doing the actual work. From
this perspective, the person selling EFF
tshirts at a trade show is a valid interview subject. He or she is exposed
one-on-one to trade show attendees' views of the EFF. Do different trade shows
(i.e. LinuxWorld and Internet World) attract attendees whose views of the EFF
differ? Is one crowd more likely to buy EFF shirts than the other? Does one
group tend to subject EFF shirtsellers to vicious harangues, while the other
says things like "keep up the good work" most of the time?
This could make an informative article that would not necessarily be biased
either in favor of or against the EFF, and the preceding paragraph also points
out a wonderful (and underutilized) feature of the World Wide Web as a
reporting medium: that instead of explaining the EFF or even mentioning that
the three letters stand for "Electronic Frontier Foundation," I simply linked
to their Web site so that readers who already knew about the EFF weren't
forced to scan a boring explanation, but those who hadn't heard of it could
instantly find out all about it, straight from the source.
I
believe links are underutilized in online reporting, especially by the
so-called "straight" press. Stories on the New
York Times Web site, for example, tend to be almost or entirely link-free,
which has always bothered me. I love the fact that, with a few keystrokes, I
can insert a link in a story that will send readers directly to the source of
my background information This allows readers both to check my work and to go
beyond my few words and do their own in-depth research if my story interests
them in a particular subject, and since getting readers interested in subjects
they might otherwise not have thought about is one of my main personal goals
as a writer, I tend to use a lot of links in my online stories.
By
using links correctly and profusely, even manufactured news can be made
interesting and informative, but I am still against it in general. Press
releases and other announcements often contain potentially important tech
news, but I would just as soon run them in their entirety, clearly labeled as
press releases or announcements -- which is how we do it on
NewsForge -- rather than regurgitate their
content in bylined stories. By doing this, we're assuming our audience is
smart enough to tell the difference between promo copy and real news, and I
feel this is a safe assumption most of the time. And by running press releases
as press releases, we are then free to put our own energy into researching and
writing "real" news, which is a rough and time-consuming job at which we are
only partially successful so far, but working hard to improve at every day.
The biggest problem we are running into with the idea of trying to bring "real
reporting" to Linux and Open Source is that most coverage of this area has
been closer to fanzine-style
hagiography than
journalism until
now, and anyone who tries to write anything that might be considered even
slightly negative about any Open Source or Free Software icons is instantly
slammed, even if their reporting is totally accurate. I stepped into this
problem big-time about a year ago on Slashdot, when I did a small writeup on a
minor potential hole in the GPL's coverage of ASPs. Flameville! How could a
non-programming ignorant schmuck like me dare to say anything even remotely
non-positive about the great Richard M. Stallman? Hundreds of comments and
emails echoed this refrain, but Stallman himself didn't seem to take my short
article as any kind of attack; indeed, some of the work now going into
GPL3 is designed to correct the very deficiency I was slammed so hard for
having pointed out.
Part of the trouble in converting the former "Gosh! Golly! Ain't all this
Linux stuff wunnerful" cheerleading that passed for Open Source news coverage
for so long into truly unbiased reporting is that many people in the "Open
Source Commumnity" (which is really a whole bunch of different so-called
communities, not a single monolithic group) haven't grasped the fact that the
revolution is over and we/they have won. It is a similar position to the one
in which the Italian Communist Party found itself when it started to win local
elections in the 1950s; it was easy for the Communists to criticize the Mayor
and City Council from the outside, but when they got into office themselves
they suddenly found that they were the ones getting criticized, and
they had a rough time learning how to deal with all that negativity,
especially when it came from publications they had considered "friendly" while
they were out-of-power underdogs.
I'm not saying that all Open Source and Linux news is or should be negative,
but that there is going to be some bad mixed in with the good. Stocks prices
for Linux companies currently suck, for instance, and that's valid news, just
as reports of huge first-day gains for Linux IPOs were big news a year or so
ago. Burlington Coat Factory and eMusic adopting Linux for big-time enterprise
applications is big news, but if a company that turns to Linux later decides
it would be better off with Windows 2000 or a proprietary Unix instead, that
is news, too, and deserves just as much attention as an Open Source success
story. And those of us who write any of those stories, whether positive or
negative, are going to get flamed for "bias" every time we say anything either
"good" or "bad" about what we cover, and if we try as hard as we can to avoid
coming to any kind of conclusion at all, or even from quoting others'
conclusions, we will probably get crucified for being wishy-washy or some
such.
But like it or not, and despite yow-yowing from GPL believers, GPL haters,
Microsoft bashers, Microsoft boosters (yes, there are still a few out there),
die-hard Apple fanatics, Amiga lovers, *BSD believers, and all rest of the
people who follow tech news closely and have something to say (usually rather
loudly) about the way it is written, coverage of Linux and Open Source will
gradually mature and become more even-handed, as will all coverage in the
computer trade press, because tech news is gradually becoming interesting
enough to the world at large that it is starting to get the level of
journalistic attention that, in the past, was reserved strictly for
"important" subjects like politics, business, sports, and movie star love
scandals.
Robin Miller (aka 'Roblimo') has been a professional writer and editor since
1985. His work has appeared in hundreds of print publications and on dozens of
high-profile Web sites. He is currently editor-in-chief of the Open Source
Development Network (OSDN), owner of freshmeat,
Linux.com, NewsForge, SourceForge, and a number of other tech-oriented Web
sites.
Assuming that you are a company considering open source for
your own code, then the bottom line is revenue. If the software can't make
money, you can't pay the bills, and everyone will need a new day job. The
choice to open source has many implications to revenue, so the implications
need to be considered as primary reasons for or against open source.
If you do open source, revenue purely from the software is
all but eliminated. This leaves only publishing (sticking the software in a
pretty box), tech support when the user gets stuck, and consulting for people
that need help setting up your software as sources of revenue. Unless your
product is many megabytes, hard to use, and hard to set up, then these may not
be enough to cover development and marketing costs.
Open source does give you some advantages that offset the
inability to sell the software: bug hunting, reliability, and community. Since
the source is out there, if there is a bug, anyone can hunt it down and then
send the fix back in to be incorporated into the master copy. With all of this
bug-stomping, your software will end up being very stable and reliable; this
is offset by all the semi-functional "neat stuff" that users will want to add.
While the open source community can be a large source of
programming talent, do not open source your software because you expect them
to solve your problems for you. You will still have to do all of the design,
initial development, maintenance, and product documentation. The desire for
programmers to fix any bug that doesn't directly affect them or to add a
feature that they don't personally want is very low. Any sufficiently hard bug
to track down will result in a bug report, not a patch. User-submitted
"features" will tend to be neat things that they and a few other people may
use, but all core functionality will still need to be developed by your
programming team.
Benefits of open source
There are many areas where open source is a simple and wise business decision
from any angle.
Legacy applications that are no longer a part of
current products being sold are an excellent area for open source, assuming
that no third-party software is incorporated into the product. Old
applications that are no longer cost effective to maintain or support can be
made open source as a way to abandon the product, while not abandoning the
users (as users who feel abandoned typically become ex-customers in a very
short time). This way, the users who cannot migrate to newer products get the
source and can use it to fix or modify things to suit their needs, while your
entire development staff can move on to current projects.
The specifications to hardware and device driver code is
another obvious place where publishing more information will benefit the
product. In the past many vendors withheld the specification on how to work
with their hardware fearing it would give competitors an advantage. The only
real effect this had was preventing many users from having the option of
buying their hardware. Writing device driver code is a development cost that
is only made up by selling more of the hardware. Publish everything you can
about it, and even help to get drivers written for the various open source
operating systems. This will help you sell more hardware to anyone who wants
it.
Any product that is aimed at establishing a standard
protocol or API needs to be open source. If the source is available, then the
adoption of any protocol or API will be much faster, and the programmers who
use it will be far more comfortable with it. Many modern protocols and
attempts at standards that were not open source failed before anyone even
noticed they existed. In these cases the software itself does not represent
the value; the things it enables does. Often, the amount of revenue from
consulting, training, and licensing from the additional developers will
completely dwarf any revenue that would have been gained by keeping the code
proprietary. Many large Fortune 500 companies make 100 times more revenue on
their consulting and support contracts than they do on their hardware and
software sales. The key to this case is that the protocol, API, or hardware is
worthless until a developer takes it and uses it to create value for the user.
Open source can be used as a powerful attack and
defense mechanism while competing with rivals. If a rival's application has no
need for support or consulting to use it, and an open source version of that
application can be created and released, then the revenue from the closed
application will be removed. This is very similar to the old method of
discounting a product until a competitor is driven out of business, or salting
the earth in a war. On the other hand, if you can develop your application as
open source, then a rival will have no way to attack you in a similar way.
The realms of closed source
There are still many areas of the software world where open source has not
made much progress. In these cases, open source projects are rare, and those
that do exist are not a threat to commercial developers.
Game and entertainment software is the first area where cost
is not an object, and open source alternatives rarely exist. People want the
latest and greatest entertainment software, and are happy to support the
developers if it will get them more frames per second, more players in the
game, and more realistic blood splattering and gore. The developers of this
software are also so in demand that anyone showing signs of free time and
talent would be hired instantly. If the user is not willing to pay, then they
will either pirate the entertainment content or simply buy one of thousands of
other entertainment alternatives. The driving factors in this category are
that the applications are more entertaining to use than they are to write, and
it requires constant work to keep up with the state of the art.
The realm of scientific software, large complex
applications, and applications that require a Ph.D. or years of experience to
even contemplate working on are also not of general concern to the open source
world. Open source projects succeed when large numbers of coders each
contribute something to a project. Since the supply of extremely skilled
people is very limited, and they are often already working 60+ hour weeks,
they do not generally have any time left to contribute to open source projects
unless the project has gone commercial. As a general rule, if the
average to advanced coder can develop an application, there are probably
several open source versions of it already. If the average coder
cannot begin to work on the software, then it is likely there are only
commercial versions of the software.
The other area that is not very open source friendly is
boring software that is not sexy to develop, or applications that need
end-user support. Things like word processors, spreadsheets, and other
end-user tools. It's no secret that most open source software is not
documented in a way that an end-user can use. You don't tend to see
applications where the user is likely to need to call in for help for
something that is being given away for free. Until open source projects
started forming companies and paying people to develop all the boring
applications non-programmers actually needed, there was no sign of them.
One thing to remember no matter how you license your
source is that it takes about 1/20th the time to copy and reverse engineer
software then it takes to develop it the first time. Your competitors,
be they another company or an open source project, will be on your heels from
the start unless you have something they can't do. Usually, things that
they won't be able to do include hardware devices, patented technology, or a
reliable service and support infrastructure. This has been true since
the dawn of time, but in the past you could at least turn around and compete
on price. Those days are gone. Now, once they catch up, your revenue is in
danger. But they won't be making any money either, so if the stock market
bubble funds your competitors but not you, then you may have to worry - unless
you use open source or other tactics to head them off.
Innovation issues
One thing that open source is not generally known for is innovation. In
general, the rate of innovation in the closed source world is far faster
because the desire to stay ahead and stay in business has always been stronger
than the desire to re-implement something that's already been done.
Even the operating system gems of the open source world are just starting to
gain the security and critical enterprise reliability features common in the
high-end commercial systems 10 years ago.
All coders by nature like to do new and interesting
things, but not necessarily things that are really new, just things which are
new to them personally. A simple search for any common application
will result in dozens of nearly identical open source projects to build it.
Like an army, there are a few high-skill generals and masses of low-skill
soldiers working their way up the ladder by working on projects like the ones
that the generals worked on when they started out. Projects have high
overlap, with low innovation.
If you have an application you need to build and there
is an existing open source project to build it or something like it, then join
that project or hire some of the main people in the project to work on it full
time. The application can then move to the level where service, support, and
consulting become sources of revenue. There is a long history of projects that
started out as research or open source and turned into commercial ventures.
Licensing issues
If you do decide to open source your software, you will face the decision of
choosing a license or writing your own. If one of the existing blessed open
source licenses (see Resources) is acceptable, it
will save you having to go through the approval process and months in a very
uncomfortable spotlight. Put on your flame-proof suit, because you will
encounter fanatics no matter what license you choose to use, but it is your
software and you get to decide how to license it.
Unlike commercial licenses, open source licenses have never
really been tested in court. So far peer pressure and threats of bad press
have been enough to enforce them. No one is sure what will happen when the
licenses are finally tested in the courts, not to mention the courts of
countries with laws different than the United States. Odds are no license
(open source or otherwise) means anything due to the patchwork of
international laws applied to a global Internet.
Open source meets the real world
There is a rapidly growing middle ground in the licensing of software to deal
with the interests of companies and authors while also having the spirit of
open source.
Hybrid licenses like the Apple Public Source License, or the
Sun Community Source License (see Resources) are
not considered "pure" open source by the older factions of the open source
community. The licenses still protect the ownership, patent, and other
interests of the inventors but publish the source and make it usable to many
people. The open source community initially objected to these new licenses,
but eventually licenses evolved that were reasonably acceptable to both
commercial inventors and the open source community.
Dual licensing is also a common option. One
way is to release everything under both a traditional commercial use and an
open source license. Users who wish to use the code commercially can provide
revenue while providing the benefits of open source to noncommercial and
academic users. The other way dual licensing is done is to lead with the
current version under a commercial license, and follow later releasing old,
obsolete versions under an open source license. Again many paying users will
need the most current version; others can wait for the version to be made open
source. Dual licensing seems to be more acceptable to the open source
community since it has been done for a longer time.
As one of the creators of Berkeley Unix,
Bill Joy knows a thing or two about developing and marketing a free operating
system. Sun Microsystems' chief scientist has survived the Unix wars and has
watched both his company and its chief competitor, Microsoft, grow from tiny
start-ups to industry giants. Though he has had a major hand in the
development of such important Unix technologies as NFS (Sun's Network File
System), the Berkeley Unix TCP/IP stack, and the vi text editor, Joy's
current obsession is trying to build a thriving development community around
Sun's Jini distributed computing technology and its not-quite-Open Source
software licensing model. Joy recently accepted Linux Magazine's
invitation to dinner, where he gave Publisher Adam Goodman, Executive Editor
Robert McMillan, and Associate Editor Eugene Kim the lowdown on what Sun
thinks of Linux and Open Source.
Linux Magazine: One of the reasons we wanted to talk to
you was that you have a long history with and a broad perspective on Unix and
free software. What do you think of Linux? A lot of people talk about it as
more than just an operating system.
Bill Joy: It's actually less. It's just a kernel if you want
to be technical about it. It's politically incorrect to conflate Linux with
the applications. At least one person will get upset. So to be quite precise,
it's just the kernel of the OS. When we did Berkeley Unix, we were doing the
operating system and all of the applications.
In a lot of ways, the Berkeley Systems Distribution (BSD)
was on the road to being free with source available and many of the things
that Linux is. But it got hung up in this legal fight between the University
of California and Unix Systems Labs.
Those are the accidents of history. Now with Linux, we have
this new version of Unix written with similar kinds of values that BSD had.
One of the great strengths of Unix is that it's been rewritten and
reimplemented several times. Applications with similar names and
similar functions are widely understood, which allows this healthy kind of
invention and reinvention to occur.
LM: So if it weren't for the lawyers, we'd be called
FreeBSD Magazine?
BJ: If BSD had been free, there would have been no reason to
rewrite it. The new thing that happened with Linux was cultural. The Internet
is now coupling people together in ways that probably couldn't have happened
before. How else would the developers have found each other?
I did my work in the era of the magnetic tape. We sent Unix
in source form to thousands of people; they sent us a few hundred dollars,
because I had to pay for the postage and for the printing of the manuals, and
that was our network. It was a postal-age speed thing. It was not very
convenient.
LM:Were licensing issues as important back then as they
seem to be now?
BJ: No. I knew I needed a license for BSD because at some
point Berkeley was going to discover it. So I just took a license from the
University of Toronto and modified it a little bit and started using that. I
figured if I sent people a tape, and there was nothing for them to sign, they
wouldn't take it seriously.
When you give things away for free, often people think
that's what it's worth: Nothing. So charging them a small amount and giving
them a license to sign actually created a perception of value. I'm not
saying the tape didn't have value, but an awful lot of stuff comes across your
desk that you just throw away.
LM: So, what did your license actually say?
BJ: I don't remember. It was a one-page thing. I didn't have
any lawyers look at it and I'm not a lawyer. I just made it up as I went
along.
What happened was that at some point we were getting to be
big enough that we were sending out hundreds of these [Unix tapes] a year and
charging hundreds of dollars for them. A quarter of a million dollars in
revenue is a great deal of money for a graduate student. Scott McNealy
likes to say: "To ask permission is to seek denial." And we were
operating with that philosophy.
But there were huge amounts of money involved and we were
becoming pretty visible. So eventually we decided to send AT&T a letter asking
them: "Is this okay what we're doing?" And 18 months later they sent a letter
back: "We take no position." We won't answer your question. So that's what it
was like to deal with a regulated monopoly of lawyers. That same sort of legal
structure is what caused [AT&T] to license the transistor for nothing.
So we couldn't actually get an answer from them and it was
only years later that this whole fracas erupted around who owns the code. It
turned out their code was as tainted with Berkeley stuff as ours was with
theirs, so they eventually came to a truce. That's what I've heard second hand
or just drinking wine with people. So there's a very tortured and funny
history to all this code.
LM: Have you ever contemplated what it would have been
like if you'd released your code under the GNU Public License (GPL) or
something similar?
BJ: I don't see what the advantage to it is. The important
thing is that people have the source code. I actually think it's fine that
people can take BSD and make improvements to it and reap software profit.
I don't think, given where we were and what we were trying
to do, that the license made that much of a difference. At Berkeley, we had
the model that software is the result of your research. The university
tradition is that when you do research, you publish. So not giving people the
source code for software meant that you weren't publishing your research. A
fundamental model of BSD was: Software is a result of our research. We'll
publish it and other people will use it if they choose. If someone
commercializes it, I don't particularly care, because if you publish research
in a university, people can commercialize
