.jpeg)
?איך להיעזר בזרים מוחלטים לטובת שיפור המוצר שלך תוך תרומה לאנושות
אני נשאל באופן קבוע "מה להוציא לקוד פתוח?" כאשר לטעמי השאלה שיש לשאול היא "מה לא להוציא לקוד פתוח?"
רבים יגידו שזו גישה מוזרה. אחרי הכל, כשאתה פותח עסק אתה משקיע הרבה זמן, כסף ונשמה בפיתוח המוצר שלך, למה שתחשוף חלקים מהקוד לציבור הרחב? למה לתת להם את פירות המאמץ שלך בחינם?
ידעתי שיש הרבה ערך לקוד פתוח, אבל לא הייתה לי דעה נחרצת בנושא או מדיניות ברורה עד שקראתי מספר מאמרים בנושא שעשו לי סדר בראש בנוגע לנושא הזה. למשל המאמר הבא:
I thought I understood Open Source. I was wrong של לורנזו סקיאנדרה שכלל את הציטוטים הבאים: (בתרגום חופשי מאנגלית)
"תראה, בניתי את זה - אם אתה רוצה גם להשתמש בזה, הנה איך לעשות זאת. עשיתי את זה בדרך שתתאים לצרכים שלי אבל אתה יכול להשתמש בזה כרצונך."
"אם אתה משתמש בפרויקט בקוד פתוח, הרי שנהיית אחד מהמפתחים שלו. פעל בצורה ההולמת את העובדה הזאת."
?אז מה לא להוציא לקוד פתוח
את הלוגיקה עסקית (Business Logic) של המוצר המייחדת את המוצר שלך ממוצרים אחרים כדאי להשאיר לעצמך. פתיחתו לעולם תעזור בעיקר למתחרים הישירים שלך. אפילו מומלץ להשתמש בכלים כמו Jscrambler שיהפכו אותו לקוד קשה לפיצוח.
?מה להוציא לקוד פתוח
כדאי להוציא את החלק הגנרי של המוצר: מדובר בדרך כלל על כ- 50% ויותר מכלל הקוד. החלק הזה כולל בדרך כלל כלים, עזרים ומערכות כלליות שפותרים בעיות ספציפיות ויכולים להיות שימושיים למפתחים שונים, ולעבוד עם מוצרים שונים ומשונים. כל אלו עדיף שיהיו בקוד פתוח לטובתך ולטובת המוצר.
?מה הערך של הוצאת החלקים הגנריים של הפרויקט לקוד פתוח
● דיווחים על בעיות וחוסרים- עשרות, מאות ולפעמים אפילו אלפי אנשים יריצו את הקוד שלך בכל מני תנאים, סביבות ומקרי קצה ויגדילו את הסיכויים שבאגים יימצאו וידווחו במהרה, עוד לפני שהם ישפיעו על המוצר שלך.
● חלק קטן מהמשתמשים יתרמו לפרויקט- תיקוני באגים, פיצ'רים, טסטים, רעיונות.
● מודולריות- כשפתרון לבעיה מסוימת נמצא במקום מנותק לגמרי מהמוצר שלך ואפילו מצהיר שמטרתו לפתור את הבעיה באופן כללי, מי שעובד על הקוד יכתוב קוד לא מצומד (coupled) ללוגיקה העסקית של האפליקציה ובכך הרבה יותר סביר שהפתרון לא יגרום לבאגים במקומות לא צפויים במערכת הראשית או יפסיק לעבוד כשיהיו שינויים במערכת הראשית.
● מוניטין- חברות המנהלות פרויקטים בקוד פתוח מפתחות מוניטין מעולה בקרב קהילת מפתחי התוכנה, וזוהי דרך מצוינת למשוך מתכנתים טובים.
?יש דוגמאות לחברות שעשו זאת
יש הרבה. מדובר בטרנד מאוד חשוב בשוק.
פייסבוק מפתחת את ריאקט בקוד פתוח. היא משתמשת בו עבור כמעט כל המוצרים שלה. לא מזמן היא הורידה אפילו את ההסתייגות הקטנה שהייתה להם בנוגע להרשאות השימוש בריאקט וספריות הנלוות אליו בנוגע לפטנטים היות והם קיבלו החלטה אסטרטגית שעדיף להם לוותר על השליטה המעטה שהייתה להם במי משתמש בכלים הללו לטובת הגדלת כמות המשתמשים והקהילה סביב הכלים.
בחברה שבה אני עובד (וול דאן פתרונות תוכנה) עושים את זה כבר שנים עם כמעט 90 פרויקטים. לספוטיפיי יש מעל 200 פרויקטים ולנטפליקס כ- 150.
למעשה, חיפוש אחר כל שחקן גדול בשוק התוכנה יניב כמות גדולה של קוד פתוח שנכתב בחלקו או במלואו על ידי השחקן. זה לא אומר שכל הפרויקטים הללו מטרידים את המפתחים שלהם באופן יומיומי.
?זה לא דורש יותר מדי תחזוקה ומאמץ לטובת אחרים
זה נכון שקיימת תרבות מסוימת של מפתחים שמרגישים שמתחזקים חייבים להם משהו, אבל האמת היא שאין לאף אחד זכות לדרוש שתעבוד על משהו שלא מעניין אותך.
:כשמישהו פונה אליך בנוגע לפרויקט פתוח יש לך כמה אפשרויות
● אתה יכול לתקן/לשפר את הקוד - במקרה כזה אתה מרוויח מזה שמישהו גילה לך שיש בה בעיה.
● אתה יכול להסביר איך מי שפנה אליך יכול לעשות את זה בעצמו - במקרה כזה אתה יכול להרוויח שיפור לקוד על ידי מישהו אחר.
● להתעלם מהבקשה שלו לגמרי. אתה לא חייב לענות לאף אחד - במקרה כזה קבלת אינפורמציה חדשה בנוגע לקוד שיום אחד יכולה להיות בעלת ערך בשבילך.
יש מי שאכן מרגיש שהוא עובד עבור אחרים ומתחזק כלים כי הוא חייב למישהו, או בשביל מוניטין שנוצר לחברה אם היא לא מתחזקת קוד - הכל עניין של גישה. לדעתי, חברה שלא מתחזקת קוד פתוח מסויים לא צריכה להתבייש בשום דבר וזה עניינה בלבד. הייתי רוצה שכולם יתייחסו לזה ככה. אני מאמין שיחס כזה יגדיל את כמות הקוד הפתוח בעולם כי אנשים פחות יחששו להוציא פרויקטים לקוד פתוח.
זהו הקוד שלך, הזמן שלך, המאמץ שלך ובסופו של דבר ההחלטה שלך בלבד.
מה אם יגנבו לך רעיונות וקוד מבלי לתרום בחזרה?
קדם כל, כנראה שזה יקרה. הטענה היא שזה לא נורא כמו שזה נשמע. אם הכלים שהוצאת לקוד פתוח הם כלים גנריים, רוב הסיכויים שהם לא יגיעו בכלל למתחרים הישירים שלך. וגם אם כן - היתרונות שצוינו קודם לכן מאפילים באופן משמעותי על ה- "נזק" הפוטנציאלי מהגדלת התחרותיות שלהם.
פרט לכך, גם להם משתלם לפתוח עליך באג או לפתור אותו אצלך שכן אם הם יפתרו את זה אצלם, הקוד שלהם לא יהיה מעודכן בתיקונים, שינויים ועדכונים שתעשה אתה והקהילה שמשתמשת בקוד בעתיד.
:אם הם ייפתחו פרויקט משלהם בקוד פתוח המבוסס על שלך, יהיו לך כמה אפשרויות
● לעבור לגרסה שלהם ולתת להם לתחזק את הפתרון אצלם.
● "לגנוב" את העבודה שלהם בעצמך ולפתוח גרסה חדשה למוצר שלך עם השינויים שהם עשו.
● לקחת בחשבון את העבודה שלהם ואת הזווית שלהם בנוגע לפתרון ולהתעלם ממנה עד שלא יוחלט אחרת.
בכל מקרה- אתה מרוויח.
קוד פתוח של רעיונות - השלב הבא בקוד פתוח
נפגשת עם הצוות שלך? יצאת מלא ברעיונות ובידע חדש? בשבילי זה החלק הכי מהנה בפיתוח תוכנה. עבודה עם אנשים חכמים וחרוצים זה פשוט דבר נפלא. אבל למה לא להתייעץ בנושא עם עוד כמה אלפי גאונים שיהיו שמחים להביע את דעתם? האמת שזה בדיוק מה שאני עושה במאמר הזה כשאני מתייעץ אתכם.
לפני כשנתיים פרסמתי בפומבי מאמר בנוגע לחלופות שיש לשוק להציע בתחום בדיקת אתרי אינטרנט - הנה הגרסה המעודכנת שלו. לאחר זמן מה, המאמר עלה למקום הראשון בגוגל כשמחפשים "javascript tests". הרעיונות שקיבלתי מהמגיבים הרבים במאמר, בפלטפורמות השונות בהם הוא שותף, עזרו לי להבין איפה טעיתי, מה פספסתי ועם מה אנשים הסכימו או לא הסכימו.
ולא מדובר פה ברעיון מהפכני. בספרו החדש של ניל פרגסון- "The Square and the Tower: Networks and Power, from the Freemasons to Facebook", הוא מראה איך רשת הנאורות (The Enlightenment Network) צמחה והשתלטה על השיח של המאה ה- 18.
התפתחות של 200 שנים בטכנולוגיות הדפסת ספרים גרמה לירידה משמעותית במחירי ספרים באירופה. הוגי דעות חשובים כמו וולטר החלו להתכתב עם אלפי מגיבים מכל שכבות האוכלוסייה שעזרו להם לחדד את הרעיונות שלהם. הרעיונות שלהם חודדו והשפיעו על השיח עד לרמה שהם גרמו למהפכות בכל אירופה ולאחר מכן גם בכל העולם.
כיום, אפשר לעשות את אותו הדבר בקלות רבה ולהגיע לקהל פי 1000 יותר רחב - בואו נשתמש בזה.
מאת: ויטלי זיידמן, ארכיטקט תוכנה בכיר, וול דן פתרונות תוכנה
?איך להיעזר בזרים מוחלטים לטובת שיפור המוצר שלך תוך תרומה לאנושות
אני נשאל באופן קבוע "מה להוציא לקוד פתוח?" כאשר לטעמי השאלה שיש לשאול היא "מה לא להוציא לקוד פתוח?"
רבים יגידו שזו גישה מוזרה. אחרי הכל, כשאתה פותח עסק אתה משקיע הרבה זמן, כסף ונשמה בפיתוח המוצר שלך, למה שתחשוף חלקים מהקוד לציבור הרחב? למה לתת להם את פירות המאמץ שלך בחינם?
ידעתי שיש הרבה ערך לקוד פתוח, אבל לא הייתה לי דעה נחרצת בנושא או מדיניות ברורה עד שקראתי מספר מאמרים בנושא שעשו לי סדר בראש בנוגע לנושא הזה. למשל המאמר הבא:
I thought I understood Open Source. I was wrong של לורנזו סקיאנדרה שכלל את הציטוטים הבאים: (בתרגום חופשי מאנגלית)
"תראה, בניתי את זה - אם אתה רוצה גם להשתמש בזה, הנה איך לעשות זאת. עשיתי את זה בדרך שתתאים לצרכים שלי אבל אתה יכול להשתמש בזה כרצונך."
"אם אתה משתמש בפרויקט בקוד פתוח, הרי שנהיית אחד מהמפתחים שלו. פעל בצורה ההולמת את העובדה הזאת."
?אז מה לא להוציא לקוד פתוח
את הלוגיקה עסקית (Business Logic) של המוצר המייחדת את המוצר שלך ממוצרים אחרים כדאי להשאיר לעצמך. פתיחתו לעולם תעזור בעיקר למתחרים הישירים שלך. אפילו מומלץ להשתמש בכלים כמו Jscrambler שיהפכו אותו לקוד קשה לפיצוח.
?מה להוציא לקוד פתוח
כדאי להוציא את החלק הגנרי של המוצר: מדובר בדרך כלל על כ- 50% ויותר מכלל הקוד. החלק הזה כולל בדרך כלל כלים, עזרים ומערכות כלליות שפותרים בעיות ספציפיות ויכולים להיות שימושיים למפתחים שונים, ולעבוד עם מוצרים שונים ומשונים. כל אלו עדיף שיהיו בקוד פתוח לטובתך ולטובת המוצר.
?מה הערך של הוצאת החלקים הגנריים של הפרויקט לקוד פתוח
● דיווחים על בעיות וחוסרים- עשרות, מאות ולפעמים אפילו אלפי אנשים יריצו את הקוד שלך בכל מני תנאים, סביבות ומקרי קצה ויגדילו את הסיכויים שבאגים יימצאו וידווחו במהרה, עוד לפני שהם ישפיעו על המוצר שלך.
● חלק קטן מהמשתמשים יתרמו לפרויקט- תיקוני באגים, פיצ'רים, טסטים, רעיונות.
● מודולריות- כשפתרון לבעיה מסוימת נמצא במקום מנותק לגמרי מהמוצר שלך ואפילו מצהיר שמטרתו לפתור את הבעיה באופן כללי, מי שעובד על הקוד יכתוב קוד לא מצומד (coupled) ללוגיקה העסקית של האפליקציה ובכך הרבה יותר סביר שהפתרון לא יגרום לבאגים במקומות לא צפויים במערכת הראשית או יפסיק לעבוד כשיהיו שינויים במערכת הראשית.
● מוניטין- חברות המנהלות פרויקטים בקוד פתוח מפתחות מוניטין מעולה בקרב קהילת מפתחי התוכנה, וזוהי דרך מצוינת למשוך מתכנתים טובים.
?יש דוגמאות לחברות שעשו זאת
יש הרבה. מדובר בטרנד מאוד חשוב בשוק.
פייסבוק מפתחת את ריאקט בקוד פתוח. היא משתמשת בו עבור כמעט כל המוצרים שלה. לא מזמן היא הורידה אפילו את ההסתייגות הקטנה שהייתה להם בנוגע להרשאות השימוש בריאקט וספריות הנלוות אליו בנוגע לפטנטים היות והם קיבלו החלטה אסטרטגית שעדיף להם לוותר על השליטה המעטה שהייתה להם במי משתמש בכלים הללו לטובת הגדלת כמות המשתמשים והקהילה סביב הכלים.
בחברה שבה אני עובד (וול דאן פתרונות תוכנה) עושים את זה כבר שנים עם כמעט 90 פרויקטים. לספוטיפיי יש מעל 200 פרויקטים ולנטפליקס כ- 150.
למעשה, חיפוש אחר כל שחקן גדול בשוק התוכנה יניב כמות גדולה של קוד פתוח שנכתב בחלקו או במלואו על ידי השחקן. זה לא אומר שכל הפרויקטים הללו מטרידים את המפתחים שלהם באופן יומיומי.
?זה לא דורש יותר מדי תחזוקה ומאמץ לטובת אחרים
זה נכון שקיימת תרבות מסוימת של מפתחים שמרגישים שמתחזקים חייבים להם משהו, אבל האמת היא שאין לאף אחד זכות לדרוש שתעבוד על משהו שלא מעניין אותך.
:כשמישהו פונה אליך בנוגע לפרויקט פתוח יש לך כמה אפשרויות
● אתה יכול לתקן/לשפר את הקוד - במקרה כזה אתה מרוויח מזה שמישהו גילה לך שיש בה בעיה.
● אתה יכול להסביר איך מי שפנה אליך יכול לעשות את זה בעצמו - במקרה כזה אתה יכול להרוויח שיפור לקוד על ידי מישהו אחר.
● להתעלם מהבקשה שלו לגמרי. אתה לא חייב לענות לאף אחד - במקרה כזה קבלת אינפורמציה חדשה בנוגע לקוד שיום אחד יכולה להיות בעלת ערך בשבילך.
יש מי שאכן מרגיש שהוא עובד עבור אחרים ומתחזק כלים כי הוא חייב למישהו, או בשביל מוניטין שנוצר לחברה אם היא לא מתחזקת קוד - הכל עניין של גישה. לדעתי, חברה שלא מתחזקת קוד פתוח מסויים לא צריכה להתבייש בשום דבר וזה עניינה בלבד. הייתי רוצה שכולם יתייחסו לזה ככה. אני מאמין שיחס כזה יגדיל את כמות הקוד הפתוח בעולם כי אנשים פחות יחששו להוציא פרויקטים לקוד פתוח.
זהו הקוד שלך, הזמן שלך, המאמץ שלך ובסופו של דבר ההחלטה שלך בלבד.
מה אם יגנבו לך רעיונות וקוד מבלי לתרום בחזרה?
קדם כל, כנראה שזה יקרה. הטענה היא שזה לא נורא כמו שזה נשמע. אם הכלים שהוצאת לקוד פתוח הם כלים גנריים, רוב הסיכויים שהם לא יגיעו בכלל למתחרים הישירים שלך. וגם אם כן - היתרונות שצוינו קודם לכן מאפילים באופן משמעותי על ה- "נזק" הפוטנציאלי מהגדלת התחרותיות שלהם.
פרט לכך, גם להם משתלם לפתוח עליך באג או לפתור אותו אצלך שכן אם הם יפתרו את זה אצלם, הקוד שלהם לא יהיה מעודכן בתיקונים, שינויים ועדכונים שתעשה אתה והקהילה שמשתמשת בקוד בעתיד.
:אם הם ייפתחו פרויקט משלהם בקוד פתוח המבוסס על שלך, יהיו לך כמה אפשרויות
● לעבור לגרסה שלהם ולתת להם לתחזק את הפתרון אצלם.
● "לגנוב" את העבודה שלהם בעצמך ולפתוח גרסה חדשה למוצר שלך עם השינויים שהם עשו.
● לקחת בחשבון את העבודה שלהם ואת הזווית שלהם בנוגע לפתרון ולהתעלם ממנה עד שלא יוחלט אחרת.
בכל מקרה- אתה מרוויח.
קוד פתוח של רעיונות - השלב הבא בקוד פתוח
נפגשת עם הצוות שלך? יצאת מלא ברעיונות ובידע חדש? בשבילי זה החלק הכי מהנה בפיתוח תוכנה. עבודה עם אנשים חכמים וחרוצים זה פשוט דבר נפלא. אבל למה לא להתייעץ בנושא עם עוד כמה אלפי גאונים שיהיו שמחים להביע את דעתם? האמת שזה בדיוק מה שאני עושה במאמר הזה כשאני מתייעץ אתכם.
לפני כשנתיים פרסמתי בפומבי מאמר בנוגע לחלופות שיש לשוק להציע בתחום בדיקת אתרי אינטרנט - הנה הגרסה המעודכנת שלו. לאחר זמן מה, המאמר עלה למקום הראשון בגוגל כשמחפשים "javascript tests". הרעיונות שקיבלתי מהמגיבים הרבים במאמר, בפלטפורמות השונות בהם הוא שותף, עזרו לי להבין איפה טעיתי, מה פספסתי ועם מה אנשים הסכימו או לא הסכימו.
ולא מדובר פה ברעיון מהפכני. בספרו החדש של ניל פרגסון- "The Square and the Tower: Networks and Power, from the Freemasons to Facebook", הוא מראה איך רשת הנאורות (The Enlightenment Network) צמחה והשתלטה על השיח של המאה ה- 18.
התפתחות של 200 שנים בטכנולוגיות הדפסת ספרים גרמה לירידה משמעותית במחירי ספרים באירופה. הוגי דעות חשובים כמו וולטר החלו להתכתב עם אלפי מגיבים מכל שכבות האוכלוסייה שעזרו להם לחדד את הרעיונות שלהם. הרעיונות שלהם חודדו והשפיעו על השיח עד לרמה שהם גרמו למהפכות בכל אירופה ולאחר מכן גם בכל העולם.
כיום, אפשר לעשות את אותו הדבר בקלות רבה ולהגיע לקהל פי 1000 יותר רחב - בואו נשתמש בזה.
מאת: ויטלי זיידמן, ארכיטקט תוכנה בכיר, וול דן פתרונות תוכנה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר