Open Source: Culture Shifting Software

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 collaborate effectively.

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 sourcedictate 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.

Cultural Ripples

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.

Experiential Evidence

I'll illustrate some of the values of the open source model through examples from my own experience.

Responsive Leaders

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 DebianGNU/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 since then.

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 Kvimeditor 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 contributions.

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 later".

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 new version.

Further Resources

You may be interested in the following resources about Open Source:

• Frequently Asked Questions about Open Source
• Keeping An Open Mind, an introduction to the Open Source movement
• The Magic Cauldron: The economics of Open Source explained