أعجوبة

البرمجيات الحُرة والمفتوحة المصدر

أدوات المستخدم

أدوات الموقع


docs:الكاتدرائية_والسوق

الكاتدرائية والسوق/البزار

حول هذه المقالة

الكاتدرائية والسوق (البزار) وثيقة مقارنة بين بيئة تطوير البرمجيات المغلقة والمفتوحة (الحرة)، وهي أيضا كتاب مطبوع نشرته بالإنجليزية O'Reilly

  • المؤلف: إريك ستيفين ريموند Eric Steven Raymond
  • ترجمة: زياد عبد الرحمن الهندي
  • التدقيق اللغوي: ريوف عبد الرحمن الهندي
  • الرخصة: رخصة النشر المفتوح Open Publication License, version 2.0
  • يمكن الوصول للوثيقة باللغة الإنجليزية على الرابط http://catb.org/esr/writings/homesteading/

ملخص

لقد قمت بتحليل مشروع ناجح مفتوح المصدر (فيتش ميل fetchmail)، والذي طبق كمشروع اختبار للفرضيات المدهشة في هندسة البرمجيات المقترحة من تاريخ نظام التشغيل “لينكس”. وسأناقش هذه الفرضيات من جانبين أساسين مختلفين كليا, الجانب الأول مبدأ “الكاتدرائية” وهو السائد لأن العالم التجاري التقني يستخدم هذا المبدأ، والجانب الآخر هو “السوق” ويسمى أيضا “البازار” ويستخدم غالبا في بيئات لينكس. وسأقوم باستعراض هذه الفرضيات التي استنبطت من وجهات نظر مختلفة حول طبيعة مهام تنقيح البرمجيات. بعد ذلك وانطلاقا من حصيلة خبرات لينكس سوف أناقش الفرضية التي تقول ” كلما زاد عدد المستخدمين قلت العلل“ وهي تقترح مقارنات فعالة مع الأنظمة ذاتية التصحيح و التي تحتوي على وكلاء أنانيين، وأخيرا سوف أختم ببعض الاستكشافات لنتائج هذه الرؤية فيما يخص مستقبل البرمجيات .

الكاتدرائية والسوق (البازار) :

إن لينكس مخرب، فمن كان يظن، حتى قبل خمس سنوات (1991)،إمكانية إنشاء نظام تشغيل عالمي - كما لو كان سحرا - من البرمجة في وقت فراغ آلاف المطورين المنتشرين حول العالم والمتواصلين عبر وصلات الإنترنت الضعيفة وحدها؟

بكل تأكيد لست أنا، ففي الوقت الذي بدأ لينكس بالغوص في شاشة راداري في مطلع عام 1993، كنت قد أكملت عشر سنوات من المشاركة في تطوير يونكس والمصادر المفتوحة. ففي منتصف 1980، كنت من أوائل المساهمين في مشروع GNU. وكنت قد أصدرت عددا جيدا من البرمجيات مفتوحة المصدر على شبكة الأنترنت، وقمت أيضا بتطوير عدة برامج سواء بشكل مباشر أو غير مباشر مثل ( nethack، ونمط VC و GUD لـ Emac، و xlife وغيرها) منها ما يزال مستعمل على نطاق واسع حتى اليوم، لقد ظننت أني أعرف كيف تسير الأمور.

ولكن لينكس قلب مفاهيمي رأسا على عقب في أشياء كثيرة كنت أظن أني أعرفها. كنت أحترم حكم يونكس المتمثلة في الأدوات الصغيرة والتصاميم المبدئية السريعة والبرمجة المتدرجة لعدة سنوات. لكني كنت أعتقد أيضًا بوجود نوع من التعقيد الحرج المبني على المركزية وكانت الحاجة ماسة لمقاربة تعتمد على لأولويات. واعتقدت بأن أكثر البرامج أهمية( نظم التشغيل والبرمجيات الكبيرة مثل بيئة تطوير ايماكس Emacs ) بحاجة بأن تبنى في بيئة الكاتدرائية، بحيث تبرمج بكل عناية علي أيدي سحرة مخصصين أو مجموعات صغيرة من الحكماء تعمل في عزلة مطلقةبدون صدور أي إصدار أولي (بيتا beta) لأي برنامج قبل وقته.

جاء أسلوب لينوس ترافولدس في التطوير (أطلق مبكرا وبشكل متكرر، فوّض كل شيء يمكن تفويضه، وكن شفّافا إلى درجة الوضوح التام) كالمفاجأة. لم يكن هناك الهدوء و التقدير لأسلوب البناء الكاتدرائي؛ بل كان مجتمع لينكس يشبه سوق ضخم مملوء بالضجيج لمختلف الأجندات و المقاربات (يتضح ذلك بشكل جلي في مواقع أرشفة لينكس التي يمكن أن تقبل المواضيع من أي شخص كان )بحيث أصبح ظهور نظام ثابت ومتماسك أمرا لا يمكن أن يحدث ظاهريا إلا بمعجزات متتابعة.

أتت حقيقة أن أسلوب السوق هذا -فيما يبدو- أنه يعمل بشكل جيد؛ كصدمة بارزة. وفيما أنا أستكشف الدرب من حولي، عملت بجهد ليس فقط على مشاريع فردية، بل حاولت أن أستوعب لماذا عالم لينكس لم يتفكك أو يصاب بحالات من الفوضى، بل على العكس تماما كان يحقق نجاحا تلو النجاح بسرعة بالكاد يمكن أن يتخيلها البناة بنظام الكاتدرائية. بحلول منتصف عام 1996، اعتقدت بأني بدأت أفهم الطريقة. تسنّت لي فرصة ممتازة لاختبار نظريتي على شكل مشروع مفتوح المصدر استطعت بإدراك تجربة أسلوب السوق (البازار)، وطبقته بالفعل و كانت التجربة ناجحة بشكل جلي.

وهذه هي قصة ذلك المشروع. و سوف أستخدمه لاقتراح مجموعة حكم فعّالة حول تطوير مشاريع مفتوحة المصدر. ليس كل هذه الأشياء تعلمتها من تعاملي مع عالم لينكس، ولكن سوف نرى كيف أن عالم لينكس أعطاها معنى معينا، وإذا كنت محقا ، ستساعدك على فهم بالضبط ما الذي يجعل من مجتمع لينكس مثل الينبوع من البرامج الجيدة، وربما سوف تساعدك على أن تصبح أكثر إنتاجية.

البريد يجب أن يمرر :

منذ عام 1993 وأنا أدير الجانب التقني من شركة صغيرة في غرب تشستر في بنسليفيا تقوم بتزويد خدمة الأنترنت تسمى Chester Country InterLink، حيث أني أحد مؤسسيها وقمت بكتابة برنامجنا الفريد لساحة الإعلانات متعددة المستخدمين — يمكنك أن تتأكد منه عن طريق telnet من هذا العنوان locke.ccil.org، واليوم تقوم الشركة بدعم قرابة ثلاثة آلاف مستخدم باستخدام 30 خط، هذه الوظيفة سمحت لي أن أحصل على النت 24 ساعة عن طريق خط المودم 56K الخاص بـCCIL، في الحقيقية الوظيفة تتطلب ذلك.

كنت قد تعوّدت علي البريد الإلكتروني الفوري. كما وجدت أن استخدام تلنت (telnet) على موقع Locke بشكل مستمر لتفحص البريد كان أمرا مزعجا. وما كنت أريده هو أن يرسل البريد إلى جهازي الخاص بحيث أبلّغ عند وصول البريد وأستطيع بعد ذلك أن أتعامل مع البريد بالأدوات المحلية الموجودة لدي.

فقد كان البروتوكول المستخدم بشكل تلقائي على الأنترنت لإرسال البريد هو SMTP (بروتوكول نقل البريد البسيط Simple Mail Transfer Protocol) لا يناسبني، لأنه يتطلب أن يكون الحاسوب متصلا بالأنترنت بشكل دائم. بينما حاسوبي لم يكن متصلا بالأنترنت بشكل دائم. ولا أملك عنوان IP ثابت. وما كنت أحتاجه أنا هو أن يقوم البرنامج بالاتصال بالأنترنت (اتصال عن طريق الهاتف Dialup) وجلب البريد إلى حاسوبي الشخصي. كنت أعرف بوجود شيء مشابه لما أريده، وأن أغلبها يستخدم بروتوكول بسيط يسمى POP. علما أن POP الآن يُستخدم بشكل واسع تقريبا من قبل عملاء البريد الإلكتروني ولكن في حينها لم يكن كذلك.

أنا بحاجة إلى عميل POP3، لذا بحثت في الإنترنت ووجدت واحدا، في الحقيقة وجدت ثلاثة أو أربعة، واستخدمت أحدهم لفترة، ولكن كان ينقصه ميزة بدهية ألا وهي القدرة على قراءة العناوين في البريد الوارد بحيث يمكن أن تعمل خاصية الرد بشكل سليم.

كانت المشكلة كالتالي : لنفترض أن شخصا وليكن joe على شبكة locke أرسل لي رسالة، فإذا قمت بجلب هذه الرسالة على نظامي الشخصي في البيت snark و حاولت أن أرد عليها، سيقوم خادم البريد بإرسالها بكل سرور إلى joe والذي هو غير موجود على snark، مما يضطرني أن أعدّل عنوان البريدي بشكل يدوي بإضافة @ccil.org، وهذه عملية مزعجة بشكل فظيع !

ومن الواضح أن هذه المهمة كان لابد أن يقوم بها الحاسوب بالنيابة عني. و لكن لم يكن أي عميل POP يعرف كيف يقوم بذلك، وهذا يقودنا إلى الدرس الأول :

  • 1-إن كل عمل جيد للبرمجيات بدأ من تلبية حاجات المطور الشخصية.

ربما قد يكون هذا أمرا بديهيا (وهي حقيقة صيغت في مثل منذ زمن بعيد: الحاجة أم الاختراع) ولكن كثيرا من مطوري البرامج يمضون أيامهم في عمل شاق من أجل المال في برامج : إما أنهم لا يحبونها أو لا يحتاجون إليها، ولكن ليس في عالم لينكس ؛ الأمر الذي قد يفسر متوسط جودة البرامج التي نشأت في مجتمع لينكس عالية جدا. لذا هل انخرطت على الفور في دوامة كتابة عميل POP3 جديد ينافس البرامج الموجودة ؟ بالتأكيد لا! بل تفحصت برامج POP الموجودة التي في يدي، و سألت نفسي ” أي واحد أقرب لما أحتاج ؟“ وذلك بسبب أن :

  • 2- المبرمج الجيد يعرف ماذا يكتب، ولكن المبرمج العظيم هو الذي يعرف ما يحتاج أن تعاد كتابته (أو يعاد استخدامه)

أنا لا أدّعي أني مبرمج عظيم، ولكني سأحاول تقليد أحدهم. وأحد مزايا المبرمج العظيم هو الكسل البنّاء، إنهم يعرفون أنك ستحصل على درجة ( أ )ليس ب بسبب المجهود بل للنتائج، وأنه دائما أسهل أن تبدأ من حل جزئي جيد من أن تبدأ من الصفر.

على سبيل المثال: “لينوس ترافولدس” لم يحاول أن يكتب لينكس من الصفر، إنما بدأ بإعادة استخدام شفرة وأفكار من مينكس (Minix) وهو عبارة عن نظام تشغيل شبيه بيونكس (Unix) وهو مخصص للأجهزة المنزلية “PC”. في النهاية جميع شفرات مينكس (Minix) اختفت أو أعيد كتابتها من جديد، ولكن عندما كانت هناك وفرت الغطاء للرضيع الذي سيصبح في النهاية لينكس.

وبنفس الحماس، ذهبت أبحث عن برنامج pop مكتوبا بطريقة جيدة؛ لكي استخدمه كأساس للتطوير.

إن تقليد مشاركة المصدر في عالم اليونكس كان دائما ودودا في إعادة استخدام الشفرة (لهذا السبب اختار مشروع جنو يونكس كنظام تشغيلي ينطلق منه، بالرغم من التحفظات الكبيرة حول النظام التشغيلي نفسه)، أخذ عالم لينكس هذا التقليد إلى حدوده التقنية القصوى تقريبا ؛ حيث أنه يملك تيرا بايتات من المصادر المفتوحة متوفرة بشكل عام، لذا فإن قضاء وقت للبحث عن شيء جيد يرجع لك نتيجة جيدة في عالم لينكس بالمقارنة مع الأنظمة الأخرى غالبا.

هذا ما حدث لي، فبالإضافة إلى البرامج التي حصلت عليها سابقا، ارتفع العدد إلى تسعة برامج مرشحة في البحث الثاني (fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail and upop) وأول برنامج استقريت عليه كان fetchpop المكتوب بواسطة Seung-Hong Oh، وقد قمت بوضع ميزة إعادة كتابة الترويسة فيه، بالإضافة إلى العديد من التحسينات و التي قبِلها الكاتب في إصدارة 1.9.

لاحقا وبعد عدة أسابيع ، عثرت على شفرة برنامج popclient لـ Carl Harris ، ووجدت أنه عندي مشكلة، فبالرغم من أن fetchpop يملك العديد من الأفكار الجيدة و الأصلية (مثل العمل في الخلفية) إلا أنه لا يستطيع أن يتعامل إلا مع POP3 فقط، وبالإضافة أن شفرته مكتوبة بشكل رديء (كان Seung-Hong في ذاك الوقت ذكيا ولكن ليس مبرمجا خبيرا، وانعكس ذلك على الشفرة ) بينما كانت شفرة Carl أفضل وأكثر احترافية وأصلب ولكن كان برنامجه ينقصه العديد من مزايا fetchpop المهمة والمعقدة التنفيذ (بما فيها المزايا التي كتبتها بنفسي).

أأستمر أم أغير ؟ إذا غيرت سأرمي بكل الشفرات التي كتبتها في مقابل قاعدة تطويرية أفضل. كان الدافع العملي للانتقال هو دعم عدة بروتوكولات، كان POP3 هو أكثر بروتوكول خادم post-office استخداما، ولكن لم يكن الوحيد، لم يدعم Fetchpop ومنافسيه POP2 و RPOP و APOP، وكانت لدي أفكار غير واضحة لإضافة دعم IMAP (بروتوكول النفاذ لرسائل الإنترنت Internet Message Access Protocol المصمم حديثا وأقوى بروتوكولات البريد post-office ) من أجل المتعة.

كون كان لدي سببا نظريا أقوى وهو أن التغيير قد يكون جيدا بحد ذاته، وهو شيء تعلمته منذ فترة طويلة قبل لينكس.

  • 3- “خطط لرمي أحدهم، وسوف تفعل ذلك على أي حال ” ( Fred Brooks من كتابه The Mythical Man-Month الفصل الحادي عشر)

أو بعبارة أخرى، في الغالب لن تفهم المشكلة بشكل جيد حتى تطبق لها حلا لأول مرة، في المرة الثانية قد يكون لديك المعرفة الكافية لتفعلها بشكل صحيح، لذا إذا رغبت أن تؤديها بشكل صحيح ؛ فلتستعد أن تبدأ من جديد مرة واحدة على الأقل .

حسنا (أخبرت نفسي) أن التغييرات التي أجريتها لـ fetchpop هي محاولتي الأولى، لذا قمت بالتغيير.

بعد أن أرسلت مجموعتي الأولى من الرقع الإصلاحية لـ popclient إلى Carl Harris في 25 يونيو 1996، وجدت أنه قد فقد اهتمامه بـ popclient قبل ذاك التاريخ بمدة، كانت الشفرة يعلوها الغبار وبها علل صغيرة، كان علي أن أقوم بتغيرات كثيرة، وبسرعة اتفقنا أنه من المنطقي بالنسبة لي أن أتوّلى تطوير البرنامج بنفسي.

وبدون أن ألاحظ بدأ المشروع في التصاعد، ولم أعد أفكر في كتابة رقع صغيرة لعملاء POP الموجودين، وأخذت مهمة صيانة البرنامج بالكامل، وكانت هناك أفكار تتفاعل في رأسي ، والتي كنت أعرف أنها ستؤدي إلى تغيرات كبيرة.

في ثقافة البرامج التي تشجع مشاركة الشفرات، هذه طريقة طبيعية لنمو مشروع، كنت أنفذ هذا القانون :

  • 4- إذا كان لديك موقف جيد، فإن المشاكل المثيرة ستجدك

لكن كان موقف Carl Harris أكثر أهمية، للفهم بأنه :

  • 5- عندما تفقد الاهتمام ببرنامج، فإن أخر مهمة لك نحوه أن تسلمه إلى خليفة متمّكن.

وحتى بدون أن نناقش المسألة، فإني أنا و Carl نعرف أنه لدينا هدف مشترك لامتلاك أفضل حل متوفر، كان السؤال الوحيد لكلينا هو إذا كنت أستطيع أن أثبت أني أستطيع العناية بالمشروع أم لا، و عندما حققت ذلك، قام هو بالرحيل بشرف، آمل أن أفعل ذلك أيضا عندما يحين دوري.

أهمية المستخدمين :

وهكذا ورثت popclient، وبنفس الأهمية ورثت قاعدة مستخدمي popclient، إن وجود المستخدمين من الأمور الرائعة التي يجب أن تملكها ليس فقط بسبب أنهم يثبتوا لك أنك تلبي حاجة ما، ولكن أيضا يبرهنوا أنك قمت بشيء ما بشكل صحيح، وبالرعاية الصحيحة قد يكونوا شركاء في التطوير.

ميزة أخرى قوية في تقليد اليونكس والتي أخذها لينكس إلى حدودها القصوى بسرور، هي أن كثيرا من المستخدمين هم أيضا هكر ، وبسبب أن شفرة المصدرية متاحة، فإنهم قد يكون هكر فعّالين، قد يكون هذا مفيد بشكل لا يتصور خصوصا في تقليص وقت التنقيح وإصلاح العلل. قدّم بعض التشجيع لهم، وسيقوم مستخدموك بتشخيص المشاكل و اقتراح الحلول، وسيساعدوا على تحسين الشفرة بسرعة أكثر مما لو كنت وحيدا.

  • 6- معاملة مستخدميك على أنهم شركاء في التطوير هو أسهل طريق لتحسين الشفرة بسرعة وجعل التنقيح فعالا.

من السهل تقليل قوة هذا التأثير، وفي الحقيقة أغلبنا في عالم المصادر المفتوحة قللنا بشدة كيف أنها ستناسب بشكل إيجابي بين عدد المستخدمين و تعقيد النظام، حتى أثبت لنا لينوس تورفالدس أن الأمر قد يكون مختلفا.

في الحقيقة، أنا أعتقد أن أذكى و أكثر هاك إنتاجية قام به لينوس ليس بناء نواة لينكس بنفسه، بل عوضا عن ذاك هو اختراعه لطريقة تطوير لينكس، وعندما عرضت أمامه هذه الفكرة في إحدى المرات، ابتسم وقال شيئا كان يكرره دائما: ” أنا في الأساس شخص كسول جدا يحب أن يحصل على المديح على أشياء قام بها الآخرون“ كسول كالثعلب، أو كما كتب Robert Heinleine عن أحد شخصياته، كسول جدا ليفشل.

وحين نستعيد الأحداث، نستطيع أن نرى سابقة لها علاقة بطريقة تطوير ونجاح لينكس في طريقة تطوير مكتبة جنو Emacs Lisp و أرشيف شفرة Lisp، فعلى خلاف طريقة بناء الكاتدرائية لنواة Emacs المكتوبة بلغة السي وأغلب أدوات جنو، نجد نمو شفرة Lisp كان جامحا وموجه بشكل كبير بواسطة المستخدمين، كانت الأفكار والتصاميم الأولية يعاد كتابتها عادة ثلاث أو أربع مرات قبل أن تصل إلى شكلها النهائي، وكان التعاون التكافلي الممكن عن طريق الإنترنت (مثل لينكس) دائما ما يتكرر.

في الواقع، لربما كان أنجح هاك لي قبل fetchmail هو نمط Emacs VC (الخاص بإدارة الإصدارات) قمت باتباع نمط تعاوني مشابه للينكس بواسطة البريد الإلكتروني مع ثلاثة أشخاص آخرين، التقيت مع واحد منهم فقط لحد هذا اليوم (رتشارد ستالمان مؤلف Emacs و مؤسس مؤسسة البرمجيات الحرة). كان الهاك واجهة أمامية لـ SCCS و RCS و أخيرا CVS ، حيث كان يقدم عملية التحكم بالإصدارات بواسطة لمسة واحدة، وقد تطوّر من نمط صغير وبدائي( sccs.el ) كتبه شخص آخر، ويعزى نجاح تطوير VC -على عكس Emacs- بسبب أن شفرات Emacs Lisp استطاعت أن تمر من خلال أطوار (الإصدار و الاختبار و التحسين ) بسرعة كبيرة.

قصة إيماكس ليست فريدة ، فقد كانت هناك منتجات برمجية أخرى تملك مستويين من البنية ومجتمعين من المستخدمين، يجمعان نمط الكاتدرائية للنواة ونمط السوق لصندوق الأدوات. وأحد الأمثلة هو برنامج MATLAB وهو أداة تجارية لتحليل البيانات وتجسيمها. دائما ما يلاحظ مستخدمو MATLAB والبرامج الشبيهة في البنية أن الإثارة والحماس والإبداع دائما ما يأخذ مكانه في الأجزاء المفتوحة من الأداة حيث يمكن للمجتمع الكبير والمتنوع أن يعدّل فيها.

أطلق مبكرا، أطلق بشكل متكرر :

إن الإصدارات المبكرة والمتكررة جزء مهم من استراتيجية تطوير لينكس. وقد اعتاد أغلب المطورين (بما فيهم أنا) التصديق على أن هذه سياسة جيدة فقط للمشاريع السهلة، بسبب أن الإصدارات الأولية في الغالب (بواسطة التعريف) ما تكون إصدارات مملوءة بالعلل، وأنت لا تريد أن تفقد صبر مستخدميك بمثل هذه الإصدارات.

عزّز هذا الاعتقاد الالتزام العام لأسلوب بناء الكاتدرائية في التطوير، فإذا كان هدفك الأساسي هو أن يرى المستخدمين أقل عدد ممكن من العلل قدر الإمكان، فلماذا تطلق إصدارة جديدة كل ستة أشهر (أو ربما أقل) ، وتعمل بجهد كبير في التنقيح بين الإصدارات؟. لقد طوّرت نواة Emacs C بهذا الأسلوب، على عكس مكتبة Lisp ؛ بسبب وجود عدة أرشيفات نشطة خارج سيطرة FSF، بحيث يمكنك أن تجد إصدارات تطويرية جديدة مستقلة عن دورة إصدار Emacs .

توقع أهم أرشيف من بينها - أرشيف Lisp لولاية Ohio - روح و مزايا أكبر أرشيفات لينكس اليوم، ولكن قلة منا فكرت بشكل جدي بتصرفاتنا، أو ما الذي يقترحه الوجود الكبير لذلك الأرشيف حول مشاكل أسلوب الكاتدرائية في التطوير الذي تتبعه FSF، لقد قمت بمحاولة جدية حوالي عام 1992 لدمج شفرات Ohio بشكل رسمي داخل مكتبة Emacs Lisp الرسمية، وانتهت بي إلى مشاكل سياسية وأخفقت بشكل كبير.

بعد مرور سنة؛ وبعد أن أصبح لينكس ظاهرا بشكل كبير، كان من الواضح أن هناك شيء مختلف و أكثر صحة يجري هناك، فقد كانت سياسة تطوير لينوس المفتوحة على نقيض سياسة بناء الكاتدرائية، فقد كانت أرشيفات لينكس تزدهر، والعديد من التوزيعات بدأت تطفو على السطح، وكل هذا مبني على تكرار إصدارات النظام الأساسي بطريقة لم يسمع أحد بها.

كان لينوس يعامل مستخدميه كشركاء في التطوير بأكفأ طريقة ممكنة :

  • 7- أطلق مبكرا، وأطلق بشكل متكرر، و استمع لزبائنك.

لم يكن إبداع لينوس في سرعة إطلاق إصدارات تحوي على الكثير من اقتراحات المستخدمين (مثل هذا كان موجودا في تقليد يونكس منذ زمن بعيد)، ولكن كان في جعل اقتراحات الزوار تنمو بشكل طردي مع درجة تعقيد المشروع الذي يطوره. في تلك الأيام الأولى ( حوالي 1991) لم يكن يجهل أنه كان يطلق إصدارة جديدة للنواة أكثر من مرة في اليوم ! ؛بسبب أنه كان ينمي قاعدته من شركاء التطوير، و يدفع بالأنترنت - أكثر من أي شخص أخر - لأن تكون وسيلة للتعاون، و قد نجح في ذلك.

ولكن كيف نحج ؟وهل هذا النجاح شيء يمكن أن أكرره، أم أنه يعتمد على عبقرية لينوس تورفالدس الفريدة ؟

لا أعتقد ذلك، فمع تسليمنا أن لينوس هاكر ممتاز؛ فكم شخص منا يستطيع أن يبني نواة نظام تشغلي بجودة الإنتاج من الصفر؟ لكن لينكس لم يمثل أي قفزة رائعة للأمام من ناحية المفاهيم. ولينوس ليس عبقري مبدع في التصميم (ليس بعد على الأقل ) مثل ما كان رتشارد ستالمن أو جيمس جوسلنج (صاحب NeWS وجافا) على سبيل المثال، بل عوضا عن ذلك، يبدو لي أنه عبقري في الهندسة و التطبيق بحاسة سادسة لمنع العلل و النهايات المميتة في التطوير، و يمتلك موهبة حقيقية لإيجاد أسهل طريق من النقطة أ إلى النقطة ب، بالتأكيد تنفّس تصميم لينكس بالكامل هذه الجودة، وعكس تحفظات لينوس الضرورية وطريقة التصميم المبسطة.

إذاً، إذا كانت الإصدارات السريعة ودفع وسيط الإنترنت إلى أقصى حد ممكن لم تكن مصادفة بل كانت أجزاء متكاملة من هندسة لينوس العبقرية مستلهمة من أقصر الطرق الممكنة، فماذا كان يهدف؟ وما هي مخرجات تلك المكنة ؟

في هذا السياق، فإن السؤال يجيب على نفسه، كان لينوس يبقي على هكره/مستخدميه متحفزين ومكافئين، متحفزين بسبب إتاحة الفرصة لهم للقيام بأشياء يفخرون بها، ومكافئين بسبب رؤيتهم أن عملهم يتم تحسينه بشكل ثابت (أو حتى يوميا).

كان لينوس يهدف بشكل مباشر لزيادة عدد ساعات الشخص التي يقضيها في التنقيح والتطوير، حتى لو كان الثمن هو عدم الاستقرار في الشفرة وإجهاد قاعدة المستخدمين إذا وجد علة خطيرة صعبة الحل، كان لينوس يتصرف كما لو كان يؤمن بشي مثل هذا :

  • 8- في حال وجود قاعدة من مختبرين البيتا وشركاء التطوير بشكل كاف، فإن أغلب المشاكل ستشخص بسرعة وسيصبح الحل ظاهرا لشخص ما.

أو بشكل أقل رسمية ” إذا وجدت عيون كافية، فإن كل العلل ستصبح سطحية “ وقد أسميته ” قانون لينوس“.

كان تأطيري الأصلي أن كل مشكلة “ستصبح شفافة لشخص ما”، وكان اعتراض لينوس أن الشخص الذي يفهم و يصلح المشكلة ليس بالضرورة أو حتى في الغالب ليس الشخص الذي يشخص المشكلة أول مرة، و يقول ” شخص ما يجد المشكلة و شخص آخر يفهمها، و سوف تسجل لي حين أقول أن إيجاد المشكلة هو التحدي الأكبر“، هذا التصحيح مهم، وسوف نرى في الفصل القادم كيف ذلك حين نختبر عملية التنقيح بشيء من التفصيل، ولكن النقطة الأساسية هي أن كلا الجزءان من العملية (الإيجاد و الإصلاح) يميلان أن يكونا سريعتان.

تكمن الاختلافات الجوهرية بين أسلوب بناء الكتدرائية و السوق في قانون لينوس حسبما أظن، فنظرة بناء الكتدرائية لمشاكل البرمجة و العلل و التطوير، هي أنها ظاهرة مخادعة و غادرة و عميقة، وهي تأخذ أشهر من الفحص بواسطة مجموعة صغيرة مخصصة حتى تتأكد من أن جميع المشاكل تم إزالتها بالكامل، كل هذا يتطلب فترات إصدار طويلة مع إحباط لا بد منه عندما تكتشف أن الإصدارة التي طال انتظارها غير كاملة .

أما في نظرة السوق على الطرف الآخر، فإنك تفترض أن المشاكل هي ظاهرة سطحية أو على الأقل أنها ستصبح سطحية بسرعة لا بأس بها عندما يتم تعريضها للآلاف من شركاء التطوير المتحمسين في كل إصدارة جديدة، لذا فإنك تطلق إصدارات بشكل متكرر لتحصل على المزيد من التصحيحات، و كتأثير إيجابي جانبي فإنك لن تخسر الكثير في حالة خروج عمل غير متقن بين حين وآخر.

هذه هي، وهذا يكفي، فإذا كان “قانون لينوس” غير صحيحا، فإن أي نظام يقوم بتطويره نفس العدد الذي يطور النواة وفي عمق تعقيد نواة لينكس ؛ فإنه - في نقطة ما - سينهار بفعل وزن التداخلات السيئة غير المرئية و العلل العميقة غير المكتشفة، و إذا كان قانون ليونس صحيحا في الجانب الآخر ؛ فإنه يكفي لتفسير خلو لينكس النسبي من العلل و استمراره في العمل لمدة أشهر أو حتى سنوات.

و ليس من المفترض أن نستغرب ذلك ، فمنذ سنوات اكتشف علماء الاجتماع أن متوسط رأي مجموعة كبيرة من المراقبين ذوي نفس المستوى من الخبرة أكثر مصداقية في التوقع من رأي مراقب واحد مختار بشكل عشوائي، وقد أطلقوا عليه تأثير دلفي Delphi، و يبدو أن ما أظهره لينوس هو أن هذا التأثير ينطبق حتى على تنقيح نظام تشغيلي، تأثير دلفي يستطيع ترويض التعقيد حتى لو كان مستوى التعقيد هو نواة نظام تشغيلي.

واحدة من أهم خصائص لينكس و التي ساعدت مع مبدأ دلفي بوضوح هي حقيقة أن اختيار المساهمين لأي مشروع كان اختيار ذاتيا. و قد أوضح أحد المتحدثين الأوائل هذا حيث أن المساهمات و المشاركات لا تأتي من مجموعة عشوائية بل من أناس عندهم الاهتمام الكافي لاستخدام البرنامج و تعلم كيفية استخدامه، و محاولة إيجاد الحلول للمشاكل التي تواجههم، وفي الواقع حتى إنتاج رقعة إصلاحية مقبولة. غالباَ كل من يعبر هذه المرشحات سيكون لديه شيء جيد ليساهم به.

يمكن إعادة صياغة قانون لينوس كالتالي ” التنقيح عملية متوازية“ فبالرغم أن التنقيح يتطلب من المنقحين أن يتواصلوا بدرجة ما مع المطور المشرف، لكنه لا يتطلب تنسيقا كبيرا بين المنقحين أنفسهم، فلذا لا يقع التنقيح ضحية التعقيد و مصاريف الإدارة المضاعفة التي تجعل إضافة مطورين مشكلة.

وفي الواقع ؛ فإن الخسارة النظرية للكفاءة بسبب تكرار عمل المنقحين في الغالب لم تكن مشكلة في عالم اللينكس، إن أحد تأثيرات سياسة ” أطلق مبكرا، و أطلق بشكل متكرر“ هو تقليل مثل ذاك التكرار بواسطة تسريع عملية قبول الإصلاحات.

حتى أن Brooks (مؤلف كتاب The Mythical Man-Month) وضع ملاحظة ليست بعيدة عن هذا الموضوع حيث قال :” إن التكلفة الإجمالية لصيانة برنامج مستعمل بشكل واسع تساوي 40% أو أكثر من كلفة تطويره، و بشكل مدهش فإن هذه الكلفة تتأثر بشدة بواسطة عدد المستخدمين، فكلما زاد عدد المستخدمين زاد عدد العلل المكتشفة“

كلما زاد عدد المستخدمين زاد عدد العلل بسبب أن زيادة عدد المستخدمين تضيف طرق أكثر لاختبار البرنامج، و يتعاظم هذا التأثير عندما يكون المستخدمين شركاء في التطوير، حيث أن كل واحد يؤدي مهمة تشخيص العلة بخلفيات و افتراضيات و أدوات مختلفة قليلا و من زوايا متعددة، و يبدو أن تأثير دلفي يعمل بشكل دقيق بسبب هذا التباين. و في سياق الخاص بالتنقيح، فإن هذا التباين يميل إلى تقليل تكرار الجهود.

لذا فإن زيادة عدد مختبري البيتا قد لا يؤدي إلى تقليل تعقيد “أعمق” علة موجودة من وجهة نظر المطور، ولكنه يزيد من احتمالية أن أدوات شخص ما ستتوافق مع المشكلة بطريقة ما تصبح معها العلة سطيحة لذاك الشخص.

لم ينس لينوس أن يحمي رهاناته، ففي حالة وجود علل خطيرة، فإن إصدارة نواة لينكس ترقم بطريقة يستطيع المستخدمون المحتملون أن يختاروا بين تشغيل آخر إصدارة مستقرة أو ركوب الحواف الحرجة و العلل الخطيرة من أجل الحصول على مزايا جديدة، وهذا التكتيك لم يقلده أغلب هكر اللينكس بشكل نظامي، ولكن ربما يجدر بهم ذلك، وحقيقة وجود كلا الخيارين على حدة، يجعل كلاهما أكثر جاذبية.

كم من العيون تكبح التعقيد :

يمكن ملاحظة شيء واحد في الصورة الكبيرة، وهو أن أسلوب السوق يسرع بشكل عظيم عملية تنقيح و تطوير الشفرة، ومن المهم أن نفهم بالضبط كيف ولماذا يفعل ذلك على المستوى الجزئي للمطور و سلوك المختبر. سنأخذ في هذا الفصل (الذي كتب بعد ثلاث سنوات من طرح الورقة الأصلية؛ باستخدام آراء المطورين الذين قرأوا هذه الورقة و أعادوا اختبار سلوكهم ) نظرة عميقة للآلية الحقيقية، مع ملاحظة أن القراء الذين لا يميلون لقراء الأشياء التقنية يمكنهم تخطي هذا الفصل بأمان.

إحدى طرق الفهم هي إدراك بالضبط لماذا أن نوع تقارير العلل الذي يأتي من المستخدمين غير المطلعين على الشفرة يكون غير مفيد بدرجة كبيرة؛ حيث يميل المستخدمين غير المطلعين على الشفرة أن يبلغوا عن الأعراض السطحية و يفترضون أن البيئة التي يعملون عليها هي السائدة ؛ فلذا يقومون أ) بحذف خلفيات المشكلة المهمة، و ب) نادرا ما يقدموا وصفة موثوقة لكيفية إعادة إنتاج العلة.

المشكلة الأساسية هنا هي عدم التوافق بين النموذج العقلي للبرنامج بين المطورين و المختبرين، حيث ينظر المختبرون من الخارج إلى الداخل، بينما ينظر المطورون من الداخل إلى الخارج. وفي نموذج تطوير الشفرات المغلقة يصبح كلاهما عالقا في هذه الأدوار، ويميل كل طرف إلى أن يتجاهل الطرف الآخر، و يجد كلا الطرفين أنهما محبطين بدرجة عميقة.

يكسر التطوير المفتوح المصدر هذا الحاجز، جاعلا من السهولة لكل من المطور و المختبر تطوير أرضية تمثيل مشتركة للشفرة الكود الحقيقية و التواصل بشكل فعال حولها. عمليا، هناك فرق شاسع في التأثير على المطور بين ذلك النوع من تقارير العلل الذي يبلغ عن المشاكل الخارجية التي تظهر بشكل سطحي، و بين ذلك النوع الذي يعلق بشكل مباشر على التمثيل العقلي لبنية الشفرة المصدرية لدي المطور حول البرنامج.

في معظم الأوقات ، معظم العلل يسهل اكتشافها بسهولة حتى لو لم تكن مكتملة لكنها مشخصة بشكل تدل على شروط الخطأ على مستوى الشفرة المصدرية. فعندما يقوم شخص ما من بين مختبرين البيتا لبرنامجك بتوضيح أن ” هناك مشكلة حدودية في السطر ص “ أو حتى ” تحت شروط س و ص و ز ، هذا المتغير يظهر خطأ “ فنظرة سريعة على الشفرة المسببة للخطأ في العادة كافية لاكتشاف نمط الفشل بالضبط و إنشاء رقعة إصلاحية له.

وبالتالي ، فإن معرفة الشفرة المصدرية من كلا الفريقين تحسن بشكل كبير كل من طريقة التواصل الجيدة والتعاون بين تقارير مختبري البيتا و بين ما يعرفه المطور(ون) الأساسي(ون). في المقابل، فهذا يعني أن وقت المطورين الأساسين يميل إلى أن يحافظ عليه بشكل جيد حتى مع وجود العديد من المشاركين.

أحد خاصيات طريقة تطوير المصادر المفتوحة والتي تحافظ على وقت المطور هي بنية التواصل في مشاريع مفتوحة المصدر النموذجية. استخدمت عبارة ” المطور الأساسي “ سابقا، وهذا يعكس الفرق بين نواة المشروع ( في العادة صغيرة نوعا ما، مطور واحد في الغالب، وواحد إلى ثلاثة في العموم) وبين ما يحيط بالمشروع من مختبري البيتا والمشاركين متوفرين ( في العادة أعداد بالمئات).

المشكلة الأساسية التي تواجه مؤسسة تطوير البرمجيات التقليدية هي قانون بروك Brook's Law والقائل: “زيادة مبرمجين إضافيين إل مشروع متأخر يجعل منه أكثر تأخرا”. وبأكثر عمومية، يتوقع قانون بروك أن تعقيد و تكاليف التواصل لمشروع ما ترتفع مع مربع عدد المطورين، بينما يزيد مقدار العمل المنجز بشكل خطي فقط.

وُجِدَ قانون بروك من تجربة أن العلل تتجه بقوة إلى التجمع حول الواجهات بين الشفرة المكتوبة بواسطة أشخاص مختلفين، وبين تكلفة التواصل/ التنسيق حول مشروع ما تتجه إلى الارتفاع مع عدد الواجهات بين الناس. لهذا، ترتفع المشاكل مع عدد طرق التواصل بين المطورين، لأنها تقاس بمربع عدد المطورين ( وللمزيد من الدقة، طبقا للمعادلة N*(N - 1)/2 حيث N هو عدد المطورين).

يعتمد تحليل قانون بروك (والخوف الناتج من الأعداد الكبيرة في مجموعات التطوير) على فرضية مخفية وهي: أن بنية التواصل للمشروع هي بالضرورة صورة مكتملة، بحيث أن كل شخص يتحدث إلى أي شخص آخر. ولكن في المشاريع مفتوحة المصدر، يعمل المطورون المحيطون بالمشروع على مهام فرعية متوازية وقابلة للفصل و يتفاعلون مع بعضهم البعض بندرة، وتنشر تغييرات الشفرة و تقارير العلل من خلال مجموعة النواة، وفقط بداخل مجموعة النواة الصغيرة نحن ندفع تكلفة قانون بروك كاملة.

ما زال هناك المزيد من الأسباب التي تجعل تقارير العلل على مستوى الشفرة المصدرية أكثر إفادة وتأثيرا. وهي تتمركز حول الحقيقة أن الخطأ الواحد يمكن في العادة أن يملك عدة أعراض ممكنة، ويظهر بأشكال مختلفة تعتمد على التفاصيل نموذج استخدام العميل وبيئته. تتجه مثل هذه الأخطاء لأن تكون من نوع تلك العلل المعقدة و الماكرة ( مثل أخطاء إدارة الذاكرة دينامكية) والتي من الصعب إعادة إنتاجها أو اكتشافها بواسطة التحليل الثابت، و تخلق في الغالب مشاكل طويلة المدى في البرمجيات.

المختبر الذي يرسل توصيف غير مؤكد على مستوى الشفرة المصدرية لعلة متعددة الأعراض (مثل “إنه يبدو لي أن هناك نافذة في إدارة الإشارة قرب السطر 1250” أو “أين تصفر ذلك الدفق؟”) يمكن أن يعطي المطور، أو حتى قريب جدا من الشفرة لنظر فيها، الدليل الحاسم إلى نصف الأعراض متباينة. في مثل هذه الحالات، يمكن أن يكون من الصعب أو حتى المستحيل معرفة أي الظواهر الخاطئة عن علة بحد ذاتها. ولكن مع الإصدارات المتكررة، ليس من الضرورة معرفتها. سيطمح المشاركون الآخرون في العادة إلى البحث بسرعة: هل عللهم قد حلت أم بعد. في العديد من الحالات، تقارير العلل على مستوى الشفرة ستسبب بإيقاف السلوكيات الخاطئة من دون الحاجة إلى توصيفها إلى أي إصلاح محدد.

تنحو الأخطاء المعقدة ومتعددة الأعراض أيضا إلى امتلاك طرق اقتفاء متعددة من الأعراض السطحية رجوعا إلى العلة الحقيقة. ويمكن لطرق الاقتفاء المعطاة للمطور أو المختبر والتي نستطيع من خلالها اقتفاء العلة أن تعتمد على دقة بيئة ذلك الشخص، و يمكن أيضا أن تتغير عبر الوقت بطريقة غير ملحوظة. وكنتيجة لهذه، كل من عينات المطور و المختبر تعامل كمجموعة عشوائية لحالة البرنامج وترتب عند البحث عن مسببات العرض. وكلما كانت العلة معقدة و غامضة، كان الاحتمال أقل بأن المهارة ستكون قادرة على تأكيد الصلة بتلك العينة.

للعلل البسيطة والسهلة والقابلة للإنتاج، إذن، فإن التركيز سيكون على “الجزئي” بدلا عن العشوائي، و خبرة التنقيح والألفة مع الشفرة ومعماريتها ستكون مؤثرة جدا. ولكن في حالة العلل المعقدة، فإن التركيز سيكون على ” العشوائي“. وتحت هذه الظروف العديد فإن كثرة الأفراد الذي يشغلون المتتبعات سيكون أكثر تأثيرا من الأفراد القليلون الذي يشغلون المتتبعات بشكل متسلسل حتى لو امتلك هؤلاء القلة مستوى في المهارة أعلى من المتوسط.

سيكون هذا المؤثر عظيما إذا كانت صعوبة متابعة طرق التتبع من الأعراض السطحية المختلفة رجوعا إلى العلة تتفاوت بشكل ملحوظ في طريقة لا يمكن توقعها بواسطة النظر في الأعراض. فالمطور الواحد الذي يعاين هذه الطرق تسلسليا سينحو بشكل متوقع إلى اختيار أصعب طريق للتتبع في المحاولة الأولى بدلا عن أسهلها. في المقابل، وبافتراض أن العديد من الأفراد يحاولون تتبع الطرق بطريقة متوازية من خلال عمل إصدارات سريعة. لذا فمن المحتمل أن أحدهم سيجد أسهل طريق فورا، و يصطاد العلة في أقصر وقت. وسيلاحظ مدير المشروع أن إطلاق إصدارة جديدة، وبقية الناس يعملون على التتبع لنفس العلة سيمكنه من إيقافها قبل أن يبذل وقتا طويلا على طرق تتبعها الأكثر صعوبة.

متى تكون وردة ليست بوردة؟ :

بعد أن درست سلوك لينوس و كونت نظرية حول نجاحه، اتخذت قرارا واعيا بأن أختبر هذه النظرية على مشروعي الجديد ( أعترف بأنه أقل تعقيدا وطموحا).

أول شيء قمت به هو إعادة تنظيم popclient و تبسيطه بدرجة كبيرة. كان تطبيق كارل هاري جيدا ولكنه يعرض نوعا من التعقيد غير الضروري الشائع للعديد من مبرمجي لغة سي. لقد عالج الشفرة كمركز و هيكل البيانات كمساعد للشفرة. وكنتيجة لهذا، كانت الشفرة جميلة ولكن تصميم هيكل البيانات كان مخصصا لغاية واحدة بل أنه قبيح (على الأقل بالنسبة إلى المعايير العالية لهذا المخضرم الهاكر بلغة LISP ).

وعلى كل حال، كان لي هدف آخر من إعادة كتابة البرنامج بالإضافة إلى تحسين الشفرة وتصميم هياكل البيانات، وهو أن أطور شيئا أنا أفهمه بالكامل، لأنه ليس ممتعا أن تكون مسؤولا عن إصلاح العلل في برنامج أنت لا تفهمه.

للشهر الأول أو نحو ذلك، كنت ببساطة أتابع نتائج تصميم كارل الأساسي. وكان أول تغيير مهم هو إضافة دعم IMAP. قمت بذلك بواسطة إعادة تنظيم آلية البرتوكول بداخل تعريف عام و ثلاثة جداول للمهام ( لأجل POP2 وPOP3 وIMAP). هذا التغيير والتغييرات السابقة رسمت مبدأ عاما من الجيد للمبرمجين أن يبقوه في أذهانهم، وخصوصا في لغة مثل سي والتي لا تقوم بالأنواع الدينامكية بشكل طبيعي:

  • 9- هياكل بيانات ذكية و شفرة غبية تعمل بشكل أفضل من الطرق الالتفافية الأخرى.

من كتاب Brooks الفصل 9:” أرني رسمك البياني و أخف جداولك، سأرتبك بلا شك. الآن أرني جداولك، ولن أحتاج في العادة إلى رسمك البياني، لأنها ستكون واضحة بنفسها.“ سمحت لثلاثين سنة من الإصطلاح والثقافة بأن تتغير، إنها نفس النقطة.

في هذه النقطة ( بداية سبتمبر 1996، حوالي ستة أسابيع من البداية)، بدأت بالتفكير بأن الاسم في طريقة إلى التغيير، لأنه على كل حال لم يصبح عميل POP فقط من الآن. ولكني ترددت؛ بسبب أنه لم يكن هناك شيئا بحق جديدا في التصميم. كان على نسختي من popclient أن تطور هويتها الخاصة.

لقد تغير ذلك، بشكل أساسي، عندما تعلم popclient كيف يمرر البريد المجلوب إلى منفذ SMTP. سأشرح ذلك بعد قليل، ولكن أولا: قلت سابقا بأني فكرت في استخدام هذا المشروع لاختبار نظريتي حول تصرفات ليونس تورفالدس. قد تسأل كيف طبقت نظريتك؟ بهذه الطرق:

  1. أطلقت مبكرا و بشكل متكرر ( في العادة ليس أقل من من عشرة أيام، وفي مدة التطوير المكثف، مرة في اليوم).
  2. تنمية قائمة البيتا التابعة لي بواسطة إضافة أي شخص يتصل بي حول fetchmail إليها.
  3. أرسلت إعلانات مهذارة، إلى قائمة البيتا عندما أطلق أي إصدارة، مشجعا الناس على المشاركة.
  4. استمتعت إلى مختبري البيتا، أستطلع آرائهم حول قرارات التصميم، وأشجعهم كلما أرسلوا إصلاحات أو آراء.

كانت النتيجة من هذه الإجراءات البسيطة فورية. فمن بداية المشروع، حصلت على تقارير متعلقة بالجودة يرغب معظم المطورين بتلافيها، وفي العادة مع إصلاحات جيدة مرفقة بها، وحصلت على نقد بناء علمي، و حصلت على بريدا تشجيعيا، وحصلت أيضا على اقتراحات لمميزات ذكية، مما يقودنا إلى:

  • 10 - إذا عاملت مختبري البيتا التابعون لك وكأنهم أثمن الموارد، فإنهم سيستجبون بأن يصبحوا أثمن الموارد لك.

أحد المقايس ذات الاهتمام لنجاح fetchmail هو الحجم الكبير لقائمة البيتا التابعة للمشروع (أصدقاء fetchmail). ففي آخر مراجعة لهذه الورقة( نوفمبر 2000) كانت تضم 287 عضوا و تزداد بمعدل شخصين إلى ثلاثة أسبوعيا.

في الحقيقة، عندما راجعت القائمة في أواخر مايو 1997 وجدت أن القائمة بدأت بفقدان أعضائها من ارتفاع يقارب 300 بسبب الاهتمام. كثير من الأفراد سألوني إلغاء اشتراكاتهم بسبب أن fetchmail كان يعمل بشكل جيد لهم وأنهم لا يرغبون برؤية رسائل القائمة المزدحمة بعد الآن. ربما أن هذا جزء من دورة الحياة العادية لمشروع ناضج في نظام السوق.

Popclient يصبح Fetchmail :

كانت نقطة التحول الحقيقة في المشروع عندما أرسل لي هاري هوشهيسر شفرته الجيدة لإعادة توجيه البريد إلى منفذ SMTP في جهاز العميل. لقد أدركت بسرعة أن أي تطبيقا موثوقا على هذه الميزة سيجعل كل أنماط توصيل البريد الأخرى في طي الهجران.

لعدة أسابيع التي ظللت أحسّن فيها fetchmail بدلا عن أن أزيد عليه شعرت بأن تصميم الواجهة كان مفيد ولكنه كان غير مقبولا أو جذابا بالإضافة إلى خياراته الهزيلة التي تستهلك وقتا في جميع أجزاءه. كانت خيارات جلب البريد إلى ملف صندوق البريد أو طريقة الخرج القياسية بالتحديد تضايقني، ولكني لم أستطع أفهم لماذا؟

( إذا لم تكن مهتما بالتفاصيل التقنية للبريد عبر الانترنت، يمكنك تخطي الفقرتين التاليتين بأمان)

ما الذي وجدته عندما فكرت حول تمرير SMTP أن popclient كان يحاول أن يعمل الكثير من الأشياء. لقد صمم لأن يكون عميلا لنقل للبريد (MTA) و عميلا للتوصيل المحلي (MDA) معا. لكن مع تمرير SMTP يمكن الاستغناء عن عملية MDA و أن يكون خالصا كـ MTA، بحيث يوصل البريد إلى البرامج الأخرى للتوصيل المحلي مثلما يفعل sendmail بالضبط.

لماذا نخوض في كل تعقيدات تشكيل عميل توصيل البريد أو إعداد عميلة قفل وإلحاق على صندوق البريد عندما يكون منفذ 25 متوفرا بشكل مضمون على أي منصة مع دعم برتوكول الشبكات TCP/IP في المقام الأول؟ وخصوصا عندما يعني هذا أن البريد المجلوب مضمون بأن يمثل شكل البريد الطبيعي الصادر من المرسل SMTP، وهو ما نريده بالفعل على كل حال.

( عودة إلى مستوى أعلى…)

حتى ولم تكن قد تابعت المصطلحات التقنية السابقة، فإن هناك العديد من الدروس المهمة. أولا، كانت فكرة تمرير SMTP أكبر فائدة حصلت عليها من تجربة المدركة من محاكة طرق ليونس. مستخدم أعطاني هذه الفكرة الرائعة، وكل ما كان عليه أن أفعله هو فهم النتائج.

  • 11- الشيء المفضل التالي لامتلاك أفكار جيدة هو إدارك الأفكار الجيدة من مستخدميك. في العادة الأخير هو الأفضل.

ومن المثير للاهتمام، أنك سرعان ما تجد أنه إذا كنت صادقا بالكامل وغير مخادع لنفسك حول مديونيتك للناس الآخرين، فإن العالم بأسره سيعاملك كما لو أنك قمت بكل جزئية من الاختراع بنفسك، وأنك فقط بدأت تصبح متواضعا حول عبقريتك الفطرية. يمكننا جميعا أن نرى نجاح هذا مع ليونس!

(عندما كنت ألقي كلمتي في أول مؤتمر لبيرل في أغسطس 1997، كان الهاكر الرائع لاري وال جالسا في الصف الأمامي. وحالما وصلت إلى آخر سطر بالأعلى، نادى عاليا بأسلوب صحوة دينية، ” قلها، قلها، أخي!“. ضحك كل الحاضرون لأنهم يعلموا أن هذه حدثت أيضا مع مخترع بيرل.)

بعد أسابيع قليلة من العمل بنفس الحيوية، بدأت بالحصول على مديح مشابه ليس فقط من مستخدمين البرنامج بل أيضا من أناس آخرين ممن وصلهم المديح. أخفيت بعض تلك الرسائل لأنظر إليها مرة أخرى في العادة عندما أبدأ أسائل نفسي ما إذا كانت حياتي مفيدة أو مهمة :-).

ولكن كان هناك درسين أساسين إضافيين غير سياسيين عاميين لكل أنواع التصميم.

  • 12- في العادة، أغلب الحلول الابتكارية والمميزة تأتي من إدراكك بأن فكرتك حول المشكلة كانت خاطئة.

لقد كنت أحاول أن أحل المشكلة بواسطة الاستمرار في تطوير popclient كمجموعة مكونة من MTA/MDA مع كل أنواع أنماط التوصيل المحلي المتنوعة. لقد احتاج تصميم Fetchmail أن يعاد التفكير به من الأساس كوحدة MTA خالصة، كجزء من تخاطب SMTP العادي لطريق البريد عبر الانترنت.

عندما ترتطم بحاجز أثناء التطوير- عندما تجد نفسك في وضع صعب أن تفكر في الإصلاح القادم-، فإنه الوقت المناسب عادة لأن تسأل ليس ما إذا كنت قد حصلت على الجواب الصحيح، بل هل أنت تسأل السؤال الصحيح؟ فلربما أن المشكلة تحتاج أن تعاد صياغتها.

حسنا، لقد أعدت صياغة مشكلتي. وبوضوح فإن الشيء الذي من المفترض أن نفعله (1) جعل دعم تمرير SMTP على شكل تعريف عمومي، (2) وجعله النمط الافتراضي، (3) وأخيرا استبعاد كل أنماط التوصيل الأخرى، وخصوصا التوصيل إلى ملف و خيارات التوصيل إلى الخرج القياسي.

لقد ترددت حول الخطوة الثالثة لبعض الوقت، خوفا من إزعاج مستخدمين popclient القدامى والذين يعتمدون على آلاليات توصيل بديلة. ونظريا، يمكنهم بشكل فوري التحول إلى ملفات .forward أو ما يكافئها للأنظمتهم التي ليست على نمط sendmail للحصول على نفس النتيجة. وعمليا، يمكن أن تصبح عملية التحول فوضوية.

ولكن عندما طبقتها، أثبتت فوائد ضخمة. لقد اختفت الأجزاء ضعيفة البنية من شفرة التعريف. والإعدادات أصبح أبسط بشكل جذري، ولا داعي للحلول الالتوائية بعد الآن من أجل نظام MDA و صناديق بريد المستخدمين، ولا داعي للقلق حول ما إذا كان النظام المضيف يدعم قفل الملفات.

أيضا لقد اختفت الطريق الوحيدة للفقدان البريد، حيث إن كنت قد حددت طريقة التوصيل إلى ملف و حدث أن القرص الصلب امتلء بالكامل، فإنك ستفقد بريدك. هذا سيناريو لن يحدث مع طريقة تمرير SMTP بسبب أن متنصت SMTP لن يرجع رسالة الموافقة ما لم يكن إيصال الرسالة ممكنا أو على الأقل يخزنها مؤقتا لتوصيلها في وقت لاحق.

أيضا، لقد تحسن الأداء (بالرغم أنك لن تلاحظه من تشغيلة واحدة). وفائدة أخرى وإن كانت غير جلية لهذا التغيير أن صفحة التعليمات أصبحت أبسط بشكل كبير.

لاحقا، أرجعت ميزة التوصيل عبر MDA المحلي المخصص من أجل السماح بإدارة بعض الحالات الغامضة الناتجة عن SLIP الحركي. ولكني وجدت طريقة أبسط بكثير لبرمجتها.

ما المغزى من هذا؟ لا تتردد باستبعاد المميزات القديمة وغير الصالحة عندما تستطيع أن تبرمجها من دون فقدان التأثير. يقول أنطوان دو سانت إكسبري(والذي كان طيارا ومصمم طائرات عندما كان لا يألف كتب الأطفال الكلاسيكية):

  • 13-” لا يتحقق الإتقان (في التصميم) عندما لا يوجد شيئا لإضافته، بل عندما لا يوجد شيئا لإزالته.“

عندما تصبح شفرتك أفضل وأبسط، عندها تعرف أنها صحيحة. وفي هذه العملية، اكتسب fecthmail هويته الخاصة، مختلفا عن سلفه popclient.

لقد حان الوقت لتغيير الاسم، لقد أصبح التصميم الجديد يشبه sendmail أكثر مما يشابه popclient القديم، فكلاهما MTA، ولكن حيث أن سندميل يدفع الرسائل ثم يوصلها، فإن بوبكلاينت الجديد يسحب الرسائل ثم يوصلها. لذا بعد شهرين أعدت تسميته إلى فتشميل fetchmail.

هناك درس عام في هذه القصة حول كيفية وصول آلية SMTP إلى فيتشميل. إنه ليس فقط عملية التنقيح متوازية، بل أيضا التطوير و (إلى حد ربما يثير الدهشة) استكشفاف فضاء التصميم. عندما يكون نمطك في التطوير يتكرر بشكل سريع، فربما يصبح التطوير والتحسين حالات خاصة من التنقيح – إصلاح العلل المغيبة في القدرات أو فكرة البرنامج الأصلية.

حتى في مستوى أعلى من التصميم، يمكن أن يكون قيّما للغاية أن تمتلك الكثير من شركاء التطوير يتجمعون عشوائيا حول فضاء التصميم بالقرب من منتجك. فكر بجدول لبركة من الماء وجد مصرفا، أو بشكل أفضل كيف تجد النمل طعامها: الاستكشاف عن طريق الانتشار بشكل أساسي، تليها استكشاف موسط عن طريق آلية تواصل متوسعة. هذا ينجح بشكل جيد جدا، كما هو الحال معي وهاري هوشهيسر، ويمكن لأي أحد ممن هم حولك أن يجد نجاحا كبيرا من حولك، بحيث أنك كنت بحاجة إلى القليل من التركيز لرؤيته.

فيتشميل ينمو :

لقد كنت مع تصميم أنيق ومبتكر، وشفرة التي أعرفها تعمل بشكل جيد لأني أستخدمها كل يوم، وقائمة بيتا نامية. وشيئا فشيئا بدأ يتضح لي بأنني لم أعد أشارك في هاكات شخصية سهلة والتي قد يحدث أنها تكون مفيدة للبعض. لقد وضعت يدي على برنامج يحتاجه بشكل فعلي كل هاكر معه نظام يونكس و اتصال بريدي SLIP/PPP.

وبميزة تمرير SMTP، أمكن له أن يسبق منافسيه بمراحل ليصبح برنامجا متفوقا (قاتل)، وهذا البرنامج يفي بحاجة المستخدم بشكل دقيق بحيث لا يهمش البدائل الاخرى فحسب بل يغيبها تماما.

اعتقد انك لاتستطيع ان تخطط لهذا الشي, بل يجب ان تنجذب له من واقع تصميم محكم وجبار بحيث تصبح النتيجة محتومة (لامفر منها) بل و مقدرة. و الطريقة الوحيدة لمحاولة شيء كهذا هو ان يكون لديك الكثير من الافكار, و الفراسة الهندسية لكي تاخذ هذه الفكرة ابعد مما كان المستخدم ينوي.

كان Andy Tanenbaum يحمل الفكرة الاصلية لبناء حاسب بسيط يعمل على يونكس Unix للحواسيب الشخصية لـ IBM, للاستخدام كادوات للتعليم (اسماها مينكس Minix).. فقام.ليونس ترافلدس Linus Torvalds بدعم تصميم مينكس Minix اكثر مما كان Andy Tanenbaum يتوقع او ينوي, و فعلا نما ليصبح شيءرائع. على نفس المسار اخذت بعض الافكار من Carl Harris و Harry Hochheiser و دفعت هذه الافكار ابعد مما نوى الاثنين و اتبعت مذهب الاختراق للتحسين hacker mythology و لم يكن اي منا من يعمل بالطريقة العاطفيه التي ينظر بها الناس الى العبقرية و لذلك معظم العماء والمهندسين و المطورين اعمالهم لم تكن اوليه .. كانت النتائج عنيدة بعض الشي في الواقع, ولكن نتج عنه النجاح الذي يطمح اي مطور او مخترق بالوصول اليه. و هذا يعني انه لابد من وضع معايير اعلى للوصول بــ fetchmail الى مستوى الجودة الذي اصبحت استوعبه, و لابد من تطوير البرنامج ليس فقط لحتياجاتي بل ايضا لحتياجات المستخدمين خارج مداري, مع البقاء على بساطة الواجه وسهولة الاستخدام.

أول وأهم ميزة ساحقة كتبت بعد تحقيق هذا الدعم كانت multidrop القدرة على جلب البريد من الصناديق التي تحتوي على تراكمات البريد كله لمجموعة من المستخدمين ، ومن ثم توجيه كل قطعة من البريد إلى المستلمين مباشرة.

قررت اضافة دعم multidrop وذلك لأن المستخدمين كانوا يطالبون به ولسبب اخر ايضا وذلك انني كنت ميقن من ان هذا سوف يظهر علل مختفية حتى الان. و هذا ماحدث معي فعلا. فحصولي على عنوان حق الاعراب RFC 822 اخذ مني وقت طويل جدا, ليس لأنني بطيء و لكن لوجود تفاصيل كثيرة مترابطه مع بعضها البعض..

و لكن ثبت اخيرا ان اختيار عنونة multidrop كان قرارا ممتازا, واليكم التفاصيل :

14. اي اداة جيدة يجب ان تفيد المجال الذي تستخدم به , ولكن الاداة الممتازة هي التي يمكن الاستفادة منها في اشياء كثيره لا تخطر علي البال.

الاستخدام الغير متوقع لــ multidrop في fetchmail هو لتفعيل قوائم البريد بينما لا تزال القائمة موجودة , و تفعيل الاسماء المعرفة للبريد alias على جهاز العميل باستخدام شبكات الانترنت.و هذا يعني ان المستخدم يستطيع من خلال جهازه الشخصي ان يدير قوائم البريد بدون اتصال مستمر مع ملفات الاسماء المعرفة للبريد alias عن طريق حساب من موفر خدمة الانترنت.. وهناك تغيير اخر مهم تم بواسطة المختبرين للنسخة الاولية فهم يوفرون الدعم لعمليات 8-bit MIME Multipurpose Internet Mail Extensions) . كان هذا امرا سهلا, لاني كنت حذر في اضافة دعم منسق لــ 8-bit في الشفرة (هذا لكي لا نستخدم البت الثامن 8th bit, و الذي لايستخدم في حروف الاسكي ASCII. لنقل المعلومات داخل البرنامج) ليس لاني توقعت ان الطلب عالي على هذه الخاصية. و لكن لكي استجيب لطلب اخر.

15-عند تصيمم برنامج يعمل كبوابة gateway لابد من تحمل مشاق توزيع المعلومات باقل طريقة ممكنة, وعدم التخلص من اي معلومات اطلاقا , الا اذا اجبرك المستقبل على ذلك.

لم انصاع لهذا التطبيق من قبل, الدعم لــ 8-bit MIME كان شاقا و مليء بالعيوب, و كل ما فعلته هو قرائة معايير (RFC 1652) و اضافة تعليل بديهي في المقدمة header-generation logic

بعض المستخدمين في اوروبا طلبوا مني اضافة خاصية الحد من عدد الرسائل المستقبلة في كل جلسة (لكي يتحكمون في التكاليف الباهظة لاستخدامهم الانترنت) لقد قاومت هذا لفترة, و لا ازال غير راضي عن هذه الاضافة. ولكنك تقوم بالتصميم للعالم, فلابد من ان تستمع الى عملائك, و هذا لايتغير لانهم لايدفعون لك المال.

مزيد من الدروس في Fetchmail :

قبل ان نعود الى دروس هندسة البرمجيات, هناك المزيد من الدروس المحددة يمكن تعلمها من fetchmail (القراء الغير تقنيين يمكنهم ان يتجاوزون هذا الجزأ)

ملف التحكم ( rc control) يحتوي على جمل تداخل `noise' اختياريه والتي تهمش بالكامل من قبل المعرب parser. و تركيب الجمل syntax المسموح به (و الشبيه باللغة الانجليزية) يمكن قرائته الى حد كبير وايضا تتبع تركيب الجمل التقليدي والذي تحصل عليه من سلخ جميع المعلومات الاخرى. . هذه بدأت كتجارب تتم في اواخر الليل عندها ادركت مدى دلالات ملف ال rc و التي تمثل وجوب وجود لغة مصغرة ( minilanguage) ( ولهذا السبب قمت بــ popclient بتغير كلمة خادم ``server الى حلب `poll)

بدا يتضح لي انه اذا جعلنا هذه اللغة مبسطة minilanguage و شبيهه باللغة الانجليزية سوف يسهل استخدامها . مع العلم اني مقتنع بمدرسة اجعلها كاللغة “make it a language” مثل Emacs و HTML و كثير من محركات قواعد البينات, الا انني لست من مناصرين جعل “تركيب الجمل شبيه باللغة الانجليزية” .

عادة يفضل المطورون اتباع نهج تركيب الجمل syntaxes بشكل متقن و مختصر و بدون اسهاب على الاطلاق. وهذا كان تقليد متبع منذ ان كانت تكاليف الحوسبة باهضة, لذلك التوثيق كان لابد ان يكون بسيط و مختصر بقدر الامكان. واستخدام اللغة الانجليزية و التي تحتوي على اسهاب زائد عن الحاجة لم تكن مناسبة في وقتة ..

و لكن هذا لم يكن السبب الوحيد الذي جعلني اتجنب استخدام اللغة الانجليزية في تركيب الجمل syntaxes, اذكرها هنا فقط لكي اهدم هذا التصرف. مع وجود قلب ودورة للنظام بسيطة و رخيصة, الاختصار يجب ان لا يكون هو الغاية بحد ذاته. في هذه الايام من الملائم ان تكون اللغة مفهومة من قبل البشر اكثر من ان تكون رخيصه في الحوسبة.

و على اية حال الباقي يشكل اسبابا جيدة للقلق. الاول هو ثمن التعقيدات في مرحلة التوثيق, بحيث اننا لا نريد ان نتعمق بهذا بالاضافة الى امكانية وجود علل و بالتالي ستسبب ربكة للمستخدم. والثاني ان محاولة جعل لغة تركيب الجمل syntaxes تشبة االغة الانجليزية, يؤدي الى تحريف اللغة الانجليزية بشكل كبير الى درجة ان التحريف يجعلها تبدو كلغة طبيعية و لكن مربكة بسبب عدم و ضوح المعاني مما يعني ان هذا مثل او اسوأ من استخدام تركيب الجمل syntaxes التقليدي (نرى هذا القصور في ما يسمى بالجيل الرابع ” fourth generation” و لغة الاستعلام لقواعد البينات التجارية).

التحكم بتركيب الجمل syntaxes في fetchmail يجنبنا هذه المشاكل لأن نطاق اللغة كان محدودا جدا. بحيث انها بعيده كل البعد عن لغة الاستخدام العام و المعلومات الموثقة غير معقدة لذلك هنالك احتمال بسيط جدا ان يرتبك المستخدم بالتنقل بين مايذكر باللغة الانجليزية و بين لغة التحكم الاساسية. واعتقد ان هناك درس اكبر يمكن تعلمه هنا :

16-عندما تكون لغتك بعيدة عن الكمال استخدم التصريف اللغوي, و تعتبر هذه افضل طريقة.

ونتعلم هنا ايضا درس اخر عن الامن باستخدام الغموض, فقد طلب مني بعض مستخدمي fetchmail تغيير البرنامج لكي يكون باستطاعتهم ان يخزنوا كلمات السر على شكل شفرات في ملف rc لكي نمنع المتطفلون من ان يصلوا اليها.

ولكني لم اقم بذلك, لأنه لايوفر الحماية الحقيقية للبرنامج و باستطاعة اي شخص لديه الصلاحيه ان يطلع على ملف ال rc الخاص بك تشغيل برنامج fetchmail عوضا عنك, و اذا كان هذا المطلع يبحث عن كلمة السر الخاصة بك يستطيع ان يتعقب آلية فك التشفير التي يستخدمها البرنامج وبذلك يمكنه ان يطلع على كلمة السر الخاصة بك. و لو قمنا بتشفير كلمات السر في .fetchmailrc لكان هذا اعطى احساسا وهميا بالأمان لهؤلاء الذين لا يفكرون بعمق. فالقاعدة العامة هي:

17-النظام الامني يظل آمنا الى ان ينكشف سره, فاحذر من الاسرار الزائفه.

الشروط الضرورية المسبقة لنمط البازار (السوق) :

عندما قام الجمهور بالمراجعة الأولية لهذه الوثيقة تسائلوا باستمرار عن الشروط المسبقة لنجاح التطوير باستخدام نمط البازار (السوق) فيما يخص مؤهلات قائد المشروع و الحالة التي تكون عليها الشفرة المصدرية عن طرحها للعموم و كذلك محاولة بناء مجتمع مكون من شركاء في التطوير.

ولكن كان من الواضح من ان شخص واحد بمفرده لا يستطيع ان يطور (يبني) في نمط البزار (السوق) ولكنه بالمقابل يستطيع ان يختبر العلل و يحسن من نمط السوق (البازار) فكان من الصعوبة ان ينشيء شخص واحد مشروع في نمط السوق (البازار) ولينوس لم يفعل ذلك و لا انا ايضا. فالمجتمع حديث النشئة يحتاج الى برنامج قابل للاختبار لكي يتعاملوا معه.

عندما تبدأ ببناء مجتمع اهم ما تحتاج ان تطرحه هو وعود معقولة, فالبرنامج لا يحتاج ان يعمل بامتياز, فمن الممكن ان يكون غير ناضج او به علل و غير مكتمل, ورديء التوثيق. ولكن مايحتاجه هو ان يكون : اولا : ان يكون يعمل, و ثانيا: لابد من ان يكون مقنعا لشركاء التطوير بانه من الممكن ان ينمو و يتطور الى شيء جميل في المستقبل ..

لنكس و fetchmail طرحا للعموم وهما في حلة قوية و بتصميم بسيط و جذاب..و كثير من الناس يفكرون بنمط السوق (البازار) كما تم شرحه على اساس ان هذا حرج, واخيرا اكتشفوا ان التصميم الجيد, الحدس و الذكاء بالفطرة شروط لابد من توفرها بقائد المشروع

ولكن لينوس توصل الى هذا التصميم من يونكس Unix و انا اخذت تصميمي من popclient (مع العلم انه تغير لاحقا بشكل كبير, و كمية التغير الذي حدثت في popclient اكثر من التغير الذي حدث في لينكس) اذا هل من المهم ان يكون لدى قائد المشروع في نمط السوق (البازار) الموهبة لتقديم تصاميم فريدة؟ او القدرة على ادراك وادارة موهبة التصميم لدى الاخرين ؟

اعتقد انه من غير المهم ان يقوم قائد المشروع بأنشاء تصميم بالغ العبقرية, ولكن من المهم ان يكون قائد المشروع لديه القدرة على ادراك التصاميم الجيدة الممنوحة من الاخرين. فمشروعي لينكس و fetchmail دليل و اضح على صحة ما ذكر.

و كما ذكرنا سابقا لينوس لم ينشيء تصميم مدهش, و لكن كان لديه القدرة البديهية للتعرف على تصميم ممتاز, و على مكاملة هذا التصميم في قلب لينكس (linux kernel), و قد شرحت قبل ذلك كيف ان اهم فكرة تصميم في ( fetchmail SMTP forwarding) اتت من شخص اخر.

المطلعين الاولين لهذه الوثيقة تذمروا من ميلي لتقليل أهمية انشاء التصميم في نمط السوق (البازار) بحجة ان لدي خبرة كثيرة في هذا المجال, ولهذا اخذت الموضوع ببساطة,و قد يكون هذا صحيحا, فالتصميم (على عكس كتابة الشفرة او تحديد العلل) كانت هي اكبر موهبة لدي. و المشكلة في كونك شخص فطن ومبتكر في تطوير البرمجيات انها تصبح عادة لديك, فتبدأ بشكل انعكاسي في جعل الاشياء اجمل و اكثر تعقيدا, و لكنه من المفترض ان تجعل الاشياء اكثر بساطة و فعالية . فقد خسرت مشروعا قبل ذلك لأني ارتكبت هذا الخطأ و لكني تفاديت هذا في fetchmail.

لذللك كنت مؤمن ان مشروع fetchmail سينجح لاني كبحت جماح فطنتي, و هذا يناقض المقولة التي تقول ان اصالة التصميم مهمة جدا لنجاح مشروع في بيئة السوق (البازار) ولا ننسى ان نأخذ لنكس بعين الاعتبار. فتخيل ان لينوس حاول ان يقوم بعمل تطويرات جوهرية في تصميم نظام التشغيل خلال مرحلة التطوير هل كان من الممكن ان يكون الناتج هو النظام المستقر الناجح الذي نراه اليوم؟

و هناك قاعدة مهمه على مستوى التصميم وهي المهارة والمعرفة و كتابة الشفرة لدي مدير المشروع, ولكنني اتوقع ان اي شخص قد يفكر في اطلاق مشروع في بيئة السوق (البازار) لابد ان يكون لديه الحد الادنى. فمحركات مجتمع المصادر الحرة تمارس الضغط الرقيق لعدم البدأ بتطوير جزأية هم غير متمكنين منها. و هذا العمل حقق نجاحا باهرا حتى الان. كما ان هناك نوع اخر من المهارة غير مرتبط بتطوير البرمجيات و اللذي اعتقد انه اهم لبيئة السوق (البازار) وهيا لابد ان يتحلى اي مدير مشروع داخل بيئة السوق (البازار) بميزة ( مهارات الاتصال و حسن التعامل مع الناس ).

فكان من المهم استقطاب الناس من اجل بناء مجتمع تطويري, وترغيبهم فيما تريد ان تعمل. و ا ابقائهم سعداء عن حجم العمل اللذي يقومون به. فالمديح (لتقديم الرضى عن النفس) يخدم كثيرا هنا, و لكن هذا ليس كل شي, فالشخصية ايضا لها تأثير كبير.

انها ليست مصادفة ان لينوس هو رجل لطيف و عنده القدرة على ان يجعل الناس يحبونه و يرغبون في مساعدته, كما انها ليست مصادفة ان اكون انا رجل بسيط, ممتليء بالحيوية و استمتع بالعمل الجماعي و لدي القدرة على التقديم و الحدس الهزلي ( stand-up comic) لذلك عندما تكون لطيفا وتملك خاصية جذب الناس فانه يساعدك كثيرا في بيئة السوق (البازار) .

السياق الاجتماعي في البرمجيات الحرة:

مكتوب انه : افضل التطويرات (الاختراقات - hacks) تبدأ كحل شخصي لمشكلة ما يواجهها المؤلف, ثم تنتشر لانه يكتشف ان هذه المشكلة تؤثر على عدد كبير من المستخدمين.وهذا يأخذنا الى محتوى القانون (1), اعيدت صياغته بشكل اكثر عملية :

18-لحل مشكلة مثيرة للاهتمام ، لابد من إيجاد هذه المشكلة المثيرة للاهتمام اولا.

لذلك كان هذا مع Carl Harris و الموروث popclient و كذلك معي و مع fetchmail و لكن هذا كان معروفا منذ فترة طويلة. و النقطة المثيرة للاهتمام والتي قمنا بالتركيز عليها و التي تتشكل في تاريخ لنكس و fetchmail هي الخطوة القادمة والتي تتشكل في تطوير المشروع في ظل وجود مجتمع كبير وفعال من المستخدمين و شركاء التطوير.

في The Mythical Man-Month, لاحظ المؤلف Fred Brooks ان و قت المبرمج لايمكن استبداله و اضافة مطورين في وقت متأخر لمشروع تطوير برمجي يساهم في التاخير. وكما رأينا في السابق ان المؤلف قد ناقش التعقيدات وتكلفة التواصل المتنامية تبعا للجذر التربيعي لعدد المطورين وبالتالي العمل المنتج يزيد بشكل خطيّ .

و قد كان سابقا قانون بروكس قانونا مسلم به, ولكننا ناقشنا في هذه الوثيقة عدد من الطرق المنهجية التي اتبعت في نمط السوق (البازار) و التي تتناقض بشكل مباشر مع استنتاجات قانون Brooks's وفي الواقع لو كان قانون Brooks's صحيحا لكان و جود لنكس مستحيل.

مؤلفة Gerald Weinberg's الكلاسيكية The Psychology of Computer Programming افادت (انها ادركت متاخرا) والتي تعد تصحيح لــ Brooks في نقاشه ( المبرمجون الغير مغرورين) لاحظت Weinberg انه في المشاريع التي يكون فيها المبرمجون غير متشديدين على ملكية الشفرة و يحثون الاخرين على الاطلاع على الشفرة لمحاولة تحديد العلل وامكانية التعديل و التطوير يحدث بشكل مثير و اسرع من اي بيئة اخرى و(مؤخرا قام Kent Beck's بتطوير منهجية للبرمجة بحيث يتم توزيع المبرمجون بشكل زوجي و يمكن لكل مبرمج ان يطلع على عمل الاخر و يفسر ذلك بانهم اخذوا نفس المنحى المذكور)

لربما كانت الصياغة التي اختارها Weinberg's ادت الى عدم تقديرها بالشكل المستحق ان الواحد ليبتسم عند سماعه ان مخترقين الانترنت (غير مغرورين) ولكني أعتقد أن حجته تبدو اليوم أكثر إلحاحا من أي وقت مضى.

فتسخير القوة الكاملة للبرمجة “egoless” بطريقة البازار لها أثر شديد اضف الي ذلك التخفيف من تأثير بروكس في نمط السوق (البازار) عن طريق تسخير جملة من المبرمجين الغير مغرورين, والمبدأ خلف قانون Brooks يكون متناقض, فبوجود مجتمع تطوير كبير و بالاضافة الى وسيلة اتصال رخيصة يمكن ان نغمر المشروع بتنافس غير متعارض, و التي لايمكن توفرها بأي طريقة اخرى و هذا يشبه العلاقة بين الفيزياء النيوتينية (اسحاق نيوتن) و الفيزياء الاينشتانية (الفرد اينشتاين) فالنظام القديم لايزال فعال في ظل وجود طاقة متدنية, و لكن عندما تزيد الكتلة و السرعة الى مستوى عالي نحصل على مفاجئة مثل لنكس.

من المفترض ان يكون تاريخ لينكس قد اعدنا لما سوف نتعلمه اليوم من لينكس (و ما قمت باثباته بالتجارب على منسوب صغير, و الذي تعمدت فيه ان اتبع نهج لينوس) هذا يعني بينما يظل اسلوب كتابة الشفرة عمل انعزالي (فردي) ياتي التطوير العظيم من تسخير الطاقة العقلية لمجتمع كامل. و المطور الذي يعتمد على قدراته العقلية فقط و يطور مشروع في بيئة مغلقة بكل تأكيد سوف يتخلف عن الركب, و في المقابل المطور الذي يعرف كيف يكون مشروع حر و ثوري في المحتوى بحيث ردود الفعل تأتي بشكل استكشاف لتصميم او تبرع بشفرة و تحديد العلل, و ايضا تحسينات اخرى تأتي من مآت (بل الألآف احيانا) من المساهمين.

مع العلم ان عالم يونكس unix منع من الاستفادة القصوى من هذة الممارسة بسبب تعقيدات قانونية في التراخيص و بسبب اسرار ومصالح تجارية ايضا بالاضافه الى ذلك ان الانترنت لم تكن فعالة في وقتها .

و قبل و جود الانترنت الرخيص كان هنالك اسااليب تواصل مربوطة بالمنطقة الجغرافية, و التي كما قال Weinberg's ادت الى نمو تقاليد المبرمجين و المطورين بحيث حثت كثير من المؤهلين سواء مساهمين كانوا أم شركاء الى التطوير. و كما نرى اليوم ان Bell Labs, MIT AI , LCS labs, UC Berkeley اصبحت اساسا للابتكار و التطوير حتى يومنا هذا.

فلينكس كان اول مشروع يستفيد وبشكل واعي من الجهود و المواهب على مستوى العالم. و لا اعتقد انه كان من محض الصدفة ارتباط مراحل مخاض لينكس مع ظهور الشبكة العنكبوتية العالمية ( World Wide Web) و في نفس الوقت نمى لينكس من مرحلة الطفولة في 1993–1994 و التي شهدت تنامي واضح في صناعة موفري خدمة الانترنت ISP و انفجار الطلب على الانترنت من الجمهور. و كان لينوس هو اول من تعلم كيفية التعامل مع التنظيم الجديد و الذي اصبح ممكنا بتوفر خدمة الانترنت بشكل اوسع.

ومن العوامل الاساسية التي ادت الى تطور نظام العمل اللذي قام عليه لنكس توفر الانترنت بشكل رخيص ولكن لا اعتقد انه وحده كان كافيا, ولكن كان هناك عاملا اخر ساعد على ذلك على نفس القدر من الاهمية الا و هو تطوير اسلوب الادارة و مجموعة من العادات و اساليب التعاون و التي بدورها ساعدت المطورين على استقطاب شركاء في التطوير لتوزيع العمل و الاستفادة من الجهود و لكن ماهو اسلوب الادارة هذا؟ و ما هي العادات و الاساليب التي يجب اتباعها؟ فمن غير الممكن ان تكون الادارة مبنية على علاقة اساسها السلطة, و حتى لو كان هذا صحيحا فالقيادة التي تبنى على التعسف لا تستمر.

الكاتب Weinberg ينقل لنا عن السيرة الذاتية للثوري الروسي Pyotr Alexeyvich Kropotkin's في القرن التاسع عشر Memoirs of a Revolutionist مما ينعكس علي موضوعنا. :

بحكم انني نشأت في في اسرة تدير اعمالها بنفسها, اندمجت مبكرا في الحياة العملية مثل جميع الشباب في ذلك الوقت فقد كانت ثقتي بنفس كبيرة جدا و كانت لدي القدرة على التنظيم و كبح جماح رغباتي و ما الى ذلك, و لذلك بدأت و بسن صغير في ادارة العديد من المشاريع الكبيرة و بالطبع قمت بالتعامل مع العمالة “ الاحرار” فعند حدوث اي خطأ قد يؤدي ذلك الى عواقب وخيمة عندها بدأت اقدر الفرق بين مبدأ القيادة القائم على الامر و العقاب او مبدأ القيادة القائم على التفاهم. فالاولى تعمل بشكل جيد في السلك العسكري و لكن في الحياة العملية لا جدوى منها لذلك ادركت ان الاهداف لا تتحقق الا من خلال الجهد الكبير و الإرادة.

. فالعبارة التي تقول “لا تتحقق الاهداف الا من خلال الجهد الكبير و الإرادة” هي بالتحديد ما يحتاجه مشروع مثل لينكس و “مبدأ القيادة” لا يمكن تطبيقه في مجتمع فوضوي من المتطوعين على الانترنت. و لكن لكي يتم ذلك بشكل فعال لابد من ان يتعلم المطورين الذين يرغبون في قيادة مشروع تكافلي كيفية استقطاب و تحفيز المجتمع الفعال كما يقترح Kropotkin's مبدأ القيادة القائم على التفاهم“. لذلك هؤلاء المطورون لابد ان يتعلموا قانون لينوس

في السابق كنت افضل مؤثرات دلفي Delphi effect كتفسير طبيعي لي قانون لينوس. و لكن هناك تفسيرات اشمل للتبني في علم الاحياء و الاقتصاد قد تكون اكثر ملائمة هنا. عالم لينكس يتصرف في اباعد كثيرة مثل بيئة السوق الحر. مجموعة من العملاء الانانين في طور تعضيم الفائدة ومن خلال هذا النهج ينتج وبشكل فوجائي الية للتصحيح الذاتي, هذة الالية فعالة بشكل كبير بحيث لايمكن الوصول الي نفس الالية في بيئة تطوير مركزية. هنا اذا هو المكان الي نصبو الي تحقيق “مبداء القيادة القائم علي التفاهم”

وظيفة الأداة التي يعظمها مطوري لينكس ليست اقتصادية تقليدية, و لكنها احساس ملموس نابع من الأنا الذاتية للشعور بالرضى عن النفس و ايضا للحصول على مكانة مرموقة بين المطورين الاخرين, فالثقافات التطوعية و التي تعمل على هذا المبدأ ليست مستغربة, مثلا انا قد اشتركت و منذ فترة طويلة في مهرجانات و عروض الخيال العلمي ” fandom” و الذي يختلف قليلا عن “hackerdom” بحيث انه في “ fandom” يجيزو بشكل واضح ان نتفاخر بالمساهمات التي قمنا بها لرفع المعنويات الشخصية و الشعور بالرضى عن النفس.

و قد نجح لينوس بتعيين نفسه حارس البوابة لمشروع التطوير الذي يتم بواسطة مطورين اخرين. و استطاع ان يستقطب الاهتمام بالمشروع من قبيل مطورين اخرين الى ان يصل المشروع الى مرحلة الثبات و الاعتماد على ذاته, ومن هذا نستنبط التجسيد لما ذكره الكاتب Kropotkin's مبدأ القيادة القائم على التفاهم” هذا المنظور الشبه اقتصادي لعالم لنكس يسمح لنا ان نفهم كيف تم تطيبق هذا التفاهم. و قد ننظر لمبدأ لينوس على اساس انه خلق اسواق فعالة في بيئة الغرور و الرضى عن النفس لتصل وبشكل وثيق بين أنانية المطور و النهايات الصعبة التي تحتاج للعمل التعاوني التكافلي. و في مشروع fetchmail اظهرت (ولو بشكل صغير) ان هذا المبدأ يمكن تقليده و بنتائج ممتازة و لعلني قمت بالعمل بشكل واعي و منهجي اكثر من لينوس.

كثير من الناس (خصوصا اولائك الذين لا يثقون في الاسواق الحرة) يتوقعون ان الثقافة المكونة من اصحاب الادارة الذاتية انانييون من السهل تمزيقهم و متعصبين لممتلكاتهم و مبذرون و متحفظون و ايضا عدوانيون. و لكن هذه الادعاءات غير صحيحة, و لكي نثبت ذلك يكفي ان الجودة المبهرة و العمق في توثيق لينكس دليل على ذلك. و من المعروف ان المطورين يكرهون التوثيق, اذ كيف يمكن لمطورين لينكس ان ينتجون كل هذا الكم الهائل من التوثيق؟ و بكل تأكيد سوق لينكس الحر في بيئة التحفيز للرضى عن النفس تعمل بكفاءة اعلى من المنشئات التجارية التي يغدق عليها المال لتوثيق البرمجيات.

كلا المشروعين fetchmail و مشروع تطوير نواة لنيكس Linux kernel projects يظهران ان مكافئة غرور كثير من المطورين هي الطريقة الصحيحة, فمدير المشروع اذا تحلى بمزيا القيادة و الخبرة في التطوير يستطيع من خلال الانترنت ان يستحوذ على الكثير من شركاء التطوير مع الحفاظ على المشروع من الفشل او التذبذب. لذلك ردا على قانون Brooks اقول :

19 لنفترض ان مدير او منسق المشروع لديه وسيلة اتصالات فعالة مثل الانترنت, و يعرف كيف يقود بدون تعسف, اذاَ زيادة المتطوعين يفي بالغرض بكل تأكيد ويكون افضل من متطوع واحد

و في اعتقادي ان مستقبل البرمجيات حرة المصدر هي في يد اولائك الذين يعرفون كيف يعملون على قوانين لينوس, و الذين يقيمون في بيئة الكتدرائية و يعتنقون مبدأ السوق “البازار” مع العلم ان هذا لايعني ان المجهودات الفردية لاتعني شيئا بل على العكس تماما, و من وجهة نظري ان معظم الثورات التغيرية في عالم التقنية سوف تبدأ من رؤية الافراد وقدرتهم على التغيير و الابتكار, و من ثم يتم اثراء هذا التغير او الابتكار بجهود المجتمعات المساهمة. .

ربما هذا ليس فقط مصير البرمجيات الحرة المصدر. فلا تستطيع أي بيئة تطويرية ان تجاري كمية العطاء الممنوح لبيئة حرة المصدر (مثل بيئة لينكس) لحل مشكلة ما. و قلة هم الذين يستطيعون تحمل تكاليف التطوير و تعين مطورين بشكل مستمر مثل ما حدث في مشروع fetchmail بحيث ان برنامج fetchmail كان يعمل علية 200 مطور ( في عام1999م وصل العدد الى 600 مطور, واصبح العدد في عام 2000 م 800 مطور) و جميعهم يتبرعون بوقتهم و مجهوداتهم بدون مقابل.

و في النهاية سوف ينتصر مبدأ البرمجيات الحرة, ليس لأن العمل التكافلي عملا اخلاقيا و احتكار البرمجيات ليس ذلك, (على اساس انك تؤمن بالثانية التي انا و لينوس لا نؤمن بها) و لكن بكل بساطة لان البيئة المغلقة المصدر لا تستطيع الانتصار في السباق التطويري مع البيئة الحرة المصدر و ذلك لأن المجتمعات التي تلتف حول البيئة حرة المصدر تشارك بجهود اعظم وتكون متزايدة باستمرار.

عن الادارة و خط ماجينوت :

انتهت الوثيقة الاصلية (لللكتدرائية و السوق “البازار”) و التي كتبت في 1997 بما ذكر سابقا- مما يسعد الحشود من المبرمجين الثوريين الذين ينافسون و يربكون بيئة البرمجيات المغلقة . و لكن كثير من المشككين الجيدين لم يكونوا مقتنعين بذلك, و السؤال الذي تم طرحه يستحق المشاركة فعلا., فمعظم المعارضات التي قدمت حول مبدأ السوق “البازار” كانت تزعم بأنني قلّلت من تقدير تأثير مضاعفة الجهود على الادارة التقليدية.

مدراء تطوير البرمجيات اصحاب العقلية التقليدية يعترضون دائما على ان عدم الاهتمام بكيفية تكوًن وتغير و انحلال فريق العمل في بيئة المصادر الحرة ينفي جزءا كبيرا من الميزة الظاهرة للاعداد من المشاركين و التي تتميز بها بيئة التطوير للمصادر الحرة عن بيئة التطوير للمصادر المغلقة. وتعليقهم هو ان في بيئة تطوير البرمجيات تكون عملية التطوير مجهود مستمرعبر الوقت و درجة تقبل تطلعات العملاء للاستمرار و الاستثمار في المنتج هو المهم, وليس فقط عدد المساهمين في المشروع. و في الواقع لقد قمت بتطوير فكرة ان الخدمات التقنية المستقبلية ذات القيمة المضافة هي المحرك الاقتصادي لانتاج البرمجيات و قد ذكرت هذا في مقالة The Magic Cauldron.

و لكن هذا النقاش يحتوي على مشكلة كبيرة غير ظاهرة, لأن الفرضيات الضمنية لبيئة تطوير البرمجيات الحرة لا تستطيع ان تقدم مجهود مستمر. في الواقع, يوجد مشاريع حرة المصدر حافظت على توجه متماسك مع وجود مجتمع مشرف على فترات زمنية طويلة بدون وجود انواع كثيرة من الحوافز او تحكم مؤسسي, واللذي يعتقد كثير من المدراء انه بالغ الاهمية. فتطوير مشروع محرر GNU Emacs يعطينا مثال تعليمي, فقد احتوى على مجهود مئات من المشاركين خلال 15 عام الى ان وصل الى رؤيا تطويرية موحدة,و على الرغم من كثرة التغير في المساهمين و وجود شخص واحد مشرف على المشروع (مؤسس المشروع) كان متواجدا خلال فترة المشروع كاملة لايوجد مشروع واحد مغلق المصدر متناظر مع مشروع محرر GNU Emacs لطول العمر.

وهذا يثير التساؤل حول الطريقة التقليدية لادارة تطوير البرمجيات و التي تكون مستقلة عن باقي النقاش في صياغة وثيقة الكتدرائية و السوق. فاذا كان ممكنا لمشروع GNU Emacs ان يستمر بالمحافظة على رؤيا تطويرية موحدة لمدة 15 عام, او لنظام تشغيل مثل لينكس ان يحافظ على المثل لاكثر من 8 اعوام مع وجود تغير و تطوير للعتاد بشكل مستمر (مع العلم ان هذا هو الواقع) ولو كان هنالك الكثير من مشاريع البرمجيات حرة المصدر لفترة تتجاوز ال 5 سنوات, اذا فالسؤال هنا يكون, ماهو المقابل للتكاليف الباهظة لعمليات تطوير البرمجيات باتباع الادارة التقليدية؟؟

مهما كان المقابل فهو بكل تاكيد ليس تحقيق موثوق للاهداف, او للميزانية, او لكل المزايا للمواصفات ,فنجد انه من النادر انتاج مشروع مدار بواحدة من هذه المزايا المذكورة, بغض النظر عن كل الثلاث. ايضا من الواضح ان الطريقة التقليدية تواجه مشكلة في تبني التقنيات الجديدة المتغيرة خلال عمر مشروع ما, و في المقابل بيئة تطوير البرمجيات الحرة اثبتت قدرتها على النمو و التغير و التبني بشكل اكثر فعالية 1)

و كثير من الناس يعتقد عند تعاملهم مع برمجيات مغلقة المصدر, بوضوح المسئولية القانونية, بحيث يكون هناك شخص مسائل قانونيا ليتم التعويض عند حدوث خلل في مشروع ما. و لكن هذا غير صحيح, فمعظم رخص البرمجيات كتبت لتسقط حق ضمان المنتج ناهيك عن ضمان الانتاجية. و وقائع التعويض التي تمت لبرامج لم تؤدي عملها كما هو نادرا جدا. حتى لو كانت هذه الوقائع كثيرة لن تشعر بالارتياح فقط لان هناك شخص او جهة تستطيع ان تشتكيها و هذا لا يحقق الهدف, فانت لا تريد ان تكون طرفا في قضية قانونية ولكن تريد ان يكون لديك برنامج يعمل.

اذا مالذي تحصل عليه بدفع تكليف الادارة؟

لكي نفهم هذا لابد ان نفهم ماذا يعتقد مدراء تطوير البرمجيات انهم يفعلون. امرأة اعرفها وهي جيدة في هذا المجال تقول ان مدراء تطوير البرمجيات لديهم خمس مهام :

- تحديد الاهداف و جعل الجميع يركز على هذة الاهداف. - المراقبة و التدقيق للتأكد ان التفاصيل المهمة لا تهمل. - تحفيز الناس لعمل المهام المملة. - ترتيب و توزيع المهام بين الناس لضمان اعلى انتاجية. - توفير الموارد اللازمة لدعم المشروع.

من الواضح ان هذه الاهداف مهمة جدا, و لكن تحت مظلة البرمجيات الحرة و البيئة الاجتماعية المحيطة بها, قد تبدو هذه الاهداف غير مهمة, ولكن دعونا نعاين هذة الاهداف بشكل عكسي.

صديقتي تقول ان تقديم الموارد هو تكتيك دفاعي, فبعد ان تحصل على الناس و الاجهزة و المساحة المكتبية, لابد ان تقوم بحمايتها من المدراء الاخرين الذين ينافسونك على نفس الموارد و من الموظفين الجدد الذين يحاولون الاستفادة من الموارد بأكبر شكل ممكن

و لكن مطورين المصادر الحرة هم في الاساس متطوعون, يختارون انفسهم لرغبتهم و قدراتهم للتبرع للمشروع الذي يعملون فيه (و هذا يظل صحيحا حتى لو دفع لهم مقابل الاختراق او تطوير البرمجيات الحرة) و لكن روح التعاون تتكفل بازالة جانب حماية الموارد بشكل تلقائي. فالناس يقومون باحضار مواردهم معهم مما يعني لا حاجة لمدير لكي يحمي هذه الموارد بالمعني التقليدي.

علي اية حال في عالم يحتوي على اجهزة حاسوب رخيصة و شبكة اتصال عالية السرعة, نجد ان المورد الصعب الوحيد هو وجود اليد العاملة الماهرة المهتمة, المشاريع حرة المصدر لا تندثر و تموت بسبب عدم و جود معدات او مساحة مكتبية و لكن الطريقة الوحيدة لموت مثل هذه المشاريع هو ان يفقد المطورون الاهتمام.

اذا كانت هذه هي الحالة, فبلا شك انه من الاهمية ان يقوم مطوري البرمجيات الحرة بتنظيم انفسهم للوصول لاعلى انتاجية عن طريق الاختيار الشخصي و الوسط الاجتماعي يحدد مقدار الكفاءة بلا رحمة. ولصديقتي خبرة في عالم تطوير البرمجيات الحرة و البرمجيات المغلقة و تؤمن ان بيئة تطوير البرمجيات الحرة تكون اكثر كفاءة و ان احد الاسباب لحدوث ذلك ان تقاليد البرمجيات الحرة لا تقبل الا المبرمجين الموهوبين و الذين يشكلون 5% من جملة المبرمجين. و هي تقضي معظم وقتها في ادارة و تنسيق اعمال المبرمجين الأقل كفاءة و الذين يشكلون 95% من جملة المبرمجين فلذلك هي تعي و بشكل مباشر الفرق الكبير بين المبرمجين البارعين و المبرمجين الاقل كفاءة. اذن هل المشاريع الفردية و القطاع بشكل كامل يكون افضل باستخدام فقط 50% من المطورين ذوي الكفاءة العالية؟ فنسب العطاء هذه دائما ما تطرح هذا التساؤل. و المدراء الاذكياء ادركوا في الماضي انه لو انحصر عمل المدير التقليدي في تحويل المطور الغير كفؤ من خسارة الى ربح بسيط جدا فعملهم هذا لا يستحق المجهود.

و نجاح مجتمع المصادر الحرة يستعرض ما ذكر بشكل واضح, عن طريق تقديم ادلة ملموسة لاستقطاب متطوعين عن طريق الانترنت ارخص و اكثر انتاجية من ان تكون الادارة عبارة عن مبنى ممتليء بموظفين يرغبون في عمل شيء اخر.

مما يضعنا امام التساؤل عن التحفيز. والطريقة المعروفة والمرادفه لرأي صديقتي, الا وهو ان المدراء في البيئة التقليدية مهم جدا للتعويض عن النتائج الفقيرة التي يقدمها المطورون الذين يفتقرون للتحفيز و الرغبة. هذا الجواب يحمل في طياته مضمون مهم و هو ان مجتمعات المصادر الحرة يمكن الاعتماد عليها للقيام بعمل ما اذا كان هذا العمل جميل او محبذ لدى التقنيين, و اي عمل اخر سوف يهمل او سيتم بطريقة ركيكة جدا, الا اذا كان هناك مقابل مادي لعملهم و بوجود الادارة و الرقابة. و هنا اود ان انوه عن السبب النفسي و الاجتماعي الذي يجعلني اشك في صحة هذا الادعاء و الموجود في وثيقة Homesteading the Noosphere. و لكن اعتقد انه من الممتع ان نناقش الاثار المترتبة لقبول هذا الاستنتاج.

اذا كان النموذج التقليدي المغلق المصدر لتطوير البرمجيات و المدار بشكل مكثف محمي فقط بطريقة خط ماقينتو Maginot Line و التي تعني ان اكتشاف المشكلة يؤدي الى اكتشاف مشكلة اخرى, اذا سوف تكون هناك جزيئات في برنامج كل فرد تحتوي على علل كامنة لن تظهر الى ان يكتشفها شخصا ما و هذا قد لايحدث الا بعد فترة طويلة جدا مما قد لا يكون هناك اهتمام لاصلاحها بعد هذه المدة و ايضا تكون من الصعوبة البالغة ان يقوم شخص ما باصلاح او التحايل على هذه العلل بعد مضي كل هذا الوقت. لذلك في الوقت الذي تظهر منافسة على برنامج حر المصدر لجزئية مملة من برنامج ما, العملاء سوف يعرفون انه اخيرا سوف يتم اصلاح هذه العلة و السبب ان المطور اختار هذا العمل مما يعني انه منجذب لهذه المشكلة و له ميول لهذه الجزئية “العلة” و في عالم تطوير البرمجيات مثل اي بيئة اخرى تتطلب الابتكار و القدرة على الابداع المحفز الداخلي لعمل شيء اقوى بكثير من اي محفز اخر و لو كان مادي. و وجود الادارة التقليدية لتحفيز المطورين, هو على الارجح التكتيك الجيد و لكنها استراتيجية سيئة, و هذا قد يؤدي الى نجاح على المستوى القريب و لكنه قد يفشل على المستوي البعيد.

لذلك يبدو ان الطريقة التقليدية لتطوير البرمجيات تخسر امام بيئة المصادر الحرة في نقطتين وهي (تقديم الموارد و التنسيق) و تبدو كما لو كانت تعمل في الوقت الضائع باستثناء حافز اخر. و يظل المدير التقليدي محاصر و بدون جدوى حقيقية. و تظل اقوى نقطة نقاش لبيئة المصادر الحرة هي مراجعة الاقران (الانداد) بحيث تضمحل جميع الطرق المرادفة لها لاصطياد العلل بشكل فعال. هل نسطيع الحفاظ على تحقيق الاهداف كمبرر للتكلفة الناتجة من الادارة التقليدية للبرمجيات؟ ربما و لكن لكي نقوم بذلك نحتاج الى سبب مقنع لكي نصدق ان لجان الادارة وخطط الشركات هي اكثر نجاحا في تحديد اهداف اكفأ و اكثر انتشارا من قادة المشاريع الذين يقومون بدور مماثل في عالم المصادر الحرة يظهر ان هذه القضية صعب اثباتها. و في الواقع هذا ليس بسبب المصادر الحرة ( الدليل وجود مشاريع معمرة مثل Emacs او قدرة لينوس تورفولدس Linus Torvalds's على توظيف مجموعات كبيرة من المطورين, و قد يكون اقنعهم بأنه ينوي ان يهيمن على العالم) و هذا يجعلها صعبة, في الواقع هذا ناتج عن قصور في الادارة التقليدية لتحقيق اهداف مشاريع البرمجيات…

و اجدة من اهم النظريات في هندسة البرمجيات وهي ان 60% الى 70% من مشاريع تطوير البرمجيات اما لاتكتمل او يرفضها مستخدميها. فاذا كانت هذه الارقام قريبة من الواقع (و انا لم اقابل مدير قط رفض او كذب هذه الارقام) اذا كثير من مشاريع البرمجيات ستوجه لهدف ما اما ان تكون : ا – امكانية تحقيقها غير واقعية ب – خاطئة تماما .

والاخيرة قد تكون السبب في تقشعر المدراء عند سماعهم كلمة “ لجنة إدارة” (وخصوصا) اذا كان السامع هو مدير. فقد و لى الزمن الذي يمسك المبرمجون بهذا النمط فقد يظهر هذا في قصاصات دلبرت Dilbert الكرتونية و قد تجده الان متدلي من مكتب المدير التنفيذي. اذا ردنا سيكون وبكل بساطه للطريقة التقليدية لادارة تطوير البرمجيات كالتالي ( اذا كانت مجتمعات المصادر الحرة قللت من تقدير الادارة التقليدية, لماذا كثير منكم يظهر ازدراء لنهجكم؟ )

ومره اخرى مثال مجتمعات المصادر الحرة يوضح هذا السؤال بشكل افضل لاننا نجد المتعة فيما نعمل. فالعمل الابداعي الذي نقوم به احرز نجاح تقني و حصة في الاسواق و نجاح منقطع النظير في مشاركة العقول. فقد اثبتنا اننا نقدم برمجيات افضل بل و اثبتنا ايضا ان المتعة هي أساس العمل.

بعد سنتين و نصف من كتابة النسخة الاولى من هذه الوثيقة, الفكرة الجذرية التي استطيع ان اقدمها في نهاية هذه الوثيقة , هي ليست رؤيا لبيئة برمجيات تهيمن عليها المصادر الحرة, بعد كل شيء, يبدو ان ذلك ظاهر لكثير من الناس حتى لاولائك الذين يرتدون البدل “رجال الاعمال”

بالأحرى, اود ان اقترح ما قد قد يكون درس اعمق و اشمل في البرمجيات (و من الممكن ان يشمل هذا الدرس او اي عمل ابتكاري ابداعي متخصص) البشر عادة ما يستمتعون بعمل شي ما خصوصا اذا كان هذا العمل يشكل أقصى قدر من التحدي و ليس سهلا الى حد الملل, و ليس صعب المنال ايضا. اذا سبب سعادة المبرمج بان يكون شخصل مهما ليس مهمشا وغير مثقل بالاهداف العقيمة وان لا تكون آلية عمل مجهدة. اذا فالمعادلة هي (المتعة تحدد الكفائة)

و فيما يخص آلية عملك فالخوف و الأشمئزاز بحد ذاته دليل على ان آلية العمل هذه فاشلة. فالمتعة و روح الفكاهه و المرح هما بكل تأكيدا لاصول و لم يكن عبثا حين ذكرت اعلاه “ الجحافل السعداء” و لم تعد اضحوكة ان شعار لينكس هو حيوان البطريق

قد يكون ان اهم درس يعلمنا اياة نهج المصادر الحرة, ان اللعب هو اكثر الطرق اقتصاديا و كفائة خصوصا في الاعمال التي تتطلب الابداع و الابتكار

خاتمة الكتاب: نيتسكيب Netscape تحتضن السوق "البزار" :

انه شعور غريب أن تدرك أنك تساعد على صنع التاريخ.

في 22 يناير 1998 و تقريبا بعد سبع اشهر من نشر هذه الوثيقة ( الكتدرائية و السوق (البزار) نتسكيب Netscape Communications, Inc.) اعلنت خططها لنشر الشفرة المصدرية لللمتصفح ( نيتسكيب كميونكيتر Netscape Communicator) و لم اكن اعرف انهم سوف يقومون بذلك قبل الاعلان. . ايرك هان Eric Hahn نائب الرئيس التنفيذي وكبير مسؤولي التكنولوجيا في نيتسكيب Netscape ارسل لي بريدا الكترونيا بقول فيه

“ نيابة عن الجميع في نيتسكيب Netscape اود ان اشكرك لمساعدتنا لنكون الاوائل للوصول الى هذا القرار . ان افكارك و كتابتك كانت مصدر الهام لهذا القرار”

``On behalf of everyone at Netscape, I want to thank you for helping us get to this point in the first place. Your thinking and writings were fundamental inspirations to our decision.''

و في الاسبوع التالي سافرت الى و ادي السليكون Silicon Valley بناءَ على دعوة من نيتسكيب Netscape's للقيام بورشة عمل ليوم واحد (4 فابراير 1998) مع مجموعة من المدراء التنفيذين و التقنيين لقد صممنا لنيتسكيب الية اطلاق الشفرة المصدرية و الرخصة.

وبعد بضعة أيام كتبت ما يلي :

نيتسكيب Netscape اوشك على توفير نموذج كبير و حي للسوق “البازار” في العالم التجاري. فتقاليد المصادر الحرة الان تواجه خطر فاذا كانت اجراءات نيتسكيب Netscape's فاشلة عندئذ فان مبدأ المصادر الحرة سوف يهمش من جانب العالم التجاري و لن يمسوه حتى عقد من الزمان. ومن جانب اخر, هذه ايضا فرصة مذهلة, فردود الافعال الاولية لهذا التصرف في اسواق المال كان ايجابيا بحذر. لقد ُمنحنا فرصة لنثبت انفسنا و اذا استطاعت نيتسكيب Netscape ان تسترجع حصص السوق عن طريق هذا التصرف, من الممكن ان يثير هذا ثورة في عالم البرمجيات. العام المقبل قد يكون تثقيفي و مثير.

و بالفعل كانت كذلك. فيما اكتب في منتصف عام 2000 التطوير الذي طرأ على ما سمي موزيلا Mozilla لاحقا لم يكن شيئا غير نجاح محقق. و قد حققت اهداف نيتسكيب Netscape's الاساسية, و التي كانت تواجه سياسة الاحتكار التي تتبعها مايكروسوفت Microsoft لمتصفحها. و ايضا حققت نجاح دراماتيكي (اصدار الجيل القادم من محرك قيكو “ Gecko rendering engine”

على اية حال لم يحصل تبرع كبير للجهود من خارج نيتسكيب Netscape و التي تأمل لها الفريق المؤسس لموزيلا Mozilla و يبد ان المشكلة تكمن في ان فريق موزيلا خالف احد اهم الشروط الاساسية لنمط السوق “البازار” فهي لم تصدر نموذج يعمل لكي يقوم المتبرعون بتشغيله لكي يساهمون به (امتد هذا الى اكثر من سنة الى ان قام فريق موزيلا Mozilla ببناء البرنامج من المصدر و التي تتطلب رخصة مغلقة لمكتبة موتف Motif library)

و السلبيات (من وجهة نظر العلم الخارجي) ان موزيالا Mozilla لم تقدم متصفح ذو قيمة منذ سنتان و نصف من وقت اطلاق المشروع و في 1999 قام احدي مدراء المشروع بتصعيد مشكلة عدم كفاءة الادارة و الفرص الضائعة فقد قال “ ان المصادر الحرة ليست عصا سحرية” و بالفعل فهو ليس كذلك. فمبدأ التخمين و الذي اخذ فترة طويلة بدأ بالتحسن بشكل جذري الان (نوفمبر 2000) مقارنة بالبرنامج في ايام استقالة جيمي زوينسكس Jamie Zawinski's و في الاسابيع الاخيرة الاصدارات الليلية ارتقت الى متصفح ذو كفاءة و يمكن استخدامه. و لكن رأي جيمي كان صحيحا فقد ادعى ان التوجه للمصادر الحرة لن ينقذ مشروع يعاني من علة في تحديد الاهداف او شفرة مصدرية عشوائية او اي من الامراض المزمنة التي تصيب مشاريع التطوير. فقامت موزيلا Mozilla بتقديم نموذجا لمشروع حر المصدر فاشل و مشروع حر المصدر ناجح ايضا.

و في الوقت الحالي فكرة المصادر الحرة حققت نجاحا كبيرا ,, ووجد مؤيدين وانصار في كل مكان. و بعد اصدار نيتسكيب Netscape نرى نموا كبيرا و متزايدا بالإهتمام باتباع نمط المصادر الحرة, نرا ميل للتوجه له و النجاح المستمر لنظام التشغيل لينكس. فالاتجاه الذي اطلقته موزيلا Mozilla لا يزال مستمر و متزايد.

1)
و من السهل اثبات ذلك, فمثلا: مقارنة تاريخ الانترنت (30 عام) مع تقنيات الشبكات المملوكة (مغلقة المصدر) او تكلفة التحويل من 16-bit الى 32-bit لدى مايكروسوفت Microsoft Windows مع تغير لينكس و الذي تم بدون صعوبة في نفس الوقت, و ليس التعامل مع خطوط انتاج انتل Intel المتغيرة و لكن العشرات من العتاد الدائم التغير بما في ذلك عتاد الفا 64-bit Alpha
docs/الكاتدرائية_والسوق.txt · آخر تعديل: 2015/04/23 03:19 بواسطة 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki