כיצד ליצור פרויקט קוד פתוח

פסטיבל IT יתקיים השבוע בסנט פטרסבורג TechTrain. אחד הדוברים יהיה ריצ'רד סטולמן. אמבוקס גם משתתף בפסטיבל, וכמובן שלא יכולנו להתעלם מהנושא של תוכנה חופשית. לכן נקרא אחד הדו"חות שלנו "מאמנות סטודנטים ועד פרויקטים בקוד פתוח. חווית אמבוקס”. הוא יוקדש להיסטוריה של הפיתוח של Embox כפרויקט קוד פתוח. במאמר זה אני רוצה לדבר על הרעיונות העיקריים שלדעתי משפיעים על פיתוח פרויקטים בקוד פתוח. המאמר, כמו הדו"ח, מבוסס על ניסיון אישי.

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

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

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

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

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

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

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

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

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

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

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

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

השלב הבא של Embox היה החיפוש אחר משתמשי צד שלישי. חשוב מאוד להבין שמשתמשים הם משתתפים מלאים בקהילת ה-opensource. בדרך כלל יש יותר משתמשים ממפתחים. וכדי לרצות להיות תורמים לפרויקט, הם מתחילים קודם כל להשתמש בו בצורה כזו או אחרת.

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

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

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

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

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

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

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

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

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

מקור: www.habr.com