מהי מידת אמינותן של מערכות קוד פתוח?

מהי מידת אמינותן של מערכות קוד פתוח?

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

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

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

בפיתוח קוד פתוח בדרך כלל נמנעים המפתחים מלהשתמש בתהליכים המקובלים מעולם הפיתוח הסטנדרטי של לייצר לכאורה מוצר המבוסס על גישות מוכחות לפיתוח תוכנה איכותית.  להיפך, בפרויקטים בקוד פתוח סביר להניח שלא תמצאו תכנון מפורט של מאמצי פיתוח המשלבים אבני דרך המבוססים על לוחות זמנים נוקשים, תזמונים, ותיעוד ערכות הסיכון. מחקר של 200 פרויקטיי קוד פתוח שנערכו על ידי  Elbaum abd Zhau (3) מראה שמה שכנראה כן תמצאו בתהליך פיתוח קוד פתוח הוא שחרור מהיר של גרסאות בתהליך איטרטיבי, אשר מייצר תהליך פיתוח המשלב שיפור מתמיד של התוכנה על ידי מספר רב של מפתחים אשר תורמים בפיתוח,  שיפורים ותיקוני באגים. מחקר נוסף של 100 יישומים בקוד פתוח אשר נערך על ידי Angelis et al  (4) מצא כי איכות מבנה הקוד של תוכנות קוד פתוח היתה גבוהה מהצפוי בהשוואה עם תוכנות דומות אשר פותחו על יד חברות מסחריות, ושפרויקטים ידועים כמו Apache  ופיתוח ה-Kernel של לינוקס הראו שמספר הפגמים אשר התגלו בתוכנות קוד פתוח היו משמעותית נמוכות יותר מאשר מוצרים מסחריים דומים.

איך מפתחים תוכנת קוד פתוח איכותית וכיצד ניתן למדוד אותה?

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

קהילת משתמשים ומפתחים רחבה ומתוחזקת

קהילות של מוצרי קוד פתוח מורכבות בדרך כלל ממפתחי קוד הליבה, מפתחי מודולים, בודקי איכות המתעדים באגים ומשתמשי הקצה. מודל זה, שמציע שכבות רצופות של סוגי משתמשים ומפתחים במספרים גדלים והולכים, נקרא מודל הבצל (Onion Modle).  צוות קטן יחסית של מפתחי הליבה שולטים על מודולריות המערכת ובדרך יבצע כ-80% של פיתוח הליבה (על פי Fielding et al) (6). מספר גדול בהרבה של מפתחים היקפיים יוסיפו פונקציות חדשות, יתקנו באגים ויבצעו מספר רב של סיקורי קוד עם עמיתים. זוהי גישה אשר הוכחה כבר כגישה  המובילה ליוזמה וחדשנות בזמן קצר ובתהליך המשכי. מספר גדול של חברי הקהילה מתנדבים לקחת חלק בתהליך בדיקה ותיעוד הבאגים ויש להם השפעה גדולה מאוד על צמצום כמות באגים במוצר.  באמצעות תהליך של מריטוקרטיה משתמשים אלה נוטים לעבור בתוך הקהילה לתוך צוות הליבה. קהילת קוד פתוח גדולה ורצינית  צריכה לחרוט על דגלה את עיקרון פתוח קוד במהירות וניפוי יעיל מאוד של בעיות (באגים) וקוד. החוקרים  Angelis et al (4), Raymond (2), O’Reilly (7) and Nakakoji et al (8) כולם מספקים ראיות התומכות בנאמר לעיל.

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

קוד המתועד היטב ומפותח בצורה מודולרית

מודולריות קוד נתמכת על ידי תיעוד טוב ונכון המאפשר למתכנתים להרחיב את המוצר על ידי עבודה על מודולים נפרדים, ללא צורך לשנות או להבין את מערכת הליבה, או להפריע להתקדמות של זה (גישת הobject oriented). זה מקטין את הסיכון של באגים חדשים שהוצגו על ידי הרחבות המוצר ומאיץ הצגות של חדשנות במוצר.  מחקרים רבים של פרויקטים בקוד פתוח, כולל אלה של Fielding et al (9), Cole and Lee (10), Moon et al (11) and Bollinger et al (12) גילו קורלציה ברורה בין מודולריות קוד גבוה למספר נמוך של פגמים בקוד.

תהליך QA

בתהליך פיתוח של תוכנות מסחריות, הקפדה על נהלי בדיקת איכות (QA)היא  חיונית להשגת איכות גבוהה. בפיתוח קוד פתוח, מגוון טכניקות שונות נמצאות בשימוש בכדי להשיג לפחות את אותה האיכות. בדיקות ביקורת של העמיתים בקהילה מיוחסת כסיבת המפתח לאיכותו הגבוהה של הקוד הפתוח. ברור שזה רק חלק אחד מהתמונה, אך זהו חלק מאוד חשוב. ביקורת ובדיקות איכות אפקטיביות המתבצעות על ידי חברי הקהילה מתאפשרות על ידי מחזורי שחרור מהירים של הקוד, דבר המאפיין פיתוח קוד פתוח. Raymond (2) מציע שתגובה מהירה של מפתחי הליבה להערות הקהילה מאפשרת לחברי הקהילה להיות מעורבים מקרוב בתהליך וממריצה אותם להמשיך ולבדוק את הקוד. גישה זו מאפשרת תהליך כתיבת קוד מהירה יותר ובאיכות גבוהה יותר. Gacek and Lawrie (13)  מציינים כי גישה זו אינה יכולה להיות יעליה בסביבה של ארגון מסחרי, אבל זה עובד טוב מאוד כתהליך בדיקה רציפה בשילוב עם מחזורי שחרור מהיר, בסביבה בה אין לחצים ואינטרסים מסחריים.
Elbaum and Zhao (3) מצאו כי תוכניות בדיקה מסודרות, כלי בדיקה מובנים ושיטות QA מקובלות לא נמצאים בשימוש נרחב בפרויקטים של קוד פתוח.

מיחזור הקוד

נראה גם כי מיחזור קוד משמש תפקיד חשוב במספר נמוך של פגם במוצרי קוד פתוח. Conradi et al (14) מצאו כי לקוד אשר מקורו בקוד ממוחזר, יהיו כ-50% פחות פגמים מאשר בקוד אשר נכתב מאפס. רבים ממוצרי קוד פתוח מסתמכים מאוד על רכיבי קוד פתוח קיימים וספריות קוד קיימות מאשר כתיבת פונקציות ותכונות מאפס. רכיבים אלו קיימים כבר כאשר שלבי בדיקות שונות נעשו עליהם בעבר  והוכחו בשימוש בעולם האמיתי.  כפי ש-Kit Palmer מחבר Accuenture כבר ציין, זהו "מחזור דרוויניסטי בו מיטב היישומים (הקודים) שורדים, אלו הלא טובים פשוט יורדים מהמדף".

אז מה הלאה?

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

בעולם של מערכות לניהול תהליכי למידה אין ספק שמוצרי קוד פתוח תופסים תאוצה משמעותית. האקדמיה הייתה בין הראשונות לאמץ מוצרים אלה לתוכה, אלא שבשנתיים האחרונות אנו עדים לעליה משמעותי בקרב ארגונים עסקיים בארץ ובעולם באימוץ מערכות דומות לניהול תהליכי הסמכה והכשרה של עובדים. Moodle הינה אחת המערכות הפופולאריות בתחום אשר נחשבת למערכת אהודה מאוד בקרב ארגונים עסקיים. המידע במאמר זה מחזק את האופן בו מערכת Moodle מפותחת בשילוב של קהילה יציבה מאוד אשר מספר חבריה הולך וגדל בהתמדה. לכן, אין פלא שארגונים כמו Shell, Bank of America, Subaru, Intel, Cisco, British Petroleum, McDonalds, Toshiba, Nikon, Canon, Timberland, Europecar וארגונים רבים אחרים אימצו מערכת זו לתוכם.   

סימוכין

1. M. Aberdour, "Achieving quality in open source software", IEEE Software, vol. 24, no. 1, 2007, pp. 58–64.

2. E. Raymond, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O’Reilly, 2001.

3. L. Zhao and S. Elbaum, “A Survey on Quality Related Activities in Open Source ”, Software Eng. Notes, vol. 25, no. 3, 2000, pp. 54–57.

4. L. Angelis et al., “Code Quality Analysis in Open Source Software Development ”, Information Systems J., vol. 12, no. 1, 2002, pp. 43–60.

5. Succi, Paulson and Eberlein, "An Empirical Study of Open-Source and Closed-Source Software Products ", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, V.30/4, april 2004

6. Mockus, R. Fielding, and J. Herbsleb, “A Case Study of Open Source Software Development: The Apache Server”, Proc. 22nd Int’l Conf. Software Eng. (ICSE 00), IEEE CS Press, 2000, pp. 263–272.

7. T. O’Reilly, “Lessons from Open-Source Software Development”, Comm. ACM, vol. 42, no. 4, 1999, pp. 32–37.

8. K. Nakakoji et al., “Evolution Patterns of Open-Source Software Systems and Communities” Proc. Int’l Workshop Principles of Software Evolution, ACM Press, 2002, pp. 76–85.

9. Mockus, R. Fielding, and J. Herbsleb, “Two Case Studies of Open Source Software Development: Apache and Mozilla”, ACM Trans. Software Eng. and Methodology (TOSEM), vol. 11, no. 3, 2002, pp. 309–346.

10. G. Lee and R. Cole, “The Linux Kernel Development as a Model of Open Source Knowledge Creation”, Haas School of Business, Univ. of California, Berkeley, 2000.

11. J.Y. Moon et al., “Essence of Distributed Work: The Case of the Linux Kernel”, First Monday, vol. 5, no. 11.

12. T. Bollinger et al., “Open Source Methods: Peering through the Clutter”, IEEE Software, vol. 16, no. 4, 1999, pp. 8–11.

13. Gacek and T. Lawrie, “Issues of Dependability in Open Source Software Development ”, ACM SIGSOFT  Software Eng. Notes, vol. 27, no. 3, 2002, pp. 34–37.

14. Mohagheghi, Conradi, Killi and Schwarz, “An Empirical Study of Software Reuse vs. Defect-Density and Stability”, Proceedings of the 26th International Conference on Software Engineering, 2004, pp. 282 – 292

Twitter Digg Delicious Stumbleupon Technorati Facebook

התגובות סגורות.