פרק מספר 365 (מספר קוסמי!) של רברס עם פלטפורמה - קרבורטור מספר 26: אורי ורן מארחים את נתי שלום (היזם של חברת Cloudify) לשיחה התקופתית על קוד פתוח, עננים, תשתיות ואירועים מהתחום מהזמן האחרון.
קצת רקע להיום: ב - 11 למרץ 2019 פורסמה הודעה של AWS על התאגדות משותפת עם מספר חברות (בינהן Expedia ו-Netflix), על מנת לקחת מוצר בשם Elastic Search (חברה שהיזם שלה ישראלי, תזכורת לפרק 362 עם אורי כהן, וגם התגובה של שי בנון המייסד) וליצור עבורו מודל הפצה חדש (Re-distribution), מה שמרעיד את אמות הסיפין בתחום ומעורר לא מעט שאלות.
- נתי גם אמר את זה קודם . . .
- הנושא הציף קודם כל את הבלבול שקיים סביב המודל העסקי של חברות קוד פתוח והאופן שבו הן מייצרות רווח - נכון עבור Elastic אבל באותה מידה גם עבור Redis או GitHub וכו’.
- כל המוצרים של החברות הללו מגיעים מחברות ממומנות ולמטרת רווח ישיר, בשונה למשל מפרויקט כמו Kubernetes, שגוגל מעודדת על מנת לעודד צריכה של Google Cloud (ומשם לייצר רווח “משני”).
- יש מספר דרכים לרווח ישיר ממוצר קוד פתוח -
- רישיון שימוש (Subscription license)
- שירות כ-SaaS (ותשלום לפי צריכה)
- שירות מנוהל (Managed Service) - דומה ל-SaaS, רק שיש אפשרות גם להריץ בעצמך
- תשלום על תמיכה ו-Extra Features
- נקודה עדינה, כי יש גבול דק שקל לעבור ולהפסיק להיות “באמת” קוד פתוח.
- כל ה-API למפתחים חייבים להיות פתוחים, אבל תחומים של Clustering או Security למשל כבר נחשבים כ”איזורי מוניטיזציה” - זה כבר לא POC או פיתוח אלא שימוש משמעותי שמצדיק תשלום.
- ההבדל המשמעותי לעומת “קוד סגור” הוא היחס שבין הספק ללקוח - צריך לשלם, אבל לא מיד ברגע שנוגעים במוצר אלא רק כשיש ערך ברור.
- חשוב לשים לב שגם צד הלקוח מעוניין הרבה פעמים בתשלום כלשהו עבור שימוש משמעותי - יוצר מחוייבות לתמיכה (או לפחות תחושה כזו) ואומר שיש מישהו מאחורי המוצר שיכול לתמוך במקרה הצורך.
- זו מערכת מבוססת אמון (Trust system) - ויש מגוון סוגי רשיונות שמגדירים מה מותר לעשות עם החלק הפתוח (החינמי)
- הרשיון “המתירני” ביותר נקרא Apache 2.0, שמאפשר כמעט הכל (כולל re-distribution) והרבה ארגונים משתמשים בו, גם מתוך חשש מרישיונות כמו GPL למשל, שאומר שאם מבצעים שינוי בקוד חייבים לשתף גם אותו (מה שעשוי להיות קשה לשליטה ובעייתי באופן כללי לארגונים גדולים).
- למיטבי לכת (ושמע) - היה פרק שלם גם על זה עם עו”ד(!) דביר גסנר (ב-2012, ועדיין), ועוד אחד על רשיונות קוד פתוח (פרק 211 מ-2014), וגם זהר זקס הרחיב על הנושא בפרק 317 על Zusammen. הרבה שיעורי בית.
- בשורה התחתונה - חברות פחדו ממצב בו מפתח בודד יעשה שימוש בקוד עם רישיון שמעבר ל-Apache 2.0 (או MIT License שהוא די מקביל) ויחייב את החברה לשיתוף שהיא לא יכולה לעמוד בו.
- השוני הגדול הוא בעיקר בזכויות ההפצה (Re-distribution) ושימוש כ-SaaS.
- העיקרון הבסיסי הוא שהפרויקטים הללו דורשים הרבה מאוד השקעה, חדשנות וטכנולגיה, ועומדות מאוריחהם חברות גדולות שבסופו של דבר צריכות מודל עסקי על מנת להתקיים ולהרוויח (ולהנפיק…).
- לא צריכה להיות סתירה בין זה לבין טובת המשתמש, שעדיין נהנה ממוצר באיכות מאוד גבוהה בחלק הפתוח
- שונה מפרוייקטים שמבוססים לחלוטין על תרומות קוד של משתמשים, מה שעובד לרוב רק כשיש חברות שמאגדות את הפרוייקט על מנת להפיק ערך באופן אחר (שוב - דוגמת Kubernetes ו-Google).
אז בחזרה לשאלה המקורית - למה רעדו אמות הסיפין?
- המרכיב הראשון הוא עניין האמון - ברגע שיש שימוש משמעותי במוצר צריך להתחיל לשלם. מה זה “משמעותי”? בדיוק . . .
- אם אני עושה שימוש משמעותי בקוד הפתוח, אבל גם מאפשר להשתמש בו בחינם (או לקבל תמיכה בחינם וכו’), נוצרת פגיעה בחברה שפיתחה את הקוד, ולא נהנית מרווח בשלב בו הוא הופך ”לגיטימי”
- אם נוסף על כך את העובדה שזה קורה בפרויקט שבו לא תרמתי למוצר מלכתחילה, ורק אפשרתי שימוש משמעותי בחינם - נוצר משבר אמון עמוק.
- אז AWS.
- משמעות ההודעה של AWS היא שעבור מוצרי קוד פתוח שהם לא באמת תרמו לפיתוחם, הם חותכים את קווי המוניטיזציה - על מנת להנות מהשימוש הרב בהם (להנות מהרווח הנגזר מהשוק שגדל, בלי להשקיע בשלב הראשון של יצירת ופיתוח השוק).
- נותנים שירות ותמיכה לחלק החינמי של השירות - ובפועל מתחרים בחברה המפתחת על התמיכה במוצר (החינמי) שלה, אותה תמיכה שהרווח הפוטנציאלי ממנה היה הבסיס והתמריץ לפיתוח.
- הדרך של החברה להגיע למשתמשים הייתה, למשל, לאפשר שירות במודל SaaS על התשתיות של AWS (שמרוויחה כבר בשלב הזה, אבל זה ממודל אחר), ולהרוויח מתמיכה. בשלב הזה נכנסת AWS שוב, ומתחרה בחברה המפתחת על תמיכה במוצר הקוד הפתוח שלה.
- מעבר ל- Elastic Search היו מקרים דומים גם עם MongoDB ו - Redis, וגם עם InfluxDB - שהגיבו ע”י שינוי מודל הרשיונות שלהן. יש הרבה דוגמאות כאלה עם AWS, שמאוד עקבית במדיניות הזו.
- התגובה הסטנדרטית של AWS במקרים כאלה היא שהם רוצים לתת שירות טוב יותר למשתמשים - ועבור הלקוחות יש לכאורה שירות יותר טוב במחיר יותר נמוך.
- האם באמת יש כאן Win-Win? שאלה טובה, נחזור אליה.
אז הכל היה כבר קודם - מה קרה עכשיו ששונה?
- נחזור לכותרת של הפוסט - “Keeping Open Source Open – Open Distro for Elasticsearch”
- נכתב ע”י Adrian Cockcroft, ארכיטקט Cloud ב-AWS, בעבר גם ב-Netflix, ביקר בארץ באמצע מרץ (Keynote speaker ב- AWS Summit 2019, אפשר גם להשלים בוידאו).
- מאז היו עוד פרסומים.
- נתפס כמעיין “הרצחת וגם ירשת?” . . . יש כאן מתקפה על חברות הקוד הפתוח בטענה שהן לא באמת מספקות קוד פתוח (כי הן מרשות לעצמן לרצות להרוויח), והצגה של AWS ככזו (בזמן שרוב המוצרים שהיא מפתחת בעצמה אינם בקוד פתוח כלשהו).
- הטענות שעולות בפוסט הן ש-Elastic במשך הזמן הוסיפו סעיפים שהופכים את הקוד ללא באמת פתוח, יחד עם הדוגמא של Java (סיפור ה-End of Life מבחינת אורקל, כש-AWS “ראו את טובת המשתמשים” והחליטו להמשיך ולתמוך).
- בשורה התחתונה - לא רק לקחו “פרי בשל” של חברה אחרת, אלא גם הטיפו מוסר. אין כאן שום דבר לא חוקי, אבל נראה לא משהו בכלל.
- הסכנה לטווח הארוך היא פגיעה בשוק הקוד הפתוח לטווח הארוך - משקיעים מתחילים לשאול איך (ואם בכלל) אפשר למנוע מ-AWS לעשות מהלכים כאלה בעתיד?
- התשובה הפשוטה - להשתמש ברשיונות פחות פתוחים
- רואים את זה כבר עם Elastic ועם MongoDB, שמתחילות להגן על עצמן מפני הפרות אמון כאלו, מה שהופך את הדיון לכללי יותר, עבור כלל התעשייה: איך בונים יחסים של Win-Win בין ספקי הקוד הפתוח לספקי תשתיות הענן (Cloud Providers)?
- האם הכיוון הוא חרם צרכנים? - מי בדיוק יחרים? . . .
- אם חברות הקוד הפתוח לא ישתמשו ב-AWS, הם יעשו את זה בעצמם. נראה ש-AWS מפסידה בעצמה כי ככל שיותר חברות קוד פתוח ישתמשו בתשתיות של AWS כך היא תרוויח.
- זו לא באמת שאלה של מי צודק, אלא שאלה של טובת הצרכן לנוכח ניגוד האינטרסים.
- שווה לשאול מה קורה עם מוצרים שאינם קוד פתוח - תוכנות Microsoft למשל.
- כאן ב-AWS ידעו למצוא מודלים של Win-Win עבור כל הצדדים
- לכאורה ההבדל היחיד הוא שבמקרה של קוד פתוח יש פירצה משפטית (או מערכת מבוססת אמון) שמאפשרת לעקוף את זה, וניצלו אותה.
- יכול להיות שהדרך היא להסתכל באותה צורה גם על חברות קוד פתוח וגם על חברות “מסורתיות” (ראה מקרה Oracle).
- ההבדל הוא שבמקרה של קוד פתוח, AWS לכאורה מספקים את השירות בחינם (הם עדיין מרוויחים על התשתיות).
- כל זאת - בזמן שעל AWS רצים יותר שרתי Windows מכל מערכת אחרת (ע”פ Adrian Cockcroft ב-AWS Summit בתל אביב), וכולם מרוויחים יפה.
- בזמן שעל Azure רצים עם Linux . . .
- כל ההבדל הוא הפירצה, והיכולת לנצל אותה.
- אין משקיע שישקיע בחברה ללא כל סיכוי לרווח כלשהו. המודל אינו התנדבות מלאה (לא מודל בר-קיימא בכל אופן).
- זה בסדר להשתמש בקוד פתוח ולא לשלם, וזה אכן נכון ל-90% מהמשתמשים. השאלה מה קורה כשמגזימים.
- אם למשל Outbrain משתמשים ב-Hadoop בלי לשלם (לשימוש פנימי), זה כנראה בסדר - כי הם לא מוכרים את המוצר, ולא מתחרים ביצרן - וזה גם כנראה נלקח בחשבון במודל העסקי של היצרן.
- זה לא המקרה עם AWS, וזה ההבדל הגדול - זה לא שימוש פנימי אלא תחרות ביצרן: הצעה של חלקים גדולים מאותו שירות לאותו בסיס לקוחות, עם התשתיות האדירות של AWS ובלי הוצאות (וסיכוני) הפיתוח.
- המעניין הוא ש Adrian Cockcroft מתייחס לזה, וטוען ש-AWS עושה שירות טוב ליצרני הקוד הפתוח, בכך שהיא מעניקה מעיין “חותמת כשרות” למוצר (ותורמת לעלייה משמעותית בשימוש בו).
- צודק - החברות אכן לא נפגעו כלכלית בשורה התחתונה, לפחות כרגע
- פחות - אם כל ספקי הענן יתנהגו כמו AWS, חברות כבר ל יוכלו להיבנות על פי אותו מודל עסקי שעליו נבנו Elastic ודומיה (מי ישקיע בזה בכאלה תנאים?), והשוק יתייבש. בראייה ארוכת טווח זה כבר לא טוב גם למשתמשים של AWS.
- אם מסתכלים על חברות ענן באופן כללי, נראה שיש הבנה והכרה בערך של קוד פתוח -
- רואים את זה מ-Google כבר לאורך הרבה זמן, ו-Microsoft בשנים האחרונות (כולל הרכישה של GitHub), יחד עם מלחמת Android-IOS התמידית
בסך הכל, שנת 2018 הייתה טובה מבחינת ההכרה בערך חשיבות הקוד הפתוח - ההנפקה של Elastic, הרכישה של GitHub, הרכישה של Red Hat, ועוד.
- אין (או לפחות לא אמור להיות) קונפליקט בין הצורך של המשתמש לבין היות המוצר פתוח - אנחנו לא רוצים להינעל על ספק, ולא רוצים לעבוד עם קופסאות שחורות.
יצא פרק קצת פוליטי (לכבוד הבחירות?!), אבל אנחנו אופטימיים 
אין תגובות:
הוסף רשומת תגובה