תחתונים גדולים (XXL ) לאנשי קוד פתוח ..
25 במאי, 2008 | מאת Doron Ofek |כבר כמה ימים שאני מסתובב עם מחשבות על איך לכתוב את הפוסט הזה (יש לי מה שנקרא "תהליכי הבשלה") ..
והאמת שגם עכשיו אני לא בטוח שמצאתי את הדרך הנכונה לומר את מה שאני חושב.
נתחיל עם עיניין הכותרת, זוהי הגרסה העדינה של הכותרת .. הגרסה הלא עדינה היתה "לאנשי קוד פתוח יש ביצים גדולות" ..
והאמת שמי שישאל את עצמו למה אנשי קוד פתוח צריכים תחתונים במידה גדולה – זה פשוט כדי להכיל בתוכן את אותן "ביצים גדולות" .
לא שעברתי ובדקתי את היקף שק האשכים של אנשי קוד פתוח – אלא פשוט אפשר לייחס את הביטוי "ביצים גדולות" כביטוי שמתאר מישהו שיש לו אומץ.
נתחיל עם כך שכאשר אתה משחרר קוד, מסמך, מדריך או כל דבר אחר – אתה בפירוש נחשף לביקורת , לא מעט אנשי קוד פתוח אפילו הגיעו לכך שלא כך דבר שהם כותבים הם מייד חושפים אלא יש את הטענה "זה לא מספיק בשל " ולכן עדיין לא הפצתי את זה (טענה שניתן לקבל אותה) , אך היא גם מגלמת בתוכה את החשש שאולי מה שכתבת הוא לא מספיק טוב .
מעבר לביקורת המהותית שיכולה להיות על משהו שמישהו כתב, כאשר מדובר בקוד (בתוכנה) עשויה להיות ביקרות על עצם בחירת הכלים לכתיבה , ביקורת שאם היא נאמרת בצורה קטלנית – זה פשוט הדבר הכי גרוע שאפשר לעשות למישהו, אך אם היא נאמרת בצורה של ביקורת בונה, הרי שאותו אדם ששיחרר את התוכנה יכול ללמוד מזה, להבין מזה ולדעתי , חשוב מאד לחשוב לפני שנותנים ביקורת.
השבוע במקרה נתקלתי בביקורת של עידו קנר על הבחירה בכלים טכנולוגיים (בעקבות שיחרור מזרים ע"י אילן שביט), הטיעון שמעלה עידו קנר אינו על הקוד אלא על עצם בחירת הכלים לבנייתו.
מן הסתם למי שכתב את התוכנה, ביקורת היא אף פעם לא דבר נעים – אבל עידו (להבנתי) מנסה לעשות זאת בצורה של ביקורת בונה.
אבל לא על זה נסוב מה שרציתי לכתוב, זה רק מהווה דוגמה אחת מיני רבות, שבמקרה קרתה בשבוע האחרון.
אני מניח שרבים יודעים שאני מתעניין / לומד ועובד עם OpenMoko אשר מפיצה (או מתכננת להפיץ) את ה FreeRunner GTA02 למעשה כמו הרבה פרוייקטים של קוד פתוח .. בתחילת הליך הפיתוח נלקחו כלי קוד פתוח שונים ו"הודבקו" ביחד על מנת ליצור את מערכת ההפעלה למכשיר – מערכתזו אכן יצאה עם הדור הקודם של המכשירים (GTA01 ) מה שקרוי Neo 1973 .
אבל אנשי הפרוייקט (הליבה של אנשי הפרוייקט) חוו לא מעט בעיות או קשיים סביב פיתוח קהילתי של כלים שונים – וחלק מהבעיות היו בגלל שהמערכת בכללה היתה מערכת שהודבקה מכלי קוד פתוח שונים.
עכשיו, בפרק הזמן הנוכחי, הסיטואציה היא כזו שפס הייצור מוכן להתחיל לייצר את המכשירים (GTA02 ), הבדיקות השונות עברו כמו שצריך .. ולמעשה נותרה בדיקה קטנה אחרונה. אנשי קוד פתוח רבים בעולם מחכים כבר לשמוע שהמכשירים בדרך אליהם .. ולמעשה ב 3 שבועות האחרונים כל שעתיים נשמעת השאלה "נו מה קורה .. " (בשלל גרסאות שונות) מצידם של אנשי קוד פתוח כלפי צוות הפרוייקט.
כלומר, הפרוייקט בגרסה הנוכחית יושב כבר על פס הייצור , לקוחות , חובבים, ואנשי מקצוע מחכים בכליון עיניים לקבל את המכשירים שלהם , חלקם כבר הזמינו מכשירים וחלקם מתכוונים להזמים ברגע ההכרזה (בתוכם גם אנשים מישראל).
ופתאום , צוות הפרוייקט מגיע למסקנה שבכל מה שקשור למערכת ההפעלה – אפשר היה לעשות עבודה טובה יותר.
נכון, שההחלטה אינה נוגעת לחומרה במכשיר אלא רק למערכת ההפעלה והתוכנות במכשיר.. אבל , באומץ ועם הרבה הרבה ביצים מחליט צוות הפרוייקט לשנות מהותית את כל ה framework ולכתוב ולסדר אותו מחדש ..
הייתרונות שיהיו מכך כמובן הם גדולים, בעיקר בתחום של בניית אפליקציות למכשיר, שיתוף או יכולת לשים אפליקציות מבוססות GTK או QT על המכשיר .. אין ספק שההחלטה היא החלטה נכונה בעיקרה.
אבל, מישהו מכיר חברה מסחרית שעומדת על פס הייצור ומחליטה לשנות את המוצר כי "אפשר היה לעשות את זה טוב יותר " ?
אם זה היה קורה בחברה מסחרית קיניינית רגילה – הרי שכמה מנהלים היו מוצאים עצמם בסוף היום נבעטים הביתה.
בחברה קיניינית רגילה (ואני אישית ראיתי מקרים דומים) , אף אחד לא היה מעלה על דעתו לשנות שינוי מהותי במערכת רגע לפני יציאה לייצור .. יותר מכך היו ממשיכים קדימה ומוכרים את המוצר בידיעה שהוא לא הכי טוב שיכול להיות ושניתן היה לעשות אותו טוב יותר. במקסימום היו מוסיפים מעט לתקציב פרסום על מנת ליצור מומנט מכירתי חזק או להדוף התקפות על המוצר.
אנשי קוד פתוח, נשפטים ע"י המשתמשים בצורה אחרת , ההחלטות שלהם, הדברים שהם מבצעים .. כל אלו יוצרים מציאות אחרת, מציאות ששמה את הלקוח במרכז .
אם בעולם קינייני אני קונה תמונה מצייר כי אני רואה את השכבה העליונה של הציור , בעולם הקוד הפתוח אני רואה גם את הסקיצות ואת כל השכבות שמתחת לשכבה העליונה – אני יכול לבקר את הצייר, להציע לו הצעות וכו' ..
אנשי קוד פתוח צריכים אומץ נדיר כדי לקבל החלטות כאלו , אולי קל מעט יותר לקבל את ההחלטות כאשר הן נוגעות רק לפרוייקט קהילתי – כי אז יכולה להיות ביקורת או טענות מסויימות. קשה יותר לבצע החלטות כאלו כאשר כבר יש השקעה כספית אדירה במוצר שנמצא על פס הייצור ופתאום צריך לקבל החלטה שהיא נכונה טכנולוגית אולם אולי יהיו לה משמעויות בטווח הקצר (העסקי).
ועכשיו אפשר לחזור לכותרת של הפוסט הזה ..
"לאנשי קוד פתוח יש ביצים גדולות"
יום טוב ושבוע טוב לכולם.
***
הבהרה: בעקבות דבריו של עידו, אולי חשוב להדגיש שאני חושב שבחירה בכלי המתאים היא תמיד דבר טוב. היא עושה חיים קלים למפתח , היא מונעת התקפי לב מהמנהל שלו ..
אבל קשה לחיות במציאות של בחירת הכלי המתאים כאשר הליך של פיתוח נמצא רק בראשיתו – ולמעשה אני מניח שהרבה יועצים , תומכים , מפתחים יכולים להעיד על בחירות לא נכונות שנעשו.
אבל , מה שאני מנסה לומר הוא שמרגע שזיהינו שיש כלי לא מתאים – אפשר לשנות את זה, גם אם המחיר לכך הוא כאב ראש לא קטן. בעולם של תוכנה קיניינית, אני אישית מעולם לא נתקלתי בשינוי שכזה שהתבצע בזמן אמת על מנת שלמשתמשים יהיה טוב יותר (תמיד אומרים : "נתקן בגרסה הבאה" .. אגב, לא תמיד עומדים גם בזה) .
- דורון
תגיות: FreeRunner, OpenMoko

11 תגובות עבור “תחתונים גדולים (XXL ) לאנשי קוד פתוח ..”
מאת ik_5 בתאריך 25 במאי, 2008 | תגובה
הביקורת שלי (כבר הרבה שנים ד"א) היא שהרבה מאיתנו בטוחים בכלי שהם משתמשים בו, בלי לעצור ולבדוק הרבה לפני שמתחילים אם יש משהו שיתן תוצאה טובה יותר (דבר ד"א שאני כן מנסה לעשות).
למשל המפתח של vim אמר פעם, שאם יש הרגשה שאפשר לעשות משהו בצורה טובה יותר, אז סביר להניח שיש, רק צריך לחפש. אבל רוב האנשים לא מחפשים, אלא בטוחים שאין משהו טוב יותר, וצריך "לסבול" את מה שיש.
אני אומר כבר כמה שנים טובות שהמקצוע שלי הוא למצוא את הכלי המתאים לתת פתרון ללקוח שלי, ולא לדעת שפת תכנות זו או אחרת. הבעיה היא שרוב השוק לא רואה את זה כך, ואז יש נפילה רצינית. זו בדיוק הבעיה של openmoko. אף אחד לא עצר לרגע לחשוב על "האם הכלי שנבחר (במקרה הזה gtk+) הכי מתאים לביצוע התוצר שאנחנו רוצים לעשות", אלא קודם עשו ורק אז משהו התעורר בצורה זו או אחרת והבין שזה יצר הרבה בעיות, ואם הבחירה היתה שונה, אז לא היו את אותן הבעיות.
ובמקרה שלהם הם פשוט חזרו לשולחן הדירטוטים. במקום לחכות לגרסה 2 כמו הפתרונות המסחריים הקיימים בשוק.
מאת Doron Ofek בתאריך 25 במאי, 2008 | תגובה
1. אני מאד מסכים איתך בנושא של בחירת הכלי .. אבל ..
2. לא תמיד אתה יודע בתחילת התהליך או הפיתוח לאן יוביל הפיתוח .. בעיקר אם מדובר במשהו שהוא קוד פתוח ..
בחברה מסחרית, ניתן אולי לנבא את המשך הליך הפיתוח, במוצר שמבוסס קוד פתוח אתה מוסיף למעשה אלפי ארכיטקטים לצוות שלך.
לבוא בדיעבד ולומר כי ניתן היה לנבא לאן הפיתוח יתקדם – זה אולי קל אבל זה לא תמיד נכון. מה גם שמרבית הפרוייקטים מתחילים כפרוייקטים דלי תקציב ורק לאחר "הוכחת היתכנות" רק אז מתחילה עבודה קצת יותר רצינית מבחינת היכולת להשקיע.
אני לא מנסה לסתור את מה שאתה אומר , אלא אני אומר שהמציאות כמו שאני מכיר אותה היא יותר מסובכת כאשר צריך לקבל החלטות בזמן אמת עם ידיעה חלקית של הנתונים.
גם אני חושב שעדיף תמיד לנסות ולחשוב.. אבל אני גם רואה את תהליכי קבלת החלטות ואני גם מסתכל תמיד על הדברים שקרו על מנת לנתח "האם ניתן היה לעשות את מה שעשינו טוב יותר" .
הגדולה של תחום הקוד הפתוח ושל אנשי הקוד הפתוח הוא שהם יכולים (נאלצים) לקבל החלטות שהם לא תמיד פופולאריות אבל הן נכונות טכנולוגית – דבר שבחברות מסחריות במוצרים קיניינים , לא תמיד קורה.
זה כל מה שניסיתי לומר .

אחלה יום.
- דורון
מאת ליאור קפלן בתאריך 25 במאי, 2008 | תגובה
אני דווקא מעדיף את הכותרת המקורית (:
מאת צפריר כהן בתאריך 25 במאי, 2008 | תגובה
QTopia היה בכלל זמין (מבחינת הרשיון) בשלבי התכנון הראשונים? למיטב זכרוני הרשיון שלו השתנה בערך כשהופיע ה־prototype הראשון. לכן כשחשבו מראש על האפשרויות, השימוש ב־QTopia כלל לא עמד על הפרק.
אגב, יש גם את הדוגמה של מוזילה: הם החליטו על שכתוב המוצר בשנת 1999 והפסיקו לפתח את בסיס הקוד הקיים. במשך בערך 4 שנים לא היה להם דפדפן סביר שגם מפותח. והם איבדו לחלוטין את השוק.
מאת אילן שביט בתאריך 25 במאי, 2008 | תגובה
דורון שלום
אלא אין לי להסכים אם מה שכתבת:
1. pythoncard איננו כלי אוטפימלי ליצור gui (למרות שהוא די נוח וניתן להסתדר איתו די בקלות בכתיבת פרויקטים קטנים).
2. אכן יש לי … גדולות
בסופו של דבר למדתי הרבה מהפרויקט הקטן הזה, ובעיקר למדתי מהעצות ומתרומת הקוד של הקהילה. לאורך כל הדרך התגובות היו מפרגנות, וגם כשהיו ביקורות הן היו בונות (ומהן השכלתי).
לסיום: אינני בטוח שהכלי שעידו מציע: FPC+LAZARUS הוא הכלי האופטימלי למזרים. לדעתי דווקא ג'אווה הייתה מתאימה יותר למשימה (בהיבטים של תלויות ונוחות בפורטביליות)
מאת ik_5 בתאריך 26 במאי, 2008 | תגובה
אילן אני חושש שאתה מספספ משהו. מבחינת תלויות, תוכנה שכתובה בFPC חייבת רק את הספריות שבהם היא משתמשת (קרי GTK). בעוד שגם ג'אווה וגם python, דורשות הרבה תלויות מעבר לספריות האלו, כדוגמת הJAR של ג'אווה והמודולים השונים של פיתון שחייבים להיות מותקנים בצד הלקוח, ולא רק בזמן בניית הקוד.
אתה מסתכל על התלות של מערכת הפיתוח (לזרוס), בתור התלות של התוצר הסופי, דבר שהוא אינו נכון לעשות בגלל שאין צורך בו.
***
דורון, אני חושש שלא הבהרתי את עמדתי מספיק בתגובה שלי, למרות שאמרתי את זה אצלי בבלוג. הרבה פעמים עצם הראייה של המפתחים צרה מאוד. גם אם אתה לא יודע לאן אתה הולך בפרוייקט, אם תשים לב לכל הפרוייקטים שראית, כולם בוחרים באותם כלי פתיחה, שרוב הפעמים מסתברים ככלים הלא נכונים לביצוע המשימה. העניין הוא שזה חוזר על עצמו כל הזמן, ובמקום ללמוד עוד כלים, אנשים נשארים באותם כלים כל הזמן. וזו הבעיה לדעתי.
תזכור, כי כשיש לך פטיש ביד, כל דבר פתאום נראה לך מסמר. זה המצב גם בקוד הפתוח ד"א.
מאת אילן שביט בתאריך 26 במאי, 2008 | תגובה
עידו שלום
ההערה שלך מקובלת (מה עוד שהתחלתי ללמוד פסקל… )
מאת Doron Ofek בתאריך 26 במאי, 2008 | תגובה
עידו .. אני לא כל כך מסכים .. אצלי דווקא, אם יש לי פטיש ביד , כל דבר נראה לי בורג , ואז אני מקלל את עצמי .. למה לעזזל לא לקחתי מברג.

בפעם הבאה אני כבר מביא איתי ארגז כלים שלם .
כל מה שניסיתי לומר בתגובה שלי היא שלא תממיד יש לנו את הכלים בתחילתו של פרוייקט להבין לאן הוא עשוי ללכת. הרי בסופו של דבר תוכנה (כמו כל דבר) היא תולדה של המון צרכים ורצונות, אנחנו יכולים לחשוב שאנחנו צריכים תוכנה קטנה שתעשה X ובסופו של דבר אנחנו מוצאים את עצמנו עם תוכנה ענקית שעושה XYZ – לכן יכול להיות שאנחנו טועים בבחירות הראשוניות שלנו .. מה שכן , יש לאנשים בקוד הפתוח את האומץ לתקן ולא "לחיות עם הטעות".
הדוגמה הכי טובה שיש לי לעיניין (ואני כרגע לא מדבר על הכלים הטכנולוגיים) היא ה kernel עצמו , אם תיזכר במייל הראשוני שלינוס טרובלדס הוציא , אפשר להבין ממנו (אפילו נאמר בו) שה kernel (שלימים נקרא לינוקס) לא הולך להגיע כל כך רחוק בגלל שללינוס עצמו אין את הכלים ליצור ממנו משהו רחב יותר (הוא דיבר ספציפית על תמיכה בדיסקים) .
המציאות הוכיחה שהוא טעה.
כאשר מדובר בפקוייקט קוד פתוח, אין למפתח הראשוני בלעדיות על הכיוון שאליו ימשיך הפיתוח, ה GPL מכתיב שאני ואתה נוכל לקחת את התוכנה ו"להפוך לה את הצורה" .
כלומר גם אם אילן בנה תוכנה לעשות X בעזרת כלי Y , אם היא פתוחה אני ואתה נוכל לקחת אותה, לשנות אותה תעשה Z ואחר כך לשכתב אותה להשתמש בכלים אחרים.
יכול להיות שיהיה וויכוח אם בכלל מדובר באותה תוכנה – אבל זה וויכוח אחר.
מאת Doron Ofek בתאריך 26 במאי, 2008 | תגובה
צפריר,
אתה צודק , QTopia לא היה זמין מבחינת הרשיון באותה תקופה.
אבל אני לא חושב שהם בוחרים ב QTopia ..
אמנם יש / היתה בימים האחרונים תכתובת ערה ברשימת התפוצה ואכן היו מי שפרסמו שיש מעבר מ GTK+2Qt כמו כאן : http://www.osnews.com/story/19764
אבל אני חושב שהשינוי הוא קצת אחר .
לא מדובר במעבר מ GTK+ ל QT אלא בבניה מחדש של ה Framework על מנת שימוך בסביבות שונות .
ראה כאן: http://wiki.openmoko.org/wiki/OpenmokoFramework
וכאן: http://www.vanille-media.de/site/index.php/2008/05/05/openmoko-framework-initiative/
-דורון