לאחרונה קיימנו (פיני כהן ואנוכי) מפגש סיעור מוחות בנושא הקוד הפתוח בישראל.
במפגש זה השתתפו CTOs, ארכיטקטים, יועצים, מובילי דעה, מנהלים טכנולוגיים בתחומים שונים בארגוני משתמשים בישראל.
מטרת המפגש הייתה לבחון מידת ישימות של הקוד הפתוח בארגונים בכלל ובארגונים ישראליים בפרט, להעלות סוגיות המהוות חסם בפני תחום זה, הגורמים המניעים אותו, תועלות, חסרונות וכד'. כמו כן, במפגש ניסינו לעמוד על רמת הבשלות של פתרונות מבוססי קוד פתוח בתחום התשתיתי לעומת התחום האפקליטיבי.
התמונה שעלתה במפגש היא שתחום הקוד הפתוח כבר די נפוץ באזורים מסוימים (כדוגמת תחום מערכות הפעלה לשרתים ותחומים תשתיתיים נוספים אותם נפרט בהמשך), לעומת תחומי אפליקציות ארגוניות (ERP, CRM, BI, WCM וכד') בהם עדיין נדיר למצוא כלי קוד פתוח מיושמים בארגוני Enterprises.
מסר חשוב שעלה מהמפגש הוא שלא ניתן ולא כדאי להתעלם מאופציית השימוש בקוד פתוח בהרבה מתחומי העשייה ב-IT (בהמשך הסיכום נתייחס לתחומים בהם ארגונים ציינו כי לא ישתמשו בקוד פתוח והסיבות לכך). מוצרי קוד פתוח בתחומים מסוימים מתחילים להיבחן על אותה סקאלה של בחינת כל מוצר אחר, עם דגשים אופייניים לתחום זה – לדוגמה, סוגיות משפטיות.
עם זאת ברצוננו לציין שרובם המכריע של ארגוני ה- enterprise מתייחסים למוצרים מתחום הקוד הפתוח כמו שהם מתייחסים למוצרים אחרים שאינם מתחום הקוד הפתוח. הארגונים בוחנים את בשלות המוצרים, את מידת התמיכה, מידת ה- certifications השונים , כלי צד שלישי שתומכים במוצר וכד'.
ברוב רובם של הארגונים אין התייחסות למימד ה"פתוח" של מוצרים הן בהקשר של "תמיכה פתוחה" – תמיכה שמסתמכת על הקהילה והן בהקשר של "קוד פתוח" – אפשרות לפתח את המוצר על ידי הוספת קוד המשפר את המוצר ה"פתוח" שהתקבל מהקהילה. פיתוח שבסופו של דבר עשוי לחזור לקהילה. על פי התנהלות המפגש, הגורמים היחידים שמוכנים לשקול את הצד "הפתוח" במוצרים הם ארגונים שהם יצרני תוכנה בעצמם.
המצב הכלכלי דחף ארגונים לשקול מודלים חדשים של מחשוב אשר מבטיחים עלויות השקעה נמוכות ובתוך כך גם מודל הקוד הפתוח. אולם ארגוני Enterprises עדיין די מבולבלים באשר למוצרי קוד פתוח ושאלות רבות מתעוררות.
להערכתנו, על מנת שהמודל יאומץ בישראל על ידי ארגונים, יצטרכו להתקיים כמה תנאים חשובים וביניהם: SLA ותמיכה מארגונים גדולים בעלי חוסן פיננסי, מודעות ובהירות גדולה יותר באשר לסוגיות המשפטיות, ידע באשר לאופציות הכלים הקיימים.נקודה רלוונטית נוספת היא שבארגוני פיתוח ישנם מקרים שבהם המתכנתים מעתיקים קטעי קוד פתוח בעצמם – קוד פתוח המבצע משימות סטנדרטיות (הכפלות מטריצות, מיונים וכד'). נכון להיום נקודה זו נבדקת (סריקת קוד לאיתור קוד שכזה) על ידי ארגונים מעטים בלבד.
מסר חשוב שעלה מהמפגש הוא שלא ניתן ולא כדאי להתעלם מאופציית השימוש בקוד פתוח בהרבה מתחומי העשייה ב-IT (בהמשך הסיכום נתייחס לתחומים בהם ארגונים ציינו כי לא ישתמשו בקוד פתוח והסיבות לכך). מוצרי קוד פתוח בתחומים מסוימים מתחילים להיבחן על אותה סקאלה של בחינת כל מוצר אחר, עם דגשים אופייניים לתחום זה – לדוגמה, סוגיות משפטיות.
עם זאת ברצוננו לציין שרובם המכריע של ארגוני ה- enterprise מתייחסים למוצרים מתחום הקוד הפתוח כמו שהם מתייחסים למוצרים אחרים שאינם מתחום הקוד הפתוח. הארגונים בוחנים את בשלות המוצרים, את מידת התמיכה, מידת ה- certifications השונים , כלי צד שלישי שתומכים במוצר וכד'.
ברוב רובם של הארגונים אין התייחסות למימד ה"פתוח" של מוצרים הן בהקשר של "תמיכה פתוחה" – תמיכה שמסתמכת על הקהילה והן בהקשר של "קוד פתוח" – אפשרות לפתח את המוצר על ידי הוספת קוד המשפר את המוצר ה"פתוח" שהתקבל מהקהילה. פיתוח שבסופו של דבר עשוי לחזור לקהילה. על פי התנהלות המפגש, הגורמים היחידים שמוכנים לשקול את הצד "הפתוח" במוצרים הם ארגונים שהם יצרני תוכנה בעצמם.
המצב הכלכלי דחף ארגונים לשקול מודלים חדשים של מחשוב אשר מבטיחים עלויות השקעה נמוכות ובתוך כך גם מודל הקוד הפתוח. אולם ארגוני Enterprises עדיין די מבולבלים באשר למוצרי קוד פתוח ושאלות רבות מתעוררות.
להערכתנו, על מנת שהמודל יאומץ בישראל על ידי ארגונים, יצטרכו להתקיים כמה תנאים חשובים וביניהם: SLA ותמיכה מארגונים גדולים בעלי חוסן פיננסי, מודעות ובהירות גדולה יותר באשר לסוגיות המשפטיות, ידע באשר לאופציות הכלים הקיימים.נקודה רלוונטית נוספת היא שבארגוני פיתוח ישנם מקרים שבהם המתכנתים מעתיקים קטעי קוד פתוח בעצמם – קוד פתוח המבצע משימות סטנדרטיות (הכפלות מטריצות, מיונים וכד'). נכון להיום נקודה זו נבדקת (סריקת קוד לאיתור קוד שכזה) על ידי ארגונים מעטים בלבד.
יתרונות מוצרי קוד פתוח (כפי שעלו מהדיון):
להלן מספר יתרונות כפי שעלו בדיון. מדובר על יתרונות אפשריים בתחום – לא על יתרונות שקיימים בכל המקרים.
- חדשנות, גמישות
- סקלביליות ומחיר – בניגוד למוצרים מסחריים, הגידול בשימוש אינו מחייב גידול במחיר. במידה וארגון משתמש בפתרון קוד פתוח שהותאם לארגון מבחינה פונקציונלית ומבחינת תמיכה, גם אם יהיה שימוש נרחב יותר לא תידרש תוספת תשלום.
- פשטות
- נושא השליטה – בעקרון, אין חברה אחת ששולטת בקוד אלה הקהילה. כאשר רוכשים "חברת קוד פתוח" (דבר מאוד פופולארי לאחרונה) רוכשים למעשה את גוף התמיכה. כאשר במקביל יכולים לצוץ גופי תמיכה אחרים, גם אם לא זהים לגמרי. למשל, CENTOS בתחום לינוקס ו- mariaDB בתחום מסדי נתונים. כאשר הקוד ממשיך להיות מפותח לפי ה- open process המקובל.
- הסכנה שמוצר OS מצליח ייעלם קטנה. הקוד עצמו שנכתב "נתרם" על ידי אנשים, וזה מעוגן משפטית. אבולוציה – "המוצר החזק שורד". בOS צריך "להמר" על איזה מוצר חזק מספיק כדי לשרוד, איזה מוצרים מקבלים יותר תשומת לב לעומת מוצר ש"נזנחים". אחת מהשיטות המעניינות שצוינו לצורך כך - להתחבר ל mailing list כדי לראות מה פעיל ומה לא פעיל (מה שגם מראה שחשוב להיות מעורבים ו"חלק מהקהילה").
- נטען כי כשהפוקוס של ארגון הוא שירות ולא רישוי (כפי שאכן קורה בארגוני קוד פתוח), השירות הנו הרבה יותר טוב. חברות שמוכרות מוצר קנייני - לכאורה פחות אכפת להן לתת שירות טוב.
- במוצרי קוד פתוח קיימות בדר"כ 2 גרסאות – גרסת Community שהיא חינמית, וגרסת Commercial שהנה בתשלום. העובדה שלמוצר OS מסחרי קיימת גם גרסת Community מאפשרת תמיד לראות מה יתפתח הלאה בגרסאות הבאות. כמו כן, מאוד קל לבחון את המוצר בפועל, ניתן לעבוד עם המוצר הקהילתי שנה-שנתיים, ואם רוצים - לקנות אח"כ את הגרסה המסחרית.
- INNOVATION BY INTEGRATION – לחברה שמפתחת מוצר אין יתרון תחרותי לפתח הכל בעצמה. היא לוקחת רכיבים שונים ומחברת, וזה היתרון / החדשנות שהיא מציעה. כל חברה מתרכזת במה שהיא עושה הכי טוב. (זוהי אחת הסיבות שקוד פתוח הרבה פעמים מוזכר באותה נשימה עם תחום ה Cloud/SaaS שגם כן מאפשרים לחברות להתרכז בmain business שלהן). לדוגמה, צ'קפוינט כוללת הרבה רכיבי OS במוצר, BING של מיקרוסופט מבוסס על תשתית STORAGE OS וכד'.
- העובדה כי במודל ה-OS קיימת ליבה וסביבה כל אחד (היצרנים עצמם) מפתחים הרבה דברים משלימים. משמעותה שהמוצר המתקבל הרבה יותר קרוב לצרכים של צרכני הקצה
- כשל שוק: השוק הישראלי מאוד מושפע מספקי ה-IT, ובמיוחד הספקים הגדולים. ארגונים ישראלים אינם חשופים לפתרונות קוד פתוח במידה רבה משום שאותם ספקים\אינטגרטורים אינם חושפים אותם לפתרונות אלה בתשובות על מכרזים וכד'. הועלתה התלבטות באשר למחויבות של ממשלת ישראל לנושא, והאם עליה לדרוש בחינה של לפחות מוצר קוד פתוח אחד בבחינת כלל מוצרים לתחום מסוים. באופן כללי, האינטגרטורים לא מספיק מכירים את מוצרי קוד פתוח, וכך קורה שאם הארגון לא רואה את הפוטנציאל בעצמו ודוחף זאת אקטיבית, הוא בדר"כ כלל לא חשוף לאופציה – וזו בעיה שעוצרת את השוק מלהתפתח. בעיה נוספת שמקשה ומרתיעה אינטגרטורים היא שבקוד פתוח האינטגרטורים יותר חשופים כי הלקוחות יכולים לבצע code review אמיתי.
- מחסור בכ"א – בחלק מעולמות התוכן אין הרבה אנשי קוד פתוח בישראל – לדוגמה, PHP בישראל, וכל מערכי ההכשרה לתחום זה פחות נפוצים.
- אחת החששות של ארגוני ENTERPRISE – השקט הנפשי. ארגונים רוצים לדעת שגם אם עוד 7 שנים אני אחפש תמיכה לא תהיה בעיה למצוא אותה. להערכת אותם ארגונים האפשרות לקבל תמיכה בטווח הארוך גדולה יותר במוצרים מסחריים מאשר במוצרי קוד פתוח.
- הנושא החוקתי משפטי- מה מותר ומה אסור? איך מעגנים חוזית בצורה הכי בטוחה מבלי לחשוף את עצמם לעניין תביעות? יש חברות שכבר יישמו מדיניות קוד פתוח. במוצרים פנימיים ארגונים ציינו שאין סוגיות בעייתיות, וישנן דוגמאות לחברות שלוקחות אחריות על נושא זה – לדוגמה, RED HAT נותנת לארגון שרוכש לשימוש פנים ארגוני LEGAL ASSURANCE, ואף נותנים ללקוח קוד חליפי אם יש תביעה. אם יש תביעה מגלגלת את האחריות אליה. יש הרבה כסף בצד שמיועד למקרי תביעות. לעומת זאת, במוצרים חיצוניים (המכוונים כלפי לקוחות הארגון) - כדאי להתייעץ עם יועץ משפטי. מסוכן להיכנס לקוד פתוח בלי להתייעץ עם ה LEGAL בייחוד ליצרני תוכנה כי יש חברות שפשוט מעתיקות קוד ומהצד השני יש חברות (בעיקר משפטנים) אשר מחפשים שימוש לא חוקי בקוד פתוח ומבצעות תביעות.
- שאלה נוספת שעלתה - איך מנהלים נכסי קוד פתוח שאין להם ערך כספי – בספרים? והאם בכלל מנהלים?
בפוסטים הבאים נדבר על פתרונות קוד פתוח שעלו במפגש (אשר בהם משתמשים ארגונים בישראל).
אין תגובות:
הוסף רשומת תגובה