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

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

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

מבוא

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

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

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

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

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

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

Desarrollo

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

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

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

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

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

PREMISE מס '1

כל העבודות הטובות בתוכנה מתחילות לנסות להוות בעיה אישית של עצמו.

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

PREMISE מס '2

מתכנתים טובים יודעים מה לכתוב. הידיעה הגדולה ביותר מה לכתוב מחדש ולבצע שימוש חוזר.

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

PREMISE מס '3

"תחשוב על השלכת לפחות אחד - אתה תסיים לעשות את זה בכל מקרה."

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

PREMISE מס '4

אם יש לך את היחס הנכון, בעיות מעניינות ימצאו אותך.

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

PREMISE מס '5

כאשר תוכנית לא מעניינת אותך יותר זמן, חובתך האחרונה היא להעביר אותה ליוצרת מוכשרת.

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

PREMISE מס '6

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

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

PREMISE מס '7

שחרר את זה בקרוב. הפעל אותו לעתים קרובות. והאזין למשתמשים שלך.

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

PREMISE מס '8

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

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

וזה מתבטא בנעימות בקטע הבא מהחומר:

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

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

סיכום

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

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

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