For the last six or so years, I've been directly participating in the open source software movement. I maintain the popular Data::FormValidator perl module. I regularly participate in several other projects through mailing lists, bug reports and direct feedback.
I have found the open source software community to be a functional
democracy. By this I mean that the leaders tend to be fair, responsive
and accountable. Many users participate with feedback and make a direct
difference in the code, the fundamental rule set of software culture.
As an observer and participant, open source culture is inspiring. It
provides a living model for how large and small groups of people can
This experience has real implications on the rest of my personal
life. I have greater expectation that others leaders in my life should
be accountable and responsive, whether they are elected are not. I have
a strong sense that I can personally make a difference by communicating
with others, or taking direct action.
At a deeper level, it addresses that core feeling of "there's
something wrong with the world and I'm not sure what to do about it".
This world-wide network of volunteers illustrates for me a functional
social group, one full of people who are generally honest, fair,
trusting and realize supporting the communities they are a part of is
in their best interest.
Beyond the personal: larger effects
The ripple effects of open source models go beyond affecting the lives of participants like myself.
Some of the largest organizations in the world are beginning te deploy it across the enterprise, on desktops as well as servers. Goverments and large corporations are adopting open source. Sometimes the motive is simply that OSS performs adequetely for a lower cost. Other times the security, stability and openness are critical factors.
Along with the software these large organizations will also be spreading the open source culture along with it.
Large organizations often have money or some kind of control as a
primary motive. By contrast Open source culture, is a gift culture,
with sharing and openness emphasized. Financial concerns are secondary,
if present. To illustrate, the Gimp is an excellent open-source graphics program which runs on Windows and Mac as well as Linux. Their website didn't even have a donations like when I wrote this.
Many recall Margaret Meade's quote: "Never doubt that a group of
thoughtful, committed citizens can change the world; indeed, it's the
only thing that ever has." I believe the same principal may apply for
change among corporations and other large organizations: "It only takes
a few enlightened corporations to transform corporate culture."
Consider this: As these first few enlightened corporations adopt OSS
on a large scale, contributions will flow back to the open source
community. Corporations have an incentive to adapt and improve the
software to meet their needs. The ecomonics of open source
dictate that contributing their software changes back to the community
will benefit themselves. When they do so, the improvements are
available to all.
This isn't abstract theory. This is happening. Consider Apple
Computer adopting "KHTML" as the foundation for their Safari web
browser. Not only was Apple able to bring a quality product to market
faster and cheaper by choosing KHTML as a foundation, many of their
improvements have been returned to the community and have now improved
the Konqueror web browser popular on Linux desktops.
As part of the German goverment's adoption of Open Source, security and integration features of the KDE personal information suite have been returned to the community.
With a relative few enlightened organizations on board, Open Source
will have the resources to create a desktop system that will be
sufficient for any other organization with similar needs.
Long Term Implications
Some long terms implications of the wide spread use of Open Source seem clear.
Greater support of local economies
Organizations will hire more programmers from their local economies
to solve problems, because the open source model allows them to do so.
No longer will they have to depend on Microsoft in the USA to solve
critical problems. A local programmer who natively speaks the same
language can review the source code and make the needed adjustments.
Longer hardware life-span
More old hardware will stay in use. Microsoft and Apple continue to
build their latest operating systems to require hardware that is
extremely new, while dropping support for systems that run on older
hardware. By contrast, there are already a number of open source
distributions which run happily on old hardware in a variety of configurations.
This reduces the toxic effects on human health and the environment
by manufacturing fewer new systems. At the same time, it frees up money
that would be spent on new hardware.
The long term cultural effects are harder to perceive. What I feel certain about is that there will be some infusion of open source values into the broader culture. I expect this to be positive change.
I'll illustrate some of the values of the open source model through examples from my own experience.
Many times I have contacted the leaders of open source software
projects with some question or suggestion. Often I'm suggesting they
alter their software to fix a bug, add a feature, or update the
documentation. In effect, I'm asking them to work more for free, after
receiving the software for free in the first place.
Quite commonly I receive a response within 24 hours. I'm not
getting back a form letter or a message from a secretary. The responses
most often are directly from the leaders themselves and are direct and
personal responses to my inquiry. Quite often my suggestions are accepted and appear in a future release.
One reason this is even possible is because of the cultural
structure of projects. Many projects have one primary developer, or
only a few people working on the project. This is a bit different than
representing all the people in the state of Indiana or the USA.
It is however, a lot like putting a lot more power into the hands of local governments and a lot less power higher up the power structure.
The open source projects that appear to be the largest, such as the Debian
GNU/Linux Distribution, are really mostly composed of infrastructure,
guidelines and frameworks. The real work of programming is being
performed by largely autonomous small groups. Thus, even with large
projects, I can often figure out who is responsible for the issue I'm
having and contact someone directly who will likely respond.
While open source software leaders tend not to have secretaries to
filter their mail, often there are community discussion lists devoted
to particular software projects. Here users often are able to help each
other without the leadership intervening at all.
Leaders who are unresponsive to their users are soon replaced.
This is in fact how I became the maintainer of the
Data::FormValidator module. Months went by without being able to
contact the original author, while it was clear further updates to the
software would be generally useful. One day, with the blessing of
another Perl author, I uploaded my own slightly modified version to
CPAN, the Comprehensive Perl Archive Network. There was no formal
review committe or approval board, I just did it. It's worked out fine
Sometimes leaders are available and communicating, but their users
don't like what their saying, or they don't like the direction the
project is moving in. In this case, open source licenses allow for
'forking' a project-- starting with a copy of the source code and
taking development in a different direction. Now users are free to
follow to whichever project is most effective for them. Often there is
little bad blood involved. The new projects will simply fill a
different but important ecological niche in the software environment.
For example, the FreeBSD was
forked to found OpenBSD, which has a greater focus on security, as well
as NetBSD, which has a greater focus on portability.
Participation is encouraged
Being an open source contributor is far from having some elite
status. Most projects I'm aware of would welcome more contributors. Not
just programmers, but documentation writers, translators, graphic
artists, website maintainers and beta testers.
While it may be laughable to think about having your name somewhere
in the credits of the next version of Windows, appearing as contributor
in the next version of Linux may be much easier than you think. For
example, I offered a developer for the Kvim
editor projet access to my home FreeBSD box. Last I checked, I'm listed
in the credits for that software, which is available as part of some
Linux distributions. I mention that because I felt my contribution
there was small. Yet, many project leaders understand that giving
credit to contributors is extremely easy, and encourages repeat
I was surprised and concerned when it was suggested thatI take over
the maintainership of Data::FormValidator-- I was only an interested
user who wanted to submit a patch-- I had never maintained software
that had been widely used before.
In restrospect, I was somewhat under-qualified for this in the sense
that I didn't have a strong sense of how to maintain software quality
at the time. On the flip-side, I took the responsibility seriously. The
experience has been pivotal in my development as a programmer. I
believe this kind of "trial by fire" works. I think people will often
step up to the plate when given a responsibility. In open source
projects, there are many opportunities for contributors to take on
roles of responsibility and leadership.
The functional CPAN anarchy
As a final anecdote, I want to mention CPAN, the central Perl software repository.
Those who maintain web servers that use Perl modules have likely had
the experience of using the similiarly named "CPAN" module to upgrade
some Perl module to the latest version. This is done automatically over
the internet. Often the requested software module will require several
others which will be upgraded or installed.
Most likely, everything that was working before kept working, and
some new bug fixes or feature additions arrived with the upgraded
software. Considering the loose and informal controls behind this
simple action, the success of it may seem somewhat incredible.
CPAN is largely a functional sort of anarchy. Other people like to
politely describe it is as a "public commons". In practice, it's
relatively easy to get an account to upload software to CPAN. Armed
with an account, anything you upload will immediately start a process
of being integrated into the offical CPAN network. This includes
appearing in directories, the CPAN search engine, appearing on various
"what's new" lists, and having the software distributed to many
download sites around the world. There is no external review of the
software as part of this process.
There is a restriction that you can't replace someone elses module
with your own. You can however name your module whatever like. To
prevent confusion, names tend to stick forever, whether well chosen or
not. There's somewhat an attitude of "upload first, ask questions
The primary quality check is that some volunteer testers may (but
may not) test your software against its own test suite and publicly
report the results. However, there's no requirement to include any
tests with your distribution, much less to throughly test it. Thus, for
the system to report "all tests passed" for a given perl module is not
strictly meaningful anyway.
It is traditional to include a "ChangeLog" with each Perl
distribution, documenting what bug fixes, feature additions and other
additions have been added to the software. However, these are not
required, and it can be non-trivial to verify the claims there.
All this might make CPAN sound like a system ripe for abuse, perhaps full of corruption. In fact quite the
opposite is true. Often when asked what the "killer app" for Perl is, people will cite CPAN as the most valuable
Perl project. It is often regarded as a source for high quality software and is widely used around the world.
How can this work? I'd say it's because people are generally decent. They are also egotistical. :) Programmers
are concerned about their reputations and how others perceive them. Thus, the work they display publicly tends
to be their best effort. The open source model takes care of a good deal of the rest of quality assurance. The
more popular the software, and the and more critical the bug, the faster it gets found, fixed, and released in a
You may be interested in the following resources about Open Source: