קוד פתוח == חינם?

קוד פתוח == חינם?

Print Friendly, PDF & Email

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


תוספת מאוחרת:

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


 על אימוץ קוד פתוח במגזר הבנקאי בחו"ל:

https://bbvaopen4u.com/en/actualidad/banks-starting-embrace-open-source-finance-and-hackathons-innovate

מאמרו של ברוס שנייר על חשיבות השקיפות בקוד הפתוח למניעת הונאות בעקבות פרשת פולקסווגן:

https://www.schneier.com/blog/archives/2015/09/volkswagen_and_.html

חלק מהספר "הקתדרלה והבזאר" על ההבדלים שבין פיתוח מסורתי לקוד פתוח:

http://www.isoc.org.il/internet-il/articles-and-research/magazine/the-cathedral-and-the-bazaar

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

https://www.quora.com/Is-open-source-more-secure-than-proprietary-software

 

השאר תגובה