Why map successful/un-successful OS projects?

Winter morning on the road – the long road ahead…

Hi :-)

I’m trying to make sense of the following arguments lets-see how far we can get:

1/ Open source (OS) development processes overcome many of the challenges that other methods of software development face.

2/ the idea that if OS processes are adapted in organizations than organizations’ will enjoy their many tributes is still prevailing

3/ However, evidence shows the OS development processes have NOT been widely adapted by organizations, certainly not as you would expect.

4/ the reasons for the later are that open source is based on a different set of economic, social and political assumptions suited for the digital world.

For example – ownership in OS is perceived as the right to distribute rather then the right to exclude. While organizations fight over scarce resources OS projects operate within a world of infinite resources. Their challenge (economic-political-social) is to attract as many contributors’ to their project as the only scarce resource is talent.

5/ OS is not a movement, it operates as a network, with many diverse motivations and is designed to encompass many possible flexibly changing centers, according to changing needs.

6/ Open source is part of the prevailing system and operates within it. Successful OS projects are always initiated in response to a specific moment and time in reality, and are intimately linked to main stream economy (Weber, 2004).

7/ However OS constantly shift’s the balance towards market production and regulation as apposed to government and  hierarchical organizations. For example, there is growing evidence that suggests that innovation in many areas is better conducted in the market then within the hierarchical organization.

8/ Finally I argue that mapping the areas in which successful OS projects have emerged can provide evidence on future change in a variety of areas associated with the project.  While mapping areas in which OS projects have not been successful can provide evidence to areas in which the hierarchical organization provides a superior solution.

9/ Just to give you a taste of the possibilities’ described at point no. 8 consider the OS Bitcoin project…

Gilad Ben-Yossef  has kindly provided me with  great insights to some of these ideas, especially with regard to points 6, 7 and 9, in any case I take sole responsibility to all points J.

חלופה תיאורתית – חזרה למקורות

(ציור של קאראווג’ו, בערך 1599, מקור: ויקיפדיה)

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

נתחיל בהגדרת גבולות הגזרה: הנושא שלנו הוא שיטות פיתוח מבוססות קוד פתוח.

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

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

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

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

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

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

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

given enough eyeballs all bugs are shallow (ריימונד). בהרצאה שלינוס טורבלדס נתן ב- 2007 בגוגל הוא הסביר שמה שהנחה אותו בבנית הארכיטקטורה של גיט – מערכת לניהול פרויקטים מבוזרים ומורכבים כמו לינוקס הייתה ש:

“no single place is more important than any other single place.”  (Torvalds, 2007)

 

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

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

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

אני שמחה ששאלתם. קודם כל יורד מהגב המחקרי שלנו over weight רציני ואנחנו מתפנים להתבונן על התופעה עצמה והאופן שבו היא מציגה את עצמה בעיניים רעננות.

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

הטענה שלי היא שכיוון מחקר מעניין ומרתק נמצא בנקודת הזמן שבה האינדיוידואל או הקבוצה הקטנה יוזמים פרויקט קוד פתוח קהילתי. סביר שבהתחלה הם אפילו לא קוראים למה שהם עושים “פרויקט” ובטח שלא “פרויקט קוד פתוח”. אבל המהות של מה שהם עושים אם נסתכל על זה ברטרוספקטיבה (ואם נתבונן על הפרויקטים הקהילתיים המצליחים) זה ליצור איזו שהיא חלופה, איזו שהיא אלטרנטיבה לקיים. ה- scratching their own itch כרוך בגירוד משהו שמעקצץ אותם, שמציק להם, אולי מציק בקטנה, אולי מה שמניע אותם היא הידיעה שהם יכולים לעשות משהו טוב יותר ממה שיש שם היום. כך או כך הם עושים, ועצם העשייה הוא שלב ראשון והכרחי ביצירת אלטרנטיבה לקיים (האלטנרטיבה לקיים כוללת שידרוג הפתרון הקיים מכיון שבסופו של ענין נוצרת אלטרנטיבה למה שהיה שם קודם).

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

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

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

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

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

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

כשמושא המחקר שלך שונה מהשיטה

  היי,

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

makers: the new industrial revolution

וקראתי את הספר האחרון של יוחאי בנקלר מ- 2011

ומצאתי את הציטוט הזה  משנת 2002 אתמול

MOCKUS, FIELDING, HERBSLEB
Two Case Studies of Open Source Software Development: Apache and Mozilla

“…The challenge is not the sort posed by a new competitor that operates according to the same rules but threatens to do it faster, better, cheaper. The OSS challenge is often described as much more fundamental, and goes to the basic motivations, economics, market structure, and philosophy of the institutions that develop, market, and use software.”

מה שמצא חן בעיני הוא שהוא מתמצת בצורה מצוינת  עניין שהעסיק אותי לא מעט.

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

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

במאמר ארוך ומרתק בשם Paradigm Shift

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

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

החצי המלא הוא  שיש למה לשאוף ב- 2013.

שנה אזרחית טובה לכלום!

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

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

שיזמית השנה היא לימור פריד ממובילות מהפכת ה

makers

ובעלת החברה הניו-יורקית

Adafriut Industries

וגם אחות של טליה פריד…

קודוס!

שנה טובה לכולם, יעל

What am I trying to do?

The simple answer – trying to organize my thoughts… with your help.

Iv’e been interested in open source for over a decade. And, believe like many others (especially appreciate Steven Webers thoughts on this issue)  that open source has been effecting many areas some of which have nothing to do with software.

My assumption is that open source is and will  effect the way we organize work. Since this is currently a far fetched idea i’m trying to minimize it to a research-able topic. What iv’e come up with for starters is to research the interesting area where open source and organizations meet. With a special interest in the conflicts that arise.

These could be organizations meeting open source by practicing the process in-house, or joining an existing open source project or initiating their open source project. For this i’ll be defining  the open source process in some form of an index. But also will be looking to find interesting case studies.