Embracing Insanity: Open Source Software Development (Other Sams)

00 1989-6 FM

8/21/00

1:12 PM

Page i

Embracing Insanity: Open Source Software Development Russell C. Pavlicek

201 West 103rd St., Indianapolis, Indiana, 46290 USA

00 1989-6 FM

8/21/00

1:12 PM

Page ii

Embracing Insanity: Open Source Software Development Copyright © 2000 by Sams Publishing All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of the information contained herein.

ASSOCIATE PUBLISHER

Michael Stephens EXECUTIVE EDITOR

Rosemarie Graham ACQUISITIONS EDITOR

William E. Brown DEVELOPMENT EDITOR

Heather Goodell TECHNICAL EDITOR

Robin “roblimo” Miller

International Standard Book Number: 0-672-31989-6

MANAGING EDITOR

Library of Congress Catalog Card Number: 00-103677

Matt Purcell

Printed in the United States of America

PROJECT EDITOR

First Printing: September 2000

George E. Nedeff

02 01 00

COPY EDITOR

4 3 2 1

Michael Dietsch

Trademarks All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Sams Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

INDEXER

Greg Pearson PROOFREADER

Candice Hightower Andrew Simmons INTERIOR DESIGN

Gary Adair COVER DESIGN

Alan Clements

Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The authors and the publisher shall have neither liability or responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.

LAYOUT TECHNICIAN

Ayanna Lacey

00 1989-6 FM

8/21/00

1:12 PM

Page iii

CONTENTS AT A GLANCE INTRODUCTION

1

PA R T I : Origins of Open Source: Has the World Gone Mad? 3 C H A P T E R 1 : What’s Going On Here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 C H A P T E R 2 : How Did All This Start? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 C H A P T E R 3 : Why Should I Care? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

PA R T I I : Exploring the Roots of the Insanity

45

C H A P T E R 4 : The Key to Many Things: Understanding Geek Culture . . . . . . . . . .47 C H A P T E R 5 : Community, Not Communism . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 C H A P T E R 6 : Primary Community Value: Truth . . . . . . . . . . . . . . . . . . . . . . . . . .75 C H A P T E R 7 : Fear, Uncertainty, and Doubt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

PA R T I I I : Embracing the Insanity: Joining the Fray 99 C H A P T E R 8 : Cooperate with the Competition? Are You Nuts? . . . . . . . . . . . . . .101 C H A P T E R 9 : The Players: Who Does What and Why . . . . . . . . . . . . . . . . . . . . .113 C H A P T E R 1 0 : The Potholes: What to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 C H A P T E R 1 1 : The Primer: What To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 C H A P T E R 1 2 : Licenses, Licenses, Licenses! . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

INDEX

171

00 1989-6 FM

8/21/00

1:12 PM

Page iv

TABLE OF CONTENTS I N T R O D U C T I O N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 PA RT I :

Origins of Open Source: Has the World Gone Mad?

3

C H A P T E R 1 : What’s Going On Here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

What Does “Internet Speed” Really Mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 You Can’t Be Serious? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 The Open Source Way . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Communication and Its Impact on Software . . . . . . . . . . . . . . . . . . . . . . . . . . .9 The Advent of Bidirectional Communication . . . . . . . . . . . . . . . . . . . . . . .10 Pulling Harmony from the Jaws of Chaos . . . . . . . . . . . . . . . . . . . . . . . . . .11 On the Cover of the Rolling Stone? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 The Discovery of Joy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Declaration of Independence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Learning From The Best, Continually . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Let the Best Code Win . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 The Course of the River Has Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 C H A P T E R 2 : How Did All This Start? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Once upon a Time in New Jersey… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 The Apostle of Freedom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 GNU and You . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 The Helsinki Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Open Source Versus Free Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 But Wait…There’s More! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 An Open Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 An Indian on the Warpath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 The Birth and Resurrection of X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 A Daemon Awakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 The Postman Knocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 The Distributions are Born . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 What Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 C H A P T E R 3 : Why Should I Care? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

From Cost Center to Profit Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 The Essential Disruptive Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Disruption: A New Way of Thinking About Desktop PCs . . . . . . . . . . . . . .28 Disruption: A New Way of Developing Software . . . . . . . . . . . . . . . . . . . . .30 Disruption: A New Way of Owning Software . . . . . . . . . . . . . . . . . . . . . . .34 Disruption: A New Way of Influencing Software . . . . . . . . . . . . . . . . . . . . .38 Disruption: A New Means of Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

00 1989-6 FM

8/21/00

1:12 PM

Page v

Disruption: A New Way of Educating Technical People . . . . . . . . . . . . . . .42 Disruption: Beowulf and a New Way of Solving Problems . . . . . . . . . . . . . .43 Disruption: Freedom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 PA RT I I :

Exploring the Roots of the Insanity

45

C H A P T E R 4 : The Key to Many Things: Understanding Geek Culture . . . . . . . . . .47

What Is a “Geek”? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Geeks Dripping with Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 From Kicked Dog to Top Dog: The Rise of Self-Esteem . . . . . . . . . . . . . . . . . .49 A New Plant with Old Roots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 Ingredients for Making Geek Soup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 The Whole Truth and Nothing But the Truth . . . . . . . . . . . . . . . . . . . . . . .53 It’s Not Who You Know, It’s What You Do . . . . . . . . . . . . . . . . . . . . . . . . . .54 The Fame Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Freedom to Choose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Open Source Requires Open Mouths . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Let Freedom Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 These Uncivilized Brutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Why Geek Culture Is the Key to Many Things . . . . . . . . . . . . . . . . . . . . . . . . .60 The Geeks Are Knocking at the Door . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 C H A P T E R 5 : Community, Not Communism . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

Size Really Does Matter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 It Is Good to Work, But It Is Better to Grow . . . . . . . . . . . . . . . . . . . . . . . . . .65 Open Development Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Open Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Let the Best Code Win . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Fast Turnaround . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Open Praise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Simple Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Fun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Soup Is On! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 A Community That Explodes the Myth of the Anti-Social Geek . . . . . . . . . . . .70 The Rise of Geek Speaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 The Meaning of Beer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 The Necessity of Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 C H A P T E R 6 : Primary Community Value: Truth . . . . . . . . . . . . . . . . . . . . . . . . . .75

Better Raw Than Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Technical Meritocracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 Learning to Love the Warts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Self-Correcting Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

00 1989-6 FM

vi

8/21/00

1:12 PM

Page vi

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Self-Correcting Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Self-Correcting News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Self-Correcting Opinions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Self-Correcting Rumors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Self-Correcting of Trolls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Why Some People Will Hate This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 GNU/Linux and Truth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 The Truth Shall Set You Free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 C H A P T E R 7 : Fear, Uncertainty, and Doubt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Classic FUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Open Source = Hacker Toys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Open Source = Written by Amateurs and Kids . . . . . . . . . . . . . . . . . . . . . .88 Open Source = Shareware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Open Source = Old Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Open Source = Unsupported Software . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Open Source = Insecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 New FUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Open Source = Uncertain Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Open Source = Increased Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 Open Source = Difficult to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 Open Source = Difficult to Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 Open Source = Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Open Source Lacks Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 Open Source and Brook’s Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 FUD Now and Forever . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97 PA RT I I I :

Embracing the Insanity: Joining the Fray

99

C H A P T E R 8 : Cooperate with the Competition? Are You Nuts? . . . . . . . . . . . . . .101

Coopetition and Real Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . . . . .101 Real Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Misunderstanding Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . . . . .104 Sharing Code Increases Real Value to the Corporation . . . . . . . . . . . . . . .105 Defining Coopetition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 The Open-Source Advantage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Coopetition as an Potential Industry Standard . . . . . . . . . . . . . . . . . . . . . . . .109 C H A P T E R 9 : The Players: Who Does What and Why . . . . . . . . . . . . . . . . . . . . .113

The Leaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Alan Cox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Jon “maddog” Hall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Bruce Perens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Eric S. Raymond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

00 1989-6 FM

8/21/00

1:12 PM

Page vii

CONTENTS

Richard M. Stallman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Linus Torvalds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 The Distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Caldera OpenLinux (www.calderasystems.com) . . . . . . . . . . . . . . . . . . . .115 Corel Linux (linux.corel.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 Debian GNU/Linux (debian.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 FreeBSD (freebsd.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 Linux PPC (linuxppc.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 Linux-Mandrake (linux-mandrake.com) . . . . . . . . . . . . . . . . . . . . . . . . . .116 NetBSD (www.netbsd.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 OpenBSD (openbsd.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Red Hat Linux (www.redhat.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Slackware Linux (www.slackware.org) . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Storm Linux (stormlinux.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 SuSE Linux (suse.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 TurboLinux (turbolinux.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Yellow Dog Linux (yellowdoglinux.org) . . . . . . . . . . . . . . . . . . . . . . . . . .118 The Reference Sites and Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Freshmeat (freshmeat.net) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Kernelnotes (kernelnotes.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Linux.com (linux.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Linux.org (linux.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 LinuxApps (linuxapps.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 Linuxresources (linuxresources.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 The Watering Holes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 Slashdot (slashdot.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 Linux Today (linuxtoday.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 OS Opinion (osopinion.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 The Online Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 Apache Today (apachetoday.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 BSD Today (bsdtoday.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 Linux Orbit (linuxorbit.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 LinuxPlanet (linuxplanet.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 LinuxPR (linuxpr.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 The Linux Show (thelinuxshow.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 Linux Today (linuxtoday.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 Linux Weekly News (lwn.net) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 LinuxWorld (linuxworld.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 RadioWallStreet’s Linux League (radiowallstreet.com) . . . . . . . . . . . . . . . .121 Slashdot (slashdot.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 Technocrat (technocrat.net) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 WideOpen News (wideopen.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121

vii

00 1989-6 FM

viii

8/21/00

1:12 PM

Page viii

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Magazines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 Linux Journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 Linux Magazine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 Maximum Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 Open Magazine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 The Development Facilitators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 Collab.net (collab.net) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 Cosource (cosource.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 SourceForge (sourceforge.net) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 The Online Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 Cheapbytes (cheapbytes.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 Copyleft (copyleft.net) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 Linux Central (linuxcentral.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 LinuxMall (linuxmall.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 Linux Systems Labs (lsl.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 The Systems Vendors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 Atipa Linux Solutions (atipa.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 Penguin Computing (penguincomputing.com) . . . . . . . . . . . . . . . . . . . . .124 VA Linux Systems (valinux.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 The Software Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 HelixCode (helixcode.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 Lutris Technologies (lutris.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 OpenSales (opensales.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Sendmail (sendmail.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 The Other Businesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Open Source Development Network (formerly Andover.net) . . . . . . . . . .125 International Data Group (IDG; Media Company) . . . . . . . . . . . . . . . . . .125 Internet.com (Online Media Company) . . . . . . . . . . . . . . . . . . . . . . . . . .125 Linuxcare (Support and Services Company) . . . . . . . . . . . . . . . . . . . . . . .126 O’Reilly (books and conferences) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 The Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 GNOME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 KDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 MySQL, PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Perl, PHP, Python, Tcl/Tk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Wine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127

00 1989-6 FM

8/21/00

1:12 PM

Page ix

CONTENTS

The Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 Apache Foundation (apache.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 Free Software Foundation (www.fsf.org) . . . . . . . . . . . . . . . . . . . . . . . . . .128 Linux Documentation Project (linuxdoc.org) . . . . . . . . . . . . . . . . . . . . . .128 Linux International (li.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 Linux Professional Institute (lpi.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 Linux Standard Base (www.linuxbase.org) . . . . . . . . . . . . . . . . . . . . . . . .128 Linux Speaker’s Bureau (linuxresources.com) . . . . . . . . . . . . . . . . . . . . . .129 Open Source Initiative (opensource.org) . . . . . . . . . . . . . . . . . . . . . . . . . .129 Software in the Public Interest (www.spi-inc.org) . . . . . . . . . . . . . . . . . . .129 The Lighter Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129 After Y2K (geekculture.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129 Segfault (segfault.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129 User Friendly (userfriendly.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129 And More to Come… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130 C H A P T E R 1 0 : The Potholes: What to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

Forget Business as Usual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Forget About Demanding Your Own Way . . . . . . . . . . . . . . . . . . . . . . . . .131 Forget Fluffy, Empty Management Speeches . . . . . . . . . . . . . . . . . . . . . . .132 Forget About Fudging Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133 Forget About Marketing that Alienates the Community . . . . . . . . . . . . . .134 Forget About Pushing Hype Rather than Real Value . . . . . . . . . . . . . . . . .134 Forget About Taking More than You Give . . . . . . . . . . . . . . . . . . . . . . . . .137 More Traps to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137 Do Not Open Your Mouth Until You Have Done Your Research . . . . . . . .137 Do Not Fight Wars Not Worth Fighting . . . . . . . . . . . . . . . . . . . . . . . . . .138 Do Not Upset Developers Who Do Not Work for You . . . . . . . . . . . . . . . .139 Do Not Tread on Other People’s Intellectual Property . . . . . . . . . . . . . . . .139 Do Not Discourage Hard Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 Do Not Mistake Revenue for Market Share . . . . . . . . . . . . . . . . . . . . . . . .140 Do Not Accept All Market Analyst Reports at Face Value . . . . . . . . . . . . .140 Do Not Mistake Freedom for Lack of Cost . . . . . . . . . . . . . . . . . . . . . . . .141 From Negative to Positive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 C H A P T E R 1 1 : The Primer: What To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

Managers’ Issues Regarding Participation in Open Source . . . . . . . . . . . . . . .143 Attracting and Retaining Talent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 What Gets Opened? And What Stays Closed? . . . . . . . . . . . . . . . . . . . . . .151 What Else Do I Need to Consider? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 Contributor’s Issues Regarding Open Source . . . . . . . . . . . . . . . . . . . . . . . . .155 Learn to Find Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 Learn to Find Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156

ix

00 1989-6 FM

8/21/00

1:12 PM

Page x

Learn to Find Projects in Need of Help . . . . . . . . . . . . . . . . . . . . . . . . . . .156 Learn to Do Advocacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157 Learn to Write Articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157 Learn to Write Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157 Get Involved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157 C H A P T E R 1 2 : Licenses, Licenses, Licenses! . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

Licensing Issues to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159 Open Source Is Not Shareware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159 Open Source Is Not Freeware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160 Open Source Is Not Public Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160 Patents and Pain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161 License Types: The Good, the Bad, and the Viral . . . . . . . . . . . . . . . . . . . . . .161 The Good: Four Essential Freedoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161 The Bad: Non-Free or Partially Free Licensing . . . . . . . . . . . . . . . . . . . . .162 The Viral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162 Role of the Open Source Initiative and the Free Software Foundation . . . .163 Lone Rangers Are a Last Resort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163 Existing Open Source Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163 GNU General Public License, Version 2 (a.k.a. Copyleft or GPL) . . . . . . .164 GNU Library General Public License (LGPL) . . . . . . . . . . . . . . . . . . . . . .165 4.4BSD Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166 Q Public License Version 1 (QPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Artistic License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Aladdin Free Public License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 Python License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 IBM Public License Version 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 Mozilla Public License Version 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169 X Window System License X11R6.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Apache License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Not-Quite-Open Source Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 I N D E X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

00 1989-6 FM

8/21/00

1:12 PM

Page xi

FOREWORD When I first met Russell Pavlicek in 1997, I was writing an online column called “Cheap Computing.” Russ had just built a Beowulf supercomputer cluster in his home office, and I was there to look it over and write a column about his creation. It wasn’t much of a supercomputer, certainly not in the same league as the “big iron” at MIT or Los Alamos, but it was one of the first Beowulfs—and one of the first supercomputers—built by an individual at home. I was fascinated by this unassuming man and his humble-looking, wired-together equipment that produced more computing power per dollar than I had ever seen before. Beowulf software, which allows groups of low-cost “commodity” PCs to perform the same big-time number crunching that had formerly been the exclusive province of room-filling mainframes built by companies like IBM and Cray, was new back then, an Open Source project still in the early stages of development. But it was far enough along for Russ and a few others to show how a combination of GNU/Linux and a little shared cleverness could use the Open Source concept to put huge amounts of computing power into the hands of people who didn’t have much money. Russ’s little home project, assembled from surplus desktop computers and network components he’d picked up for next to nothing, had as much processing power as IBM had been selling for $1 million or more only a few years before. Now Beowulf supercomputers, running Open Source and free software, are being built or bought by cost-conscious government agencies, universities, and businesses all over the world. But it took Russ and people like him to do the first experimenting and tinkering with the concept, to work out the early bugs, to test different kinds of network adapters, and do all the other little tweaking and development work that must be done to turn a gleam-in-the-eye concept into a workaday tool. Since Russ built his little home Beowulf, the number of people and companies working on Open Source development has grown by several orders of magnitude, but the number of people able to effectively articulate Open Source and free software concepts has hardly increased at all. As one of the few who can stand in front of an audience or sit in front of a keyboard and explain why Open Source and free software methods produce better programs faster than proprietary, corporate-controlled software development teams, Russ is now in such demand as a speaker and writer that he hardly has any time left to tinker with software. This is sad, but Russ seems to be accepting his new-found fame with more grace than most. He still lives in the same old house, and his family still puts up with computer parts and partially disassembled computers scattered here and there. In a way, this is the essence of the Open Source and free software movements; that software development is an end in itself, an activity as fascinating as building ham radios or race cars or writing poetry, and that if you happen to make a little money or gain a little notoriety along the way, that’s fine, but if it doesn’t happen, that’s fine too. How this relates to corporate bottom lines can be expressed in the old phrase, “Take care of the top line and the bottom line will take care of itself.” But beyond that, I will say nothing, because over the next several hundred pages Russ does a truly excellent job of explaining why the Open Source and free software movements are good not only for software developers, but also for the companies that employ them. —Robin Miller, Elkridge Maryland, July 2000

00 1989-6 FM

8/21/00

1:12 PM

Page xii

ABOUT THE AUTHOR Russell C. Pavlicek has been working with Linux since 1995. He became active in the Open Source community in 1997 and began taking on the role of a Linux Advocate in that same year. He has written a number of articles for Linux Web sites and magazines and is a frequent speaker at Linux and Open Source technology conferences. Russell has spent the last two decades enjoying the progress of the computer industry. He has been a software designer, troubleshooter, and consultant. In 1987, he joined Digital Equipment Corporation as a software consultant in the Washington D.C. area. After Digital was acquired by Compaq Computer Corporation, he was given the position of Compaq’s Linux Evangelist for Professional Services and was named Compaq’s representative to Linux International. Russell and his family live outside of Washington D.C. in Maryland. Their house is shared with a good number of pets and, occasionally, foreign exchange students.

ABOUT THE TECHNICAL EDITOR Robin Miller is editor-in-chief of OSDN (Open Source Development Network), the online publishing company that owns Slashdot.org and freshmeat.net. He has been writing about Linux and Open Source since 1997, and has been writing professionally, not necessarily about computers, since 1985.

00 1989-6 FM

8/21/00

1:12 PM

Page xiii

DEDICATION To Maryann, Stephanie, and Christopher, who have had to put up with so much for so long to see this through.

ACKNOWLEDGMENTS The author wants to acknowledge the folks at Digital Equipment Corporation and Compaq Computer Corporation who let him follow a Linux path when few people in the industry even knew what Linux was. Also, the author would like to express his thanks to Jon “maddog” Hall (Linux International), Robin Miller (Andover/Slashdot), Scott James Remnant (Segfault), and Dave Whitinger (Linux Today) for encouragement over the years.

00 1989-6 FM

8/21/00

1:12 PM

Page xiv

TELL US WHAT YOU THINK! As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we’re doing right, what we could do better, what areas you’d like to see us publish in, and any other words of wisdom you’re willing to pass our way. As an Associate Publisher for Sams, I welcome your comments. You can fax, email, or write me directly to let me know what you did or didn’t like about this book—as well as what we can do to make our books stronger. Please note that I cannot help you with technical problems related to the topic of this book, and that due to the high volume of mail I receive, I might not be able to reply to every message. When you write, please be sure to include this book’s title and author as well as your name and phone or fax number. I will carefully review your comments and share them with the author and editors who worked on the book. Fax:

317-581-4770

Email:

[email protected]

Mail:

Michael Stephens Sams Publishing 201 West 103rd Street Indianapolis, IN 46290 USA

01 1989-6 Intro

8/21/00

1:11 PM

Page 1

WHY SHOULD I READ THIS BOOK? The Open Source community is a passionate group of people. They can be very technical, very gifted, and sometimes even very argumentative, but they are very passionate. For years, people outside of the community have tried to put down people in the community by saying, “Hey, this isn’t a religion. It’s just software.” That statement is only half true. Open Source is not a religion, but it is a whole lot more than “just software.” Open Source is a revolutionary perspective on how software should be created. It defies the stereotypes of what it is to be a technical person in the twenty-first century. It challenges the very foundation of the current software industry. In this book, I will attempt to describe the methods and the madness of the Open Source world. If you are at all curious about the way in which the technical world is changing, you will hopefully find this book valuable.

Who Is This Book’s Intended Audience? This book is intended to meet the needs of people who want to know more about the Open Source world. It should be of value to the programmer as well as to the IT manager. It should have particular value to people interested in either participating in the Open Source movement or for companies that seek business opportunities there. But, as you will learn, the Open Source movement is about people. As such, I believe any person interested in the dynamics of communities will find some value in this work.

What Will You Learn from This Book? This book gives you the knowledge and perspective needed to comprehend the basic workings of the Open Source movement. You will understand why the Open Source community operates in a vastly different way than most people expect. You will be able to see why the movement is capable of creating very high-quality software in a very short period of time. And you will be able to understand why the Open Source movement is changing the way in which software is created.

01 1989-6 Intro

2

8/21/00

1:11 PM

Page 2

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

How This Book Is Organized This book is divided into the following parts: Part I: Origins of Open Source: Has the World Gone Mad? This section is an overview of the history of Open Source, its importance in the growing Internet world, and reasons it cannot be ignored. Part II: Exploring the Roots of the Insanity Understanding how and why the Open Source community does what it does. This also includes a section on understanding the messages of fear, uncertainty, and doubt that are aimed at the community. Part III: Embracing the Insanity: Joining the Fray The “do’s and don’ts” of participating in the Open Source world, as a contributor, vendor, or beneficiary.

02 1989-6 Part I

8/21/00

1:12 PM

Page 3

PA R T I

ORIGINS OF OPEN SOURCE: HAS THE WORLD GONE MAD?

1

What’s Going On Here?

2

How Did All This Start?

3

Why Should I Care?

02 1989-6 Part I

8/21/00

1:12 PM

Page 4

03 1989-6 CH01

8/21/00

1:11 PM

Page 5

CHAPTER 1

WHAT’S GOING ON HERE?

The Linux philosophy is to laugh in the face of danger. Oops. Wrong one. “Do it yourself.” That’s it. — Linus Torvalds

I

n the 1970s, a popular question of the day was, “What’s your sign?” At the dawn of the new millennium, the question has become, “What’s your URL?” What a difference a generation makes.

The age of the Internet is upon us. It seems that it is no longer possible to run a business—any business—without a Web site. Everything from bookstores to dog groomers can be found on the Web. Company names now include “.com” in them the same way they used to contain “Inc.” or “Ltd.” And it is not just businesses that need to have a space on the Web; people want to have their own presence, too. Everyone, from PhD mathematicians to 11-year-olds down the block, has his or her own Web page. And instant messaging accounts. And an email address. Or two. Or four… Seemingly innocuous words such as commerce and business are routinely assaulted with random leading es and is. You cannot simply go shopping anymore. You must use your iMac so you can “eShop” at the “eRetailer.” Life has become “eCrazy.” But, for the person interested in the high-tech industry, nothing seems so eCrazy as the rise of the Open Source movement. A strange and seemingly chaotic band of programmers strewn across the world, these people seem utterly insane to many. After all, who in their right mind spends days and weeks and months crafting powerful computer software only to give it all away when the job is done? Smart people. Very smart people. But what makes them smart? They understand the power of the Internet. And they fully grasp what it means to work at “Internet speed.”

03 1989-6 CH01

6

8/21/00

1:11 PM

Page 6

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

What Does “Internet Speed” Really Mean? There is a lot of buzz today in the business community about working at Internet speed. “We need to change quickly,” they say. “We need to adapt rapidly because the Internet moves so fast.” In many companies, the term Internet speed is used as an excuse to get people to work harder. But the essence of Internet speed has to do with working smarter, not harder. Some companies comprehend the need to work smarter. So they attempt to be more flexible and more innovative in the way they go about their work. They try to streamline processes, reduce overhead, brainstorm more. They look for any advantage they can find and lunge for it. But very few companies have ever really recognized what it is to work at Internet speed. And that is because they have never actually understood what the term Internet speed really means, or where it actually came from. Without that understanding, they are doomed to be at the mercy of the companies that finally understand the key to working at Internet speed. So, where does the term come from? Some people think that it comes from the fact that Web sites change rapidly. In a blink of an eye, a company can change its Web presence from a dull, lackluster set of pages to a dazzling e-commerce Web site. Is this Internet speed? Others think that the term comes from amazing way that someone in his bathrobe can sit down at the computer and within minutes order an entire wardrobe of clothes that can be delivered overnight. Fast food can be ordered over the Web and appear at your door in 30 minutes. Music can be purchased online and downloaded in moments. But is this Internet speed? In reality, all these things pale in comparison to the real meaning of Internet speed. The term refers to something much faster, more revolutionary, and yet more basic than all these things. The term Internet speed describes the process of developing Open Source software.

You Can’t Be Serious? Let me attempt to explain Internet speed using an example that is not specifically technical. Suppose two companies are competing in business. The first business lays out strategies as best it can, trying to come up with good business practices and working out the kinks, but sometimes it can take weeks or months to escalate problems to the point where solutions appear. But every year or two, key management people change. They want to leave their impression on the business and begin changing things that work as well as those things which do not. So most of what has happened in the business in the past is forgotten and a new team with a new plan takes over. They try not to make the same mistakes again, but some errors always seem to creep in, since they are attacking the problem all over again. And, since there have been widespread changes in every area, workers have to be retrained to work differently, causing confusion and periods of limited productivity. Now suppose a second company in the same market does things a bit differently. Like the first company, the second company also creates the best business strategies that it can. But as flaws

03 1989-6 CH01

8/21/00

1:11 PM

Page 7

Chapter 1 • WHAT’S GOING ON HERE?

are found in business processes, this company corrects them in minutes or hours rather than weeks or months. To keep from making the same business mistakes over and over again, the second company emphasizes refining existing business practices or adding additional practices rather than repeatedly reinventing the same processes every few years. The goal is to make a practice that addresses the need very, very well. A particular process is only replaced when it is clear that it is not worth keeping. The result is that fewer and fewer business mistakes are made over time. Now, if you had to guess which business would prevail in the long term, which would you choose? The first is slow to react to changes, repeats errors time after time, and loses time by periodically replacing essential processes that already work well. The second moves quickly to fix mistakes and keeps from making them again. The second business is better positioned than the first. It does not waste time reinventing processes that work well. It refines weak processes until they do work well. And it does all this quickly, before its customers and its employees become acclimated to a corporate culture of failure. And employees need not lose productivity by the constant retraining which is required when a working process is needlessly replaced. The second business has begun to understand what it is to move at Internet speed. It survives and thrives by employing part of the model that Open Source software development uses. Fix what is broken. Make things that work well work even better. Stop reinventing the wheel. React quickly when changes are required.

The Open Source Way In closed-source development, when company A creates a program to do something, it keeps the source code unavailable for others to see. When company B decides to do something similar to what company A has done, company B must start development from scratch. It must define, specify, and create code that will do the same task that Company A has done. Company B will not be able to draw on lessons learned by Company A, nor will Company A benefit from any advances that Company B develops. The new code will have to be laboriously coded, tested, and debugged. And both companies will need to retain technical people to maintain and fix the system as needed. The result is that both companies pay for independent development of the same basic “wheel.” And, unless the companies are in the wheel-building business, neither business will have added to its respective bottom line. Each has spent money on necessary infrastructure, but each would have been better off reducing the cost of reinventing the wheel and spending more time doing real business. In the Open Source world, however, this is not a problem. In the Open Source movement, Internet speed is accomplished in many ways. Since the source code is always available, there is no need to constantly reinvent the wheel the way normal commercial software endeavors need to. Once a good implementation of something exists, everyone can benefit from it by incorporating it as needed in subsequent efforts. And as enhancements are added to the code and published for all to see, the originators of the code can benefit from the changes if they so choose. Debugging time is greatly reduced, since multiple parties are now involved in the task.

7

03 1989-6 CH01

8

8/21/00

1:11 PM

Page 8

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

And no one user has to foot the bill for a full development staff to maintain the code in perpetuity, since many parties will participate in the maintenance task. At this point, you might say, “Hey, I want my competition to go through the pain we went through to set up computer systems! I don’t want to make it easier for them!” The point is well taken: why make life easier for other companies, especially if you are competing with them? But that perspective is myopic. First, it ignores the fact that the originator of the code can benefit greatly from the enhancements and fixes contributed by others. And second, it makes the common mistake of assuming that most companies are in the business of producing software and therefore need to keep that software secret. Companies tend to protect the things that are critical for their success. For example, a soft drink manufacturer clearly wants to keep the formulas of its products a secret. That is an essential differentiator for it in the marketplace. But does a soft drink manufacturer need to hide the brand of pencil it supplies to its finance people? Does it need to obscure the name of the company it goes to for office supplies? The answer is No. And, unless a company is in the software business, there is little reason to keep most of its software secret. Yes, corporatedeveloped software can provide useful elements to an electronic infrastructure. But is this software so critical to the success of the company that it would reduce the bottom line of the company if it were to leak out to the competition? Most of the time, this is clearly not the case. So why keep the software secret and incur the expense of continually maintaining it alone, when you might be able to get others to maintain the software with you, thus reducing your costs? Another benefit of Open Source development is the increased modularity of the solutions. Open Source programmers often reuse routines that they consider good and solid. As a result, programmers are very aware that the code they write for one project might be used in other projects in the future. This knowledge that good code is likely to be reused in products and projects for years to come has a definite effect on the approach of most Open Source projects. This wide view of the world causes many programmers to write much more modular and reusable code than they might otherwise produce. This way, if they do a good job of implementing the task at hand, their code will be easily reused by projects yet to come, thus saving other project teams considerable development time and debugging effort. So, the effective reuse of software can reduce development cost and increase overall quality. But simple code reuse alone does not make for Internet speed. Other pieces also contribute to this puzzle. In most Open Source projects, a minimum of two versions of the product are normally available at any time. One is the bleeding-edge development version, which is unsuitable for end users; it contains unproven code and might be unstable. The second version is the stable product (if the project is mature enough to have a stable version). This is what end users will normally want to employ. The presence of the development version is critical for most Open Source efforts. This allows developers and motivated users to assess how the effort is progressing. It allows for immediate feedback and testing. When problems are identified, they can be reported early in the process. In the case of technical users, sometimes actual source code patches are submitted along with

03 1989-6 CH01

8/21/00

1:11 PM

Page 9

Chapter 1 • WHAT’S GOING ON HERE?

the problem statement. So not only is the problem identified, but often the solution is submitted as well. This harnesses the talents and the self-interest of the tester to aid the developer in crafting a solid solution. It also allows problems to be attacked quickly and thoroughly. As a result, the number of bugs in the resulting stable release product tends to be much smaller than would otherwise be the case. Of course, all this turns on one key point: You have to learn to listen well to accomplish goals such as these. Goals such as reacting fast and fixing what is broken require that you become intimately aware of what your users are saying. Unlike the lip-service buzzwords of many corporate efforts, it is absolutely essential that Open Source endeavors listen to the voice of the customer and adapt accordingly. But true Internet speed is not achieved by simply realizing a need to listen well. There is something much more complex at work here. In the Open Source world, the very nature of communication has changed.

Communication and Its Impact on Software In normal software development, as in many traditional Western societies, communication tends to flow in a single direction: from the provider to the consumer. The provider publishes code and information, while the consumer accepts what is produced. Information from the consumer back to the provider is usually sorely limited and occasionally nonexistent. Since the advent of the printing press, information has been flowing from the provider to the consumer. Whether it is in books, newspapers, radio, or television, media that communicates to many people tends to be the province of corporations. This is understandable, considering the cost inherent in using traditional wide-ranging media. Very few individuals can afford the expense involved in broadcasting their opinions to the world. Yes, most corporations have telephone support lines and mail addresses where complaints can be registered. But, although the consumer can register a complaint with the information provider, she cannot easily inform other consumers regarding the errant claims of the provider. She must rely on the good will of the provider to acknowledge the error and change its ways or hope that some other provider will hold the first accountable. Either way, the consumer has very little power to directly affect the provider or correct its message. The result is a society where information providers and information consumers are separated by a fixed chasm. Frequently, information consumers find themselves at the mercy of the information providers. Unless checked by other large forces, such as government regulations or news reporters, information providers have the possibility of being able to make questionable statements with little possibility of being publicly corrected by information consumers. Essentially, it has been the job of information providers to hold other information providers in check. For example, an automobile manufacturer makes the claim of making the safest cars on the road. But a government-run testing program issues a report showing that among automobile manufacturers, this particular manufacturer ranks very low in safety features. A television

9

03 1989-6 CH01

10

8/21/00

1:11 PM

Page 10

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

news network realizes the sharp discrepancy between the manufacturer’s claims and the test results and runs a story comparing the two viewpoints. In this case, the automaker, the government program, and the news media are all information providers. The efforts of the last two providers keep the effort of the first in check. An irate consumer, injured in a car accident because of the manufacturer’s poor safety mechanisms, could yell, scream, and write letters for months on end, but the effect would not be as substantial as when these other information providers use their platforms to correct the claims of the automobile company. Unfortunately, the ability or will of information providers to watch the statements of other information providers is far from perfect. In the computer industry, for example, many press releases come out weekly stating things that customers no longer believe. Everyone claims to be the biggest, the best, and the most cost effective. Consumers often rely on analysts to tell them who to listen to. But who keeps the analysts in line? In the greater realm of communications, the Western consumer has become suspicious of most purveyors of information. Even the news media, once widely trusted to deliver the facts to the people is under heavy scrutiny. It was once common not to know the political bias of most reporters because it never seemed to appear in their work. Today, it is often difficult to tell where the facts end and the bias begins. Someone might argue that the bias was always present in the past and people are simply more aware of it now. Whether it is a matter of truth or perception is basically immaterial. The fact is that many people have become deeply suspicious of our information providers. Whether the provider is a corporation, news outlet, or politician, if it has the power to tell things to the people, it is suspect.

The Advent of Bidirectional Communication In the midst of the growing cynicism regarding information sources, the World Wide Web concept arose. As we will explore further in the next chapter, the Internet had been around for years. It had been a valuable tool for educators and researchers to share data with one another, but it was not very simple to navigate. The Web concept changed all that. A product of the thought of Tim Berners-Lee, the World Wide Web introduced a graphical means for navigating the Internet. Gone were the many cryptic interfaces to locate and extract information. The world could now be seen through the eye of a new beast called a Web browser. But, as revolutionary as that change was, it was the stepping stone to an even greater change: The wall that separated information providers from information consumers came crashing down. Suddenly, any information consumer could become an information provider. At first, the information providers were mostly academic. But, before long, avenues sprung up everywhere so that anyone—regardless of position, education, or wealth—could add content to the Web. Anyone with a voice suddenly could find a way to be heard. And not just heard by a few people. Everyone could present a message that people across the world could read.

03 1989-6 CH01

8/21/00

1:11 PM

Page 11

Chapter 1 • WHAT’S GOING ON HERE?

Unheralded by trumpets or corporate announcements, the nature of communication in the world changed. Like a tenant whose rent was long overdue, the age of unidirectional communication slipped away in the night. The era of bidirectional communication burst on the scene.

Pulling Harmony from the Jaws of Chaos Bidirectional communication is essential in order to travel at Internet speed. The Open Source development model is based on nimble and free communication between members in the development group and those outside the development group. To the uninitiated, the communication may appear chaotic and even counterproductive. But, to those who have learned the importance of this methodology, it is the key to delivering a high-quality result in amazingly short periods of time. Eric S. Raymond, in his landmark paper The Cathedral and the Bazaar, (http://tuxedo.org/) contrasts the standard method for creating software (“The Cathedral”) with the Open Source model (“The Bazaar”). In the Cathedral model, a small group of cloistered developers gathers far away from the watching eyes of the world, develops the software as it sees fit, and delivers the finished product to the anxiously waiting masses. In the Bazaar model, on the other hand, there is a seemingly chaotic set of interactions between developers and users that somehow results in high quality software. The Cathedral method is familiar and comfortable, but the Bazaar model produces higher quality in a shorter period of time. The Bazaar model absolutely requires bidirectional communication between developers and users. Working with the theory that “the only bug that a user fears is the one that never gets fixed,” the Bazaar model allows motivated users to examine and test the software while it is in development. Feedback is swift and direct. No separate department gathers user feedback, boils it down to a few key points, and delivers it to the developers sometime down the road. Rather, users can communicate with the developers directly and can express their feelings in detail. Bugs can be identified and developers can hear for themselves why certain issues might be critical for users. And, most importantly, the developers receive the feedback early and consistently in the development cycle. The problem of engaging in a long development cycle only to find that the software misses the mark with users is avoided altogether. The user community itself becomes a key component to the development of the software. Through this constant feedback, both the developers and the users themselves experience a sense of responsibility for the software. Both groups see their contributions reflected in the resulting software, so they work hard to create an excellent product. The speed of the feedback is also a critical matter. Not only does rapid feedback help developers to flush out bugs early in the process, but it also adds to the sense of contribution from those who are identifying problems and donating fixes. By seeing their feedback and fixes acted on quickly by developers, the sense of ownership of the product expands well beyond the core developers. Participants quickly see that their contributions have not gone unheeded. When they see their thoughts and code appear in short order in the developing product, enthusiasm rises. This is unlike submissions to some bureaucratic suggestion box where you might wait for months or

11

03 1989-6 CH01

12

8/21/00

1:11 PM

Page 12

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

years to see some change take place (and, if it does occur, you are never sure whether it was your idea that generated the change). Rather, in this model submissions are acted on swiftly, and if the change is accepted or rejected, it is clear that the submitter has been heard. The bidirectional communication that is a key revolution of the Internet is likewise embodied in the Open Source model of software development. Gone are the days when the consumer must “put up and shut up.” Now is the time when everyone has a voice and a chance to make things better. This advance alone would have increased enthusiasm for this form of software development. But it was not alone. An equally exciting development accompanied it: fame.

On the Cover of the Rolling Stone? The Open Source model meant that developers and users would interact with each other. No intermediary would obscure the identities of the users and boil down their responses into unrecognizable pabulum. The users now had names. And the developers now had reputations. That meant that people would be known by their contributions. When new code appeared, the name of the author or contributing user would appear in the release notes or in the code comments. People could be judged by their peers. And, for some, there would be a measure of fame awaiting them for their efforts. The power of this simple concept would prove to be immense in the development of the Open Source movement. People would now be known by what they contributed to the work. Both developers and users alike would cease to be anonymous entities. Both now had the opportunity to let their efforts be associated with their names. The immediate effects of this would be felt in two ways. First, when something has a developer’s name on it, there is additional effort to make sure that the quality is high. A developer does not want to be known as someone who writes lousy code. Secondly, the prospect of building a reputation for yourself has proved to be an effective motivator for many developers. The ability to gather a degree of fame in the eyes of your peers causes many developers to become especially prolific in their contributions. People who give much to the community are often held in high esteem. And this, as we will explore in Chapter 4, “The Key to Many Things: Understanding Geek Culture,” touches a hot button with many software developers.

The Discovery of Joy We have covered many of the factors that contribute to Open Source’s Internet speed. But one key aspect that is perhaps least understood is the function of fun and joy. Linus Torvalds has said from the beginning of his work that “Linux should be fun.” But, in this time when people commonly think of Linux in terms of its business opportunities, they sometimes forget that Linux was meant to be enjoyed. Nontechnical people might find the whole concept rather foreign and strange. Who would enjoy doing work for free? But this is something that marks much of the Open Source

03 1989-6 CH01

8/21/00

1:11 PM

Page 13

Chapter 1 • WHAT’S GOING ON HERE?

movement. There is great joy in the pursuit of creating something that improves the world. And there is lots of fun involved with doing things you enjoy doing. Many people involved in Open Source software development have been at least partially motivated by the joy of programming. For many of these people, producing excellent software is like producing excellent art. The fact that they might never see any substantial remuneration from their work is not the issue. They had something inside of them that they wanted to put out into the world. They can look at what they have done and realize that they have made the world a little better than it was, and, in some sense, just a little more beautiful. In the 1970s, there was an active debate in the computer industry. Some people maintained that computer programming was a science. They proposed that programming should therefore be taught like other sciences. There should be theories put forward regarding proper methods and practices. The study of computer science might be dry, it was argued, but the goal of creating solid computer scientists who could improve the world through carefully crafted techniques was well worth the small degree of tedium required. On the opposite side of the debate, other people claimed that programming was an art. They pointed to the elegance of certain algorithms. They examined the efficiency of the certain designs. Certain solutions were said to be “beautiful,” rather than just scientific. They pointed out the young programmers who would voluntarily work long hours each day, not because it increased their paychecks, but because of passion for their art. These programmers were programming for the love of it; the fact that they made money while doing it just made life easier to handle. The poles were laid out. One group insisted that programming was a scientific endeavor, akin to chemistry or physics. The other group was adamant that it was an artistic endeavor fed by a sense of aesthetic and passion that more closely resembles the heart of Vincent van Gogh than the brain of Sir Isaac Newton. But, assertions aside, the question remained: Who was right? The Open Source movement arrived on the scene and produced its own answer to the puzzle. As we will explore more fully in this book, the Open Source movement does not bother to debate the issue. Rather, the Open Source developers show that programming is actually neither solely art nor science. For these people, programming is simply a way of life. It is a human endeavor, and like most human endeavors, it contains elements of both science and art. It is both logical and emotional, both disciplined and passionate. Programming is a task of the heart, soul, and mind. Unlike pure art, the logic of it is unavoidable. But unlike pure science, it requires passion and an appreciation of an aesthetic to do it well. So, for some developers, Open Source has become the canvas for great art as well as great science. It is a means of self-expression. And something that facilitates discovering joy.

Declaration of Independence Another important factor contributing to the sense of fun and joy is the rise of professional independence. For the first time in the history of this industry, there is a widespread opportunity for programmers to create software that they dearly want to create. Programmers get to

13

03 1989-6 CH01

14

8/21/00

1:11 PM

Page 14

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

pick the projects that they want to work on. They are not subjected to tight schedules based on some arbitrary delivery date. And the pressure to “just ship the code” by some deadline, regardless of whether or not the code is working, is essentially nonexistent. In the land of Open Source, the developer becomes captain of his own destiny. He makes the decisions that affect his assignments. He decides what problems merit his attention. And he decides how long it will take to get the job done. In Open Source projects, few people can afford to worry much about deadlines, since the labor is normally done on nights and weekends. This is in stark contrast with the traditional closed-source developer who has another ruling her world. Projects are assigned to the developer. Schedules cast in concrete are often presented to her. And marketing deadlines often overshadow the need to make the program sound. The impact of this change should not be underestimated. For years, programmers have had people telling them what to do, how to do it, and what not to do. They have been treated like unruly children more than seasoned professionals. Management frequently treats them like part of the machine, rather than as part of the brain trust of the corporation. With the arrival of the liberty of Open Source, developers have been given room to grow. They have been given the opportunity to make their own decisions—and, at times, their own mistakes—and grow from the experience. They have been able to explore their own capabilities, concepts, and passions without the restrictions that often encumbered them. They have been given the chance to experience freedom while doing a task that appeals to them. This taste of freedom threatens to revolutionize the programming world. This will be discussed in detail starting in Chapter 3, “Why Should I Care?”

Learning From The Best, Continually Another key part of Open Source participation is the enhanced ability to learn continually. In normal closed-source development, learning is often treated as a necessary evil. It must be facilitated by books and courses because the most potent examples of a job well done—the source code to leading-edge software—is closed to the eyes of the average programmer. While there are ample numbers of books and courses regarding programming in the Open Source world, there is nothing as potentially effective as the presence of accessible source code. The Open Source programmer can benefit from examining the work of the best and brightest minds in the community. Rather than studying overly simplistic examples in a textbook, the programmer can freely study the approach, the implementation, and the comments of top programmers who have created some of the most ingenious software in the world. In the Open Source world, any programmer can become the virtual apprentice of some of the most respected technical minds in the industry. For many Open Source programmers, this represents a vital educational opportunity over mere textbooks or professional courses. And, since the available source code keeps increasing over time, the ability to increase knowledge and understanding is continual.

03 1989-6 CH01

8/21/00

1:11 PM

Page 15

Chapter 1 • WHAT’S GOING ON HERE?

The effects of this are profound. Not only can the programmer see how to do a task in a simple way, he can study the tradeoffs and methods employed in complex, real-world tasks as well. A programmer can glean great insight from the ability to ask questions like, “The Apache Web server has to handle the problem I have in front of me. How does it handle the problem and why?” So, by opening the source code, the movement ensures that the lessons learned by leaders in the community can be learned by others as well.

Let the Best Code Win Finally, the best Open Source projects follow the example of Linus Torvalds, originator of the Linux project, in a key way. In corporate programming efforts, important code is generally designed and implemented by the most senior analysts and programmers. It follows the assumption that the best people will have the best ideas, so the corporation puts its best people on the most critical projects and assumes it will get the best results. Junior-level people need to aspire to rise to a more senior level before they can expect to see the opportunity of making important decisions on important projects. In the Linux project, though, Linus Torvalds decided to use another means of solving the most difficult problems. Rather than assuming that the best people would necessarily create the best solution, he decided that the best solution to a problem would be evident to someone and it was his job as project leader to spot it when it appeared. So he managed his project with a concept that has become known as “Let the best code win.” It does not matter whether the best solution comes from someone with three PhDs and 30 years of experience or from a bright 18-year-old who is just beginning college. The project will benefit the most by using the best solution. The pedigree of the author makes little difference. The issue is the solution. So, with this simple change in philosophy, Linus made it possible for anyone with a good idea to be heard and heeded. Suddenly, the young as well as the old have the opportunity to make significant contributions. The senior, the junior, the expert, the novice—all developers have a chance to find the best solution. All can learn from the excellent insights contributed by others. And, in the style of Linus, all have the ability to receive public acknowledgment for their contribution. Once again, we shall explore some of the impact of this change in the chapters that follow.

The Course of the River Has Changed So, what does all this mean? We see a community that defines the term Internet speed. Community members work quickly and openly. They rely on two-way communication with each other and with the users of their software. They enjoy a good deal of self-rule in their

15

03 1989-6 CH01

16

8/21/00

1:11 PM

Page 16

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

work. They learn from the code submitted by others. They find joy in their tasks. And they let the best solutions rise to the top of the pile. The Open Source community is simultaneously derived from the Internet and driving the Internet. The community both reflects the Internet’s properties and shapes its direction. The social impact of two-way communication, the opportunities for a measure of fame, the recognition of joy in computing, and the ability to contribute something meaningful to others regardless of background are revolutionizing the computing world. And, more importantly, these changes are reaching far beyond the realm of computing to the world itself, thanks to the power of the Internet. Open Source is quickly becoming mainstream. It may not have widely infected the corporate structures yet, but it has begun infecting both the technical world and the nontechnical world through the Internet. And, as it matures, its impact will not be denied. Take, for example, the impact of the birth of the IBM PC. When the PC was first announced, few companies had visions of placing a PC on every desk. In fact, many companies developed rules saying that no PCs were to be purchased. The corporate standard was the dumb computer terminal tied to a large machine in the computer room and that would suffice. But corporations that took that stance soon found out that the PC was changing the rules for computing. PCs introduced things such as spreadsheets and word processing programs that people were using at home. At work, people began demanding that they be given the same capabilities, which allowed people to do certain tasks better and faster than before. And even those corporations with “no PC” policies began to find PCs sitting on desks throughout the organization. They could not fight the direction of the world, so they soon learned to flow with it. The Open Source movement woven around the Internet is creating much the same effect. In the chapters that follow, we will explore how the Open Source movement operates, what its tenets are, and how it is affecting life in the computing world and beyond. In addition, we will discuss how individuals and forward-looking companies can join in this movement and benefit from it.

04 1989-6 CH02

8/21/00

1:13 PM

Page 17

CHAPTER 2

HOW DID ALL THIS START?

S

o where did all this Open Source stuff come from? Is this some type of strange or irrational behavior that occurred in a vacuum? Or did this arise naturally from some earlier movement?

To understand the culture and impact of the Open Source movement, we need to comprehend something of its origins. The beginning of the movement helps us to understand how it operates. And it also helps us to understand where it is headed. One mistake many people make is to associate the Open Source movement with the shareware or freeware movement that appeared during the beginning of the PC era. The association between the two is both understandable and obvious. In both cases, the software is low-cost or no-cost. In both cases, sharing of software is encouraged or, at least, condoned. And, in both cases, the software is usually generated by named individuals, rather than corporations. But, when it comes down to it, Open Source has very little to do with the shareware and freeware phenomenon that became so popular with the rise of the personal computer. The Open Source movement has its roots in a very different movement: the free-software movement. And, despite the name free software, this movement does not focus on the price of the software. Cheap is not the issue here; rather, liberty is the key. The rise of Open Source comes from a few different roots. Prominent among them are Bell Labs, computer hackers from the Massachusetts Institute of Technology, and a student from Finland. The story dates back over 30 years, encompasses thousands of people, and involves almost every country on the globe. Some excellent accounts have been written about the earliest parts of this story. Notably, the book by Peter Salus titled A Quarter Century of UNIX gives an excellent detailed account of much of this history. Rather than attempt to do likewise, I will cover a few key highlights that have shaped the Open Source world.

Once upon a Time in New Jersey… In the 1960s, long before the age of the personal computer, there were many different computer hardware platforms created by numerous computer companies. Each hardware

04 1989-6 CH02

18

8/21/00

1:13 PM

Page 18

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

platform tended to have its own hardware architecture, supported by its own operating system. This meant that almost every time a company purchased the latest in computer technology, the operating system changed. As a result, the application software would have to be rewritten to work on the new computer. Programmers, operators, and users would all need retraining. Substantial time would be lost adapting to the new system. The cost of adopting new technology was quite dear. In this atmosphere, there arose a group of engineers at AT&T’s Bell Labs which decided to solve the problem. The New Jersey–based researchers wanted to create a computer operating system that would be portable between multiple hardware architectures. That way, migrating to a new hardware platform would require no reengineering of application software and no substantial retraining of workers. A basic design decision was made at this time which would have substantial ramifications for the Open Source movement later. To facilitate portability, the researchers decided to build the system out of numerous discrete pieces rather than build one gigantic monolithic operating system. This meant that the resulting system could grow and develop many capabilities without fear of becoming bloated like many other systems. This way, the end user could simply install those capabilities that were needed and omit much of the software that was unnecessary for a particular installation. The result was AT&T’s first Unix operating system. Developed to be used internally, it was constructed to be portable and practical. Initially, there was little effort to make Unix “pretty,” since it was never intended to be a commercial product. But it worked very well and began the journey toward becoming an incredible survivor in the rapidly changing computer industry. Early in Unix’s history, AT&T decided to lease it for very little money. And, in keeping with the practice of the day, it gave the licensees full copies of the Unix source code. This allowed the users to understand exactly what the system was doing, and more importantly, enabled technical users to fix problems when they occurred. But, in later years, things changed. Unix was being licensed in much the same way that other commercial operating systems were. Gone were the days when licensing was inexpensive and source code was readily available. This left a void for those people who longed for an operating system that was useful, inexpensive, and accessible in source code.

The Apostle of Freedom The next progenitor of the Open Source movement, The free-software movement, was shaped by the philosophy of its chief apostle: Richard M. Stallman. The story of Richard’s founding of the Free Software Foundation can be found in the FSF Web site http://www.fsf.org/. In brief, it can be summarized as follows: In the 1970s, Stallman was a hacker in the MIT Artificial Intelligence Lab; not a cracker, as in someone who tries to violate security of a system, but a hacker, someone enjoys doing clever things with a computer. During that time, the AI Lab hackers had developed an operating system called ITS: the Incompatible Timesharing System. The source code to ITS was made

04 1989-6 CH02

8/21/00

1:13 PM

Page 19

Chapter 2 • HOW DID ALL THIS START?

available to anyone who asked for it. But, unfortunately, it was created to depend on the PDP10 hardware architecture it ran on. When the time came to move to a new computer, MIT decided not to try to move ITS to the new machine and instead opted to purchase the commercial operating system which the vendor was selling with the machine. The ramifications of this move had far-reaching effects on Stallman. He was now expected to use a closed-source operating system. He could not read the source code to understand what was going on in the operating system. He could not make any needed changes or repairs to the system. And, if he chose to pay an expensive license fee to receive the source, he would be prevented by the license from sharing his changes with others suffering from the same problems. He had already known what it was to be restricted by nondisclosure agreements. The AI Lab used a printer that had a proprietary driver. When problems arose, they were prevented from fixing the situation because of the nondisclosure agreement. This made Stallman mad. He could not fix the problem. And, if he agreed to sign the nondisclosure agreement to be able to solve the problem, he would be prevented from sharing the solution with others who suffered from the same problem. Stallman had become utterly convinced that creating restricted software was immoral. The only solution was to create free software. The term free was not meant to denote lack of cost, but rather lack of restriction. The standard explanation is “Free as in free speech rather than free beer.” What was needed was software that could be shared without restriction. The software would also need to be modifiable by anyone and the modifications would need to be able to be redistributed without restriction. To pursue this goal, Stallman eventually founded the Free Software Foundation. The FSF is an organization dedicated to the production and promotion of free software. Through the FSF, many critical pieces of software have been developed that have been the foundation for later free-software and Open Source projects.

GNU and You The ideal of software that is freely available for everyone to use is certainly commendable, but is it enforceable? If the software is released into the public domain, the code is available to all. But it doesn’t ensure that people continue to share it. And it certainly doesn’t ensure that people share all enhancements that they make to the program after it is in the public domain. Why is that important? Because if someone has the right to improve the program and keep the improvements private, the results are no longer available to everyone. In this instance, the ideal of software freedom goes unfulfilled. So, a project was born to create truly free software. This project would have to ensure that the software would remain free in perpetuity. The name of that project is GNU. GNU (usually pronounced “guh-noo’”) is the recursive acronym for the phrase, “GNU’s Not Unix.” The GNU project was to create a Unix-like operating system that would embody Stallman’s ideal of truly free software. And with the beginning of the GNU Project, people

19

04 1989-6 CH02

20

8/21/00

1:13 PM

Page 20

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

mark the beginning of the organized free-software movement. The free-software movement would later give rise to the movement that we have come to know as Open Source software. For the GNU project to successfully produce software that granted the user Stallman’s concept of freedom, the problem of ensuring that freedom needed a solution. Because no legal structure could be found to safeguard the freedom of GNU software, Stallman created one. This became known as the GNU Public License or GPL. This, along with the Lesser GNU Public License (or LGPL), would become the legal backbone of the free-software movement. 1. The freedom to use the software and have access to the source code 2. The freedom to modify the software 3. The freedom to redistribute the software 4. The freedom to ensure that all modifications must be redistributable The emphasis was never on price. Indeed, selling copies of a computer program was and is both condoned and encouraged. But the idea is not to sell some secret intellectual property which is found in the bits on the CD. Rather, the idea is to sell the convenience of providing the freely available code in an easily accessible form. The value of GNU software on a CD lies in the fact that it is easier to install from CD than to download and install from the Internet. But, either way, the actual programs are free.

The Helsinki Connection The picture was incomplete, though. Even though the GNU project was making significant progress toward a free operating system, certain things were lacking. One major piece was the absence of a workable kernel—the core of the operating system which enables all the other components to work together. But another major piece was absent as well. Although Stallman and company had progressed substantially toward the stated goal of creating a free Unix-like operating system, there was a nontechnical hurdle that would likely limit its use. In academia, the GNU project had a decent following. But in corporations, the GNU project was largely regarded as the pet project of a group of weird idealists. The entire project was largely ignored by businesses. After all, what would the corporate world do with the product of a group of supposed “strange fanatics”? Widespread adoption of free software would require more than just technology. It was a matter of more than just code. What the GNU project would need to rise out of the academic world into the corporate realm was a sense of corporate legitimacy. As it turns out, both the origin of a functional kernel and the advent of corporate legitimacy would arise from the same place: Finland. In 1991, Helsinki University student Linus Torvalds was working with his humble 386 PC. He was unhappy with the limitations of the MS-DOS operating system and longed for the power of the Unix operating system that was used on the University’s large computers. There were commercial Unix implementations available for the PC, but even these were beyond the

04 1989-6 CH02

8/21/00

1:13 PM

Page 21

Chapter 2 • HOW DID ALL THIS START?

modest means of a university student. He wanted a Unix-like operating system that would be available to everyone. But there was something else, too. Here was a young man who was not out to build the next billion-dollar software empire. He was looking for a way to do something that he liked to do: programming. He wanted to create an operating system that was actually fun to work on. This notion, that this project should be fun, would prove to be a key concept in its future development. Linus intended to enjoy his work and wanted others to enjoy it as well. Linus obtained information about the Intel x86 architecture and began work. He announced his efforts on a Usenet newsgroup and began posting pointers to his code. Other people with similar desires slowly began joining the process, suggesting changes, submitting patches, and eventually taking on necessary tasks such as writing drivers for various pieces of PC hardware. The person running the Web site that held the source code dubbed the effort Linux: a cross between Linus and Unix. A major accomplishment was the porting of the GNU C compiler to the Linux system. With that, most of the GNU utilities could now be compiled and used in conjunction with the Linux kernel. Before too long, Linus’s little project became a project team of several dozen people. Linus made sure that people who submitted code to the project were given public credit for their efforts and saw the fruits of their work quickly. He produced new kernels on a daily basis (sometimes multiple times per day), so submitters quickly saw their contributions come to life. This quick positive feedback built up enthusiasm for the project. He also never let go of the concept that Linux itself should be a fun thing. And before long, more and more people began joining in the work. In 1994, the Linux kernel reached version 1.0. The number of users worldwide was estimated to be one million or more, with most of those being computer professionals or students. In the years that followed, however, the numbers began growing precipitously. By the beginning of the year 2000, Linux had gained the status of a rising star in the software industry.

What About That Fat, Little Penguin? A small, but significant, piece of the Linux puzzle is a little fellow named Tux. Tux is a chubby little penguin, normally pictured in a seated position, who is as ubiquitous in the Linux world as the Windows logo is in the Microsoft world. The basic artwork is an image created by Larry Ewing which he has allowed to be used as the basis for most of the Tux images which populate the Linux arena. The origin of Tux is not found in some corporate marketing group which sought to produce a visual image to represent the Linux system. Rather, the Linux penguin originated in the same place that many other penguins originate: a zoo. During a visit to an Australian zoo, Linus Torvalds was nipped on a finger by a pygmy penguin. Good-natured stories began to appear in the Internet newsgroups about Linus’s encounter with the “ferocious beast.” As Linus found the whole episode amusing, the association of two things he enjoys (Linux and penguins) seemed quite reasonable.

Open Source Versus Free Software Despite the fact that so many developers were working hard to develop a free operating system, there were some differences in philosophy. The GNU project was focused on the moral

21

04 1989-6 CH02

22

8/21/00

1:13 PM

Page 22

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

and ethical necessity of producing free software, whereas many of the Linux developers were more interested in the pragmatic benefits of producing a free operating system. Although many of the goals were clearly compatible, there arose the need to make some distinctions between the philosophies. Because of these differences, a new term was coined: Open Source software. How do the two categories differ? The free-software community stressed the moral imperative of producing free software. In their eyes, anyone who produces closed software is performing an act that could be described as “evil.” It is imperative, therefore, to educate people about the need to produce and use only free software. The Open Source community, however, takes a more pragmatic view about the production of free software. The emphasis is not on a moral imperative to share knowledge, but on the fact that sharing code makes for better software. It is often argued that Open Source software is of higher quality than its closed counterparts, since it is the product of many more interested and critical onlookers. In this viewpoint, closed software is viewed not as “evil” but as irrelevant. The secret, it is said, is to get people to develop more high-quality Open Source software. When each closed software product has to stand toe-to-toe with a superior Open Source equivalent, the closed software will naturally fade into obscurity in time. What is the importance in making the distinction between Open Source and free software? Open source is seen as a more business-friendly concept than free software. The key benefits from the term Open Source include: • Open Source emphasizes quality • Open Source stresses flexibility • Open Source decreases development time • Closed software is characterized as non-competitive, rather than immoral

But Wait…There’s More! Even though these stories are key in the development of the Open Source movement, there is much more to the story. Although the projects covered so far are essential for understanding the history of Open Source, they are by no means the only stories to be told. There are many other stories as well. Here are a few worth noting.

An Open Network One of the most crucial decisions in the history of Open Source was also one of the most intuitively obvious. As the ARPAnet grew, the need for a suite of robust networking protocols became apparent. The eventual result was TCP/IP. But beyond being a set of robust protocols, these were a set of documented, open protocols. The need for open protocols was obvious: How else could a diverse group of machines expect to talk to each other? The protocols needed to be proposed in the open, reviewed in the open,

04 1989-6 CH02

8/21/00

1:13 PM

Page 23

Chapter 2 • HOW DID ALL THIS START?

and approved in the open. Everyone had to have a chance to give suggestions and voice objections before the standard was set. Indeed, the Internet grew around these principles. Although these actions might seem obvious and reasonable, they must not be taken for granted. It was this dedication to open standards that propelled the Internet while it changed the world of computing in the 1990s. And it is this dedication to open standards that brings about furious objections to some corporations which seek to develop closed protocols on the Internet. Many corporations have sought to create de facto Internet standards based on their closed, proprietary standards. People who come from a PC background often find no problem in this approach, since so much of the PC world developed in this manner. But people who have been steeped in the Open Source background often become infuriated at such efforts. Without dedication to open standards, the Internet cannot continue to be the Internet. Indeed, the Internet without open protocols is merely a sandbox for selected corporate entities, not a virtually unrestricted playground for the entire world.

An Indian on the Warpath The early 1990s marked the birth of the World Wide Web. The Web concept combined some of the traditional Internet protocols with a new graphical user interface called a Web browser. To feed the browser with information, HTTP servers were created. By 1995, the most popular server was the public domain httpd daemon created by the National Center for Supercomputing Applications (NCSA), University of Illinois, Urbana-Champaign. It worked fairly well, but it still had a number of bugs that had to be fixed. Unfortunately, development of the program stalled when its core developer, Rob McCool, left NCSA in 1994. A group of interested programmers arose to fill the void in the development of the NCSA httpd program. In 1995, they released their first patched version of the NCSA program. Since they were creating a “patchy” server, they decided to call the effort Apache. Over the years, Apache grew into something more than just a patched version of the old NCSA server. It became a robust, feature-rich Web server which increased steadily in popularity. The surprising growth of the World Wide Web helped push Apache into the spotlight. The computer industry giants had plans for the future of computing in the early 1990s, and none of them had the spontaneous growth of the World Wide Web in their plans. When the Web began to grow furiously in the mid-1990s, neither the technology giants nor their corporate customers had developed significant Web strategies. Corporate IT departments were faced with a problem: Begin a Web presence now, or hand an advantage to their competitors? But how could it be done? The commercial solutions that corporations normally relied on were either immature or nonexistent. Since few large companies perceived the importance of the Web until it was already upon them, there were no budgets in place to purchase expensive servers and software to establish a Web presence. It was this situation that helped propel Apache into stardom. IT departments the world over wrestled to create a Web presence without the benefit of commercial tools or a significant budget. A common solution was to take a low-cost PC and combine it with Apache and an Open

23

04 1989-6 CH02

24

8/21/00

1:13 PM

Page 24

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Source operating system (often Linux or FreeBSD) to create an inexpensive but reliable Web server. Often, upper-level management would be told of the successful installation of the Web server, but the presence of the Open Source software was not always mentioned. Corporate decision makers did not know or understand anything about Open Source yet, so the technical people frequently neglected to tell them that the new solution included such software. The result was that Apache quickly became the most used Web server on the Internet. Even as major players such as Microsoft began developing commercial Web servers, Apache continued to grow in popularity. By the beginning of the year 2000, the Netcraft Web survey (http:/www.netcraft.org/) indicated that Apache was responsible for hosting over 60% of all Web sites on the Internet. It was no longer the most popular Web server on the planet; it had risen to be the de facto standard Web server for the Internet.

The Birth and Resurrection of X Another project that traces its roots to MIT is the X Window System. X was not born from the efforts of the Free Software Foundation. Instead, X came from the desire to create consistent graphical interfaces on various types of computer workstations. Unlike the GNU Project, the X Window System enjoyed widespread support by corporations in the 1980s. Just about every Unix workstation vendor featured graphical interfaces built on X. However, X itself was built as more of a toolkit than a finished graphical user interface. It was designed to be highly flexible and capable of supporting many types of GUIs. But, as a result, many companies developed X-based GUIs that varied a great deal from one another. So a consortium arose to create a standard look and feel to X that could be embraced by multiple workstation vendors. The consortium was called the Open Software Foundation (OSF), which produced the Motif toolkit and the Motif-based Common Desktop Environment (CDE). Although it was adopted as a standard X desktop by many manufacturers, it was not a very rich environment. As new graphical desktops from Microsoft and Apple appeared, it became clear that Motif and CDE left much to be desired. As they were the results of design by committee, however, they failed to progress sufficiently to meet the challenge of the PC. By the early 1990s, the common wisdom in the industry was that both Motif and the X Window System were yesterday’s technology. Even the most ardent supporters of X realized that it was dying. But something very strange happened. The decline of X was cut short by the dramatic increase in use of the Linux operating system. As free software designed for Unix workstations, X was the natural choice for implementing a Linux GUI. But Motif and CDE, the previous champions of the X desktop, were both lacking in features and in license; Motif was not free software. Some lightweight challengers arose in the Linux community to occupy the desktop, but everyone realized that a more feature-rich solution would be needed if Linux were ever to make a play for the corporate or home desktop. Two projects arose to fill the void. The first of these was the K Desktop Environment (KDE). Although it had it sights on some admirable goals, it had a problem. One of its critical libraries, Troll Tech’s Qt library, did not have a license that fit the full definition of free software

04 1989-6 CH02

8/21/00

1:13 PM

Page 25

Chapter 2 • HOW DID ALL THIS START?

as defined by the Free Software Foundation. So a second desktop project, GNOME (usually pronounced “guh-nome’”) was launched to create a rich desktop with totally free software. Eventually, the license issue of KDE was solved, and so there are now two user-friendly desktops available for Linux and other Unix-like operating systems. For the first time, the promise of a truly rich X-based GUI was being fulfilled. And something unusual happened: A computer technology deemed obsolete and dying suddenly came back to life. Suddenly, no one was discussing the impending death of X. Instead, GUIs based on X became big news in the trade press.

A Daemon Awakes Around 1980, the University of California at Berkeley began to create the Berkeley Standard Distribution (BSD) of Unix. The license that BSD was distributed under allowed the software to be used by anyone, just like the GPL license of the GNU Project. But, unlike the GPL, the BSD license did not force receivers to keep the code open or free. As a result, a few forms of BSD grew up, some free, some not. These included BSDi, FreeBSD, NetBSD, and OpenBSD among others. Among these, FreeBSD is sometimes used as an alternative to Linux, often as a Web server. FreeBSD is known for having a very quick and tight network stack, making it an attractive operating system for network services. However, most of the BSD varieties suffered from having traditional Unix-style desktops. Much of the work that went into the Linux desktops later found its way to the BSD variants, thus allowing them to benefit from the rapid advances experienced in the Linux world. BSD’s mascot, the BSD Daemon, is often seen accompanying Tux, the Linux Penguin, on Web pages and at trade shows.

The Postman Knocks Around 1980, the ARPAnet migrated to using TCP/IP as its major networking protocol suite. New programs were needed to handle tasks such as mail delivery. Eric Allman developed a program called sendmail to handle mail delivery on the fledgling network. Over time, Allman and others grew sendmail into a solid and powerful mail handling program that now report1 edly handles over 75% of Internet mail traffic. In 1997, Allman was a cofounder of Sendmail, Inc., which sells an easy-to-use corporate version of sendmail. However, Sendmail, Inc. has committed to continue development of the free version of sendmail.

The Distributions are Born The arrival of Linux and free software marked the arrival of a new animal called a distribution. A distribution is the bundling of multiple pieces of software into one branded whole. In the Linux world, the Linux kernel and drivers are frequently packaged with a wide assortment of GNU and BSD utilities, an installation program, a selection of GNU-licensed applications software, and occasionally commercial software. 1 http://wideopen.com/print/763.html

25

04 1989-6 CH02

26

8/21/00

1:13 PM

Page 26

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Before the arrival of the distributions in the early 1990s, the normal way to build a Linux system was to visit various Web sites and download the individual pieces of software needed to create a working Linux system. It required a great deal of expertise to know where to find the various packages, download them from the Internet, compile them, and configure each component so the result was a usable system. This was acceptable when Linux was in its infancy, but it soon became clear that software needed to be organized in order to make installations simpler. One of the earliest distributions to arrive on the scene was Slackware. Originally designed to be installed from floppies, Slackware was one of the first attempts to take the many pieces of software that go into a working Linux operating system and put them together into a cohesive group. Although Slackware still has a reputation as more of a kernel hacker’s distribution, it should be realized that Slackware has survived because of its configurability. Many other early distributions lived and died before Linux began to grow in popularity. Red Hat has the distinction of being one of the first distributions to grow from humble roots into a major Linux player. Caldera was one of the first distributions to focus entirely on the business uses for Linux. SuSE and TurboLinux established footholds in Europe and Asia, respectively.

What Next? The history of Open Source, then, is quite diverse. It comes from the work of idealists, pragmatists, academicians, and corporations. Despite this varied background, however, Open Source software has progressed remarkably over the years. But all this history means nothing if there is no future to Open Source software. This is the issue we will explore in the following chapter.

05 1989-6 CH03

8/21/00

1:13 PM

Page 27

CHAPTER 3

WHY SHOULD I CARE?

A

fter learning something about the Open Source community, many people ask the natural question, “Why should I care?” The actions of this group might be interesting or novel, but what difference do they make? Yes, they produce some interesting and useful software, but if I am not part of that community, what difference does it make to me? It is a surprise to many, but the effects of the Open Source movement actually reach much farther and wider than one might believe. Detractors say that Open Source is just software. Linux is merely an operating system. And, to a certain extent, they are correct. But the effects of Open Source go far beyond the software.

From Cost Center to Profit Center Until the dawn of the Internet age, most organizations viewed computers as a necessary evil of corporate life. The IT department was required to support the goals of the organization. PCs and support staff were overhead required to keep the company functioning. Ideally, computers reduced the cost of doing business. But very few organizations saw computers as an actual profit center—something that would bring profit into the corporation. All that changed when the World Wide Web was born. Suddenly, computers were no longer just tools to support the profit-making areas of the corporation; they were profit-making areas of the organization. Everyone from giant multinational corporations to small, local mom-andpop shops now had a Web site. Size, industry, and locality no longer mattered. Every company, it seemed, needed a Web site. With the arrival of the age of the Internet, the entire world became a single marketplace. Almost overnight, anything that could be bought, could be purchased on the Web. In the blink of an eye, the Web became the source of potentially huge profits. But to make those profits, companies needed computers. And to run those computers, companies needed software. So, suddenly, software was elevated from the role of necessary overhead to the position of facilitating significant additional revenue. It was no longer a cost to be swallowed. It was now enabling technology for higher profits.

05 1989-6 CH03

28

8/21/00

1:13 PM

Page 28

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The Essential Disruptive Technology Those who look at the history of technology know that there are certain technologies that do more than simply enhance the state of the art. There are certain technologies that arise that actually change the direction of technical progress. They appear, not as the logical progression of existing technology, but as something that seemingly comes out of nowhere. They are not found on the charts of pundits who project the paths of technology for the future. Instead, these technologies frequently change the rules by which the industry plays. They tend to catch the established players off-guard. They often challenge the established norms of the technical world. They are called disruptive technologies. Many industry players look at Open Source software such as Linux and proclaim that it is not a disruptive technology. They point to its obvious roots in the Unix operating system. They see that organizations such as the Free Software Foundation have been around for years. They proclaim that Linux is merely a slightly updated form of some very old technology. “No disruptive technology here,” they crow. But it is not that simple. Yes, much of the Open Source movement has very traceable roots. And, yes, parts of Linux clearly reflect many of the known technologies found in Unix. But part of being a disruptive technology is the ability to change things in very surprising ways. Open Source hits this target square on. In this case, it is not so much that Open Source ventures onto technical ground that has never been explored before. But it does bring the rules and expectations from one area of technology (large computer systems) into another area (PC systems). And, most importantly, it does it all in a way that defies the norms of the computer industry, as you will see later in this chapter.

Disruption: A New Way of Thinking About Desktop PCs Since the dawn of the personal computing era, a common characterization of the PC by many computer professionals is that it is a computer that does one thing at a time, and does it badly. Since its inception, the PC has been lauded by business people for bringing compute power to their desktops. No longer did they need to wait months for the data processing department to create a new report; a few clicks and the data magically appeared on the PC screen. No longer did they need to spend tiresome hours painstakingly going over figures with an adding machine; a few numbers punched into a spreadsheet gave the correct total every time. And no longer was there any need to struggle with old-style typewriters, carbon copies, and correction fluid; now every document from the word processing program was totally perfect. But the PC has also been denigrated by many computer professionals who found that it lacked the stability and multiprocessing capability of “real” computers. PCs are notoriously unreliable things that have to be rebooted often, unlike their larger counterparts that normally stay working for months at a time. They have difficulty doing two or more tasks at once, unlike departmental machines which easily handle dozens of concurrent tasks. They also frequently require

05 1989-6 CH03

8/21/00

1:13 PM

Page 29

Chapter 3 • WHY SHOULD I CARE?

someone to physically intercede at the PC in order to correct problems and do system management tasks, unlike bigger systems that can be managed remotely. So, the PC gives power to the user, but it lacks the robustness associated with larger machines. Or so we have been led to believe. After years of working with PCs, however, I would find out that the complaints surrounding the PC were not entirely accurate. A few weeks later, I was slated to attend an intensive two-week training session away from home. The schedule for the course appeared to be quite grueling and it would be difficult to speak to my wife during this time. We did not have an Internet service provider at the time (in the spring of 1995, very few people did), so we had no access to an email system through which we could communicate. On a “real” Unix system, I knew it was possible for more than one person to log in and send mail to each other. If I brought my laptop to the training session, I could conceivably log in to my home PC over the telephone and exchange email with my wife any time during the day or night. This seemed to be just the solution I needed. So, I went about configuring my little Linux PC to accept remote logins over its modem. And, I wrote a little menu system so my wife could easily log in to my PC and send and receive mail while I was away. This would solve my problem, while allowing me to judge how well this Linux operating system would work under fire. Little did I know that the results of this little experiment would eventually have a major impact on my career. One night during the trip, as I logged in from my hotel room, I checked the status of my home PC. My wife happened to be on the machine at the same time composing an email to me. I knew from the technical description on the Linux CD that it was supposedly possible for two or more people to work on the same machine at the same time. But I must admit I was skeptical. I went about my business sending and reading email, half expecting the machine to experience a problem. But no problem appeared. The machine simply went about its job without complaint. In fact, had I not looked at the machine status when I logged in, I would never had known that my wife was busily typing away on the keyboard at home. It was handling two people at the same time without any problem whatsoever—just like a “real” Unix machine. Within seconds, my years of assumptions regarding the stability of the PC platform were blown away. The PC really could handle multiple tasks and multiple users at the same time. It could actually stay up for days at a time without needing a reboot. Over the many years I had used PCs, I had assumed that the personal computer hardware itself was so deeply flawed that it could not deliver a highly stable and flexible computing experience. Only an expensive “real” computer, like those housed in corporate data centers, could perform that way, I thought. But a 386 PC proved I was wrong. The real problem was not that the hardware was incapable of doing the job but that the software I had been using was not up to the task. But, given the proper software, the PC hardware could be convinced to deliver a robust computing environment.

29

05 1989-6 CH03

30

8/21/00

1:13 PM

Page 30

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

This was revolutionary to me. I could have essentially the same strong computing environment at home that I had at work. All I needed was really good software. And I found that software on a CD that said Linux on its label. Another lesson was driven home to me in 1997 when I constructed a Linux workstation out of garbage found in one of the development labs at my office. I created a 486 PC from discarded components, loaded Linux and the Apache Web server, and used the result as my combination workstation and intranet server. I found that the garbage box was capable of doing an impressive amount of work, despite the fact that it was created with components at least two generations behind the state of the art. The real kicker came when I decided to see how long the system would continue to run before it hung or crashed. I knew that the components in this system had probably never been run for a solid week without requiring a reboot. Now that it was running Linux, I wanted to discover how long this box would run before it crashed. Would it last for a month? Perhaps two months? Or more? It finally came down when an electrical storm took down the power for the building. Since it was not categorized as a critical system, it was not placed on an uninterruptable power supply. So the machine finally came down after 267 days of continuous uptime. The little machine that was probably rebooted daily for most of its life was suddenly a workhorse that had to fall prey of natural forces before it would stop. But does this mean that Open Source is disruptive to the common concept of the desktop PC? I say “Yes.” The desktop PC can no longer be considered a flaky, single-user machine incapable of much beyond simple tasks. It is a robust compute platform that is capable of far more than simple single-user tasks. Proper realization of this underused compute power in a corporation could revolutionize the types of data analysis which could be done. Consider the fact that in many large corporations, the aggregate compute power found on all employee desktops easily dwarfs the computational power found in the data centers. But, although the servers in the data center might be straining to handle the load placed on them, most desktop machines sit entirely idle some 16 hours per day. The ability to harness this compute power could revolutionize a corporation’s ability to analyze trends buried in its data. But you cannot do any of this if your desktop is just an unstable, single-user machine.

Disruption: A New Way of Developing Software Perhaps the most obvious disruption caused by the Open Source movement is in the area of software development. The methods by which Open Source software is created are far from conventional. In fact, they defy the set norms of the software industry.

Disrupting the Economics of Software Development The first part of the disruption in software development is economic. Obviously, a company which produces commercial closed-source software will find the Open Source model

05 1989-6 CH03

8/21/00

1:13 PM

Page 31

Chapter 3 • WHY SHOULD I CARE?

challenging at best and earth shattering at worst. A company which is built on the economic concept of providing guarded proprietary secret code to customers for a price can hardly expect to use such a model in developing Open Source solutions. In Open Source solutions, the notion of making money by obscuring the code from the user’s eyes is anathema. Rather, the code is open to all, so revenue cannot be generated from the premise that the code is secret and protected. There are a number of ways to generate revenue from an Open Source development effort, but each is different from the garden-variety commercial closed-source commercial effort. Some Open Source companies develop applications which are initially closed source, but they commit to opening the source within a particular period of time (often 12 to 18 months). This way, customers who want the latest and greatest capabilities can pay for them when the product is released, but everyone will benefit from it in time. The developing company makes money, the customer gets software with source, and the community gets the benefit in the long term. Other Open Source companies survive on consulting opportunities. As a customer needs additions or enhancements to an Open Source project, she contracts with a consulting firm to create the extensions. The consulting firm then submits the code changes to the project team, so they become incorporated in the official project. The customer gets the enhancements she needs, the consulting company gets revenue, and the community receives the enhancements. Another form of consulting derives not from custom software production, but from expertise in implementation. Complex business solutions can require expertise to implement. Open Source consulting firms can use their skills to construct solutions that customers need. And, of course, there is always the opportunity to generate revenue from software support. Whether through telephone call centers, email and bulletin board services, or remedial installation services, support services are always needed in the computer industry. And there certainly is no reason why an Open Source company cannot supply such services. Indeed, there are several companies which do just that.

Disrupting the Methodology of Software Development The second part of the disruption in software development rests in the methodology. Unlike closed software, Open Source development frequently takes place in teams that extend well beyond any single corporation. Development is not focused on creating wealth for a corporate entity. It is a group effort to create a solution to some problem or fill a perceived need. As such, the team is not structured with the same top-down dedication to a company-defined goal on a company-specified timeline. Instead, the goal is the creation of software that will answer the issue at hand. There are no arbitrary schedules, no predefined goal sheets, no pressure to ship the product by some date whether it is ready or not. And, most importantly, there is no extensive management structure in place who can veto proposed innovations simply because they’re “not in the plan.” Many Open Source development teams are reasonably small. Even the larger ones often have a small central core of developers who do most of the critical work with a larger group of developers around them who contribute code as necessary. The small size of the core team

31

05 1989-6 CH03

32

8/21/00

1:13 PM

Page 32

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

facilitates important design decisions without creating unnecessary bureaucracy. But, unlike many corporate product groups where some people design while others implement, the typical Open Source project team does not normally contain people who only design. The members who design the solution also normally implement part of it. This prevents many of the disconnects that sometimes happen on closed-source project teams between design issues and implementation issues. In the Open Source team, the designers usually implement and the implementers often design.

Disrupting the Chain of Command in Software Development A third part of the disruption in software development lies in the chain of command. In most corporate programming teams, the chain of command is defined by position within the corporation. And, position in the corporation frequently has to do with the history of the individual, the number of years with the corporation, and corporate politics. A developer normally does not rise to a position of authority unless he has a long history of successes, several years of service, and the blessing of corporate management. In Open Source teams, however, the chain of command on a project is handled in a very different way. The team leader is often the person who had the idea for the project in the first place, or at least was the first person to become motivated enough to create the project team. Sometimes the team originator will yield the leadership to another team member if the originator believes that the other member will do a better job as a leader. Regardless of who becomes the leader, it does not happen the way it does in the corporate world. There is no common corporation in which to earn seniority; politics rarely comes into play. In Open Source, the main qualification for most team leaders is a dedication to seeing the job through. The burning desire to create the software is often the critical factor for a team leader. People are given the chance to prove their worth regardless of their credentials. Some projects feel the impact of inexperienced leadership, but the net result is that many people considered too young and inexperienced by the computer industry quickly develop into seasoned leaders following the Open Source method. The Open Source world is full of illustrations of this regard. The most visible example is Linus Torvalds himself. Starting the Linux project as a university student, Linus had no earthshattering credentials nor a long and seasoned history of software project leadership. Yet, this young man uncorked the bottle from which a genie would arise to change the path of the software world. Similar stories can be found throughout the Open Source world. For instance, Larry Wall wanted a language that could scan text files and create reports better than existing Unix utilities such as awk or sed. So, in 1987 he released the language called Perl, which would soon become one of the most used languages on the World Wide Web. Patrick Volkerding was just a university student when he began fixing problems in the early versions of Linux. He wanted to help stabilize the code and share it with others. His efforts eventually gave birth to the Slackware Linux distribution, one of the first and best of the Linux distributions.

05 1989-6 CH03

8/21/00

1:13 PM

Page 33

Chapter 3 • WHY SHOULD I CARE?

The stories go on and on. Time after time, people with no special credentials and no impressive resume simply saw a problem, worked hard for a solution, and motivated others to do likewise. Project after project came into being this way. To the established software world, these projects seemed to spring from nowhere, since no company or big-name software guru was at the helm of the effort. But good people with good ideas have built some excellent software, and their impact is being felt throughout the industry.

Disrupting the Competition in Software Development A fourth area of the disruption in software development deals with cooperation among competitors. The traditional view of software development tends toward separate companies developing software independently from each other. Cooperation between companies is usually restricted to such efforts as setting of standards, often with a great deal of bureaucracy and formal negotiation. Cooperative ventures between competitors tend toward narrowly defined ventures consummated after much negotiation. The Open Source world, by comparison, not only encourages but demands a degree of informal cooperation between competitors. To improve the software used by friend and foe alike, there needs to be shared effort by all parties. This will be discussed in detail in Chapter 8, “Cooperate with the Competition? Are You Nuts?”

Disrupting the Roles in Software Development A fifth area of the disruption has to do with the redefinition of the role of commercial software developers. As noted earlier, the structure of a software development group can change considerably under most Open Source models. Developers will need to cooperate with many people in other corporations on the task at hand. But, more importantly, companies that hire developers to work on Open Source projects will find that they will benefit from a high return on investment (ROI). In closed-source efforts, corporations generally do one of two things: Either they hire a full staff of developers to create software for the corporation, or they purchase commercial off-theshelf (COTS) solutions. The first option often yields software that meets the needs of the business, but at a very high price. The second option lowers the price considerably, but the software sometimes lacks the features the company desires. In the Open Source world, the solution might be to hire one or two developers to work on an Open Source project. For the cost of one or two people instead of a full staff of analysts and programmers with associated managers, the company can ensure that the project continues to service the needs of the corporation. The solution might not be quite as inexpensive as simply purchasing a license for commercial software, but the corporation no longer relies on the vendor’s vision for the product.

Disrupting the Code Review in Software Development Finally, the sixth disruption to software development has to do with peer review. Closedsource efforts often suffer from flaws and problems which the original development team never anticipated. Lack of inspection of the code by other programmers can mean that inappropriate design constraints or other errors might not be discovered until the code is already in use.

33

05 1989-6 CH03

34

8/21/00

1:13 PM

Page 34

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Other teams sometimes become too reliant on the expertise of some single individual. When that person leaves, there is often a mad scramble to find out what the person was doing and how they were going about it. The loss of a programmer of even mediocre talent can turn into an expensive effort to recover work in progress, as well as trying to gain understanding of certain aspects of the project that he alone knew. In Open Source software development, however, most work is done in the open. Test versions of the code are normally made public frequently, without long periods of silent work which suddenly produced finished code. Everyone on the team—as well as people outside of the team—can see the code as it forms. Expertise can be acquired by others as they review the work. Bugs and limitations can be spotted while the code is still in development. Critical issues can be addressed early in the development cycle, before a large amount of time is wasted developing a solution that will prove to be inadequate on delivery.

Disruption: A New Way of Owning Software That Open Source is a disruption in the way in which software is created is readily apparent to many people. But many people fail to see how Open Source disrupts the way in which software is “owned.” Consider a common way a PC user purchases software. The user walks into her local PC software retailer. She locates the appropriate box on the store shelf. She pays for the software on the checkout line. She now “owns” that copy of the software. She now takes the software home, installs it on her PC, and uses it at will. At first blush, purchasing a copy of Open Source software seems to be much the same. The same scenario can be repeated to purchase a copy of Linux, FreeBSD, or some other Open Source software. So where is the disruption? One commonly cited difference is cost. As strange as it sounds, the difference in cost is simultaneously the most overestimated differentiator, and yet one of the most underestimated differentiators between Open Source and closed-source software offerings. When many industry pundits discuss Open Source software, one of the first topics discussed is the fact that it is generally cheaper than its closed-source alternatives. In fact, listening to some commentators, you might come to believe that cost is the only real difference between Open Source and closedsource software. And that difference, they say, is not all that significant. The argument that is put forward often sounds like this: A normal PC operating system, when purchased with a new machine, costs perhaps $90. An Open Source operating system, such as Linux, can cost $30 (or less). For a large corporation that annually spends millions of dollars on computer-related products and services, the prospect of saving a few thousand dollars on licensing fees is utterly trivial. Hence, it is argued, the lower cost of Open Source software is not only nondisruptive, it is a nonplayer. Saving a few bucks on each copy of a piece of software just does not matter in the corporate world. This analysis can be heard from the lips of many pundits. In that regard, it is perhaps the most frequently cited benefit of Open Source software. But the flaws in this analysis show that it is also one of the most underestimated benefits of using Open Source solutions.

05 1989-6 CH03

8/21/00

1:13 PM

Page 35

Chapter 3 • WHY SHOULD I CARE?

The difference in cost between the Open Source and closed-source operating systems is not particularly large. But is that all there is? What about the cost of the compilers that come along with the Open Source operating systems, but are purchased separately on most closed-source systems? What about email servers and clients? Word processors? Remote access software? Databases? Web servers? And licenses that allow for unlimited connects to the server software? When the total cost of all these pieces is compared, the difference in cost between the two solutions becomes much larger. The amounts will depend on the software configuration needed, but the difference could be anywhere from a few hundred dollars for a client machine to over a thousand for a server. Another less-apparent cost savings comes from the fact many Open Source solutions require less hardware to do the same job as many closed-source alternatives. Since systems such as Linux and FreeBSD use the basic theory of Unix, much of the operating environment is built on modules, rather than large, monolithic kernels. And, the Open Source development model tends to cause improvements over time, thus refining many of the modules toward better efficiency. The result is a system that only loads as much code as needed to get the job done. This frequently translates to requiring less memory and CPU power than many of the closed-source alternatives require. So, an Open Source solution can reduce cost by allowing you to use an older, cheaper machine instead of a newer, more expensive model. Once again, that is not the end of the matter. As many analysts will say, the cost of maintaining a PC can dwarf the cost required to purchase it. So even a more substantial gap in price between the two solutions will be overshadowed by the cost of maintaining them after purchase. But, here too, Open Source has an impressive story. The fact that Open Source systems normally include remote access capability and very high levels of stability means that less time is required for management and maintenance. And, when such tasks are required, most of them can be performed remotely, reducing time lost due to physical travel. The robust scripting environment also means that even rather complex procedures can be propagated to a large number of systems in a short period of time with very little labor. These capabilities drive down the total cost of ownership of an Open Source solution even farther. Is a lower total cost of ownership really disruptive? On its own, no. But it does pave the way for more advances which are disruptive. In a major corporation, saving some money is nice, but it probably will not significantly impact the bottom line to such an extent that stockholders would be aware of the change. But, in a small company, doing a big job with a low-cost solution could play a major role in the success of that company in its early years. Even greater is the impact in countries where new computers are prohibitively expensive compared to the local wage scales. Suddenly, these developing nations can use the old computers that are deemed “worthless” by developed countries to do important tasks. Poor countries that can obtain old 486 systems can suddenly find themselves capable of Internet connectivity. This means that developing nations can learn more quickly and enter the worldwide marketplace much sooner than they would be able to do otherwise.

35

05 1989-6 CH03

36

8/21/00

1:13 PM

Page 36

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

But cost does not even begin to address the biggest issue with respect to owning software. The key is the word owning. With most commercial software, you receive a license with many terms included in it. These terms often include restrictions on the installation, use, distribution, and backup of the software. They also include the limitations on liabilities of the software provider. While Open Source licenses often address most of the same issues, the results are far different. In the commercial world, what does a fairly normal license look like? Well, in the United States at least, it generally restricts the user to installing the software on only one machine (or, if installations on more than one machine are allowed, only one machine is permitted to be in use at one time). The software may only be used in the manner described in the license. If not, the provider may claim the license null and void and the consumer is forbidden from using the software at all. Distribution of the software by the user is normally strictly forbidden. The occasional exception is an allowance to resell the original media and license to a second user, with the first user ceasing all use of the software, uninstalling it from all machines, and destroying all copies of it that might have been made. The commercial software provider’s liabilities are normally spelled out in detail. Specifically, most commercial products come with explicit statements denying all liability beyond replacement of the media or refund of the cost of the software. It might come as a surprise to people who have never actually read a software license, but most licenses state that the provider can not be held responsible for losses if the software is found unfit for its stated use or if the software actually causes the user physical or financial harm through an inability to perform as expected. The provider, in essence, warrants that there is software in the box which might or might not work as stated, and if problems arise, the provider is essentially absolved from all guilt whatsoever. Under the worst of cases, the provider has the option of simply refunding the amount paid and the user is supposed to consider the matter closed. Ah, but what about legal action on the part of the user? Most licenses specifically state that the rights of the consumer may be broader than specified in the license because of state and local legislation. Surely, this will allow the user to receive due compensation for losses suffered from malfunctioning software, will it not? Even the most restrictive licensing agreement must be subject to the prevailing laws of the land. But there is a fly in the ointment here as well. As I write this, software industry lobbyists are busily working to influence the laws regarding software procurement in America. Not surprisingly, the proposals often floated before legislators look rather like the license agreements already included in the software. The liability of the software providers is generally quite small, while the burden of maintaining proper licensing often falls on the consumer. Some legislation goes as far allowing software providers to include programs that will automatically uninstall the software product if the user fails to prove that the license has been renewed by the provider at some proscribed interval. When the whole picture is considered, it is difficult to consider using the term ownership to describe the relationship of the user to the software. In fact, the word rental seems closer to describe the relationship. But even that term seems wanting, when one considers that the software provider does not warrant that the product will even begin to work as described. Regardless, the term ownership seems to best reflect the provider of the commercial software far more than it does the user of such software.

05 1989-6 CH03

8/21/00

1:13 PM

Page 37

Chapter 3 • WHY SHOULD I CARE?

In the Open Source world, there are also frequent license provisions regarding the installation, use, distribution, and backup of the software. There are some restrictions placed on the user. But the net result is quite different indeed. Most Open Source licenses do put some type of restrictions on people. For example, most licenses hold the code’s producer blameless for problems resulting from malfunctions of the program. And, as the producer normally receives no fee from the user for the use of the code, there is no issue of refunding the purchase price. But, as similar as this sounds to the standard commercial closed-source licenses, there are significant differences in liberties that greatly modify the impact of this release from liability. There are other common restrictions as well. For example, it is normally the case that the user is precluded from taking someone else’s code and putting his own name on it, claiming the code as the user’s own original work. Another restriction imposed by some licenses (like the GNU Public License), demand that the source code always be made available by the distributor and that all changes made to the source code by the user be made available as well. But, regardless of the Open Source license used, there are also significant liberties which are granted to the user of the software. Most Open Source licenses allow users to install the software on as many machines as they want. They even allow users to share the software with friends and associates. Many licenses even allow users to make and sell duplicate copies of the distribution media to whomever they want. But one of the most significant and underestimated liberties is the right to fix and enhance the code as needed. Many critics try to downplay this capability as insignificant, as most people have no desire or expertise to actually change a program’s source code. However, that criticism misses the point entirely. As great as the ability to examine and change the source code is, it is not as significant as the right to make the change. That is to say, with Open Source solutions the user has been granted the right to make the program work as needed. This makes the difference between closedsource and Open Source licenses seem like night and day. With standard closed-source licenses, the code is not warranted against defect, the producer is held legally blameless, and the broken code will only be fixed if the provider believes it is in his best interest to fix it. With standard Open Source licenses, the code is not warranted against defect and the producer is held legally blameless, but the broken code can be fixed if the user believes it is in the user’s best interest to fix it. With most closed-source software, the user is essentially a renter of the software. With most Open Source software, the user shares in the ownership of the software. But is this change really disruptive? Someone might argue that, yes, it may allow a technical user to alter the software as needed, but that represents a very small percentage of the using population. Even most businesses do not have the staff on hand to make significant coding changes to Open Source products. So how is this change really disruptive? It is disruptive because it gives users concrete means by which they can influence software.

37

05 1989-6 CH03

38

8/21/00

1:13 PM

Page 38

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Disruption: A New Way of Influencing Software Consider the plight of the organization that must select and use software to further its ends. High-level IT management is well aware of the fact that it must choose its technology partners wisely. Not only is it concerned about the cost of deploying a technology solution, but it must consider the quality and future of the solution as well. If the solution fails to live up to its promised potential, organizations often have to rely on placing pressure on the vendor to fix the problem. The amount of pressure the organization can generate is often proportional to the amount of revenue it provides the vendor’s company. So, the larger the organization, the more likely the vendor is to respond. But, even so, the customer is still at the mercy of the vendor’s opinion. If the vendor is simply unwilling to address the problem, the customer is in trouble. Likewise, the customer organization must make a careful study of the future plans of the vendor company. If the vendor does not intend to develop the product in question in the direction which the customer needs it to be developed, the customer would be advised to find another solution. Since the customer can only hope to influence the vendor, but lacks the actual power to direct the product, the customer needs to find a solution which closely follows the course that the customer needs. The problem of futures has developed an entire culture in the IT industry. At major trade shows and at vendor meetings, IT managers can be heard demanding long-term plans from the vendor. It is absolutely essential for the security of the customer that these plans be revealed and reviewed. Of course, the fact that many of the these plans never seem to go exactly as described is regrettable but accepted in the industry. When the only way to protect the future of an organization is to demand future plans from a vendor, you do the best you can, but you expect turns in the road. Given this practice, it is unsurprising to find IT managers demanding extensive future plans from Open Source organizations. But given the nature of Open Source, it is unsurprising that Open Source project teams do not normally have the types of plans that large organizations demand. Open Source groups generally have broad goals, but specific plans are often formed according to the perceptions of the project team. This sometimes causes IT managers to call for Open Source groups to “grow up” and do things the way customers expect. But this is the point at which the disruption caused by the new type of ownership of a product is most acute. What is needed here is not so much that the Open Source groups have to begin acting like their commercial counterparts and provide elaborate guesses at the future of the project and the surrounding technologies, but that customer organizations need to grasp that the need to assess future directions has been profoundly changed. The issue here is not that the Open Source groups need to lay out the future of the project. Rather, the issue is that customer organizations must begin playing an active role in directing the future of the project itself. This fact cannot be overstated: In the Open Source world, the user becomes one of the true owners of the code. And, as one of the true owners, the user has both a right and a responsibility to guide the development of the project. The user can lay out specific goals that she sees for the project. She can communicate directly with the developers. She can allow employees to help

05 1989-6 CH03

8/21/00

1:13 PM

Page 39

Chapter 3 • WHY SHOULD I CARE?

develop the future of the project or fund developers to implement the enhancements that are needed. In fact, in the world of Open Source, users can have a direct and measurable impact on the future of the project. And, unlike typical efforts to add functions around closed-source solutions, the user does not become saddled with self-maintenance of the developed code. If they participate with development group, they can find that the extensions that they need can be added to the standard project, thus keeping the user from being saddled with the cost of continuous support. The importance of this last point should be noted. Participation in the development of the code brings release from the long-term maintenance burden, while attempting to make private extensions adds to the maintenance burden. Many companies might feel tempted to make private extensions to the code and not tell anyone else about it. That is a mistake to do, in most cases. Unless there are some absolutely unique requirements in the organization which no one else in the world will ever need, it is far better to cooperate with the development team and submit changes than it is to make private changes and bear the cost of supporting the modified code forever. In the world of Open Source, organizations find freedom. They become free to shape the future of the software around their needs, rather than constantly having to shape the future of their business around the software’s needs. They become free to release the cost of maintaining home-grown code to others outside of the corporation. And the organizations which realize the impact of this first will be the organizations which will develop a competitive advantage. For example, look at the example of IBM’s support for the Apache project. By hiring a few seasoned Apache developers, IBM is assured that the Apache Web server will address the needs of the business community. And in exchange for having a high-quality product to offer in its solutions, it pays for a only a fraction of the cost of developing an industrial strength web server. Or, look at Compaq’s support for Linux on the Alpha hardware platform. In exchange for Compaq’s investment in engineering teams that ensure that Linux runs well on Alpha systems, the corporation can offer its customers an excellent 64-bit solution at an attractive price. The company does not need to absorb the considerable cost associated with developing and testing an entire operating system, while the community benefits from having software that can run in a 64-bit environment. Herein lies a key business disruption: The first companies which properly understand and use the future-direction advantages that Open Source brings stand to prosper. They will begin to be able to shape the future of the software they use, while their competitors are busy trying to find closed-source software that is willing to head in the direction they need. And, while their competitors are paying to develop extensive plans to migrate away from the closed-source solution which is no longer going the direction they need it to, users of the Open Source solution can invest a much smaller amount to ensure that the product continues to serve their needs for a long time to come. The users of the closed-source solution are at the mercy of the vendor, subject to costly disruptions in business when the solution fails to develop with them, while the users of the Open Source solution are in charge of their own future.

39

05 1989-6 CH03

40

8/21/00

1:13 PM

Page 40

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

In this way, Open Source can truly revolutionize the way in which companies direct the future of software.

Disruption: A New Means of Support Many people look at the Open Source world, with its diverse and far-flung project teams, and ask, “But who will support me?” In the closed-source world, users contract support services from the software vendor. They receive a telephone number they can call to get answers when issues arise. They speak to people who represent the software manufacturer and dole out information that is officially sanctioned by the company that created the product. Some of these people look at the Open Source movement and panic. Who will be there when problems arise? Who will they call? Who is responsible for delivering the official reply to the problem? And how could you possibly trust an answer if you actually received one? Once again, the Open Source movement disrupts the industry model. It is correct that there is no longer a single software vendor that produced the code and that offers support services. But there is a new way of support: one that gives the user choices and opportunities. Instead of relying on a single vendor for support, the user now has the choice of many vendors. Each vendor has access to the source code. Each vendor has the ability to submit code to the project team responsible for the software which is being supported. Each vendor can compete on a fairly even playing field. Strange as it might seem, there are people who view this situation as counterproductive. Some corporate people believe that it is better to deal with the vendor supplying the proprietary solution than to have the choice among several vendors competing to support an Open Source solution. Arguments are frequently made that it is better to have a single vendor to be held accountable for the solution than to have the option of engaging one of a number of vendors. Although this argument might appear to have some merit at first, it inevitably fails under the weight of scrutiny. In the traditional closed-source model, the vendor creating the software has a virtual monopoly with respect to supporting the product. The creator can access the source code for investigating problems. It can access the list of customers who have purchased the product. It alone has the ability to change the product source code to fix problems. But monopolies in service rarely serve the best interest of the consumer. Choice and competition is a great motivator for service organizations to develop technical prowess and to keep costs in line. The vendor that is guaranteed service revenue after the sale of a product is far less motivated to make sure that quality is high and cost low than is the vendor who must compete for every service dollar earned. Competition is good for keeping suppliers under control. And, despite the comfort level of working with a virtual monopoly, competition can produce highquality support services at reasonable prices, thus adding to the success of the software user.

05 1989-6 CH03

8/21/00

1:13 PM

Page 41

Chapter 3 • WHY SHOULD I CARE?

Robert Young, chairman of Red Hat Software, frequently uses the following illustration. Suppose you purchase an automobile, drive it home, and try to open the hood to look at the engine only to find that the hood is welded shut. You go back to the dealership and ask why this is so. You are told, “We don’t trust other mechanics to properly maintain our vehicles, so we keep the hood welded shut. And, since we don’t allow others to work on our engines, we don’t publish information about how to fix them or tune them up. But we have a fine service department here, so if something goes wrong with the car, simply bring it back to us and we will take care of it.” Who would want to be at the mercy of the dealership for the rest of the life of the car? Who would not want the option of choosing a mechanic he trusts to work on the vehicle? And who would want to be in the situation where the support provider has no incentive from competition to make service prices reasonable? Choice in support is standard in most parts of life, and few people would consider loss of that choice to be a good thing. Consumers want the option of selecting the service provider that best suits their needs. And, with the arrival of Open Source, this option is now extended to software. But the advantages of Open Source support do not stop at the simple opportunity to select a support vendor. In the Open Source world, the authors of software are almost never anonymous. In a realm where personal credentials rest on one’s contribution to the community, the names of the people who create the software are both known and heralded. This means that the user of the software has access to the names and email addresses of the development team that created the software. The end user, then, has the option of conversing with the actual developers when problems arise. Certainly, these developers might not be available at a moment’s notice, but they are motivated to produce the best software possible. Often, a carefully detailed query sent to a developer can yield beneficial information—and sometimes a patch to the code—in an amazingly short period of time. Very few commercial closed-source vendors identify their developers to their customers. And, fewer vendors yet allow their developers to actually converse with customers over support issues. But, with Open Source, serious support issues can quickly yield serious consideration from the development team. And that is an advantage that is hard to beat. Another important support consideration derives from the disruption in the ownership of software that was discussed earlier in this chapter. Not only do users develop a degree of ownership of the software, they tend to develop a degree of ownership for the support of the software. And out of that sense of ownership has grown the most active and extensive usersupport network that the computer industry has ever seen. Through standard Internet tools such as Usenet newsgroups, Internet Relay Chat (IRC), and Web pages, a large worldwide multilingual support system has arisen. People from across the globe regularly band together to give support to each other. And they do it all without cost. This support network is so significant, it won an award from InfoWorld magazine for “Best Technical Support Organization” in 1997. In the chapters that follow, we will discuss the community that has accomplished this remarkable feat.

41

05 1989-6 CH03

42

8/21/00

1:13 PM

Page 42

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Disruption: A New Way of Educating Technical People An interesting disruption takes place in the realm of technical training and education. With most closed-source systems, sources of training are reasonably well defined. There are basically two choices for learning about closed-source systems: experience and tutorials. Someone equipped with time and curiosity can sit down with a software program and begin poking at it. Through observation, experimentation, and the reading of help messages, a person may be able to gain enough experience to become fluent in a software program. The cost of learning from such a method has the advantage of not requiring a direct outlay of money to accomplish the goal. But, although the person might rise to become a truly savvy user of the software, he will normally have limited insight into how the internals of the program actually work. The user might nonetheless be well equipped for meeting the task at hand. Other people who desire a more formal means of learning, or who want to gather some insight beyond what is apparent by simply using the code, might resort to a tutorial of some sort. This includes such options as attending a formal training course or reading a book that describes the software. This method is more structured and can often yield some insight to the inner workings of the software, as the instructor or author responsible for the materials often receives additional information from the closed-source development team that generated the software. This method generally requires some direct expenditure of money to accomplish the goal and normally has limitations regarding how much knowledge is received regarding the internal structure of the software. The Open Source world has these two options for learning, plus more. The most obvious learning alternative afforded by Open Source is the ability to actually read the code. From the code itself, a programmer with enough time, talent, and motivation can determine exactly how the program works. In addition, by reading the comments in the code and the technical notes that often accompany the source code, the programmer can gain insight into why the program was designed to behave the way it does. The result can be a technical person with insight into the software that exceeds the knowledge of a support person at an equivalent closed-source software company. However, this method of learning is normally beneficial only to people with the ability to read code or the desire to learn how to do it. But there are other less-obvious options for learning as well. One of these is to ask the development team members specific questions about the software. While most development teams clearly have no time to answer every user question that comes up, many teams will gladly answer thoughtful questions which deal with the internal workings of the software. This method is very useful for getting information about unobvious things, but it generally leaves much to be desired for simpler issues. For the simpler questions, information is readily available from numerous sources, such as Usenet newsgroups and IRC channels. Questions ranging from the simple to the complex are handled in these discussion groups every day. The fact that these people share in the ownership of the program means that they share in the burden of sharing knowledge with others. And this form of community-based learning has proven to be quite effective over the past few years.

05 1989-6 CH03

8/21/00

1:13 PM

Page 43

Chapter 3 • WHY SHOULD I CARE?

But one of the least obvious means of learning about a program is to participate in its development. When people share in the design, coding, debugging, or documenting of an Open Source effort, they tend to develop true expertise in that software. And although many companies might see the act of hiring a programmer to develop Open Source software as some form of peculiar altruism, it is, in fact, an act that protects the interests of the company. When a company hires an Open Source programmer, it is acquiring an immense amount of knowledge about that software system. It has obtained someone with knowledge that dwarfs that of standard closed-source support people. And if a corporation will pay substantial sums for support contracts with people who know the software system, the same corporation will get substantially more for its money by hiring someone with a superior knowledge of the product. But how is this disruptive? From the viewpoint of the individual, it means that vast amounts of technical information are available from sources that charge little or no money, and the level of knowledge which is obtainable can match that of any developer. From the viewpoint of a corporation, it means that the business is no longer reliant on others for doling out knowledge. All its employees will have access to as much information as they need to do their jobs. But the greatest disruption takes place at the national level. While the United States and Western Europe may have numerous centers for learning about technology, many developing countries do not. Countries that have been limited regarding computer hardware, software, and expertise suddenly have a wealth of information available to them for little or no cost. They have the opportunity to study working code and to join in the effort to improve it. Suddenly, countries with little technical talent will have the ability to develop substantial technical capabilities by joining with those who are developing leading-edge software. The potential effect of this disruption is enormous, as it has the possibility of significantly increasing technical expertise across the planet.

Disruption: Beowulf and a New Way of Solving Problems One disruption that is yet to be fully realized has to do with the advent of parallel processing in the normal world. With the low cost, high performance, high reliability, and customizability of Open Source, the birth of low-cost supercomputing occurred. Lots of inexpensive, common PC’s could be lashed together to form a virtual supercomputer for a small fraction of the cost of the real item. A common form of this technology, called a Beowulf cluster, is beginning to appear in universities and research institutions. Most of the technology used in these systems has been around for years. People learned long ago how to tie together Unix workstations to serve as multiple compute nodes for parallel processing problems. Much of the key software has also been around for some time. So how can this be disruptive? The point of disruption is not in any one piece of the technology used to accomplish this. Rather, the disruption takes place by virtue of the confluence of all the pieces at one time. Never before could such an extensive set of powerful, standard machines be built for so little money. With the formation of a truly inexpensive and yet scalable parallel processing solution,

43

05 1989-6 CH03

44

8/21/00

1:13 PM

Page 44

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

businesses that had never dreamed of purchasing a Cray supercomputer to do parallel processing were suddenly exploring the potential for such farms of standard PCs. Parallel solutions for business problems had been unheard of before this. But, suddenly, forward-thinking companies were daring to consider new methods of computing. Although the jury is still out on how this will develop, I believe that the new millennium will see the birth of parallel processing in business. And it will occur largely because of the power, flexibility, and low cost of Open Source solutions.

Disruption: Freedom Finally, the advent of freedom in the software world will bring about a disruption all its own. The freedom in question is not the freedom to use, inspect, and modify the software. Rather, the issue here is the freedom that management will encounter as a result of the Open Source process. As stated earlier in the section about support options, management will now have the ability to choose support options that were not available in the closed-source world. There will be decisions to be made regarding which Open Source projects should be supported by the corporation, which solutions will need to be employed, and how to move projects in the direction that the company needs. There will be many issues which used to be solved by following the lead of the vendor which will now require serious management thought. Some managers will be scared of this scenario. The fact that new questions will require answers will make some managers pine for the “good old days” when the answers were clear, because the choices were self-evident. This will drive some people to stay with the closedsource solutions that do not ask for new answers. But it will also cause a disruption in the ranks of IT management. Good leaders are not afraid to lead. Good decision makers do not shudder at the thought of making decisions. But less-gifted people will balk at the change. Because of this, then, Open Source will begin to polarize the ranks of management. Many of the best and brightest managers will not be afraid to lead their organizations into the Open Source arena. But many lesser managers will stand firm, their feet paralyzed by fear. In this way, the divisions between the strong leaders and the non-leaders will become quite apparent. And, when the results come in, it will become clear which managers are which.

06 1989-6 Part II

8/21/00

1:12 PM

Page 45

PA R T I I

EXPLORING THE ROOTS OF THE INSANITY

4

The Key to Many Things: Understanding Geek Culture

5

Community, not Communism

6

Primary Community Value: Truth

7

Fear, Uncertainty, and Doubt

06 1989-6 Part II

8/21/00

1:12 PM

Page 46

07 1989-6 CH04

8/21/00

1:11 PM

Page 47

CHAPTER 4

THE KEY TO MANY THINGS: UNDERSTANDING GEEK CULTURE

T

his is the indispensable chapter. In this entire book, this is the one chapter that should not be missed.

Why make such a statement? In a book that tries to give some very practical advice about living in and doing business in the Open Source world, why would a chapter on geek culture be the most important?

The first section of this book deals with the “what” issues of Open Source—history, context, and projects. The last section deals with the “how” issues—how to participate, how to succeed. But this section deals with “why.” And if you fail to understand why the Open Source community does what it does, your interaction with the community is at serious risk. So, the central question is “why?” Why does the Open Source community do what it does? Why do the people sometimes act so oddly? Why do they seem to get upset at “trivial” things, while seemingly ignoring “important” issues? Why can they be so rude at times? The crux of the matter is understanding of the culture. The ethics, the points of sensitivity, the motivation, and the will of the community all arise from the fluid yet substantial culture that permeates the Open Source movement. When one understands the culture, the rest of the matter is mere fact and deduction. But before discussing the impact of geek culture, there is a question that begs answering.

What Is a “Geek”? Communities sometime adopt specific terms to denote key concepts within the community. When a community develops a concept that is not well reflected in the common language, it either creates a new term or revises an old one that it can use to express this important idea. In the Open Source community, the term geek reflects one such key concept. In the common usage, the word geek is an unflattering word. It normally denotes someone who is socially inept, physically unattractive, and often exceptionally bright. In common speech, the term geek is frequently used as a synonym for the term nerd.

07 1989-6 CH04

48

8/21/00

1:11 PM

Page 48

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

But, in the Open Source community, the term geek means something quite different. Like many communities, the Open Source community took a derogatory term and turned it into a com1 pliment. So, to be called a geek in the Open Source field is to receive a badge of honor . In this community, a geek is someone who is very technically oriented. In particular, people who write Open Source software are lauded as geeks. And among the geeks, none are so geeky as the kernel hackers—those programmers who have spent time developing code for the 2 kernel of an Open Source system. It should be noted as well that the term hacker is used in a very specific way. In the common culture, the term hacker is often used to denote someone who breaks into a computer system. In the geek world, that person would instead be called a cracker. In the geek world, a hacker is usually defined as a talented programmer who employs novel or clever techniques in his coding. Once again, to be called a hacker is a badge of distinction. And although a few hackers are also crackers, most hackers have an intense dislike for the misassociation of the term hacker with people who perform illegal acts. The geeks who write Open Source software comprise a community. They tend to value certain basic concepts. They often debate particular issues which are considered important, such as freedom, appropriate licensing, or technical toolkits. And even when they disagree, they clearly understand the issues raised by the other person, because they are working from similar frames of reference. Looking at the Open Source movement, some outside people are tempted to categorize the movement in terms of economics, personalities, or politics. But this treatment does not begin to do justice to the movement. The key to understanding the way the Open Source movement behaves is very simple. To steal a phrase from that ever-articulate and caring realm known as American politics: “It’s the culture, stupid!”

Geeks Dripping with Culture The geek culture is the core of the matter of understanding the Open Source movement. The very existence of geek culture may take some people by surprise. In the general world, geeks are often characterized as being antisocial individuals. Not only is that characterization inaccurate, it is absolute nonsense. Geeks are very social people, as we will discuss in detail in the next chapter. But their social interactions tend to follow the rules of geek culture much more than those of the society at large. It must be stated up front that the culture is not monolithic in its essence. That is to say, the geek culture itself is not so much a single thing, but a confluence of multiple forces. Any individual may display few, some, or all of the qualities which will be described here. 1. It should be noted that the term nerd is still unflattering in some circles and something of an insult. It is wise not to confuse the two words. 2. The term kernel refers to the software at the core of an operating system. Programming an operating system kernel is generally regarded as one of the most difficult and complex programming tasks.

07 1989-6 CH04

8/21/00

1:11 PM

Page 49

Chapter 4 • THE KEY TO MANY THINGS: UNDERSTANDING GEEK CULTURE

But, in that regard, it is no different from most other cultures. In most cultures, there are those who fit the cultural norm well, whereas others which seem not to fit it well at all. This should not be surprising, because human beings rarely fit stereotypes very well. Regardless, the impact of the culture on its participants is often quite evident, regardless of where the person fits in the spectrum. So, if your Open Source friend or co-worker does not appear to fit the bill as described, you may well find that he or she is well aware of the cultural issues none the less.

From Kicked Dog to Top Dog: The Rise of Self-Esteem Geek culture is the product of many forces and tensions. Some are based in necessity, while others have roots in emotion. Some are matters of invention, while others are matters of reaction. But few are as difficult to grasp and yet so paramount as those that are combinations of both emotion and reaction. Chief among these is the rise of geek self-esteem. For years, the place of the technical person in Western society has been a mishmash of conflicting tensions. A geek is often regarded as intelligent, yet is also regarded as socially inept. A geek is regarded as having a solid employment future, yet is often felt to be unable to attain “important” positions in business. As a youth, a geek may be lauded by parents and teachers, yet tormented by peers and siblings. As an employee, a geek may be called a critical asset to the corporation, but unworthy of receiving public credit for work performed by having his or her name associated with a particular piece of software. In short, a geek’s life is often a continuous balancing act between times of praise and times of discouragement. For every moment of victory there seems to be a moment of total failure. For every moment of joy, there is a moment of sorrow. For every silver lining, there is, inevitably, a dark cloud. Interestingly, this is quite like the profile of many comic book super heroes. They are equipped with super powers, but they must keep their true identities secret to be accepted by the world at large. They can do things other people can only dream about, but they cannot regain their native worlds which have been lost to them. Their extreme power is balanced by extreme loss and extreme pain. It should not be surprising that many geeks have a strong affinity for comic book characters. How does this balance between accomplishment and pain affect the geek’s psyche? Like a teeter-totter with two children of equal weight aboard, any small shift of equilibrium can make the entire apparatus fall to one side or the other. Shifting to one side inevitably causes one side to come down safely to the ground, while the other side dangles precariously in the air. Shifting again can cause the dangling side to return to earth, but only at the cost of the immediate ascent of the other side into the air. Balance is possible, but not simple. And it is difficult for the geek to know which state is actually best.

49

07 1989-6 CH04

50

8/21/00

1:11 PM

Page 50

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Let us examine four common ways which a geek might deal with the struggle between the joys of technology and the heartache of society. Let me be quick to add that this is not an attempt to paint every geek as falling into one of these categories. But these seem to be fairly common scenarios that can be found in a variety of geeks at different times. I myself have resided in some of these pigeon holes at different times in my life. And, upon looking around, I found that a great number of other geeks were sharing the same hole with me. In one scenario, a geek might focus on the positives, normally arising from his technical prowess. But to do so means to ignore social criticism, which is both difficult and dangerous to fully achieve. For the geek who wants to be both technically praised and yet not socially condemned runs the risk of abandoning society in pursuit of technology. He tends toward arrogance in pride over his technical powers. At the same time, he becomes more and more of a social outcast. Technology takes the form of the geek’s personal heaven, while society takes on the aura of a lost cause. The net result is that this type of geek devolves into becoming less like a human and more like a machine. In another scenario, the geek hears the loud voices that criticize his social skills. The sounds of technical praise seem muffled by comparison. He is intimately aware of his social flubs and failures. He might even be willing to sacrifice some of his technical prowess if he could just fit in with the rest of the world. Instead, he stands convicted by his peers, and his technical talents do little more than cheap gin does to deaden the ever-present feeling of social failure and misery. This type of geek is hard pressed under the burden of the criticism heaped upon him, and he can find little joy in his talents. In a third scenario, the geek flip-flops back and forth between the two poles. Yesterday, he relished the successes that technical talent brought him. Today, he is acutely aware of his lack of standing in the social order. Tomorrow, he will find relief in accomplishments. The day following, he will wish he could have been popular. And so on… This type of geek does manage to keep alive his perspective on life, but his emotional existence feels like a roller-coaster ride. Finally, the fourth scenario involves the geek who tries to balance the positive and negative. With extreme effort, he attempts to counterbalance the good with the bad. He tries to keep his emotions on an even keel. The social lows are few, but so are the technical highs. He does not feel devastated by his defeats, but he rarely can enjoy the exhilaration of conquest. This type of geek is somewhat balanced, but he has had to sacrifice much of his joy to avoid much of his pain. Among these four typical scenarios, some are more desirable than others. But all of the scenarios share the same difficulty: None of them fix the social problems that many geeks face. They are scenarios about coping with pain, but none of them speak to reducing the pain, so that coping is no longer a problem. The real solution to the problem of social pain lies in the creation of geek culture.

07 1989-6 CH04

8/21/00

1:11 PM

Page 51

Chapter 4 • THE KEY TO MANY THINGS: UNDERSTANDING GEEK CULTURE

Consider the nature of the problem. Technical people are often much more focused on working with technology than just about anything else. The social customs of society at large often seem arbitrary and immaterial. Practicing these customs is often uncomfortable and takes time away from really important things like programming and exploring technology. The solution, then, is to either fix the culture or replace it. Since the culture at large does not tend to “fix” easily, creation of a replacement would be in order. This new culture would not actually replace the culture at large, but it would become an alternative culture that the technical person could participate in without fear of social condemnation. Just as alternative cultures sometimes grow up around new genres of music, there would be an alternative culture, the geek culture, that grows up around technology. And, just as the alternative cultures in music often affect the mainstream culture by introducing changes in music, dress, and lifestyle, so the geek culture has begun to affect the culture at large. But rather than dealing with issues of music and fashion, geek culture affects the perception of the technical person in society.

A New Plant with Old Roots Before considering the impact of geek culture on the world at large, let us understand what this culture is and what it provides. At first blush, it may seem like a simple knee-jerk reaction to a society which does not appreciate the geek’s passion for technology. But it is much more than that. The roots of geek culture are actually quite old. There have been many people who have experienced or witnessed small pockets of technical people who seemed to form a bond in certain ideals and behaviors which facilitated their study of technology, but varied from the norms of society. Colleges, universities, and business start-ups have seen the creation of such small technical groups over the years. People in these groups are often marked by a willingness to work incredibly long hours on problems, a strong desire to solve problems, a willingness to share information, and a driving compulsion to learn. Personal appearance and presentation are seen as being of limited importance and sometimes disregarded entirely. You could argue that the roots of geek culture stretch back hundreds of years. For example, the history of Europe recalls many brilliant scientists who dedicated themselves to the discovery of scientific truth, even at the cost of being branded as “odd” or “eccentric” by their own societies. This basic mindset that the pursuit of truth must prevail over less important matters that preoccupy society is clearly alive in modern geek culture. One documented example of this may well be the MIT Artificial Intelligence lab community that Richard M. Stallman talks about in his history of the Free Software Foundation. The FSF Web page, http://www.fsf.org, describes a group of people who built the ITS operating system by openly and freely collaborating with one another. The focus was clearly on the technology, and many social norms apparently took a back seat to the task of building the software. I will leave the final determination of whether my observation is correct to Richard, however, since he knows that experience better than I do.

51

07 1989-6 CH04

52

8/21/00

1:11 PM

Page 52

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

But other examples of geek culture can be seen throughout the history of computing. Apple Computer cofounder Steve Wozniak was a member of the Homebrew Computer Club, a group of geeks who sought to build computers before the age of the PC had dawned. At Apple, Wozniak designed and built the Apple I and Apple II computers, finding great joy in the challenge of it. But when Apple became a major player in the growing personal computer industry, Wozniak chose not to try to ride the wave into greater wealth and fame. Instead, Wozniak left Apple and spent years teaching computing to everyone from teachers to grade school students. Such are the decisions of someone whose priorities diverge from the expected norms. But the phenomenon called geek culture is actually much larger and more complex than any of the instances of small geek groups that have sprouted over time. These groups did accomplish some of the functions of the current geek culture in microcosm, but the depth and impact of today’s geek culture goes far beyond its predecessors.

Ingredients for Making Geek Soup So just what makes up this thing called geek culture? First and foremost, there is a passion for programming and technology. Most geeks genuinely enjoy the act of programming. Spending long hours working through a complex problem is very intellectually satisfying. And the thrill of seeing the completed project work can be a natural high. But the crucial element in the makeup of geek culture is a reorganization of priorities. To construct a culture that represents the sensibilities of geeks, the community reorganized the core values of common society to match the needs of the geeks. It did not represent a “revolutionary” mode of thinking with people discarding outright the central tenets of normal society. Rather, it was a far more subtle effort to simply change the priorities which are placed on certain actions and behaviors. It is also important to note that the adoption of these priorities has been so gradual and so implicit that very few geeks have probably spent much time considering this subject. Indeed, the adjustment of priorities has been done in classic Open Source style: a series of subtle “patches” to geek culture to simply make it work better over time. It was as if the geeks had received a badly functioning culture from the world around them and debugged it slowly over time until it finally worked well. It is important to note that relatively little has been written on the subject of geek culture because of the subtlety of its progression. Geeks such as Richard M. Stallman and Eric S. Raymond have written some highly informative essays on aspects of the free-software and Open Source movements, but the overall volume of work written on the subject is quite small. This is because the creation of geek culture is not the product of some “grand design” by some revolutionary thinkers, but a community effort to make life work better. The surprise inside the rise of geek culture, however, is its impact on the rest of society. We will deal with that subject at the end of this chapter.

07 1989-6 CH04

8/21/00

1:11 PM

Page 53

Chapter 4 • THE KEY TO MANY THINGS: UNDERSTANDING GEEK CULTURE

The Whole Truth and Nothing But the Truth To understand the cultural priorities of the geek, you must keep in mind the appropriate perspective. You must be mindful of the goals of geeks within the culture. Among the highest goals is the continued production of high-quality, Open Source software. It stands to reason, therefore, that the core values of the culture should support the things needed to accomplish that goal. It should not be surprising, then, that one of the key values for the community is truth. In a world where people are constantly exchanging ideas, evaluating concepts, and suggesting enhancements, it is vitally important that everyone speak the truth as he sees it. If someone fails to speak the truth, the process of creating software will be greatly impaired. Now, someone may read this and say, “So what? Many people in normal society want to hear the truth. They do not want to listen to lies any more than the next person does. So what’s the big deal?” In normal society, there is value placed on truth. But frequently the value placed on truth is not as great as the value placed on other things. Take, for example, the relationship of truth to political expediency in American politics. I have known many political constituents who are willing to support a politician whom they know to be a liar, so long as he continues to vote in the legislature in a way that matches their interests. It is clear that for such people, the voting record of the politician is a higher priority than his truthfulness. In the Open Source world, however, you cannot function without truth. The impact of telling lies is devastating to the process of creating software. If someone in charge of a piece of code willingly lies about how the code functions to other developers seeking to use that code, that person has caused great harm. Someone who lies to a development team could cost that team hundreds or even thousands of wasted hours of development. In that case, the liar has caused numerous individuals to waste precious hours of time chasing down a dead-end road. In a business setting, when someone misleads another project team, there is anger over time wasted and schedules that slip as a result. The issue of lying is (perhaps) escalated to management who will (hopefully) address the issue with the perpetrator and correct the situation so it does not happen again. But, at the end of the day, the corporate programmer still receives his pay check. So, even though there has been a loss of time, there is still some compensation for the time that has been expended. This is not normally the case in the Open Source world. As most Open Source programmers today are using their personal spare time to develop programs, the developer who wastes time over the lie of another is deeply affected. Since the main reward of the geek is often seeing his project completed and in use, he has been robbed of his compensation by the efforts of the liar. His time, for which he probably received no paycheck, is gone. The reward of seeing the code in use cannot be realized if the code has been designed to a specification which was incorrect.

53

07 1989-6 CH04

54

8/21/00

1:11 PM

Page 54

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Also, consider the lack of centralized management to discipline the liar. In the Open Source world, no one wields the might of an executive in the corporate world to order that an individual act appropriately or be removed from the company forever. Something different must be done to correct the actions of liars. The solution to this problem is found in the primacy of truth in geek culture. As lying is a horrible offense in the Open Source world, it is not tolerated. To be accused of lying is to suffer a serious blow to the reputation. And, as reputation is the key to many things in the Open Source world (which we will discuss presently), a person known to be a liar will find himself unwelcome in most projects. He will often be restricted from participating in most projects because of his damaged reputation. After all, who wants to risk losing his geek compensation (that is, seeing his project come into use) because of the work of a liar? But this emphasis on truth raises other questions as well. For instance, what happens if someone says something that is not true, but he was not actually lying? If someone makes an honest mistake and says something is true when it is not, what happens? Will he be ostracized like the liar was? Does this not place a terrible burden on the speaker when he says things? In the Open Source world, it is critical that false statements be exposed for the protection of the process of developing solid Open Source software. Hence, when someone innocently makes a mistake and says something that he believed was true when it was not so, one of two things should occur. If no one has challenged his errant statement, he should take the initiative to correct it in the exact same forum in which he made it (if at all possible). If someone has challenged the validity of his statement, he must admit his honest mistake to his accusers as well as in whatever forum he made his unknowingly false statement. For example, in an Internet mailing list, someone asks whether the Flibgib networking protocol is implemented under Linux. Joe Hacker responds and says, “I believe it appears in kernel version 2.2.” But someone else responds and says, “I saw an email from Linus last week and he said that support for that protocol is not even in the development kernel yet.” It is the responsibility of the person who made the mistake to speak up again on the mailing list and admit the error. “Gee, I thought I saw that Flibgib was listed in the supported protocols under 2.2. I guess I was wrong.” This action shows that he is not a liar. He made a mistake and admitted it. Depending on the seriousness of error made, he might take some ribbing or even some pointed comments from people about his actions. But, in the end, the error is forgiven and the event forgotten. The need to forgive honest mistakes is also a necessity in the community. Very few programmers are capable of writing code that is bug-free the moment it is typed in. This means that essentially everyone in the community has had the experience of inadvertently making mistakes while programming. So, if honest programming mistakes can and must be forgiven, it is clear that honest mistakes outside of programming must also be met with due grace.

It’s Not Who You Know, It’s What You Do In a culture that does not rely on titles, awards, or paychecks to provide rank within the society, another method of recognizing someone’s performance must be established. It is essential

07 1989-6 CH04

8/21/00

1:11 PM

Page 55

Chapter 4 • THE KEY TO MANY THINGS: UNDERSTANDING GEEK CULTURE

that key people are elevated in some manner. In geek culture, this is accomplished through the building of reputation. Reputation is built through accomplishment, not association. The fact that I might know or have worked with someone of good reputation does not increase my reputation. The only way to increase reputation is by giving something of value to the community. Eric S. Raymond wrote a landmark series of papers about the Open Source community, which have been published as a book under the title The Cathedral and the Bazaar. In his work, Eric compares the Open Source community to an anthropological gift community. In certain cultures where food, shelter, and clothing are not scarce, reputation is obtained by giving excellent gifts to other members of the community. And even among the very wealthy in Western cultures, reputation is built by giving lavish parties for peers and for constructing charitable foundations to assist those who are less fortunate. Eric’s observation that a similar method of building reputation is at work within the Open Source community is right on the mark. The Open Source world rises and falls on the back of the people involved. The people who give the most valuable gifts to the community are held in highest esteem. And, since the gifts valued most by the community are not money, title, education, or management authority, everyone is free to pursue an excellent reputation. Within the geek culture, acceptable contributions to the community include such things as programming, design, team leadership, debugging, writing of books and articles, advocacy, and documentation. But, unlike the common culture, the greatest contributions are not automatically those associated with management tasks. The people who establish the best reputations are generally those who can point to a substantial amount of code that they have contributed to the community. It is not coincidental that many of the most celebrated contributors also happen to be in leadership positions. But many of them rose to those positions because they had a passion for the project and were contributing large amounts of programming time to the effort. In fact, many of the most famous people began the projects for which they are best known, which means that they are not merely managers, but are hard-core contributors of code. This is a important change in priorities that geek culture made against the norms of standard culture. The community values a hard-working hacker much more highly than a vice president of a Fortune 50 corporation. While members of the community will normally be quite cordial to an executive from a major company, they will be enthralled with the prolific hacker. And, as we will discuss later, the top executive had better be prepared to answer tough questions if his company is mouthing Open Source support but not delivering in substance. This is one instance where the need for truth will win out over “good manners” every time.

The Fame Game The priority placed on reputation naturally leads to the issue of fame. In geek culture, fame is obtainable by being a geek. This is in direct opposition to common culture where being a geek will practically ensure that you will never be famous. But, in geek culture, the folks who are the geekiest geeks are held in highest esteem.

55

07 1989-6 CH04

56

8/21/00

1:11 PM

Page 56

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Someone might think that fame in the geek world is some form of consolation prize for those who cannot earn fame in the world at large. But consider the nature of fame in common society. Who generally achieves fame? Handsome men and beautiful women always seem to lead the pack of the famous. But what have they accomplished in their lives to justify their fame? Often they have achieved stardom based on skills in acting, music, or sports. But somehow, people in those professions who are attractive seem to gain more fame than those with equal talent, but lesser looks. In fact, the music industry in particular is filled with stories of singers and musicians who work unheralded in the background to help a mediocre front person who might lack talent but has “the look” needed to be a star. Faced with this emphasis on form over content, geek culture rebels from the societal norm. Considering the emphasis on truth, the only fair judge for fame in geek culture is reputation, since reputation derives directly from accomplishment. So those who gain fame in the Open Source world are those who have given the most to the community. Fame in the geek world is based on earned merit. A pleasant appearance means little or nothing in the geek world. A culture that tends to interact via electronic means, often without benefit of a video signal, would naturally not stress the importance of appearance. It is common for geeks to work together in the community for years before even seeing what the other looks like. So, given the emphasis on truth and the absence of appearance, it is natural for geek fame to value content over form. And, strange as it may seem to some people, geek fame is not a consolation prize for those who were not “pretty” enough to make the grade in the common culture. Geek fame is a badge of high honor. And most geeks would rather be famous in the geek culture, where their fame is based on what they have earned, than in the common culture, where fame is more arbitrary and fleeting. Consider a comparison of geek fame to special award programs used by some companies. Some companies have special incentive programs designed to encourage people to become top performers. They select their top people to receive a reward of some form, meant to provide special incentive for people to do good work. A frequent problem with this type of award is that selection is based as much on the whim of managers as it is on accomplishment. Even award systems that some managers brag about as being fair often draw grumbles from the technical people for being overly political and subjective. Geek fame, however, is something that is not bestowed on an individual by the direction of a leader. It is based on a fluid consensus of the community. It is not a hurdle to be achieved as much as it is an awareness of contribution in the community. It is the community itself recognizing that a given individual has done much for the welfare of the body at large.

Freedom to Choose Another cherished priority in geek culture is the ability of the geek to pursue her passions and ideas. Most people working in the software industry are assigned to projects by their bosses. In geek culture as well, people are often willing to take on tasks that need to be done, even if it is a task they do not relish the thought of pursuing. But geek culture recognizes that there are

07 1989-6 CH04

8/21/00

1:11 PM

Page 57

Chapter 4 • THE KEY TO MANY THINGS: UNDERSTANDING GEEK CULTURE

also tasks that need to be done not because a project requires it, but because the task is burning in the heart and mind of the geek. Like an artist who stands before a blank canvas and suddenly knows precisely what he must paint, a geek can be inspired to create software that must be written. The software might not have anything to do with the current commercial project on which she is supposed to be working. The fact that she feels a need to write it is reason enough to let her do so. Remember that in Open Source, there is no one to say, “No, you may not pursue that idea.” A developer is free to follow her passion and then be judged on her results. A common concern from outside the community arises from this desire for the freedom to choose projects. Analysts sometimes claim that the Open Source movement will inevitably fail to address the issues that are necessary for complete solutions because people select their own assignments. These analysts claim that much of the software in use by corporations is far too mundane to be intellectually stimulating for the Open Source community. As such, they claim, no developers will arise to actually do the job. While this analysis does well in raising the question, “Who will do the mundane tasks?” it ignores certain facts. While it is true that certain jobs (like kernel development) are considered “sexy” and interesting by the culture, that does not mean that everyone will rush to those jobs and that no one will bother to do the drudge work. There are three main safeguards against this scenario: First, different programmers find different things interesting. While one person finds writing a video device driver to be absolute heaven, another may find it painful. The latter geek might find creating a word processing package intensely exciting, while the former might see that task as a journey into the land of total anguish. The size of the community and diversity of its members assures that a variety of tasks will be addressed. Indeed, part of the unspoken wisdom of the geek culture is the realization that a job is best done by someone who is interested in doing it. A developer who genuinely wants to attack a particular problem has a strong motivation to do the job well. Therefore, it is wise to let a problem be handled by someone who wants to do the job. The second safeguard against people neglecting issues in software is the motivation that arises from need. Developers who need specific problems addressed are frequently motivated to either address the problem themselves or encourage others to address the issue. While need for software may not be as pleasant a motivator as an artistic desire to create software, it is a potent motivator nonetheless. The old saying, “Necessity is the mother of invention” is just as true today as it was in ages past. Finally, the third safeguard against important software issues remaining unaddressed is the fact that a large number of geeks understand what it is to have a professional attitude. Just because a geek is engaged in Open Source development does not mean that he is unwilling to do jobs that he would normally be paid to do. Every programmer worth his salt understands that there are certain times in programming when the work can turn tedious. Tasks inevitably arise that are not particularly interesting but are vitally important nonetheless. A programmer of a professional mind understands that these tasks must not be ignored. Freedom to choose a task

57

07 1989-6 CH04

58

8/21/00

1:11 PM

Page 58

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

does not negate the responsibility to do what is needed. That lesson is not lost on the most mature members of the community.

Open Source Requires Open Mouths As mentioned in Chapter 1, “What’s Going On Here?” bidirectional communication is needed to work at Internet speed. Open Source development requires solid bidirectional communication to work properly. So it should come as a shock to no one that geek culture sees this model of communication as essential. Society in general has largely functioned on the implicit premise that some people have acquired the right to communicate more loudly and more widely than others. The people with the greatest right to be heard are those who have risen to the highest positions in leadership. And the people with the least right to be heard are those at the bottom of the ladder. For instance, a corporate CEO may send a directive to the entire corporation with a push of a button. But a mailroom clerk may be prohibited from doing likewise unless he enlists the support of a suitably high-placed executive. It is assumed by position that the words of the CEO are far-reaching in scope and should be heard by everyone in the corporation. He is, after all, the CEO. But the clerk in the mailroom should be concerned with mailroom issues, according to his position. So any idea he might have that affects the entire corporation needs to travel up the management chain, passing management review at each step. If the idea is deemed worthy by each manager in the chain, it will arrive on the desk of an executive who will decide whether it warrants action. From the mindset of a traditional corporation, the differing abilities of the CEO and mail clerk to address the entire corporation are understandable. The hierarchy is clearly defined and often deeply ingrained in the functioning of the organization. In this very common management structure, it is expected that communication will flow much more readily from top to bottom than it does from bottom to top. But this type of structure does not exist in the Open Source world. Although there are team leaders who decide which code is ready for inclusion into a project, there are no executives who determine the direction for the entire community. There is no CEO who decides which problems Open Source will or will not tackle. Instead, the Open Source model is based on the assumption that if enough people consider a problem, there will be someone for whom the solution will be both clear and elegant. This is the principle that Eric S. Raymond calls, “Given enough eyes, all bugs are shallow.” If this method is to work, then it is obvious that everyone looking at a problem must have the ability to make his solution known to the team. It stands to reason, then, that geek culture would adopt a model of communication that would not only allow people to contact each other without red tape and restrictions, but it would encourage people to contact the right person when needed. So geek culture has no concept of someone being “unworthy” to contact someone else.

07 1989-6 CH04

8/21/00

1:11 PM

Page 59

Chapter 4 • THE KEY TO MANY THINGS: UNDERSTANDING GEEK CULTURE

There are occasionally rules of access implemented for much more pragmatic reasons. A common example is a development team that asks that bug reports be submitted through a form on a particular Web page instead of by simply sending email to one of the developers. This procedural change allows the development team to track bug reports more efficiently and reduces the amount of email that they need to sort through every day. But access to developers is not actually restricted. Much to the contrary, the method of communication is made more efficient so that the communication will be more effective.

Let Freedom Ring As expected, one of the premier priorities of geek culture is a dedication to openness and freedom. The desire to create strong software that is available to everyone runs hot in the culture. That desire occasionally runs even wider into other places where the concept of intellectual property keeps important information out of the hands of people who need it. But although this commitment runs hot and wide in the community, it runs deeper in some people than in others. The nominal dividing line stands between the free-software movement and the Open Source movement. The geeks in both groups believe in creating software that is available to everyone, complete with source code. They work hard to make the software come about and actively and passionately promote the use of such software. But the geeks who tend to identify themselves with the free-software movement often carry the commitment to the ideal of freedom even farther. As mentioned earlier, the Free Software Foundation considers the production of closed, proprietary software to be immoral. The geeks who align themselves with the free-software movement, as opposed to the Open Source movement, tend to agree with that tenet of the FSF. This difference tends to be most apparent in public forums where commercial software is discussed. While the members of the Open Source community are often happy to find commercial software companies embracing free operating systems like Linux and FreeBSD, the members of the free-software movement are often unmoved. They are not happy with the presence of commercial software anywhere, and so they will not embrace companies that produce closed proprietary software, regardless of operating system platform. In fact, it is common to hear members of the free-software movement tell executives of proprietary software companies that their company is doing wrong by keeping the software closed and proprietary. This can be unsettling for some people to hear, since such accusations are often considered rude by many people in the common culture. But, in geek culture, truthfulness must win out over gentility every time.

These Uncivilized Brutes This raises another question: Where do rules of civility fit into the puzzle? After all, geeks are sometimes characterized by common society as being abrupt or rude, lacking in necessary social graces. Many people suggest they need to become more civilized in order to work in society.

59

07 1989-6 CH04

60

8/21/00

1:11 PM

Page 60

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

However, the issue is not that geeks lack knowledge of “civilized behavior.” The issue is that geek culture does not value “civilized behavior” as highly as some other virtues. In particular, the emphasis on telling the truth takes clear precedence over any desire to say things in a gentle manner. Remember that the need to tell the truth is absolutely essential in geek culture. A civil tongue is useful when it can express truth fully and accurately. But, in the eyes of many in geek culture, if civility attempts to trim the rough edges off truth, it must be sacrificed to keep the truth intact. The details of this exchange will be discussed more fully in Chapter 6, “Primary Community Value: Truth.”

Why Geek Culture Is the Key to Many Things So where do all these priorities lead us? Geek culture takes the values described in this chapter (and more not discussed here) and raises them to the levels required to effectively develop excellent Open Source software. It also builds a cultural framework that allows a geek to excel without being bombarded with feelings of inferiority and failure that standard society tries to heap on her. The weaknesses and failings that society at large considers essential become far less important in geek culture. The primary values—truth, freedom, open communication, opportunity to follow your heart—create a potent mixture that translates to an opportunity for geeks to succeed in the world and feel good about themselves. Indeed, geek culture is the great enabler for positive self-esteem, personal success, and the opportunity to achieve fame. Thanks to the function of geek culture, people who formerly flipflopped between feelings of success and failure now have the opportunity of tasting success on its own. Where they were once condemned to be socially insufficient, they now find the opportunity to prove themselves. Where they were formerly judged to be lacking before they began, they now find the freedom to be judged according to their efforts. In geek culture, many technical people find a level playing field for the first time in their lives. They no longer feel handicapped from the start because they have a different sense of what is important in life. Not only do they have a chance to win the game of life, they have a chance to enjoy playing it. Geek culture breathes life into many people who suffered at the hands of society at large. And this is precisely why this subject is so incredibly essential to understand. Businesses that try to woo Open Source people without understanding the importance of the geek culture are doomed to leave great successes unrealized. As geek culture gives a geek the ability to succeed in a system that reflects his values, a company that ignores geek culture is likely to keep its technical people from doing their best work and realizing success. A wisely run organization will find ways to let their technical people participate in geek culture, as we will discuss in Chapter 11, “The Primer: What To Do.”

07 1989-6 CH04

8/21/00

1:11 PM

Page 61

Chapter 4 • THE KEY TO MANY THINGS: UNDERSTANDING GEEK CULTURE

The Geeks Are Knocking at the Door But the least apparent result of geek culture is the fact that it has begun to affect popular culture. In the same way that the Internet has revolutionized communications and reshaped the platform for commerce, geek culture has begun nibbling at the edges of general society. In some cases, it pushes along reactions to failures of the social system. In other cases, it helps along tendencies toward nontraditional thinking. The Web has proven that two-way communication is essential and is here to stay. As the greater world participates in the same discussions that Open Source aficionados populate, the call for free and open discussion strikes chords with the population at large. The “fact of life” that some people have more right to speak to the public than others is challenged. The geek love of truth is also beginning to invade society at large. In areas like politics and marketing where lies and half-truths have gone virtually unchecked for so long, people are beginning to speak out. Individuals are no longer waiting for “someone to do something”; they are beginning to speak out on their own. The falsehoods told by the powerful are now beginning to be questioned. People are beginning to indicate an unwillingness to listen to any more tales. They want truth. And they are being helped along by the geek culture’s call for truth that is everywhere evident on the Internet. Likewise, the stories about the success of major Open Source efforts like Linux have begun to echo in the halls of corporations and school buildings alike. People begin asking themselves, “if this group can achieve so much without the aid of corporate backing, why can’t I?” The established confines of what an individual or group can do are suddenly under question. Suddenly, the sky is the limit. The rise of geek fame is also having an effect on the broader world. The creation of a large, visible, worldwide society where people achieve status through actions, rather than beauty or wealth or politics, is earth-shattering to many cultures. The concept that a measure of real fame is not out of reach for anyone who is willing to work for it is mind-boggling. This is especially true among the legions of computer programmers worldwide. Anyone who has ever spent years studying for a career in computers can tell you that fame is extremely rare in this field. People who want fame are drawn to dreams of movie stardom, athletic prowess, modeling, or even becoming a CEO of a major corporation. But people who work with computers have not had sight of a clear path that led to fame—until now. For the first time in history, programmers are becoming far more visible in the eyes of the world at large. In an Internet world where storefronts of brick and mortar are giving way to ecommerce Web pages, the role of computer people is becoming much more visible. Suddenly, having access to talented people who design and implement the Web store is now a necessity. As the computer is now a profit center, computer people are now the virtual sales staff. They provide the flash and glitz that is required to bring in revenue. As a result, geeks are becoming “sexy” in the eyes of many businesses.

61

07 1989-6 CH04

62

8/21/00

1:11 PM

Page 62

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The net result is this: The geeks who have been criticized by elements in society for so long are now taking control of their lives. They have found self-esteem. They have found a level playing field. They have found a desire to change the world. And they have found a spirit to win. Geeks have begun changing their status from outcasts to stars in their own right. They have built a culture which reflects their own values and priorities, and they are fighting to infect society at large with their convictions. The impact of this culture on the century ahead of them remains to be seen, but only the most ill-informed analyst would dare treat geek culture as an unimportant force in the years to come.

08 1989-6 CH05

8/21/00

1:13 PM

Page 63

CHAPTER 5

COMMUNITY, NOT COMMUNISM

S

ome people look at the Open Source movement and complain that it resembles some form of commune. People are sharing code. There does not seem to be a notion of personal property (with respect to code, at least). And these free software people keep talking about the evils of corporations that create closed proprietary software. To some people outside the movement, this sounds like some adaptation of communist thinking to the world of programming. Although there may be superficial elements that might appear to resemble some things found in communist states, the whole is not a model of communism. In fact, the political and economic biases tend to be quite varied among the members of the Open Source world. It is not unusual to hear these various biases occasionally mentioned during electronic discussions. But these political slants are entirely secondary in Open Source. They are treated by the community the same way the corporate world treats discussions of hobbies: Discussion of them is fine as long as it does not get in the way of getting the job done, but they have no bearing on the task at hand. Rather than exemplifying some new form of communism, the Open Source world is a model based on the scientific community. Instead of embodying some political or economic ideal, the Open Source community is the result of some basic philosophy and simple pragmatism applied to the task at hand. The focus is not on making others think and act like the geeks; rather, it is on allowing geeks to produce what the world needs.

Size Really Does Matter Something that people new to the world of Open Source (usually called newbies) sometimes fail to appreciate is the sheer size and impact of the community. Most people have become aware of small pockets of geeks that might congregate in a university computer lab or a business data center. The group may get along well with each other, but the group is usually quite small with little actual impact on the organization around it. A common mistake made by people on the outside is to dismiss the Open Source community as just a slightly larger, but essentially inconsequential, group of geeks. Nothing could be farther from the truth. First, the community is big. Really big. How big? It is impossible to come up with absolute figures, but the number of programmers whose names appear in software contained in any Linux distribution is well into the thousands. Add to those authors the

08 1989-6 CH05

64

8/21/00

1:13 PM

Page 64

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

thousands more who have debugged and submitted patches for code. Many of these have isolated problems and suggested solutions, but their names may not appear attached to any particular program. And now add to that thousands more of the technical users who have used the code and identified problems. Sometimes people say, “All this is well and good, but this group of hackers can’t possibly compete with some of the huge commercial software companies in the world. After all, what can a group of volunteers hope to do when faced with the giants of the software industry? These companies have thousands of employees and millions of dollars to spend to further their businesses. This group of hackers doesn’t even have a budget! How can this geek community even hope to compete?” The truth of the matter is quite different. Commercial software companies have thousands of highly compensated employees. The Open Source community has tens of thousands of highly motivated software developers. Commercial software companies have millions of dollars to spend on development. The Open Source community has an unlimited budget; there is no point in time when someone will say “We can’t afford to do this.” But the real topper is this: The Open Source community is growing each and every day in every country on the planet at rates that no commercial developer can possibly match. For example, IDC reported that the number of Linux servers shipped in 1997 was trivial. By 1999, however, Linux server shipments swelled to become the second most popular in the United States1. Every day, more and more talented programmers from every corner of the world join the community. And many countries that are only now beginning to develop their own programmers are beginning to do so on Open Source platforms by using Open Source code for examples and Open Source programming techniques. Many of these countries, like India and China2, like the concept of controlling their own technical destiny by having their own people work on the software which will become the backbone of their computer infrastructure. The Open Source community only began to reach critical mass in the mid-1990s. Compared to most large commercial software entities, the Open Source community is the new kid on the block. The community, then, works hard at catching up with the products that the commercial world has already developed. But some outsiders mistake this catch-up activity for a lack of creativity. Several analysts over the years have proclaimed that the focus on creating Open Source equivalents to closed-source applications demonstrates that the community is largely devoid of creative spirit. This allegation used to make many Open Source people laugh at the absurdity of the claim. The Open Source movement could never have progressed to its current stage without having a dedicated group of highly creative people. And, as the community moves swiftly to re-create the applications that closed source already has, more and more people begin to break new creative ground. 1. http://www.infoworld.com/articles/pi/xml/00/02/11/000211pilinmarket.xml 2. http://linuxtoday.com/news_story.php3?ltsn=2000-06-30-005-04-PS-CY http://www.idg.net/idgns/2000/04/05/LinuxFavoredByAsiasDevelopingNations.shtml

08 1989-6 CH05

8/21/00

1:13 PM

Page 65

Chapter 5 • COMMUNITY, NOT COMMUNISM

It Is Good to Work, But It Is Better to Grow A key element behind the fact that the Open Source world could move so swiftly to produce so many applications in so short a period of time is the size of the community. But the community was not always so large or so proficient. What happened to cause this? As mentioned in Chapter 2, “How Did All This Start?” the Free Software Foundation under the guidance of Richard Stallman has been laboring since 1984 toward creating free software, including a free operating system. In the 1980s, many people knew of Stallman’s desires, but relatively few programmers were involved in the effort. Among computer professionals, the Free Software Foundation was often characterized as a group of radical idealists. But something happened to change the perception that the task of creating free software was for extreme idealists. In 1991, Linus Torvalds began his work on the Linux kernel, which when combined with the work done by the FSF and other free software developers, eventually yielded a working free operating system. Although this accomplishment is often heralded as a great achievement in the history of free software, an equally great accomplishment is often overlooked entirely. Linus brought free software to the attention of the world. But how did this happen? Some people make the mistake of believing that this is due to the fact that the existence of a good free kernel made the free operating system usable. They claim that although the GNU project was only a set of utility programs, it was not “sexy” enough to warrant the attention of many technical people. But, with the appearance of the Linux kernel, the resultant coupling of Linux and GNU made a workable system which finally began to attract the attention of the computing world. The argument is that when the code became reasonably complete, the explosion of interest was essentially inevitable. This perspective—often heard on the lips of people in the free-software movement—misses one absolutely essential ingredient: the reason for the blossoming of the community. The assumption is that the functionality of the code, perhaps coupled with the liberating concept of free software, was sufficient to build the community which has been responsible for the dramatic rise in free software. The community’s growth must have been due to the excitement over working code and dedication to the concept of free software. But this is not the case. Although community growth certainly was aided by functional code, and certain members of the community were attracted by the concept of free software, the coupling of these elements is insufficient to explain the dramatic increase in size of the community during the 1990s. In many ways, the community began growing as the most positive elements of geek culture began to flower. And the person who did the most watering was Linus Torvalds. When Linus Torvalds began leading the Linux project in 1991, he set a stage that would be ready for community growth. He employed a few simple elements that would cause people to gravitate to the work. And he removed barriers that had repelled some people from working toward free software.

65

08 1989-6 CH05

66

8/21/00

1:13 PM

Page 66

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The ingredients employed by Torvalds are so simple that they are often taken for granted by observers who seek to understand the Open Source community. The elements are clearly a product of some common sense applied to knowledge of how geeks think. Yet it was these simple ingredients which would launch the community into a worldwide force capable of developing immense amounts of high-quality free software over a relatively short period of time.

Open Development Cycle First among the ingredients is openness of the development cycle. In this model, important design decisions are discussed in public forums before their implementation begins. Everyone is given the opportunity to see the code as it is developed. People examining the developer’s release of the code will see new portions as they come into being. The new portions may be badly broken with some new routines missing entirely. The code may not be complete enough to make it through the computer language compiler without generating show-stopping errors. But that is precisely the beauty of the thing. Other developers can see new, complex code often before it works. This means that the community can see precisely how things are implemented as they are being implemented. It gives the community the opportunity to discuss the merits of using one type of implementation rather than another before anything has been cast in stone. This simple method of providing for ongoing peer review helps to solve problems before they occur. It means that the many eyes of the community can examine things early in the cycle, so many bugs and potential flaws can be handled before new portions of code become too big to be changed easily. Prior to the beginning of the Linux project, many free-software efforts varied considerably on the openness of the development cycle. Often times, free software was produced much like closed software, where the users only received the code when it was already working (for the most part). Eric Raymond’s The Cathedral and the Bazaar describes how the development of the core of the GNU Emacs project fit this model. The open method of access during coding used by the Linux project, however, raised the bar for accessibility to the code during development. An example of this is the Linux kernel-development model. At any time, there are two trees available: one stable and one in development. New software capabilities are introduced into the development tree. When the code has been thoroughly tested and integrated into the development tree, it might be integrated into the stable tree. Eventually, the entire development tree is stabilized and it becomes the basis of a new stable tree. If someone looks at the development version of the code, they will often find unfinished segments of code, routines needing debugging, or gutless prototypes of routines that need to be written but are not yet in place. The availability of such unfinished work allows other people to point out potential flaws in the implementation strategy before it is completed.

Open Development Team A second key ingredient used by Linus is inclusion. People from across the world, regardless of status, may examine the code and submit patches. In some other free-software development

08 1989-6 CH05

8/21/00

1:13 PM

Page 67

Chapter 5 • COMMUNITY, NOT COMMUNISM

efforts, the development team was a fairly closed group. A person outside of the team was free to submit patches, but there was a distinct difference between a developer raising an issue and someone outside raising the same issue. There was a line drawn between developers and users. Under Torvalds’ leadership, however, the line between developer and user blurred. Certainly, a core group of developers was relied on to handle certain tasks. But the people outside the core group were also seen as valued contributors to the success of the project. When those outside of the core group made suggestions and submissions, they found that their voices were heard. This meant that anyone with the desire and talent to try to contribute to the effort was free to do so. And, by contributing, each of these people could develop a sense of ownership for the project. There was no longer a line between the developer and the onlooker. Instead, the community itself began to feel ownership of the project.

Let the Best Code Win The free-software teams which tended toward closed development groups often seemed to prefer code written by core developers over that submitted by those outside. And, even if that was not the case in actuality, the appearance that it was so was discouraging to those who wanted to contribute. As a player in a game may become discouraged when the rules seem stacked against him, so many of these outsiders began to feel that it almost was not worth submitting code when the work of insiders seemed to be preferred. But, in the Linux development model, the technical mantra “Let the best code win” ruled the day. It did not matter if the submitter was a core developer or someone who had just begun to look at the code. The only measuring rod used to evaluate submissions was the question, “Is this the best solution to the problem?” This meant that anyone—absolutely anyone—could contribute something of value. The task was to create the best solution possible, and that meant that anyone with a good idea was free to try his hand at contributing to the best solution. The enthusiasm this generated over time is inestimable. It created a totally level playing field for geeks to compete. It also meant that those who succeeded in having code accepted into the project were enthralled by the success. Geeks who had wanted for years to be appreciated for their technical expertise suddenly had an outlet that electrified them. There were no social norms to uphold. There were no office politics to endure. They could simply contribute on the basis of their long suit—a deep knowledge of programming—and be appreciated for those contributions.

Fast Turnaround A fourth ingredient is exceptional speed in turnaround. During the early years of Linux kernel development, it was not unusual for Linus to post a new kernel every day—or even more frequently. This meant that people who submitted acceptable patches would often see their code appear in the project within days or hours of submission. This created a tremendously strong positive feedback loop in the development cycle. Since people quickly realized that their contributions were accepted and used, they began to work all that much harder. They felt the gratification of success in real time.

67

08 1989-6 CH05

68

8/21/00

1:13 PM

Page 68

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

In some other projects, successful patch submissions might not appear in the project’s code base for weeks or months. Those projects which used an old-style release cycle of closed development followed by a release of working code did not provide the immediate positive feedback that the Linux project did.

Open Praise A fifth element is open praise. As basic and simplistic as it might seem, not all projects bothered to give public credit for people who contributed code. Without praise, a programmer might feel gratified that his work was deemed good enough to be accepted into a project. But the lack of credit could leave a lingering sense that appreciation could have been greater. The willingness of Linus Torvalds to acknowledge the contributions of others by name in public ways was very important to ensuring the success of Linux. The presence of public praise meant that there was a concrete reward for submitting quality code and ideas. It was an honest level of appreciation that geeks had often longed for but never found.

Simple Philosophy A sixth element is an implicit and pragmatic philosophy. Although often attacked by people in the free-software movement, the simple pragmatism of Linus Torvalds made the subject of free software less a matter of moral imperatives than a issue of practical preferences. The members of the free-software movement often expound on the need to have all software free. All software should be available in source code, for anyone to use or modify, and modifications must remain free as well. Anything less than that is not truly free, and anyone who does not ascribe to all those tenets is not fit to stand as champion of the free-software movement. Torvalds, however, has not made an issue insisting that all software must be free. Rather, he and his followers have taken a much simpler view: If you create excellent free software, the closed proprietary packages will fail to survive. The task then is not to convince people of the moral imperative that all software must be free, but rather to use the combined strength of the community to make sure that the free packages are superior and preferable to their closed counterparts. The difference in philosophy has had an extremely important effect on the growth of the community. The statement that “all software must be free” is too extreme for most people to embrace. But the notion that free software is a better alternative than proprietary software is a very attractive idea. People have shown themselves willing to work toward creating a superior alternative that is available to everyone. The difference in philosophy is also a boundary marker between the free-software movement and the Open Source movement. The free-software movement sticks to its basic concept that free software is a moral imperative, whereas the Open Source movement does not insist on making that claim. The Open Source community tends to work with a “big tent” concept: It counts the free software people as part of its ranks, even if the free software people do not include the Open Source people in their numbers.

08 1989-6 CH05

8/21/00

1:13 PM

Page 69

Chapter 5 • COMMUNITY, NOT COMMUNISM

Still, both the free software people and the Open Source people work side by side creating software. The resulting software and licensing tend to be indistinguishable from one another, with the exception that the free software people tend to use GNU licenses almost exclusively, whereas Open Source efforts will sometimes employ a different licensing scheme. The major differences between the Open Source and free software people tend to arise during discussions rather than in code. But the difference in philosophy has been a profound aid to the growth of the Open Source movement. And I suspect the philosophical change has actually benefited the free software people as well, since the popularity of Open Source has given them a pulpit from which they may seek to teach people about their position.

Fun The final ingredient is fun, the one ingredient that people tend to overlook entirely. And, as the Open Source movement grows into the areas of business, it is the one ingredient that needs to be labeled as an endangered species. From the start of his work, Linus Torvalds has repeatedly said that Linux should be fun. It is not a drudgery to endure. It is not even a great moral cause (as the free software people might contend) It is simply a way to produce better software that would be available to everyone and that people could actually enjoy writing and using. And, in this, Linus succeeded wildly. Back in 1997, I attended one of the early Linux conferences, the Atlanta Linux Showcase. As Linux was still not very well known in business, the show was quite small. About 500 people gathered on a weekend to attend technical seminars and hear addresses from several people, including Eric Raymond, Jon “maddog” Hall, and even Linus Torvalds himself. Perhaps 20 vendors occupied the exhibit floor outside of the conference rooms. From a statistical viewpoint, the conference was immaterial. In an era when big computer trade shows would find tens of thousands of people wandering through exhibit halls that spanned multiple buildings, the gathering of 500 people and 20 vendors in three rooms in Atlanta was inconsequential. But the important difference about this show does not appear in the statistics. The people in attendance were different from those at normal computer shows. They did not show up because their bosses told them to go. They did not attend because they wanted a day off from work (the show was on a weekend, after all). They did not even show up to get freebies and trinkets from the vendors (there were only a few giveaways). No, the people came because they wanted to be there. They came because they wanted to attend the technical sessions. They came to hear people like Linus, Eric, and maddog speak. And, most of all, they came because it was fun. I could see it in the faces. I could hear it in their voices. These folks were having a grand time! They were enjoying every minute of it! They were having fun. The fact that geeks from across the world could work at Linux and have fun while doing so increased the popularity of the Open Source community. Tasks are always easier to do when you enjoy doing them. And the simple truth of this was quite apparent in the early years of the community.

69

08 1989-6 CH05

70

8/21/00

1:13 PM

Page 70

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

As work progressed, the corporate world began to take an interest in the movement. Many in the community were overjoyed with the growing recognition by business that these projects were producing some truly useful software. But some were afraid that the business world would change the community if the community did not remind itself of its core values. The community has fought hard to remember its core values. It has fought off the temptation to lose its unique identity. But the sense of fun seems to be waning somewhat under the stress of IPOs, market caps, and business plans. Fun has not disappeared from the map, but it seems that the routes to it are not used nearly as much these days.

Soup Is On! The combination of these key elements—an open development cycle, an open development team, fairness, fast turnaround, praise, a simple philosophy, and fun—make a potent recipe for a growing community. These ingredients among others helped propel the community from a relatively small bunch of idealists into a large body of motivated Open Source developers.

A Community That Explodes the Myth of the Anti-Social Geek Perhaps one of the most worrisome and tiresome stereotypes in modern society is the portrayal of geeks as antisocial individualists. In this sad age where the evening news seems cursed all too often with gut-wrenching reports of teenagers who have somehow snapped and harmed classmates or teachers, the dreadful stereotypes about geeks seem to live on in spite of fact and reason. It seems that just minutes after every one of these tragic episodes, a wild flurry of “experts” appear in the popular media trying to explain what happened. These accusations seem to hover around the old stereotype of geeks as antisocial people. As discussed at length in Chapter 4, “Understanding Geek Culture,” nothing could be farther from the truth. In fact, geeks are quite social. They just have a different sense of priorities. But having a different sense of priorities is a far cry from being a social miscreant. In fact, the community uses a number of ways to socially connect with each other. Many of them are basic tools of the Internet, such as email, Internet Relay Chat (IRC), mailing lists, and Web-based forums. Others are community news and discussion sites like Slashdot and Linux Today. But the most personal methods of socializing concern user group meetings. Especially prevalent in the Linux community, where they are called LUGs (for Linux Users Groups), user groups are local bands of people who come together periodically to talk about subjects pertaining to Open Source software. Naturally, the content and frequency of these meetings varies according to the wishes of the attendees. But many of them feature installfests, which are events where people can bring in their computers and have the local experts install Open Source software on them. Out of these local user groups occasionally grow larger technical conferences. Unlike many computer shows where the vendor-filled exposition floor is considered the center attraction,

08 1989-6 CH05

8/21/00

1:13 PM

Page 71

Chapter 5 • COMMUNITY, NOT COMMUNISM

these technical conferences focus on producing high-quality technical seminars for geeks to hear about various Open Source technologies. The exposition floor, if it exists, is generally a sidebar to the conference itself. But these very social occasions are important cornerstones of the not-so-antisocial geek community. These events allow geeks to meet, socialize, and talk about the things that matter to them. They also bring about two important community activities: the delivery of technical presentations and the sipping of beer.

The Rise of Geek Speaking The growth of user meetings within the community brought about the role of geek speakers. The common culture frequently characterizes geeks as lacking the skills to do formal presentations. Instead, society often points to managers and salespeople who can stand up in front of a crowd and talk with ease. In the past twenty years, I have seen many people do presentations of one kind or another. I have seen many business people of importance stand up and deliver their speech. I have observed their polished and poised ways as they deliver their points in carefully rehearsed and measured tones. I have heard them make the obligatory jokes that all good speakers make at the exact time in the speech when they are supposed to be made. I have watched the crowd applaud graciously as the speaker concludes his remarks and takes his seat. And I have turned to the person sitting next to me and said, “He spoke very well, but what did he say?” In the past decade, I have witnessed some presentations that stood above the rest. They were informative, dynamic, funny, and interesting. And, as strange as it might seem to some people, they were all delivered by geeks. How is this possible? The secret, I believe, is in the context. When the typical geek in high school is told to speak about something that the teacher thinks is important, he may lack enthusiasm and be very aware of his assigned role as the outsider of mainstream society. Standing up in front of people in that atmosphere is like going to the zoo only to find that you are one of the animals in the cage. But, when the geek is given the opportunity to speak about something that really matters to him, and can speak to a group that actually wants to hear what he has to say, something almost miraculous happens. The shy, introverted geek discovers his voice. He discovers that he really can speak after all. I have heard professional speakers whose speeches came to a dead halt because the system containing their slides died. And I have seen geek speakers facing the same problem deliver an informative and witty presentation without the aid of any notes or slides at all. In the same way that geek culture changes the priorities in the society to match what geeks find important, so do geek speakers employ the elements that they feel make for solid communication. Geek speakers tend to have a very clear message in mind when they speak. They also tend to have a passion for the subject matter. And they know what makes them laugh about the subject, so they share it with their listeners.

71

08 1989-6 CH05

72

8/21/00

1:13 PM

Page 72

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

This form of communication is very important to the community. First, it is helpful for proper geek-to-geek communication. Many geeks take advantage of the technical sessions at conferences to become acquainted with projects they have not dealt with before. If someone stands up and gives a standard content-free marketing pitch for the project, it would put most geeks to sleep—and the few who remained awake would not be in an especially pleasant frame of mind. Likewise, a lifeless recitation of slides would be insufficient, as geeks tend to require answers to pointed questions and become frustrated when the presenter has neither the knowledge to answer the question nor the flexibility to accommodate audience interaction. But a good geek speaker can react well with a geek audience. The speaker knows his subject matter, so the presentation itself has valuable information. Most audience questions are not difficult to handle, since he has a depth of knowledge in the subject. And the thought of departing from the preordained presentation is not threatening in the least, since he is talking about subjects he knows well. The result of this is that the geek speaker is able to effectively impart valuable knowledge to the geek audience. This is very important, since the realm of Open Source software is far too wide for any one person to master. So an effective geek speaker is a tremendously valuable asset to quickly educate other geeks regarding the status of projects outside of their sphere of participation. The second vital role of the geek speaker is as an interface to the outside world. As Open Source grows in popularity, there is a steady influx of people coming in to the community and looking around. This is especially evident at Open Source trade shows and conventions, where many newbies join geeks in attending technical sessions to understand the technology. This is the situation where not only the knowledge but the passion of the speaker becomes important. Part of the job of the geek speaker in that instance is to impart some of his excitement for the technology to the newbie. If the speaker can get the outsider to comprehend not just the technical advantages of the software, but the excitement that he feels for the project, he is well on the way toward convincing the newbie that this project in particular—and Open Source in general—is something worth pursuing. In a world where it seems every salesperson feigns delight over their mediocre product line, the presence of genuine excitement and real conviction stands out in the minds of those who listen. The role of the geek speaker in imparting this genuine excitement to the listener should not be underestimated. It is the means by which many newbies realize that Open Source is not just about software, it is about people and the community they have formed.

The Meaning of Beer No community would seem complete without some form of ritual observance. Most communities have something that needs to be celebrated in a prescribed fashion. Religious communities frequently have some rite which needs to take place at a given place or time in a given manner. National communities often celebrate certain holidays in some traditional way. The Open Source community is no different in this regard.

08 1989-6 CH05

8/21/00

1:13 PM

Page 73

Chapter 5 • COMMUNITY, NOT COMMUNISM

One of the most visible observances has to do with beer. In the Open Source community in general, and the Linux community in specific, beer is simultaneously a symbol of value and of the community itself. It has little to do with drunkenness, foolishness, or lack of control. The image of beer-chugging college kids like those portrayed in the movie Animal House have nothing to do with the meaning of beer in the geek community. Some of the earliest references to beer in the community had to do with people owing a “virtual beer” to someone else who solved a difficult problem for them. It was an assignment of value to a job well done. It was a way of saying “thank you” to someone who had done something that affected you personally. A “virtual beer” was a very personal gift, not something that was given lightly. It was something that was earned. There are also many references to people discussing the Linux code over a beer. This was magnified by a reasonably popular photograph of Linus Torvalds chatting with someone with a bottle of beer in front of him. The matching of beer with discussion of code began to solidify as a cultural element. But the meaning of beer is never so evident as when one attends a Linux technical conference. Although the bigger marketing shows often invest in loud parties where you can barely hear yourself think, the smaller technical conferences often feature nightly get-togethers over beer. In the best of these, the music is low and in the background, the beer is varied and inexpensive, and conversation is endless. I can think of many such events I have attended over the years. Upon entering the establishment, the thoughts are not focused on drunkenness or carnal desires. Rather the focus is on your peers and the talk is about code (and beer). A good night of chatting and sipping can last for hours, and yet it will still seem all too short when the time to retire for evening arrives. Beer becomes the excuse to socialize with your fellow geeks. It becomes a symbol of the value of work well done. And it fosters celebration and fun as people talk about the work they are doing and the plans they have for the future. The idea is not to get drunk, since drunk people cannot talk about code. The idea of beer is to enjoy the company of people like you while talking about the work you like to do so much that you do it for free. And, in the case of people too young to drink beer, it is possible to substitute a soft drink without losing the true meaning of the encounter.

The Necessity of Community Any group that grows rapidly faces the possibility that it might lose its identity. As more and more people come in from the outside, there is always a risk that the people on the outside will affect the people inside the group more than the people inside the group will affect those coming in from outside. When this happens, a group can sometimes lose its moorings. It no longer remembers its charter. Its priorities shift. And, before long, it is in danger of death from distraction. In the late 1990s, some analysts were suggesting that the Open Source world needed to “grow up.” This meant that the Open Source structures needed to begin to resemble those of the

73

08 1989-6 CH05

74

8/21/00

1:13 PM

Page 74

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

corporate world. What were needed, it was said, were things like business plans, development schedules, and big-picture presentations about the future of Open Source. Much of this freewheeling attitude needed to be curtailed. Development had to follow plans like the rest of the software industry. And, this childish concept of “community” needed to give way to more corporate thinking. This was then, and is now, total nonsense. Yes, the Open Source community needed to learn how to “do business.” The variety of Open Source–related businesses that have appeared since 1998 or so indicates that the community is addressing that issue. There have been bugs in the business plans which sometimes need fixing, but in characteristic style, they are dealt with rapidly. I would be surprised if many of the Open Source businesses do not have to make more adjustments to their business models in the future, since many of them need to invent the rules as they play the game. However, the notion that the community must stop being a community and act more like a corporation is absurd. As this chapter has been striving to explain, the community is essential for the well-being of Open Source. To expect the Open Source world to survive without the community is like expecting a flower to survive without its roots. And to suggest that a flower will look much better without “those dirty roots” hanging from the bottom is the pinnacle of shortsightedness. The community is the life of the Open Source movement, nourishing its developers and creating an environment where life and the fruit of labor can come forth. It sustains the people. Is it ugly at times? Yes. Squabbles sometimes occur between team members. And, as communication needs to be done in the open most of the time, these squabbles sometimes receive undue visibility. Unlike corporations, the Open Source community has no locked doors behind which key players may argue and bang their fists on the table. But the real truth is this: If the way of business is so vastly superior to the ways of the Open Source world, why are businesses now lining up to use Open Source solutions? If standard means of software production are so good, why are so many closed-source companies struggling to move at Internet speed? Open Source solutions work precisely because the Open Source community works. And, although ways of bettering the community should always be entertained, killing off the community to fit someone else’s notion of how Open Source should operate is absolute folly. To suggest that the Open Source world should shed itself of the Open Source community is to suggest suicide. Nothing less.

09 1989-6 CH06

8/21/00

1:13 PM

Page 75

CHAPTER 6

PRIMARY COMMUNITY VALUE: TRUTH

Software that is correct most of the time is like a car that only explodes occasionally.

A

s explained in Chapter 4, “The Key to Many Things: Understanding Geek Culture,” the Open Source community values many things. Things such as freedom and fairness ring very true in the heart of the Open Source community. But nothing is so central to its core as the desire for truth.

Truth is the key to collaboration. Without truth, collaboration is futile. If all people on a team do not work together honestly and truthfully, their efforts are condemned to failure from the outset. Truth is the key to correctness. Code cannot be correct unless it conforms to a strict line of truth. Code that is only partially correct is code that is untrustworthy. And code that is untrustworthy is not worth much at all. Truth is the key to freedom. In order for people to be free, they must walk hand in hand with truth. One does not find freedom in lies. Only truth can facilitate true freedom. It is not surprising, therefore, that a community that values collaboration, correctness, and freedom must necessarily put a high value on truth. A strong emphasis on truth permeates the entire fabric of geek life. But the strict emphasis on truth is not something that most people from outside geek culture are prepared for.

Better Raw Than Wrong Perhaps the most difficult thing for people from outside the community to fathom is the impact of truth on social norms. In greater society, truth has a value, but civility and propriety are often held in higher esteem. A well-told lie is often tolerated more than a crudely told truth. We see this illustrated in positions of power throughout common society. Many politicians lie boldly with frightening regularity, yet they are reelected. Many managers fill presentations with double-speak and empty words, yet they are lauded as great leaders in

09 1989-6 CH06

76

8/21/00

1:13 PM

Page 76

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

the workplace. And many advertisers promise the moon with miraculous solutions to common problems, but never seem to deliver. But the geek’s devotion to truth does not yield so easily in the face of social situations. Even when the truth hurts, it must remain uncompromised. It is far more forgivable to be perceived as rude than it is to be seen as a liar. And from the community’s perspective, the line of what is considered a lie is drawn much closer to the truth than where the popular culture draws it. As a result, it is not unusual to hear geeks taking an uncompromising stand on issues that seem trivial to the general populace. Whether it is a company “stretching the truth” in a press release or a person who calls free software “shareware,” some geeks fly into a rage over seemingly petty offenses. The world often suggests that the geek just “shut up and live with it.” And the geek often replies that the world should do something quite rude. The problem is that the issue for one group is not the issue for the other. The world at large sees the issue as a few poorly chosen words, or perhaps the flexible speech of a marketing department. The geek, however, sees the issue as a violation of truth. And truth is always a critical issue, regardless of the particular application. As the insistence of one party that no transgression of merit has occurred rams headlong into the insistence of the other party that a primary value has been violated, a secondary problem ensues. This problem is the misunderstanding of perspectives. This causes frustration to grow and sometimes results in a geek making frank but crude statements about the other person’s participation or collaboration with the lie that was originally detected. Since the nongeek has received a rebuke for something he believes was inoffensive, the nongeek takes offense at the geek’s seemingly rude response. The final result is a situation where both parties feel that the other has violated primary codes of conduct. The geek feels the nongeek has violated the primary rule of truth, and the nongeek feels the geek has been offensive without due cause. So this basic clash of perspectives brings about the sense that some geeks are very rude people. It also brings about the sense in some geeks that nongeeks are frequent liars. But either way you look at it, the situation is due to a conflict over values. Since geek culture absolutely requires truth, rudeness can be forgiven when defending truth. Since the world at large usually values a civil tongue over speaking the truth, the words of the geek seem crude and inappropriate. The only real solution to surviving the clash of geek culture and popular culture is to try to understand both perspectives from the onset.

Technical Meritocracy The emphasis on truth also manifests itself in the concept of a meritocracy. In a technical meritocracy of Open Source, one ascends the ladder of prominence in the community by exhibiting appropriate merit. In the eyes of the community, this would generally include serving the community as a developer, project leader, speaker, or writer.

09 1989-6 CH06

8/21/00

1:13 PM

Page 77

Chapter 6 • PRIMARY COMMUNITY VALUE: TRUTH

This type of system is a derivative of the emphasis on truth in the movement. It stands to reason that a system that stresses truth must place the highest value on individuals who best fulfill the values of the community in their actions. So those who give the most valuable efforts to the community are generally afforded the greatest respect of the community. But this system does not always sit well with people outside of the community. They want to talk to the CEO. They want to hear from a vice president of development who can lay out the strategic plan, list the key assets of the corporation, and provide forward-looking information. But the community does not work that way.

Learning to Love the Warts Since a community in love with truth will necessarily expose error, it is important to understand those errors in a proper context. In the corporate world, much is done to put a consistent, smiling face on all company communications with the rest of the world. Advertisements boast that the company’s products are the best. Marketing people constantly highlight the company’s greatest wins in the marketplace. Managers appearing in public always portray the company as accelerating toward even greater success. And senior executives always seem to indicate to market analysts that great things are ahead for the corporation. But is the corporate world always so blissful? Of course not. In corporations across the world there are people who cannot seem to say a single nice thing about particular coworkers. There are decisions which come about not by some grand design, but through hard-fought battles of opposing factions within the corporate structure. There are senior managers who cannot step into a room with certain other senior managers without a shouting match ensuing. And there are executives gripped with fear over weakening revenue streams, despite the optimistic words of the CEO as he reported to shareholders. The business world—and society in general—allows for many unsavory things to be hidden away from the public eye. Problems, arguments, fights, and dirty little secrets are often obscured from plain sight. Yes, in public corporations certain problems must be revealed to the stockholders, but those problems often represent only the visible tip of a substantial submerged iceberg of strife and issues. As society is accustomed to seeing only part of the truth, it often engages people who try to determine the unspoken truths from the truths which are readily displayed. For example, outside analysts are employed to read between the lines of the problems reported at a corporation to gauge the depth of the sorrows actually besetting the company. Customers often study the claims of a vendor to determine how much of the content of the glossy sales brochures are fact and how much of it is mere marketing hype. The Open Source world, however, does not function that way. Since truth and openness are primary concerns, there is not much room to hide anything. Personal conflicts, leadership difficulties, and design disputes generally take place on a public stage for all to see. This is a price imposed on the community by its own value system. Most attempts to circumvent that truth

77

09 1989-6 CH06

78

8/21/00

1:13 PM

Page 78

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

and openness would require a violation of basic principles, which, in the end, is a far worse fate than displaying your dirty laundry to the public. Attempts to obscure the facts would often call for hypocrisy on the part of someone, and such hypocrisy could stand to destroy the culture and community which is built on pillars such as truth, openness, and freedom. With this in mind, then, one must come to the inevitable conclusion that people seeking to embrace the Open Source world must learn to appreciate it fully—warts and all, so to speak. When people try to impose the societal norm of hiding blemishes to the Open Source community, the results are necessarily devastating. For the community to function properly, the bad spots must be left intact. Concerted efforts to cover over problems would ruin the very methodology that permits the community to create software at Internet speed. That is not to say that there is no room for tact in strictly personal matters. For example, two developers might disagree in public vehemently over which of two possible solutions is best to solve a common problem. That discussion, though it might be far from the facade that a corporation would want to project, is essential for the process of developing good software and for the overall health of the community. But that does not mean that the developers need to introduce personal slurs and questions of the other’s parentage in the conversation. That matter is personal and can—and should—be taken offline from the public discussion of software. Indeed, the warts of the Open Source world are many and varied. There are personality conflicts, sometimes even among very prominent leaders. There are certainly misunderstandings and roughly worded retorts to some issues. Although this is certainly nothing to be proud of, it has to be expected in the realm of human interaction. Perhaps the most damaging issues, however, are those blown out of proportion by the media. For example, there were stories in some computer periodicals around a conflict between two high-profile members of the community. For a while, the technical positions of both men seemed to become tainted with the obvious feelings of anger that each aimed at the other. Although the two men eventually worked out their differences to the point where they agreed it would never serve as public a spectacle again, some of the industry media picked up the story of the conflict and tried to sensationalize it. Wild speculation about whether or not the Open Source movement could withstand such strife was published. People on the outside of the community were led to believe that the future of the movement was hanging in the balance. In fact, nothing could be farther from the truth. When all was said and done, the two men had a personal conflict not at all unlike those that occur daily in the corporate world. The problem, however, was that the media was not used to such displays and reasoned that if such turmoil was becoming visible, there must be deep problems within the movement. In a corporate situation, this might have been a viable assumption, since corporations try to keep such conflicts away from the public. But, in this case, the media did not understand the community and so applied the wrong reasoning, yielding the wrong result. In the Open Source model, unsightly warts will appear at times. The wise person will be unsurprised when they occur. The uninformed person will use them to fashion some type of

09 1989-6 CH06

8/21/00

1:13 PM

Page 79

Chapter 6 • PRIMARY COMMUNITY VALUE: TRUTH

doomsday prophecy for the community. In fact, if someone uses community warts to substantiate a pet theory of why the movement will die, that is a decent indicator that the person does not understand the community much at all.

Self-Correcting Community The passion for truth means that errors cannot go unchallenged for very long. The nature of the community is that it seeks to correct its errors quickly. This takes place in some ways which are expected and other ways that might be somewhat surprising.

Self-Correcting Code The most obvious way in which the community will act to correct itself is in the area of code. Indeed, the Open Source community has been stressing the fact that it works quickly to correct the bugs in its code. In this area, the community clearly works at Internet speed. The Usenet newsgroups are replete with stories of people who discovered a serious bug and described it in an appropriate newsgroup, only to receive a working patch in a few hours rather than days or months. The Open Source community works hard to correct its mistakes, and it does so in very short periods of time.

Self-Correcting News In the era of bidirectional communications, everyone has the possibility of voicing their opinion and of being heard. One of the tremendous advantages of the advent of bidirectional communications is that the information receivers can also be information providers. Or, in this case, information receivers can correct information providers. This process happens at several levels. The first level is story feedback. Most Internet news services provide a facility for users to respond to the stories they have read, but few take this capability so seriously as do the Open Source news sites. On many of the sites serving community, the feedback is not an afterthought, it is essential to the service. The function of the feedback on Open Source news sites is not to pacify the readers into thinking that their voices had been heard. To the contrary, the feedback from readers is a critical to the success of these sites. It is the function of the feedback is to keep the news honest, accurate, and trustworthy. Take, for example, the site Slashdot (slashdot.org). This site functions as one of the key online social centers for the community. It posts several news articles each day on topics of interest to the community. It also provides the community with a place to respond to each article. Yet it would be a mistake to consider that to be an adequate description of the function of the site. Many standard media outlets, like television news networks, provide news sites as well. Articles are posted to a Web site and a place is allocated for discussion. But that is where the similarity ends.

79

09 1989-6 CH06

80

8/21/00

1:13 PM

Page 80

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The media-outlet Web pages normally do not use the true power of bidirectional communications. The article talks to the readers and in the discussion the readers talk to each other. But any effect of the readers on the article is negligible at best. Why? Some people might try to argue that this is so for reasons of journalistic integrity: The reporter must not be swayed by public opinion. The reality of the matter, though, is that the readership often has a better knowledge of the facts than the author does. On such sites, however, this fact will go unacknowledged. This is not the case at Slashdot. When an article is posted, a discussion generally begins within seconds. Mildly interesting articles might draw only a few dozen responses, but items of a broader interest will gain multiple hundreds of responses in just a few hours. But the discussion is not simply between the readers. The discussion will often involve the readers, the writer, the publishers, and any named sources in the article. The value and power of this dynamic that cannot be underestimated. First, the recognition that the readership is also knowledgeable in the subject matter is a radical departure from the traditional media methodology. The implicit assumption behind the normal methodology of a news source issuing articles to the public is that the news organization has a superior knowledge or understanding of the facts of the matter. But in the Open Source community in specific and the world in general, this assumption is rapidly becoming invalid. As discussed earlier, in the Internet age the line between information provider and consumer has blurred considerably. As such, media outlets can no longer blindly assume that the readership has nothing of consequence to add to the facts of the article. In the case of Slashdot, it is not unusual for a posted story to be updated as a result of the facts revealed by the reading community. Additional information will be appended to the story header to note needed corrections. Or, sometimes, outright retractions will be posted—often within minutes—if the original story is found to contain significant errant information. Plus the addition of the SlashBack feature allows room for follow-ups and corrections to earlier stories. The result of this approach is that the community has been given both the right and responsibility to correct the information printed about it. Lest anyone try to dismiss this need for correction as being the result of bad journalistic practices of geek authors who do not bother to verify facts well enough before publication, consider the fact that this situation arises just as much if not more when articles are cross-posted from other news sites. The fact is that no media outlet—geek or traditional—can claim to have an infallible grip on fact. And in these days when few media concerns still have substantial numbers of people to check facts, the need for factual accountability is higher than ever.

Self-Correcting Opinions An interesting sidelight of the community’s actions for correcting news reports is its activity with regard to opinion pieces. In the computer industry, there are a substantial number of people whose job includes the formation and dissemination of opinions about technologies, companies, and news events. From expensive analyst reports on the future of the industry, to the weekly diatribes on corporate shenanigans in weekly trade rags, many people make a living by expressing their opinions.

09 1989-6 CH06

8/21/00

1:13 PM

Page 81

Chapter 6 • PRIMARY COMMUNITY VALUE: TRUTH

Until now, ill-informed opinions, like factually incorrect articles, were essentially held in check by corporate, government, or media information providers. Someone with enough vested interest in the situation and enough power to pull it off had to stand up and say, “I disagree!” In the case of opinion pieces and analysis, it was fairly rare to see much in the way of a rebuttal appear in any form. Normally, the information consumer simply had to choose to accept or reject the position presented without the aid of a detailed critical analysis of the statements made by the author. But now the community has the opportunity to publicly correct not only errant facts in news stories, but baseless opinions of critics. Mechanisms like Slashdot allow for the opinion articles to be posted and responses gathered, just as they are in news stories. But, in the case of opinion pieces, this can represent the only detailed public response that many authors will ever receive. They might receive emails that try to dissuade them from their positions, but few will receive the in-depth public scrutiny which tends to proceed from a Slashdot-style discussion. This type of intense scrutiny can have significant impacts in several areas. First, there is the impact on the columnists of the standard computer trade periodicals. Many of them have worked for years giving their opinions every week or so in their publications. If they publish a poorly informed or controversial column, they might be subjected to an increase in their email or perhaps a negative comment or two appearing in the Letters to the Editor page. However, neither of these means of correction will normally carry the impact in public opinion that the original column would have carried. In the Open Source community, however, the drive for truth will not allow ill-informed opinions to survive unchallenged. Although most opinion pieces will draw a little interest, columns that draw totally invalid conclusions are subjected to a rigorous and vigorous public debate. For perhaps the first time, these columnists have to face public analysis of their own analytic skills. They have to stand accountable for their opinions in a public forum. The net result is that these columnists quickly learn that they cannot afford to be ill-informed before they write. The same situation exists for corporate analysts. Many of these people and their high-powered firms write the reports on which the corporate world often bases buying decisions. Although they are less likely to make impulsive and uninformed statements than many columnists are, they still have enjoyed a pulpit from which few rebuttal opinions are ever heard. As a result, many of their high-profile, corporate-influencing conclusions have never been challenged in public. But the Open Source community changes all this. For example, many analysts and commentators issue opinions regarding the suitability of certain technologies for deployment within an enterprise. People have often contested the conclusions that were published but had no podium from which to protest in public. But now published opinions must meet the public assessment of the community at large. The last area where correction of opinion is highly significant is in the area of marketing. The ability of marketing organizations to go almost unchallenged when issuing inflated or unrealistic claims is gone. Now, marketing messages will be held up to the light of public analysis and debate.

81

09 1989-6 CH06

82

8/21/00

1:13 PM

Page 82

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Self-Correcting Rumors The Open Source community has little need for rumors within itself. In a community where important information is not held back from public view, there is little reason to rely on rumors to uncover “the untold story.” But rumors about corporations do arise, of course. And corporations that participate in the life of the Open Source community are of interest to the community. But, unlike the rest of the industry, rumors rarely surface without encountering efforts to verify them. The Open Source world is interested in fact, not hearsay. So unsubstantiated claims of corporations doing one thing or another in the Open Source arena naturally precipitate a reaction from the people. There needs to be corroboration before people will consider it. Again, the community works to verify things in real time. It is not unusual to see one of the Open Source news services linking to a media report containing rumors regarding a major company’s Open Source position. It is also not unusual to find that within hours or minutes of the initial post, some clarifying information that proves or disproves the point has appeared along with the original story.

Self-Correcting of Trolls Within the realm of Internet communication, there are individuals who are known as trolls. Especially visible on sites such as Slashdot, trolls are people who write inflammatory, insipid, or intentionally inaccurate remarks. These are the individuals that cynical outsiders claim characterize the Open Source community. In actuality, nothing could be farther from the truth. Trolls are universally disliked in the Open Source community. People who contribute and participate in the community generally care too much about the values associated with the movement to make idiotic statements in public forums. Trolls are regarded as a unfortunate, but necessary, evil in the community. If there is to be freedom in the community, there must be freedom of speech. If there is freedom of speech, there is freedom to speak stupidly at times. The occasional ranting of trolls is the price of assuring freedom of expression. But the process of dealing with trolls is not simply an issue of ignoring insipid remarks. The value of truth cannot be circumvented by clinging to the value of freedom. So the Open Source community has experimented with several methods to provide for the needs of both truth and freedom. The first and most obvious method is simply to answer the troll in the context of his comment. If a troll makes some senseless remark (unfairly disparaging a person’s character, for instance), many people will simply answer the point as made. People will attack the basis of the troll’s attack and even begin to refer to the individual as a troll in order to clearly characterize their perception of the remarks. Although this does serve the purpose of truth to reply to the charges or claims of the troll, it does not do the job perfectly. In forums where trolls are unusually persistent, for example, much time can be lost answering the frothing of trolls. This gives them far too much power to

09 1989-6 CH06

8/21/00

1:13 PM

Page 83

Chapter 6 • PRIMARY COMMUNITY VALUE: TRUTH

distract the discussion away from more important issues. The solutions to this problem are varied, but the Slashdot solution (as I write this) is especially inventive. People who participate in the Slashdot discussions are randomly given a few temporary moderator points. Anyone who has received moderator points has the opportunity to rate comments by other members in the discussion. If the temporary moderator thinks a comment is especially valuable, he might choose to add to the rating value of the comment. If the comment is that of a troll, it can be moderated downward in value. Normally, all comments are visible to readers except for those which have moderated downward for trollish content. But even though the comments are hidden by default, they still exist and can be viewed if the reader chooses to do so. So this gives the reader the option of skipping over the work of trolls, while protecting both the freedom of speech and the freedom to read all comments entered. And, since the moderator duties are only temporary and random across the community, no one body of moderators can monopolize the rating of comments. In this way and others, the community seeks to balance the needs of truth and freedom.

Why Some People Will Hate This Book Sometimes the passion for truth brings results that can make people uneasy. For example, I fully expect that there will be some people who will begin to read this the book and immediately hate it. Why? For the love of truth. The love of truth is so strong in the community that trivial errors, differences of opinion, or things perceived as errors can cause some people to condemn works that might be over 99% accurate. This phenomenon dumbfounded some of the earliest members of the computer industry press as they began discussing Linux. Some people wrote terrible articles about Linux, filled with inaccuracies and misperceptions, and found that their mailboxes instantly overflowed with hate mail (or flames as they are commonly called). As disturbing as that might have been, many journalists understood why strong errors brought out a strong outcry. But, when other journalists wrote much more favorable articles about Linux, something very peculiar happened. Along with a large number of complimentary messages, they received a large number of flames. Why? Because the presence of small factual errors ruined the articles for many readers. These infractions could be as seemingly mild as referring to the software as shareware or freeware, poorly summarizing the terms of the GNU Public License, or naming the wrong year that Linus Torvalds started working on Linux. For these errors, some people would suggest that the article was so poor that it should never have been published. The reason for this is, of course, the centrality of truth within the community. In the task of programming, a seemingly trivial error in the code can make the entire program fail. It is absolutely essential that the error be expunged from the code to protect the integrity and functionality of the program. And, although many errors are very tricky and take time to locate and correct, errors that are obvious in nature are generally handled immediately. Their presence might cause problems elsewhere, so their existence must be addressed first before looking for more subtle problems.

83

09 1989-6 CH06

84

8/21/00

1:13 PM

Page 84

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

It is this mindset that causes the community to bristle at the presence of obvious errors. To see a piece of code with obvious errors that are being ignored by the author can cause a geek to become very angry. The author’s lack of diligence could cause problems that could cripple any program that relies on the faulty code. The cry naturally rises that this code must be fixed, and fixed promptly. To miss subtle errors is forgivable, but to ignore obvious errors is not tolerable. So, when the community runs across an article that is accurate and well-written, but still has a few obvious errors, it can cause turmoil. Some people are mindful of the fact that writing and programming are two different disciplines and will offer the author a note that praises him on his work but quietly suggests that there were a few minor errors. Other people will deal with the author as if he were a careless maintainer of code. His apparent refusal to address obvious errors that could be fixed in seconds causes the geek reader to send off a flaming tome which questions the article, the talent of the author, and the legitimacy of his parentage.

GNU/Linux and Truth Another theme that often arises in discussions has to do with term GNU/Linux. Although most companies generally use the term Linux to represent the various distributions that are based on the Linux kernel, some people (especially, but not exclusively, those who identify themselves with the free-software movement) insist that the name of the operating system be called GNU/Linux. The rationale for this is that there is more code from the GNU project included in a standard Linux distribution than there is code from the Linux project specifically. The basis for this argument has to do with truthfully giving credit where it is due. Since the GNU project has donated a substantial quantity of code to the project, it should be acknowledged in the name of the product, say adherents to this view. And, since the amount of GNU code is larger than the amount of kernel code, the GNU name should come first. Although there is logic in this stance, it is also a very slippery slope. For example, it has been pointed out that the amount of code in the X Window System is greater in mass than either the GNU or Linux kernel code. Should the name of the operating system be called X/GNU/Linux then? There is also BSD code present as well, so should the name be X/GNU/Linux/BSD? How far do you take this? At what point do you credit the results of one Open Source project over another? And what happens if a distribution decides to change the mix of utilities somewhat? Say, for example, that a distribution decides to carry more BSD programs than GNU programs. Do you change the order of the elements of the name to represent the name? I shared this argument with someone who was promoting the GNU/Linux moniker. The response I received was surprising. This person said, in essence, that since the X Window System was free software, it could be lumped into the GNU name, since GNU can be inclusive of free software. But that argument causes the exact problem the GNU/Linux people are trying to solve. By that very reasoning, the name Linux suffices, since Linux could be said to include all free software, including GNU.

09 1989-6 CH06

8/21/00

1:13 PM

Page 85

Chapter 6 • PRIMARY COMMUNITY VALUE: TRUTH

Although I have sympathy for the issue at hand, I personally use the term Linux because the term GNU/Linux does not truly solve the problem. Since the real issue is truthfully acknowledging the contribution of the GNU people, the ongoing discussions about GNU software in the community seem to do an excellent job of providing that recognition without resulting to the action of changing the name to GNU/Linux and creating even more issues around the issue of recognition. Secondly, the logic around changing the name is based entirely on the amount of code in the product. I believe this to be an important, but not sufficient, basis for naming. In fact, the amount of GNU code in the world has grown significantly as a result of the popularity of distributions that use the Linux kernel. And this popularity is a direct result of the management style of Linus Torvalds and others who began developing Open Source software as a result of his efforts. As such, Linus and Linux helped GNU grow in ways it might not have under other circumstances. I therefore believe that calling the resulting operating system Linux while recognizing the important contributions of GNU, the X Windows System, BSD, and so on is the best solution to the problem. But each person is certainly free to propose his own solution to that problem.

The Truth Shall Set You Free The key to remember is this: In the world of Open Source, few things generate as much anger as a violation of truth. Such a violation might arise from things as normal in the computing world as a poorly worded press release or advertising statement. But the Open Source community survives because it requires accurate, truthful information. People and companies that want to participate in or market to Open Source must remember to adhere to a very high view of truth in their interactions with the community.

85

09 1989-6 CH06

8/21/00

1:13 PM

Page 86

10 1989-6 CH07

8/21/00

1:13 PM

Page 87

CHAPTER 7

FEAR, UNCERTAINTY, AND DOUBT

O

ne thing that people in the Open Source world are used to is FUD. FUD—fear, uncertainty, and doubt—has accompanied the development and use of Open Source software since the computer industry began to “discover” it (usually in the form of Linux) around 1995. The basic theme of FUD is simple: whatever this stuff is, however useful it might appear, it cannot possibly succeed.

Classic FUD The types of FUD that have confronted Open Source software have changed over the years. Many early forms of FUD have been thoroughly refuted already and are far too ludicrous to espouse now in view of the many successes of the movement. However, even these ancient falsehoods occasionally arise from the lips of particularly clueless commentators who mindlessly parrot the earlier comments of others, thus alerting people that the individual is not only ignorant of the situation, but willingly so, since most any novice with Internet skills could refute these statements with a few minutes of research.

Open Source = Hacker Toys One of the classic FUD pieces is the portrayal of Open Source programs as “hacker toys.” The old saw went something like this: “You want to use this software for business? Are you crazy? This software is nothing but the toys of hackers. It is not meant to run serious business systems. You are a fool if you trust it.” This particular line of FUD was quite prevalent until about 1998. That was about the time it became apparent that Open Source software was already powering many new mission-critical sites on the World Wide Web, as well as key Internet services such as mail delivery and Internet name lookup. In the face of such masterful successes as the Apache Web server, sendmail, bind, and the increasingly large number of Linux and BSD servers powering major Web sites, there was no longer any excuse for this errant assertion. In truth, much Open Source software was far more ready for the Internet revolution than competing mainstream commercial software was.

10 1989-6 CH07

88

8/21/00

1:13 PM

Page 88

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Open Source = Written by Amateurs and Kids A second piece of FUD which was closely aligned with the first was the assertion that Open Source was the product of “freaks, amateurs, and teenage hackers.” The story went something like this: “You can’t trust this type of software. It’s written by a bunch of long-haired hippie retreads and juvenile delinquent hackers. Don’t waste your time with junk built by amateurs. You need software built by highly trained professionals!” This, as it turns out, is absolute nonsense. Yes, the bulk of Open Source software is built by people in their spare time. But most of the people working on the projects are themselves professional programmers. In some cases they are students who are well on their way toward becoming professional programmers. But the characterization of the average Open Source programmer as some type of unprofessional oddball is entirely unwarranted.

Open Source = Shareware One of the more irritating forms of FUD was the frequent association of Open Source software with “shareware” or “freeware.” It was especially irritating to the geek culture because it was an obvious falsehood born either of a lack of consideration for the subject matter or of a desire to cast aspersions on the effort. In the corporate world, shareware had a reputation of being uneven in quality and suspect in origin (even though there were and are some rather good pieces of shareware in the world). It was often characterized as the product of amateurs. So associating Open Source with shareware was to associate Open Source with unproven quality and shrouded origins. As discussed in Chapter 2, “How Did All This Start?” Open Source and free software are not shareware by any means.

Open Source = Old Technology Another tack of some FUDmongers was to associate Open Source software with “old technology.” The logic went like this: Most Open Source software is modeled after Unix. Unix is quite old. Therefore, Open Source is just more old technology. This logic, of course, only makes sense if you accept the premise that Open Source software is simply another implementation of an ancient Unix operating system. This is incorrect. Open Source efforts needed to start with the task of creating the basic functions of a Unix-like system before they could proceed to newer and more advanced functionality. But the newer features have come along with relish. New technology such as the Apache Web server and the GNOME and KDE desktops have taken the system into new areas with greater capabilities than formerly associated with “old Unix software.”

Open Source = Unsupported Software Another classic piece of FUD was the notion of Open Source as “unsupported software.” The logic was sublimely simple: If there is no commercial vendor behind the software, the software is unsupported. And anyone who runs a business on unsupported software is a fool. The classic response to this was that software did not need a commercial vendor to be supported. The community supported its software incredibly well, so the absence of a vendor

10 1989-6 CH07

8/21/00

1:13 PM

Page 89

Chapter 7 • FEAR, UNCERTAINTY, AND DOUBT

was not a problem. A person with a problem could simply employ a standard Internet search engine or use IRC or one of many mailing lists and have answers in a very short period of time. I spoke to an employee of a very well-known system reseller who claimed that his employer did a study on problem-resolution times for different operating systems. This company found that the average time to resolve problems under Linux using Open Source support methods was far shorter than the time to resolve problems on commercial operating system platforms using traditional support methods. Of course, the issue of “no support” is now essentially moot. Many companies offer Open Source telephone and contract support. Each company has access to the full source code, and it does not take long to find and retain a company with a strong reputation in the Open Source arena that is willing to meet the needs of a corporation. And, in the current Open Source world, a number of companies produce Open Source software that they also directly support.

Open Source = Insecure Another oldie-but-goodie class of FUD is the claim that Open Source software is insecure compared to closed-source offerings. “If every teenage script kiddie and every cyber terrorist can see the code, it cannot be safe,” goes the reasoning. “Security through obscurity” is the key thinking here. Again, this belief rests entirely on inappropriate assumptions. The ability to read Open Source code does leave vulnerabilities open for the entire world to see. That world is inhabited by crackers and script kiddies, but it is also inhabited by security-conscious technical people. The result is that many problems are found by the community before they are ever exploited by crackers, and those vulnerabilities that are exploited by crackers are normally fixed within hours of the first recorded attacks. So Open Source security is not perfect, but it is aggressive. Of course, the incidents that basically put this FUD on the back burner were the serious email virus attacks of late 1999 and early 2000. These attacks displayed conclusively that closing the source does not necessarily equate to promoting safety. Safety through obscurity is not assured by any means. And when a closed source system is exploited, users have no recourse but to wait for the vendor to fix the problem. As displayed during the outbreaks of email viruses, the time spent waiting for the closed-source vendor to create a fix can leave the door open for tremendous harm.

New FUD Not all the FUD that has been brought against the Open Source movement is in the past, however. There are a number of FUD messages which still dog the heels of the Open Source world. The current major FUD issues are as follows.

Open Source = Uncertain Future A frequent bit of FUD in corporate circles is the statement that Open Source software has an “uncertain future.” The rationale behind this is clear: Open Source software often has no

89

10 1989-6 CH07

90

8/21/00

1:13 PM

Page 90

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

sponsoring company behind it. It also frequently lacks an individual who will stand up in front of business people and declare the future road map for the software. As such, the logic goes, there is no certainty regarding the future direction or development of the software. This “uncertain future” FUD plays on the notion that any differences between Open Source practices and commercial closed-source practices are necessarily flaws in the Open Source model. This is not the case. Although it is true that there is no company with a profit motive to drive the development of most Open Source projects, there is a community motivated by need that does drive the development. And even a quick assessment of the lifecycle of most products will show that most companies stop development on products long before their customers have lost use for the product. Thus, a user-driven development cycle is likely to ensure that product development continues longer than in the profit-driven cycle. And, in the case that a particular company wants to see development continue on some project that has stopped development, it is able to restart the maintenance of the project either by funding someone to make changes or by doing the job itself. Access to full source code makes it impossible for the company to be stuck with a truly dead product. Once again, the Open Source model makes certain that the future is never bleak. The second part of this FUD, the notion that the lack of a stated road map is necessarily bad, again relies on casting differences as weaknesses. Yes, most Open Source projects lack expressed multiyear road maps. That is because the users are free to guide the development into the direction they need it to go, rather than being at the mercy of a vendor’s idea of where the user needs to go. The future direction of the software is based in the customers’ needs, not the vendor’s needs. So Open Source means greater control over the future, not less control. The assertion that closed proprietary software is superior to Open Source because the proprietary software includes a road map is like claiming a bus is superior to a taxi because the bus driver knows where he is going before you set foot inside the vehicle. In actuality, most people prefer the taxi to the bus, because the taxi will take you exactly where you want to go when you want to go, while the bus will get you somewhat close to your destination at a time schedule that is almost totally out of your hands.

Open Source = Increased Risk One of the prevalent FUD assertions is that using Open Source increases risk. “If something goes wrong,” goes the saying, “you have no one to hold accountable. You have no one to sue!” As it turns out, this is quite true. However, this piece of FUD miscasts the situation by what it implies, but never states. The assumption is that the user of closed proprietary software has the reasonable ability to sue the commercial software vendor if the software fails to perform according to description. This belief is not well founded. If you read most commercial software licenses, you inevitably find statements that indicate that the software is provided “as is” and if the software does not work according to design, the provider is absolved from all guilt. For some company to successfully sue a commercial software provider for nonperformance, that company would have to win a court ruling that essentially invalidates just about every commercial software license in North

10 1989-6 CH07

8/21/00

1:13 PM

Page 91

Chapter 7 • FEAR, UNCERTAINTY, AND DOUBT

America. While that might be a possibility, it certainly does not appear likely given recent legislation in the United States which strengthens, rather than weakens, the rights of software providers. “Increased risk” FUD can be difficult to counteract simply because it tends to be disguised in other actions. Many people who try to convince management to use Open Source sometimes face an impenetrable wall of “we don’t use unsupported software!” responses, even after explaining all the technical support options available for Open Source. But these people fail to recognize that the problem is not technical support, but management support. And, for that, there is a fairly simple solution. The solution is to engage professional support and consulting services. Professional support services can provide the telephone support required. But professional consulting services can be used to guarantee success. Many top-tier computer companies can be engaged to deliver quality Open Source solutions. The names of these companies are known to top management, so there is little fear of someone saying, “Why did you risk the business on some unknown company?” And, perhaps more importantly, these consulting companies will sign contracts which guarantee that the project will be done. And, unlike with shrink-wrapped software, the customer really can sue the consulting company if the solution fails to work.

Open Source = Difficult to Use Another persistent article of FUD is that Open Source software is difficult to use. This is inevitably matched with images of the limited friendliness of a 1980s Unix workstation. “Unix has always been difficult to use,” states the FUD spreader. “As a Unix-like system, therefore, Open Source software is plagued with the same malady of unfriendliness that has plagued Unix for years.” If Open Source software were nothing more than just another 1980s Unix implementation, the criticism would be valid. But that is not the case here. Open Source has greatly improved on the usability of standard Unix. The new GUI desktops such as KDE or GNOME are simple enough to be used by nontechnical people without batting an eye. On the system administration side of things, Open Source software does well too. Consider the rapid adoption of Open Source solutions by system administrators, often in spite of corporate edicts. System administrators do not relish implementing systems which will tax their time in the long term. One reason why Open Source solutions are a favorite with many administrators is that they are not difficult to manage.

Open Source = Difficult to Install Perhaps the longest running piece of FUD is the notion that Open Source software is difficult to install. This particular complaint has been around as long as Open Source has been on the corporate radar. Like many other types of FUD, this has an element of truth mixed with invalid assumptions. There are definitely times when Open Source software (particularly operating systems) can be difficult to install. This is especially true when bleeding-edge hardware is involved, where a

91

10 1989-6 CH07

92

8/21/00

1:13 PM

Page 92

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

driver might not be available yet, or when proprietary hardware is present in the system (this is most common with laptops). It should be remembered that very few Open Source hardware drivers are actually written by the hardware manufacturers. They are normally written by the community, based on whatever information users receive about the hardware. As Open Source becomes more mainstream, more hardware vendors are showing interest in releasing information and drivers for use by customers. It is also worth noting that there are many instances when installing proprietary operating systems can also be difficult. This is most evident on the PC platform, where a wide variety of hardware is available. To reduce the support burden, some proprietary vendors drop support for older hardware in time. This can cause headaches during system upgrades. Open Source operating systems, however, rarely see the need to drop support for hardware. But, the crux of the matter is that more people notice problems installing Open Source software simply because Open Source software is not normally preinstalled the same way many other operating systems are. This situation is changing, particularly in the area of Linux, where a number of vendors are now offering the operating system preinstalled on the hardware. It is also important to contrast the installation of the software with the maintenance of the software. There are software systems that not only have to be installed, but have to be reinstalled at times because they have the capability of becoming corrupted through the installation of other software. Most Open Source operating systems use excellent package managers which keep one software package from inappropriately replacing files needed by other software packages. So, in the case of some proprietary software packages, ease of installation is crucial because it might be repeated many times. Most Open Source systems have fought to eliminate the need to reinstall software needlessly. The Open Source community is also working hard to improve installation procedures, so that those people who need to install the software will find it easy to do so.

Open Source = Fragmentation The fear of fragmentation is perhaps the most lingering form of FUD in the Open Source world. This is due largely to the connection between Open Source software and Unix. Since Unix split disastrously into many different partially compatible proprietary implementations, the fear is that the Open Source projects will suffer the same fate. Given the fact that the fragmentation of Unix almost succeeded in killing it as a growth technology, it is valid to ask whether Open Source systems might suffer from such a potentially fatal tendency as well.

The Fracturing of Unix It is well known in the industry that Unix fragmented along vendor lines. Different versions of Unix had different capabilities, variations in programming libraries, and different administration tools. Programs that worked under one vendor’s Unix sometimes had to undergo minor, but undesirable, changes to run under another vendor’s Unix. System administrators had to learn different sets of incompatible administration tools in order to serve a multivendor Unix computing environment. And users often would face desktop interfaces which varied in look and in capabilities across different Unix implementations.

10 1989-6 CH07

8/21/00

1:13 PM

Page 93

Chapter 7 • FEAR, UNCERTAINTY, AND DOUBT

The fragmentation occurred when different Unix vendors tried to differentiate their products from the other Unix implementations in the industry. In order to prove that their particular Unix had the best administration capabilities, each vendor developed its own set of scripts and admin tools. To claim that its offering had the most productive workstation, each vendor created its own desktop environment. The results of this effort were disastrous. Instead of one vendor’s concepts winning out over another, the entire Unix market became mired in the mix of proprietary extensions that seemed to haunt just about every offering. As a result, Unix developed a bad reputation in many business circles due to the fragmentation of the vendors. Efforts were devised to rescue commonality through standards like the POSIX specifications and the Common Desktop Environment (CDE). In the end, these efforts were too little too late. The PC had risen during the time of squabbling among Unix vendors. Many vendors dismissed the PC as a lightweight computing platform which could not approach the power, sophistication, and utility of a Unix workstation. Unfortunately, these same vendors failed to learn the lessons of computing history that they themselves participated in when Unix came into being. The rule of thumb in computing is that systems will become smaller, cheaper, and faster and will do so with a frequency rarely observed in other markets. Yes, the early PCs were brutish toys compared to the sophisticated Unix workstations of the 1980s, but the PC would not remain in that state for long. The PC grew by leaps and bounds. And, as the capabilities of the hardware increased, the operating environment also improved. Before long, the PC was simpler to use and much cheaper than the proprietary workstations of the Unix vendors. Even though the PCs lacked many of the server functions of the Unix systems, the PCs were judged to be functional enough to replace Unix on the desktop. Suddenly Unix was primarily a server operating system. And, as computing power and software capabilities increased in the early 1990s, the place of Unix on servers was brought into question. The term legacy Unix servers was popularized and analysts began predicting dates for the death of Unix as a viable server operating system. The fragmented approach of vendors who cared more about short-term profits than long-term market growth had succeeded in putting the Unix market into a death spiral. But, in the middle 1990s, a technical miracle occurred. While the traditional Unix marketplace was given the kiss of death by the industry pundits, a new force arrived on the scene to reshape the market once again. The unexpected rise of the World Wide Web had caught many of the industry powers flat-footed. The gap between the need to connect to the Web and the weaknesses of commercial software solutions in this area opened a window of opportunity for what would come to be called the Open Source movement. Led in the media by the efforts of Linus Torvalds and the Linux project, these creators of free software were churning out usable Web-enabled software at just the right time. Suddenly, the software world had a new and potent set of players, and these players all worked with something that looked and smelled a whole lot like Unix. As incredible as it seemed, a technology all but declared dead was experiencing a resurrection in a way that few ever dared to believe possible.

93

10 1989-6 CH07

94

8/21/00

1:13 PM

Page 94

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Will Open Source Succumb to Temptation? Fear of fragmentation haunted the blossoming movement almost from the start. At first, the various BSD projects appeared to inherit some of the fragmentation baggage inherited from the traditional Unix world. The early segmentation into FreeBSD, NetBSD, OpenBSD, and others seemed to echo the failures of those that came before. But even these fractures would prove to be less tragic than first perceived. Fear of fragmentation hung wearily around the necks of the early Linux developers, and when Linus Torvalds decided to license his project under the GNU Public License, he essentially declared that the Linux kernel should not be able to be taken private and mired with closed, proprietary enhancements to facilitate the desires of software corporations. Instead, the kernel would remain open and free at all times, and that meant that the profit rationale behind fragmenting the kernel was now a moot point. No one had the right to make the kernel into a proprietary piece of code, so no one had any reason to fork (or split) kernel development. In addition to that, though, the Open Source community on the whole began developing an aversion to forking projects. The lessons of the traditional Unix market were clear: fragmentation without substantial cause is wrong. In fact, many of the people who worked on Open Source software were veterans of the Unix battles in the 1980s. This experience served to strengthen their resolve that forking code development is reserved for situations where no other tactic will work. In time, this commitment to avoid forking except in the most extreme circumstances became a real part of the community mindset. Only a handful of projects forked in the 1990s. Those that did were surrounded with many, many dissertations justifying the need for such radical action. One (the gcc/egcs compiler fork) actually healed itself in time when the two factions decided to support the same version. Even in the BSD camp, there is little desire to have separate distributions if they do not solve unique problems. The missions of most BSD variants tend to be well-defined: NetBSD focuses on multiple hardware platform support, FreeBSD works toward high degrees of network performance and security, and so forth. In fact, in the beginning of 2000, BSDi and FreeBSD announced that they were merging back into a single project. The community does not need extra choices if there is no need for them to exist.

What About the Different Linux Distributions? A constant example drummed up by people intent on proving that Open Source software will fragment is the existence of so many Linux software distributions. “Every Linux company has its own Linux distribution! This is just what the traditional Unix systems did!” claims the FUD spreader. “Open Source has failed!” However, the differences between Linux distributions are not nearly as severe as the differences between Unix implementations. Linux distributions do not use forked versions of the Linux kernel. Each distribution uses the same kernel software as every other distribution. Likewise, major utilities are generally identical across distributions. What tends to change across distributions is emphasis. As outlined in more detail in Chapter 9, “The Players: Who Does What and Why,” some distributions emphasize some aspects more strongly than others. For example, some focus on the desktop, whereas others focus on server functions. Still others try to

10 1989-6 CH07

8/21/00

1:13 PM

Page 95

Chapter 7 • FEAR, UNCERTAINTY, AND DOUBT

balance client and server concerns. Some of them put strong emphasis on internationalization, while others are more focused on a single language base. Some distributions build their directory trees slightly differently. A file in the directory /usr/doc in one distribution might be contained in /usr/doc/HOWTO in another distribution. Changes of this nature are not fatal, but they are annoying. To circumvent such inconsistencies, the Linux Standard Base (LSB) organization was born. The LSB is actively working to remove such annoying differences from the distributions and to ensure that software meant to be installed on one distribution will be able to be installed on any other without modification. This stress on compatibility is a major difference between the Linux distributions and the fragmentation of the Unix implementations. Software that works on one distribution of Linux within a hardware architecture can work on other distributions as well. Until the LSB finishes its work, it might take a different installation procedure to accomplish the task, but a program is capable of running on any Linux distribution within a given hardware architecture.

What About KDE and GNOME? Another frequently used example of fragmentation is the competition between KDE and GNOME, currently the two most popular desktop interfaces in the Open Source world. KDE is the slightly older of the two and is generally regarded as more mature. GNOME exists because KDE was built using Troll Tech’s Qt library, which had a license that allowed it to be used without charge, but the license did not qualify as a free software license. In response to this, the GNOME project was born to supply a user interface that was constructed entirely with free software. Later, Troll Tech modified its licensing terms so that the Qt library could be used under a free (but slightly cumbersome) license. It should be noted that GNOME is not a fork of KDE but a separate solution to a similar problem. It should also be noted that the sole reason for GNOME’s existence was the issue of free software, an issue that strikes at the heart of the community. The competition between the two was not the result of some profit motive or because of the egos of the parties involved. It takes a matter of that much importance to get the community to willingly entertain launching a second project that will take on a major problem. In some ways, the competition between KDE and GNOME has had many positive effects. Each project has pushed the other to resist the urge to declare victory and slow down development. Instead, each project reminds the other that advances in ease of use must be ongoing. This in and of itself is a major change for the Unix-like desktop, where rather sparse user interfaces had ruled for much of the 1980s. In these two projects, the X Window System finally received the types of desktops that it was designed to provide. Competition has moved the task along. Also, there have been concerted efforts on the part of KDE and GNOME teams to permit as much interaction between the desktops as possible. For example, the main menu for KDE on my workstation has a menu for GNOME applications as well. The teams are not interested in obliterating each other, and they are willing to cooperate where it makes sense. While having two desktop options might be somewhat confusing to some people in the short term, the tale of KDE and GNOME is hardly the story of fractures running rampant in the community. It is a story of last resort required to ensure that the software is free.

95

10 1989-6 CH07

96

8/21/00

1:13 PM

Page 96

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Open Source Lacks Innovation Finally, one of the most popular bits of FUD in recent times has been the assertion that Open Source is incapable of innovation. “All these Open Source people do is to copy other people’s designs. They do not have the capacity to do real innovation. That requires an expensive group of talented researchers, like those found at large commercial software companies. These Open Source hackers just cannot hope to accomplish the radical new breakthroughs that these big companies create.” This particular assertion makes some poor assumptions. First, it assumes that revolutionary software is usually generated by large corporations with huge budgets. However, recent history challenges this notion. The blossoming of the World Wide Web itself is not due to the plans of giant computer firms. Rather, most of the enabling technologies for the Web arose from small groups and companies that decided to pursue some interesting ideas. The original groundbreaking work in browsers, Web servers, and other Web services were not the result of deep corporate pockets. Therefore, it is a mistake to assume that Open Source developers cannot match the innovations of large corporations. A second assumption is that the Open Source community’s work to create basic functionality over the past several years equates to a follower’s attitude. This is a poor assumption. The community needed to create basic functionality because without it, there would be no opportunity to create advanced functionality. It is important to remember that some very innovative Open Source technologies—like the Apache Web server, scripting languages like Perl and Python, and the sendmail mail-handling system—all power significant portions of the Internet. Their ability to run on astounding numbers of hardware architectures using Linux and NetBSD is something that closed-source software has not been able to accomplish. But many instances of community innovation are coming to light. The advances that have been made in the palm-sized and portable device front are showing that Open Source is capable of moving into new areas and going toe-to-toe with closed source rivals. Likewise, advances in embedded solutions indicate that Open Source will be ready to meet the new crop of networked devices which are expected to find their way into the home and data center in the near future.

Open Source and Brook’s Law Brook’s Law: “Adding manpower to a late software makes it later.”

This type of FUD claims that the Open Source method for developing software cannot continue to turn out projects at the current incredibly fast rate. Following the pattern of Brook’s Law, increasing the size of a large team of people actually slows the pace of the team. It is argued that since the Open Source community is a large body of people, the growth of the community can only succeed in slowing down the production of software. While the concern over Brook’s Law is reasonable, the application of it to the Open Source community arises from a fundamental misconception of how the Open Source community

10 1989-6 CH07

8/21/00

1:13 PM

Page 97

Chapter 7 • FEAR, UNCERTAINTY, AND DOUBT

works. Most Open Source projects are not mobs of dozens of developers. The average project has a core team of a few central developers. There might be a group of occasional contributors around them, but the core team is still generally small. So the growth of the community does not necessarily increase the number of people in a given project team. If anything, an increase in the size of the community will help spawn additional project teams to handle new projects. Brook’s Law, then, is not likely to cause a failing of the community in software creation any time soon.

FUD Now and Forever The important thing to remember about FUD is that you can expect it to be around the Open Source community for a long time. Open Source challenges the norms of the software industry. It is natural, then, to find some software competitors and analysts who will try to cast these essential differences as weaknesses in the Open Source model. But, as Open Source matures, it becomes more and more evident that many of these supposed flaws are nothing more than FUD: fear, uncertainty, and doubt.

97

10 1989-6 CH07

8/21/00

1:13 PM

Page 98

11 1989-6 Part III

8/21/00

1:14 PM

Page 99

PA R T I I I

EMBRACING THE INSANITY: JOINING THE FRAY

8

Cooperate with the Competition? Are You Nuts?

9

The Players: Who Does What and Why

10

The Potholes: What to Avoid

11

The Primer: What to Do

12

Licenses, Licenses, Licenses!

11 1989-6 Part III

8/21/00

1:14 PM

Page 100

12 1989-6 CH08

8/21/00

1:12 PM

Page 101

CHAPTER 8

COOPERATE WITH THE COMPETITION? ARE YOU NUTS?

I

ngrained deep in the heart of every Western businessperson is the concept of competition. You need to compete. You are paid to compete. And you are paid to win.

The executives at Coca-Cola are not paid to play bridge with the executives at PepsiCola. They are not hired to spend hours of “constructive dialogue” about joys of working in the soft drink industry. No, the executives at Coca-Cola are paid to make Coca-Cola the number-one brand in the industry, with Pepsi and all others falling into the “also ran” category. Likewise, the executives at Pepsi-Cola want to see their product be the numberone cola drink in the industry. If Coca-Cola loses market share while Pepsi rises in the ratings, the Pepsi team will not shed a single tear. This is normal for business, but there is something quite different at work in the Open Source movement. At the heart of the Open Source community is the concept of cooperation. To do Open Source software, you need to cooperate with everyone. You need to cooperate with your friends, cooperate with strangers, and cooperate with… the competition! This is a frightening concept to some people. Why should I cooperate with my competition? My job is to beat them, not meet with them.

Coopetition and Real Intellectual Property The answer to this problem is the concept called coopetition. A term frequently employed by Ransom Love, CEO of Caldera, coopetition speaks to the need for companies to cooperate at one level, while competing at another. Both aspects are essential for doing business in the Open Source world. The concept, though, is not foreign to businesses, even outside the Open Source marketplace. For example, there are computer manufacturers that purchase IBM-brand disk drives. These drives are then integrated into the manufacturer’s computer systems which are then sold to customers. During the sales cycle, it is not unusual for that manufacturer to go up against IBM in attempting to make the system sale. So IBM is both a partner and a competitor for that manufacturer. It all comes down to the level at which the two companies interact.

12 1989-6 CH08

102

8/21/00

1:12 PM

Page 102

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The same is quite true in the Open Source marketplace. At one level, two companies may compete head-to-head for a customer’s business of one type or another. But at another level, the same two companies may have people collaborating on improving an Open Source project. Both companies will benefit from the efforts that either company puts into the project. This is especially true for the companies that sell and service Linux software distributions. For example, Red Hat employs a number of key developers including Alan Cox, regarded as the right-hand man of Linus Torvalds. When Alan works on changes to the Linux kernel, the code is available both to Red Hat and to every one of Red Hat’s competitors. Alan’s work goes straight into the general body of code which is Linux; none of it stays as proprietary extensions for Red Hat alone. This pattern is repeated time and again in the Open Source companies. Many distributions make use of Red Hat’s package manager that simplifies software installation. When Red Hat makes enhancements to the software, the enhancements help everyone who uses them— including Red Hat’s competitors. Since the software is available freely, Red Hat does not make one penny of profit from other people using its code.

Real Intellectual Property In many companies, however, the code created by technical employees is considered the intellectual property (IP) of the company. For technical employees of multiple companies to cooperate on project development, the companies appear to be sharing intellectual property. But does this apparent sharing of intellectual property with competitors run counter to the established norms of business? It might not, especially if the “valuable intellectual property” is not actually “valuable” at all. So what is “valuable intellectual property” anyway? From a business perspective, intellectual property is only truly valuable if it significantly impacts your profitability or that of your competition. For example, let us assume that you are the manager of a department store. The architectural drawings of your building which your company built can be considered your company’s intellectual property. Your company paid for it, and it probably cost a fair amount of money. Yet, for most companies, that intellectual property is not particularly valuable. The profitability of the corporation would not be reduced if your competitor were to obtain the plans. Nor would your competition likely experience a sudden increase in revenues or customer satisfaction if they were to obtain your building’s design documents. The fact is that unless you are in a real estate–sensitive business (like hotels, for example), no one cares about your building. Likewise, unless you are in the software business, it is highly unlikely that anyone will care about your software. And it is unlikely that the software which makes up your computing infrastructure will impact your bottom line. Undoubtedly, someone will cry foul over this statement. They will point to a massive integrated database system which cost some company millions of dollars to install over a long period of time. The system had to be customized for the company, and all sorts of business rules, data flow diagrams, and relationship models had to be meticulously defined. The enormous cost and multiple man-years of development supposedly will be dwarfed by the

12 1989-6 CH08

8/21/00

1:12 PM

Page 103

Chapter 8 • COOPERATE WITH THE COMPETITION? ARE YOU NUTS?

expected return on investment (ROI). So, this unquestionably must be a case where the software is valuable intellectual property. Or is it? Is it really the case that the software in this case represents valuable intellectual property? At first blush, that may seem to be the case. But that perspective may not hold up under closer scrutiny. The company in question ordered some expensive software and contracted for some very expensive consulting work to implement the software according to the needs of the corporation. The basic software may have been expensive to purchase, but without the customizations, it would never perform the tasks for which it was procured. So, clearly, the base software alone has limited value. If your competitor obtained the very same basic software, would they automatically realize the promised benefits of the software? No. Without the customizations, no real benefit can be experienced. And what is the value of these customizations, anyway? If your competitor with the same basic software received a copy of your customizations, would they encounter the benefits promised to you? Probably not. The customizations were designed for your company’s workflow and practices. It was not designed to complement your adversary’s means of operation. So the basic software is worth little without the customizations, and the customizations are worth little unless they are designed for the company in question. Where, then, is the valuable intellectual property? My contention is that the real intellectual property is the talent of the individuals who create the customizations needed to fit the corporate situation. After all, if the basic code and the customizations are not inherently valuable, it must be the people who create the solution out of all the parts who supply the real intellectual property. In companies working in the software industry, there may be some intellectual property built into the code. But that intellectual property derives from the value of their employees; it would never exist without the talents of the employees. Furthermore, this code-based intellectual property will have a very short shelf life. The state of the art in computing moves so rapidly that today’s hot software will probably find itself in the clearance bargain bin sometime next year. The valuable intellectual property within a typical software program will remain valuable only if more new intellectual property is added to it at regular intervals. In most companies outside the software industry, intellectual property has little to do with code. Indeed, it has never been about the code. The people are the truly valuable assets. This fact has been apparent for years. When competitors seek to improve their technology situation, what do they do? Do they steal the code of their competitors? Do they search through the trash for printouts? No, they hire new talent for the technical staff. Or, perhaps, hire away the competitor’s technical staff. Many companies run the exact same software on the exact same hardware as their competitors. Yet, one company might have an excellent command of its revenue and inventory situation, while another company may be utterly clueless. Why? Because the first company knows how

103

12 1989-6 CH08

104

8/21/00

1:12 PM

Page 104

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

to use all that software to its advantage, while the second does not. It is the people—not the hardware or the software—who make up the real value. The truly valuable intellectual property lies in the minds of the staff who understand what to do. Therefore, a smart corporation will seek to retain its talented workers, rather than wasting time protecting ancillary code. The value of people is incredibly apparent in the software-consulting market. As a professional consultant for many years with Compaq Computer Corporation and Digital Equipment Corporation, I know firsthand that smart corporations are willing to pay extra for consulting companies that bring intelligent people in the door to solve problems. Where I live in the Washington D.C. area, many consulting companies are available to install common IT solutions like Microsoft Exchange. Many smaller companies offer lower prices than the big-name companies do. Yet the bigger consulting companies frequently win out over the smaller companies. Why? The software is the same regardless of whether it is installed by a Fortune 100 consulting company or by a company that works out of the owner’s spare bedroom. The key difference is the knowledge, experience, and expertise that the larger company brings to the table. And that knowledge, experience, and expertise is contained in the minds of some very talented people.

Misunderstanding Intellectual Property Many years ago, I worked for a large company that had acquired a number of corporate properties. About 35 of these business properties had been given a minicomputer containing software systems to handle various aspects of the business: payroll, general ledger, billing, and the like. The time came to upgrade the operating system on these minicomputers to something more current. As a member of the corporate staff that oversaw the operating system upgrade procedure, I began to speak with the people in charge of the applications to make certain that there would be no serious issues with performing the upgrade. Most applications appeared to be ready for the upgrade with no problem. But there was one application which was a problem. This application was one which was very particular to the business. It could not be easily replaced with some third-party software offering. As I examined the application, it was clear that the upgrade would not go smoothly. It used some utilities in the operating system which I knew would change in the new version. When I began to inquire about how much work it would take to convert the code, I was not prepared for what I heard. It seems that this homegrown piece of software was a mess. It used a number of brutal coding mechanisms to get the job done. Even worse, the application compromised system security. It left passwords sitting in files for everyone to see. On top of that, the code was never designed to take into account all the variations that were employed by the various business properties, so each copy of the software was custom-patched by the developer to do the job differently at each site. But the situation got even more interesting. There was no record of what patches were installed on what site. Source code for the patches might or might not exist. Knowledge of what was done and where was restricted to the gray matter in the head of the lead developer.

12 1989-6 CH08

8/21/00

1:12 PM

Page 105

Chapter 8 • COOPERATE WITH THE COMPETITION? ARE YOU NUTS?

I took this information to one of the senior managers in the IT department. Under the circumstances, I suggested that plans for a simple upgrade might not be appropriate. A better solution would be to rewrite the application entirely. Make it configurable, so that each site could run it their way without needing custom patches. Make it secure, so that the highly sensitive data contained on the machines could not be stolen by any disgruntled employee or by any malicious teenager with a modem. Make it less brutal, so it would not break with every operating system upgrade. Make it documented, so everyone else would have an idea what was going on. Make it transportable, so that when the current line of minicomputers was replaced as planned in a few years, the application would have a chance to survive. I still remember the response I received. “Rewrite it? Why it took over five years to design that software! It is far too complicated to rewrite!” The manager then spent several minutes explaining to me how valuable that software was and why it was inconceivable to enter into a rewrite. I already knew enough about the application to be certain about one thing: It had never been “designed.” It may have taken the developer five years sitting in his chair to code the mess which was the application, but it had none of the earmarks of “designed” software. Furthermore, the five years cited were most likely the result of a lack of design in the first place. The application simply was not big enough to take anywhere near five years to code. A hefty amount of manpower would be likely to be needed to keep this maintenance nightmare intact in the years ahead. And, try as management might to claim it was “too big” of a job to rewrite, it would have to be done in a few years anyway, when the corporate timetable demanded that the current crop of minicomputers be replaced with an entirely new type of processor. The crux of the matter was that the management failed to understand where the intellectual property in this case really was. It was not in the awful piece of code that could cost the company untold grief for the rest of its life. It was in the brain of the lead developer who actually understood the business process, but was not particularly clever about bringing it into practice. The intelligent move would be to couple the brain of the developer with the brain of a truly talented program designer and let them lay out a design that would fit the needs of the application while also fitting the needs of useful, maintainable, and secure software. Instead, they chose to treat the poor application as the valued property. If their lead designer ever decided to walk out the door, however, they would quickly find out that the software was of much less value than the designer.

Sharing Code Increases Real Value to the Corporation But, if the valuable intellectual property is actually in the employees rather than in the software, is it not foolish to let employees work on Open Source projects where others—including your competition—will benefit from their efforts? At first, this might seem like a valid concern. But, in the end, the exact opposite is true. Consider again the fact that many companies run their operations on the same basic software systems. If the software improves, will their business situation improve? This is akin to asking whether a person building a house will do a better job if he upgrades his hand tools to power

105

12 1989-6 CH08

106

8/21/00

1:12 PM

Page 106

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

tools. If the workman has the talent, upgrading the tools will simply make the job easier. If the workman is inept, more powerful tools will not help productivity. Likewise, better software only helps if the user already knows how to get the job done. So the key is the knowledge of the person, not the power of the tool. If a business has a talented staff, improving the software tools will improve its efficiency and the quality of the results. If a business lacks a talented staff, it is likely to have problems regardless of what tools it employs. So, allowing your talented people to submit code to Open Source projects will definitely benefit you. If your competitor has a talented staff, they will have the opportunity to improve along with you—no one gains, no one loses. If the competitor has a weaker staff, however, you will widen the gap between you. So, again, you see benefits from maintaining a talented group of people. And, of course, if your competitor is too stuck in its ways to use Open Source software at all, you stand to gain much, since your competitor needs to wait for its software supplier to give it what it needs—if the vendor decides to supply it at all, that is. But this is only part of the Open Source picture. Giving your people an opportunity to work with Open Source software allows you to benefit from their insights. But it also allows you to benefit from the technical improvements of everyone else working on the project as well. Your talented people will be able to make use of the enhancements that others submit to the project as well. These improvements come at no cost to your company, yet your staff will be able to use these tools to better your corporate situation.

Defining Coopetition Coopetition, therefore, is not the process of handing valuable intellectual property to your competitors. It is the way in which you cooperate with your competitors on things that are not central to business in order to better prepare yourself to compete on matters which are central to business. From a strictly business standpoint, it is the process of sharing the unimportant in order to compete over the important. Let the technical people work on Open Source projects. Encourage them to do so. Pay them to do so, when it makes sense to. They will improve the tools they use to do their jobs. As the tools improve, the technical person can spend less time doing grunt work and more time devising ways to give you better support for your business. That is the real value they add to the organization: technical knowledge applied to your corporate circumstances to yield better results in your business. I have seen this many times over my years as a professional software consultant. The best consultants learn to master whatever tool kits are appropriate to perform the job at hand. As the mastery of tools improves, less time is required for mundane tasks and more time available to devise more efficient ways of handling problems. So, the better the tools in the hand of a talented technical person, the better the overall results. It is important to remember that in the age of the Internet, business computing is no longer a cost center; it is a profit center. Few businesses can afford to ignore the competitive position that a compelling Web site brings. And many businesses need a substantial e-commerce

12 1989-6 CH08

8/21/00

1:12 PM

Page 107

Chapter 8 • COOPERATE WITH THE COMPETITION? ARE YOU NUTS?

presence just to keep from losing ground to competitors. Computer systems are no longer the necessary evils that data center–based accounting and inventory systems once were. Internet servers are now the necessary road to greater revenues and higher profits. Facilitating the task of keeping the servers productive is not an option. If the servers go down, your profits go with them. When your Web site ceases to respond to user requests, it is as if you were running a retail store which closed for no reason while patrons were walking around the store. The more times you leave someone wanting to buy an item but unable to do so, the more likely it is that you will lose customers. And, if the servers are too slow or too overworked to serve pages in a timely fashion, it is like a store where the help is inattentive and aloof, preoccupied with other things. Customer satisfaction will not remain acceptable for long, and dissatisfied customers will rapidly become former customers. A key to success, then, is to retain a good technical staff to keep the servers running well and equip them with the tools needed to do the job expediently. This is the place where Open Source excels. Talented people on your staff can gather with other talented people and create the tools that do exactly what is needed to be done. Once the tools are in hand, it is up to the various businesses to compete at the level where business is really done: at the level of the store.

The Open-Source Advantage A natural question at this point is this: If it is important that the technical people have excellent tools at their disposal, would it not be better to develop these tools in secret and reap the benefits in private? After all, if good tools are important to producing good technical results, why share them with the competition? The concept of hiding the code from the opposition sounds plausible, but it misses the mark in several ways. In actuality, the coopetition solution is superior in several ways: • Coopetition emphasizes the core business. As mentioned earlier, most companies are not in the software business. Why create a dedicated staff to design, implement, and test something that is not the core product of the company? It is better to let an independent project team handle the most of concerns of running and staffing the project. • Coopetition emphasizes the real intellectual property. As discussed earlier, the truly valuable intellectual property in most organizations rests in the brains of its talented employees. Investing heavily in a certain project develops the inaccurate sense that the project is the important intellectual property, rather than the employees. The more time and money that is spent managing, developing, and maintaining the project, the more the misconception will grow that the project itself is important to the corporation. By allowing others outside of the corporation to run the project instead, the tendency to place undue value on the project itself is avoided. • Coopetition reduces development cost. Building and managing an entire project team is an expensive proposition. Staffing, salaries, time, and management all cost serious amounts of money. Choosing instead to share the cost with other individuals and businesses through an Open Source project reduces the development cost significantly.

107

12 1989-6 CH08

108

8/21/00

1:12 PM

Page 108

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

• Coopetition reduces maintenance cost. After the software is created, it is likely that there will be a need to modify it from time to time as the business and the other software around it change. This will require retaining a staff of programmers experienced in the code for the duration of its useful life. In the Open Source model, however, the program maintenance is spread over the virtual team which extends beyond the confines of the company. • Coopetition reduces development time. In the age of the Internet, time is critical. The old saying “Time is money” has never been truer than it is today. It is not simply the case that time costs money, but that time unfulfilled loses money. In a world where a down Web site can cost thousands of dollars per minute, the cost of delaying an opportunity can be monstrous. So it is in the best interest of the corporation to obtain or develop tools as quickly as possible. The Open Source development model is amazingly adept at creating software quickly. • Coopetition increases robustness. With the importance of Web sites that must be available 24x7, robust software is essential. Software that is developed within a company needs to be tested and debugged. This can be costly and time consuming. And it can be even more costly if a bug appears while the software is in use. • Coopetition increases service and support. With the rapid change of technology, tools sometimes need to change rapidly to keep up. Having the ability to select an external vendor to service or support your tools reduces your exposure. With a homegrown solution, you are on your own for support. But with Open Source, you can actually get support from the project team or from outside vendors. In addition to these reasons, there are also a number of ways in which the Open Source coopetition model is superior to simply purchasing closed-source software: • Open Source can be guided into the proper direction. With commercial software, you are subject to the will of the producer regarding the focus and direction of program development. With Open Source, you can ensure that the software will meet your needs. • Open Source can be tailored to fit the need. With closed-source software, you are stuck with whatever functionality is or is not present. With Open Source, small changes to enhance usability can net big gains in productivity. • Open Source increases expertise. Working to develop Open Source software can make a technical person into an expert on that software. Having an expert on staff means wasting less time on hold when calling support people for answers when problems arise. • Open Source lowers cost. Closed-source commercial software can be quite pricey to purchase, upgrade, and support. Especially in very large organizations, the cost of deploying a set of expensive software to a large number of PCs can be very significant. The Open Source equivalents of the same solution will normally cost a small fraction of the price. • Open Source means vendor independence. Commercial solutions based on closedsource programs lock the user into relying upon on the software vendor. If there is any

12 1989-6 CH08

8/21/00

1:12 PM

Page 109

Chapter 8 • COOPERATE WITH THE COMPETITION? ARE YOU NUTS?

dissatisfaction with the vendor’s performance, the buyer cannot move on to another vendor without sacrificing much of the investment made in the current solution. Open Source solutions, however, are frequently supported by multiple vendors and often can be run on multiple hardware architectures. This gives the customer total control over the choice of vendors. • Open Source can increase public awareness of your company. As technical people participate in the Open Source process, the employers of these people receive positive press in the community. The technical donations of a corporation can yield free advertising for the company. • Open Source can attract geek workforce. As mentioned before, attracting and retaining good technical people is critical in the Internet age. Participation in Open Source projects can serve to attract technical people to your company. This is a subject I’ll explain in depth in Chapter 11, “The Primer: What To Do.”

Coopetition as an Potential Industry Standard The rise of the Internet has brought about many material changes to the world. As discussed at length in Chapter 1, “What’s Going On Here?” the Internet has brought about new means of communicating and new means of doing business. The old ways need to be reexamined to see whether they should be retained in this new way of doing business worldwide, 24x7, at Internet speeds. At the heart of business on the Internet is the concept of open standards. Companies cannot run amok doing whatever they want on the Internet any more than retail stores can do whatever they want along a freeway. There are basic rules that everyone must follow. For instance, someone might consider it profitable to tear up a major interstate and reroute the road so it passes by the front door of their store. That tactic might very well increase business, but such a practice would not normally be allowed by the government. The situation in cyberspace in this regard is not very different. There are basic rules for the common good that all must adhere to. The fact that all the competing stores along the highway agree to act within certain guidelines does not hinder their ability to compete. In fact, having a level playing field allows for better and fairer competition. For example, assume there is a small town with two main grocery stores in it. The owner of the first store wants to take business away from the second store. To this end, he devises a plan. He will pay people to park their cars in the other store’s parking lot, thus making it harder for paying customers to find parking spaces. This will cause people to become frustrated with the second store and come over to his store instead to do their shopping. Now, is he competing by doing such a thing? Yes. Could the owner of the first store conceivably beat his competitor by employing such a tactic? Yes. Is it the genuine type of competition that business should be engaged in? No.

109

12 1989-6 CH08

110

8/21/00

1:12 PM

Page 110

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

So competition without basic rules is not good. When the rules are followed, the resulting competition is healthy. When the rules are broken, the resulting competition is sick. It is the same way with Open Source coopetition. Cooperating in the production of software creates a level playing field, allowing the companies to compete in business in a fair and reasonable manner. Cooperation at the code level does not decrease the competition any more than a refusal to park cars in the opposition’s parking lot does. One of the most unexpected sidelines to adhering to a coopetition model is its effect on the IT budget. It used to be quite common to hear the complaint, “We cannot afford to add that feature! It is too costly!” It was also common to hear the cry, “We don’t have the staff to write that! And who will pay for the support staff we will need?” The solution many companies went toward in the 1980s and 1990s was to purchase commercial, closed-source software to do the job. Such commercial off-the-shelf (COTS) software became the mainstay of the corporate computing world. There was no longer a need to maintain large programming teams when COTS solutions were available. But the rise of COTS solutions brought a new type of grief with them. It was true that it was no longer necessary to hire and retain costly development teams, but it was also true that often times a company was at the mercy of what the software vendor was willing to provide. While this can be an acceptable trade off in software that supports the infrastructure of a business, it has already shown itself to be unacceptable in the Web software that drives the revenue for a company. The rise of the Internet also created the need for immediate solutions. A six-month delay in implementing certain “nice” computing features for internal use in a corporation was acceptable in the 1990s. But a sixth-month delay in implementing certain leading-edge e-commerce facilities on a Web site for customer use is unacceptable in the Internet age. It is imperative that software be created and deployed quickly, in order to keep pace with the rapidly changing Internet e-commerce market. A case in point: A few years ago, I was working with a project team at Compaq Professional Services that was charged with creating a working e-commerce prototype for a large organization. We were instructed that the Web site must produce certain forms displaying bar codes of a particular type. Time to market was absolutely critical, so we were given a short deadline to produce the functional prototype. If we had a working prototype, we could win a major contract doing the full implementation. If we could not produce the prototype in the time allotted, we would stand to lose the contract and our customer would be at risk for losing its window of opportunity to be the first to market with this Web-based solution. As the work commenced, it was clear that the bar codes could become the biggest technical sticking point. One person on the team was sent off to find commercial tools for printing the bar codes on the Web page. I was sent off to see if the Open Source world had what was needed to create Web page bar codes. After a few days of continuous searching, the other person came back with the disappointing news: He had spoken with every vendor of bar code solutions that he could find and not one

12 1989-6 CH08

8/21/00

1:12 PM

Page 111

Chapter 8 • COOPERATE WITH THE COMPETITION? ARE YOU NUTS?

of them would have the product we needed in time for delivering the prototype. Some vendors were working on their products for this type of solution, but they were still months from release. We would not have a commercial, Web-based bar code generator in time for the deadline. On the same day that word arrived that no commercial solution could be found, I demonstrated a test Web page I had created that generated bar codes on the fly using an unencumbered Open Source bar code library I had located. Eventually, this would become the bar code engine that would be used in the prototype. Back then, the conventional wisdom for creating software solutions was to use a COTS solution or resort to writing the code yourself if no COTS solution were available. But, in the age of the Internet, this has real drawbacks. Commercial products normally arise only after there is sufficient business reason to justify their creation. Then there must be development and testing. So the commercial implementations can arrive anywhere from six months to a year after the early adopters have set up shop on the web. If your competition happens to be one of those early adopters, reliance on a commercial solution can guarantee that your competitor is at an advantage for many months before you catch up. And, if you resort to writing your own solution from scratch, you have to deal with significant development costs as well as the time to create, debug, test, and employ the software. The coopetition model, though, is much better. It allows you to either capitalize on the work that others have done already or to start a new project where the work is shared by several companies, thus reducing cost and time to market. Either way, the net result is faster implementation and smaller cost of the solution. Both are critical factors in today’s Internet economy. And that means you have a chance at competing and winning. You cannot do that while you are waiting for software to be developed. As the industry continues its trek to the Internet, then, it is clear that coopetition will arise at some point among the best practices of industry leaders. Coopetition, linked with Open Source methods, enables a corporation to move more swiftly and nimbly than traditional closed-source approaches normally allow. Coopetition, then, is likely to appear as the industry standard for companies that need to move as quickly as the Internet itself moves. It is the potential standard for companies that need to move at Internet speed.

111

12 1989-6 CH08

8/21/00

1:12 PM

Page 112

13 1989-6 CH09

8/21/00

1:11 PM

Page 113

CHAPTER 9

THE PLAYERS: WHO DOES WHAT AND WHY

T

he world of Open Source development is filled with people, places, and groups that perform vital functions in the community. To fully benefit from Open Source, it is essential to understand who the people are, where the places are, and what it is that

they do.

In many ways, this is a very difficult list to assemble. The problem is not in listing people and groups of significance, but in knowing who and what to leave out. The Open Source community is vast, with an incredible number of leaders, contributors, projects, and forums. This chapter will barely graze the surface of the names worth knowing. But it is far worse to not discuss the details at all than to risk omitting people and places that should have been mentioned. It should also be noted that the information contained herein is likely to be very time sensitive. It is likely that some information will have changed between the time this book was written and the time it was published. This must be expected. But the names and information given in this chapter should serve as a useful background for people needing a fast overview of the people and players within this remarkable community.

The Leaders The Open Source community has numerous leaders. Many lead projects, some lead media efforts, and still others lead organizations. The list of leaders is gigantic, given the number of projects that exist. Some people are very key players in the community. Their names appear over and over in discussions and in the trade press. The following list is meant to identify some of these key folks. The list cannot be considered exhaustive in any sense, since an enormous number of people have done much for the community and many of them are very well known for their areas of expertise. Presented in last name order, here are the names of some key people in the Open Source world.

13 1989-6 CH09

114

8/21/00

1:11 PM

Page 114

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Alan Cox Alan is best known as the right hand of Linus Torvalds. A man with a long résumé of Linux kernel coding, Alan has taken a lead position in kernel development. He is employed by Red Hat to do Linux kernel development.

Jon “maddog” Hall maddog is the executive director of Linux International. A consummate Open Source advocate, maddog probably travels more extensively than anyone else in the Open Source world. He travels the world seeking to promote the use of Open Source in education, in business, and in the home.

Bruce Perens Bruce has been involved in the Open Source Initiative and Software in the Public Interest, and he is a former leader of the Debian distribution. A frequent writer and speaker, Bruce is one of the knowledgeable people in the movement regarding licensing. He currently heads up a venture capitalist group that funds Open Source startup companies.

Eric S. Raymond Author of the landmark work The Cathedral and the Bazaar, Eric is the primary traveling philosopher of the Open Source movement. One of the founders of the Open Source Initiative, Eric has spoken to numerous corporations and groups about using Open Source software. Among his most requested topics is his dissertation on how companies can write Open Source software and still make money.

Richard M. Stallman The founder of the Free Software Foundation and the GNU project, Richard is the highly vocal spokesman for the free-software movement, which is separate from but related to the Open Source movement. Often called “RMS” after his initials, which often populate his code, he also writes position papers and speaks at gatherings worldwide about the need to produce free software. Even those who disagree with his conviction that all software must be free respect his position as the conscience of the community.

Linus Torvalds The originator of the Linux project, Linus is one of the most recognized figures in the computer industry today. He functions as the chief engineer for the Linux kernel and is responsible for approving any design changes to the kernel. He works for chip manufacturer Transmeta.

13 1989-6 CH09

8/21/00

1:11 PM

Page 115

Chapter 9 • THE PLAYERS: WHO DOES WHAT AND WHY

The Distributions Since the Open Source software can be freely shared, it is natural to see different groups use it in different ways. For companies distributing the software, it is expected that they will package the software with a particular type of use in mind. In the Linux community especially, one finds a number of different distributions focused at solving different problems. The software contained in each distribution is largely the same, but an emphasis is placed on different areas. For instance, some distributions place emphasis on server applications, whereas others are interested in the desktop. Some have focused on extensive multilingual support, while others have focused on a nifty installation process. The net result is not split in the code but is merely a difference in flavor. It is essentially impossible to pick a “wrong” Linux distribution for a job, but you may find that certain distributions address your concerns more clearly than others. The case is different in the BSD world, where parts of the code can be significantly different from distribution to distribution. This is a result of the BSD license which does not require people to make all changes to the source code available to the community. In the Linux world, there is also the notion of an “official” distribution and a “GPL” distribution. An official distribution often comes with a an official installation or reference manual, some installation support, and sometimes test-drive software from closed-source application companies. A GPL distribution, however, is the same code available for free from the provider’s FTP site. There is no manual or support or additional software, but there is a fully functional operating system. Many Linux vendors will sell CD-ROMs containing the GPL distributions for a dollar or two per CD-ROM. Also, many third-party Linux books will include a GPL CD of a particular Linux distribution. The Linux world also has the concept of the meta-distribution. In a meta-distribution, the GPL distribution of one vendor is taken and enhanced and rereleased. This method is generally used for very particular reasons, such as the circumstances discussed in the Mandrake distribution listed below.

Caldera OpenLinux (www.calderasystems.com) Born out of the plans of a research team at Novell, Caldera OpenLinux was one of the first Linux distributions to focus on business desktop solutions. Even in 1997, Caldera was promoting the concept that Linux could sit on corporate desktops. Caldera believes in bundling commercial software with its offerings when doing so will produce a better business solution. Although Caldera has produced free software with and for the community, its willingness to embrace commercial software often keeps many people in the community from being overly warm toward the company. The distribution is also known for its emphasis on NetWare connectivity. CEO Ransom Love is a frequent keynote speaker at Open Source conventions.

115

13 1989-6 CH09

116

8/21/00

1:11 PM

Page 116

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Corel Linux (linux.corel.com) Corel Linux is a relatively recent entry into the distribution market. Corel’s main selling point is the port of Corel Office Suite, featuring WordPerfect, to Linux. Corel sells bundles of Corel Office with Corel Linux to create an inexpensive, easy-to-install office desktop solution. Corel Linux was originally a version of Debian that was equipped with a simplified installer and a focus on desktop, rather than server, systems. Corel’s main contribution to the community has been in the area of the Wine project, discussed later in this chapter. Corel’s emphasis on selling its closed-source office suite does not ingratiate the company to the members of the freesoftware movement.

Debian GNU/Linux (debian.org) Of all the distributions listed here, Debian is the one that most closely aligns itself to the ideals of the free-software movement. The official Debian distribution carries nothing but software that fits the definition of free software as defined by the Free Software Foundation. It is also the only distribution in the group that officially uses the name GNU/Linux rather than just Linux. Official Debian distributions can be manufactured by anyone who will use the approved CD image. Official Debian distributions are often sold with a small donation bundled into the price, so that Debian will receive some funding from the sale of the CDs.

FreeBSD (freebsd.org) FreeBSD is a project that grew out of the original Berkeley Software Distribution of Unix. FreeBSD is known for its excellent network performance and it is used to power many Internet Web servers. It receives high praise in situations where network performance and security is especially critical.

Linux PPC (linuxppc.org) A native port of Linux to the PowerPC platform, Linux PPC brings Linux to some Apple Power Macintoshes, some IBM RS/6000 systems, and some embedded Motorola processors, as well as other compatible systems.

Linux-Mandrake (linux-mandrake.com) Originally a meta-distribution of Red Hat Linux, Mandrake has become a distribution that focuses on ease of use and multinational usability. With offices in both the United States and France, Mandrake takes a much broader view of the world than many U.S.-based distributions. One of Mandrake’s most visible contributions to the Open Source world is DiskDrake, a piece of software that is used to nondestructively shorten an existing Windows partition during installation to allow Linux to be installed on a Windows disk.

13 1989-6 CH09

8/21/00

1:11 PM

Page 117

Chapter 9 • THE PLAYERS: WHO DOES WHAT AND WHY

NetBSD (www.netbsd.org) NetBSD is a highly portable version of BSD. It runs on a very wide variety of hardware platforms.

OpenBSD (openbsd.org) OpenBSD is a BSD system that was developed to emphasize security, standards, and portability. It contains integrated cryptography, since as a Canadian organization, it is not subject to U.S. export rules.

Red Hat Linux (www.redhat.com) Generally regarded as the most popular Linux distribution in the United States, Red Hat is a flexible distribution which is found on everything from servers to laptops. Red Hat has been actively supporting the community for years and was the first x86-based distribution to branch out onto both the Alpha and SPARC hardware architectures. Red Hat boasts a staff of highly respected kernel hackers, including the likes of Alan Cox and Stephen Tweedie. Chairman Robert Young is one of the most quoted executives in the industry that has grown out of the Open Source world.

Slackware Linux (www.slackware.org) One of the oldest Linux distributions, Slackware was the effort of Patrick Volkerding to gather the various programs needed to build a running system into one location. Many people who ran Linux in the middle 1990s have clear memories of downloading Slackware from the Web. Installable via floppies, Slackware was very popular before the rise of CD distributions. In the late 1990s, Slackware was eclipsed by many of the other distributions and it looked for a while like Slackware’s time had passed. But, surprisingly, there seemed to be a mild upsurge in the popularity of Slackware since 1999, which seems to have revived interest in the distribution. Slackware is still a favorite of people who need to squeeze Linux into a small amount of disk space or who need to install the operating system from floppy disks. It is also quite popular among people who like to have full control over placement of files on a system.

Storm Linux (stormlinux.com) A relatively new distribution, Storm Linux is the product of Stormix Technologies. Like Corel, it is a variant of the Debian distribution with an improved installer and added desktop usability features. It also includes a modular administration framework for improved system administration.

SuSE Linux (suse.com) Frequently regarded as Europe’s favorite Linux distribution, SuSE arises from Germany. Its European roots have made it strong in multilingual situations. SuSE has recently begun to become more prominent in the North American market. It has also branched out into the Alpha architecture.

117

13 1989-6 CH09

118

8/21/00

1:11 PM

Page 118

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

TurboLinux (turbolinux.com) Originally known as Pacific HiTech, TurboLinux is currently the prevailing Linux distribution in Japan and has begun making inroads into China. TurboLinux offers clustering software as a closed source add-on. In its business model, the code will be opened at a future time.

Yellow Dog Linux (yellowdoglinux.org) Yellow Dog Linux is another version of Linux for the PowerPC platform. It is available in server, workstation, and home versions.

The Reference Sites and Repositories A number of Web sites contain pointers to source code or basic information on how to use Open Source software. These are the repositories and reference sites. Although there are quite a number of these, a few of the best known are listed here.

Freshmeat (freshmeat.net) Part of the Open Source Development Network (OSDN), Freshmeat is one of the first places that many people go to look for software. Software releases and updates are announced here, usually within minutes or hours after they are made public, and links to information pages and downloadable files are kept here. It can be accessed both by a category-tree structure as well as through ad hoc searches. It also features guest editorials on Open Source software issues.

Kernelnotes (kernelnotes.org) Kernelnotes acts a repository and information center for Linux kernel development. It generally points to the latest stable and development kernels, as well as giving information on the latest additions to the kernel.

Linux.com (linux.com) Linux.com is another OSDN Web site with many articles explaining how Linux works. It also includes news, user group listings, newbie information, and more.

Linux.org (linux.org) Linux.org is a general starting place for learning about Linux. It contains many pointers and articles about basic issues, such as “Where did Linux come from?” and “How do I obtain the software?” It is one of the older Linux reference sites on the Web.

13 1989-6 CH09

8/21/00

1:11 PM

Page 119

Chapter 9 • THE PLAYERS: WHO DOES WHAT AND WHY

LinuxApps (linuxapps.com) LinuxApps is similar in function to Freshmeat. A property of Internet.com, it has a slightly smaller database of applications than does Freshmeat but still maintains information about thousands of software releases.

Linuxresources (linuxresources.com) Hosted by Linux Journal, the Linuxresources Web site is one of the longest-running Open Source reference sites on the Web. It contains pointers to users’ groups, documentation, and news sites, as well as numerous other pieces of useful information.

The Watering Holes Every community needs a place to gather and talk. In the Open Source world, there are a number of virtual watering holes where people come to talk to one another about the matters which concern the community. Some of these include Internet Relay Chat (IRC) channels and mailing lists. Others are Web sites, some of which are listed here.

Slashdot (slashdot.org) Described as “the water cooler of geek culture,” Slashdot is the place where many members of the Open Source world meet to chat about things that interest them. A number of news stories are posted each day, and the response to them can range from a few dozen comments to several hundred comments per story. The discussions are often animated, and if someone makes absurd claims, there may be some rather rude remarks mixed in. But Slashdot frequently reveals many of the current issues which are important to the community. Slashdot is an OSDN Web site.

Linux Today (linuxtoday.com) Primarily a news and information site, Linux Today also has discussion areas attached to articles. While the discussions are nowhere near the size of those found at Slashdot, they do tend to display the attitudes of the community concerning important issues. Linux Today is an Internet.com Web site.

OS Opinion (osopinion.com) While not focused entirely on Open Source issues, OS Opinion is a Web site which publishes opinion papers from the community. As such, it tends to highlight many of the key issues being discussed in the community. Its format frequently causes people to write papers seeking to convince others of their perspective, so it is a mistake to assume that the positions taken by the authors necessarily represent a majority of the community.

119

13 1989-6 CH09

120

8/21/00

1:11 PM

Page 120

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The Online Media The Open Source community has developed its own sources for news and information. There are a large number of online media outlets in the community, spanning many languages and nationalities. Most were started as the project of a few motivated individuals. Some of the best ones have been purchased by larger media companies. A sampling of some of the most wellknown media Web sites are listed below.

Apache Today (apachetoday.com) A property of Internet.com, Apache Today is an excellent place to find Apache Web server news and articles. Many of the articles are written by members of the Apache core team.

BSD Today (bsdtoday.com) BSD Today is place where BSD news items are posted as they occur. People involved with BSD will find it useful. It is an Internet.com property.

Linux Orbit (linuxorbit.com) Linux Orbit is a news and reviews Web site. It does carry some interesting original content as well as headlines from other services.

LinuxPlanet (linuxplanet.com) Another Internet.com Web site, Linux Planet features some good original content.

LinuxPR (linuxpr.com) An affiliate site of Linux Today, LinuxPR is an excellent location to find Linux-related press releases. Some are from top-tier computing companies, but many are from various Open Source companies. LinuxPR allows companies large and small to issue press releases to the community without incurring the costs normally associated with most press releases.

The Linux Show (thelinuxshow.com) The lead show of the Geekcast Network, the Linux Show is currently a weekly hour-long Web cast which features the opinions and analysis of host Jeff Gerhardt and company. Although occasionally there have been and still are Web casts from other sources aimed at the geek world, the Linux Show is the most consistent geek Web cast, both in frequency and in content.

Linux Today (linuxtoday.com) As mentioned in the Watering Hole section, Linux Today is a news and information Web site. It is perhaps best known by the sheer quantity of stories it carries on a given day. During the work week, it is not unusual to see over 50 stories per day posted to the site. Linux Today is an Internet.com property.

13 1989-6 CH09

8/21/00

1:11 PM

Page 121

Chapter 9 • THE PLAYERS: WHO DOES WHAT AND WHY

Linux Weekly News (lwn.net) Linux Weekly News was one of the earliest Open Source news sites. Unlike many newer sites, it has no facility for reader discussions, but it is widely respected for its solid news coverage. Of special note is Elizabeth Coolbaugh’s listing of Linux distributions, known and unknown. Linux Weekly News is a property of Tucows.com.

LinuxWorld (linuxworld.com) LinuxWorld is one of the few Web sites that actually originated as an effort of a major computer industry publisher. Most other Web sites listed here were started by independent people and groups and later purchased by larger media concerns. LinuxWorld is an IDG Web publication and features the work of Nicholas Petreley, a well-known author and commentator in the computer industry.

RadioWallStreet’s Linux League (radiowallstreet.com) RadioWallStreet features a regular Web cast called “The Linux League.” It features guests and opinions from the Open Source community. Unlike The Linux Show, this show is aimed more at the businessperson rather than the geek.

Slashdot (slashdot.org) As mentioned above, Slashdot is a main gathering place for the community. The discussions normally revolve around articles posted on the Web site. Unlike many strictly news sites, the number of articles posted in a given day may be relatively small, but the discussions that they spawn are normally much more sizable than those found at other sites. Slashdot is an OSDN property.

Technocrat (technocrat.net) Technocrat is a news and opinion Web site, featuring the work of Bruce Perens. This site tends to highlight issues that Bruce considers important for the community. It tends to be both challenging and informative.

WideOpen News (wideopen.com) WideOpen News is an independent news Web site owned by Red Hat. It started publication in 1999 under the guidance of renowned journalist Russ Mitchell. Unfortunately WideOpen felt the need to scale back operations in the beginning of the following year. As of this writing, it does not carry much original content.

121

13 1989-6 CH09

122

8/21/00

1:11 PM

Page 122

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Magazines Even in the age of Internet communication, it is sometimes helpful to have hard-copy magazines to supplement the delivery of information. This section contains a few of the more dedicated magazines.

Linux Journal Linux Journal was the first actual Linux magazine. It began publication back in 1994 and has been focused on the needs of the technical community since its inception. It normally features articles which are very technical in content. Its publisher, Phil Hughes, is well-known in the Open Source community.

Linux Magazine Linux Magazine began publication in 1999 and has been gaining credibility in the community. Rather than focusing on the strict technical content like Linux Journal, Linux Magazine is a bit more generalist in nature. It features interviews and perspectives on Open Source topics.

Maximum Linux Maximum Linux is a new magazine which is still building its reputation in the community. It is currently published bimonthly and features a CD-ROM with each issue.

Open Magazine A new magazine from the Open Source Development Network, Open Magazine is one of the first “free subscription” periodicals to hit the Open Source world. At this writing, the first edition has yet to be published, but its arrival is greatly anticipated in the community.

The Development Facilitators New means of supporting production of Open Source software appeared during 1999. Some of these paired Open Source developers with businesses that were willing to fund some software development. Others simply gave developers access to free tools to make the job of running a project go more smoothly.

Collab.net (collab.net) Collab.net is an effort to bring together Open Source developers with companies in need of software. Projects are proposed by the companies and then developers sign on to do the work. The result is that the companies receive the software they need and the developers are paid for their efforts. The Web site used to facilitate this interaction is called SourceXchange. Collab.net was cofounded by Brian Behlendorf, one of the main Apache developers.

13 1989-6 CH09

8/21/00

1:11 PM

Page 123

Chapter 9 • THE PLAYERS: WHO DOES WHAT AND WHY

Cosource (cosource.com) Cosource is a Web site where one group of people proposes a project and puts up some money, while another group of people volunteers to implement the project. Businesses and people which fund projects normally experience a very high return on investment, while developers get the opportunity to make some money working on the projects. The resulting code is released under a suitable Open Source license.

SourceForge (sourceforge.net) SourceForge is an OSDN hosting location for Open Source projects. It gives project teams free access to most of the infrastructure tools required to run an Open Source project. These tools include a Web site, mailing lists, source trees, bug tracking systems, message forums, and code backups, among other things. There are thousands of projects using SourceForge to facilitate development.

The Online Stores There are a number of Open Source related stores in the United States and across the world. The list below is meant to be a short list of some of the better known U.S. stores. These are by no means the only vendors selling Open Source–related goods. The entries below are not meant to list the complete lines of business for each of the companies listed. They are meant to be a quick summary of some of the goods available for these vendors. Please refer to the vendor Web sites for more information.

Cheapbytes (cheapbytes.com) Cheapbytes sells both official CD distributions, GPL versions, and books.

Copyleft (copyleft.net) Copyleft specializes in clothing items adorned with Open Source logos and slogans.

Linux Central (linuxcentral.com) Linux Central sells official CD distributions and GPL versions, as well as books and some novelty items.

LinuxMall (linuxmall.com) LinuxMall and the Linux Store recently merged. The result is a vendor that sells everything from software to hardware and clothing items. LinuxMall also includes a news site.

Linux Systems Labs (lsl.com) Linux Systems Labs sells official CD distributions and GPL versions.

123

13 1989-6 CH09

124

8/21/00

1:11 PM

Page 124

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The Systems Vendors A growing number of top-tier computer systems vendors have begun certifying and shipping systems equipped with Open Source software. IBM, Compaq, and others have been announcing programs in this area. But many vendors have arisen who focus largely on the creating and selling systems equipped with Open Source software. Some of the more notable companies are listed here.

Atipa Linux Solutions (atipa.com) Atipa sells systems Linux systems built on x86 and Alpha architecture. It also creates and sells Beowulf clusters and network appliances. It is creating important Web content through its Linevents and Lintraining Web sites.

Penguin Computing (penguincomputing.com) Penguin Computing sells Linux x86 servers and clusters. Sam Ockman, well known for his Linux activities, is CEO of the company.

VA Linux Systems (valinux.com) VA Linux Systems sells x86 Linux servers and clusters. VA has a very large presence in the community, due to its acquisition of Andover.net. (including Slashdot and Freshmeat) and its hosting of Web sites like SourceForge. CEO Larry Augustine is one of the best known CEOs in the Open Source world.

The Software Developers A large assortment of commercial software companies have begun porting software to Open Source platforms. Names like Oracle, Informix, Computer Associates, IBM, Compaq, and others have ported some of the best-known closed-source software in the industry to Open Source operating systems. But other companies have arisen to try to create Open Source applications while still making money. A few notable entries of the latter are listed here.

HelixCode (helixcode.com) Founded by Miguel de Icaza and Nat Friedman of the GNOME project, Helixcode is creating free software to complement the GNOME desktop. Some very ambitious projects are underway to create software that will make it possible for both corporate and home users to have as much functionality in a free-software desktop as currently available through current closedsource products.

13 1989-6 CH09

8/21/00

1:11 PM

Page 125

Chapter 9 • THE PLAYERS: WHO DOES WHAT AND WHY

Lutris Technologies (lutris.com) Lutris Technologies is the creator of Enhydra, an Open Source Internet applications server. It offers support and consulting services to allow companies to implement Enhydra-based solutions.

OpenSales (opensales.com) OpenSales is a creator of Open Source e-commerce software. They offer support, installation, and customization services.

Sendmail (sendmail.com) Sendmail maintains the Open Source sendmail program, as well as certain closed source addons. Revenue is derived from the add-ons, as well as from technical support and professional services.

The Other Businesses There are other businesses which support the Open Source world as well. A few prominent ones are show here.

Open Source Development Network (formerly Andover.net) Although it was acquired by VA Linux Systems, OSDN still functions as an editorially independent entity. Formerly known as Andover, it boasts some very popular Web sites such as Slashdot and Freshmeat. It also claims some key talent, such as Robin Miller, Rob Malda, and Jeff Bates.

International Data Group (IDG; Media Company) IDG is the computer industry media corporation that publishes the Web magazine LinuxWorld. It also organizes the LinuxWorld Expo, which set a record for an Open Source expo by drawing over 20,000 attendees to one of its shows at the beginning of 2000.

Internet.com (Online Media Company) A company which has acquired a number of key Open Source Web sites, Internet.com is the chief rival to OSDN in key Linux news sites. It features a number of important Web sites including Linux Today, Linux Central, and LinuxStart.

125

13 1989-6 CH09

126

8/21/00

1:11 PM

Page 126

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Linuxcare (Support and Services Company) Linuxcare offers a number of support and consulting services in the Linux arena. It has made a number of support agreements with large companies as well as offering services for individuals and small businesses.

O’Reilly (books and conferences) Well known as a publisher of technical books, O’Reilly features a large number of Open Source–related titles. It also organizes various technical conferences featuring Open Source topics.

The Projects The number of projects in the Open Source world is astounding. Thousands upon thousands of projects are listed in the software repositories (like Freshmeat and LinuxApps), with thousands more which have probably never been formally announced. The list below is an example of a few of the most important and visible projects in the Open Source world. For the sake of brevity, however, many excellent projects will not be found on this list.

Apache One of the best known Open Source projects in the world, Apache is the leading Web server on the Internet according to the monthly Netcraft survey. According to the July 2000 Netcraft Survey, Apache runs over 60% of all Web sites and the percentage is growing, Started by a group of programmers who were trying to patch the NCSA Open Source Web server, the “a patchy server” project has grown to be one of the mission critical components of the World Wide Web. Apache’s unambiguous dominance over several commercial Web server offerings stands as an example of how Open Source software can become an industry standard.

FreeBSD Considered by many to be the second-largest Open Source operating system in terms of usage, FreeBSD is generally regarded as the most prominent of the BSD derivatives. It is currently used in many Web server applications due to its efficient and solid networking capability. FreeBSD is a descendant of 386BSD port created by Bill Jolitz in the late 1980s.

GNOME GNOME is the GNU project’s graphical user interface (GUI). Led by Miguel de Icaza, the GNOME project aims at making an easy-to-use point-and-click interface used in conjunction with the X Window System. GNOME was born because KDE was originally built with a library which did not fit the definition of free software.

13 1989-6 CH09

8/21/00

1:11 PM

Page 127

Chapter 9 • THE PLAYERS: WHO DOES WHAT AND WHY

GNU The brainchild of Richard Stallman and the Free Software Foundation, the GNU project has been working toward the goal of a Unix-like operating system built entirely out of free software. GNU utilities can be found on most computing platforms in existence. Linux makes extensive use of many GNU utilities, causing Richard Stallman to call the combination GNU/Linux. An operating system built entirely by the GNU project, called GNU Hurd, is now available, but doesn’t yet offer as much hardware support as Linux or the BSDs.

KDE The K Desktop Environment, or KDE, is a point-and-click GUI which provides a number of useful desktop functions. Because of the problems with the original license of the Qt graphical library from Troll Tech, KDE was not embraced by the free-software community, resulting in the creation of the GNOME project.

Linux A project that eventually brought Open Source software into public view, the Linux project was started by Linus Torvalds in 1991. It has grown to the point where it powers a large percentage of Internet servers worldwide. It is also appearing on the desktop and even in embedded applications.

MySQL, PostgreSQL MySQL and PostgreSQL are two Open Source database systems that are quite popular. As of July 2000, MySQL is only beginning to support full transaction processing but provides a very lightweight and fast data lookup function. PostgreSQL is an object-relational database system which is frequently used where full transaction semantics are required.

Perl, PHP, Python, Tcl/Tk Perl, PHP, Python, and Tcl/Tk are all powerful scripting languages. Perl, PHP, and Python are often used for back-end processing on Web servers, while Python and Tcl are often used for generating interactive tools.

Samba Samba is the server system which speaks the Microsoft SMB protocol. This allows Windows PCs to share disks and printers with non-Windows boxes running Samba.

Wine Wine is the project which seeks to bring Windows compatibility to the Open Source world. It does two things: It implements many of the Windows APIs so that existing Windows code can be linked with Wine libraries to facilitate porting software to Open Source operating systems, and it allows many Windows executables to run as is. Programs that can utilize Wine do so without facing serious performance degradation.

127

13 1989-6 CH09

128

8/21/00

1:11 PM

Page 128

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The Organizations Sometimes even the Open Source community must resort to creating more formal bodies which can support the task of creating Open Source software. A few of the most critical organizations are listed below.

Apache Foundation (apache.org) The Apache Foundation provides non-technical assistance to the Apache Web server development team. It is a not-for-profit corporation which provides legal and financial support for the development of the Apache Web server and affiliated projects.

Free Software Foundation (www.fsf.org) Created by Richard Stallman, the Free Software Foundation is the entity which supports the GNU project and the message of free software. The Free Software Foundation also sells CDROMs and documentation to financially support the GNU project.

Linux Documentation Project (linuxdoc.org) The Linux Documentation Project is a group which seeks to create high-quality documentation in multiple languages for the Linux operating system and associated Open Source utilities.

Linux International (li.org) Linux International is a business-supported group that seeks to promote the use of Linux and the growth of Linux businesses worldwide. Linux International began in 1994. Jon “maddog” Hall has served as the executive director of the organization for several years.

Linux Professional Institute (lpi.org) The Linux Professional Institute is working to create certifications for various degrees of Linux expertise. It is developing standardized tests which can be taken to achieve multiple levels of certification.

Linux Standard Base (www.linuxbase.org) The Linux Standard Base is an organization that seeks to minimize unnecessary differences between Linux distributions. For example, one distribution might employ a slightly different directory tree than another distribution. The job of the LSB is to create a group of workable standards for distributions which will allow flexibility but keep all the distributions following basic rules. This will help to eliminate problems when doing installation of add-on software packages.

13 1989-6 CH09

8/21/00

1:11 PM

Page 129

Chapter 9 • THE PLAYERS: WHO DOES WHAT AND WHY

Linux Speaker’s Bureau (linuxresources.com) Hosted by Linux Journal, the Linux Speaker’s Bureau is a valuable resource for groups wanting to locate speakers for Linux meetings and for Linux speakers to make themselves known. Companies that want to better understand how certain aspects of Open Source work can often benefit from engaging people listed in the Speaker’s Bureau.

Open Source Initiative (opensource.org) An organization begun in 1998, the Open Source Initiative is responsible for promoting the cause of Open Source software worldwide. It was also responsible for promoting the term Open Source over the term free software in businesses, since the term free software is often mistaken as a type of shareware concept. Although the Open Source Initiative has benefited from the labors of many people, Eric Raymond is generally regarded as one of the most visible proponents of the Open Source idea.

Software in the Public Interest (www.spi-inc.org) This is a group which promotes the production of Open Source software and open hardware specifications.

The Lighter Side Even people committed to ideals such as free software need a break now and again. To that end, the community has seen the rise of a few humor sites. Three of the best known are listed here.

After Y2K (geekculture.com) Nitrozac’s comic strip involving geeks and (inexplicably) beautiful women. Done in a classic comic book style, After Y2K touches on everything from community personalities to the supposed geek desires of Martha Stewart. It is a light-hearted fantasy of the geek kind with a growing following in the geek community.

Segfault (segfault.org) A site based on contributions of its readers, Segfault runs everything from fake news to humorous commentary on the computer industry. Quality tends to vary according to the writer, but there are some funny pieces which reflect some of the more insane moments of the community.

User Friendly (userfriendly.org) A favorite of many people in the community, User Friendly is a daily comic strip written by Illiad. It describes life working at a fictional Internet service provider.

129

13 1989-6 CH09

130

8/21/00

1:11 PM

Page 130

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

And More to Come… It is important to remember that the people, Web sites, and companies listed here are just a small subset of what the community has to offer. It is also essential to note that the community is constantly creating new Web sites and forming new companies to meet new demands in the computing world. Also, as new needs arise, new faces come to the forefront to meet the challenges head-on.

14 1989-6 CH10

8/21/00

1:12 PM

Page 131

CHAPTER 10

THE POTHOLES: WHAT TO AVOID

T

he Open Source world has many, many opportunities for people. There are opportunities to become involved at a technical level, opportunities to become involved on a personal level, and opportunities to become involved at a business level. In order for someone to succeed, however, there must be a commitment to do things the right way— the way determined by the community. In this chapter and the following chapter, I will discuss some of the things that are required to succeed in the Open Source world. In this chapter, I will look at things that should not be done if you want to succeed. In the next chapter, I will look at things that should be done for you to have success.

Forget Business as Usual One of the subtlest and yet most dangerous temptations is to pursue the Open Source market with a business-as-usual attitude. Certainly, the basic rules of business still apply: A company needs to make more money than it spends, it needs to establish a good reputation in the market, and so forth. But that does not mean that working in the Open Source world is business as usual. As described throughout this book, the culture and requirements of the Open Source world are quite different than the culture and requirements of standard society. To ignore this difference is to invite failure. If success is desired, any mindset of “we always do it this way, and that’s good enough” needs to be discarded. Changes you might think are inconsequential or annoying may eventually lead to overall success. This section of the chapter explores some of these changes.

Forget About Demanding Your Own Way One common flaw of business as usual is to demand your own way. In business, the needs of your corporation are frequently cast as the undisputed top priority in the daily schedule. The task at hand is to make sure that everyone gives you what you need when you need it so that the business can prosper. If other companies do not like that attitude, that is their problem. You are to get what your company needs and everyone else can just “put up and shut up.”

14 1989-6 CH10

132

8/21/00

1:12 PM

Page 132

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

In the Open Source world, this attitude of “I don’t care what anyone else thinks as long as I get what I need” just does not work. In a community, people and companies need to interact according to the rules. Companies can certainly pursue their own goals, but they do not have the latitude to run roughshod over the other members of the community. In a world where cooperation is required to move at Internet speed, the adoption of a totally self-centered attitude harms both the community and, in the long run, yourself. The most concrete example of this type of failure can actually be seen in the history of Unix (as you learned in Chapter 2, “How Did All This Start?”). Companies seeking their own good at the expense of all those around them created the fracture which would threaten to destroy the entire Unix marketplace. Every company built its own separate code base, with its own separate features, and its own separate management utilities. The result was a market that had splintered and was unable to fight the onslaught of a different operating system that began invading its territory. The Unix market began to die, until the rise of Open Source restored the cooperation needed for success and brought new life to the Unix marketplace. In more localized terms, the needs of the company cannot be allowed to cross certain lines in the community. For example, one of the most frowned-on activities in the community is the needless forking of projects. Projects should not be broken into two separate code bases headed in two different directions unless that action represents a last desperate attempt to keep essential goals alive. A corporation that tries to fork a project to facilitate its own ends has done something very wrong. Likewise, there is no problem adding capabilities to software. But when a company tries to add features to software that can only be exploited using the company’s proprietary software extensions, that company is going too far. Additional features should be open to anyone who can use the capability.

Forget Fluffy, Empty Management Speeches The Open Source community has a strong dedication to truth. As such, speeches laden with buzzwords, hype, and empty statements are not held in high regard by the community. While it may be expected that a manager will give such a speech to the computer industry at large, it is a mistake to deliver a speech like this to the Open Source community. In talks delivered to the Open Source community, or delivered to project teams within your organization that function as part of the Open Source community, a different tack is required. It is much better to go long on facts and short on gloss. Skip the buzzwords, the empty jargon, and the broad-brush statements. Here is a quick rule of thumb when speaking to Open Source people: If your closest competitor could be heard saying the same words, you are probably saying the wrong thing. The Open Source community does not like nebulous hyperbole. For example, the statement, “We are the industry leader for enabling Internet technologies” is utterly worthless. Most of your competitors are probably using the exact claim in their speeches as well. Whether it is accurate for them to do so is immaterial in this instance. The fact is that the phrase is perceived as empty, meaningless marketing jargon by the community. If your standard presentation contains many

14 1989-6 CH10

8/21/00

1:12 PM

Page 133

Chapter 10 • THE POTHOLES: WHAT TO AVOID

such “blue sky” phrases, you would be better off omitting them altogether. You will get a far better reception from a 10 minute speech laden with facts than you will from a 45 minute speech which contains 10 minutes of real facts. Concentrate on the facts: Our development teams are porting applications X, Y, and Z to Linux, the first of which should be available next quarter. We are working with members of the Open Source ABC project to make sure that the ABC software will properly support our software and make it possible for other projects to benefit as well.

This is a solid statement that has meaning for the community and delivers content that is understandable and important. Compare that statement to this: We are actively engaging our Open Source knowledge to maximize our impact in the marketplace. Our commitment to leverage our strategic partnerships to enhance synergy in the Open Source market will mean greater success ahead for our partners and customers. People will benefit greatly from our best-in-class engineering efforts.

This statement means nearly nothing in the Open Source community. It appears to be simple marketing jargon with no apparent basis in fact. If your speech more closely resembles the latter example than the former, you should consider rewriting it before you embarrass yourself.

Forget About Fudging Facts Another thing to do when speaking is to not stretch, avoid, or misrepresent the facts. As explained in Chapter 6, “Primary Community Value: Truth,” the community has a deep desire for truth. The rather common business practice of avoiding issues by tap-dancing around them with words is not only unhelpful in the Open Source world, it is counterproductive. When someone is asked a direct question and cannot seem to give a direct answer, that person has brought a cloud of suspicion on himself. He would have been far better off giving either an unpopular answer or saying, “I don’t know the answer to that.” By dancing around the issue, the speaker casts doubt on his credibility. His avoidance of the issue shows he may be lying. And lying is the unforgivable sin in the Open Source world. It is much better to say things that are true but unappealing to the listeners than to say things that are appealing but false (or at least not entirely true). The person who speaks an unwelcome message truthfully may see the message attacked, but a person who speaks a welcome message falsely will find his integrity attacked. And once integrity is damaged, your ability to be heard in the community is compromised. An unpopular message is readily correctable, a bad reputation is not. And, whatever else you do, do not lie. Do not do it. It will never be worth the consequences.

133

14 1989-6 CH10

134

8/21/00

1:12 PM

Page 134

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Forget About Marketing that Alienates the Community Another thing to keep in mind is the type of marketing that is done within the community. Standard computer-industry marketing has been known to stretch the truth beyond the breaking point at times. This approach might be acceptable or at least excusable in the industry, but it is guaranteed to fly like a dead quail in the Open Source community. If you intend to market products to the community, you will need to do it properly. Hugely overstated claims will not convince members of the community that you have the best product; rather it will convince people that your company lies too much to be trusted. If you want to succeed, drop the notion that overstating the truth will win customers. It will not. It will guarantee that many folks will remove your solution from their list of most favored possibilities. Any tactic that reliably causes you to be dropped from the customer’s “short list” is not worth using. If you have a product you want to market to the Open Source world, make certain you have lots of detailed information available about it. If it is a piece of hardware, it is wise to release enough interface information about it so that people can use it in Open Source software. If it is a piece of software, it is preferable to make it Open Source. If you cannot do that for some reason, then at least publish the Application Programming Interface (API) for the software so that Open Source projects can exchange data with it. Whatever it is, give lots of detailed information. Remember that this is a technical community. Color glossy handouts may whet the appetite of people, but the details will be what makes the sale. Geeks will not buy it without the knowledge that they can use the item the way they want to. And that means useful technical interface information.

Forget About Pushing Hype Rather than Real Value Posturing to look like you are participating in the Open Source world, when you are actually doing nothing of consequence, is an incredibly foolish thing to do. This “strike a pose and hope people believe you” attitude is seen fairly often in the computer industry at large. It tends to be most prevalent in companies where a major trend has been missed altogether. Once it is discovered that the major trend has been missed, there is a frantic internal scramble to create the image of participation in the trend. Statements are made concerning the corporation’s dedication to the new technology; press releases appear to describe a new initiative around the key technology. But, as time progresses, nothing of note seems to come from the corporation regarding this “commitment” to the new trend. Some corporations have appeared to take this stance with respect to Linux, especially in the late 1990s. Some companies mouthed support for Linux when it was clear that many of their competitors were doing so. But, as time passed, no real concrete signs of support appeared. Products that would be ideal matches for Linux came and went without any apparent effort to make them work with Linux. In some cases, the verbal support was meant to give the impression that the company was pursuing new avenues for revenue, when it was not. In other cases, the company may have been

14 1989-6 CH10

8/21/00

1:12 PM

Page 135

Chapter 10 • THE POTHOLES: WHAT TO AVOID

buying time for itself by talking loudly while it was running frantically in an effort to catch up with the rest of the industry. In other cases, a corporation may have been using the statements as a way of gauging the need for developing products; if enough people asked for the products that were announced, they would develop it, otherwise they would not. In the computer industry at large, this sort of behavior is common. But, in the industry, there are so many players and so many press releases that there are very few people who watch to make certain that a vendor keeps his word regarding new product directions. But that is not the case in the Open Source community. Since the community is, indeed, a community and not just an industry, there are people who are on the watch for deceivers. A corporation that mouths support for the community and then provides nothing will not have the luxury of slipping away unnoticed in the night. The watchers will inevitably call the vendor to account. And they will do so, not by writing letters to executives who can safely file them away in the trash, but by entering the community forums and proclaiming loudly, “This vendor has lied to us!” The bidirectional communication discussed in Chapter 1, “What’s Going On Here?” will be used well by the watchers to make sure that the entire community knows about the lack of integrity displayed by the company in question. These charges, if not answered with substantive displays of support by the vendor, will result in a damaged reputation for the corporation. And the damaged reputation will cause the corporation to lose sales in the community.

Pushing Hype: A Case in Point A classic example of hype over value occurred in 1999. The company involved did a number of extremely poor things that caused a significant public outcry within the community. The outcry became so loud that many traditional press sources began covering the story. Last I heard, some people of prominence were reporting that the company in question wanted to mend its ways. Since I am more than willing to see a company correct its errors and do something productive, I will refrain from mentioning the name of the company here. But the actions of the company stand as a lesson to all companies that try to put hype over substance. When this story began, the market for initial public offerings (IPOs) of stock for Linux companies was hot. For a short period of time, it appeared that any high-tech firm with the word Linux in its business plan was destined for insanely good stock prices in the major stock markets. In the frenzy of buying of Linux stocks on Wall Street, it appears that some people realized that even a weak Linux company might experience amazing results when pursuing an IPO. As the major Linux companies began to prepare for their entrance into the stock market, a name appeared in press releases that was unknown in the community. This self-proclaimed Linux company was preparing for its IPO as well. The arrival of an unknown company in most industries would have drawn little attention in most industries, but in the Linux community, it was spotted the day information began appearing about its impending IPO. Stories began appearing in the major Linux news and discussion Web sites. What was this company? What products did it offer? What services did it bring to the table? What had it done for the community? Many people began to investigate the company.

135

14 1989-6 CH10

136

8/21/00

1:12 PM

Page 136

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

This supposed Linux company filed paperwork in preparation for the IPO. People in the community immediately began analyzing the documents filed. Someone quickly noticed strong similarities between this new company’s IPO documents and those of an earlier Linux company which had gone public. Within hours, someone posted the results of the analysis: This new company’s paperwork was (allegedly) simply the older company’s IPO papers with the name changed. The new company even included sections about key personnel who worked for the older company. This new company seemed to be standing on very shaky ground, indeed. Immediately a cry went up in the community, “Watch this company! It seems to be behaving in a very suspicious way!” More people in the community began investigating. Stories began appearing in the Linux news Web sites indicating that the CEO of this corporation had earlier been at the head of an Internet company that had gone public resulting in some substantial stock valuation. This Internet company, it was claimed, had apparently appeared quickly and disappeared equally quickly, resulting in real losses to shareholders. Despite (or perhaps because of) the flack it was receiving from the community, this Linux company announced it would be producing two new Linux distributions. With no fanfare, the company set up a small booth at one of the major Linux expositions and began handing out sample CDs containing these supposedly new distributions. Again, the community went to work and combed the CDs to find out just how much effort had gone into these new distributions. It was quickly reported that the two distributions were actually two established Linux distributions that had apparently been edited to provide a change in name and little else. The problem here was not that this company had started with established distributions, which is allowable under the rules of free software, but that no value was added to these supposedly “new” distributions. This was apparently a case of simply rebadging existing software, without making any improvements whatsoever. Once again the cry rang out in the community. In fact, the cry became so loud and so potent, that the business media began to take notice. Reputable business media outlets began carrying the story of this strange Linux company and began asking hard questions. Before long, the company announced that it was delaying its IPO until an unspecified future time. Clearly, this case involved some rather extreme and unusual practices by the company in question, but it stands as a potent reminder regarding the strength and watchfulness of the community regarding matters of truth and hype. In many other markets, the company in question might have succeeded in its quest for an IPO. Indeed, the CEO had apparently already done so with an Internet company a few years earlier. But the watchfulness of the community and its dedication to truth caused the strange practices of this company to be exposed. The result was a company that could not execute its plan.

14 1989-6 CH10

8/21/00

1:12 PM

Page 137

Chapter 10 • THE POTHOLES: WHAT TO AVOID

Forget About Taking More than You Give In the world of Open Source, people and organizations that feed on the community, rather than enriching the community, are not warmly embraced. If your intention is to do business with the community, make certain that you are giving at least as much as you are getting. In particular, it is wise to have people participating in software development within the community. Even if you intend on selling closed-source software, work in the Open Source development community to create better Open Source software. It might be software that works in conjunction with your product line, or it might be software that is totally unrelated to your products. The issue here is not facilitating your software as it is building your reputation. If you have fine software, but a low reputation, you will not prosper. If you want a good reputation, work to create good Open Source code. Also, the attitude of “I will do as little as possible for the community; I just want to sell my product” is a loser’s attitude. If you have it, change it. Or, find yourself another marketplace. A lousy attitude will keep you from success, almost regardless of whatever efforts you put forth. This is a community. This is a group of human beings who have elected to come together for the greater good. People and companies who view participation in community activities as mere “necessary evils” toward financial success are not likely to find themselves as integrated parts of the community. And the community will always trust its own people before it trusts the people who are merely acting like economic leeches. Is this concept unsettling to many people who are pure business folks? Yes. But, then again, doing business in a foreign country requires that changes in business attitudes be made to accommodate the foreign culture. The issue is the same here, except for the fact that some of those people in the foreign culture may be riding in the elevator with you as you enter your office every day.

More Traps to Avoid There are other important concerns regarding actions to avoid. Some of them are common sense, but others are much more subtle.

Do Not Open Your Mouth Until You Have Done Your Research This is an obvious piece of advice: Do not say things until you know what is worth saying. However, recent history has shown that this is apparently harder than you might think. For example, in 1999 a software vendor issued a press release talking about the release of its new software. It claimed that this was the first time this type of software was available in Open Source form. It was wrong.

137

14 1989-6 CH10

138

8/21/00

1:12 PM

Page 138

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

In fact, another software company had released a similar piece of software as Open Source about a year before. The later company, in its desire to establish its place in the Open Source world, had overreached its bounds and claimed something that was untrue. When the other software company brought the issue to the community and to the offending party, the press release was corrected. The fact that the company was willing to correct the errant statement was good, but the fact that it made the error at all was bad. The sad fact was that the information about the earlier software could have been located in a few minutes using most Internet search engines. The fact that the company apparently did not bother to check its claims did not go over too well with some people. The error was forgivable, but the appearance of being sloppy with such a critical fact did not enhance its position in the community. This situation has shown up in other places as well. At an Open Source conference in 1999, an executive from a major software company was preparing to take the podium to deliver his keynote address. Before ascending to the stage, someone introduced him to Eric S. Raymond, one of the most visible spokesmen of the Open Source movement. Upon taking the stage, he made some introductory remarks about how glad he was to finally have met “Eric Stallman.” The crowd was polite enough not to correct him, but that slip made people wonder if he knew what was really going on in the Open Source world.

Do Not Fight Wars Not Worth Fighting In the Open Source world, it is quite common for two or more projects to begin to attack a problem from slightly different angles. This can be seen clearly upon perusing software repositories. There are frequently several projects which overlap one another in functionality. But if the effort has matured to the point where several of these projects are actually working, it is common to note that most of the projects are no longer actively being developed. What happened? Unlike closed-source software, Open Source project teams have the ability to look at the code of competing projects. They also have the ability to both use the other team’s code and give code to the other team. A frequent result of this interaction is that although many projects might begin chasing the same goal, only a few will continue active development once things mature. The project teams will begin to assess each other’s work and begin combining the best features into one or two of the best implementations. This produces projects which are combinations of the best concepts from different teams. The result is software that matures much faster than its closed-source counterparts because it can benefit from all the work done to date. Understanding this dynamic, then, it is foolish for a project team to pursue a “victory at all costs” strategy. In the closed-source world, being the last product left standing in a competition is essential for economic success. Companies will throw vast sums of money into developing a product so that it will beat the competition’s offering. In Open Source, that is no longer the primary goal. The primary goal is to create the bestquality free solution that can be made. It does not matter whether your group is the progenitor of the winning project, so long as the final product incorporates the best ideas that the community has to offer. Hence, a project team that realizes that another team has a superior

14 1989-6 CH10

8/21/00

1:12 PM

Page 139

Chapter 10 • THE POTHOLES: WHAT TO AVOID

product may lend its expertise to incorporate key ideas into the other group’s offering. The offering of the losing project team will remain available for people to use and improve. Bugs may continue to be fixed and people using that utility can still have the security in knowing that it will not become unusable. But the superior product will receive most of the focus of the developer community, and eventually, the user community as well.

Do Not Upset Developers Who Do Not Work for You One of the strange consequences of working in an Open Source environment is the need not to draw lines on company boundaries. In the traditional system, all a manager needed to be concerned about is how her employees felt about the company. In Open Source, this is no longer the case. Now, if a company issues a press release about the Open Source project it is involved in, it needs to be sensitive to the other members of the team who do not work for the company. A company can praise the team, laud its success, and boast of the company’s participation without a problem. However, it must be certain that the wording of the press release does not imply that these great accomplishments were effected by the company alone. The result of such a faux pas can be serious. By refusing to acknowledge the fact that others outside of the company contributed in a substantial way, the company has created a condition that could lead to an exodus of talent from the project. If you are relying on people outside your company to get the job done, you must be willing to acknowledge their role in some concrete way.

Do Not Tread on Other People’s Intellectual Property Some closed-source software contains routines and libraries that are licensed from a third party. If you want to open your closed-source software, you will need to make sure that you do not give away other people’s intellectual property. Chapter 8, “Cooperate with the Competition? Are You Nuts?” contains a more thorough discussion of this matter.

Do Not Discourage Hard Questions In many corporations, lower-level people are discouraged from asking pointed or difficult questions of the management above them. In public presentations, managers are often given polite and simple questions by the audience after the talk. This is definitely not the case in the Open Source movement. Since the Open Source movement is built on truth above tact, it is quite reasonable to expect Open Source people to pose difficult or uncomfortable questions to upper management. It should also be expected that an executive giving a presentation will face difficult but important questions from any Open Source people in the audience. This behavior should not be suppressed. If a manager succeeds in suppressing it in the organization, that manager will just have to face the questions outside the organization. The manager is much better off if she simply learns how to handle the rough questions from her own people so she can handle the ones from outside the company when they occur.

139

14 1989-6 CH10

140

8/21/00

1:12 PM

Page 140

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Do Not Mistake Revenue for Market Share A common mistake that seems to occur more and more these days surrounds the reading of analyst reports on the software industry. These reports indicate that the software revenue of Open Source operating system companies is incredibly small when compared to commercial operating system vendors. Many executives and managers see the numbers and fear that the Open Source market is not as large as originally believed. This is definitely not the case. The problem arises from assuming revenue should somehow reflect market share. This is true to some degree for many segments of the software industry, but it is clearly not true for Open Source operating system sales. The fact is that Open Source operating systems are available freely or at very low cost from a number of vendors. Even for deluxe product offerings, Open Source operating system vendors cannot charge the very high prices that closed-source vendors can. This is a simple fact of the market that every Open Source operating systems vendor realizes when it enters the business. It stands to reason, therefore, that the software revenues for these vendors will not come close to matching the software revenues of closed-source operating system vendors. This basic financial reality is the reason most Open Source operating system vendors position themselves not as software vendors but as service providers. The model for Open Source provides far more opportunities for service revenue than for software sales revenue. It is a mistake, therefore, to attempt to correlate Open Source operating system revenue figures with marketshare numbers.

Do Not Accept All Market Analyst Reports at Face Value A brief review of market analyst reports since 1997 illustrates some issues with regard to the effects of Open Source in the software marketplace. Since many analyst organizations tend to measure data from the top of the organization (for example, “We asked the vice presidents of many Fortune 500 IT organizations about their plans…”), they do not always get a true measure of market activity. In particular, Open Source software has been appearing at major companies driven from the bottom of the organizational chart rather than the top. System administrators have deployed many Open Source solutions without the knowledge or permission of IT executives. As such, market analyst reports need to be read with care. Some analysts have acknowledged that their earlier methods did not properly account for the influx of Open Source systems from the bottom of the organization and have taken steps to improve on their results. Other analysts continue to sample from the top only and constantly produce reports showing large gains in the Open Source world, frequently coupled with predictions that are likely to miss the mark almost as much as their earlier predictions did. These analysts will finally “predict” the trend correctly only after it has fully flowered. The need, then, is to pick analysts who have acknowledged that their methods have not given the best result to date. Some of the best of these have modified their methods only to find that

14 1989-6 CH10

8/21/00

1:12 PM

Page 141

Chapter 10 • THE POTHOLES: WHAT TO AVOID

their growth projections for Open Source are still more conservative than what actually occurs. But their projections are still far better than those who do not bother to properly understand the dynamic of the community and the marketplace.

Do Not Mistake Freedom for Lack of Cost As explained in Chapter 2, there is a considerable difference between the use of the word free as in freedom and the use of it as in free beer. A perpetual mistake of many established companies is to emphasize the “free beer” aspect of Open Source software and ignore the “freedom” aspect. It is a misconception to believe that the major concern of the community is software that lacks cost. To the contrary, the community on the whole is more interested in the freedom to use and modify the software source code than to simply have the executable programs available without the outlay of money. A corollary to this mistake is to declare any program with source code available as Open Source. Nothing could be farther from the truth. The Open Source tag requires adherence to the basic freedoms discussed in Chapter 2. If you do not intend to grant basic freedoms, do not use the terms Open Source or free software. It is better to accurately state your case, even if it is unpopular, than to misrepresent your position and ruin your reputation entirely.

From Negative to Positive The list of don’ts in this chapter may be discouraging to some people. They may appear trivial or unworthy of serious effort or consideration. Yet your ability to refrain from the items discussed here will greatly affect your ability to succeed in this community. But the don’ts alone are not enough. There is a list of do’s which you must follow as well. The next chapter will tackle these issues in detail.

141

14 1989-6 CH10

8/21/00

1:12 PM

Page 142

15 1989-6 CH11

8/21/00

1:14 PM

Page 143

CHAPTER 11

THE PRIMER: WHAT TO DO

T

his is the chapter where the rubber meets the road. How do you apply knowledge of the way Open Source works? How can someone from outside the community realize benefits from all this information? How does someone put this information into

action?

For the sake of clarity, let us examine the issues in two contexts: those that concern management and those that concern individuals. The concerns of management are frequently focused on how the organization can benefit from Open Source. The concerns of the individual, however, focus on how he personally can participate in the movement.

Managers’ Issues Regarding Participation in Open Source There are several key issues that most managers should examine. These include people practices (like attracting suitable talent, creating a positive work environment, and rewarding people appropriately) and coding practices (like opening code, altering project methodology, and participating in Open Source code development). Both sets of issues must be examined carefully, as both will affect the organization’s success in developing an effective Web presence in particular and a sound Information Technology (IT) structure in general.

Attracting and Retaining Talent One of the most challenging areas for management when dealing with the Open Source movement is the appropriation and retention of talented technical individuals. Of all the challenges that Open Source brings to managers, this one may bring the most severe consequences if handled poorly. There must be realization that the people who have been affected by the Open Source movement will potentially have a different set of attitudes about compensation, loyalty, and recognition.

Ignorance Is Not Bliss Now, some managers may harbor the notion that if their organization will not be engaged in creating Open Source software, they will not have to be concerned with this subject. This is emphatically not true. The facts of the situation are that technical people are being affected

15 1989-6 CH11

144

8/21/00

1:14 PM

Page 144

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

both directly and indirectly by the Open Source movement. The rise of geek culture is touching the minds and hearts of technical people both inside and outside of the movement. The outlooks of many technical people are changing as a result, so even the manager of a closedsource internal project team will need to be acutely aware of this shift in the industry. No project is immune from the influence of Open Source thinking on technical people. As discussed earlier, the rise of Open Source brought about the rise of geek culture. And the rise of geek culture brought about the rise of geek self-esteem. This is marked by the discovery of geeks that it is possible to succeed and do many interesting things in life. For many geeks, this results in a heightened sense of self-will in the business arena. Old management systems that tell technical people to “sit down, shut up, and do as you are told” will not fly very far in this new world. Today, technical people are discovering their own worth, and many of the best and brightest are finding that they can locate positions which are both personally and financially fulfilling. This is highly apparent in the area of recruiting. Since contributors to Open Source projects are known by name, they are also sought out for employment. A company that is not paying attention to its talented people from the Open Source world may find that its people are receiving unsolicited attractive job offers from other companies. But, unlike much of the IT recruiting of the past, these are not efforts of headhunters who think that the person might be good; these are the efforts of companies that know that the person is good. As more and more companies begin to adapt their corporate culture to attract people from the Open Source world, companies that are slow on the uptake will find themselves dealing less and less with top technical people. Companies which move to change with this key move in the industry will have a chance to obtain the services of top technical people, while companies holding to their old ways will find it progressively more difficult to locate people of high caliber. And, in an age when Internet Web servers are profit centers for most companies, settling for second-rate technical talent can visibly reduce the bottom line of the corporate earnings report, while simultaneously enhancing the position of the competition in the marketplace.

Let My People Code Even if the corporation itself will not be creating Open Source applications, it is important that the corporation be supportive of its workers’ wishes to contribute to Open Source projects. It might not be necessary to allow technical people to use company time to create Open Source software, although if the organization is using a particular piece of Open Source code, it would be a wise move to allow some participation on the company clock. The increased level of expertise acquired by the contributor could very well exceed the cost of his involvement. And the effect of such a pro–Open Source stance would aid greatly in attracting and retaining strong technical people. The decision to allow technical people to actively pursue Open Source projects also wins in other ways. It keeps the job attractive, since there is some room for invention, regardless of how dull the standard assignments might be. It keeps the skills of the programmer sharp by giving him the opportunity to work on challenging projects. And it keeps morale up, since there is less chance that the programmer is wishing he could do something else technically.

15 1989-6 CH11

8/21/00

1:14 PM

Page 145

Chapter 11 • THE PRIMER: WHAT TO DO

Even an investment of 10% of a person’s time in Open Source projects can make a person happier and more productive with the remainder of his time. Some managers might be concerned that the technical person may spend too much time on Open Source work and neglect his assignments. While this is possible, it is no more significant than any other potential distraction in the workplace. For most people, periodic nonaccusatory reminders that the Open Source contribution level should not exceed x% of a person’s work time should do well toward curbing excessive time loss. A technical person who is happy for the chance to spend some of his time doing what he wants is far more likely to expend extra effort on behalf of the corporation when crunch times arise. In the event that the corporation does not want to let the employee contribute to Open Source projects on company time, it should try to make it easy to let the employee contribute on his own time. For some corporations, this may require amending the employment agreement. Many technical people are bound by employment agreements which state that any idea or program that they create is the rightful property of the corporation. The employee, then, finds himself in the unenviable situation where contributing to an Open Source project could cause him to lose his job or even be sued for inappropriately dispensing intellectual property belonging to the corporation. This situation benefits no one. The company is not better off for the employee’s refusal to write code for an Open Source project (especially if the company actually uses the project internally), and the person is not better off for having to turn away from something he wants to do. The net result of such a policy is that the employee’s frustration and resentment over such a policy will grow until it becomes unhealthy. This is similar to an owner starving a race horse to death because he is afraid that the horse might become too fat to run if it eats well. In the end, the employee is likely to leave for a company that will allow him the chance to enjoy participation in the Open Source community, an option the race horse does not have. Another action which a corporation can take is to allow use of certain assets after hours in support of employees working on Open Source projects. Giving employees access to certain computers after hours, allowing them to use printers and modems, and even paying for them to attend one or two Open Source conferences per year are ways that an employer can endear itself to its employees without incurring substantial out-of-pocket costs. The bottom line is that companies which facilitate their employees’ Open Source activities are more likely to attract and retain contributors, while companies which try to keep employees from contributing are liable to lose those employees. Considering the fact that many of the most talented technical people are active in the Open Source world, losing these people can put a company at a serious competitive disadvantage.

Loyalty As many people in the computer industry can tell you, many workers’ sense of loyalty to the corporation took a nose dive in the late 1980s and early 1990s. As management began to adopt the disastrous notion that technical people are easier to hire and fire than they are to retrain, the notion of the disposable workforce left deep scars in the hearts and minds of many workers. Even many young computer people, too young to be employed during that period,

145

15 1989-6 CH11

146

8/21/00

1:14 PM

Page 146

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

were affected by this corporate concept. Many of these younger folks were the children of people who were laid off from high-tech jobs, and they have not forgotten the pain their families endured. As a result, very few technical workers currently have strong ties to a particular company. A good Open Source policy can improve this situation. Many of the people in the Open Source movement have a much more firm loyalty to the movement than to the corporation. By casting the corporation as “Open Source friendly,” the organization can generate considerable goodwill among its technical employees. The closer to the Open Source movement the company becomes, the more the employee will appreciate the company. The closer the company identifies with Open Source, the more the employee’s loyalty to Open Source will overlap with his or her loyalty to the company. Note that it is not recommended that a company state a desire to support Open Source in order to gain employee loyalty, but fail to live up to its own rhetoric. The strong sense of truth in the geek community will cause the technical people to be repulsed by the apparent lie told by the company regarding something that the employee holds dear. In the end, it is likely that such a false position will cause the company to actually lose any sense of loyalty the geek employees may have had to the organization. So, if you are going to do it, do it. But do not even think about faking it. If you know you cannot do it for real, do not even consider posturing for the sake of appearances. It will harm you much more in the end than it will help you in the short term.

Obtaining a Buy-In One practice which should be employed when possible is the practice of explaining the importance of the project. Open Source people are used to doing work on a project because they perceive its value to the community. In business, programmers are expected to work on a project “because the boss says so,” and compliance is required to continue receiving paychecks. But, as previously noted, an atmosphere of “do it because I say so” is likely to drive geeks away in time. There is a simple practice that can help alleviate the problem. If a manager can effectively explain the importance of the assignment, he can frequently obtain an implicit buy-in from the geek. When a geek (or any employee, for that matter) realizes why a task is important, he is more likely to do it and do it well, even if he does not particularly care for the task itself. A few minutes of a manager’s time spent in this regard can improve the working conditions for both the geek and the manager. Now, some managers may complain that this sounds like begging a worker to do his job. In actuality, nothing could be farther from the truth. This is simply a case of supplying talented people with suitable motivation to work well. It must be remembered that Open Source geeks tend to be very creative people. As such, they must be managed in a way that keeps them engaged in the workplace. Simplistic attitudes of “you will do what I say or you will leave” will successfully trim the workforce of talented geeks. In the age of the Internet, that is a recipe for corporate economic disaster.

15 1989-6 CH11

8/21/00

1:14 PM

Page 147

Chapter 11 • THE PRIMER: WHAT TO DO

Make Room for Quality It also should be remembered that the desire for creating quality often runs deep through the community. As such, there is often a natural abhorrence for attitudes such as, “I don’t care if it is broken, we need to ship it today! We’ll fix it after the fact if we get time!” There must be room for doing a quality job. Over the years, there have been many times when I have witnessed geeks being branded as “inflexible” or “not team players” for their stubborn refusal to do a poor job in order to meet a deadline. In every circumstance I can recall, however, the real problem was not that the geek was “too rigid” in his standards; the real problem was that management simply made promises that it could not keep. Quality is not optional. It is an essential element of functional software. Geeks know and appreciate this fact. Do not make the mistake of treating quality as an optional feature during the development cycle.

Rewards, Recognition, and Compensation The issues surrounding the concepts of rewarding excellent work are numerous. Appropriately recognizing the work of someone exposed to geek culture is not as cut and dried as you might think. The simplistic approach of simply handing someone a paycheck, slapping her on the back, and saying “Good job!” will ring hollow in the minds of many geeks. To understand this point, you need to consider some of the basic values of geek culture, as you learned in Chapter 4, “The Key to Many Things: Understanding Geek Culture.” You need to understand that peer recognition is very important, often more so than the issue of salary or title. However, life in the world at large does require money, so obviously a paycheck that corresponds to the efforts of the technical person will be important. Pay is, after all, a very concrete form of communicating recognition and praise. But, in the geek mind, it is far from the only form. And it is often seen as not even the highest form of praise. Title is not generally critical to geeks in the sense of climbing the corporate ladder, but it is rather important in recognition of technical accomplishments. So a geek may not be overly impressed by someone who is the vice president of a corporation, but he might be enthralled with the individual who has been named chief technical officer of a corporation in view of his long list of incredible technical achievements. The real problem with titles is that they generally reflect the corporate structure much more than technical achievement. In many companies, technical titles correspond to longevity or political savvy as much as to technical prowess. In fact, there are few things that a technical person can do to hurt his career that are as bad as being hired in at too low a level within the organization. Why? In many organizations, once you take a place on the corporate ladder, you are doomed to pass through each and every step of that ladder at a prescribed time in a prescribed way, regardless of accomplishment. Take, for example, someone who is hired into a large company right out of college. She is given some standard corporate title such as “Junior Associate Programmer. Level 1.” This is the standard entry level for college hires. But, in a matter of a year, this individual displays

147

15 1989-6 CH11

148

8/21/00

1:14 PM

Page 148

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

amazing technical skill. She revolutionizes the Web site. She takes your clunky e-commerce efforts and creates a fully functional prototype that is streamlined and full of bleeding edge features—the very thing that can increase your Web site revenues in a noticeable way. She uses her Open Source savvy to display how you can get more done with half the number of servers you currently have—and do it all for a fraction of what it previously cost. In meetings, she quickly becomes used to speaking her mind. She evaluates every suggestion from a technical standpoint, regardless of who made the suggestion. She does not seem to recognize that words uttered by a senior staff member are supposed to carry more weight than those of junior staff. What happens to this individual? Well, in many companies, her bleeding edge e-commerce prototype is sent to the senior analyst in charge of e-commerce, who rejects the design on the basis of it being “too radical” and then implements 20% of the ideas himself without bothering to give credit to the young geek. The geek then goes in for her annual performance review and receives a cost-of-living increase plus 2% for “good effort.” She is told that she may even make it to Junior Associate Programmer, Level 2 next year if she learns to bite her tongue and “go with the flow” in meetings. Within a few months after this review, the young geek hands in her notice. What happened to her? She went to your competitor. It hired her as a Web developer. By the time she was done making its Web site run rings around yours, she was made a senior Web analyst. And members of your board of directors noted an “unexplainable” loss of e-commerce revenue during the very same quarter that your competitor boasted of the best e-commerce quarter in its history. Does this tale sound far-fetched? In actuality, variations on this theme are played daily in corporations around the world. I have personally witnessed enough pieces of this scenario to know that it happens far too often. My knowledge of this community leads me to believe it will not only continue to occur, but it will occur more frequently in the future. The secret to surviving this scenario is to adopt the attitude of the second corporation described above. There is a need for corporations to be more flexible and to meet the challenge posed by a talented and aggressive Open Source workforce. To expect today’s opinionated, passionate Open Source worker to act like the reserved, tie-clad corporate men who serviced the needs of mainframes in the 1960s is to lack perception of where this industry is headed. Most geeks are not looking for security in the corporation that they work for. They already have that security in the community itself. What they want from the corporation is a means of realizing goals. These goals include the material (a paycheck, an acceptable standard of living, access to suitable technology) and the ethereal (a chance to do challenging work, an opportunity to build reputation in the Open Source community, an ability to stretch oneself technically). But almost all these goals include some form of recognition in the eyes of the technical community. The desire for peer recognition burns deep in the soul of many a geek. It is a mistake to believe that these people will be satisfied without some accommodation of this need. And it is utterly absurd to think that these people will stay long in a job that demands that they labor in total anonymity to service the needs of the corporation.

15 1989-6 CH11

8/21/00

1:14 PM

Page 149

Chapter 11 • THE PRIMER: WHAT TO DO

But the problem is not a simple one to solve. If the fast-moving geek climbs the business ladder quickly on the basis of his technical acumen, his co-workers who have been supporting the organization for years will likely face some disillusionment. Their long years of toil will seem to be unappreciated by management if this newcomer vaults over them. In some stagnant organizations, it might be best to stir things up like this, but in other organizations this can lead to brain drain—the departure of key individuals who have a deep knowledge of how the corporation runs and what is needed to keep it afloat. In this case, it might be prudent to construct a new ladder next to the old. Continue the old system of slow rise through the corporate ranks for the long-time employees, but build a new ladder of technical accomplishment for the motivated geek. In the new ladder, let titles be more fluid, reflecting the accomplishments of the individual (such as “e-commerce guru” or “chief Web designer”). Downplay the mapping of positions into the corporate ladder and instead make sure that people are valued for their accomplishments. Do not let the attitude of “I am more important than you are” dwell in the minds of the technical staff. Instead, foster an attitude in the workplace where people are valued by their contributions to the company, rather than by their position in the corporate tree. Perhaps the most detrimental situation is one where individuals within a group need to compete against one another for scarce resources. Take, for example, the situation where the annual “pot” of money for raises is static for the group. So, for every person who excels and deserves an excellent raise, there must be at least one other person who receives less money than they otherwise might have received. So, in this case, the highly talented people might be seen as assets to the corporation by management, but liabilities to personal success by coworkers. This brings about an adversarial group dynamic which is bad in any situation but disastrous with people from an Open Source background. Open Source people are used to working as a fairly cohesive unit. They are used to the notion that every talented individual on the team adds value—each to his own portion of the project. To these people, the concept that talented co-workers are adversaries who take money away from their paycheck is both foreign and detestable. Open Source people will tend to grow very frustrated very quickly in this situation. The smart manager will work hard to recast this situation so people on the same project team do not compete against one another for compensation. The smart manager will also fight to produce a system whereby very talented individuals each may receive compensation and recognition according to their contribution. In many companies, this may be a tall, if not impossible, order. But a manager who recognizes the value of his people needs to fight for the goal as best he can. And, if the members of his group are aware of his efforts to change the system (futile as they might be), those people will be more likely to be satisfied with the result. Why? Because peer group recognition is critical in the Open Source community, and if the group manager takes the lead on trying to get rewards for his people, his people will appreciate the recognition which he exhibits for them by his actions.

149

15 1989-6 CH11

150

8/21/00

1:14 PM

Page 150

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Making Room for Fame Some managers may object to this approach of “coddling” technical people. After all, the standard system has worked fine in many corporations for over 30 years, right? But how many of those employees had name recognition among thousands, if not hundreds of thousands, of people? It must be remembered that many Open Source folks are celebrities in their own right—and many of them are under 30 years of age. In most IT shops, the Open Source people are far more famous to the world at large than the vice president of the organization. In this regard, these people bring their “name equity” with them when they join the company. This is a vast departure from the days when the company gave the worker “name equity.” It used to be the case that people would be impressed with a person if she worked for a prestigious company. Now, people are impressed with the company if it succeeds in hiring people with excellent reputations. The “name equity” scenario is turned on its head. If the company seeks to stifle the voice of its Open Source contributors, it harms both the contributors and the company itself. This is especially true if the company intends to do business in the Open Source market. If the company has no visible Open Source developers, it casts suspicion on its position in the market. Open Source people tend to be shy away from corporations which do not demonstrate some level of commitment to the Open Source community. The solution, then, is not only to allow but to promote the concept of technical employees doing Open Source development. Likewise, companies would do well to speak loudly about the accomplishments of their people in the Open Source community. These people should be listed by name in press releases or other promotional material. This will simultaneously raise the corporate image in the community, while giving geeks the type of recognition they want. So, in one stroke, the company makes itself more visible in the marketplace, increases its ability to hire more talented people, and reduces the likelihood of its geeks wanting to leave. It is a win/win/win situation. Now, someone will likely say there is a downside to this strategy. If someone leaves, marketing materials may have to be reworked. And by increasing the visibility of the staff, this will increase the likelihood that other companies will try to hire them away. Neither objection carries much weight. Given the average shelf life of marketing materials, the cost of reworking materials upon the departure of a key person would normally not be that great. In many cases, it might just slightly accelerate the normal time frame for reworking standard materials. But, the fact that the company is publicly acknowledging its technical people increases the employee’s sense of being appreciated and decreases the likelihood that he will depart. The charge that saying people’s names in public will cause them to be desired by the competition ignores a key fact. In the Open Source community, the person is probably known before the company starts talking about them. The employee who is believed to be safely hidden away by the corporation is not hidden at all. Open Source people who contribute well to the community will likely be discovered by headhunters—if the headhunters are not already calling. There is no way to achieve security through obscurity when it comes to hiding Open Source talent. If a corporation tries that approach, it is highly likely that the people will be hired away long before the company knows what is happening.

15 1989-6 CH11

8/21/00

1:14 PM

Page 151

Chapter 11 • THE PRIMER: WHAT TO DO

What Gets Opened? And What Stays Closed? The issue of opening up existing source code to the world is very important. It is a mistake to either ignore the matter or to rush into it without thinking. Some careful thought should go into the decision, but the decision needs to be made. As discussed at length in Chapter 8, “Cooperate with the Competition? Are You Nuts?” it is necessary to determine whether any of your existing code really fits the definition of true intellectual property. One decent rule of thumb is to ask the question, “If we were to release this code, would it visibly affect the profit totals for this company or its competitors in the months to come?” There are basically three answers to the question.

Opening the Code Will Improve the Corporation’s Bottom Line If the company will directly and noticeably benefit from opening the source code, then there is a clear financial incentive to go forward. Organizations which focus on generating revenue from support, consulting, and training are the most likely candidates for this situation. Remember to check the code thoroughly before announcing an intention to open the code. If you are employing routines that are licensed from some other vendor, you may not be able to open your code without violating your agreement with them. This hurdle is especially prevalent among software vendors who utilize other vendors’ proprietary tool kits.

Opening the Code Will Hurt the Corporation’s Bottom Line If opening the code will negatively impact corporate profits, the company is probably either in the software industry or is in some sector of the economy which relies on unique, bleedingedge technology solutions. An example of the latter might be a company which is deciphering human genetic information. Since the work is highly reliant on developing fast means of isolating and identifying genetic information, allowing competitors to use your code may hurt your position in the market. Of the three answers regarding opening source code, this is the hardest to handle, for obvious reasons. No company is quick to undermine its own position in the market—nor should it be. This does not mean that opening the source is necessarily out of the question for the company. It does mean, however, that adjustments to the business model or to the distribution model will probably be required if the company is to open its code. Some software companies in this situation will choose to open older versions of products while keeping the current versions closed. After a defined period of time, the company will open the current closed software, fully expecting that a new version will exist by then. This approach yields certain benefits: • It allows the software producer to collect fees for the current version of software, just like closed vendors do. • It gives customers the investment security of knowing that the code will be Open Source in the future. This may aid in closing sales, especially where the customer wants to be protected if the vendor goes out of business.

151

15 1989-6 CH11

152

8/21/00

1:14 PM

Page 152

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

• It gives the consumer the option of using the older Open Source version of the software for free. Among other things, this can weaken the stance of competing products. If more people select your free version over your competitors’ products, it escalates your position in the marketplace while taking business from the competition. • Experience with the free version of the software can be a persuasive argument for upgrading the software to the new version. Every new user of the free version represents a possible sale of the new version at a later time. It will be far easier for users to migrate to your pay version than to your competitor’s commercial product. Add new features that customers want and they might upgrade to the new version. • Even organizations with deep pockets will like to “try before they buy.” An Open Source version of the code lets them try out the solution (minus the latest features) to see whether they want to use the software. This can greatly reduce the cost of selling, especially if customers have already decided to buy before the salesperson ever meets them. • Every user of either the new or old version can be sold support contracts. Organizations that opt to use the old version may be willing to pay for a support contract to give them additional security, especially since they are not paying anything up front for the software. • As less-affluent organizations use the free version of the software, they create a larger workforce of people skilled in the software. Presence of such skilled individuals in the workforce is often necessary to win more sales. • Having older versions Open Sourced means that bugs isolated by the user community may be fixable in the current version. This allows the motivated technical staff of your customers to supplement your own technical staff. • Having Open Source products means possibly receiving technical and word-of-mouth support from the Open Source community. This situation where code is routinely opened after a period of time will allow the company to gain some respect in the Open Source community. Another alternative is to open secondary code. If you cannot open the main code, then publish all the Application Programming Interface (API) specifications so other programs can call your code. In addition, opening the source code to associated programs while keeping the core code closed may help. But keep in mind that the approach of keeping some code closed while opening other parts is a hybrid that is not welcomed by the free software people and at best mildly embraced by the Open Source community.

Opening the Code Will Not Affect the Corporation’s Bottom Line This is the scenario that the vast majority of corporations face. Most corporations are not in the software business and will need to look at the possibility of opening source code from a practical viewpoint. When the pros are weighed against the cons, most of the time there is a practical benefit in opening the code.

15 1989-6 CH11

8/21/00

1:14 PM

Page 153

Chapter 11 • THE PRIMER: WHAT TO DO

Let us consider some of the perceived problems with opening code: • You must be willing to share with anyone, even your competition. This is true, but what difference does it make? If the software does not impact your bottom line, why would it impact theirs? So who cares if they use it? • You need to have someone head up the continuing Open Source development of the product. True, but if you keep the software closed and in-house, you will need someone to maintain it anyway. If you set it up as an Open Source project, you stand to gain from improvements made by other developers whom you do not need to pay. • You need to waste time focusing on this new Open Source project instead of adding to the corporate bottom line. Once again, closed software will probably need maintenance to keep up with changes in the computing environment anyway. The truth is that developing closed software is both expensive and distracting to begin with. Open Source allows a better return on investment (ROI) for the necessary cost of maintaining the current computing environment. • You might be revealing valuable intellectual property. If this intellectual property is so valuable, why does it not impact your corporate bottom line? Your closed source applications may be your intellectual property, but they have no substantial value from a corporate standpoint.

What Else Do I Need to Consider? There are other matters that must be examined. As mentioned earlier, intellectual property from other vendors cannot be revealed in your code without permission. If you use tool kits or libraries which are licensed from other vendors, you may not be able to open the entire code. Another item of concern is to select an appropriate software license. This issue will be discussed in detail in Chapter 12, “Licenses, Licenses, Licenses!”

Open Source Methodology If you decide to open some or all of your source code, you will need to understand the basic tenets of Open Source methodology. Many of these points have already been discussed in this book. The need for truth, openness, cooperation, and basic organization are all critical elements. There are many forms which are employed to pursue Open Source development. Many projects have a single project leader who coordinates development. But some, like the Apache project, actually use a team approach to management with no single leader. Many projects will post new code to the source tree on an ongoing basis. Other projects only post changed sources every few days or weeks. To handle the project correctly, it would be wise to examine the methods used by projects of a similar size and nature. Seeing how similar projects are handled and asking why certain choices were made may save some grief down the road. Talking with the leaders of other such projects can reveal which choices were possibly not as good as they could be.

153

15 1989-6 CH11

154

8/21/00

1:14 PM

Page 154

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

But one thing that should be considered is the fact that most Open Source projects start as Open Source projects, not closed projects. This means that the project team grows in knowledge with the development of the project itself. However, when a closed product is made Open Source, there is an inevitable hurdle to immediate productivity. The potentially interested developers need to try to understand the existing body of code before they can effectively begin modifications. This is not dissimilar from the startup time of hiring new employees, except that in the Open Source world, it is not normally the daytime job of the developers to ramp up the code. To facilitate this orientation period, certain things are helpful. First, it is good if the code can be cleaned up and documented as best as possible prior to release. If the code is cryptic, undocumented, or filled with obsolete routines, it will confuse and frustrate people as they seek to comprehend the code. And undue confusion and frustration can keep the community from rallying around the effort. Next, a Web page with as much documentation as possible needs to be constructed and maintained. A source tree (usually cvs or equivalent source-management system) needs to be constructed and access controls put into place. Provision must be made for software downloads as well, normally via an FTP site. And, finally, a project team should be in place. If the project is small, a single person might suffice. But, if the project is fairly large, it would be wise to keep as many existing developers on the project as possible until the number of functional external developers grows sufficiently. Once the external developers are capable of handling the needs at hand, many of the internal developers can gradually begin to withdraw from the project. If a large code base is simply thrown at a group of unprepared developers without the initial support of your internal staff, the external developers may never catch on. If you treat your code like a disease that you are trying to get rid of, you cannot expect others to embrace it as a valuable gift. Whatever you do, do not attempt to treat the project like a standard corporate project. The values of the community are reflected in the methods used by the community. To come to the table with methods that reflect your corporation’s values more than the community’s values will cause the community to shy away from your project. The community welcomes your participation in, but not your commandeering of, the work of the community. Decide to enter with humility. It will keep you from being humiliated later. When these things are all in place and you have decided how the development will be managed, announce the project. It should be listed with repositories like Freshmeat and LinuxApps. For corporate visibility, put together a small announcement to release to LinuxPR. It need not be a formal press release, but it should announce the fact that your corporation is releasing this project to the community. Make sure that you specify which license will be used, as this will handle immediate questions about whether it is truly free software.

Set Executive Expectations If you are in low or middle management, you will need to keep in mind that executives above you in the corporation will need to have expectations set regarding this entire endeavor. It might be necessary to prepare a report or presentation on the risks and benefits, with explana-

15 1989-6 CH11

8/21/00

1:14 PM

Page 155

Chapter 11 • THE PRIMER: WHAT TO DO

tions and justifications for this action. A clear and unambiguous report on the expected return on investment of the action, along with answers to the same questions discussed in this chapter, will go a long way to putting their minds at ease. Once you secure the buy-in of upper management, you are in position to get on with the work at hand.

Learn to Love the Slashdot Effect There is a phenomenon in the Open Source community known as the Slashdot Effect. This is the result of something really interesting being listed among the stories at Slashdot (although lesser effects can also be seen from listings at other major Open Source sites). Basically, when the URL of something very cool appears on Slashdot, it is quite common that the Web server serving that URL will immediately begin to be hit hard with thousands of incoming connections. This is due to the fact that so many geeks reading Slashdot will begin following the link to the URL in question. The result can be disconcerting for Web sites that are not prepared for a sudden influx of attention. More than a few Web servers have been maxed out or even crashed as a result of the traffic. The effect can be similar to facing a denial of service (DOS) attack, except that it is generated from a huge number of people who actually want to see what you have to offer. However, while the Slashdot Effect can put a strain on your Web site, it is a badge of honor. When your work captures the attention of such a significant portion of the community, you should be pleased.

Contributor’s Issues Regarding Open Source For people who want to join the Open Source effort but do not know where to start, here are a few important items to consider.

Learn to Find Information Finding information in the Open Source world is a very different task than in most closedsource domains. When someone in the closed-source world needs information, the normal action is to consult the vendor’s Web site, and then to place a phone call to the vendor’s technical support hotline. While you could do the very same in the Open Source world, that is the wrong way to approach finding information. With closed-source, you must assume that the vendor is the guardian of all knowledge regarding the product. If anyone else has knowledge about your problem or issue, it is probably due to the fact that he had the same issue and already spoke to the vendor about it. But this is not the proper assumption when working in the Open Source arena. Instead of assuming that the vendor has the key to solving the problem, assume that the community carries the key to the matter. The code is developed and maintained by the community, so it will naturally have the information that is needed.

155

15 1989-6 CH11

156

8/21/00

1:14 PM

Page 156

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The rule of thumb for dealing with Open Source problems is this: Search engines are your friends. If you need to locate information, a good place to start is a Web search engine like Google or AltaVista. By entering a few keywords that relate to your problem, you can often find the information you need very quickly. If a check of Web pages does not resolve the matter, a search through the Usenet newsgroups (via Deja or a similar engine) will often shed light on the problem. If both of those fail, check the project homepage to see whether a known bug is responsible for the problem. Also, you can use IRC channels and mailing lists to see if the problem is known to anyone else. If nothing else works, there are always paid support contracts from a number of Linux vendors. They offer the same type of telephone support found in the closed-source world. And, if a new bug is found, these organizations can create a patch for the problem and submit it to the appropriate project team. People used to telephone support may reach for the phone before trying the search engines, but experience shows that taking a few minutes to search for the answer often brings about much faster problem resolution.

Learn to Find Software As described in Chapter 9, “The Players: Who Does What and Why,” certain Web sites function as software repositories. Although the closed-source world also has such sites, the Open Source world lives by them. In the closed-source world, when software is needed, the normal question is “Where can I buy software that will do x?” In the Open Source world, however, the appropriate question is “Where do I find software that will do x?” Sometimes the software may already be installed on a machine running an Open Source operating system and the user is simply unaware of its presence. Using a command like apropos or one of the manual page search tools can quickly reveal if some software is installed that might fit the bill. If no appropriate software is installed, or if you do not have an Open Source machine available, the next step is to search the Web repositories. Most are structured in a tree format, with categories and subcategories, so that software can be located relatively easily. Most also have keyword search capabilities, which are very useful. By entering a few keywords in a search query, many potentially appropriate projects can be located.

Learn to Find Projects in Need of Help If you want to join the development team for a project, it is best to let your interests or your needs dictate the type of project to pursue. Is there some program you use already that makes you say, “If it would just do this it would be so much better”? Or do you have some natural interest in a particular technical area? Searching the software repositories for projects that are aligned with your interests can be quite rewarding. Also, visiting Web sites like SourceForge where many project Web pages are hosted can be very enlightening. Once you locate a possible project, visit the development team’s Web site. It is often apparent from reading its “to do” list whether it needs more help. Look at the source code. Is it a language you know written in a style that you can support? Check out any newsgroups

15 1989-6 CH11

8/21/00

1:14 PM

Page 157

Chapter 11 • THE PRIMER: WHAT TO DO

or discussion forums that support the effort. Join any mailing lists. Read the mailing list archive if it exists. Query the project leader: “Do you need help? I am willing to help out.”

Learn to Do Advocacy One of the very important but often unspecified tasks to be done in the Open Source world is advocacy. There is always a need to speak to friends, co-workers, managers, and customers about using Open Source software. Many Open Source conferences include sessions on advocacy. I myself have given talks about advocacy at conferences many times, and I am not alone in that regard.

Learn to Write Articles With the proliferation of Open Source news and information Web sites, and the growing number of magazines that deal with Open Source topics, there is a need for articles. These articles range from product reviews, to information for advanced hackers, to simple guides for newbies. So, whatever your skill level, if you can present good information to a target audience, you might want to consider writing articles. A good place to start might be one of the Open Source news Web sites. As these Web sites normally do not pay for articles, they rely heavily on the best efforts of people who are not established authors. This is a good opportunity to develop your skills while doing something of value. These Web sites normally have a page describing the submission process. Understand the submission process, develop the article, submit it, and see what happens. Be aware that performing such tasks as writing articles is an excellent way for nonprogrammers to “give back” to the community. As the community lives on the contributions of its members, these essential writing tasks are an excellent alternative to coding for people who wish to participate in the culture in a meaningful way.

Learn to Write Documentation As Open Source software becomes more prevalent in the office and the home, good documentation becomes more critical to its success. When the software was written by geeks for geeks, many things could be left unsaid in formal documentation. But the wider use of the code requires that good, solid documentation be present. The best way to get involved is through organizations like the Linux Documentation Project (http://linuxdoc.org/). These documentation groups generally have a list of tasks that must be done as well as a list of basic standards that should be met. By visiting the Web sites of these organizations, you can receive just about all the information needed you need to get involved.

Get Involved Whatever you choose to do, remember this: Proper action is the key. If you believe that you

157

15 1989-6 CH11

158

8/21/00

1:14 PM

Page 158

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

can ignore the movement or play by your own rules, you will court failure. To truly enjoy the long-term success in the Open Source world, you need to get involved and cooperate with the ways of the community. That will ensure your ability to benefit in the years ahead.

16 1989-6 CH12

8/21/00

1:13 PM

Page 159

CHAPTER 12

LICENSES, LICENSES, LICENSES!

T

he Open Source community knows that for software to remain free, it must be protected. The method by which most Open Source software is guarded is through software licensing. It is critical, therefore, that a proper license be associated with a piece of software in order to properly protect the freedom of the software itself. Given the importance of the license, the Open Source community tends to take the issue of licensing very seriously. In fact, people looking in from the outside on a community discussion of licensing sometimes accuse the community of being too uptight and divisive. The problem, though, is that if people are not diligent in their selection and defense of software licensing, the entire Open Source movement stands to fall on its face. Without proper licensing, Open Source is largely wishful thinking. It is essential, therefore, to gain a good fundamental understanding of what makes for a good Open Source license and what does not. If you are considering creating or releasing software as Open Source, it is critical that you select an appropriate license and understand the ramifications of its use. It is also essential to understand what types of provisions can cause problems in the future.

Licensing Issues to Avoid There are a few basic things to remember when entering into Open Source licensing. In particular, there are certain common types of software which are mistaken for Open Source when, in fact, they are not. It is necessary to identify these forms of software and understand why they do not qualify as Open Source.

Open Source Is Not Shareware Open Source software is not shareware. Do not call it shareware. Do not think of it as shareware. If you refer to Open Source software as shareware, you will likely find yourself corrected publicly and loudly by members of the community. Shareware and Open Source have very little in common. Shareware is built on a try-before-you-buy model. It allows end users to try software for a while and then pay for it if they find that it meets their needs. Licensing enforcement is generally left up to the conscience of the user, sometimes accompanied with annoying messages that suggest that the user register the software.

16 1989-6 CH12

160

8/21/00

1:13 PM

Page 160

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

But shareware, by and large, is just an inexpensive form of commercial software. The source is normally closed. Licensing terms indicate that the software must be paid for if the user continues to use the product past some arbitrary test period. It is simply commercial software delivered in a more flexible fashion. When you license your Open Source software, do not use a shareware-style license. If you really want to write shareware, not Open Source, that is your prerogative. But please do not try to call your shareware “Open Source.”

Open Source Is Not Freeware Open Source is not freeware. Thanks to the flexibility of the word free in the English language, some people confuse freeware with free software. As normally used, these terms are not equivalent. Freeware is a term that commonly reflects the cost of the software, whereas free software reflects the liberty associated with the software. Freeware is software used without cost, whereas free software grants basic liberties to use, share, and change the programs. Some people might look at the distinction and say, “Big deal. The two definitions are close enough that it doesn’t really matter. It all comes down to the same thing.” But this is not the case at all. The Open Source and free software movements are not focused on producing software that costs nothing. They are focused on software that can be used and modified by anyone. Freeware does not grant the liberty of using and modifying the code to fit the user’s needs; therefore freeware is neither free software nor Open Source. If the Open Source movement did not require that the source be available, the amazing advances that have occurred in Open Source software would never have happened at all. The key is in having the right to use the source and modify it when needed. If you are not intending to give rights to use the source code of your software, you are not creating free software or Open Source; you are creating freeware. You may certainly create freeware, but please do not call it free software.

Open Source Is Not Public Domain Another incorrect assumption made by some people is that Open Source software is the same as public-domain software. Although public-domain software can be classified as Open Source, the reverse is not usually true. Open Source software is rarely in the public domain. Most of the time, there is a copyright holder for each piece of Open Source software. The copyrighted software is then licensed appropriately so that the world may freely use, modify, and distribute the software. It may come as a surprise to many people to learn that public domain is not the favorite method by which Open Source software is made available. Why? Because it offers no protection for the freedom of the code. Public-domain software is software that has intentionally not been put under copyright. As such, it does fit the description of free software; the user has the freedom to use, modify, and

16 1989-6 CH12

8/21/00

1:13 PM

Page 161

Chapter 12 • LICENSES, LICENSES, LICENSES!

redistribute the software at will. However, it also permits the user to take the code and use it in a closed-source commercial application without even acknowledging the use of the code itself. This ability to take the code and make it proprietary is a concern for a large number of people in the Open Source community. Although some free software licenses allow code to be modified and used in closed, proprietary software products, the most common free software license, the GPL, does not.

Patents and Pain The use of software patents has been a real problem in the Open Source world. Because of the nature of patents, it is possible to create a free software program that is actually not free at all. If the author unknowingly violated a software patent, the program cannot be distributed without permission from the patent holder. For this reason, many people in the Open Source movement do not have a high regard for software patents. However, one form of software patent is acceptable in the Open Source arena: a patent obtained for defensive, rather than offensive purposes. This type of patent is licensed for unhindered use by the patent holder. The reason for the patent in the first place is to ensure that no one else takes out a patent on the technology and tries to restrict the use of the patented material. It is a similar rationale to that used by people who purchased slaves so that they could turn around and free them legally. The idea is to make the resulting freedom clear and unambiguous, so that no one can easily challenge that freedom in court.

License Types: The Good, the Bad, and the Viral Licenses comes in many styles and flavors. This is good from the perspective that they give the copyright holder flexibility, but it is also troublesome because recipients of the licensed code have to figure out just what they can and cannot do under the license. Among the worst cases are licenses that read like free software licenses at first but later throw in provisions that make the software not really free at all.

The Good: Four Essential Freedoms Good licenses preserve the four essential freedoms needed for truly free software: 1. The freedom to use the program 2. The freedom to examine and change the source code 3. The freedom to distribute the program 4. The freedom to distribute any changes to the source code If one or more of these freedoms is not granted, it cannot be called either free software or Open Source software.

161

16 1989-6 CH12

162

8/21/00

1:13 PM

Page 162

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

The Bad: Non-Free or Partially Free Licensing Non-free licensing is something that most consumers of PC software are accustomed to. It grants only the first freedom listed above. With commercial proprietary software, you normally do not have the opportunity to see or manipulate the source code. You also lack the ability to distribute the program to other people as you see fit. Although most consumers have come to expect this form of licensing, the Open Source movement is working very hard to change that expectation. The trickier matter is the issue of partially free licensing. A partially free license can look very much like a free license, except that it departs in some key area—often in what is initially perceived to be a trivial fashion. The net result, however, is a license which does not preserve the individual’s right to use, modify, or distribute the software. One example of this are the type of programs that meet the criteria for free software, but only when used for noncommercial purposes. These licenses sometimes stipulate that the software cannot be used for commercial purposes. Others state that when the software is used commercially, payment of some form of royalty is required. This was one of the issues surrounding the original licensing of the Qt library that the KDE desktop uses. The original license stated that the Qt library could be used without cost on noncommercial projects, but commercial projects would require a licensing fee. There were other issues as well, but this provision alone was enough to keep the Qt library from being free software. Troll Tech, authors of the Qt library, later issued a license that has been accepted by the Open Source Initiative and the Free Software Foundation as a valid free software license.

The Viral A major issue with any license is to determine whether it is viral. A viral license “infects” the code that touches it. Introducing a piece of code containing a viral license into a program will cause the entire program to come under that license. As one might imagine, this can yield quite spectacular, and occasionally unwanted, results. It is especially problematic when a viral license comes into contact with a piece of code that is the property of a third party, or when two viral licenses meet in the same code. The net result is a situation which cannot legally exist. Either the copyright holder of one of the pieces must change its licensing, or one of the pieces of code must be withdrawn. Take, for example, the GNU General Public License (GPL). The GPL is a viral license. If you have written a piece of code and you decide to integrate a piece of GPL code into your work, you have made your entire program come under the GPL. But, if your code contains some code which you licensed from some other person, you are making that code fall under the GPL as well. In the event that the copyright holder does not want his work to come under the GPL, you have basically two choices: Either remove the third party code from your work, or remove the GPL code. Short of getting someone to change the licensing conditions of the software, there is nothing else to do. It should be noted that the Library GPL, also called the Lesser GPL (LGPL), was created to avoid this problem. A more detailed discussion about the GPL and LGPL will follow shortly.

16 1989-6 CH12

8/21/00

1:13 PM

Page 163

Chapter 12 • LICENSES, LICENSES, LICENSES!

It is absolutely imperative that licensing conditions be followed to the letter. Licensing protects the freedom of the code. Just because a particular situation does not fit your liking does not mean you have the option of ignoring the terms of the license. Work with the system, even if it means changing your plans once in a while. Respect for the software license is the vehicle by which the community is assured that its work will not be in vain. If software licenses are subject to rampant abuse, the community’s sense of ownership of the free software process will be violated. The community’s sense of ownership of free software is integral to the enthusiasm and dedication that people feel toward the Open Source movement.

Role of the Open Source Initiative and the Free Software Foundation Since the entire issue of licensing can be very sticky in many ways, it is useful to have the services of an educated observer who can properly assess whether a license truly grants the proper freedoms. To this end, both the Open Source Initiative and the Free Software Foundation regularly examine new and proposed software licenses for compliance with the four essential freedoms, listed earlier. Richard M. Stallman of the Free Software Foundation has been known to publish dissertations analyzing certain licenses and discussing their compliance with Free Software principles. The Open Source Initiative lists a group of approved Open Source–compliant licenses on its Web page (http://opensource.org/).

Lone Rangers Are a Last Resort For a while, it seemed that every company which released its formerly proprietary code under an Open Source license wanted to write a license from scratch. Whether from an effort to satisfy corporate lawyers or from a long-standing practice of “doing it our own way,” these companies came out with their own unique licenses. Unfortunately, crafting a good Open Source license that guards essential freedoms well and yet interoperates well with other licenses is not a simple task. In the end, many of these companies decided it was better to simply pick an appropriate existing license and spend time writing good software instead of employing more copyright lawyers. As a rule of thumb, existing Open Source–compliant licenses should be used whenever possible. New licenses require new assessments from the community to determine soundness and possible pitfalls, including community acceptance. But most proposed new licenses seem to bring very little new to the table, except confusion. It is far better for a company to assess the existing licenses and simply pick the one that reflects the company’s vision regarding the use of the software.

Existing Open Source Licenses As previously mentioned, a number of Open Source licenses have been carefully scrutinized and accepted in the Open Source community. In an effort to draw attention to features of

163

16 1989-6 CH12

164

8/21/00

1:13 PM

Page 164

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

many of the better-known licenses and copyrights, this section will list some of the more important issues covered by these licenses. It is important to note that although I am a reasonably intelligent individual, I am not a lawyer. It would be prudent, therefore, for any corporation seeking to release code under an Open Source license to have the proposed license reviewed by appropriate legal counsel before implementation. In the paragraphs that follow, the structure of each license is summarized according to the paragraph or section numbers used in the license itself. Much of the information is rather dull and dry. That is because most licenses are dull and dry. Nonetheless, a proper license is essential to preserve the rights of free software. Please note that the information below is my effort to summarize most of the key points of these licenses. It is not an effort to make certain that every point is covered in detail. In fact, many details are eliminated to give a short overview of the provisions of each license. It is essential that you consult the original documents before making the decision to use a particular license or copyright statement.

GNU General Public License, Version 2 (a.k.a. Copyleft or GPL) The granddaddy of free software licensing, the GPL is perhaps the most popular license in the Open Source world today. A product of Richard M. Stallman and the Free Software Foundation, the GPL is the benchmark for protection of liberties combined with the ability to ensure that the code will remain free in all future incarnations. It is a very readable license, compared to some of the licenses below that were created by corporate legal departments. The basic structure of the license is as follows: Preamble: background information on free software and the importance of proper licensing. 0. Definition of terms and limitations of license. Running the software is not restricted. 1. Software may be copied with copyright intact. You may charge to make copies or to provide warranty services. 2. You may modify files provided you make notations in the source code. This license is viral. Copyright notice must normally be visible when starting the program, unless no notice is normally displayed. The license is viral to all portions of the work distributed together. An aggregation of separate works is exempt from viral infection. 3. You may distribute binary copies as long as source code is distributed as well, or as long as source code is available on request. 4. You may not violate this license or your rights will be terminated. 5. Modifying or distributing the program indicates that you accept this license. 6. The license goes with the software when you redistribute it. 7. If it is impossible to distribute the program in accordance with this license and other legal restrictions (such as patents that require royalties), then the program may not be distributed at all.

16 1989-6 CH12

8/21/00

1:13 PM

Page 165

Chapter 12 • LICENSES, LICENSES, LICENSES!

8. If this program cannot be freely distributed in certain countries due to patents and so on, the copyright holder may exclude the right to distribute in those countries. 9. The GPL may be revised. The copyright holder may license under one version of the GPL or all versions that follow the current one. 10. To incorporate parts of the code into a program with different licensing, write the author and ask permission. 11. Statement of no warranty. 12. Statement of no liability.

GNU Library General Public License (LGPL) The Library GPL, also called the Lesser GPL, is similar in terms to the GPL shown above. The major exception to this is the fact that it is nonviral. Linking LGPL libraries with your code does not automatically make your code come under the LGPL. If the libraries were licensed under the GPL, however, the act of linking would cause the entire work to come under the GPL. So, the LGPL is useful when you expect your code to be linked with code that you do not want to be forced to come under the GPL. Preamble: similar to the GPL preamble, but with additional examples with respect to libraries. 0. Definition of terms and limitations of license. Running software that uses the library covered by this license is not restricted. 1. The library may be copied with copyright intact. You may charge to make copies or to provide warranty services. 2. You may modify the library and distribute the modifications under the following conditions: The modified work must be a library, modifications must be documented, this license will apply to the entire modified work, and the function must attempt to perform well in the absence of optional application data. This license does not apply to sections of work that are independent of the library, unless they are distributed as a single work. Aggregation of other works with the library does not affect the licensing of the other works. 3. You may opt to replace the LGPL with the GPL in your work. This is useful when incorporating code from an LGPL library into a non-library program. 4. Object code may be distributed as long as the source code is made available. 5. Programs which are not derivative of the library, but merely use the library, are not affected by this license. Executables which are built using the library are covered according to the provisions in section 6. 6. Executables built from the library may be distributed under terms of your choice. Modification of the executable for the customer’s own use and reverse engineering must be permitted. The use of the library and a copy of license must be included. If copyright notices are displayed, the copyright of the library must be displayed also. Source code

165

16 1989-6 CH12

166

8/21/00

1:13 PM

Page 166

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

for the library must accompany the work or be made available in ways prescribed by the license. Sufficient data and utility programs needed to rebuild the executable must be included with the library source. 7. Non-LGPL libraries may be placed side-by-side into a single library with the LGPL library without subjecting them to the LGPL. Certain conditions for this are called out in detail in the license. 8. Attempting to distribute, modify, or link with the library against the terms of the license will cause termination of your right to distribute, modify, or link with the library. 9. Modifying or distributing the software constitutes acceptance of the license. 10. Recipients of software created under this license automatically receive a license to utilize the software under this license. No additional restrictions are allowed. 11. The library may not be distributed if doing so would violate the law (e.g., the work employs patented software which requires a royalty). If a portion of the license is ruled unenforceable, the remainder of the license still applies. 12. If this program cannot be freely distributed in certain countries due to patents and so on, the copyright holder may exclude the right to distribute in those countries. 13. The LGPL may be revised. The copyright holder may license under one version of the LGPL or all versions that follow the current one. 14. To incorporate parts of the code into a program with different licensing, write the author and ask permission. 15. Statement of no warranty. 16. Statement of no liability.

4.4BSD Copyright This is the backbone of the BSD operating systems. The BSD license is not viral and does not exclude the possibility of including the software in a closed-source commercial product. Redistribution of source code, binaries, and modifications is allowed as long as 1. Copyrights appear in the source. 2. Copyright statement must accompany binaries in a separate file or in the documentation. 3. Advertisements must acknowledge the University of California. 4. University of California endorsements must be arranged by permission. A statement of no warranty is included.

16 1989-6 CH12

8/21/00

1:13 PM

Page 167

Chapter 12 • LICENSES, LICENSES, LICENSES!

Q Public License Version 1 (QPL) 1. If you distribute this software, you agree to the license. 2. Distributed software must be complete and unmodified. 3. Modifications can be distributed as patches, as long as the copyright statement is intact, your patches are licensed under the QPL, and Trolltech can choose to use your patches in future releases. 4. You may distribute binaries as long as you include the copyright, you must make the original source code available, and you must make source code to any changes available. 5. You may use the software in your programs. 6. You may develop programs which use the software and redistribute the programs provided you make the source code available at minimal or no cost, the license follows the code, and you must make source code available to Trolltech. A statement of limitation of liability and statement of no warranty are included.

Artistic License This is a license to give “the copyright holder some semblance of artistic control over the development of the package” while protecting the freedoms of the users. 1. Unmodified copies of software can be made as long as the copyright notice is included. 2. You may make bug fixes from the public domain or the copyright holder. 3. You may make changes to the software as long as you document the change and do one of the following: Put the change in the public domain, use the modification in your organization only, rename changed programs and provide documentation, or make other arrangements with the copyright holder. 4. You may distribute binaries as long as you do one of the following: Tell where the source is available, distribute the source and source of modifications, rename non-standard executables and document them, or make other arrangements with the copyright holder. 5. You may charge for copying or supporting the software but not for the software itself. You may aggregate the software with other programs. 6. Scripts and library files are not automatically covered by this copyright. 7. Subroutines you add to this package are not part of this package, provided they do not cause regression tests to fail. 8. Aggregation of the software in commercial packages is allowable as long as the software is not presented like a separate program. 9. Endorsements by the copyright holder are by permission only. 10. A statement of no warranty.

167

16 1989-6 CH12

168

8/21/00

1:13 PM

Page 168

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

Aladdin Free Public License The Aladdin Free Public License is used for distribution of the Aladdin Ghostscript product. The preamble states that the license may be applied to your own work, provided the only alteration is the name and description of the product in section 0. 1. Identifies the software covered by the license. Modifying or distributing the program indicates acceptance of the license. 2. You may distribute and modify the modifications of the program provided you do it in accordance with the license and include a copy of the license with the program. 3. Charging for the program or for a service related to the program is prohibited (examples and exclusions are included; it would be wise to read this paragraph thoroughly). Use of the program and its output is not restricted. Modifications to the program must be prominently documented. Modifications are subject to this license. Copyright and no warranty statements must be displayed when running the program. Source code must be included in the distribution. Printed documentation must include the license or a pointer to it. Additional restrictions must not be applied to the recipient of the software. Supplying a pointer to the source code is acceptable under certain conditions. 4. Failure to adhere to the license will result in revocation of rights to modify or distribute the program. 5. If distribution of the code is prohibited in certain countries, a list of excluded countries may be added to the terms of the license. 6. Statement of no warranty and no liability. 7. Adherence to laws for the State of California. U.S. Government rights restriction notice.

Python License This is the copyright statement that accompanies the Python language. The Python license is a short document that gives the right to use, copy, modify, and distribute the software for any purpose. Copyright notice must appear in documentation. Names of the principal suppliers of the software must not be used in advertising without permission. The license is not viral and has no restrictions on commercial use. A statement of no warranty is included.

IBM Public License Version 1.0 This is the license issued for the IBM Jikes Compiler. It is a very tedious mass of legal-speak. I strongly advise that any use of this license (as well as any license listed in this chapter) be assessed by an appropriately skilled lawyer. The summary that follows is my best assessment of this particularly difficult license. 1. Definitions.

16 1989-6 CH12

8/21/00

1:13 PM

Page 169

Chapter 12 • LICENSES, LICENSES, LICENSES!

2. You may distribute, modify, and copy the source code and binaries. You may distribute, modify, and copy the patented software contributed by the authors. You are responsible for obtaining permissions to use other patents not held by the contributors. Contributors believe they have the right to make this agreement. 3. Binary distributions must comply with this agreement. Contributors must be protected from liability and claims of warranty. Instructions on obtaining source must be included. Source copies must contain the copyright. 4. If the program is used in a commercial product, the contributors must be protected from liability. 5. Statement of no warranty. 6. Disclaimer of liability. 7. Lots of painful legal verbiage.

Mozilla Public License Version 1.0 The Mozilla Public License was created by Netscape to cover the code in the Open Source project called Mozilla. This license has a large amount of legalese. 1. Definitions. 2. You may use, modify, and distribute the original code and any modifications. Any patented portions of the software may be used without cost. 3. Source code and modifications are covered by this license. You must make source code available to any modifications. Modifications must be documented. Third-party intellectual property must be documented. License must appear in documentation. Copyright statement must appear in source code. Conditions for binary distributions spelled out. If the software is distributed as part of a larger work, you must fulfill the requirements of the license. 4. If there are legal problems complying with the license, you must document them in a separate file. 5. A pointer to the program covered by the license. 6. Versions of the license. 7. Statement of no warranty. 8. Termination of rights will occur if you do not comply with the license. 9. Statement of limitation of liability. 10. U.S. Government clause. 11. Miscellaneous legal stuff. 12. You are responsible for damages.

169

16 1989-6 CH12

170

8/21/00

1:13 PM

Page 170

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

X Window System License X11R6.4 This is the license that covers the X Window System. The license has essentially the same provisions described under the Python copyright listed above.

Apache License This is the copyright used by the Apache Group for the Apache web server. Redistribution is allowed under the following terms: 1. The copyright must be included in the source code. 2. The copyright must be included in the documentation in binary distributions. 3. Advertising must acknowledge the Apache Group. 4. The Apache Group must not be used in endorsements without permission. 5. The name “Apache” may be used only by permission. 6. A specified acknowledgment must be included in the distribution. A statement of no warranty is included.

Not-Quite-Open Source Licenses Occasionally, some licenses appear that have the look of an Open Source license, but they do not protect the four essential freedoms associated with truly free software. You must be very cautious not to employ these licenses or attempt to combine software created under these licenses with true Open Source licenses, unless you have studied the particular licenses well enough to know that they can coexist. The Sun Community Source License (SCSL), for example, has certain Open Source elements to it. It does allow the user community to look at the source code and it does allow patches to be sent back to the maintainers. But it also requires things like fees for commercial use of the software and the need to sign an additional licensing agreement to redistribute the software. These things are inconsistent with the licensing of free software, so adopting this form of license can bring serious problems if you intend to use your code with Open Source code. The requirements of the two types of licenses may be irreconcilable.

17 1986-6 Index

8/21/00

1:12 PM

Page 171

INDEX

Symbols 4.4BSD copyright, 166

A accepting hard questions, 139 acknowledging developers’ contributions, 139 advocacy, 157 After Y2K Web site, 129 Aladdin Free Public License, 168 Allman, Eric, 25 Apache copyright, 170 Apache Foundation, 128 Apache server, 23-24, 126, 170 Apache Today Web site, 120 Artistic License, 167 Atipa Linux Solutions, 124 attracting and retaining employees, 143-144 appreciation of quality work, 147 loyalty, 145-146 motivation, 146 participation in Open Source projects, 144-145 rewards and compensation, 147-149

B Bazaar model (software development), 11 beer, role in Open Source community, 72-73 behavior to avoid, 131 accepting market analyst reports at face value, 140-141 demanding own way, 131-132 discouraging hard questions, 139 empty management speeches, 132-133 factual errors, 137-138 fudging facts, 133 giving away others’ intellectual property, 139

mistaking freedom for lack of cost, 141 mistaking revenue for market share, 140 overstated marketing claims, 134 pushing hype, 134-136 refusing to acknowledge developers’ contributions, 139 taking more than you give, 137 “victory at all costs” strategies, 138-139 Berkeley Standard Distribution UNIX. See BSD UNIX Berners-Lee, Tim, 10 bidirectional communication advantages of, 11-12 geek culture, 58-59 origins of, 10-11 Brook’s Law, 96-97 BSD (Berkeley Standard Distribution) UNIX, 25 4.4BSD copyright, 166 FreeBSD, 116 NetBSD, 117 OpenBSD, 117 BSD Today Web site, 120 businesses, profits from Web sites, 27

C Caldera OpenLinux, 115 The Cathedral and the Bazaar, 11, 55 Cathedral model (software development), 11 CDE (Common Desktop Environment), 24 chain of command (software development), 32-33 Cheapbytes Web site, 123 closed-source development, 7 code advantages of code sharing, 105-106 determining code to open, 151-153 reusing, 8 reviewing, 33-34 self-correcting, 79

Collab.net Web sites, 122 Common Desktop Environment (CDE), 24 communication bidirectional advantages of, 11-12 geek culture, 58-59 origins of, 10-11 distrust of information providers, 9-10 geek speakers, 71-72 local user groups, 70-71 rude behavior, 75-76 community (Open Source), 63 behavior to avoid, 131 accepting market analyst reports at face value, 140-141 demanding own way, 131-132 discouraging hard questions, 139 empty management speeches, 132-133 factual errors, 137-138 fudging facts, 133 giving away others’ intellectual property, 139 mistaking freedom for lack of cost, 141 mistaking revenue for market share, 140 overstated marketing claims, 134 pushing hype, 134-136 refusing to acknowledge developers’ contributions, 139 taking more than you give, 137 “victory at all costs” strategies, 138-139 conflicts within, 77-79 development facilitators, 122-123 effects on society, 27 education and training, 42-43

17 1986-6 Index

172

8/21/00

1:12 PM

Page 172

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

influences on software, 38-40 management freedom, 44 problem-solving, 43-44 role of desktop PCs, 28-30 software development, 30-34 software ownership, 34-37 technical support, 40-41 emphasis on truth, 53-54, 75 disadvantages of, 83-84 GNU/Linux and, 84-85 rudeness and social interaction, 75-76 geek culture, 47-49 advantages of, 60 bidirectional communication, 58-59 commitment to free software and Open Source software, 59 crackers, 48 emphasis on truth, 53-54, 75, 83-85 fame, 55-56 free-software movement, 59 freedom to choose projects, 56-58 geeks, 47-48 impact on popular culture, 61 importance of reputation and accomplishments, 54-55 kernel hackers, 48 manners/polite behavior, 59-60 origins of, 51-52 passion for programming and technology, 52 priorities, 52 self-esteem issues, 49-51 geek speakers, 71-72 importance of, 73-74 leaders, 113-114 local user groups, 70 magazines, 122 online media, 120-121 online stores, 123 organizations, 128-129 participating in advocacy, 157 attracting and retaining employees, 143-150 determining code to open, 151-153 executive expectations, 154-155 finding information, 155-156 finding projects, 156-157 finding software, 156 involvement in community, 157

Open Source methodology, 153-154 Slashdot Effect, 155 writing documentation, 157 writing news articles, 157 philosophy of, 65-66 fast turnaround, 67-68 fun, 69-70 “let the best code win” philosophy, 67 open development cycle, 66 open development team, 66-67 pragmatism, 68-69 public praise, 68 role of beer in, 72-73 self-correcting, 79 code, 79 news, 79-80 opinions, 80-81 rumors, 82 trolls, 82-83 size of, 63-64 social interaction, 70-71, 75-76 software developers, 124-125 systems vendors, 124 technical meritocracy, 76-77 virtual watering holes, 119 compensating employees, 147-149 competition. See coopetition conflicts within Open Source community, 77-79 continuing education, 14-15, 42-43 cooperation, 101. See also coopetition coopetition, 101-102 benefits of, 107-108 definition of, 101, 106-107 intellectual property misunderstandings about, 104-105 valuable intellectual property, 102-104 Open Source advantage, 108-109 as potential industry standard, 109-111 sharing code, 105-106 Copyleft license (General Public License, Version 2), 123, 164-165 copyrights. See also licenses 4.4BSD copyright, 166 Apache copyright, 170 Python copyright, 168 Corel Linux, 116 correcting errors, self-correction, 79 code, 79 news, 79-80 opinions, 80-81 rumors, 82 of trolls, 82-83 Cosource Web sites, 123 cost considerations development, 107 maintenance, 108 software ownership, 34-35

Cox, Alan, 114 crackers, 18, 48

D Debian GNU/Linux, 116 demanding your own way, dangers of, 131-132 desktop PCs, role in today’s society, 28-30 determining code to open, 151-153 developers, 33-34, 124-125 development, closed-source, 7 development, Open Source, 30 advantages of, 108-109 code reuse, 8 continuing education, 14-15 Internet speed, 7-9 joy in programming, 12-13 “let the best code win” philosophy, 15 motivation, 12 professional independence, 13-14 quality, 12 chain of command, 32-33 code review, 33-34 communication bidirectional, 10-12 distrust of information providers, 9-10 compared to free software, 21-22 competition, 33 costs, 107 development facilitators, 122-123 development teams, 66-67 economics, 30-31 methodology, 31-32 myths about Open Source, 87 Brook’s Law, 96-97 difficulty of installation, 91-92 difficulty of use, 91 fragmentation of Open Source, 92-95 future of Open Source, 89-90 increased risks, 90-91 lack of innovation, 96 Open Source as hacker toys, 87 Open Source as shareware, 88 Open Source written by amateurs and children, 88 outdated technology, 88 security issues, 89 unsupported software, 88-89 origins of, 17 Apache server, 23-24 BSD (Berkeley Standard Distribution) UNIX, 25 distributions, 25-26

17 1986-6 Index

8/21/00

1:12 PM

Page 173

INDEX

Free Software Foundation, 18-19 GNU, 19-20 Linux, 20-21 open network protocols, 22-23 sendmail, 25 UNIX operating system, 17-18 X Window System, 24-25 philosophy of Open Source movement, 65-66 fast turnaround, 67-68 fun, 69-70 “let the best code win” philosophy, 15, 67 open development cycle, 66 open development team, 66-67 pragmatism, 68-69 public praise, 68 role of software developers, 33 development facilitators, 122-123 development teams, 66-67 disruptive technologies defined, 28 effects of Open Source software education and training, 42-43 freedom of management, 44 influences on software, 38-40 problem-solving, 43-44 role of desktop PCs, 28-30 software development, 30-34 software ownership, 34-37 technical support, 40-41 distributions, 25-26, 115 Caldera OpenLinux, 115 Corel Linux, 116 Debian GNU/Linux, 116 FreeBSD, 116 Linux, 94-95 Linux PPC, 116 Linux-Mandrake, 116 meta-distributions, 115 NetBSD, 117 OpenBSD, 117 Red Hat Linux, 117 Slackware Linux, 117 Storm Linux, 117 SuSE Linux, 117 TurboLinux, 118 Yellow Dog Linux, 118 do’s and don’ts. See behavior to avoid documentation, 157 doubt. See FUD (fear, uncertainty, and doubt)

E economics of software development, 30-31 education and training, 14-15, 42-43 email programs, sendmail, 25 employees, attacting and retaining, 143-144 appreciation of quality work, 147 loyalty, 145-146 motivation, 146 participation in Open Source projects, 144-145 public recognition and acknowledgement, 150 rewards and compensation, 147-149 empty management speeches, 132-133 errors, self-correcting, 79 code, 79 news, 79-80 opinions, 80-81 rumors, 82 trolls, 82-83 etiquette, 59-60, 75-76. See also behavior to avoid Ewing, Larry, 21 executive expectations, 154-155

F fame (within geek culture), 55-56 fast turnaround, 67-68 fear, uncertainty, and doubt. See FUD finding Open Source information, 155-156 Open Source projects, 156-157 software, 156 fragmentation, 92-95 free software, compared to Open Source software, 21-22 Free Software Foundation (FSF), 18-19, 128 free-software movement, 59 FreeBSD, 25, 116, 126 freedom of developers, 56-58 of management, 44 versus lack of cost, 21-22, 141 freeware, 160 Freshmeat Web site, 118 Friedman, Nat, 124 FSF (Free Software Foundation), 18-19, 128 FUD (fear, uncertainty, and doubt), 87 Brook’s Law, 96-97 confusing Open Source with shareware, 88 difficulty of installation, 91-92 difficulty of use, 91 fear of outdated technology, 88 fragmentation of Open Source, 92-95

future of Open Source, 89-90 increased risks, 90-91 lack of innovation, 96 Open Source as hacker toys, 87 Open Source written by amateurs and children, 88 security issues, 89 support for Open Source software, 88-89 fudging facts, 133 fun. See joy in programming future of Open Source, 89-90

G geek culture, 47-49 advantages of, 60 bidirectional communication, 58-59 commitment to free software and Open Source software, 59 crackers, 48 emphasis on truth, 53-54 fame, 55-56 free-software movement, 59 freedom to choose projects, 56-58 geek speakers, 71-72 impact on popular culture, 61 importance of reputation and accomplishments, 54-55 kernel hackers, 48 manners/polite behavior, 59-60 origins of, 51-52 passion for programming and technology, 52 priorities, 52 self-esteem issues, 49-51 geek speakers, 71-72 General Public License, Version 2 (GPL), 164-165 GNOME, 95, 126 GNU, 19-20, 127 GNU/Linux, 84-85 licenses GPL (General Public License, Version 2), 164-165 LGPL (Library General Public License), 165-166 GPL (General Public License, Version 2), 164-165 groups (user), 70

H hacker toys, perception of Open Source as, 87 hackers, 18, 48 Hall, Jon “maddog,” 114 hard questions, accepting, 139 HelixCode, 124 help, 40-41

173

17 1986-6 Index

174

8/21/00

1:12 PM

Page 174

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

history of geek culture, 51-52 Open Source development, 17 Apache server, 23-24 BSD (Berkeley Standard Distribution) UNIX, 25 distributions, 25-26 Free Software Foundation, 18-19 GNU, 19-20 Linux, 20-21 open network protocols, 22-23 sendmail, 25 UNIX operating system, 17-18 X Window System, 24-25 hype, pushing, 134-136

I IBM Public License, Version 1.0, 168-169 Icaza, Miguel de, 124 importance of Open Source community, 73-74 independence, 13-14 influencing software, 38-40 innovation in Open Source projects, 96 installing Open Source, 91-92 intellectual property, 139 misunderstandings about, 104-105 valuable intellectual property, 102-104 International Data Group, 125 Internet speed, 6-7 Internet.com, 125 IP. See intellectual property

J-K job titles, 147 journals, 122 joy in programming, 12-13, 69-70 KDE (K Desktop Environment), 24, 95, 127 kernel hackers, 48 Kernelnotes Web site, 118

L leaders of Open Source community, 113-114 legal issues intellectual property, 139 misunderstandings about, 104-105 valuable intellectual property, 102-104 licenses. See licenses “let the best code win” philosophy, 15, 67 LGPL (Library General Public License), 165-166

licenses, 36-37, 159 freeware, 160 Open Source, 161, 163-164 4.4BSD copyright, 166 Aladdin Free Public License, 168 Apache copyright, 170 Artistic License, 167 benefits of, 161 GPL (General Public License, Version 2), 164165 IBM Public License, Version 1.0, 168-169 LGPL (Library General Public License), 165-166 Mozilla Public License, Version 1.0, 169 non-free licensing, 162 partially free licensing, 162 Python copyright, 168 QPL (Q Public License, Version 1), 167 role of Open Source Initiative, 163 viral licenses, 162-163 writing from scratch, 163 X Window System License X11R6.4, 170 patents, 161 public-domain, 160-161 SCSL (Sun Community Source License), 170 shareware, 159-160 Linux Cox, Alan, 114 distributions, 94-95, 115 Caldera OpenLinux, 115 Corel Linux, 116 Debian GNU/Linux, 116 FreeBSD, 116 Linux-Mandrake, 116 Linux PPC, 116 meta-distributions, 115 NetBSD, 117 OpenBSD, 117 Red Hat Linux, 117 Slackware Linux, 117 Storm Linux, 117 SuSE Linux, 117 TurboLinux, 118 Yellow Dog Linux, 118 GNU/Linux, 84-85 history of, 20-21 Linux Documentation Project, 128, 157 Linux Professional Institute, 128 Linux project, 127 Linux Speaker’s Bureau, 129 Linux Standard Base, 128 LUGs (Linux Users Groups), 70 Torvalds, Linus, 114 Tux (penguin logo), 21

Web sites Linux Central, 123 Linux Journal, 122 Linux Magazine, 122 Linux Orbit, 120 Linux Show, 120 Linux Systems Labs, 123 Linux Today, 119-120 Linux Weekly News, 121 Linux.com, 118 Linux.org, 118 LinuxApps, 119 LinuxCare, 126 LinuxMall, 123 LinuxPlanet, 120 LinuxPR, 120 Linuxresources, 119 LinuxWorld, 121 Linux Central Web site, 123 Linux Documentation Project, 128, 157 Linux International, 128 Linux Journal Web site, 122 Linux Magazine Web site, 122 Linux Orbit Web site, 120 Linux PPC, 116 Linux Professional Institute, 128 Linux project, 127 Linux Show Web site, 120 Linux Speaker’s Bureau, 129 Linux Standard Base, 128 Linux Systems Labs Web site, 123 Linux Today Web site, 119-120 Linux Users Groups (LUGs), 70 Linux Weekly News Web site, 121 Linux-Mandrake, 116 Linux.com Web site, 118 Linux.org Web site, 118 LinuxApps Web site, 119 LinuxCare, 126 LinuxMall Web site, 123 LinuxPlanet Web site, 120 LinuxPR Web site, 120 Linuxresources Web site, 119 LinuxWorld Web site, 121 local user groups, 70 Love, Ransom, 101 loyalty, 145-146 LUGs (Linux Users Groups), 70 Lutris Technologies, 125

M maddog (Jon Hall), 114 magazines, 122 mail programs, sendmail, 25 maintenance costs, 108 management. See also participating in Open Source attracting and retaining employees, 143-144 appreciation of quality work, 147 loyalty, 145-146 motivation, 146

17 1986-6 Index

8/21/00

1:12 PM

Page 175

INDEX

participation in Open Source projects, 144-145 public recognition and acknowledgement, 150 rewards and compensation, 147-149 behavior to avoid, 131 accepting market analyst reports at face value, 140-141 demanding own way, 131-132 discouraging hard questions, 139 empty management speeches, 132-133 factual errors, 137-138 fudging facts, 133 giving away others’ intellectual property, 139 mistaking freedom for lack of cost, 141 mistaking revenue for market share, 140 overstated marketing claims, 134 pushing hype, 134-136 refusing to acknowledge developers’ contributions, 139 taking more than you give, 137 “victory at all costs” strategies, 138-139 executive expectations, 154-155 freedom of, 44 Slashdot Effect (italics), 155 tips for management speeches, 132-133 Mandrake, 116 manners, 59-60, 75-76. See also behavior to avoid market analyst reports, 140-141 market share, 140 marketing market analyst reports, 140-141 overstated marketing claims, 134 media Apache Today, 120 BSD Today, 120 Linux Orbit, 120 Linux Show, 120 Linux Today, 120 Linux Weekly News, 121 LinuxPlanet, 120 LinuxPR, 120 LinuxWorld, 121 RadioWallStreet’s Linux League, 121 Slashdot, 119, 121 Technocrat, 121 WideOpen News, 121 meritocracy, 76-77 meta-distributions, 115

methodology of software development, 31-32, 153-154 mistakes. See behavior to avoid misunderstandings about intellectual property, 104-105 Motif, 24 motivating employees, 146 Mozilla Public License, Version 1.0, 169 MySQL project, 127 myths about Open Source, 87 Brook’s Law, 96-97 difficulty of installation, 91-92 difficulty of use, 91 fragmentation of Open Source, 92-95 future of Open Source, 89-90 increased risks, 90-91 lack of innovation, 96 Open Source as hacker toys, 87 Open Source as shareware, 88 Open Source written by amateurs and children, 88 outdated technology, 88 security issues, 89 unsupported software, 88-89

N-O NetBSD, 117 Netscape, Mozilla Public License, 169 Netscraft Web survey, 24 new articles, writing, 157 news, self-correcting, 79-80 non-free licensing, 162 O’Reilly, 126 online stores, 123 open development cycle, 66 open development teams, 66-67 Open Magazine Web site, 122 open network protocols, 22-23 open praise, 68 Open Software Foundation, 24 Open Source community. See community Open Source development. See development Open Source Development Network, 125 Open Source Initiative, 129, 163 Open Source licenses, 161, 163-164 4.4BSD copyright, 166 Aladdin Free Public License, 168 Apache copyright, 170 Artistic License, 167 benefits of, 161 GPL (General Public License, Version 2), 164-165 IBM Public License, Version 1.0, 168-169 LGPL (Library General Public License), 165-166 Mozilla Public License, Version 1.0, 169 non-free licensing, 162 partially free licensing, 162

Python copyright, 168 QPL (Q Public License, Version 1), 167 role of Open Source Initiative, 163 viral licenses, 162-163 writing from scratch, 163 X Window System License X11R6.4, 170 OpenBSD, 117 OpenSales, 125 opinions, self-correcting, 80-81 organizations, 128-129 OS Opinion Web site, 119 OSF (Open Software Foundation), 24 overstated marketing claims, 134 ownership of software, 34-37

P partially free licensing, 162 participating in Open Source advocacy, 157 attracting and retaining talent, 143-145 appreciation of quality work, 147 loyalty, 145-146 motivation, 146 public recognition and acknowledgement, 150 rewards and compensation, 147-149 determining code to open, 151-153 executive expectations, 154-155 finding information, 155-156 finding projects, 156-157 finding software, 156 involvement in community, 157 Open Source methodology, 153-154 Slashdot Effect, 155 writing documentation, 157 writing news articles, 157 patents, 161 PCs, role in today’s society, 28-30 Penguin Computing, 124 penguin logo (Linux), 21 Perens, Bruce, 114 Perl, 127 philosophy of Open Source movement, 65-66 fast turnaround, 67-68 fun, 69-70 “let the best code win” philosophy, 67 open development cycle, 66 open development team, 66-67 pragmatism, 68-69 public praise, 68 PHP, 127 polite behavior, 59-60, 75-76. See also behavior to avoid PostgreSQL project, 127 pragmatism, 68-69

175

17 1986-6 Index

176

8/21/00

1:12 PM

Page 176

EMBRACING INSANITY: OPEN SOURCE SOFTWARE DEVELOPMENT

praise, 68 priorities (geek culture), 52 problem-solving, 43-44 problems to avoid. See behavior to avoid professional independence, 13-14 profits, effect of Open Source participation, 151 decreased profits, 151-152 increased profits, 151 no change to profits, 152-153 projects (Open Source) Apache, 126 finding, 156-157 FreeBSD, 126 GNOME, 126 GNU, 127 KDE (K Desktop Environment), 127 Linux, 127 MySQL, 127 Perl, 127 PHP, 127 PostgreSQL, 127 Python, 127 Samba, 127 Tcl/Talk, 127 Wine, 127 protocols, TCP/IP, 22-23 public praise, 68 public-domain software, 160-161 publications, 122 pushing hype, 134-136 Python, 127, 168

Q-R QPL (Q Public License, Version 1), 167 RadioWallStreet’s Linux League Web site, 121 Raymond, Eric S., 11, 55, 114 recognizing employees, 150 recruiting employees, 143-144 appreciation of quality work, 147 loyalty, 145-146 motivation, 146 participation in Open Source projects, 144-145 public recognition and acknowledgement, 150 rewards and compensation, 147-149 Red Hat Linux, 117 reports, market analyst, 140-141 repositories, 118-119 reputation, importance in geek culture, 54-55 retaining employees, 143-144 appreciation of quality work, 147 loyalty, 145-146 motivation, 146 participation in Open Source projects, 144-145

public recognition and acknowledgement, 150 rewards and compensation, 147-149 revenue, compared to market share, 140 rewarding employees, 147-149 robustness, increasing, 108 rude behavior within Open Source community, 75-76. See also etiquette rumors, self-correcting, 82

S Samba, 127 SCSL (Sun Community Source License), 170 security, 89 Segfault Web site, 129 self-correction, 79 code, 79 news, 79-80 opinions, 80-81 rumors, 82 trolls, 82-83 self-esteem issues (geek culture), 49-51 sendmail, 25, 125 servers, Apache, 23-24, 170 shareware, 88, 159-160 sharing code, advantages of, 105-106 sites. See Web sites size of Open Source community, 63-64 Slackware Linux, 26, 117 Slashdot Effect, 155 Slashdot Web site, 79-80, 119, 121 social interaction within Open Source community, 70 geek speakers, 71-72 local user groups, 70-71 role of beer, 72-73 rude behavior, 75-76 software finding, 156 freeware, 160 influencing, 38-40 patents, 161 public-domain, 160-161 shareware, 159-160 technical support, 40-41 software developers, 33-34, 124-125 software development. See development Software in the Public Interest, 129 software licenses. See licenses software ownership, 34-37 speakers geek speakers, 71-72 tips for management speeches, 132-133 speed, Internet speed, 6-7 Stallman, Richard M., 18, 114 stores (online), 123 Storm Linux, 117 Sun Community Source License (SCSL), 170

support for Open Source software, 40-41, 88-89 SuSE Linux, 117 systems vendors, 124

T taking more than you give, 137 Tcl/Talk, 127 TCP/IP protocol suite, 22-23 teams (development), 66-67 technical meritocracy, 76-77 technical support, 40-41 Technocrat Web site, 121 technology, disruptive. See disruptive technologies titles (job), 147 Torvalds, Linus, 20-21, 114 training and education, 14-15, 42-43 traps to avoid. See behavior to avoid trolls definition of, 82 self-correcting, 82-83 truth, importance within Open Source community, 53-54, 75. See also self-correction disadvantages of, 83-84 GNU/Linux and, 84-85 rudeness and social interaction, 75-76 TurboLinux, 118 Tux (Linux penguin logo), 21

U-V uncertainty. See FUD (fear, uncertainty, and doubt) UNIX BSD (Berkeley Standard Distribution) UNIX, 25 fragmentation along vendor lines, 92-93 history of, 17-18 User Friendly Web site, 129 user groups, 70 VA Linux Systems, 124 valuable intellectual property, 102-104 vendors, 124-126 “victory at all costs” strategies, dangers of, 138-139 viral licenses, 162-163 virtual beer, 73

W-X-Y-Z Web sites After Y2K, 129 Apache Foundation, 128 Apache Today, 120 Atipa Linux Solutions, 124 BSD Today, 120

17 1986-6 Index

8/21/00

1:12 PM

Page 177

INDEX

The Cathedral and the Bazaar, 11 Cheapbytes, 123 Collab.net, 122 Copyleft, 123 Cosource, 123 Freshmeat, 118 FSF (Free Software Foundation), 128 HelixCode, 124 Internet.com, 125 Kernelnotes, 118 Linux Central, 123 Linux Documentation Project, 128 Linux International, 128 Linux Journal, 122 Linux Magazine, 122 Linux Orbit, 120 Linux Professional Institute, 128 Linux Show, 120 Linux Speaker’s Bureau, 129 Linux Standard Base, 128 Linux Systems Labs, 123 Linux Today, 119-120 Linux Weekly News, 121 Linux.com, 118 Linux.org, 118 LinuxApps, 119 LinuxMall, 123 LinuxPlanet, 120 LinuxPR, 120 Linuxresources, 119 LinuxWorld, 121 Lutris Technologies, 125 Netscraft Web survey, 24 Open Magazine, 122 Open Source Initiative, 129 OpenSales, 125 OS Opinion, 119 Penguin Computing, 124 RadioWallStreet’s Linux League, 121 Segfault, 129 Sendmail, 125 Slashdot, 79-80, 119, 121 Software in the Public Interest, 129 as source of business profit, 27 Technocrat, 121 User Friendly, 129 VA Linux Systems, 124 WideOpen News, 121 WideOpen News Web site, 121 Wine project, 127 writing documentation, 157 X Window System, 24-25, 170 X Window System License X11R6.4, 170 Yellow Dog Linux, 118

177