כאן בישראבלוג קוראים את הקוראים. באופן ספציפי, יש לי פה רק קורא אחד, כנראה, אבל כל אחד צריך להסתפק במה שהוא מקבל.
אז איך הולך הקסם הזה שנקרא תוכנה חופשית? מי מחליט מה, איך ומתי? התהליך הולך בערך כך:
השלב הראשון הוא שמישהו מחליט להתחיל פרוייקט תוכנה חופשית. אם זה פרוייקט שהיום מרכזיים וחשובים, כגון לינוקס, ואם משהו שולי. למישהו היה איכפת מספיק כדי לכתוב את הקוד, ולשחרר אותו.
בשלב הזה, מי שמחליט מה יהיה בקוד הוא מי שכותב את הקוד. אני אתן רמז – זה לא משתנה מאוד בהמשך. דוגמא אמיתית מפרוייקט קטן: משתמש בשם Jhonatas M. Rodríguez רצה תמיכה בסוג משתנה חדש בדרייבר שלינגנו מתחזקת. התשובות האפשריות הן:
1. אוקיי, נכתוב
2. מצטער, אין לנו משאבים. תכתוב אתה ונכניס
3. זה לא מתאים, מצטערים.
במקרה של לינגנו (ותמיכה מסחרית בכלל), יש גם:
4. אם תשלם אז נכתוב, אחרת – תכתוב בעצמך
היופי פה הוא שאין אינטרס למשחקים. אם באמת לא מתאים, לא נכניס קוד חדש. אם כן מתאים אבל אין משאבים לפתח, אז הוא מוזמן לפתח בעצמו (או לשכנע מישהו אחר לפתח), ואנחנו נכניס את זה לקוד.
עכשיו שאלה – מה יקרה אם הוא יפתח תוספת שתורמת לקוד, אבל מייצרת תחרות עם לינגנו? מה ימנע מאיתנו למנוע את הכניסה של הקוד הזה, שטוב לכל העולם למעט לינגנו, לפרוייקט?
התשובה היא פשוטה. בעוד שאני שולט על פרוייקט OLE DB שנמצא על שרת של PostgreSQL, אני לא שולט על כלל הדרייברים של OLE DB שנמצאים בעולם. גם לא על אילו שנכתבו בהתבסס על הקוד שלי. במילים אחרות – אם הניהול שלנו את הפרוייקט מעכב אותו במקום לתרום לו, הרי שיכול כל אחד שאכפת לו מהפרוייקט לקחת את הגרסאות החופשיות שכבר קיימות, ולהתחיל לפתח גרסא אחרת על פי ראות עיניו. התופעה הזו נקראת “forking” (מיזלוג?).
מדרך הטבע, יווצרו עכשיו שתי תוכנות שמתחילות את דרכן מאוד דומה. כדי שאנשים יעברו מהתוכנה הקיימת לתוכנה החדשה, צריכה להיות סיבה ממש טובה לביצוע fork. בהיסטוריה של תוכנה חופשית, יש מעט מאוד מיקרים שבהם בפועל בוצעה פעולה כזו. אחת מהן, שקרתה מאוד לא מזמן, הינה בפרוייקט XFree86, ובפרוייקט שהתפצל ממנו – X.Org.
במקרה שבו התוכנה המקורית הינה תחת רשיון Copyleft דוגמת ה-GPL, הרי שמובטח שעדיין אפשר יהיה לבצע מעבר קוד הדדי בין הפרוייקטים. דבר זה אומר, בפועל, שלא יתצע Forking לאורך זמן. בד”כ, גם אם ינסו, אחד הפרוייקטים (החדש או הישן) יאבד מומנטום, וכל השינויים שייעשו בו ימצאו את דרכם לפרוייקט השני. בד”כ, אחד מהם ימות.
מתנגדי הקוד הפתוח טוענים בד”כ ש-forking הינה הסכנה הגדולה ביותר לקוד פתוח. בפועל, אנחנו רואים שהדבר כמעט ולא קורה, בעיקר בגלל שקשה לייצר מומנטום לפרוייקט חדש, ובלי מומנטום תוכנה חופשית לא חיה.
עוד סיבה שהתופעה לא קוראת הרבה הינה בגלל היכולת לייצר גרסאות מקומיות עם שינויים. למשל, אם אתם משתמשים בלינוקס מתוך הפצה של RedHat, הליבה שאתם מריצים מאוד מאוד שונה מהליבה המקורית. בספירה אחרונה, רד האט מכניסים מעל 600 שינויים שונים בקוד הליבה שהם מפיצים, לעומת הליבה המקורית כפי שניתנה מלינוס.
מדוע אני לא קורה לזה fork? הסיבה היא שעל אף השינויים, הליבה של רד האט עדיין עוקבת אחרי הליבה הנקיה. מספרי הגירסאות, התכונות והקוד ממשיכים לזרום מהליבה המקורית אל הליבה של רד האט. מצד שני, שינויים שהוכיחו את עצמם בליבה של רד האט יכולים למצוא את דרכם אל תוך הליבה הראשית. למעשה, לינוס ממליץ לאנשים שרוצים לשכנע אותו להכניס שינויים שלהם לליבה הראשית, להכניס את השינויים לליבה של הפצה כלשהי קודם. ע”י כך, לינוס זוכה לראות את השינוי בפעולה, ולקבל רושם טוב יותר לגבי היתרונות (והסיכונים) של להכניס אותו פנימה.
עוד דוגמא מעניינת של הקוד שרודף אחרי קוד אחר הינה היחסים ההדדיים שבין Wine לבין Crossover Office. למי שלא מכיר, Crossover Office הינו מוצר קנייני שמבוסס על Wine. כמובן שהמוצר אינו כולו סגור, מכיוון ש-Wine הינו תחת רשיון LGPL.
בין גרסת ה-Wine שנמצאת בתוך Crossover Office לבין גרסת ה-Wine הסטנדרתית יש מספר הבדלים. יצרני XOO עבדו קשה, ומצאו טריקים ומעקפים שגורמים לאפליקציות שבהם הם מעונינים (Office, Internet Explorer וכו) לעבוד יותר טוב. השינויים האילו הינם זמניים ו”מכוערים” מידי מכדי שהמפתח האחראי על פרוייקט Wine יכניס אותם לקוד הראשי. מכיוון שאפשר להוריד את הקוד מהאתר של Code Weavers (היצרנים של XOO), זה לא הופך לסוד מסחרי. עדיין, XOO עוקב אחרי Wine, למרות שיש בו שינויים תמיד.
אני מקווה שהתהליך קצת יותר ברור.
שחר