הקתדרלה והבזאר/הקתדרלה והבזאר

היסטורית הגירסאות

הצגה ראשונה של המאמר ב-Linux Kongress (גירסה 1.16 ב- 21 מאי 1997 )

הוספת ביבליוגרפיה (גירסה 1.20 ב- 7 ביולי 1977 )

הוספת אנקדוטה מכנס Perl (גירסה 1.27 ב- 18 נובמבר 1998 )

שינוי המונח "תוכנה חופשית" למונח "קוד פתוח" ( גירסה 1.29 ב- 9 פברואר 1998 )

הוספת הפרק "סוף דבר : נטסקייפ מצטרפת לבזאר!" ( גירסה 1.31 ב- 10 פברואר 1998 )

הסרת הגרף של פול אגרט "GPL בניגוד לבזאר" בתגובה לטיעונים מתנגדים (גירסה 1.39 ב- 28 יולי 1998 )

הוספת תיקון של ברוקס המתבסס על מסמכי "ליל כל הקדושים" (גירסה 1.40 ב- 20 נובמבר 1998 )

הוספת הפרק "על הנהלה וקו מז'ינו", כמה רעיונות על השימושיות של בזארים בחקר של אפשרויות תכנון, שיפור סוף-דבר בצורה משמעותית (גירסה 1.44 ב- 29 יולי 1999 )

הוספת הערות השוליים העוסקות בעיקרון SNAFU, דוגמאות פרה-היסטוריות של פיתוח בזאר ומקוריות בתכנון (גירסה 1.45 ב- 8 אוגוסט 1999 )

הוספת הערת שוליים [HBS] על זמני פיתוח (גירסה 1.49 ב- 5 מאי 2000 )

הוספת דוגמא נוספת המבוססת על פיתוח MATLAB ( גירסה 1.52 ב- 28 אוגוסט 2000 )

הוספת פרק חדש " כמה עיניים צריך כדי לשתלט על מורכבות? " (גירסה 1.57 ב- 11 ספטמבר 2000)

הפשטה

במסמך זה אנתח פרוייקט קוד-פתוח מוצלח, Fetchmail, שרץ כניסיון מכוון לבדוק כמה מהתיאוריות המפתיעות על הנדסת תוכנה שעלו מההיסטוריה של לינוקס. אדון בתיאוריות אלו במונחים של שתי שיטות פיתוח בסיסיות שונות, מודל ה"קתדרלה" של רובו של העולם המסחרי ומולו מודל ה"בזאר" של עולם הלינוקס. אראה ששני המודלים מתפתחים משתי הנחות מנוגדות באשר לאופייה של מלאכת דיבוג התוכנה. אוכיח אז, בעזרת הניסיון שנצבר עם לינוקס, את הטענה כי "בעזרת מספיק עיניים, כל הבאגים שטחיים", אציע אנלוגיות מעשיות למערכות תיקון-עצמי אחרות של סוכנים אנוכיים, ואסיים בבדיקת ההשלכות של הראייה החדשה הזו על עתיד עולם התוכנה.

הקתדרלה והבזאר

לינוקס הוא מחתרתי. מי היה חושב, אפילו לפני חמש שנים בלבד (1991), שניתן ליצור מערכת הפעלה מהשורה הראשונה, כאילו בקסם, על ידי כמה אלפי מפתחים והאקרים בשעות הפנאי והמפוזרים על פני כל העולם, מחוברים רק על-ידי הקורים העדינים של האינטרנט?

בהחלט לא אני. כשלינוקס הזדחל למסך המכ"מ שלי בתחילת 1993 כבר הייתי מעורב ביוניקס ובפיתוח תוכנות קוד-פתוח מזה כ- 10 שנים. הייתי אחד מהתורמים הראשונים ל-GNU באמצע שנות השמונים. פרסמתי כמות גדולה של תוכנת קוד-פתוח לרשת, ופיתחתי או סייעתי בפיתוח מספר תוכנות (nethack, Emacs, VC ו-GUD, xlife ואחרות) שהן עדיין בשימוש נרחב כיום. חשבתי שידעתי איך עושים את זה.

לינוקס הפך לחלוטין את מה שחשבתי שידעתי. מזה שנים שהייתי מטיף לבשורת היוניקס, הדוגלת בכלים קטנים, שימוש נרחב באב-טיפוסים ותכנות מתפתח. אבל גם האמנתי שיש רמה קריטית של מורכבות שמעליה יש צורך בגישה יותר מרוכזת, יותר מתוכננת מראש. האמנתי שהתוכנות החשובות ביותר (מערכות הפעלה וכלים גדולים באמת כמו Emacs) צריכות להיבנות כמו קתדרלות, מורכבות בזהירות על ידי קוסמים בודדים או קבוצות של קוסמים העובדים בבדידות מזהירה, בלי לפרסם אף גרסת בטא בטרם זמנה.

סגנון הפיתוח של לינוס טורוולדס – פרסם מוקדם ולעתים קרובות, בזר סמכויות ככל האפשר, היה שקוף עד כדי בלבול – באה עלי בהפתעה. לא היה כאן פיתוח שקט וממוקד בנוסח הקתדרלה – במקום זאת, קהילת הלינוקס דמתה יותר לבזאר גדול ורועש של עמדות שונות וגישות שונות (סמל טוב לכך יהיו אתרי הארכיב של תוכנות לינוקס, המקבלים תוספות מ כל אחד) ואשר מתוכו צמחה מערכת עקבית ויציבה, שלמראית עין הייתה יכולה לצמוח רק על ידי נסים.

ההבחנה שסגנון הבזאר יכול לעבוד, ולעבוד היטב, באה עלי בהלם ברור. אחרי שהכרתי את הסביבה עבדתי קשה לא רק על הפרוייקטים העצמאיים אלא גם ניסיתי להבין מדוע עולם הלינוקס לא התפרק לגורמים מתוך הבלבול אלא הגדיל את כוחו במהירות שקשה למפתחי קתדרלה אפילו לדמיין אותה.

באמצע 1996 חשבתי שהתחלתי להבין. המזל זימן לי את הדרך המושלמת לבחון את התיאוריה שלי, בדמות פרוייקט קוד-פתוח שאותו יכולתי להריץ בסגנון הבזאר באופן מודע. כך עשיתי – והוא היה הצלחה רצינית.

זהו סיפורו של הפרוייקט שלי. אני אשתמש בו כדי להציע כמה קביעות קצרות על האפקטיביות של פיתוח קוד-פתוח. לא את כל הדברים האלה למדתי בעולם הלינוקס, אבל עוד נראה איך עולם הלינוקס נותן להם חוד מסוים. אם אני צודק, הם יעזרו לך להבין בדיוק מה הוא הדבר שהופך את קהילת הלינוקס לכזה מעיין של תוכנה טובה – ואולי גם יעזור לך להיות יותר יצרני בעצמך.

הדואר חייב לעבור

מאז 1993 הרצתי את הצד הטכני של ISP קטן בעל גישה חינם בשם Chester County InterLink (CCIL) במערב צ'סטר, פנסילבניה (עזרתי להקים אתCCIL וכתבתי את תוכנת לוח המודעות רבת המשתמשים הייחודית שלנו – אתם יכולים לבדוק אותה בעצמכם על-ידי טלנט ל- locke.ccil.org. היום הוא תומך בכמעט 3000 משתמשים על 30 קווים). העבודה אפשרה לי גישה של 24 שעות ביום לרשת דרך חיבור ה-56K של CCIL – בעצם, היא ממש דרשה את זה!

משום כך, התרגלתי מאוד לדואר אלקטרוני מיידי מהאינטרנט. מסיבות מורכבות היה קשה לגרום ל-SLIP לעבוד בין המחשב שלי בבית (snark.thyrsus.com) לבין CCIL. כאשר לבסוף הצלחתי, גיליתי שהצורך לטלנט לעתים קרובות ל-locke כדי לבדוק את הדואר שלי היה מעצבן. מה שרציתי היה שהדואר שלי יישלח ל-snark כך שאדע מתי כשהוא מגיע ואוכל לטפל בו בעזרת כל הכלים המקומיים. שליחת דואר על-ידי sendmail פשוט לא הייתה עוזרת לי, כי מחשב הבית שלי לא היה תמיד על הרשת ולא הייתה לו כתובת IP קבועה. מה שהייתי צריך הייתה תוכנה שתגיע מעבר לחיבור ה-SLIP ותמשוך את הדואר שלי, כדי שיחולק מקומית. ידעתי שכאלה דברים היו קיימים, ורובם השתמשו בפרוטוקול תוכנה פשוט שנקרא POP (Post Office Protocol) וכמובן, כבר היה שרת POP3 מצורף עם מערכת ההפעלה BSD/OS של locke.

הייתי צריך לקוח POP3. אז פניתי לרשת ומצאתי אחד. למעשה, מצאתי שלוש או ארבע. השתמשתי ב-pop-perl במשך כמה זמן, אבל היה חסר בו מה שראיתי כיכולת מובנת מאליה, היכולת לשנות את הכתובות על הדואר שהורד כך שתשובות למכתבים יעבדו כמו שצריך.

הבעיה הייתה כזו: נניח שמישהו בשם joe על locke שלח לי דואר. אם הורדתי את הדואר ל-snark ואז ניסיתי לענות לו, תוכנת הדואר שלי הייתה מנסה בעליזות לשלוח אותו ל-joe בלתי קיים על snark. עריכה ידנית של כתובות התשובה והוספה של "ccil.org@" בסופן נעשתה מהר מאוד למטרד רציני.

זה בפירוש היה משהו שעל המחשב היה לעשות בשבילי. אבל אף אחת מלקוחות ה-POP הקיימים ידעו איך לעשות זאת! מה שמביא אותנו לשיעור הראשון:

1. כל עבודת תכנות טובה מתחילה בפתרון מטרד אישי של המפתח.

יכול להיות שזה היה צריך להיות מובן מאליו (אחרי הכל, פתגם ידוע הוא "צורך היא אמה של ההמצאה") אבל לעתים קרובות מדי מפתחי תוכנה משקיעים את ימיהם, בעבודה קשה עבור שכר, כדי לפתח תוכנות שהם אינם צריכים ואינם אוהבים. אבל לא בעולם הלינוקס – מה שיכול להסביר מדוע האיכות הממוצעת של תוכנה המגיעה מעולם הלינוקס היא כל-כך גבוהה.

כאן, האם נכנסתי במהירות למערבולת עצבנית של תכנות כדי ליצור לקוח POP3 חדש שיתחרה עם הלקוחות הקיימים? בחיים לא! הסתכלתי בזהירות על תוכנות העזר ל-POP שהיו לי ביד, ושאלתי את עצמי "מה מהן היא הקרובה ביותר למה שאני רוצה?". משום ש:

2. מתכנתים טובים יודעים מה לכתוב. מתכנתים מעולים יודעים מה לשכתב (ובמה להשתמש מחדש)

אני לא מתיימר להיות מתכנת מעולה, אבל אני מנסה לחקות אחד כזה. נטייה חשובה של המעולים היא עצלנות קונסטרוקטיבית. הם יודעים שמקבלים ציון "טוב מאוד" לא על מאמץ אלא על תוצאות, והם יודעים שכמעט תמיד קל יותר להתחיל מפתרון חלקי טוב מאשר משום-דבר בכלל. לינוס טורוולדס, למשל, לא באמת ניסה לכתוב את כל לינוקס מחדש. במקום זאת הוא התחיל על-ידי שימוש מחדש בקוד ורעיונות מ-Minix, מערכת הפעלה זעירה דומה ליוניקס לתואמי PC. בסופו של דבר כל הקוד המקורי של Minix יצא או שוכתב לחלוטין – אבל בזמן שהוא עדיין היה שם הוא סיפק מסגרת לתינוק שבסופו של דבר יהיה לינוקס.

מסורת השיתוף-בקוד של עולם היוניקס הייתה תמיד ידידותית לשימוש מחדש בקוד (וזו הייתה הסיבה שפרוייקט GNU בחר ביוניקס כמערכת ההפעלה הבסיסית שלו, למרות הסתייגויות רציניות בקשר למערכת ההפעלה עצמה). עולם הלינוקס הביא את המסורת הזו כמעט עד למגבלה הטכנולוגית שלה; יש טרה-בייטים של קוד פתוח נגיש לציבור. כך שלניצול הזמן לחיפוש פתרון כמעט-מספיק-טוב של מישהו אחר יש סיכוי טוב יותר לתת תוצאות טובות בעולם הלינוקס מאשר בכל מקום אחר.

וכך היה בשבילי. יחד עם אלה שמצאתי קודם לכן, החיפוש השני שלי העלה בסך הכל תשעה מועמדים – fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail ו-upop. הראשון שבחרתי בו היה fetchpop של סאונג-הונג או. הוספתי לו את יכולת שכתוב הכותרת שלי, והוספתי כמה שיפורים אחרים שהכותב קיבל לגרסה 1.9.

כמה שבועות לאחר מכן, למרות זאת, נתקלתי בקוד של popclient של קארל האריס, וגיליתי שהייתה לי בעיה. למרות של-fetchpop היו כמה רעיונות טובים ומקוריים (כמו מצב daemon), היא יכול היה לטפל רק ב-POP3 והיה מקודד בצורה חובבנית (סאונג-הונג היה באותו הזמן מתכנת מבריק אבל חסר ניסיון, ושתי הנטיות היו בולטות). הקוד של קארל היה טוב יותר, מקצועי למדי ויציב, אבל התוכנה שלו הייתה חסרה כמה יכולות חשובות וקשות-ליישום שהיו קיימות ב-fetchpop (כולל אלה שהוספתי בעצמי).

להישאר או לעבור? אם אעבור, אני אזרוק את כל התכנות שכבר עשיתי בתמורה לבסיס טוב יותר לפיתוח.

מניע מעשי לעבור היה הייתה היכולת לריבוי פרוטוקולים. POP3 הוא הפרוטוקול הנפוץ ביותר מבין הפרוטוקולים של שרתי בית-דואר, אבל הוא אינו היחיד. fetchpop וכמה מהמתחרים לא יכלו לבצע POP2, RPOP או APOP וכבר היא לי מחשבות עמומות על הוספת תמיכה ב- IMAP – Internet Message Access Protocol, (הפרוטוקול החדש והחזק ביותר לבית-דואר) רק בשביל הכיף.

אבל הייתה לי סיבה יותר תיאורטית שגרמה לי לחשוב שהמעבר יכול להיות רעיון טוב, משהו שלמדתי הרבה לפני לינוקס.

3. תכנן מראש לזרוק ניסיון אחד לפח; בכל מקרה תצטרך. (The Mythical Man-Month, מאת פרד ברוקס, פרק 11).

או, אם לומר זאת בדרך אחרת, לעתים קרובות אתה לא באמת מבין את הבעיה עד הפעם הראשונה שיישמת פתרון. בפעם השנייה, אולי תדע מספיק כדי לעשות זאת כמו שצריך. כך שאם אתה רוצה לעשות זאת כמו שצריך, היה מוכן להתחיל מחדש לפחות פעם אחת. [JB].

נו, (אמרתי לעצמי), השינויים ל-fetchpop היא הניסיון הראשון שלי. אז עברתי.

אחרי ששלחתי את הסט הראשון של הטלאים שלי לקארל האריס ב25- ביוני 1996, גיליתי שהוא בעצם איבד עניין ב-popclient כמה זמן לפני כן. הקוד היה קצת מאובק, עם באגים קטנים שצצו פה ושם. היו לי הרבה שינויים לעשות, ומהר מאוד החלטנו שהדבר ההגיוני לעשות הוא שאקח את התוכנה לידי.

בלי שבעצם שמתי לב, הפרוייקט הסלים. כבר לא רק חשבתי על טלאים קטנים ללקוח POP קיים. לקחתי על עצמי תחזוקה של תוכנה שלמה, והיו לי רעיונות מבעבעים בראש שידעתי שכנראה יובילו לשינויים רציניים.

בתרבות תוכנה המעודדת שיתוף בקוד, זו הייתה הדרך הטבעית לפרוייקט להתפתח. פעלתי על-פי העיקרון הזה:

4. אם יש לך גישה נכונה, בעיות מעניינות ימצאו אותך

אבל הגישה של קארל האריס הייתה אפילו יותר חשובה. הוא הבין ש:

5. כאשר אתה מאבד עניין בתוכנית, משימתך האחרונה היא להעביר אותה ליורש מתאים

מבלי שהיה עלינו לדון בכך, לקארל ולי הייתה מטרה משותפת: להגיע לפתרון הטוב ביותר. השאלה היחידה לשנינו הייתה איך לדעת אם הייתי אדם שבטוח להעביר אליו את הפרוייקט. ברגע שהוכחתי זאת, הוא פעל בחן ובמהירות. אני מקווה שאעשה כמוהו כשיגיע תורי.

החשיבות שיהיו משתמשים

וכך ירשתי את popclient. וחשוב לא פחות, ירשתי את בסיס המשתמשים של popclient. משתמשים הם דבר נהדר, ולא רק בגלל שהם מדגימים שאתה משרת צורך, שאתה עושה משהו כמו שצריך. אם מטפחים אותם, הם נעשים מפתחים-מסייעים.

עוד נקודה חזקה של מסורת היוניקס, נקודה שלינוקס דוחף עד לקיצוניות מאושרת, היא שהרבה משתמשים הם האקרים בעצמם. בגלל שקוד המקור נגיש, הם יכולים להיות האקרים אפקטיביים. זה יכול להיות שימושי להדהים בצמצום זמן הדיבוג. עם קצת עידוד, המשתמשים שלך יכולים לאתר בעיות, להציע תיקונים, ולעזור בשיפור הקוד הרבה יותר מהר ממה שאתה יכול לעשות ללא עזרה.

6. התייחסות למשתמשים שלך כמפתחים-מסייעים היא הדרך הקלה ביותר לשיפור קוד מהיר ולדיבוג אפקטיבי.

קל מאוד לזלזל בכוח של ההשפעה הזו. למעשה, כמעט כולנו בעולם הקוד הפתוח לא הערכנו כמה טוב תפעל ההשפעה גם בגידול מספר המשתמשים יחד עם הגידול במורכבות המערכת – עד שלינוס טורוולדס הראה לנו.

בעצם, אני חושב שהשיפצור הפיקח ביותר ובעל ההשפעה הרבה ביותר היה לא בניית הגרעין של לינוקס עצמו, אלא ההמצאה של מודל הפיתוח של לינוקס. כשהזכרתי פעם אחת את הדעה הזו בנוכחותו הוא חייך ובשקט חזר על משהו שהוא אמר לעתים קרובות: "למעשה, אני אדם מאוד עצלן שאוהב לקחת קרדיט בשביל דברים שבעצם אנשים אחרים עושים". עצלן כמו שועל. או, כמו הציטטה המפורסמת מדבריו של אחת מדמויותיו של רוברט היינליין, עצלן מכדי להיכשל.

בדיעבד, אפשר לראות את אחד התקדימים לשיטות ולהצלחה של לינוקס בפיתוח של ספריית ה-LISP והארכיבים של קוד LISP ל-Emacs. בניגוד לסגנון בניית-הקתדרלה של ליבת ה-C של Emacs וכלים אחרים של FSF, האבולוציה של מאגר קוד ה-LISP של Emacs הייתה זורמת ונדחפה בעיקר על-ידי משתמשים. רעיונות ואב-טיפוסים של מצבים שוכתבו לעיתים קרובות שלוש או ארבע פעמים לפני שהגיעו למצב סופי יציב, ועבודות קבוצתיות של קבוצות רופפות מקושרות על-ידי האינטרנט, בסגנון לינוקס, היו נפוצות.

אכן, אחד השיפצורים המצליחים ביותר שלי לפני fetchmail היה כנראה VC של Emacs, עבודה משותפת דמוית-לינוקס יחד עם עוד שלושה אנשים, מתוכם עד היום פגשתי רק אחד מהם (ריצ'רד סטאלמן, מחבר Emacs ומייסד ה- FSF). המוד היה תוכנת שליטה ב-SCCS, RCS ולאחריו CVS מתוך Emacs שהציע שליטת-גרסאות ב"לחיצת כפתור אחת". הוא התפתח ממצב sccs.el זעיר וגולמי שמישהו אחר כתב. והפיתוח של VC הצליח בגלל שקוד ה-LISP של Emacs, שלא כמו Emacs עצמו, יכל לעבור את מעגל הפרסום / בדיקה / שיפורים מהר מאוד.

ספורו של Emacs אינו ייחודי. ישנם מוצרי תוכנה רבים בעלי ארכיטקטורה דו-שלבית וקהילת משתמשים בעלת שני סוגי אנשים, המשלבת גרעין "קתדרלה" וכלי "בזאר". דוגמא לכך היא MATLAB, כלי מסחרי לניתוח והצגת נתונים. משתמשי MATLAB ומוצרים בעלי ארכיטקטורה דומה מדווחים בקביעות שהעשייה, הלהט והחידוש מתרחשים בעיקר בחלקו הפתוח של מוצר התוכנה, אותו קהילה גדולה ומגוונת יכולה לשנות.

שחרר מוקדם, שחרר בתכיפות

שחרורים מוקדמים ותכופים הם חלק קריטי של מודל הפיתוח של לינוקס. רוב המפתחים (כולל אני) היו רגילים להאמין שזו הייתה מדיניות רעה בשביל פרוייקטים מעבר לגודל של פרוייקטים טריוויאליים, משום שגרסאות מוקדמות הן כמעט על-פי הגדרה מלאות באגים ואתה לא רוצה לאבד את הסבלנות של המשתמשים.

האמונה הזאת חיזקה את המחויבות הכללית לפיתוח בסגנון בניית-קתדרלה. אם המטרה הכללית הייתה שמשתמשים יראו מעט באגים ככל האפשר, מוטב לפרסם גרסה אחת כל שישה חודשים (ולעתים קרובות פחות) ולעבוד כמו חמור בין הגרסאות על דיבוג. ליבת ה-C של Emacs פותחה בדרך זו. ספריית ה-LISP, למעשה, לא – בגלל שהיו ארכיבים אקטיביים של ספריות LISP מחוץ לשליטת ה-FSF, ושם יכולת למצוא גרסאות מתפתחות של קוד, עצמאי ממחזור הפרסום של Emacs [QR].

הארכיב החשוב מכולם, ארכיב ה-eLISP של אוניברסיטת אוהיו, ראה מראש את הרוח הזו והרבה מהתכונות שקיימות היום בארכיבי לינוקס גדולים. אבל רק מעטים מאתנו באמת חשבו ברצינות על מה שעשינו או על מה שעצם קיום הארכיב אמר לגבי בעיות במודל הפיתוח בניית-קתדרלה של ה-FSF. ניסיתי פעם אחת ב- 1992 לגרום לשילוב רשמי של הרבה מהקוד של אוהיו לתוך ספריית ה-LISP הרשמית של Emacs, אבל נתקלתי בבעיות פוליטיות והניסיון לא היה מוצלח.

אבל שנה מאוחר יותר, כשלינוקס נעשה נפוץ, אפשר היה לראות שמשהו שונה והרבה יותר בריא התחיל לקרות. מדיניות הפיתוח הפתוחה של לינוס הייתה ההפך המושלם מבניית-קתדרלה. הארכיבים של Sunsite (כעת Metalab) ו-tsx-11 פרחו, וכל זה נגרם על ידי פרסומים של ליבת המערכת בקצב גבוה מכל פרוייקט אחר שהיה קודם לכן.

לינוס התייחס למשתמשים שלו כמפתחים-מסייעים בצורה האפקטיבית ביותר האפשרית:

7. שחרר מוקדם. שחרר תכופות. והקשב ללקוחותיך.

החידוש של לינוס לא היה כל-כך בכך שעשה זאת (משהו כזה היה מסורת של עולם היוניקס במשך זמן רב) אלא בכך שהעלה את סדר הגודל ואת קצב הפרסומים לרמה שתאמה את המורכבות של מה שהוא פיתח. באותם ימים מוקדמים (בסביבות 1991) לא היה נדיר שלינוס פרסם יותר מגרעין חדש אחד כל יום! בגלל שהוא טיפח את בסיס המפתחים-מסייעים שלו והשתמש באינטרנט לעבודה משותפת יותר מכל אחד אחר, זה עבד.

אבל איך זה עבד? והאם זה היה משהו שניתן לשכפל, או שהוא היה תלוי בגאוניות ייחודית של לינוס טורוולדס?

אני לא חשבתי כך. נכון שלינוס הוא האקר מעולה (כמה מאתנו יכולים להנדס גרעין שלם של מערכת הפעלה באיכות שימוש?). אבל לינוקס לא ייצג אף זינוק רעיוני מדהים קדימה. לינוס הוא לא (או לפחות, עדיין לא) גאון של תכנון חדשני כפי שלמשל ריצ'רד סטאלמן או ג'יימס גוזלינג (James Gosling, של NeWS ו-Java) הם כאלה. במקום זאת, לינוס נראה כגאון של הנדסה, עם חוש שישי להימנעות מבאגים ומבוי סתום פיתוחי, ויכולת אמיתית למצוא את הדרך הקלה ביותר מנקודה א' לנקודה ב'. ואכן, כל התכנון של לינוקס נושם את האיכות הזאת ומחקה את הגישה השמרנית והמפשטת של לינוס.

לכן, אם פרסום תכוף ושימוש באינטרנט לא היו מקרים לא-מכוונים אלא חלקים בלתי-נפרדים מגאוניות-התכנון של לינוס בניסיון למצוא את הדרך הקלה ביותר, מה לינוס הגביר? מה הוא הצליח להשיג מהמכונה?

בניסוח הזה, השאלה עונה על עצמה. לינוס הקפיד שבסיס המשתמשים / האקרים שלו יהיה מעודד ומתוגמל. עידוד – על ידי הרעיון מספק-האגו שחלק מהעבודה הזו היא שלהם, ותגמול – המראה של שיפור מתמיד (אפילו יומי) בתוצאה.

המטרה של לינוס הייתה להעלות עד למקסימום את מספר שעות-האדם שהושקעו בדיבוג ובפיתוח, אפילו במחיר האפשרי של חוסר יציבות בקוד ובכך שלבסיס המשתמשים יימאס אם באג רציני יימצא בלתי ניתן לפתרון. לינוס התנהג כאילו האמין במשהו כזה:

8. עם מספר גדול מספיק של בודקי בטא ומפתחים-מסייעים, כמעט כל בעיה ניתנת לסיווג מהיר והפתרון יהיה מובן מאליו למישהו.

או, בצורה פחות פורמלית, "עם מספיק עיניים, כל הבאגים שטחיים". אני קורא לו "חוק לינוס".

הקביעה המקורית שלי הייתה שכל בעיה "תהיה מובנת מאליה למישהו". לינוס התנגד, וטען שהאדם שמבין והאדם שפותר את הבעיה הם לא בהכרח או אפילו ברוב המקרים אותו אדם. "מישהו מוצא את הבעיה", הוא אומר, "ומישהו אחר מבין אותה. ואני אמשיך ואומר שלמצוא אותה הוא האתגר הגדול יותר". אבל הנקודה היא ששני הדברים נוטים לקרות מהר מאוד.

וזה, אני חושב, ההבדל הבסיסי בין סגנון בניית-קתדרלה וסגנון הבזאר. מנקודת המבט התכנותית של בניית-קתדרלה באגים ובעיות פיתוח הן תופעה בעייתית, מכשילה, "עמוקה". יש צורך בעבודה קשה וממוקדת לאורך חודשים רבים של צוות המתכנתים עד שהם משתכנעים שהם הצליחו להוציא את כל הבאגים. זאת הסיבה למחזורי הפרסום האיטיים, ולאכזבה הבלתי נמנעת כשהגרסאות החדשות, שלהן מחכים כל-כך הרבה, אינן מושלמות.

מנקודת המבט של הבזאר, מצד שני, אתה מניח שבאגים הם בבסיסם תופעות "שטחיות" – או, לפחות, הם הופכים להיות כאלה מהר מאוד ברגע שהם נחשפים לאלף מפתחים-מסייעים מתלהבים שבודקים היטב כל גרסה חדשה. בהתאם, אתה מפרסם גרסאות חדשות בקצב מהיר יותר כדי לקבל יותר תיקונים, ובתור תופעת לוואי יש לך פחות להפסיד אם אתה מפרסם גרסה הרוסה או בעייתית.

וזהו. זה הכל. אם "חוק לינוס" לא היה נכון, כל מערכת מורכבת כמו גרעין לינוקס, משופצרת על ידי כל כך הרבה אנשים כמו גרעין לינוקס, הייתה מתמוטטת בנקודה מסוימת תחת המשקל של בעיות התכנון שלא נצפו מראש ובאגים "עמוקים" שלא נתגלו. אם הוא נכון, לעומת זאת, הוא מספיק כדי להסביר את חוסר-הבאגים היחסי של לינוקס ואת הזמנים הארוכים שמערכת לינוקס יכולה להחזיק מעמד בלי להתרסק – חודשים ואפילו שנים.

או אולי זו לא הייתה צריכה להיות כזו הפתעה. סוציולוגים גילו כבר לפני שנים שהדעה הממוצעת של קבוצה גדולה של אנשים מומחים ברמה דומה (או בורים ברמה דומה) היא הרבה יותר אמינה מאשר דעה של אדם אחד שנבחר באקראי מתוך הקבוצה. הם קראו לזה "שיטת דלפי". כנראה שמה שלינוס הראה הוא שתוצא הזה עובד אפילו בדיבוג מערכת הפעלה – ששיטת דלפי יכולה "לאלף" מורכבות של פיתוח אפילו ברמת מורכבות כזו.

עוד תכונה מיוחדת של המצב של לינוקס שבאופן ברור עוזר לשיטת דלפי היא שהתורמים לפרוייקט בוחרים את עצמם. כבר בתחילת הדרך הביע אחד האנשים המעורבים את הדעה שתרומות אינן מתקבלות מקבוצה אקראית של משתמשים אלא מאלה המתעניינים מספיק כדי להשתמש בתוכנה, ללמוד איך היא עובדת, לנסות למצוא פתרונות לבעיות שהם מגלים, וממש ליצור תיקונים סבירים. כל מי שעובר את המסננים האלה, סביר מאוד שיש לו משהו שימושי לתרום.

אני אסיר תודה לידידי ג'ף דטקי שציין שאפשר שאפשר לנסח את חוק לינוס כ"דיבוג היא משימה הניתנת לביצוע בצורה מקבילית". ג'ף ציין שלמרות שדיבוג דורשת מהמדבגים לתקשר עם איזשהו מפתח-מתאם, היא אינה דורשת שהמדבגים יתקשרו בינם לבין עצמם. לכן היא אינה נופלת טרף לעלייה הריבועית במורכבות ובהוצאות הניהול שבגללה הוספת מפתחים לפרוייקט היא בדרך כלל בעייתית.

בפועל, אובדן היעילות הפוטנציאלי בגלל עבודה כפולה של מדבגים כמעט לעולם איננה מהווה בעיה בעולם הלינוקס. תוצאה אחת של "מדיניות פרסם מוקדם ובתכיפות" היא צמצום הכפילות על ידי פרסומם של תיקונים במהירות. [JH].

ברוקס אפילו ציין אבחנה אחת הקשורה לזו של ג'ף: "ההוצאות הסופיות של תחזוקה של תוכנה נפוצה היא לעיתים קרובות 40 אחוז או יותר מעלות הפיתוח. במפתיע, העלות הזאת תלויה באופן הדוק במספר המשתמשים. "יותר משתמשים מוצאים יותר באגים" (הדגשה שלי).

יותר משתמשים מוצאים יותר באגים כי הוספת משתמשים מוסיפה יותר דרכים שונות לבחון את יציבות התוכנה. התוצאה אפילו חזקה יותר כשהמשתמשים הם מפתחים-מסייעים. כל אחד מהם ניגש למשימת תיאור הבאג עם תפיסה ושיטות אנליטיות שונות במקצת, וזווית שונה על הבעיה. נראה ש"שיטת דלפי" עובדת בדיוק בגלל הווריאציות האלה. בסביבה הספציפית של דיבוג, הווריאציות גם עוזרות להפחית כפילות מאמץ.

כך שהוספת בודקי בטא אולי לא תפחית את המורכבות של באג "העמוק ביותר" הנוכחי מנקודת המבט של המפתח, אבל היא תגביר את הסיכויים שהשיטות האנליטיות של מישהו יתאימו בדיוק לבעיה כך שהבאג ייראה "שטחי" לאותו אדם.

לינוס גם מאזן את ההימורים שלו. במקרה שיש באגים רציניים הגרסאות של לינוקס ממוספרות בצורה כזו שמשתמשים פוטנציאליים יכולים לבחור אם להריץ את הגרסה האחרונה שהוכרזה כ"יציבה", או לבחור להריץ את הגרסה החדשנית ביותר ולהסתכן בבאגים כדי לקבל תכונות חדשות. רוב ההאקרים של לינוקס עדיין אינם מחקים באופן רשמי את הטקטיקה הזו, אבל אולי כדאי שיעשו כן; העובדה ששתי הבחירות קיימות גורמת לשתיהן להיראות יותר אטרקטיביות.

כמה כדורי עיניים מאלפים מורכבות?

דבר אחד הוא להבחין ברמת העל שסגנון הבזאר מאיץ במידה ניכרת את מהירות ניפוי השגיאות והתפתחות הקוד. דבר אחר הוא להבין בדיוק איך ומדוע הוא עושה זאת ברמה המיקרו התנהגותית היום-יומית של המפתח והבודק. בחלק זה (שנכתב שלוש שנים לאחר הפצת המסמך המקורי, תוך שימוש בתובנות שונות של מפתחים שקראו אותו ובחנו מחדש את התנהגותם) נבחן בקפידה את המנגנון הממשי. קוראים ללא רקע טכני יכולים לדלג בבטחה לחלק הבא.

אחד מהמפתחות להבנה היא ההכרה מדוע דיווח הבאג, הנשלח על ידי משתמשים שלא מודעים לקוד המקור, נוטה להיות לא מאד שימושי. משתמשים שלא מודעים לקוד המקור נוטים לדווח אך ורק על סימפטומים שטחיים; הם לוקחים את סביבתם כמובן מאליו, ולכן הם: (א) מחסירים נתוני-רקע הכרחיים (ב) לעיתים רחוקות מעבירים מרשם אמין לשחזור הבאג.

הבעיה היסודית כאן היא חוסר התאמה בין בוחן התוכנית והמפתח, כאשר הם מתבוננים על התוכנה; הבוחן, המסתכל מבחוץ פנימה, והמפתח, המביט מבפנים החוצה. בפיתוח קוד סגור שניהם תקועים בתפקידים אלה. הם נוטים לדבר על נושאים שמחוץ לתחום הבנתו של חברם, ועל כן שני הצדדים מתוסכלים עד מאד.

פיתוחו של הקוד-הפתוח מאפשר לבוחן ולמפתח להתגבר על מגבלות אלו וליצור בקלות ייצוג משותף המושרש בקוד-המקור הממשי ולתקשר ביעילות לגביו. מעשית, לדיווח באג המבוסס ישירות על קוד המקור של המפתח (ובכך מייצג מנטאלית את התוכנית) יש יתרון משמעותי על פני דיווח של סימפטומים חיצוניים בלבד.

מרבית הבאגים, רוב הזמן, נפתרים בקלות אם נתון תאור של תנאי השגיאה ברמת קוד-המקור, אפילו אם התאור מרמז בלבד. כאשר מישהו מבין בוחני התוכנה שלך יכול לומר: "ישנה בעיית קצה בשורה nnn" או אפילו רק "תחת תנאים Y, X ו-Z המשתנה הזה מתהפך" – אזי מבט חטוף על הקוד הבעייתי מספיק לעיתים קרובות על מנת לזהות את מצבה המדויק של התקלה ולייצר תיקון.

לכן מודעות לקוד המקור משני הצדדים מגבירה במידה רבה גם תקשורת טובה בין הצדדים וגם שיתוף פעולה אפקטיבי בין הדיווח של בוחן-הבטא והידע של מפתחי הליבה. מכאן, שזמנם של המפתחים נוטה להיות מנוצל היטב, אפילו עם משתפי פעולה רבים.

מאפיין אחר של שיטת הקוד הפתוח העוזר לשמר את זמנו של המפתח הוא מבנה התקשורת של פרויקטי קוד פתוח אופייניים. קודם לכן השתמשתי במונח "מפתח ליבה"; מונח זה משקף אבחנה בין ליבת הפרוייקט (בדרך-כלל די קטנה; בדרך כלל יימצא מפתח ליבה יחיד, וטיפוסי שיהיו אחד עד שלושה כאלה) לבין הילת הפרוייקט של בוחני-התוכנה ותורמים זמינים (שלעיתים קרובות נספרים במאות).

הבעיה היסודית שארגון פיתוח-התוכנה המסורתי בא לפתור היא חוק ברוק (Brook's Law): "הוספת יותר מתכנתים לפרוייקט שנמצא באיחור גורמת לו לאחר אף יותר". באופן כללי יותר, חוק ברוק מנבא שהמורכבות ועלויות התקשורת של פרוייקט עולים עם ריבוע מספר המפתחים, בעוד שהעבודה שנעשית צומחת רק באופן ליניארי.

חוק ברוק מושתת על הניסיון כי באגים נוטים להתקבץ סביב ממשקי הקוד הנכתב על ידי אנשים שונים, וכן כי התקורה (Overhead) על התקשורת/שיתוף הפעולה בפרויקט נוטה לעלות עם העלייה בממשקים בין האנשים. מכאן שבעיות קשורות במספר מעברי התקשורת שבין המפתחים, השקול לריבוע מספר המפתחים (ליתר דיוק, בהתאם לנוסחא N*(N-1)/2 כאשר N הוא מספר המפתחים).

הניתוח של חוק ברוק (והחשש הנוצר כתוצאה ממנו לגבי מספרים גדולים של קבוצות פיתוח) מבוסס על הנחה סמויה: מבנה התקשורת של הפרויקט הוא בהכרח גרף שלם, בו כולם מדברים עם כולם. אולם בפרויקטים של קוד-פתוח, מפתחי ההילה עובדים על תת-משימות נפרדות אך מקבילות ופועלים יחד מעט מאד; שינויי קוד ודו"חות באגים זורמים לקבוצת הליבה, ובעצם, רק בתוך קבוצת הליבה הקטנה הזו, אנו משלמים את מלוא התקורה הברוקית.

עדיין קיימות סיבות נוספות לכך שדיווחי באגים ברמת קוד המקור נוטים להיות מאד יעילים. שגיאה בודדת יכולה להתבטא במספר רב של סימפטומים שונים, כאשר לכל אחד ביטוי שונה כתלות בדפוסי השימוש והסביבה של המשתמש. שגיאות אלה נוטות להיות בדיוק סוג הבאג הסבוך והעדין (כגון שגיאות ניהול דינאמי של זיכרון או חלון פסיקה לא דטרמיניסטי) שהם הקשים ביותר לשחזור, ולאיתור על ידי ניתוח סטאטי, והתורמים הטובים ביותר ליצירת בעיות תוכנה ארוכות טווח.

בוחן השולח אפיון ברמת קוד-מקור של באג בעל מספר סימפטומים (לדוגמא "נראה לי שיש חלון באיתות ליד שורה 1250" או "איפה מאפסים את החוצץ הזה") יוכל לתת למפתח, היושב קרוב מדי לקוד מכדי להבחין בו, רמז חשוב למספר סימפטומים נפרדים. במקרים כאלו, שיוך כל התנהגות חיצונית לבאג מסוים יכולה להיות קשה עד בלתי אפשרית – אולם ברגע שהפרסומים מופיעים בתדירות גבוהה, בעצם גם אין צורך לדעת. משתפי פעולה נוספות יוכלו לגלות במהירות האם הבאג שלהם תוקן או לא. במקרים רבים, דיווחי באגים ברמת קוד-המקור ימנעו משגיאות מסוימות לחזור שנית בלי שהן שויכו לתיקון מסוים.

שגיאות מורכבות, בעלות מספר סימפטומים, ניתן לאתר במספר דרכים, החל מהסימפטומים השטחיים ועד הבאג עצמו. מפתח או בוחן נתון ייבחר בדרך האיתור התואמת לתכונות של סביבת העבודה שלו, וזו תוכל להשתנות באופן לא דטרמיניסטי ועקבי במהלך הזמן. למעשה, במהלך החיפוש אחר האטיולוגיה של סימפטום, כל מפתח ובוחן דוגם מערכת אקראית למחצה של מצבים במרחב התוכנה. ככל שהבאג מורכב ועדין, הסיכוי שמיומנות תוכל להבטיח את הרלוונטיות של דגימה זו הולך ופוחת.

עבור באגים פשוטים הניתנים לשכפול הדגש יהיה על ה"למחצה" ולא על ה"אקראי"; למיומנות מציאת התקלות והאינטימיות עם הקוד והארכיטקטורה שלו חשיבות רבה במקרה זה. אולם עבור באגים מורכבים, הדגש יושם על "אקראי". בנסיבות הללו אנשים רבים המריצים את הקוד צעד אחר צעד יוכלו לתרום הרבה יותר מאשר אנשים ספורים המבצעים זאת בהמשכים – אפילו אם מדובר באנשים ספורים בעלי ממוצע של רמת מיומנות גבוה הרבה יותר.

אפקט זה יוגבר מאד כאשר הקושי במעקב אחר דרכי האיתור מסימפטומים שטחיים שונים בחזרה לבאג המקורי משתנה באופן משמעותי, בצורה שלא ניתנת לחיזוי על ידי בחינת הסימפטומים. מפתח יחיד הדוגם את הדרכים הללו בהמשכים יוכל לבחור באותה מידה בדרך איתור מורכבת או קלה בניסיון הראשון שלו. מצד שני, נניח שהרבה אנשים מנסים במקביל דרכי איתור שונות כאשר הם מפיצים פרסומים בתדירות גבוהה. קרוב לוודאי שאז אחד מהם יאתר את הדרך הקלה ביותר באופן מיידי, וישמיד את הבאג תוך זמן קצר הרבה יותר. האיש המתחזק את הפרויקט יאתר זאת, יבצע הוצאה של גרסא חדשה, וכל האנשים הנוספים שהריצו מעקב על אותו הבאג יוכלו להפסיק זאת עוד לפני שהשקיעו זמן רב בבבצוע מעקב קשה יותר בקוד.

מתי ורד אינו ורד?

לאחר שחקרתי את התנהגותו של לינוס וגיבשתי תיאוריה למה היא מוצלחת, החלטתי החלטה מודעת לבדוק את התיאוריה הזו על הפרוייקט החדש שלי (מתוך מודעות שהוא הרבה פחות מורכב ושאפתני).

אבל הדבר הראשון שעשיתי היה לארגן ולפשט מאוד את popclient. היישום של קארל האריס היה הגיוני מאוד אבל הייתה בו הרבה מורכבות בלתי נחוצה שנפוצה אצל הרבה מתכנתי C. הוא התייחס לקוד כמרכזי ולמבני הנתונים כתומכים בקוד. כתוצאה מכך, הקוד היה יפהפה אבל מבני הנתונים נראו כאילו תוכננו במחשבה שלאחר מעשה והיו די מכוערים (לפחות על פי הסטנדרטים הגבוהים של האקר LISP ותיק כמוני).

הייתה לי עוד כוונה בשכתוב חוץ משיפור הקוד ומבני הנתונים. רציתי שהתוכנה תתפתח למשהו שהבנתי לחלוטין. אין כל כיף בלהיות אחראי על תיקון באגים בתוכנה שאתה לא מבין.

לכן, במשך החודש הראשון או משהו כזה פשוט עקבתי אחרי ההשלכות של התכנון הבסיסי של קארל. השינוי הרציני הראשון היחיד שעשיתי היה להוסיף תמיכה ב-IMAP. עשיתי זאת על-ידי ארגון מחדש של החלקים האחראים על הפרוטוקולים לדרייבר כללי ושלוש טבלאות של שיטות (ל-POP2, POP3, ו-IMAP). השינוי הזה והקודמים מדגימים עיקרון כללי שטוב שמתכנתים יזכרו, בייחוד בשפות כמו C שאינן תומכות באופן טבעי בטיפוסים דינמיים:

9. מבני נתונים חכמים וקוד טיפש עובדים הרבה יותר טוב מאשר הדרך ההפוכה.

ברוקס, פרק 9: "הראה לי את [הקוד] והסתר את [מבני הנתונים] שלך, ואמשיך להיות מבולבל. הראה לי את [מבני הנתונים], ובדרך כלל לא אצטרך את [הקוד]; הוא יהיה מובן מאליו."

בעצם, הוא אמר "תרשים זרימה" ו"טבלה". אבל אחרי שלושים שנה של שינויים בטרמינולוגיה ובתרבות זה כמעט אותו הדבר.

בנקודה הזו (תחילת ספטמבר 1996, בערך שישה שבועות מאפס) התחלתי לחשוב ששינוי השם אולי יהיה במקום – אחרי הכל, זה כבר לא היה רק לקוח POP. אבל היססתי, כי לא היה עדיין שום דבר חדש באופן מקורי בתכנון. הגרסה שלי של popclient עדיין לא פיתחה זהות משלה.

אבל העובדה הזו השתנתה, ובצורה קיצונית, כש-fetchmail למד איך לשלוח דואר שהורד לפורט SMTP. אני אגיע לזה עוד מעט. אבל קודם כל: אמרתי קודם שהחלטתי להשתמש בפרוייקט הזה כדי לבדוק את התיאוריה שלי בקשר למה שלינוס טורוולדס עשה כמו שצריך. איך (אתה יכול לשאול) עשיתי זאת? בדרכים האלה:

• פרסמתי מוקדם ובתכיפות (כמעט לעולם לא בתכיפות נמוכה יותר מפעם ב- 10 ימים; בתקופות של פיתוח מואץ, פעם ביום).
• הגדלתי את רשימת התפוצה של הבטא שלי על ידי כך שהוספתי אליה כל מי שהתקשר אלי בקשר ל-fetchmail.
• שלחתי הודעות פטפטניות לרשימת התפוצה של הבטא כל פעם שפרסמתי, ועודדתי אנשים להשתתף.
• הקשבתי לבודקי הבטא שלי, שאלתי אותם כקבוצה בקשר להחלטות של תכנון, ועודדתי אותם כל פעם ששלחו לי טלאים ותגובות.

התשלום עבור הצעדים הפשוטים האלה היה מיידי. כבר מתחילת הפרוייקט, קיבלתי דיווחי באגים באיכות שרוב המפתחים היו מתים לקבל, לעתים קרובות עם תיקונים טובים מצורפים. קיבלתי ביקורת בונה, קיבלתי דואר ממעריצים, קיבלתי הצעות אינטליגנטיות לתכונות חדשות. מה שהוביל ל:

10. אם תתייחס לבודקי הבטא שלך כאילו הם הנכס היקר ביותר שלך, הם יגיבו בכך שיהיו הנכס היקר ביותר שלך.

מדד מעניין להצלחת fetchmail היה הגודל עצמו של רשימת התפוצה של גרסת הבטא של הפרוייקט, fetchmail-friends. בזמן הכתיבה גודלה היה 249 חברים ונוספים אליה עוד שניים או שלושה כל שבוע.

בעצם, עכשיו כשאני עובר על המסמך הזה בסוף מאי 1997, רשימת התפוצה מתחילה לאבד חברים מהשיא שלה, קרוב ל- 300 חברים, מסיבה מעניינת. מספר אנשים ביקשו ממני להוריד אותם מהרשימה בגלל ש-fetchmail עובד כל-כך טוב בשבילם כך שהם לא צריכים לראות את התנועה ברשימה! יכול להיות שזה חלק נורמלי ממחזור החיים של כל פרוייקט בוגר בסגנון הבזאר.

Popclient הופך ל- Fechmail

נקודת התפנית האמיתית בפרוייקט הייתה כשהארי הוצ'הייסר שלח לי את קוד הטיוטה שלו לשליחת דואר לפורט ה-SMTP של המחשב הלקוח. הבנתי כמעט מייד שיישום אמין של התכונה הזו תהפוך את כל המצבים האחרים של חלוקת הדואר למיושנים.

במשך שבועות רבים שיפרתי את fetchmail באמצעות תוספות בעיקר והרגשתי שתכנון הממשק היה במצב עובד אבל מבולגן – לא אלגנטי, עם יותר מדי אופציות מוזרות מסביב. האופציות לשים דואר מורד ישר בקובץ תיבת הדואר או לפלט הסטנדרטי הטרידו אותי במיוחד, ולא ידעתי למה.

מה שראיתי כשחשבתי על שליחה באמצעות SMTP היה ש-popclient ניסה לעשות יותר מדי דברים. הוא ניסה להיות גם MTA (Mail Transfer Agent)וגם MDA (Mail Delivery Agent ). בעזרת שליחה ל-SMTP, הוא יוכל להפסיק להיות MDA ולהתחיל להיות אך ורק MTA, כשהוא מעביר את הדואר לתוכנות אחרות לחלוקה מקומית ממש כמו sendmail.

למה להתעסק עם כל המורכבות של קינפוג סוכן לחלוקת דואר או לדאוג לנעילה-והוספה של תיבת דואר כאשר פורט 25 כמעט תמיד קיים בכל פלטפורמה שיש בה תמיכה ב-TCP/IP מלכתחילה? בייחוד כשזה אומר שדואר מורד תמיד ייראה כמו דואר SMTP רגיל שניזום על-ידי השולח, וזה מה שאנחנו רוצים בכל מקרה.

יש כאן כמה שיעורים. דבר ראשון, השליחה ל-SMTP הזו הייתה התשלום היחיד הטוב ביותר שקיבלתי מהניסיון המודע לחקות את השיטות של לינוס. משתמש נתן לי את הרעיון המדהים הזה – וכל מה שהייתי צריך לעשות הוא להבין את ההשלכות.

11. הדבר השני הטוב ביותר אחרי להיות אדם בעל רעיונות טובים הוא לזהות רעיונות טובים מהמשתמשים שלך. לפעמים זה הוא אפילו טוב יותר.

מעניין, אבל תגלה מהר מאוד שאם אתה מודה בכנות ובצניעות בכמה שאתה חייב לאנשים אחרים, העולם יתייחס אליך כאילו שאתה הוא שעשית כל חלק בהמצאה בעצמך ואתה רק צנוע בקשר לגאוניות שלך. קל לראות כמה טוב זה עבד בשביל לינוס!

(כשנשאתי את הנאום הזה במפגש Perl באוגוסט 1997, לארי וול ישב בשורה הראשונה. כשהגעתי לשורה האחרונה הוא צעק כאילו קיבל הארה הדתית: "ספר, ספר, אחי!". כל הקהל צחק, כי הם ידעו שזה עבד גם עבור ממציא Perl.)

לאחר כמה שבועות שבהם הרצתי את הפרוייקט ברוח כזו, התחלתי לקבל מחמאות דומות לא רק מהמשתמשים שלי אלא גם מאנשים אחרים שהשמועה הגיעה אליהם. שמרתי בצד קצת מהדואר הזה; אני אסתכל בו שוב מתישהו אם אי פעם אתחיל לתהות אם החיים שלי היו שווים משהו :-)

אבל יש עוד שני רעיונות בסיסיים, לא פוליטיים וכלליים לכל סוג של תכנון:

12. לפעמים, הפתרונות המדהימים והחדשניים ביותר באים מהבנה שעצם התפיסה שלך של הבעיה הייתה מוטעית.

ניסיתי לפתור את הבעיה הלא נכונה על ידי כך שהמשכתי לפתח את popclient כ-MTA/MDA משולב עם כל מיני מצבים מוזרים לחלוקת דואר מקומית. הייתי צריך לחשוב מחדש על fetchmail כ-MTA טהור, חלק ממסלול הדואר הטבעי של SMTP.

כשאתה נתקע בפיתוח – כשאתה מוצא את עצמך במצב שקשה לך לחשוב מעבר לטלאי הבא – לפעמים זה הזמן לשאול את עצמך לא אם יש לך את התשובה הנכונה, אלא אם אתה שואל את השאלה הנכונה. לפעמים צריך לשים את הבעיה במסגרת אחרת.

ובכן, שמתי את הבעיה במסגרת אחרת. בבירור, הדבר הנכון לעשות היה (1) לשפצר תמיכה במשלוח ל-SMTP לתוך הדרייבר הכללי, (2) לגרום ל-SMTP להיות ברירת המחדל, ו-(3) לזרוק בהדרגה את כל שאר מצבי החלוקה, ובייחוד את החלוקה לקובץ והחלוקה לפלט סטנדרטי.

היססתי בקשר לצעד 3 במשך כמה זמן, משום שפחדתי לאכזב כמה משתמשים וותיקים ב-popclient שהיו תלויים בדרכי חלוקה אלטרנטיביות. בתיאוריה, הם יכלו תמיד לעבור לקבצי .forward"" או לחלופות שאינן sendmail כדי לקבל את אותן התוצאות. בפועל, המעבר יכול להיות בעייתי.

כשעשיתי זאת, הרווחים היו עצומים. החלקים המאולתרים ביותר של הדרייבר נעלמו. קינפוג נעשה פשוט יותר בצורה קיצונית – כבר לא היה צורך להתעסק עם ה-MDA של המערכת או תיבת הדואר של המשתמש, ולא היה יותר צורך לדאוג אם מערכת ההפעלה תומכת בנעילת קבצים.

בנוסף, הדרך היחידה לאבד דואר נעלמה. אם ציינת חלוקה לקובץ והדיסק היה מלא, הדואר אבד. זה לא יכול לקרות עם שליחה ל-SMTP כי התוכנה המקבלת את ה-SMTP לא תחזיר OK אלא אם כן ההודעה חולקה או לפחות נמצאת במאגר לחלוקה מאוחרת יותר.

כמו-כן, הביצועים השתפרו (למרות שלא כל-כך שתבחין בכך בהרצה יחידה). עוד שיפור לא זניח שנגרם על ידי השינוי היה שהמדריך למשתמש הפך להיות פשוט הרבה יותר.

מאוחר יותר, הייתי צריך להחזיר חלוקה דרך MDA מקומי של המשתמש כדי לאפשר טיפול במצבים מוזרים ש-SLIP דינאמי היה מעורב בהם. אבל מצאתי דרך פשוטה הרבה יותר לעשות זאת.

מוסר ההשכל? אל תהסס לזרוק תכונות מיושנות כשאתה יכול לעשות זאת בלי אובדן אפקטיביות. אנטואן דה סיינט אקסופרי (שהיה טייס ומעצב מטוסים בזמן שהוא לא היה עסוק בלהיות המחבר של ספר ילדים קלאסי) אמר:

13. שלמות (בתכנון) מושגת לא כשכבר אין יותר מה להוסיף, אלא כשכבר אין יותר מה לקחת

אם הקוד שלך נעשה בו זמנית טוב יותר ופשוט יותר, אתה יודע שזו הדרך. ובתהליך הזה התכנון של fetchmail קיבל זהות משלו, שונה מזו של האב הקדמון popclient.

זה היה הזמן לשינוי שם. התכנון החדש נראה הרבה יותר כמו מקביל ל-sendmail מאשר מה ש-popclient הישן היה; שניהם היו MTA, אבל במקום בו sendmail דוחף ואז מחלק, popclient החדש מושך ואז מחלק. וכך, חודשיים מהתחלת הפרוייקט, שיניתי את השם ל-fetchmail.

יש עוד שיעור כללי בסיפור הזה על איך SMTP הגיע ל-fetchmail. לא רק דיבוג ניתן לביצוע בצורה מקבילית; גם פיתוח ואפילו מחקר על אפשרויות תכנון (במידה מפתיעה) הוא כזה. כשהפיתוח שלך עובד בתדירות גבוהה, פיתוח ושיפורים נעשים מקרים מיוחדים של דיבוג – תיקון "באגים של השמטה" ביכולות המקוריות של הרעיון או התוכנה.

אפילו ברמה גבוהה יותר של תכנון, החשיבה של הרבה מפתחים-מסייעים החוקרים את אפשרויות התכנון הקרובות למוצר שלך יכולה להיות שימושית מאוד. חשוב איך שלולית מים מוצאת את המרזב, או, טוב יותר, איך נמלים מוצאות אוכל – חקר באמצעות פיזור, ולאחריו ניצול של הרעיון באמצעות תקשורת. זה עובד טוב מאוד; כמו אצל הארי הוצ'הייסר ואני, יכול להיות שאחד המפתחים-המסייעים שלך יימצא פתרון פשוט ומצוין שהחשיבה שלך הייתה מוגבלת לתחומים מסוימים מכדי שתוכל להבחין בו.

Fechmail מתבגר

בנקודה זו הייתי עם תכנון מצוין וחדשני, קוד שידעתי שעבד היטב משום שהשתמשתי בו כל יום, ורשימת בטא מתארכת. בהדרגה הבנתי שכבר לא הייתי מעורב בשיפצור אישי טריוויאלי שיכול להיות שימושי גם עבור מספר אנשים נוספים. הייתה לי תוכנה שכל האקר עם יוניקס וחיבור דואר SLIP/PPP באמת צריך.

עם יכולת השליחה דרך SMTP ,fetchmail התקדם הרבה מעבר לתחרות ונעשתה בפוטנציה "הורג קטגוריה", אחת מאותן תוכנות קלאסיות שממלאות את הגומחה שלהן ביכולת כל-כך מושלמת שהחלופות האחרות לא רק מושלכות אלא נשכחות כמעט לחלוטין.

אני חושב שאתה לא באמת יכול להתכוון או לתכנן תוצאה כזאת. אתה חייב להימשך לתוכה על ידי רעיונות תכנון כל-כך חזקים שלאחר מכן התוצאות פשוט נראות בלתי-נמנעות, טבעיות, אפילו מוכוונות-מראש. הדרך היחידה להגיע לרעיונות כאלה היא לקבל הרבה רעיונות – או להשתמש בשיפוט הנדסי כדי לקבל את הרעיונות הטובים של אנשים אחרים מעבר למה שהמתכנן המקורי חשב שהוא יוכל להגיע אליו.

לאנדרו טננבאום היה הרעיון מקורי לבנות יוניקס פשוט לתואמי IBM PC, לשימוש כעזר ללימוד. לינוס טורוולדס דחף את הרעיון של Minix מעבר למה שאנדרו כנראה חשב שהוא יוכל להגיע – והוא גדל להיות משהו נפלא. בדרך דומה (למרות שבקנה מידה הרבה יותר קטן) לקחתי רעיונות מקארל האריס והארי הוצ'הייסר ודחפתי אותם רחוק. אף אחד מאתנו לא היה "גאון" בדרך הרומנטית שאנשים חושבים על גאונים. אבל רוב המדע, ההנדסה ופיתוח התוכנה אינו נעשה על-ידי גאון מקורי, למרות המיתולוגיה ההאקרית.

התוצאות היו די מדהימות, בכל זאת – למעשה, בדיוק ההצלחה שכל האקר מקווה לה! והמשמעות הייתה שיכולתי לקבוע את הסטנדרטים שלי אפילו גבוה יותר. כדי לגרום ל-fetchmail להיות כפי שידעתי עכשיו שאפשרי, היה עלי לכתוב לא רק לצרכים שלי, אלא גם לכלול תמיכה ויכולות החיוניים לאחרים מחוץ לסביבה שלי. ולעשות זאת תוך כדי שמירה על התוכנה פשוטה ואמינה.

היכולת הראשונה, ובאופן בולט החשובה ביותר שכתבתי לאחר שהבנתי זאת הייתה תמיכה בכתובות של מספר משתמשים – היכולת להוריד דואר מתיבות דואר שאספו את כל הדואר עבור קבוצה של משתמשים, ואז להעביר כל דבר דואר למכותב הספציפי שלו.

החלטתי להוסיף את התמיכה במספר משתמשים קודם כל משום שכמה מהמשתמשים התעקשו עליה, אבל חלקית גם בגלל שחשבתי שזה יעזור לי למצוא באגים בקוד התומך במשתמש אחד בלבד על-ידי כך שיכריח אותי להתעסק בכתובות בכלליות מלאה. וכך קרה. פירוש ה- RFC 822 לקח לי תקופת זמן ראויה לציון, לא בגלל פיסה מסוימת בו שהייתה קשה אלא בגלל שהוא עירב ערמה של פרטים קטנוניים ותלויים אחד בשני.

אבל הבחירה בתמיכה בכתובות של מספר משתמשים הוכיחה עצמה גם כהחלטת תכנון מצוינת. וכך ידעתי:

14. כל כלי צריך להיות שימושי בדרך הצפויה, אבל כלי טוב באמת מתאים גם לשימושים שמעולם לא צפית

השימוש הבלתי צפוי ביכולת התמיכה בכתובות של מספר משתמשים היה להריץ רשימת תפוצה כאשר גם הרשימה וגם פתרון השם מבוצע על צד הלקוחשל חיבור ה-SLIP/PPP. זה אומר שמי שיש לו מערכת אישית ומחבר אותה דרך חשבון ב-ISP יכול לנהל רשימת דיוור בלי להמשיך ולהשתמש בקבצי רשימת השמות של ה-ISP.

עוד שינוי חשוב שבודקי הבטא שלי דרשו היה תמיכה בפעולות 8 bit MIME. זה היה די קל לעשות כי הייתי זהיר מספיק לשמור על הקוד נקי מבחינת ה-8 bit (כלומר, לא ללחוץ את הביט השמיני, שאינו בשימוש בקוד ASCII, לשימוש כדי שיעביר מידע בתוך התוכנית). לא בגלל שצפיתי את הדרישה ליכולת הזו, אלא מתוך נאמנות לכלל אחר:

15. כשאתה כותב גשר מכל סוג שהוא, עדיף לטרוח ולשנות את זרימת הנתונים כמה שפחות – ו*לעולם* לא לזרוק אינפורמציה אלא אם כן הצד המקבל מכריח אותך!

אם לא הייתי מציית לחוק זה, תמיכה ב- 8 bit MIME הייתה קשה ומלאת באגים. אבל כפי שהמצב היה כל שהייתי צריך לעשות הוא לקרוא את RFC 1652ולהוסיף חתיכות קוד טריוויאליות כדי ליצור את הכותרות.

כמה משתמשים אירופאים נדנדו לי כדי שאוסיף אופציה להגביל את מספר המסרים המורדים בכל הרצה (כך שהם יוכלו לשלוט על ההוצאות כספיות לרשתות הטלפון היקרות שלהם). התנגדתי לכך במשך זמן רב, ואני עדיין לא לגמרי שלם עם זה. אבל כשאתה כותב בשביל העולם, אתה חייב להקשיב ללקוחותיך – וזה לא משתנה רק בגלל שהם לא משלמים לך בכסף.

כמה לקחים נוספים מ- Fechmail

לפני שנחזור לנושאי הנדסת-תוכנה כלליים, יש עוד כמה שיעורים ספציפיים מהניסיון של fetchmail שכדאי לחשוב עליהם.

מבנה קובץ ה-rc כולל מילות "רעש" אופציונאליות שהמפרש מתעלם מהן לחלוטין. המבנה דמוי-האנגלית שהן הרשו היה קריא יותר בצורה משמעותית מאשר זוגות מילת-מפתח-ערך המסורתיים שמקבלים אם מוחקים את מילות הרעש.

אלה התחילו כניסוי של שעת לילה מאוחרת כשהבחנתי עד כמה ההכרזות בקובץ ה-rc החלו לדמות למיני-שפה (זוהי גם הסיבה שבגללה שיניתי את מילת-המפתח המקורית של popclient "server" ל-"poll").

נראה לי שניסיון לשנות את השפה כך שתדמה יותר לאנגלית יוכל לעשות אותה קלה יותר לשימוש. עלי לציין שלמרות שאני חסיד משוכנע של אסכולת התכנון "עשה זאת בעזרת שפה", אינני בדרך כלל מעריץ גדול של מבנים "דמויי-אנגלית".

מתכנתים מסורתיים נטו להעדיף מבנים מאוד מדויקים, חסכוניים וחסרי כפילות בכלל. זוהי ירושה תרבותית מהתקופה בה משאבי מחשב היו יקרים, וכך שלבי הפירוש היו צריכים להיות זולים ופשוטים ככל האפשר. אנגלית, שבה כ- 50% כפילות, נראתה כמודל בלתי-מתאים ביותר.

זוהי אינה הסיבה שלי להימנעות ממבנים דמויי אנגלית; אני מזכיר אותה כאן כדי לסתור אותה. עם מחזורי פעולות מחשב וליבה זולים, שפה ספרטנית אינה צריכה להיות מטרה בפני עצמה. בימינו זה הרבה יותר חשוב לשפה להיות נוחה לבני-אדם מאשר חסכונית למחשב.

למרות זאת, נשארו כמה סיבות להיות זהירים. סיבה אחת היא עלות הסיבוך של שלב הפירוש – אינך רוצה להעלות את המורכבות עד לנקודה שהיא מקור לבאגים ולבלבול של משתמשים בפני עצמה. עוד סיבה היא שניסיון ליצור שפה עם מבנה דמוי-אנגלית לעתים קרובות דורש שה"אנגלית" שהוא משתמש בה תעוות בצורה רצינית, עד כדי כך שהדמיון השטחי לשפה טבעית מבלבל ממש כמו שהמבנה המסורתי היה יכול להיות. (אפשר לראות זאת בהרבה מהשפות הקרויות "דור רביעי" ושפות מסחריות המיועדות לשאילתות לבסיסי נתונים).

נראה שמבנה שפת השליטה של fetchmail הצליח להימנע מהבעיות האלה משום שתחומה של השפה מוגבל מאוד. הוא אינו קרוב כלל לשפה למטרה כללית; הדברים שהשפה אומרת פשוט אינם כה מסובכים, כך שיש מעט מאוד פוטנציאל לבלבול כאשר עוברים מנטאלית מתת-קבוצה זעירה של אנגלית לשפת השליטה עצמה. אני חושב שיש כאן שיעור רחב יותר:

16. כאשר השפה שלך אינה קרובה אפילו לשלימות-טורינג, Syntactic Sugar יכול להיות מועיל.

עוד שיעור הוא אבטחה על-ידי הסתרה. כמה ממשתמשי fetchmail ביקשו ממני לשנות את התוכנה כך שתשמור סיסמאות מוצפנות בתוך קובץ ה-rc בכדי שמרחרחים לא יוכלו לראות אותם במקרה.

לא עשיתי זאת, משום שזה לא באמת מוסיף הגנה. כל אחד שהשיג הרשאה לקרוא את קובץ ה-rc שלך יוכל להריץ את fetchmail כמוך בכל מקרה – ואם הסיסמה היא מה שהוא מחפש, הם יוכלו למצוא את השיטה לפענח את ההצפנה בקוד של fetchmail עצמו.

כל מה שהצפנת סיסמאות ב-.fetchmailrc היה עושה הוא לתת הרגשת ביטחון שגויה לאנשים שלא חושבים יותר מדי. החוק הכללי הוא:

17. מערכת אבטחה לעולם אינה בטוחה יותר מהסוד שלה. היזהר מסודות-למחצה.

תנאים מוקדמים הכרחיים לסגנון הבזאר

האנשים הראשונים שקראו מסמך זה והקהלים שניסיתי אותו עליהם העלו באופן עקבי שאלות לגבי התנאים המוקדמים להצלחת פיתוח בסגנון הבזאר, וכללו גם את יכולותיו של מנהיג הפרוייקט עצמו וגם את מצבו של הקוד בזמן שהוא נעשה ציבורי והניסיון לבנות קהילה של מפתחים-מסייעים מתבצע.

זה ברור למדי שאי-אפשר להתחיל לתכנת מההתחלה בסגנון הבזאר [IN]. . אפשר לבדוק, לדבג ולשפר בסגנון הבזאר אבל זה יהיה קשה מאוד להתחילפרוייקט במצב בזאר. לינוס לא ניסה זאת. גם אני לא. קהילת המפתחים הראשונית צריכה משהו שאפשר להריץ ולבדוק כדי לשחק אתו.

כשמתחילים לבנות קהילה, מה שצריך לעשות הוא להציג הבטחה סבירה. התוכנה לא צריכה לעבוד בצורה יוצאת דופן. היא יכולה להיות בנויה בצורה גסה, מלאת באגים, לא שלמה ובעלת תיעוד חסר. אבל אסור לה להיכשל ב-(א) לרוץ, ו-(ב) לשכנע אנשים שהיא יכולה להתפתח למשהו באמת נחמד בעתיד הנראה לעין.

אבל לינוס לקח את התכנון הבסיסי מיוניקס. אני לקחתי את שלי מהאב הקדמון popclient (למרות שהוא השתנה הרבה מאוד. הרבה יותר, באופן יחסי, ממה שלינוקס השתנה). וכך, האם למנהיג / מתאם של פרוייקט בסגנון בזאר צריך להיות כשרון תכנון יוצא דופן, או האם הוא יכול להסתדר על-ידי שימוש בכשרון התכנון של אחרים?

אני חושב שזה לא קריטי שהמתאם ידע לעצב באופן מבריק בצורה יוצאת דופן, אבל זה צורך חיוני לחלוטין שהמתאם ידע לזהות רעיונות תכנון נכונים של אחרים.

שני הפרוייקטים, לינוקס ו-fetchmail, הם הוכחות לכך. לינוס לא היה (כפי שהזכרתי קודם) מעצב מקורי באופן יוצא דופן, אבל היה לו כשרון חזק לזהות תכנון טוב ולשלב אותו בגרעין הלינוקס. וכבר תיארתי איך הרעיון התכנוני החזק ביותר של fetchmail (שליחה ל-SMTP) הגיע ממישהו אחר.

קוראים מוקדמים של המסמך הזה החמיאו לי בכך שהציעו שאולי יש לי נטייה להעריך פחות מדי מקוריות בתכנון של פרוייקטים בסגנון הבזאר בגלל שיש לי הרבה רעיונות מקוריים כאלה בעצמי. יכול להיות שיש בכך אמת; תכנון (בניגוד לתכנות או דיבוג) הוא בהחלט הכשרון החזק שלי.

אבל הבעיה עם תחכום ומקוריות בתכנון תוכנה היא שזה הופך להרגל – אתה מתחיל באופן רפלקסיבי לעשות דברים בצורה חמודה ומסובכת בזמן שעדיף לשמור עליהם פשוטים ויציבים. היו לי פרוייקטים שהתמוטטו בגלל הטעות הזאת, אבל הצלחתי להימנע מכך עם fetchmail.

וכך, אני מאמין שפרוייקט fetchmail הצליח באופן חלקי משום שריסנתי את נטייתי להיות מתוחכם; זה עונה (לפחות) לטענה האפשרית שמקוריות בתכנון היא חיונית להצלחת פרוייקטים בסגנון הבזאר. וקחו את לינוקס לדוגמה. נניח שלינוס טורוולדס היה מנסה כמה חידושים בסיסיים בתכנון מערכות הפעלה תוך כדי פיתוח; האם זה נראה סביר שהגרעין שנוצר היה יציב ומוצלח כפי שהוא היום?

רמה בסיסית מסוימת של יכולת תכנון ותכנות נדרשת, כמובן, אבל אני מצפה שכמעט כל מי שחושב ברצינות על התחלת פרוייקט בזאר כבר יהיה מעל הרמה המינימאלית. השוק הפנימי של פרסום חיובי בקהילת הקוד הפתוח מפעיל לחץ מסוים על אנשים לא להתחיל פרוייקטים שהם אינם מסוגלים להמשיך בהם. עד כה נראה שזה עבד טוב מאוד.

יש עוד סוג של כשרון שבדרך כלל לא משייכים אותו עם פיתוח תוכנה, אבל אני חושב שהוא חיוני ממש כמו יכולת תכנון טובה לפרוייקטים של בזאר – והוא יכול להיות חיוני עוד יותר. מתאם פרוייקט בזאר חייב להיות בעל יכולת תקשורת בין-אישית טובה.

זה צריך להיות מובן מאליו. כדי ליצור קהילת מפתחים, מתאם הפרוייקט צריך להיות מסוגל למשוך אנשים, לעניין אותם במה שהוא עושה, ולדאוג שירצו להשקיע זמן רב ככל היותר. פעילות טכנית חדשה ומעניינת היא גורם חשוב בכך, אבל היא אינה הכל. האישיות שהוא מקרין גם היא חשובה מאוד.

זה איננו צירוף מקרים שלינוס הוא בחור נחמד שגורם לאנשים לאהוב אותו ולרצות לעזור לו. זה איננו צירוף מקרים שאני אדם מוחצן ואנרגטי שנהנה לעבוד עם ציבור גדול ושיש לו כמה מהכשרונות והאינסטינקטים של קומיקאי. כדי שמודל הבזאר יעבוד, יש צורך בלפחות מעט כשרון בלהקסים אנשים.

הסביבה החברתית של תוכנת קוד-פתוח

זה נכון: השיפצורים הטובים ביותר התחילו כפתרונות אישיים לבעיות היום-יום של הכותב, והתפשטו כי הבעיה הייתה בסופו של דבר טיפוסית לקבוצה גדולה של משתמשים. זה לוקח אותנו בחזרה לחוק 1, שאפשר גם לנסח בצורה יותר שימושית:

18. כדי לפתור בעיה מעניינת, מצא קודם כל, בעיה שמעניינת אותך

כך זה היה עם קארל האריס והאב הקדמון popclient, וכך היה גם איתי ועם fetchmail. אבל זה היה מובן במשך זמן רב. הנקודה המעניינת, הנקודה שההיסטוריות של לינוקס ו-fetchmail ממש דורשות שנתרכז בה, היא השלב הבא – ההתפתחות של תוכנה בנוכחות קהילה גדולה ופעילה של משתמשים ומפתחים-מסייעים.

בספרו "The Mythical Man Month", טוען פרד ברוקס שזמנו של המתכנת אינו ניתן להוספה; הוספת מתכנתים לפרוייקט שאינו עומד בלוח הזמנים רק גורמת לו לאחר עוד יותר. הוא טוען שהמורכבות ועלויות התקשורת של הפרוייקט עולות ביחס לריבוע מספר המפתחים, בזמן שהעבודה עולה רק ביחס ישר. הטענה הזו זכתה מאז לשם "חוק ברוקס" ומתייחסים אליה כאמת לאמיתה. אבל אם חוק ברוקס היה נכון, לינוקס היה בלתי-אפשרי.

הקלאסיקה של ג'רלד ווינברג "הפסיכולוגיה של תכנות מחשבים" מספקת את מה שבראיה לאחור אנו יכולים לראות כתיקון חיוני לברוקס. בדיון שלו ב"תכנות חסר אגו", ווינברג מציין שבמקומות שבהם מפתחים אינם טריטוריאליים בקשר לקוד שלהם, ומעודדים אנשים אחרים לחפש באגים ואפשרויות לשיפור, שיפורים קורים מהר הרבה יותר מאשר במקומות אחרים.

ייתכן שבחירת המלים של ווינברג מנעה מהניתוח שלו להיעשות מקובל כפי שמגיע לו – אחרי הכל, מחשבה מצחיקה היא תיאור האקרים באינטרנט כ"חסרי אגו". אבל אני חושב שהטיעון שלו נראה יותר מושך כיום מאשר בעבר.

ההיסטוריה של יוניקס הייתה צריכה להכין אותנו למה שאנחנו לומדים היום מלינוקס (ומה שווידאתי בקנה מידה קטן יותר על ידי העתקה מכוונת של שיטותיו של לינוס) [EGCS]. : שלמרות שתכנות נשארת בבסיסה פעילות של אדם בודד, שיפצורים טובים באמת מושגים על ידי רתימת תשומת הלב והשכל של קהילות שלמות. המפתח המשתמש רק במוחו הוא בפרוייקט סגור יפגר אחרי מפתח שיודע איך ליצור סביבה פתוחה ומתפתחת שבה מגיעות חקירות על אפשרויות התכנון, תרומות קוד, דיווחי באגים ושיפורים אחרים ממאות (ואולי אלפי) אנשים.

אבל עולם היוניקס המסורתי לא יכל היה להגיע עם גישה זו לשיא ממספר סיבות. סיבה אחת הייתה ההגבלות החוקיות של רשיונות שונים לשימוש בתוכנה, סודות ואינטרסים מסחריים. סיבה אחרת (במבט לאחור) הייתה שהאינטרנט עדיין לא היה טוב מספיק.

לפני הגעת האינטרנט הזול היו מספר קהילות שהיו ממוקמות במקומות גיאוגרפיים מצומצמים ומוגדרים שבהן התרבות עודדה את התכנות "חסר האגו" של ווינברג, ושבהן מפתחים יכלו למשוך בקלות הרבה מפתחים-מסייעים ונותני-עצות מיומנים. מעבדת Bell, מעבדת MIT AI, האוניברסיטה של קליפורניה בברקלי – כל אלה היו ביתן של המצאות שהפכו לאגדה ושעדיין הן בעלות יכולת היום.

לינוקס היה הפרוייקט הראשון שבמאמץ מודע ומוצלח השתמש בכל העולם כבמאגר הכשרונות שלו. אני חושב שזה לא היה צירוף מקרים שתקופת ההתפתחות הראשונית של לינוקס הקבילה ללידת ה-World Wide Web, או שאותה תקופה, 1993-1994, שבה לינוקס המריא הקבילה להמראה של תעשיית ה-ISP או ההתפוצצות של העניין של הזרם המרכזי של התקשורת באינטרנט. לינוס היה האדם הראשון שלמד איך לשחק לפי החוקים החדשים שהאינטרנט הציג.

אבל בעוד שאינטרנט זול היה תנאי הכרחי כדי שהמודל של לינוקס יתפתח, אני לא חושב שהוא היה תנאי מספיק בפני עצמו. עוד גורם הכרחי היה התפתחות של סגנון מנהיגות ומנהגים שיתופיים שאפשרו למפתחים למשוך מפתחים-מסייעים ולנצל את האינטרנט בצורה מרבית.

אבל מה הוא סגנון המנהיגות ומה הם המנהגים? הם אינם יכולים להיות מבוססים על יחסי כוח – וגם אם כן, מנהיגות המבוססת על כפייה לא הייתה מביאה לתוצאות שאנו רואים. ווינברג מצטט את האוטוביוגרפיה של האנרכיסט הרוסי בן המאה ה- 19 פיוטר אלקסייביץ' קרופוטקין "זכרונותיו של מהפכן":

"כמי שגדל במשפחה של בעלי-איכרים נכנסתי לחיים פעילים, כמו כל הגברים הצעירים של זמני, עם הרבה אמונה בנחיצות של פקודות, הוראות, נזיפות, עונשים וכיוצא באלה. אבל כאשר, בשלב מוקדם, היה עלי לנהל יוזמה רצינית ולהתעסק עם אנשים [חופשיים], היכן שכל טעות הייתה עלולה להוביל מייד לתוצאות חמורות, למדתי להעריך את ההבדל שבין פעולות עיקרון הפיקוד והמשמעת לבין פעולות מתוך עקרון ההבנה הדדית. השיטה הקודמת עובדת בצורה ניתנת להערצה במצעד צבאי, אבל אינה שווה דבר בחיים האמיתיים, וניתן להשיג את המטרה רק באמצעות המאמצים של רצונות רבים המתמקדים בנקודה אחת."

"המאמצים של רצונות רבים המתמקדים בנקודה אחת" הם בדיוק מה שפרוייקט כמו לינוקס צריך – ו"עקרון הפיקוד" הוא באופן מעשי בלתי אפשרי לשימוש אצל המתנדבים בגן העדן האנרכיסטי שהוא האינטרנט. כדי לפעול ולהתחרות בצורה אפקטיבית על האקרים הרוצים להוביל עבודה משותפת ללמוד איך לגייס ולהניע קהילות של עניין משותף בצורה המוצעת באופן מעורפל ב"עקרון ההבנה ההדדית" של קרופוטקין. עליהם ללמוד להשתמש בחוק לינוס.

במקום מוקדם יותר התייחסתי ל "שיטת דלפי" כהסבר אפשרי לחוק לינוס. אבל מתבקשות מאוד גם אנלוגיות חזקות יותר במערכות מסתגלות בביולוגיה וכלכלה. עולם הלינוקס מתנהג במובנים רבים כמו שוק חופשי או אקולוגיה, אוסף של סוכנים אנוכיים המנסים להעלות למקסימום את הרווח, ובתהליך נוצר סדר ספונטני המתקן את עצמו והוא יותר מפורט ויעיל מאשר מה שכל תכנון מרכזי היה יכול להשיג. כאן, אם כן, הוא המקום לחפש את "עיקרון ההבנה ההדדית".

ה"רווח" שהאקרים של לינוקס מנסים להגדיל אינו רווח כלכלי קלאסי אלא שילוב של סיפוק האגו שלהם והפרסום החיובי שלהם אצל האקרים אחרים. (ניתן לקרוא למניע זה "אלטרואיסטי", אבל מי שעושה כן מתעלם מהעובדה שהאלטרואיזם עצמו הנו צורה של סיפוק האגו של האלטרואיסט). תרבויות התנדבותיות העובדות בצורה כזו אינן בלתי-נפוצות; אחת מהן שלה הייתי שותף במשך זמן רב היא תרבות החובבים של מדע בדיוני, שבניגוד לתרבות ההאקרים מכירה בצורה מפורשת ב-"egoboo" (סיפוק האגו הנובע מפרסום חיובי אצל חובבים אחרים) כמניע הבסיסי מאחורי פעילויות התנדבותיות.

לינוס, בכך שהציב את עצמו בהצלחה כשוער הפרוייקט שבו רוב הפיתוח נעשה על ידי אחרים, ובכך שטיפח עניין בפרוייקט עד שנעשה מקיים את עצמו, הראה תפיסה מדויקת של "עקרון ההבנה המשותפת" של קרופוטקין. התפיסה הדמוי-כלכלית הזו של עולם הלינוקס מאפשרת לנו לראות איך משתמשים בהבנה הזו.

נוכל לראות את שיטותיו של לינוס כדרך ליצור שוק יעיל ב-"egoboo" – לחבר את האנוכיות של האקרים אינדיבידואליים בצורה חזקה ככל האפשר כדי להגיע למטרות קשות שניתן להשיג אותן רק על ידי שיתוף פעולה יציב. בעזרת פרוייקט fetchmail הראיתי (למרות שבקנה מידה קטן יותר) שניתן לשכפל את שיטותיו ולהגיע לתוצאות טובות. ייתכן שאפילו עשיתי זאת בצורה מודעת ושיטתית יותר ממנו.

אנשים רבים (ובייחוד אלה שאינם תומכים פוליטית בשווקים חופשיים) היו מצפים מתרבות של אגואיסטים המונעים על ידי עצמם שתהיה מפוצלת, טריטוריאלית, בזבזנית, נוטה לסודיות ועוינת. אבל הציפייה הזו מוכחת כבלתי נכונה על ידי (למשל) הגיוון, האיכות והעומק המדהימים של התיעוד של לינוקס. דבר ידוע הוא שמתכנתים שונאים לתעד; איך קרה, אם כך, שהאקרים של לינוקס עושים זאת כל כך הרבה? כנראה שהשוק החופשי של לינוקס ב-"egoboo" עובד טוב יותר ביצירת התנהגות ערכית ומתחשבת מאשר הפרוייקטים המסחריים הגדולים והממומנים-היטב של יצרני התוכנה המסחריים.

שני הפרוייקטים, לינוקס ו-fetchmail, הראו שעל ידי סיפוק האגו של האקרים רבים אחרים, מפתח / מתאם טוב יכול להשתמש באינטרנט כדי לנצל את היתרונות של ריבוי מפתחים-מסייעים מבלי שהפרוייקט יקרוס לתוהו ובוהו. וכך אני מציע את החוק הבא כניגוד לחוק ברוקס:

19: אם למתאם הפיתוח יש דרך תקשורת טובה לפחות כמו האינטרנט, והוא יודע איך להנהיג ללא כפייה, מוחות רבים הם בהכרח טובים יותר מאחד.

אני חושב שהעתיד של תוכנת קוד-פתוח יהיה שייך במידה הולכת וגוברת לאנשים היודעים איך לשחק את המשחק של לינוס, אנשים העוזבים מאחוריהם את מודל הקתדרלה ומאמצים את הבזאר. איני מתכוון בכך שחזון אישי כבר אינו משנה; אלא שהפיתוח החי של תוכנת קוד-פתוח יהיה שייך לאנשים המתחילים בחזון והברקה אישית ומגבירים אותם באמצעות הבנייה האפקטיבית של קהילות התנדבותיות של בעלי עניין משותף.

וייתכן שלא רק העתיד של תוכנת קוד-פתוח. אף מפתח קוד-סגור אינו יכול להשיג מאגר כשרונות דומה לזה שקהילת הלינוקס יכולה לגייס כדי לפתור בעיה. מעטים מאוד יכולים אפילו לשכור יותר ממאתיים (1999: שש מאות) האנשים שתרמו ל-fetchmail!

ייתכן שבסופו של דבר תרבות הקוד הפתוח תנצח לא בגלל ששיתוף-פעולה הוא נכון מבחינה מוסרית או ש"הגבלת תוכנה" היא דבר שגוי מוסרית (בהנחה שאתה מסכים עם הטענה האחרונה, טענה שגם לינוס וגם אני איננו מסכימים עמה), אלא פשוט בגלל שעולם הקוד הסגור אינו יכול לנצח במרוץ חימוש התפתחותי עם קהילות הקוד הפתוח, היכולות לתרום יותר זמן של בעלי כשרון כדי לפתור בעיה, בכמה סדרי גודל.

על ניהול וקו מז'ינו

מסמך "הקתדרלה והבזאר" המקורי הסתיים בחזון למעלה – אספסוף מאושר ומרושת של מתכנתים / אנרכיסטים דוחקים את רגליו ומדהימים את העולם ההירארכי של תוכנת קוד-סגור קונוונציונאלית.

למרות זאת, ספקנים רבים לא השתכנעו; והשאלות שהם העלו ראויות לתשובות הוגנות. רוב ההתנגדויות לטיעונים התומכים בבזאר התבססו על הטענה שהם לא העריכו מספיק את ההשפעה מכפילת-הייצור של הנהלה קונוונציונאלית.

מנהלי תוכנה רבים בעלי חשיבה מסורתית טענו שהצורה הבלתי מסודרת שבה קבוצות פרוייקטים נוצרות, משתנות ומתפרקות בעולם הקוד הפתוח מספיקה כדי לבטל חלק ניכר מהיתרונות שנוצרים עקב המספרים הגדולים של המפתחים שיש לפרוייקטים של קוד פתוח לעומת כל מפתח קוד-סגור. הם טענו שבפיתוח תוכנה מה שמשנה באמת הוא המאמץ המרוכז לאורך זמן ועד כמה המשתמשים יכולים לצפות להשקעות מתמשכות בתוכנה, ולא רק כמה אנשים זרקו עצם לסיר ועזבו אותה להתבשל.

יש משהו בטיעון הזה; למעשה, פיתחתי את הרעיון שהציפייה לשירות בעתיד היא המפתח לכלכלה של תעשיית התוכנה ב- The Magic Cauldron.

אבל בטיעון הזה יש גם בעיה חבויה; ההנחה המובלעת שפיתוח תוכנת קוד-פתוח אינו יכול לספק מאמץ מרוכז כזה. למען האמת היו הרבה פרוייקטים של קוד פתוח שהיו להם כיוון מוגדר קהילת מתחזקים אפקטיבית במשך תקופה ארוכה מאוד בלי אף אחת משיטות התמריצים או השליטה המוסדית שהנהלה קונוונציונאלית תופסת כהכרחיים. הפיתוח של עורך התמלילים GNU Emacs הוא דוגמה קיצונית היכולה ללמד אותנו רבות; הפרוייקט קלט את מאמציהם של מאות מפתחים לאורך יותר מ- 15 שנים לתוך חזון תכנוני אחיד, למרות התחלופה הגבוהה והעובדה שרק אדם אחד (הכותב של הפרוייקט) נשאר פעיל לאורך כל הזמן. אף עורך תמלילים של קוד סגור לא הצליח מעולם אפילו להגיע לאורך חיים כזה.

הדוגמה הזו מציעה סיבה טובה לבדוק את היתרונות של פיתוח תוכנה המנוהל בצורה קונוונציונאלית, ולעשות זאת בצורה נפרדת משאר הטיעונים התומכים בשיטת קתדרלה לעומת הבזאר. אם GNU Emacs יכול לשמור על חזון ארכיטקטוני עקבי לאורך 15 שנים, או מערכת הפעלה כמו לינוקס יכולה לעשות את אותו הדבר לאורך שמונה שנים, תוך כדי שינוי מהיר של טכנולוגית החומרה והפלטפורמה; ואם (כמו שאכן הוא המצב) ישנם הרבה פרוייקטים מתוכננים היטב של קוד פתוח שהם בני יותר מחמש שנים – יש לנו את הזכות לתהות מה, אם בכלל, הם היתרונות של ההוצאה הצדדית האדירה הכרוכה בהנהלה קונוונציונאלית.

היתרונות האלו ללא ספק אינם כוללים עמידה בלוח זמנים, עמידה בתקציב, או תמיכה בכל היכולות של התכנון המקורי; דבר נדיר הוא שפרוייקט "מנוהל" עומד אפילו באחת מהמטרות האלו, לא כל שכן כל השלוש. היתרון גם לא יכול להיות היכולת להסתגל לשינויים בטכנולוגיה ובסביבה הכלכלית במשך חיי הפרוייקט; קהילת הקוד הפתוח הוכיחה עצמה אפקטיבית הרבה יותר בתחום הזה (כפי שכל אחד יכול לוודא בקלות, למשל, על-ידי השוואת שלושים שנות האינטרנט למחציות-החיים הקצרות של טכנולוגיות הרשת הסגורות – או עלות המעבר מ- 16 ביט ל- 32 ביט ב-Microsoft Windows בניגוד להגירה כמעט חסרת המאמץ של לינוקס באותה תקופת זמן, ולא רק בקו הפיתוח של אינטל אלא גם ליותר מתריסר פלטפורמות חומרה אחרות, כולל Alpha הרץ ב- 64 ביט).

דבר אחד שאנשים רבים מחשיבים כיתרון של הדרך המסורתית היא שיש מישהו אחראי מבחינת החוק שאפשר לתבוע ממנו פיצויים אם משהו בפרוייקט מתקלקל. אבל זוהי רק אשליה; רוב הרשיונות לשימוש בתוכנות נכתבים כדי להתנער אפילו מהאחריות ל-merchantability, שלא לדבר על תפקוד – והמקרים שבהם שולמו פיצויים עבור בעיות בתפקוד הם נדירים עד כדי היעלמות מוחלטת. אבל אפילו אם הם היו נפוצים, הרגשת ביטחון בגלל היכולת לתבוע מישהו תהיה החמצת הנקודה. מלכתחילה לא רצית להיות בתביעה משפטית; רצית תוכנה עובדת.

אז מה נותנת לנו ההוצאה הצדדית על הנהלה?

כדי להבין זאת, עלינו להבין מה מנהלי פיתוח תוכנה מאמינים שהם עושים. אישה אחת שאני מכיר, ודומה שהיא טובה מאוד בעבודתה, אומרת שלניהול פרוייקט תוכנה יש חמישה תפקידים:

• להגדיר מטרות ולשמור על כך שכולם בפרוייקט יהיו ממוקדים באותו הכיוון.
• להשגיח ולהקפיד על כך שלא מדלגים על פרטים חיוניים.
• להניע אנשים לבצע עבודה משעממת אבל חיונית.
• לארגן את השימוש באנשים כך שתושג יצרנות אופטימלית.
• להשיג משאבים הנחוצים כדי להמשיך את הפרוייקט.

נראה שאלה מטרות ראויות, כולן; אבל במודל הקוד הפתוח ובסביבה החברתית שלו, הם מתחילים להיראות לא רלוונטיים באופן מוזר. נתייחס אליהם בסדר הפוך.

ידידתי מספרת שהרבה מהשגת המשאבים היא בבסיסה הגנתית; ברגע שמנהל משיג אנשים ומחשבים וחדרי משרדים עליו להגן עליהם ממנהלים עמיתים המתחרים עמו על אותם המשאבים, וממנהלים בכירים יותר המנסים לארגן את המאגר המוגבל של המשאבים בצורה היעילה ביותר.

אבל מפתחי קוד פתוח הם מתנדבים, הבוחרים את עצמם גם מתוך עניין וגם מתוך יכולת לתרום לפרוייקטים שהם עובדים עליהם (ובאופן כללי קביעה זו נשארת נכונה גם כשמשלמים להם שכר כדי לשפצר קוד פתוח). האתוס של ההתנדבות דואגת לצד "ההתקפי" של השגת המשאבים באופן אוטומטי; אנשים מביאים משאבים משלהם לפרוייקט. ויש מעט מאוד צורך למנהל להיות הגנתי במובן הקונוונציונאלי.

בכל אופן, בעולם של מחשבים זולים וקישורי אינטרנט מהירים, נראה שבאופן עקבי למדי המשאב המוגבל היחיד הוא כוח אדם מיומן. פרוייקטים של קוד פתוח כמעט מעצם ההגדרה לעולם אינם נסגרים עקב מחסור במחשבים או חדרי משרדים; הם מתים רק כאשר המפתחים עצמם מאבדים עניין.

וכאשר זה המצב, חשוב אפילו יותר שהאקרים של קוד פתוח יארגנו את עצמם ליצרנות מקסימלית על ידי בחירה עצמית – והסביבה החברתית היא חסרת רחמים בהעדפת הכשרונות שלה. ידידתי, שגם עולם הקוד הפתוח וגם פרוייקטים סגורים גדולים מוכרים לה מאמינה שהקוד-הפתוח הצליח חלקית בגלל שהתרבות שלו מקבלת רק את ה- 5% המוכשרים ביותר מתוך אוכלוסיית המתכנתים. היא מבלה את רוב זמנה בארגון שאר ה- 95% וכך יכולה לראות ממקור ראשון את ההבדל המפורסם העצום של פי 100 בין המתכנתים המוכשרים ביותר לבין אלה המסוגלים לבצע את המשימה אך לא יותר מכך.

הגודל של ההבדל הזה מעלה שאלה משונה: האם פרוייקטים אינדיווידואליים והתחום ככלל יתפקדו טוב יותר בלי יותר מ- 50% מאלה שמסוגלים פחות מכל לבצע את העבודה? מנהלים חושבים הבינו כבר לפני זמן רב שאם התפקיד היחיד של הנהלת תוכנה קונוונציונאלית הוא להפוך את התרומה נטו של הפחות מוכשרים מהפסד לרווח שולי, ייתכן שכל המשחק אינו שווה את המאמץ.

ההצלחה של קהילת הקוד הפתוח מחדדת את השאלה הזו באופן ניכר, על ידי הספקת עדויות מוצקות לכך שלעיתים קרובות זה הרבה יותר זול ואפקטיבי לגייס מתנדבים הבוחרים את עצמם מהאינטרנט במקום לנהל בניינים מלאים באנשים שהיו מעדיפים לעשות משהו אחר.

מה שמביא אותנו לשאלת המוטיבציה. צורה דומה ונפוצה לנסח את הטענה של ידידתי היא שניהול פיתוח תוכנה הוא פיצוי הכרחי למתכנתים חסרי מוטיבציה שאלמלא כן לא היו מסוגלים ליצור עבודה טובה.

התשובה הזו בדרך כלל משולבת בטענה שקהילת הקוד הפתוח מסוגלת לבצע רק עבודה "סקסית" או מגרה טכנולוגית; כל דבר אחר לא יבוצע (או שיבוצע בצורה גרועה) אלא אם כן היא נעשית על ידי פיוני-משרד המונעים על ידי כסף ועם מנהלים המחזיקים שוטים מעל לראשם. אני מתייחס לסיבות הפסיכולוגיות והחברתיות לפקפק בטענה זו ב"ליישב את הנוספרה" ( Homesteading the Noosphere). למטרות הנוכחיות, אני חושב שמעניין יותר להצביע על ההשלכות המתבקשות אם הטענה נכונה.

אם הסגנון הקונוונציונאלי בעל הקוד הסגור והמנוהל בצורה כבדה של פיתוח תוכנה מוגן אך ורק על ידי קו מז'ינו של בעיות הנחשבות למשעממות, ההגנה תעבוד לכל תחום תוכנה רק כל עוד אף אחד לא מצא את הבעיות האלה מעניינות או אינו מוצא דרך להגיע למטרה מסביבן. משום שברגע שתהיה תחרות פתוחת-קוד לפיסת תוכנה "משעממת", לקוחות ידעו שהבעיה סוף סוף נפתרה על ידי מישהו שבחר לפתור אותה בגלל עניין בבעיה עצמה – ובתוכנה כמו בכל סוג של עבודה יצירתית, עניין גורם למוטיבאציה גבוהה הרבה יותר מאשר הכסף לבדו.

לכן, שימוש במבנה ניהול קונוונציונאלי כאשר המטרה היחידה היא ליצור מוטיבאציה, היא כנראה טקטיקה טובה אבל אסטרטגיה גרועה; ניצחון בטווח הקצר, אבל הפסד בטוח בטווח הארוך.

עד עכשיו, נראה שהנהלת פיתוח קונוונציונאלית מפסידה בשתי קטגוריות (השגת משאבים, ארגון) וחיה על זמן שאול בשלישית (מוטיבציה). והמנהל הקונוונציונאלי המודאג המסכן גם לא יקבל שום תמיכה מנושא הפיקוח; הטיעון הטוב ביותר שיש לקהילת הקוד הפתוח הוא שבדיקת העמיתים המבוזרת מנצחת את כל השיטות הקונוונציונאליות המנסות לוודא שפרטים קטנים לא נשארו מאחור.

האם נוכל לומר שהגדרת מטרות היא ההצדקה להוצאה הצדדית של הנהלת פרוייקט תוכנה קונוונציונאלית? אולי; אבל כדי לעשות כך נצטרך סיבה טובה להאמין שוועדות ניהול ומפות-דרך תאגידיות יצליחו בהגדרת מטרות ראויות טוב יותר ממנהיגי הפרוייקטים ומזקני השבט הממלאים את התפקיד המקביל בעולם הקוד הפתוח.

על פניו זהו טיעון שקשה מאוד לטעון אותו. ולא דווקא הצד של הקוד הפתוח במשוואה (החיים הארוכים של Emacs, או היכולת של לינוס טורוולדס להניע המוני מפתחים בדיבורים על "שליטה עולמית") הוא שמקשה על הטיעון. מה שמקשה עליו הוא חוסר ההצלחה הידוע הנורא שבה מנגנונים קונוונציונאליים מגדירים את מטרות הפרוייקטים.

אחת הקביעות הידועות ביותר של הנדסת תוכנה היא שכ- 60% עד 75% מהפרוייקטים הקונוונציונאליים לעולם אינם מגיעים לידי השלמה או נדחים על ידי המשתמשים המיועדים שלהם. הטווח הזה אפילו קרוב למציאות (ומעולם לא פגשתי מנהל בעל ניסיון המערער עליו), הרי שרובם של הפרוייקטים הם (א) בלתי אפשריים, ריאליסטית, או (ב) פשוט מוטעים.

זו, יותר מכל בעיה אחרת, היא הסיבה שבעולם הנדסת התוכנה של היום, מספיקות רק המילים "וועדת הנהלה" כדי לגרום לצמרמורת בגבו של הקורא – אפילו (ואולי בייחוד) אם הקורא הוא מנהל. הימים שבהם רק מתכנתים התלוננו על התבנית הזו עברו מזמן; קריקטורות "דילברט" תלויות כעת מעל שולחנותיהם של מנהלים בכירים.

אם כן, תשובתנו למנהל פיתוח התוכנה המסורתי היא פשוטה – אם קהילת הקוד הפתוח באמת לא העריכה מספיק את ערכה של ההנהלה הקונוונציונאלית,מדוע כה רבים מכם מראים תיעוב כזה לשיטות של עצמכם?

שוב, קיומה קהילת הקוד הפתוח מחדדת מאוד את השאלה – משום שכיף לנו עם מה שאנחנו עושים. המשחק היצירתי שלנו משיג הצלחה טכנית, נתח-שוק ונתח-ידע בקצב מדהים. אנחנו מוכיחים לא רק שאנחנו יכולים ליצור תוכנה טובה יותר, אלא גם שאושר הוא נכס.

שנתיים וחצי לאחר הגרסה הראשונה של החיבור הזה, המחשבה הקיצונית ביותר שאני בוחר לסיים בה היא כבר לא החזון של עולם תוכנה הנשלט על ידי קוד פתוח; חזון כזה, אחרי הכל, נראה אפשרי להרבה אנשים פיכחים בחליפות בימים אלה.

במקום זאת, אני רוצה להציע את המחשבה שיכול להיות שיש כאן שיעור רחב יותר על תוכנה (וייתכן שעל כל סוג שהוא של עבודה יצירתית). באופן כללי, אנשים נהנים מעבודה כאשר היא נמצאת במין מיקום של אתגר אופטימאלי; לא מספיק קל כדי להיות משעמם, ולא קשה מדי להשגה. מתכנת מאושר הוא מתכנת שאיננו, מצד אחד, מנוצל פחות מדי, ומצד שני אינו צריך לעמוד בעומס של מטרות לקויות ובלחצים ובחיכוך הכרוכים בתהליך היצירה. הנאה צמודה ליעילות.

התייחסות לשיטת העבודה שלך עצמך בפחד ובתיעוב (אפילו בצורה האגבית והאירונית הנרמזת על ידי תליית קריקטורות דילברט) צריכה להיות סימן שהשיטה נכשלה. הנאה, הומור ומשחק הם באמת נכסים; לא למען היצירתיות בלבד השתמשתי במלים "המונים מאושרים" למעלה, וזו אינה בדיחה שהסמל של לינוקס הוא פינגווין ילדותי וחמוד.

יכול מאוד להיות שיתברר בסופו של דבר שאחת ההשפעות החשובות ביותר של הצלחת הקוד הפתוח היא ללמד אותנו שמשחק הוא המצב היעיל ביותר של עבודה יצירתית.

סוף דבר: נטסקייפ מצטרפת לבזאר

זו הרגשה מוזרה להבין שאתה עושה היסטוריה…

ב- 22 ביוני 1998, בערך שבעה חודשים לאחר שפרסמתי לראשונה את "הקתדרלה והבזאר", הכריזה Netscape Communications, Inc. על תוכניותיה לתת את קוד המקור ל-Netscape Communicator. לא היה לי שום מושג שזה עומד לקרות עד היום שלפני ההכרזה.

אריק האהן, סמנכ"ל ומנהל הטכנולוגיה הראשי בנטסקייפ, שלח לי דואר אלקטרוני זמן קצר לאחר מכן שאמר: "בשם כולם בנטסקייפ, אני רוצה להודות לך על שעזרת לנו להגיע לנקודה זו מלכתחילה. חשיבתך וכתיבתך היו השראות חיוניות להחלטתנו."

בשבוע שלאחר מכן טסתי לעמק הסיליקון בעקבות הזמנת נטסקייפ לדיון אסטרטגי של יום שלם (ב- 4 בפברואר 1998) עם כמה מהמנהלים הבכירים שלהם והאנשים הטכניים. תכננו את אסטרטגיית פרסום קוד המקור והרשיון יחד.

מספר ימים לאחר מכן כתבתי את הדברים הבאים:

"נטסקייפ עומדת לספק לנו מבחן אמיתי בקנה מידה גדול של מודל הבזאר בעולם המסחרי. בפני תרבות הקוד הפתוח ניצבת סכנה; אם הניסיון של נטסקייפ לא יעבוד, ייתכן שרעיון הקוד הפתוח יוכתם בצורה כזו שהעולם המסחרי לא ייגע בו שוב במשך עשור שלם.

"מצד שני, זוהי גם הזדמנות נפלאה. התגובה הראשונית לצעד הזה ב-Wall Street ובמקומות אחרים הראתה אופטימיות זהירה. יש לנו גם הזדמנות להוכיח את עצמנו. אם נטסקייפ תצליח להשיג נתח שוק רציני באמצעות הצעד הזה, ייתכן שזה יתחיל מהפיכה שכבר מזמן הגיע זמנה בתעשיית התוכנה.

"השנה הקרובה תהיה חינוכית ומעניינת מאוד."

ואכן היא הייתה. כשכתבתי זאת באמצע 1999, הפיתוח של מה שמאוחר יותר נקרא מוזילה היה הצלחה מוכחת. מוזילה השיגה את מטרתה המקורית של נטסקייפ, שהייתה למנוע ממייקרוסופט ליצור מונופול סגור בשוק הדפדפנים. היא גם השיגה הצלחות טכניות דרמטיות (למשל מנוע התצוגה של הדור הבא, Gecko).

למרות זאת, היא עדיין לא הצליחה להשיג מאמץ פיתוח מסיבי מחוץ לנטסקייפ שיוזמי מוזילה קיוו לו. כאן נראה שהבעיה הייתה שבמשך זמן רב מוזילה בעצם שברה את אחד החוקים הבסיסיים של מודל הבזאר; הם לא פרסמו משהו שתורמים פוטנציאליים יכולים להריץ בקלות ולראות אותו עובד. (עד יותר משנה לאחר הפרסום, בניית מוזילה מקוד המקור דרשה רשיון מספריית Motif הסגורה).

הנקודה השלילית ביותר (מנקודת המבט של העולם החיצוני) הייתה שצוות מוזילה עדיין לא פרסם דפדפן באיכות שיווק – ואחד ממנהלי הפרוייקט גרם לסנסציה לא קטנה כאשר התפטר והתלונן על הנהלה גרועה והזדמנויות שהוחמצו. "קוד פתוח," הוא העיר, ובצדק, "איננו מטה קסמים".

ואכן הוא איננו. התחזית ארוכת הטווח לעתידה של מוזילה נראית טובה יותר כעת (באוגוסט 1999) מאשר בזמן התפטרותו של ג'יימי זווינסקי – אבל הוא צדק בהערכתו שקוד פתוח לא בהכרח יציל פרוייקט קיים הסובל ממטרות לקויות, קוד ספגטי או כל אחת מהמחלות הכרוניות האחרות שמהן עלול לסבול פרוייקט הנדסת תוכנה. מוזילה הצליחה לספק, בו זמנית, דוגמה לצורה שבה פרוייקט קוד פתוח יכול להצליח ולצורה שבה הוא יכול להיכשל.

למרות זאת, רעיון הקוד הפתוח הצליח בינתיים ומצא תומכים במקומות אחרים. בשנת 1998 ובשלהי שנת 1999 הייתה התפוצצות של עניין במודל הפיתוח של קוד פתוח, והתפוצצות זו גם נגרמה וגם תרמה להצלחה הנמשכת של מערכת ההפעלה לינוקס. הכיוון שמוזילה התחילה נמשך בקצב מואץ.

ביבליוגרפיה

ציטטתי מספר חלקים מפרדריק פ. ברוקס בספרו הקלאסי The Mythical Man Month משום שבמובנים רבים עדיין אין מתחרים לתפיסות שלו. אני ממליץ בכל לב על גרסת יום השנה ה- 25 מהוצאת אדיסון-ווסלי (Addison-Wesley, ISBN 0-201-83595-9) שהוסיפה את מאמרו מ- 1986 "No Silver Bullet".

הגרסה החדשה מביאה מבט לאחור בן 20 שנה שלא יסולא בפז, ובו ברוקס מודה באומץ בכמה מקביעותיו בטקסט המקורי שלא עמדו במבחן הזמן. קראתי לראשונה את המבט לאחור אחרי שהגרסה הפומבית הראשונה של המסמך הזה הייתה ברובה מוכנה, והופתעתי לגלות שברוקס מייחס מנהגים דמויי-בזאר למיקרוסופט! (אבל, למרות זאת, הייחוס הזה התגלה כמוטעה. ב- 1998 למדנו ממסמכי ליל כל הקדושים שקהילת המפתחים הפנימית של מיקרוסופט מפוצלת מאוד, כך שגישה כללית לקוד המקור החיונית כדי לתמוך בבזאר אפילו אינה באמת אפשרית.)

ג'רלד מ. ווינברג The Psychology Of Computer Programming ניו-יורק, הוצאת Van Nostrand Reinold, 1971) הציג את הרעיון (שזכה לשם גרוע) "תכנות חסר-אגו". למרות שללא צל של ספק הוא לא היה הראשון שהבין את חוסר הטעם ב"עיקרון הפיקוד", הוא כנראה היה הראשון שהבין וטען את הטיעון הזה בהקשר של פיתוח תוכנה.

ריצ'רד פ. גבריאל שחקר את תרבות היוניקס בעידן שקדם לעידן הלינוקס, הכיר בחוסר רצון בעליונות של דגם דמוי בזאר פרימיטיבי ב- 1989 במאמרוLISP: Good News, Bad News and How To Win Big. למרות שהוא מיושן במספר מובנים החיבור הזה עדיין מפורסם, ובצדק, אצל חובבי LISP רבים (כולל אותי). כותב מסויים הזכיר לי שהפרק שכותרתו "Worse is Better" ניתן לקריאה כמעט כציפייה ללינוקס. המסמך הזה נגיש ברשת ב-http://www.naggum.no/worse-is-better.html.

דה-מרקו ו-Lister's Peopleware: Productive Projects and Teams (ניו יורק, Dorset House, 1987, ISBN 0-932633-05-6) הוא אבן חן בלתי מוערכת כראוי ואני שמח לראות אותה מצוטטת במבט לאחור של פרד ברוקס. למרות שמעט ממה שיש למחברים לומר מתקשר ישירות ללינוקס או לקהילות קוד פתוח, ההארות של המחברים לגבי התנאים הנחוצים לעבודה יצירתית הן מדויקות ושוות את זמן הקריאה לכל מי שמנסה לייבא חלק מיתרונות מודל הבזאר לסביבה מסחרית.

ולבסוף, עלי להודות שכמעט וקראתי למסמך זה "הקתדרלה והאגורה" (The Cathedral and the Agora), כשהמונח האחרון הוא השם היווני לשוק פתוח או למקום מפגש ציבורי. המסמכים הלימודיים "agoric systems" מאת מארק מילר ואריק דרקסלר, על ידי כך שתיארו את התכונות של אקולוגיות מחשוביות דמויות-שוק, עזרו לי לחשוב בבהירות על תופעות מקבילות בתרבות הקוד הפתוח כשלינוס הראה לי אותן בתקיפות חמש שנים מאוחר יותר. המסמכים האלה נגישים ברשת ב- http://www.agorics.com/agorpapers.html. הערות שוליים

[JB] ב-Programming Pearls, מדען המחשב הנודע ג'ון בנטלי העיר על קביעתו של ברוקס ב"אם אתה מתכנן לזרוק ניסיון אחד לפח, אתה תזרוק שניים". הוא צודק כמעט בוודאות. הנקודה של קביעתו של ברוקס ושל קביעתו של בנטלי אינן רק שעליך לצפות שהניסיון הראשון לא יעלה בהצלחה, אלא שהתחלה מחדש עם הרעיון הנכון היא בדרך כלל אפקטיבית יותר מאשר ניסיון להציל בלגן.

[QR] קיימות גם דוגמאות של פרוייקטים פתוחי-קוד של בזאר שהקדימו את התפוצצות האינטרנט ואינם קשורים למסורות היוניקס והאינטרנט. הפיתוח של תוכנת הדחיסה info-Zip בין 1990 ל- 1992, בעיקר למערכות DOS, הייתה אחת. דוגמה אחרת היא מערכת לוח ההודעות RBBS (שוב ל-DOS) שפיתוחה החל ה- 1983 ושפיתחה קהילה חזקה מספיק לכך שיש לה פרסומי גרסאות סדירים למדי עד להווה (אמצע 1999) למרות היתרונות הטכניים האדירים של דואר אינטרנט ושיתוף בקבצים דרך מערכות לוח מודעות מקומיות. אמנם, קהילת ה-info-zip הייתה תלויה במידה מסוימת בדואר אינטרנט, אבל קהילת ה-RBBS הצליחה בפועל לבסס קהילה מקוונת בעלת-משקל על RBBS שהייתה עצמאית לחלוטין מתשתית ה-TCP/IP.

[JH] ג'ון האסלר הציע הסבר מעניין לכך שכפילות מאמץ אינו תמיד מגבלה נטו בפיתוח קוד-פתוח. הוא מציע שאקרא לכך "חוק האסלר": ההוצאות הקשורות בכפילות מאמץ גדלות בקצב הקטן מריבוע גודל הצוות – כלומר לאט יותר מההוצאות הצדדיות הכרוכות בתכנון וניהול הנחוצות כדי להיפטר מהן.

הטענה הזו למעשה אינה סותרת את חוק ברוקס. ייתכן שבאמת ההוצאות הצדדיות הנובעות ממורכבות ופגיעות לבאגים גדלות ביחס ישר לריבוע גודל הצוות, אבל שהוצאות הנובעות מעבודה כפולה הן למרות זאת מקרה מיוחד הגדל בקצב נמוך יותר. לא קשה לפתח סיבות אפשריות לכך, ואחת מהן היא העובדה הבלתי מעורערת שהרבה יותר קל להסכים על גבולות פונקציונאליים בין קוד של מפתחים שונים שימנעו כפילות מאמץ, מאשר קל למנוע אינטראקציות מזיקות ובלתי מתוכננות בין חלקי המערכת הגורמות לבאגים.

השילוב בין חוק לינוס וחוק האסלר מציע את האפשרות שיש שלושה גבולות גודל קריטיים בפרוייקטים של תוכנה. בפרוייקטים קטנים (אני מעריך בין מפתח אחד לשלושה) אין צורך בשום שיטות הנהלה מעבר לבחירת מתכנת מוביל. ויש גם טווח ביניים מעליו שבו העלות של הנהלה קונוונציונאלית היא נמוכה יחסית, כך שהרווחים הנובעים ממנה (הימנעות מכפילות מאמץ, איתור באגים ופיקוח המוודא שלא הוחמצו פרטים) הם בעצם חיוביים בסופו של דבר.

למרות זאת, מעבר לטווח זה השילוב בין חוק לינוס לחוק האסלר גורם לכך שההוצאות והבעיות של ניהול מסורתי מתגברות בקצב מהיר הרבה יותר מאשר ההוצאה הצפויה הנגרמת על ידי כפילות מאמץ. אחת מהבעיות האלו היא חוסר היכולת המובנית לרתום את אפקט העיניים הרבות אשר (כפי שראינו) פועל בצורה טובה יותר לכך שבאגים ופרטים קטנים לא יוחמצו מאשר הנהלה מסורתית. לכן, במקרה של פרוייקטים גדולים, השילוב בין החוקים האלו גורם לכך שהיתרון הסופי של הנהלה מסורתית ייעשה אפס.

[IN] ישנו עוד נושא הקשור לשאלה אם אפשרי הדבר להתחיל פרוייקט קוד-פתוח מההתחלה והוא אם סגנון הבזאר מסוגל לתמוך בעבודה חדשנית באמת. יש הטוענים כי ללא הנהגה חזקה הבזאר יכול רק לשכפל ולשפר רעיונות הקיימים כבר בגבול היכולת של ההנדסה, אבל אינו יכול למשוך את גבול היכולת הזה הלאה. כנראה שהמקום המפורסם-לרעה ביותר שבו נטען הטיעון הזה היה ב מסמכי ליל כל הקדושים , שני מזכרים פנימיים מביכים של מיקרוסופט על תופעת הקוד הפתוח. המחברים השוו את פיתוח לינוקס כמערכת הפעלה דמוית יוניקס ל"מרדף אחרי אורות אחוריים של מכונית" והביעו את הדעה ש"[ברגע שפרוייקט מגיע לגבול היכולת בתחום], רמת ההנהלה ההכרחית כדי להגיע לגבולות חדשים נעשית מסיבית".

יש שגיאות רציניות בטיעון הזה. אחת מהן נחשפת כאשר מחברי המסמכים עצמם משקפים מאוחר יותר ש"לעיתים קרובות […] רעיונות מחקר חדשים מיושמים ונגישים קודם כל בלינוקס לפני שהם נגישים / משולבים בפלטפורמות אחרות."

אם נקרא "קוד פתוח" במקום "לינוקס", נוכל לראות שזו איננה תופעה חדשה. היסטורית, קהילת הקוד הפתוח לא המציאה את Emacs או את ה-World Wide Web או את האינטרנט עצמו על-ידי רדיפה אחרי אורות אחוריים או על ידי כך שנהייתה מנוהלת באופן מסיבי – ובהווה, יש כל כך הרבה עבודה חדשנית בקוד הפתוח שאפשר להתפנק מעצם הבחירה. פרוייקט GNOME (אם לבחור אחד מרבים) דוחף הלאה את גבולות היכולת בממשק משתמש גרפי (GUI) וטכנולוגית עצמים בצורה כל כך חזקה שהוא משך תשומת לב ראויה לציון בעיתונות המחשבים הרבה מחוץ לקהילת הלינוקס. דוגמאות אחרות הן רבות, כפי שביקור ב- Freshmeat בכל יום שהוא יכול להוכיח במהירות.

אבל ישנה שגיאה בסיסית יותר בהנחה המובלעת שמודל הקתדרלה (או מודל הבזאר, או כל סוג אחר של מבנה ניהול) יכול איכשהו לגרום לחידושים לקרות באופן אמין. אלה הם שטויות. לקבוצות אין רעיונות פורצי דרך – אפילו קבוצות מתנדבים אנרכיסטים של בזאר בדרך כלל אינן מסוגלות למקוריות אמיתית, שלא לדבר על וועדות תאגידיות המורכבות מאנשים בעלי אינטרס שרידה המחייב את שימור הסטטוס-קוו. רעיונות חדשים באים מיחידים. כל מה שהחברה המקיפה אותם יכולה לקוות לעשות הוא להגיב לרעיונות פורצי דרך – לטפח אותם, לתגמל ולבדוק אותם בשקדנות במקום למעוך אותם.

יהיו כאלה שיראו זאת כנקודת מבט רומנטית, חזרה לסטריאוטיפים הישנים של הממציא-הבודד. אין זה כך; איני קובע שקבוצות אינן מסוגלות לפתח רעיונות פורצי דרך ברגע שאלה "בקעו מהביצה"; אנו אכן למדים מתהליך ביקורת העמיתים שקבוצות פיתוח כאלה הן חיוניות כדי להגיע לתוצאות בעלות איכות גבוהה. במקום זאת, אני מצביע על כך שכל פיתוח קבוצתי חייב להתחיל מהניצוץ של רעיון טוב אחד בראשו של אדם. קתדרלות, בזארים ומבנים חברתיים אחרים יכולים לתפוס את הניצוץ הזה ולזקק אותו, אבל הם אינם יכולים לגרום לו לקרות על פי דרישה.

לפיכך, הבעיה היסודית של חדשנות (בתוכנה או בכל מקום אחר) היא באמת איך לא למעוך אותו – אבל, אפילו חשוב יותר, איך לטפח הרבה אנשים שיכולים להיות להם רעיונות מלכתחילה.

יהיה זה אבסורדי להניח שפיתוח בסגנון קתדרלה יכול להצליח בכך אבל סף הכניסה הנמוך והתהליך הזורם של הבזאר אינם יכולים. אם כל מה שצריך הוא אדם אחד עם רעיון טוב, אזי הסביבה החברתית שבה אדם אחד יכול למשוך במהירות מאות או אלפי אחרים לרעיון הטוב הזה היא סביבה שתעלה בחידושיה, בסופו של דבר, על חברה שבה על אדם לעשות עבודת מכירות פוליטית להירארכיה כדי שיוכל לעבוד על הרעיון שלו בלי להסתכן בפיטורין.

ואכן, אם נסתכל על ההיסטוריה של חידושים בתוכנה על ידי ארגונים המשתמשים במודל הקתדרלה, נמצא במהירות שהם די נדירים. תאגידים גדולים מסתמכים על פיתוח אוניברסיטאי לרעיונות חדשים (ולכן חוסר הנחת של מחברי מסמכי ליל כל הקדושים מהיכולת של לינוקס להזין ולהשתמש בחידושים האלו בצורה מהירה יותר). או שהם קונים חברות קטנות שנבנו סביב מוחו של ממציא כלשהו. בשני המקרים החידוש אינו נולד בתרבות הקתדרלה; אכן, רבים מהחידושים המיובאים בצורה כזו מסיימים את דרכם בחנק שקט תחת "ההנהלה המסיבית" שמחברי מסמכי ליל כל הקדושים כל כך מפליגים בשבחם.

למרות הכל, זהו טיעון שלילי. ייתכן שהקורא ישוכנע טוב יותר על ידי טיעון חיובי. אני מציע את הניסוי הבא:

בחר קריטריון למקוריות שאתה מאמין שאתה מסוגל להשתמש בו באופן עקבי. אם ההגדרה שלך היא "אני אזהה את זה כשאראה את זה", זו אינה בעיה למטרות הניסוי הזה.

בחר כל מערכת הפעלה סגורת-קוד המתחרה עם לינוקס ואת המקור הטוב ביותר לדיווחים על עבודת הפיתוח הנוכחית בשבילה.

עקוב אחרי המקור ואחרי Freshmeat למשך חודש ימים. כל יום, ספור את מספר ההכרזות של פרסומים ב-Freshmeat שאתה מחשיב כעבודה "מקורית". השתמש באותה הגדרה של "מקוריות" להודעות של מערכת ההפעלה האחרת וספור אותן.

לאחר שלושים יום, סכם את שני המספרים.

ביום שכתבתי זאת, היו ב-Freshmeat עשרים ושתיים הכרזות על פרסומים, מתוכן שלוש נראו כאלה הדוחפות קדימה את גבול היכולת באיזושהי דרך. זה היה יום עייף ל-Freshmeat, אבל אני אהיה נדהם אם איזשהו קורא ידווח על מספר גדול יותר משלוש חידושים אפשריים בחודש בכל ערוץ סגור-קוד.

[EGCS] כעת יש לנו היסטוריה של פרוייקט שייתכן שיוכל לספק לנו מבחן טוב יותר להנחות הבסיסיות של הבזאר מאשר Fetchmail, במספר דרכים:EGCS, the Experimental GNU Compiler System.

הפרוייקט הוכרז באמצע אוגוסט 1997 כניסיון מודע להשתמש ברעיונות של הגרסאות הפומביות הראשונות של "הקתדרלה והבזאר". מייסדי הפרוייקט חשו שהפיתוח של GCC, מהדר ה-C של GNU, הלך והתפרק. במשך כ20- חודשים לאחר מכן GCC ו-EGCS המשיכו כמוצרים מקבילים – כאשר שניהם משתמשים באותה אוכלוסייה של מפתחים באינטרנט, שניהם מתחילים מאותו בסיס קוד מקור של GCC, ושניהם משתמשים באותם כלי יוניקס ובאותה סביבת פיתוח. ההבדל בין הפרוייקטים התבטא אך ורק בכך ש-EGCS ניסה באופן מודע להשתמש בעקרונות טקטיקת הבזאר שתיארתי קודם לכן, בזמן ש-GCC שימר ארגון הדומה יותר לקתדרלה עם קבוצת מפתחים סגורה ופרסומים בלתי תכופים.

זו הייתה הדוגמה הקרובה ביותר לניסוי מבוקר שיכולנו לבקש, והתוצאות היו דרמטיות. בתוך חודשים, הקדימו גרסאות ה-EGCS בצורה משמעותית ביכולות, באופטימיזציה טובה יותר ובתמיכה טובה יותר ב-FORTRAN וב-C++. אנשים רבים ראו את גרסאות הפיתוח של EGCS כיציבות יותר מאשר רוב הגרסאות היציבות העדכניות של GCC, ודיסטריבוציות לינוקס ראשיות החלו לעבור ל-EGCS.

באפריל 1999, הקרן לתוכנה חופשית (FSF, המממנים הרשמיים של GCC) פיזרו את קבוצת הפיתוח המקורית של GCC והעבירו את השליטה על הפרוייקט לצוות ההיגוי של EGCS באופן רשמי.

[SP] כמובן, הביקורת של קרופוטקין וחוק לינוס מעלים כמה נושאים רחבים יותר הקשורים לקיברנטיקה של ארגונים חברתיים. קביעה עממית נוספת של הנדסה תוכנה מציעה נושא אחד כזה: חוק קונווי מנוסח כ"אם יש לך ארבע קבוצות עובדות על מהדר, תקבל מהדר של ארבעה שלבים". המשפט המקורי היה כללי יותר: "ארגונים המתכננים מערכות מוגבלים לייצור תכנונים שהם עותקים של מבני התקשורת של הארגונים האלו". נוכל לנסח זאת בצורה ממצה יותר כ"האמצעים מגדירים את המטרה" או אפילו "תהליך נעשה מוצר".

לכן כדאי לשים לב לכך שבקהילת הקוד הפתוח, המבנה הארגוני והמטרה הארגונית תואמים בהרבה רמות. הרשת היא הכל ונמצאת בכל: לא רק האינטרנט, אלא האנשים המבצעים את העבודה יוצרים רשת מבוזרת ורופפת המחברת עמית לעמית, המספקת כפילות אמצעים ומתמודדת היטב עם חוסר תפקוד של חלקים ממנה. בשתי הרשתות, כל נקודה חשובה רק במידה שנקודות אחרות רוצות לשתף פעולה אתה.

העובדה שהמבנה הארגוני מתבסס על יחסי עמית לעמית היא חיונית ליצרנות המדהימה של הקהילה. הנקודה שקרופוטקין ניסה לקבוע בקשר ליחסי כוח מפותחת עוד יותר על ידי "עיקרון SNAFU": "תקשורת אמיתית אפשרית רק בין שווים, משום שאנשים כפופים מתוגמלים באופן עקבי יותר על שקרים נעימים מאשר על אמירת האמת על ידי הממונים עליהם". עבודת צוות יצירתית תלויה באופן מוחלט בתקשורת אמיתית ולכן היא מופרעת באופן רציני על ידי נוכחותם של יחסי כוח. קהילת הקוד הפתוח, החופשייה למעשה מיחסי כוח כאלה, מלמדת אותנו באמצעות הניגוד כמה באמת הם עולים לנו בבאגים, ביצרנות נמוכה ובהזדמנויות מוחמצות.

יותר מכך, עיקרון SNAFU חוזה שבארגונים המבוססים על סמכות יהיה ניתוק הולך וגובר בין מקבלי ההחלטות לבין המציאות, כאשר יותר ויותר מהקלט לאלה המחליטים נוטה להיות שקרים נעימים. קל לראות את הדרך בה מתבטאת הנטייה הזו בפיתוח תוכנה קונוונציונאלי: יש תמריץ חזק לכפופים להסתיר, להתעלם ולהפחית מערך בעיות. כאשר התהליך הזה נעשה מוצר, תוכנה היא אסון.

[HBS] ברוקס (מחבר " The Mythical Man-Month") אף הביע דעתו על כך: "העלות הכוללת של תחזוקת תוכנה הנמצאת בשימוש נרחב היא בד"כ כ- 40% או יותר מאשר עלות הפיתוח. באופן מפתיע, עלות זו מושפעת רבות ממספר המשתמשים. יותר משתמשים מוצאים יותר באגים." [ההדגשה אינה במקור]

יותר משתמשים מוצאים יותר באגים מכיון שהוספת משתמשים מוסיפה יותר דרכים לבחון את התוכנה. הדבר אף מועצם כאשר המשתמשים הם שותפים לפיתוח. כל אחד מהם ניגש למלאכת אפיון הבאג עם יכולת תפיסתית וכלי ניתוח שונים מעט, זוית שונה של הבעייה. נראה כי "שיטת דלפי" עובד באופן מדויק בגלל שוני זה. ובהקשר הספציפי של דיבוג תוכנה, שוני זה נוטה להפחית מאמץ מיותר.

לכן, הוספת עוד בטא-טסטרים עשויה שלא להשפיע על מורכבות הבאג הנוכחי, שהוא, מנקודת מבטו של המפתח, "מסובך ביותר" – אלא מעלה את הסיכוי שאחר, בעל יכולות מתאימות, ימצא את הבעיה הזו פשוטה למדי. לינוס לא לקח סיכונים. במקרה והיו באגים רציניים, הגרעין של לינוקס מוספר כך שמשתמשים פוטנציאליים יכלו לבחור בין הרצה של הגרסה האחרונה המסומנת כ-"יציבה", או להשתמש בגרסה המעודכנת ביותר – ולהסתכן בבאגים תמורת יכולות ותכונות חדשות. טקטיקה זו לא אומצה עדיין ע"י רוב ההאקרים המשתמשים בלינוקס, אך אולי עדיף שהיו משתמשים בה. העובדה ששני האפשרויות קיימות רק הופכות את שניהן ליותר אטרקטיביות.

תודות

המסמך הזה שופר בעזרת שיחות עם מספר גדול של אנשים שעזרו לדבג אותו. בייחוד אני רוצה להודות לג'ף דטקי שהציע את הנוסחה "דיבוג ניתן לביצוע בצורה מקבילית" ושעזר לפתח את הניתוח שנבע ממנה. אני גם רוצה להודות לננסי לייבוביץ' עבור הצעתה שאחקה את ווינברג בכך שאצטט את קרופוטקין. ביקורת חדת עין גם הגיעה מג'ואן אסלינגר ומרטי פרנץ מרשימת General Technics. גלן ונדנבורג הצביע על החשיבות של בחירה עצמית באוכלוסיות של תורמים והציע את הרעיון הפורה שאפשר להתייחס לחלק גדול מתהליך הפיתוח כפתירת "באגים של השמטה"; דניאל אפר הציע את האנלוגיות הטבעיות לכך. אני אסיר תודה לחברים של קבוצת משתמשי הלינוקס של פילדלפיה (PLUG) ששימשו כקהל ניסוי לגרסה הפומבית הראשונה של המסמך הזה. פאולה מטושק האירה את עיניי בעניין הנהלת תוכנה. פיל הדסון הזכיר לי שהארגון החברתי של תרבות ההאקרים משקפת את הארגון של התוכנה שלה, ולהפך. ולבסוף, הערותיו של לינוס טורוולדס עזרו מאוד ותמיכתו הראשונית הייתה מאוד מעודדת.

אודות המתרגמים ותרגום זה לעברית

התרגום לעברית של הקתדרלה והבזאר זכה לשתי גירסאות. הגירסה הראשונה של עדי סתיו בשנת 1999 וגירסה שניה של אלירן גונן ושלומי פיש שהתחילו את העבודה ב־2001 והפסיקו אותה במחציתה לאחר שהסתבר שקיימת גירסה קודמת שטרם פורסמה ברבים.

הפרק המאוחר "כמה עיניים צריך כדי להשתלט על מורכבות?" נלקח מהתרגום של אלירן גונן ושלומי פיש. פרק זה נחלק בויקיטקסט למספר חלקים כדי להתאימו למקור האנגלי. שאר המאמר מבוסס על התרגום של עדי סתיו.

ותודה גם לאלי מרמור שזרק קצה חוט ובזכותו נחסך תרגום שלישי נוסף.

הערות לתרגום העברי על ידי עדי סתיו

תרגום טקסטים טכניים מאנגלית לעברית הוא תמיד בעייתי, בגלל מחסור במלים ובעיית ההטיות. כעניין של עיקרון, אני משתדל להתעלם עד כמה שאפשר מההנחיות של האקדמיה ללשון העברית, ולהשתמש בשורשים מרובעים הנגזרים ממלים טכניות: "לדבג", "לקמפל" וכו'. זה מאפשר להוסיף שורשים חדשים לשפה העברית, שדבר שהיא צריכה באופן דחוף. זוהי גם השיטה הנפוצה יותר בדיבור בין אנשי מקצוע. אני מקווה שכתוצאה הטקסט נעשה ברור וטבעי יותר.

"הקתדרלה והבזאר" מכיל גם מלים נוספות רבות הנפוצות בקהילת האקרים אבל אינן נפוצות בד"כ בקהילת התוכנה, כך שהיה צורך למצוא להן תרגום:

האקר

Hacker. בניגוד לרושם המוטעה לחלוטין שנוצר על-ידי התקשורת הכללית והמקצועית בארץ ובעולם, האקרים, ברובם, אינם עוסקים כלל בפריצה למחשבים, לשום מטרה. האקרים הם אנשים הנהנים מעיסוק בתוכנה ובמחשבים, ונהנים להתנסות, לחקור את המערכות ואת יכולת התכנות שלהם. לינוקס, ותוכנות מצויינות רבות אחרות, נכתבו על-ידי האקרים, בלי שיהיה לתוכנות או למתכנתים כל קשר לפריצות למחשבים. המלה נולדה ב-MIT בשנות השישים במשמעות זו בדיוק (של אהבת תכנות ולא פריצה).

אלה הפורצים למחשבים מכונים קראקרים, ולא האקרים. הטעות נולדה כנראה באחד הסיקורים הראשונים של פריצה למחשבים, כאשר פורץ תיאר את עצמו באזני התקשורת כהאקר. בשנים האחרונות, התקשורת בארצות-הברית מודעת יותר להבדל, ומקפידה לקרוא לקראקרים בשמם, בעיקר עקב מאמץ הסברתי של האקרים מפורסמים, בין השאר של אריק ס. ראימונד, מחבר "הקתדרלה והבזאר". אבל המודעות הזו עדיין לא הגיעה לארץ.

הבעייה נעשית חמורה יותר כאשר כתבים מגלים שלמעשה אין הבדל בין קראקרים להאקרים, אבל אינם מבינים היטב את ההבדל: הם מפרסמים לעתים קרובות "הבהרות" המגלות לקוראים כי קראקרים עוסקים בפריצה על-מנת לגרום נזק, בעוד שהאקרים פורצים מבלי לגרום נזק. "הבהרות" שגויות אלה גורמות לאנשים רבים להרגיש כאילו הוכנסו בסוד העניינים, והם מניחים לעתים קרובות שמי שמשתמש במלה "האקר" במשמעות המקורית פשוט לא הבין נכון את האמת הצרופה מהעיתון. לכן, אדגיש שוב: פורצי מחשבים למטרות נזק, ופורצי מחשבים למטרות טובות, אלה גם אלה הם קראקרים. רוב ההאקרים אינם פורצים כלל, והם אנשים טובים התורמים לחברה בדרכים יצירתיות.

שפצור

באנגלית משתמשים לעתים קרובות גם בהטיות של המלה "האקר" לפעלים, שמות-תואר וכו' כדי לתאר שכלולים זריזים או מתוחכמים במיוחד. על-פי הצעתה של חן שפירא השתמשתי במלה "שפצור", "לשפצר" וכו'. אפשר גם להשתמש במלה "שפצר" (משקל בעלי מקצוע) במשמעות זהה להאקר.

תוכנה חופשית

באנגלית, אין הבדל בין המלים חינם וחופשי — שניהם free. בעברית, כמו בשפות רבות אחרות, ההבדל ברור: חינם מתייחס למחיר, חופשי לחוסר הגבלות. באנגלית קיימת, לכן, בעיה קשה להבדיל בין תוכנה חופשית, שמותר להפיצה ולשנותה, ולבין תוכנה חינם. בעיה זו הייתה אחת הסיבות שגרמו לאריק ס. ראימונד ואחרים לשנות את שמה של תוכנת חופשית לתוכנת קוד-פתוח, אבל ישנם רבים המעדיפים עדיין את השם המקורי, משום שהוא מצביע על חוסר ההגבלות כעניין עקרוני.

בעברית אין בעיה כזו. לכן גם אין כל צורך ליצור אותה או לייבא אותה מאנגלית. כדאי, לכן, גם להתעלם מההחלטה התמוהה של האקדמיה ללשון העברית לתרגם את freeware כחופשה.