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

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

1. הצטרפו לקהילה

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

כך לא עובדת תוכנה חופשית.

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

הנה קישור לעמוד ה Issues של ספריית הבדיקות Jasmine למשל:
https://github.com/jasmine/jasmine/issues

ואגב לאותו הפרויקט יש גם עמוד בגוגל גרופס בקישור הזה:
https://groups.google.com/forum/#!forum/jasmine-js

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

2. שלחו תיקון במקום לשנות קוד רק לעצמכם

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

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

3. היו מנומסים בעת שליחת בקשות משיכה או דיווח על באגים

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

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

דיווח על באג לדוגמא יתקבל הרבה יותר טוב אם הוא יגיע בליווי בדיקת יחידה שאפשר להריץ ולאמת את קיום הבאג.

4. המנעו מתלות במוצר מסוים עד כמה שניתן

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

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

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

5. למדו לעומק את ההבדל בין סוגי הרשיונות השונים

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

כאן תמצאו רשימה של רשיונות מרכזיים והמשמעויות שלהם. זכרו לחפש את הרשיון בכל קוד חופשי שאתם מסתמכים עליו ולהבין האם מה שאתם עושים עם הקוד תואם לרשיון:
http://opensource.org/licenses/category

כדאי כמובן להתיעץ עם עו״ד אם יש ספק, או לשלוח מייל למתכנת הראשי של הפרויקט או אם הרשיון הוא GPL, LGPL או AGPL אפשר להתיעץ עם איגוד התוכנה החופשית לפי המיילים שמופיעים בעמוד הבא:
https://www.fsf.org/about/contact/email

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