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

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

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

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

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

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

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

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

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

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

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

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

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