בזאר (תוכנה חופשית)
- ריצ'רד סטולמן, "פרויקט גנו GNU". תרגום: רביבה טל. בתוך: נאורה ואחרים(2004), "הקתדרלה והבזאר ועוד מאמרים על חופש המידע", הוצאת התעוררות, 2004, עמ' 92-93.
- "נסה!
- "הפילוסופיה של יודה (Yoda, "אין דבר כזה ,נסה,") נשמעת נהדר, אבל אינה מתאימה לי. ביצעתי את רוב עבודתי בזמן שהייתי חרד אם יהיה ביכולתי לסיים את המשימה, ולא בטוח שאצליח להשיג את המטרה גם אם אכן אסיים. אך ניסיתי בכל מקרה, בגלל שבין האויב לבין העיר שלי לא היה אף אחד מלבדי. להפתעתי, מדי פעם הצלחתי.
- "לעיתים נכשלתי; חלק מהערים שלי נפלו. ואז מצאתי עיר מאוימת אחרת והתכוננתי למלחמה נוספת. במשך הזמן למדתי לזהות איומים ולמקם את עצמי ביניהם לבין העיר שלי, כשאני קורא להאקרים אחרים להצטרף אלי.
- "כיום, לעיתים קרובות אינני היחיד. זו הנאה ועונג כאשר אני רואה גדוד האקרים מתחפר להחזיק את הקו, ואני מגלה שהעיר עשויה לשרוד - לעת עתה. אך הסכנות גדולות בכל שנה, וכעת מיקרוסופט שמה את הקהילה שלנו על הכוונת באופן מפורש. עתיד החופש אינו מובן מאליו. אל תקבלו אותו כמובן מאליו. אם ברצונכם לשמור על החופש שלכם, עליכם להיות מוכנים להגן עליו."
- עקרונות הבאזר, מתוך: אריק ס. ריימונד, "הקתדרלה והבזאר". תרגום: עדי סתיו, אלירן גונן, שלומי פיש. בתוך: נאורה ואחרים (2004), "הקתדרלה והבזאר ועוד מאמרים על חופש המידע", הוצאת התעוררות, 2004, עמ' 105-133.
1. כל עבודת תכנות טובה מתחילה בפתרון מטרד אישי של המפתח.
2. מתכנתים טובים יודעים מה לכתוב. מתכנתים מעולים יודעים מה לשכתב ובמה לעשות שימוש-חוזר).
3. תכנן מראש לזרוק ניסיון אחד לפח; בכל מקרה תצטרך לעשות זאת (The Mythical Man-Month, מאת פרד ברוקס, פרק 11). או, אם לנסח זאת אחרת, לעיתים רקרובות אתה לא באמת מבין את הבעיה עד הפעם הראשונה שיישמת פתרון. בפעם השניה אולי תדע מספיק כדי לעשות זאת כמו שצריך.
4. אם יש לך גישה נכונה, בעיות מעניינות ימצאו אותך.
5. כאשר אתה מאבד עניין בתוכנית, משימתך האחרונה היא להעביר אותה ליורש מתאים.
6. התייחסות למשתמשים שלך כמפתחים-מסייעים היא הדרך הקלה ביותר לשיפור קוד מהיר ולדיבוג אפקטיבי.
7. פרסם מוקדם. פרסם תכופות. והקשב ללקוחותיך.
8. אם מספר גדול מספיק של בודקי בטא ומפתחים-מסייעים, כמעט כל בעיה ניתנת לסיווג מהיר והפתרון יהיה מובן מאליו למישהו. או, בצורה פחות פורמלית: "כשיש מספיק עיניים, כל הבאגים הם שטחיים". אני קורא לו "חוק לינוס" [ע"ש לינוס טרובדס, המפתח שהקים את מערכת ההפעלה לינוקס, ב.א.]
9. מבני נתונים חכמים וקוד טיפש עובדים הרבה יותר טוב מאשר בדרך ההפוכה.
10. אם תתיחס לבודקי הבטא שלך כאילו הם הנכס היקר ביותר שלך, הם יגיבו בכך שיהיו הנכס היקר ביותר שלך.
11. הדבר השני הטוב ביותר אחרי להיות אדם עם רעיונות טובים הוא לזהות רעיונות טובים של המשתמשים שלך. לפעמים זה אפילו טוב יותר.
12. לפעמים, הפתרונות המדהימים והחדשניים ביותר באים מהבנה שהדרך שבה תפסת את הבעיה היתה מוטעית.
13. אל תהסס לזרוק תכונות מיושנות כשאתה יכול לעשות זאת בלי אבדן אפקטיביות. שלמות (בתכנון) מושגת לא כשכבר אין יותר מה להוסיף, אלא כשכבר אין יותר מה לקחת. [ע"ע חוק הסכין של ??? ב.א.]
14. כל כלי צריך להיות שימושי בדרך הצפויה, אבל כלי טוב אמת מתאים גם לשימושים שמעולם לא צפית.
15. כשאתה כותב גשר (gateway) מכל סוג שהוא, עדיף לטרוח ולשנות את זרימת הנתונים כמה שפחות - ולעולם לא לזרוק אינפורמציה אלא אם כן הצד המקבל מכריח אותך!
16. כאשר השפה שלך אינה קרובה אפילו לשלמות-טיורינג, Syntactic Sugar יכול להועיל.
17. מערכת אבטחה לעולם אינה בטוחה יותר מהסוד שלה. היזהר מסודות-למחצה.
18. כדי לפתור בעיה מעניינית, מצא קודם כל בעיה שמעניינת אותך.
19. אם למתאם הפיתוח יש דרך תקשורת טובה לפחות כמו האינטרנט, והוא יודע להנהיג ללא כפייה, מוחות רבים הם בהכרח טוב יותר מאחד.
מנהל פרויקט בקוד סגור (קתדרלה) מול מתאם מתנדבים בצוות תוכנה חופשית (בזאר):
- עקרונות הבאזר, מתוך: אריק ס. ריימונד, "הקתדרלה והבזאר". תרגום: עדי סתיו, אלירן גונן, שלומי פיש. בתוך: נאורה ואחרים (2004), "הקתדרלה והבזאר ועוד מאמרים על חופש המידע", הוצאת התעוררות, 2004, עמ' 135-138.
- להגדיר מטרות ולוודא שכולם בפרויקט יהיו ממוקדים באותו הכיוון; להשגיח ולהקפיד על כך שלא מדלגים על פרטים חיוניים. <=> אז איך זה שכ60-75 אחוז מהפרויקטים הקונבנציונאליים לעולם אינם מגיעים לידי השלמה, או שהם נדחים על ידי המשתמשים המיועדים שלהם?
- להניע אנשים לבצע עבודה משעממת אבל חיונית. <=> פיסת תוכנה "משעממת" ברגע שהיא נפתרה סוף-סוף על ידי מישהו שבחר לפתור אותה בגלל עניין בבעיה עצמה. [קל וחומר לגבי בעיה מעניינת ב.א.]. ובתוכנה כמו בכל סוג של עבודה יצירתית - עניין גורם למוטיבציה גבוהה הרבה יותר מאשר הכסף לבדו.
- לארגן את השימוש באנשים כך שתושג יצרנות אופטימלית. <=> האקרים של קוד פתוח מארגנים את עצמם ע"י בחירה עצמית
- להשיג משאבים הנחוצים כדי להמשיך את הפרויקט. <=> המשאב המוגבל היחיד הוא כח אדם מיומן, הרבה יותר זול ואפקטיבי לגייס דרך האינטרנט מתנדבים שבוחרים את עצמם במקום לנהל בניינים מלאים באנשים שהיו מעדיפים לעשות משהו אחר.
משחק כתהליך עבודה
- עקרונות הבאזר, מתוך: אריק ס. ריימונד, "הקתדרלה והבזאר". תרגום: עדי סתיו, אלירן גונן, שלומי פיש. בתוך: נאורה ואחרים (2004), "הקתדרלה והבזאר ועוד מאמרים על חופש המידע", הוצאת התעוררות, 2004, עמ' 138.
- "שוב, קיומה של קהילת הקוד הפתוח מחדד מאוד את הסוגייה - משום שכיף לנו עם מה שאנחנו עושים. המשחק היצירתי שלנו משיג הצלחה טכנית, נתח שוק ונתח ידע בקצב מדהים. אנו מוכיחים לא רק שביכולתינו ליצור תוכנה טובה יותר, אלא גם שאושר הוא נכס.
- "...
- "... אני רוצה להציע את הרעיון כי ייתכן שיש כאן שיור רחב יותר על תוכנה (וייתכן שעל כל סוג שהוא של עבודה יצירתית). באופן כללי, אנשים נהנים מעבודה כאשר היא נותנת אתגר אופטימלי; לא מספיק קל כדי להיות משעמם, ולא קשה מדי להשגה. מתכנת מאושר הוא מתכנת שאיננו, מצד אחד, מנוצל פחות מדי, ומצד שני אינו צריך עלמוד בעומס של מטרות לקויות ובלחצים ובחיכוך הכרוכים בתהליך היצירה. הנאה צמודה ליעילות.
- "התייחסות לשיטת העבודה שלך עצמך בפחד ובתיעוב (אפילו בצורה האגבית והאירונית הנרמזת על ידי תליית קריקטרות של דילברט) צריכה להיות סימן שהשיטה נכשלה. הנאה, הומור ומשחק הם באמת נכסים; לא למען היצירתיות בלבד השתמשתי במילים "המונים מאושרים" למעלה, וזו אינה בדיחה שהסמל של לינוקס הוא פינגווין ילדותי וחמוד.
- "ייתכן מאוד שיתברר בסופו של דבר כי אחת ההשפעות החשובות ביותר של הצלחת הקוד הפתוח היא בכך שלמדנו שמשחק הוא המצב היעיל ביותר של עבודה יצירתית."
