הקדמהרב פרוייקטי התוכנה החופשית נכשלים.בדרך-כלל איננו שומעים רבות אודות הכשלונות. רק פרוייקטים
מצליחים מושכים תשומת-לב, וקיימים כל-כך הרבה פרוייקטי תוכנה
חופשיתSourceForge.net, אתר אירוח פופולרי, הכיל
79,225 פרוייקטים רשומים באמצע אפריל 2004. מספר זה כמובן כלל לא
קרוב לכמות הכוללת של פרוייקטי תוכנה חופשית באינטרנט; זה רק מספרם
של אלה שבחרו להשתמש ב SourceForge. שאפילו אילו רק
אחוז קטן מצליחים, התוצאה עודנה פרוייקטים מוחשיים רבים. כמו-כן
איננו שומעים אודות הכשלונות מאחר וכשלון אינו אירוע. אין רגע יחיד
בו פרוייקט חודל להיות חיוני; אנשים פשוט מתרחקים ממנו ומפסיקים
לעבוד עליו. ייתכן רגע בו נערך שינוי סופי לפרוייקט, אך אלו שביצעו
אותו, בדרך-כלל לא ידעו ברגע הביצוע שזה יהיה השינוי האחרון. אין
אפילו הגדרה ברורה למתי פרוייקט מאבד תוקף. האם זה כאשר לא בוצעו בו
שינויים ופעילות במשך שישה חודשים? כאשר מאגר המשתמשים שלו חדל לצמוח,
מבלי לעקוף את מאגר המפתחים? מה אם המפתחים של הפרוייקט נוטשים אותו
מאחר והבינו כי הם משכפלים עבודה של אחר? ומה אם מצטרפים לאותו
פרוייקט אחר, ומרחיבים אותו להכיל את מרבית המאמצים המוקדמים שלהם? האם
הפרוייקט הראשון הסתיים, או פשוט שינה בית?עקב המורכבות הזו, בלתי אפשרי לעמוד בדיוק על מספר הכשלונות.
אך ראיות אנקדוטיות שהופיעו במשך למעלה מעשור, חלקן באתר
SourceForge.net וחלקן מחיפוש בגוגל, כולן מצביעות על אותה מסקנה: מספר
הכשלונות גבוה ביותר, סביר כי בין 90 עד 95 אחוז. המספר מטפס גבוה יותר
אם כוללים פרוייקטים ששורדים אך לוקים בתפקוד: אלה שמייצרים
קוד רץ, אך אינם מקום נחמד להיות בו, או שאינם משיגים התקדמות במהירות
או בנאמנות שהיו יכולים להשיגה.ספר זה הוא אודות המנעות מכשלון. הוא סוקר לא רק כיצד לעשות דברים
נכונה, אלא גם איך לעשותם לא נכון, בכדי שתוכלו לזהות ולתקן בעיות מוקדם.
אני מקווה שלאחר שתקראו אותו, יהיה בחזקתכם רפרטואר שיטות לא רק בכדי
להמנע ממכשולים מוכרים של פיתוח בקוד פתוח, אלא גם בכדי להתמודד עם הגידול
והתחזוקה של פרוייקט מצליח. הצלחה איננה משחק סכום-אפס, וספר זה איננו
אודות ניצחון או עקיפת התחרות. למעשה, חלק חשוב בניהול פרוייקט קוד פתוח
הוא עבודה חלקה יחד עם פרוייקטים קרובים. בטווח הארוך, כל פרוייקט מצליח
תורם לטובת כל הגוף העולמי, הכולל, של התוכנה החופשית.זה יהיה מפתה לומר שפרוייקטי תוכנה חופשית כושלים מאותן סיבות
מהן כושלים פרוייקטי תוכנה קניינית. בוודאי אין לפרוייקטי תוכנה חופשית
מונופול על דרישות לא מציאותיות, הגדרות עמומות, ניהול משאבים גרוע
שלבי תכן לא מספקים, או כל מרעין בישין אחר הידוע היטב לתעשיית
התוכנה. רבות נכתב על נושאים אלה, ואני אשתדל לא לשעתק זאת בספר זה.
במקום זאת, אנסה לתאר את הבעיות הייחודיות לתוכנה חופשית. כאשר
פרוייקט תוכנה חופשית מתרסק, לרוב זה מכיוון שהמפתחים (או המנהלים)
לא העריכו את הבעיות הייחודיות לפיתוח בקוד פתוח, על-אף שאולי היו
מוכנים היטב לקשיים הידועים יותר של פיתוח בקוד סגור.אחת הטעויות הנפוצות ביותר היא ציפיות לא מציאותיות בנוגע
ליתרונות הקוד הפתוח כשלעצמו. רשיון פתוח לא מבטיח שעדרים של מפתחים
פעילים ינדבו לפתע את זמנם למען הפרוייקט שלך, וכן פיתחת קוד של
פרוייקט בעייתי לא מרפאת את חולייו באופן אוטומטי. למעשה, ההפך
הוא הנכון: פתיחת פרוייקט יכולה להוסיף נדבך חדש של מורכבויות
ולעלות יותר בטווח הקצר מאשר פשוט להשאיר
אותו סגור "בבית". פתיחת הפרוייקט פירושה הפיכת הקוד לנהיר וקריא
עבור זרים מוחלטים, הקמת אתר פיתוח ברשת ורשימות תפוצה, ולעתים
קרובות, כתיבת תיעוד בפעם הראשונה. מדובר בהמון עבודה. וכמובן,
אם מפתחים מעוניינים אכן מופיעים, נוסף העול
של לענות להם על שאלותיהם זמן מה טרם מפיקים תועלת מנוכחותם.
כפי שאמר המפתח ג'יימי זווינסקי על הימים המוקדמים הבעיתיים של
פרוייקט מוזילה:
קוד פתוח עובד, אך בהחלט איננו תרופת פלא. אם יש
מוסר השכל כאן, הוא שאינך יכול לקחת פרוייקט גוסס, לפזר עליו מעט
מאבקת הפיות של ה"קוד הפתוח", ושהכל יעבוד לפתע כבמגע קסם. פיתוח
תוכנה זאת מלאכה קשה. הבעיות בה, אינן כה פשוטות.(מתוך )
טעות קשורה הינה חיפוף בהצגת ואריזת הפרוייקט, מתוך מחשבה
שאלה תמיד יכולים להתבצע מאוחר יותר, כאשר הפרוייקט כבר נמצא בדרכו.
הצגה ואריזה מכילות בחובן מגוון רחב של משימות, אשר כולן סובבות סביב
הפחתת חסם הכניסה לשוק. הפיכת הפרוייקט למזמין עבור זרים, פירושה
כתיבת תיעוד למשתמשים ולמפתחים, הקמת אתר אינטרנט אינפורמטיבי לחדשים
עבור הפרוייקט, מיכון של כמה שיותר מתהליכי ההידור וההתקנה, וכו'.
לרוע המזל, מתכנתים רבים מתייחסים למשימות אלה כמשניות בחשיבותן לעומת
כתיבת הקוד עצמו. יש לכך מספר סיבות. הראשונה היא שזה יכול להרגיש
כמו עבודה שחורה, היות והערך שלה ברור יותר למי שפחות מכיר את פרטי
הפרוייקט, ולהפך. אחרי הכל, המפתחים של הקוד, לא ממש צריכים את האריזה.
הם כבר יודעים כיצד להתקין, לנהל, ולהשתמש בתוכנה, מאחר והם כתבו אותה.
שנית, הכישורים הנדרשים להצגה ואריזה של הפרוייקט בצורה טובה, לעיתים
קרובות כלל אינם אלה הנדרשים לכתיבת הקוד. אנשים נוטים להתמקד במה שהם
טובים בו, על-אף שייתכן ויישרתו טוב יותר את הפרוייקט אם ישקיעו במה
שפחות מתאים להם לעשות. דן בהצגה
ואריזה לפרטים, ומסביר מדוע זה אקוטי שיהיו בחשיבות גבוהה כבר בשלבים
הראשונים של הפרוייקט.טעות נוספת היא ההנחה המוטעית שניהול פרוייקט מועט או לא
קיים נחוץ לקוד פתוח, או מאידך גיסה, שאותן גישות ניהול הנהוגות
בפיתוח קנייני, יעבדו באותה מידה על פרוייקט קוד פתוח. ניהול
בפרוייקט קוד פתוח אינו תמיד ברור וגלוי, אך בפרוייקטים המצליחים,
בדרך-כלל הוא מתרחש מאחורי הכללים בצורה כלשהי. ניסוי מחשבה קטן,
מספיק על-מנת להמחיש מדוע. פרוייקט קוד פתוח מורכב מאוסף מתכנתים
אקראי - קבוצה בעלת חוש עצמאות מפותח כשלעצמו - אשר סביר להניח
שמעולם לא פגשו זה את זה, ואשר ייתכן שיש להם מטרות פרטיות שונות
בעבודה על הפרוייקט. ניסוי המחשבה הינו פשוט לדמיין מה יקרה לאותה
קבוצה בלי ניהול. ללא ניסים, הפרוייקט יקרוס
או יתמוגג מאד מהר. דברים לא יפעילו את עצמם, למרות שאולי נקווה
לכך. אך הניהול, שייתכן והוא אפילו מאד פעיל, לרב איננו רשמי,
הוא מעודן, ועל אש נמוכה. הדבר היחיד שמחזיק קבוצת פיתוח ביחד,
הוא האמונה שיחדיו יוכלו להשיג יותר מאשר לחוד. על-כן, תפקיד
הניהול הוא שחברי הקבוצה ימשיכו להאמין בכך, על-ידי הצבת תקנים
לתקשורת, וידוא שמפתחים מועילים לא נזרקים לשוליים עקב נסיבות
אישיות, ובאופן כללי, הפיכת הפרוייקט למקום שמפתחים ירצו לשוב
אליו. טכניקות ייעודיות להשגת מטרות אלו, יידונו במהלך המשך
הספר.לבסוף, ישנה קבוצת בעיות כללית אשר ניתן לכנות "כשלונות בניווט
תרבותי". לפני עשר שנים, אפילו חמש, היה זה מוקדם לדבר על תרבות גלובלית
של תוכנה חופשית, אך לא עוד. תרבות כזו הופיע אט-אט, ואף שוודאי איננה
עצומה - איננה חסינה מפני ויכוחים וחילוקי דעות, לפחות כמו תרבות
מעוגנת מבחינה גיאוגרפית - יש לה גרעין די עקבי. רב פרוייקטי הקוד הפתוח
המצליחים, מציגים חלק אם לא את כל המאפיינים של ליבה זו. הם מעודדים
התנהגויות מסויימות ומוקיעים אחרות. הם יוצרים אווירה שמעודדת השתתפות לא
מתוכננת, לעיתים במחיר תיאום מרכזי. יש להם מושגים של נימוסין וחוסר
נימוסין, אשר עלולים להיות שונים מהותית מאלה המקובלים במקומות אחרים.
החשוב מכל הוא שמשתתפים בעלי ותק רב, הפנימו את הסטנדרטים הללו ויש
ביניהם הסכמה רחבה לגבי אופן ההתנהגות הרצוי. פרוייקטים כושלים לרוב
סוטים בבירור מליבה זו, אולי אף לא במתכוון, ולעיתים אפילו אין להם
הסכמה על מהי התנהגות ברירת מחדל רצויה. פירוש הדבר הוא שכאשר מופיעות
בעיות, המצב עלול להתדרדר במהרה, היות ולמשתתפים חסר מערך תגובות תרבותי
להשען עליו, על-מנת לפתור מחלוקות.ספר זה הינו מדריך מעשי, לא מחקר או סיכום אנתרופולוגי. למרות
זאת, ידע מעמיק אודות המקורות של תרבות התוכנה החופשית בת זמננו, הינו
יסוד חיוני לכל עצה מעשית. אדם אשר מבין את התרבות יכול לטייל רחוק
בנבכי עולם הקוד הפתוח,להתקל במספר רב של ניבים ומנהגים מותאמים, ובכל-זאת
להיות מסוגל לקחת חלק בנוחות בכל מקום. לעומתו, אדם שאינו מבין את התרבות
ימצא את תהליך ארגון והשתתפות בפרוייקט, קשה ומלא הפתעות. מאחר ומספר
האנשים המפתחים תוכנה חופשית עודנו גדל בקצב ניכר, ישנם רבים בקבוצה
השניה - אשר ברובה מהווה תרבות של מהגרים חדשים, ותשאר כזו במשך זמן מה.
אם אתה חושב שאתה אחד מהם, הקטע הבא מספק רקע לדיונים אשר תפגוש בהמשך
בין אם בספר זה, או ברשת האינטרנט. (מאידך, אם אתה עובד עם קוד פתוח זמן
מה, ייתכן ואתה כבר מכיר הרבה מההיסטוריה, ותרצה לדלג לקטע הבא.)היסטוריהSoftware sharing has been around as long as software itself. In
the early days of computers, manufacturers felt that competitive
advantages were to be had mainly in hardware innovation, and therefore
didn't pay much attention to software as a business asset. Many of
the customers for these early machines were scientists or technicians,
who were able to modify and extend the software shipped with the
machine themselves. Customers sometimes distributed their patches
back not only to the manufacturer, but to other owners of similar
machines. The manufacturers often tolerated and even encouraged this:
in their eyes, improvements to the software, from whatever source,
just made the machine more attractive to other potential
customers.Although this early period resembled today's free software
culture in many ways, it differed in two crucial respects. First,
there was as yet little standardization of hardware—it was a
time of flourishing innovation in computer design, but the diversity
of computing architectures meant that everything was incompatible with
everything else. Thus, software written for one machine would
generally not work on another. Programmers tended to acquire
expertise in a particular architecture or family of architectures
(whereas today they would be more likely to acquire expertise in a
programming language or family of languages, confident that their
expertise will be transferable to whatever computing hardware they
happen to find themselves working with). Because a person's expertise
tended to be specific to one kind of computer, their accumulation of
expertise had the effect of making that computer more attractive to
them and their colleagues. It was therefore in the manufacturer's
interests for machine-specific code and knowledge to spread as widely
as possible.Second, there was no Internet. Though there were fewer legal
restrictions on sharing than today, there were more technical ones:
the means of getting data from place to place were inconvenient and
cumbersome, relatively speaking. There were some small, local
networks, good for sharing information among employees at the same
research lab or company. But there remained barriers to overcome if
one wanted to share with everyone, no matter where they were. These
barriers were overcome in many cases. Sometimes
different groups made contact with each other independently, sending
disks or tapes through land mail, and sometimes the manufacturers
themselves served as central clearing houses for patches. It also
helped that many of the early computer developers worked at
universities, where publishing one's knowledge was expected. But the
physical realities of data transmission meant there was always an
impedance to sharing, an impedance proportional to the distance (real
or organizational) that the software had to travel. Widespread,
frictionless sharing, as we know it today, was not possible.עלייתן של התוכנה הקניינית והתוכנה החופשיתAs the industry matured, several interrelated changes occurred
simultaneously. The wild diversity of hardware designs gradually gave
way to a few clear winners—winners through superior technology,
superior marketing, or some combination of the two. At the same time,
and not entirely coincidentally, the development of so-called "high
level" programming languages meant that one could write a program
once, in one language, and have it automatically translated
("compiled") to run on different kinds of computers. The implications
of this were not lost on the hardware manufacturers: a customer could
now undertake a major software engineering effort without necessarily
locking themselves into one particular computer architecture. When
this was combined with the gradual narrowing of performance
differences between various computers, as the less efficient designs
were weeded out, a manufacturer that treated its hardware as its only
asset could look forward to a future of declining profit margins. Raw
computing power was becoming a fungible good, while software was
becoming the differentiator. Selling software, or at least treating
it as an integral part of hardware sales, began to look like a good
strategy.This meant that manufacturers had to start enforcing the
copyrights on their code more strictly. If users simply continued to
share and modify code freely among themselves, they might
independently reimplement some of the improvements now being sold as
"added value" by the supplier. Worse, shared code could get into the
hands of competitors. The irony is that all this was happening around
the time the Internet was getting off the ground. Just when truly
unobstructed software sharing was finally becoming technically
possible, changes in the computer business made it economically
undesirable, at least from the point of view of any single company.
The suppliers clamped down, either denying users access to the code
that ran their machines, or insisting on non-disclosure agreements
that made effective sharing impossible.Conscious resistanceAs the world of unrestricted code swapping slowly faded away, a
counterreaction crystallized in the mind of at least one programmer.
Richard Stallman worked in the Artificial Intelligence Lab at the
Massachusetts Institute of Technology in the 1970s and early '80s,
during what turned out to be a golden age and a golden location for
code sharing. The AI Lab had a strong "hacker
ethic",Stallman uses the word "hacker" in the sense of
"someone who loves to program and enjoys being clever about it," not
the relatively new meaning of "someone who breaks into
computers." and people were not only encouraged but
expected to share whatever improvements they made to the system. As
Stallman wrote later:
We did not call our software "free software",
because that term did not yet exist; but that is what it was.
Whenever people from another university or a company wanted to
port and use a program, we gladly let them. If you saw someone
using an unfamiliar and interesting program, you could always
ask to see the source code, so that you could read it, change
it, or cannibalize parts of it to make a new program.
(from )
This Edenic community collapsed around Stallman shortly after
1980, when the changes that had been happening in the rest of the
industry finally caught up with the AI Lab. A startup company hired
away many of the Lab's programmers to work on an operating system
similar to what they had been working on at the Lab, only now under an
exclusive license. At the same time, the AI Lab acquired new
equipment that came with a proprietary operating system.Stallman saw the larger pattern in what was happening:
The modern computers of the era, such as the VAX
or the 68020, had their own operating systems, but none of them
were free software: you had to sign a nondisclosure agreement
even to get an executable copy.This meant that the first step in using a
computer was to promise not to help your neighbor. A cooperating
community was forbidden. The rule made by the owners of
proprietary software was, "If you share with your neighbor, you
are a pirate. If you want any changes, beg us to make them."
By some quirk of personality, he decided to resist the trend.
Instead of continuing to work at the now-decimated AI Lab, or taking a
job writing code at one of the new companies, where the results of his
work would be kept locked in a box, he resigned from the Lab and
started the GNU Project and the Free Software Foundation (FSF). The
goal of GNUIt stands for "GNU's Not Unix", and the
"GNU" in that expansion stands for...the same
thing. was to develop a completely free and open
computer operating system and body of application software, in which
users would never be prevented from hacking or from sharing their
modifications. He was, in essence, setting out to recreate what had
been destroyed at the AI Lab, but on a world-wide scale and without
the vulnerabilities that had made the AI Lab's culture susceptible to
disintegration.In addition to working on the new operating system, Stallman
devised a copyright license whose terms guaranteed that his code would
be perpetually free. The GNU General Public License (GPL) is a clever
piece of legal judo: it says that the code may be copied and modified
without restriction, and that both copies and derivative works (i.e.,
modified versions) must be distributed under the same license as the
original, with no additional restrictions. In effect, it uses
copyright law to achieve an effect opposite to that of traditional
copyright: instead of limiting the software's distribution, it
prevents anyone, even the author, from limiting
it. For Stallman, this was better than simply putting his code into
the public domain. If it were in the public domain, any particular
copy of it could be incorporated into a proprietary program (as has
also been known to happen to code under permissive copyright
licenses). While such incorporation wouldn't in any way diminish the
original code's continued availability, it would have meant that
Stallman's efforts could benefit the enemy—proprietary software.
The GPL can be thought of as a form of protectionism for free
software, because it prevents non-free software from taking full
advantage of GPLed code. The GPL and its relationship to other free
software licenses are discussed in detail in
.With the help of many programmers, some of whom shared
Stallman's ideology and some of whom simply wanted to see a lot of
free code available, the GNU Project began releasing free replacements
for many of the most critical components of an operating system.
Because of the now-widespread standardization in computer hardware and
software, it was possible to use the GNU replacements on otherwise
non-free systems, and many people did. The GNU text editor (Emacs)
and C compiler (GCC) were particularly successful, gaining large and
loyal followings not on ideological grounds, but simply on their
technical merits. By about 1990, GNU had produced most of a free
operating system, except for the kernel—the part that the
machine actually boots up, and that is responsible for managing memory,
disk, and other system resources.Unfortunately, the GNU project had chosen a kernel design that
turned out to be harder to implement than expected. The ensuing delay
prevented the Free Software Foundation from making the first release
of an entirely free operating system. The final piece was put into
place instead by Linus Torvalds, a Finnish computer science student
who, with the help of volunteers around the world, had completed a
free kernel using a more conservative design. He named it Linux, and
when it was combined with the existing GNU programs, the result was a
completely free operating system. For the first time, you could boot
up your computer and do work without using any proprietary
software.Technically, Linux was not the first. A free
operating system for IBM-compatible computers, called 386BSD, had come
out shortly before Linux. However, it was a lot harder to get 386BSD
up and running. Linux made such a splash not only because it was
free, but because it actually had a high chance of booting your
computer when you installed it.Much of the software on this new operating system was not
produced by the GNU project. In fact, GNU wasn't even the only group
working on producing a free operating system (for example, the code
that eventually became NetBSD and FreeBSD was already under
development by this time). The importance of the Free Software
Foundation was not only in the code they wrote, but in their political
rhetoric. By talking about free software as a cause instead of a
convenience, they made it difficult for
programmers not to have a political consciousness
about it. Even those who disagreed with the FSF had to engage the
issue, if only to stake out a different position. The FSF's
effectiveness as propagandists lay in tying their code to a message,
by means of the GPL and other texts. As their code spread widely,
that message spread as well.Accidental resistanceThere were many other things going on in the nascent free
software scene, however, and few were as explictly ideological as
Stallman's GNU Project. One of the most important was
the Berkeley Software Distribution
(BSD), a gradual re-implementation of the Unix
operating system—which up until the late 1970's had been a
loosely proprietary research project at AT&T—by programmers
at the University of California at Berkeley. The BSD group did not
make any overt political statements about the need for programmers to
band together and share with one another, but they
practiced the idea with flair and
enthusiasm, by coordinating a massive distributed development effort
in which the Unix command-line utilities and code libraries, and
eventually the operating system kernel itself, were rewritten from
scratch mostly by volunteers. The BSD project became a prime example
of non-ideological free software development, and also served as a
training ground for many developers who would go on to remain active
in the open source world.Another crucible of cooperative development was the X
Window System, a free, network-transparent graphical
computing environment, developed at MIT in the mid-1980's in
partnership with hardware vendors who had a common interest in being
able to offer their customers a windowing system. Far from opposing
proprietary software, the X license deliberately allowed proprietary
extensions on top of the free core—each member of the consortium
wanted the chance to enhance the default X distribution, and thereby
gain a competitive advantage over the other members. X
WindowsThey prefer it to be called the "X Window
System", but in practice, people usually call it "X Windows", because
three words is just too cumbersome. itself was free
software, but mainly as a way to level the playing field between
competing business interests, not out of some desire to end the
dominance of proprietary software. Yet another example, predating the
GNU project by a few years, was TeX, Donald Knuth's free,
publishing-quality typesetting system. He released it under a license
that allowed anyone to modify and distribute the code, but not to call
the result "TeX" unless it passed a very strict set of compatibility
tests (this is an example of the "trademark-protecting" class of free
licenses, discussed more in ). Knuth wasn't
taking a stand one way or the other on the question of
free-versus-proprietary software, he just needed a better typesetting
system in order to complete his
real goal—a book on computer
programming—and saw no reason not to release his system to the
world when done.Without listing every project and every license, it's safe to
say that by the late 1980's, there was a lot of free software
available under a wide variety of licenses. The diversity of licenses
reflected a corresponding diversity of motivations. Even some of the
progammers who chose the GNU GPL were much less ideologically driven
than the GNU project itself. Although they enjoyed working on free
software, many developers did not consider proprietary software a
social evil. There were people who felt a moral impulse to rid the
world of "software hoarding" (Stallman's term for non-free software),
but others were motivated more by technical excitement, or by the
pleasure of working with like-minded collaborators, or even by a
simple human desire for glory. Yet by and large these disparate
motivations did not interact in destructive ways. This is partly
because software, unlike other creative forms like prose or the visual
arts, must pass semi-objective tests in order to be considered
successful: it must run, and be reasonably free of bugs. This gives
all participants in a project a kind of automatic common ground, a
reason and a framework for working together without worrying too much
about qualifications beyond the technical.Developers had another reason to stick together as well: it
turned out that the free software world was producing some very
high-quality code. In some cases, it was demonstrably technically
superior to the nearest non-free alternative; in others, it was at
least comparable, and of course it always cost less. While only a few
people might have been motivated to run free software on strictly
philosophical grounds, a great many people were happy to run it
because it did a better job. And of those who used it, some
percentage were always willing to donate their time and skills to help
maintain and improve the software.This tendency to produce good code was certainly not universal,
but it was happening with increasing frequency in free software
projects around the world. Businesses that depended heavily on
software gradually began to take notice. Many of them discovered that
they were already using free software in day-to-day operations, and
simply hadn't known it (upper management isn't always aware of
everything the IT department does). Corporations began to take a more
active and public role in free software projects, contributing time
and equipment, and sometimes even directly funding the development of
free programs. Such investments could, in the best scenarios, repay
themselves many times over. The sponsor only pays a small number of
expert programmers to devote themselves to the project full time, but
reaps the benefits of everyone's contributions,
including work from unpaid volunteers and from programmers being paid
by other corporations."חופשי" לעומת "קוד פתוח"As the corporate world gave more and more attention to free
software, programmers were faced with new issues of presentation. One
was the word "free" itself. On first hearing the term "free software"
many people mistakenly think it means just "zero-cost software." It's
true that all free software is zero-cost,One may charge
a fee for giving out copies of free software, but since one cannot
stop the recipients from offering it at no charge afterwards, the
price is effectively driven to zero immediately.
but not all zero-cost software is free. For example, during the
battle of the browsers in the 1990s, both Netscape and Microsoft gave
away their competing web browsers at no charge, in a scramble to gain
market share. Neither browser was free in the "free software" sense.
You couldn't get the source code, and even if you could, you didn't
have the right to modify or redistribute it.The source
code to Netscape Navigator
was eventually released under an open source
license, in 1998, and became the foundation for the Mozilla web
browser. See . The only thing
you could do was download an executable and run it. The browsers were
no more free than shrink-wrapped software bought in a store; they
merely had a lower price.This confusion over the word "free" is due entirely to an
unfortunate ambiguity in the English language. Most other tongues
distinguish low prices from liberty (the distinction between
gratis and libre is
immediately clear to speakers of Romance languages, for example). But
English's position as the de facto bridge language of the Internet
means that a problem with English is, to some degree, a problem for
everyone. The misunderstanding around the word "free" was so
prevalent that free software programmers eventually evolved a standard
formula in response: "It's free as in
freedom—think free
speech, not free beer." Still, having
to explain it over and over is tiring. Many programmers felt, with
some justification, that the ambiguous word "free" was hampering the
public's understanding of this software.But the problem went deeper than that. The word "free" carried
with it an inescapable moral connotation: if freedom was an end in
itself, it didn't matter whether free software also happened to
be better, or more profitable for certain businesses in certain
circumstances. Those were merely pleasant side effects of a motive
that was, at bottom, neither technical nor mercantile, but moral.
Furthermore, the "free as in freedom" position forced a glaring
inconsistency on corporations who wanted to support particular free
programs in one aspect of their business, but continue marketing
proprietary software in others.These dilemmas came to a community that was already poised for
an identity crisis. The programmers who actually
write free software have never been of one mind
about the overall goal, if any, of the free software movement. Even
to say that opinions run from one extreme to the other would be
misleading, in that it would falsely imply a linear range where there
is instead a multidimensional scattering. However, two broad
categories of belief can be distinguished, if we are willing to ignore
subtleties for the moment. One group takes Stallman's view, that the
freedom to share and modify is the most important thing, and that
therefore if you stop talking about freedom, you've left out the core
issue. Others feel that the software itself is the most important
argument in its favor, and are uncomfortable with proclaiming
proprietary software inherently bad. Some, but not all, free
software programmers believe that the author (or employer, in the case
of paid work)
should have the right to control the terms of
distribution, and that no moral judgement need be attached to the
choice of particular terms.For a long time, these differences did not need to be carefully
examined or articulated, but free software's burgeoning success in the
business world made the issue unavoidable. In 1998, the term
open source was created as an alternative
to "free", by a coalition of programmers who eventually became The
Open Source Initiative (OSI).OSI's web home is . The OSI felt
not only that "free software" was potentially confusing, but that the
word "free" was just one symptom of a general problem: that the
movement needed a marketing program to pitch it to the corporate
world, and that talk of morals and the social benefits of sharing
would never fly in corporate boardrooms. In their own words:
The Open Source Initiative is a marketing
program for free software. It's a pitch for "free software" on
solid pragmatic grounds rather than ideological
tub-thumping. The winning substance has not changed, the losing
attitude and symbolism have. ...The case that needs to be made to most techies
isn't about the concept of open source, but the name. Why not
call it, as we traditionally have, free software?One direct reason is that the term "free
software" is easily misunderstood in ways that lead to
conflict. ...But the real reason for the re-labeling is a
marketing one. We're trying to pitch our concept to the
corporate world now. We have a winning product, but our
positioning, in the past, has been awful. The term "free
software" has been misunderstood by business persons, who
mistake the desire to share with anti-commercialism, or worse,
theft.Mainstream corporate CEOs and CTOs will never
buy "free software." But if we take the very same tradition, the
same people, and the same free-software licenses and change the
label to "open source" ? that, they'll buy.Some hackers find this hard to believe, but
that's because they're techies who think in concrete,
substantial terms and don't understand how important image is
when you're selling something.In marketing, appearance is reality. The
appearance that we're willing to climb down off the barricades
and work with the corporate world counts for as much as the
reality of our behavior, our convictions, and our
software.(from
and )
The tips of many icebergs of controversy are visible in that
text. It refers to "our convictions", but smartly avoids spelling out
exactly what those convictions are. For some, it might be the
conviction that code developed according to an open process will be
better code; for others, it might be the conviction that all
information should be shared. There's the use of the word "theft" to
refer (presumably) to illegal copying—a usage that many object
to, on the grounds that it's not theft if the original possessor still
has the item afterwards. There's the tantalizing hint that the free
software movement might be mistakenly accused of anti-commercialism,
but it leaves carefully unexamined the question of whether such an
accusation would have any basis in fact.None of which is to say that the OSI's web site is inconsistent
or misleading. It's not. Rather, it is an example of exactly what
the OSI claims had been missing from the free software movement: good
marketing, where "good" means "viable in the business world." The
Open Source Initiative gave a lot of people exactly what they had been
looking for—a vocabulary for talking about free software as a
development methodology and business strategy, instead of as a moral
crusade.The appearance of the Open Source Initiative changed the
landscape of free software. It formalized a dichotomy that had long
been unnamed, and in doing so forced the movement to acknowledge that
it had internal politics as well as external. The effect today is
that both sides have had to find common ground, since most projects
include programmers from both camps, as well as participants who don't
fit any clear category. This doesn't mean people never talk about
moral motivations—lapses in the traditional "hacker ethic" are
sometimes called out, for example. But it is rare for a free software
/ open source developer to openly question the basic motivations of
others in a project. The contribution trumps the contributor. If
someone writes good code, you don't ask them whether they do it for
moral reasons, or because their employer paid them to, or because
they're building up their resumé, or whatever. You evaluate
the contribution on technical grounds, and respond on technical
grounds. Even explicitly political organizations like the Debian
project, whose goal is to offer a 100% free (that is, "free as in
freedom") computing environment, are fairly relaxed about integrating
with non-free code and cooperating with programmers who don't share
exactly the same goals.המצב היוםWhen running a free software project, you won't need to talk
about such weighty philosophical matters on a daily basis.
Programmers will not insist that everyone else in the project agree
with their views on all things (those who do insist on this quickly
find themselves unable to work in any project). But you do need to be
aware that the question of "free" versus "open source" exists, partly
to avoid saying things that might be inimical to some of the
participants, and partly because understanding developers' motivations
is the best way—in some sense, the only
way—to manage a project.Free software is a culture by choice. To operate successfully
in it, you have to understand why people choose to be in it in the
first place. Coercive techniques don't work. If people are unhappy in
one project, they will just wander off to another one. Free software
is remarkable even among volunteer communities for its lightness of
investment. Most of the people involved have never actually met the
other participants face-to-face, and simply donate bits of time
whenever they feel like it. The normal conduits by which humans bond
with each other and form lasting groups are narrowed down to a tiny
channel: the written word, carried over electronic wires. Because of
this, it can take a long time for a cohesive and dedicated group to
form. Conversely, it's quite easy for a project to lose a potential
volunteer in the first five minutes of acquaintanceship. If a project
doesn't make a good first impression, newcomers rarely give it a
second chance.The transience, or rather the potential
transience, of relationships is perhaps the single most daunting task
facing a new project. What will persuade all these people to stick
together long enough to produce something useful? The answer to that
question is complex enough to occupy the rest of this book, but if it
had to be expressed in one sentence, it would be this:
People should feel that their connection to a
project, and influence over it, is directly proportional to
their contributions.
No class of developers, or potential developers, should ever
feel discounted or discriminated against for non-technical reasons.
Clearly, projects with corporate sponsorship and/or salaried
developers need to be especially careful in this regard, as discusses in detail. Of course, this doesn't
mean that if there's no corporate sponsorship then you have nothing to
worry about. Money is merely one of many factors that can affect the
success of a project. There are also questions of what language to
choose, what license, what development process, precisely what kind of
infrastructure to set up, how to publicize the project's inception
effectively, and much more. Starting a project out on the right foot
is the topic of the next
chapter.