Foreword

The IBM 701, announced to the public in 1952, was IBM’s first commercial scientific computer.  Three years later representatives from seventeen of its installations met to see how they could coordinate their programming work.  The organization they formed was named SHARE, and this book contains parts of its DNA.  Not many know that a key contribution of SHARE was the distributed development of system and application programs and their dissemination in source code form.

We’ve come a long way since the early days of SHARE.  At that time both IBM’s operating systems and SHARE’s patches and libraries were usually distributed in source code format.  Nowadays software distribution is bifurcated into two large branches.  Software sold for profit is more often than not delivered in a closed binary format, while software available in open source format is typically distributed for free.   This second branch is where we’ve seen significant growth and innovation in the last years.  Auspiciously, this book examines the profound implications of the open source software development practices.

In a Communications of the ACM article titled “Software is not a Product” Phillip Armour fittingly described software as a medium for storing knowledge.  Knowledge storage isn’t novel: the DNA, our brain, material artifacts, and books have served this purpose for centuries or millennia.  Yet software is different, because it is the first human-created mechanism that can actively execute this stored knowledge.  And open source software is different again, because it allows everybody to examine both how the knowledge is derived (the process) and how it is expressed (the product).

This book’s authors deal with many interesting aspects of the open source development process and the corresponding products.  On the process front they examine the software development tools and human resource management methods that allow open source products to flourish against significant odds.  As the records of the development process are typically also open, other chapters use those as a study field looking for evidence of quality, examining the dynamics of the project community, or using them as a test bed for performing process optimization experiments.

Further chapters focus on the open source products.  Economies of scale often force proprietary software development companies to focus on the fat head of their potential users’ power law distribution.  Yet the Internet delivery and collaboration channels coupled with a development model based on volunteers allows open source products to occupy spectacular niches in the users’ distribution famously long tail.  There are chapters examining life in that long tail and the ecosystem in which open source projects prosper.

Finally, there are chapters navigating the turbulent waters where open source, proprietary software, and the real world meet.  How can we best adopt open source software in corporate environments?  How can we handle migration from proprietary solutions?  How are business models based on open source software related with the software’s quality?  Answering these questions isn’t easy, but venturing on these directions is certainly fascinating.

SHARE’s founders chose their organization’s name hoping they could subsequently come up with a clever set of words to match the initials.  None of the suggestions put forward were good enough, and therefore, true to today’s open source spirit, they decided that individual members were free to interpret them in their own way.  The 1956 SHARE Reference Manual, perhaps the first codification of open source principles and practices, notes that this action was symbolic of one of SHARE’s core values: unity in essentials and freedom in the accidentals.

Diomidis Spinellis

Athens University of Economics and Business
Department of Management Science and Technology
http://www.spinellis.gr