May 1, 2003

'On Open Source Procurement Policies'

- by Tony Stanco -
Editor's note: This is the (lightly edited) transcript of a presentation Tony Stanco, Director of the Center of Open Source & Government, and
Associate Director of the Cyber Security Policy and Research
Institute at The George Washington University, made at a meeting of the New York City Council's
Select Committee on Technology in Government on April 29, 2003.

Good
Morning, Chairperson Brewer and members of the Council. I am Tony
Stanco, Director of the Center of Open Source & Government, and
Associate Director of the Cyber Security Policy and Research
Institute at The George Washington University.

It
is a special pleasure to appear before you to speak on Open Source
procurement policies. This is a very timely topic being looked at by
a number of governments around the world. Governments ranging from
Texas and Oregon to Peru, India, China, U.K., Germany, France and the
U.S. Federal government are all seriously analyzing Open Source
procurement policies. As I am sure you are aware, or you will shortly
find out, this is a very politicized issue with multi-billion dollar
companies and their non-profit associates actively trying to
disparage the Open Source model. The Open Source side doesn't have
the money to hire lobbyists and salesmen to
constantly knock on the doors of government officials to give their
side of the story. So, opportunities like this where both sides are
allowed to speak openly and equally are very welcome.

One
question that is seldom asked is, "How can Open Source possibly be
giving multi-billion dollar companies so much competition that they
feel they need to actively dissuade government officials from even
thinking of using
Open Source software?" This is not an idle question. Open Source
doesn't have lobbyists or marketers or ad men to promote its
software. So, to say that governments shouldn't have rules to
consider Open Source software, as Open Source opponents often do,
takes away the only avenue that Open Source has to really reach
government. The Open Source sales model is fundamentally "pull"
model, where enlightened procurement officers need to know enough to
ask about Open Source in the first place. There is no "push"
model of sales in Open Source like that employed by the multi-billion
dollar companies with their legions of salesmen,
ad men, and lobbyists. In fact, the average large software company is
1/3 software developers, and 2/3 salesmen, marketers, management, apologists, and lawyers. So, a very apt question is -- if their
software is so good and they have an extra 2 people for every one
developer pushing it, why is it that they try so hard to impede
government officials from making side-by-side comparisons? You would
think they would be anxious to have procurement rules that
require such comparisons so that they can show how much better their
very expense software is.

But
they don't do that. Instead, they descend on any government official
who tries to introduce a law or regulation that requires procurement
officers to "consider using Open Source software when acquiring
new software," as the Oregon House bill merely does.

This
is a very subtle silencing of Open Source. It is supremely
disingenuous, and violates the fundamental principle of a free
market: fully informed decision-making. Why shouldn't procurement
officers be asked to consider Open Source software? In fact, having
such rules is only doing what The President's Information Technology
Advisory Committee (PITAC) recommended should be done to level the
playing field. In its October 2000 Report to the President on
"Developing Open Source Software to Advance High End
Computing," the committee said, "a 'level playing field'
must be created within the government procurement process to
facilitate Open Source development." Notice the use of the
word "must" in that recommendation.

At
this point, I want to leave the procedural fairness issues of having
Open Source considered equally by procurement officers, and move on
to what I see as the substantive issues that make Open Source
software considerably better than traditional proprietary software
for government use. I will cover these under the headings of 1.
Democratic Implications, 2. Privacy, 3. Cost, 4. Research and
Development/Technology Transfer, 5. Education, 6. Job Creation, and
7. Security.

Democratic
Implications

Governments
are special entities and their functions and operations can be at
odds with proprietary software applications that are developed for
multiple purposes. Governments have special obligations to protect
the integrity, confidentiality and accessibility of public
information throughout time like no other entity in society.
Therefore, storing and retrieving government data through secret and
proprietary data formats tied to a single provider is especially
problematic, since the usability, maintenance and permanence of
government data should not depend on the goodwill or financial
viability of commercial suppliers.

Furthermore,
citizens have a right to transparency in public acts, which may be
hampered by secret, proprietary software. A clear example of this is
e-voting software. I expect no one would seriously defend the right
of proprietary software companies to prevent political candidates
from inspecting the software that tallies the votes in elections.
There are many other public acts that fall into the same category. So
many, in fact, that the onus should rightly be placed on companies to
justify the use of proprietary software in purely governmental
settings.

Privacy

There
is a constitutional right to privacy, and it is
incumbent on government to set rules to protect the privacy of
its citizens. Software that may transmit private data to, or allow
control and modification of computer systems by, third parties
without the explicit consent of the user is a violation of the
citizen's right to privacy. It is disingenuous to argue, as Open
Source opponents often do, that the market will sufficiently protect
the rights of citizens in these circumstances. Software follows the
principle of "network effects" where, after a certain
tipping point, all consumers lose their freedom of choice and are
herded into using the same product for the sake of interoperability.
The existence of monopoly situations in software also work to
restrict freedom of choice, further limiting the protective effects
of a purely market-based solution. As a result, government
intervention is appropriate to protect the privacy rights of its
citizens.

Cost

On
Tuesday, April 15, 2003 Mayor Bloomberg, facing a budget gap of $3.4
billion, warned that the city may have to lay off up to 10,000 city
employees on top of the 4,500 previously announced job cuts. This at
a time when the City of New York spends almost $750 million each year
on information technology.

It
is an anomaly that software prices are increasing during the worst IT
slump in decades, but it is happening, because with proprietary
software there are negative network effects and powerful monopolies
that can extract ever-increasing monopoly rents even as many others
are facing severe economic distress.

Could
software costs be cut, instead of government jobs, in an effort to
reduce the deficit? It is a question that should at least be
investigated. Replacing some proprietary software products
with free, Open Source counterparts would obviously eliminate the
licensing costs of those products. There are reports from people who
testified at the Oregon Open Source hearing that some school
districts saved so much money by using Open Source software that they
could afford to hire additional teachers.

Google
and Amazon serve as examples of leading IT companies that saved money
in the real world with Open Source software. Why couldn't government
do the same thing?

Google
is powered by over 10,000 Linux servers and its founder said that
Linux was chosen because it "offers
the best price-for-performance ratio
."

In
a filing with the Securities and Exchange Commission (where I
happened to work for almost 6 years as a securities attorney before
joining George Washington University),
Amazon said it was able to cut technology expenses by about 25
percent, from $71 million to $54 million. The reduction was
attributed to a large degree to Amazon's migration to a Linux-based
technology platform that utilizes a less-costly technology
infrastructure
.

Research
and Development/Technology Transfer

The
Open Source method is analogous to the scientific method, where
researchers share information and results, and are not hampered by
having to constantly "reinvent the wheel." Additionally,
Open Source researchers do not have to deal with expensive and
restrictive licensing terms, which arbitrarily preclude the
involvement of talented people. This creates a very low threshold to
get into the research and development of projects, allowing smaller
schools and even industrious individuals to participate.

It
is acknowledged within the R & D community that non-Open licenses
can hinder technology transfer, because the license holder controls
what gets done with the research. Sometimes, those licenses preclude
sharing or even showing others the results of the research. Other
times, the license holder decides not to implement the R & D
themselves , and refuses to let anyone else
to do so, either. As a result, the research gets buried, forgotten
and never used. This doesn't happen with Open Source.

Education

Open
Source is a superior way to educate the next generation of IT
professionals. With Open Source, the developers see and study the
actual code running real world systems, rather than working with
stripped-down "toys" designed merely for educational
purposes. Many developers have recounted that they learn best by
trying and watching what happens in the program as it runs. This
should not be surprising at all, since this was how developers
learned the craft before the 1980s when the closed software industry
arose. Open Source is just returning software to its free and open
roots.

Also,
it should be noted that Open Source software development is known to
be more modular and more readily understandable from its very
structure. It is developed in this organized way, because otherwise
people would not be able to contribute effectively to the code base,
since oftentimes there is no documentation but the code itself to
study. As a result, self-education by looking at the code is an
important feature of Open Source that is "baked-in" to
the development model itself. For the lawyers in the audience this is
similar to the "case method" of learning law, where
struggling with real cases is generally expected to create better
lawyers. The theory is that in studying the hard cases, there is a
transcendent moment when the veil of utter confusion over most
first year students is lifted as the patterns and logic of the cases
suddenly, magically emerges. It is said that young software
developers experience the same sort of thing in studying the
complexity of Open Source programs and are, thereby, made better
developers for enduring that challenge.

It
should also be noted that Open Source has marvelous outreach programs
run by community groups in most cities around the world. It is very
common for teenagers, IT students and experienced professionals to
attend free Open Source events to share ideas, software and
programming skills. There are a number of these groups in New York
City, which itself has a large and vibrant
Open Source community.

Job
Creation

The
business model for Open Source software is that of a specialized
services industry, similar to law, medicine or engineering. As a
result, moving government systems to Open Source software means that
there will be more local, high-paying IT jobs for integrators and
consultants in New York City's own Silicon Alley. Furthermore, using
government procurement to help create New York-based Open Source
consulting jobs has a spin-off economic multiplier
effect that will benefit many other New York residents, too.
Software dollars that are kept in New York, and not paid to
out-of-state companies, will obviously increase the city's and
state's tax base.

Security

The
open secret in the defense and intelligence communities around the
world is that Open Source is the preferred software for secure
systems. These groups don't trust software that they can't study and
compile themselves, because of concerns over bugs and "spyware,"
and therefore would rather use Open Source software for their
sensitive and classified systems.

Quoting
from the Executive Summary of the January 2003 Mitre Report called
the "Use of Free and Open Source Software (FOSS) in the U.S.
Department of Defense":

"The
main conclusion of the analysis was that FOSS plays a more critical
role in the DoD than has generally been recognized. FOSS applications
are most important in four broad areas: Infrastructure Support,
Software Development, Security, and Research. One unexpected result
was the degree to which Security depends on FOSS. Banning FOSS would
remove certain types of Infrastructure components that currently help
support network security. It would also limit DoD access to, and
overall expertise in, the use of powerful FOSS analysis and detection
applications that hostile groups could use to help stage
cyberattacks. Finally, it would remove the demonstrated ability of
FOSS applications to be updated rapidly in response to new types of
cyberattack. Taken together, these factors imply that banning FOSS
would have immediate, broad, and strongly negative impacts on the
ability of many sensitive and security-focused DoD groups to defend
against cyberattack."

This
concludes my testimony today. I would be pleased to respond to any
questions you may have.

Category:

  • Migration
Click Here!