Compared to other programming languages, the UNIX operating system is—well, ancient. As a result of that established history, many of the principles taken for granted by developers today stem from proven UNIX practices. Open source development can likewise trace its roots to the UNIX development practices established decades ago.
With age comes a certain amount of maturity and wisdom that can be expressed in a guiding set of principles. The principles of UNIX programming are discussed and explained in "Chapter 19: Open Source," from The Art of UNIX Programming, written by Eric Raymond and published by Addison-Wesley Professional. Builder.com exchanged e-mail with Raymond on several issues facing UNIX software developers and open source community. Here are some of his insights.
Download the sample chapter
We've provided "Chapter 19: Open Source" as a downloadable excerpt from Eric Raymond's book, The Art of UNIX Programming.
The state of UNIX programming
Q: With the release of MAC OS X, with its UNIX roots, there seems to be a flurry of open source development activity for the Apple computer platform. Some of our members have expressed interest in developing for MAC OS X. What long term impact will MAC OS X have on UNIX software development, and open source development?
A: I think the most likely impact is for the open source community's standards for quality of user interfaces to rise as the Macintosh lessons are gradually absorbed. The proprietary UNIX community is more insular and seems less likely to be affected.
Q: A major part of the culture of open source development is the idea of volunteers taking a personal interest in the development and refinement of a software project. Playing the devil's advocate, doesn't that mean that eventually volunteer developers will lose interest and development will cease? How do you convince an enterprise to invest in software that may be orphaned without an upgrade path?
A: Oddly enough, sustainability is a question open source developers often find themselves asking about proprietary code. We have a history of long-running projects like Emacs, Linux, Perl, and Apache that shows we know how to handle succession problems in volunteer groups and successfully forward-port our stuff across generations of computing technology. I personally still maintain and distribute a utility I wrote in 1982.
Most closed-source vendors don't seem to be able to maintain continuity over timeframes anywhere near that long. Binaries are much more brittle than source code. Products get end-of-lifed and are never seen again. Commercial closed-source software seems to have a half-life of about three years. Profit-seeking is fine, it's the engine of the economy—but most managers can't afford to look beyond the next quarterlies, and the result is chronic short-termism and instability.
Markets are a great way to solve material-scarcity problems. But for sustained long-term creative behaviors, religion or artistic aspiration is actually a more reliable motivator than money. The hundreds of years of effort that went into constructing each one of the great medieval cathedrals of Europe were not organized by limited-liability corporations.
The hacker culture will still be here a century from now. At any normal rate of attrition, 99 percent of the proprietary software firms now in existence won't be. If you're an IT manager, plan accordingly.
Q: How do you answer the common proprietary-software-universe criticism of open source development: How do you make money on software if the source code is made available?
A: Open source turns software into a service industry. The choices come down to singing for your supper (getting paid through tips and donations), running a corner shop (a small, low-overhead service business), or finding a wealthy patron (some large firm that needs to use and modify open source software for its business purposes).
Programmers still make money in this world, and projects still get funded. What goes away is investor leverage. Service-provider firms (think of medical and legal practices) can't be scaled up by injecting more capital into them; those that try only scale up their fixed costs, overshoot their revenue base, and starve to death.
So you can still make money by doing open source, or by using open source—just not by speculating on its production.
Application to all programming
Many of the principles that underlie open source development can be applied to commercial and proprietary software development. Download the sample chapter to read the time-tested guidelines for releasing open source created code. These guidelines establish a base of assumptions you can use to assure the success of your next development project—whether open source or not.
As you read "Chapter 19, Open Source," ask yourself whether you can work as a developer in an open source environment. Do you agree with the principles outlined? Will you implement them or do you prefer the current prominent paradigm of proprietary commercial software? Consider these questions and then share your thoughts with the rest of the Builder community in the discussion below. Let's form a consensus, if possible, on open source development.
This book excerpt is from chapter 19 of the forthcoming book by Eric S. Raymond, The Art of UNIX Programming, ISBN 0131429019, copyright 2004, to publish in late September 2003. All rights reserved. This chapter, titled "Open Source," is posted with permission from Addison-Wesley Professional.
Mark Kaelin is a CBS Interactive Senior Editor for TechRepublic. He is the host for the Microsoft Windows and Office blog, the Google in the Enterprise blog, the Five Apps blog and the Big Data Analytics blog.