docs:الكاتدرائية_والسوق
اختلافات
عرض الاختلافات بين النسخة المختارة و النسخة الحالية من الصفحة.
جانبي المراجعة السابقةالمراجعة السابقة | |||
docs:الكاتدرائية_والسوق [2010/03/20 10:14] – استبدال وتنقيح الترجمة omlx | docs:الكاتدرائية_والسوق [2015/04/23 03:19] (حالي) – تحرير خارجي 127.0.0.1 | ||
---|---|---|---|
سطر 1: | سطر 1: | ||
+ | {{tag> | ||
+ | ====== الكاتدرائية والسوق/ | ||
+ | |||
+ | ===== حول هذه المقالة ===== | ||
+ | |||
+ | الكاتدرائية والسوق (البزار) | ||
+ | |||
+ | * المؤلف: | ||
+ | * ترجمة: زياد عبد الرحمن الهندي | ||
+ | * التدقيق اللغوي: | ||
+ | * الرخصة: | ||
+ | * يمكن الوصول للوثيقة باللغة الإنجليزية على الرابط | ||
+ | |||
+ | ===== ملخص ===== | ||
+ | لقد قمت بتحليل مشروع ناجح مفتوح المصدر | ||
+ | |||
+ | |||
+ | ===== الكاتدرائية والسوق (البازار) : ===== | ||
+ | إن لينكس مخرب، فمن كان يظن، حتى قبل خمس سنوات (1991)،إمكانية إنشاء نظام تشغيل عالمي - كما لو كان سحرا - من البرمجة في وقت فراغ آلاف المطورين المنتشرين حول العالم والمتواصلين عبر وصلات الإنترنت الضعيفة وحدها؟ | ||
+ | |||
+ | بكل تأكيد لست أنا، ففي الوقت الذي بدأ لينكس بالغوص في شاشة راداري في مطلع عام 1993، كنت قد أكملت عشر سنوات من المشاركة في تطوير يونكس والمصادر المفتوحة. ففي منتصف 1980، كنت من أوائل المساهمين في مشروع GNU. وكنت قد أصدرت عددا جيدا من البرمجيات مفتوحة المصدر على شبكة الأنترنت، وقمت أيضا بتطوير عدة برامج سواء بشكل مباشر أو غير مباشر مثل ( nethack، ونمط VC و GUD لـ Emac، و xlife وغيرها) منها ما يزال مستعمل على نطاق واسع حتى اليوم، لقد ظننت أني أعرف كيف تسير الأمور. | ||
+ | |||
+ | | ||
+ | |||
+ | جاء أسلوب لينوس ترافولدس في التطوير (أطلق مبكرا وبشكل متكرر، فوّض كل شيء يمكن تفويضه، وكن شفّافا إلى درجة الوضوح التام) كالمفاجأة. لم يكن هناك الهدوء و التقدير لأسلوب البناء الكاتدرائي؛ بل كان مجتمع لينكس يشبه سوق ضخم مملوء بالضجيج لمختلف الأجندات و المقاربات (يتضح ذلك بشكل جلي في مواقع أرشفة لينكس التي يمكن أن تقبل المواضيع من أي شخص كان )بحيث أصبح ظهور نظام ثابت ومتماسك أمرا لا يمكن أن يحدث ظاهريا إلا بمعجزات متتابعة. | ||
+ | |||
+ | أتت حقيقة أن أسلوب السوق هذا -فيما يبدو- أنه يعمل بشكل جيد؛ كصدمة بارزة. وفيما أنا أستكشف الدرب من حولي، عملت بجهد ليس فقط على مشاريع فردية، بل حاولت أن أستوعب لماذا عالم لينكس | ||
+ | بحلول منتصف عام 1996، اعتقدت بأني بدأت أفهم الطريقة. تسنّت لي فرصة ممتازة لاختبار نظريتي على شكل مشروع مفتوح المصدر استطعت بإدراك تجربة أسلوب السوق (البازار)، وطبقته بالفعل و كانت التجربة ناجحة بشكل جلي. | ||
+ | |||
+ | وهذه هي قصة ذلك المشروع. و سوف أستخدمه لاقتراح مجموعة حكم فعّالة حول تطوير مشاريع مفتوحة المصدر. ليس كل هذه الأشياء تعلمتها من تعاملي مع عالم لينكس، ولكن سوف نرى كيف أن عالم لينكس أعطاها معنى معينا، وإذا كنت محقا ، ستساعدك على فهم بالضبط ما الذي يجعل من مجتمع لينكس مثل الينبوع من البرامج الجيدة، وربما سوف تساعدك على أن تصبح | ||
+ | |||
+ | ===== البريد يجب أن يمرر : ===== | ||
+ | منذ عام 1993 وأنا أدير الجانب التقني من شركة صغيرة في غرب تشستر في بنسليفيا تقوم بتزويد خدمة الأنترنت تسمى Chester Country InterLink، حيث أني أحد مؤسسيها وقمت بكتابة برنامجنا الفريد لساحة الإعلانات متعددة المستخدمين --- يمكنك أن تتأكد منه عن طريق telnet من هذا العنوان | ||
+ | |||
+ | كنت قد تعوّدت علي البريد الإلكتروني الفوري. كما وجدت أن استخدام تلنت (telnet) على موقع Locke بشكل مستمر لتفحص البريد كان أمرا مزعجا. وما كنت أريده هو أن يرسل البريد إلى جهازي الخاص بحيث أبلّغ عند وصول البريد وأستطيع بعد ذلك أن أتعامل مع البريد بالأدوات المحلية الموجودة لدي. | ||
+ | |||
+ | فقد كان البروتوكول المستخدم بشكل تلقائي على الأنترنت لإرسال البريد هو SMTP (بروتوكول نقل البريد البسيط Simple Mail Transfer Protocol) لا يناسبني، | ||
+ | |||
+ | أنا بحاجة إلى عميل POP3، لذا بحثت في الإنترنت ووجدت واحدا، في الحقيقة وجدت ثلاثة أو أربعة، واستخدمت أحدهم لفترة، ولكن كان ينقصه ميزة بدهية ألا وهي القدرة على قراءة العناوين في البريد الوارد بحيث يمكن أن تعمل خاصية الرد بشكل سليم. | ||
+ | |||
+ | كانت المشكلة كالتالي : لنفترض أن شخصا وليكن joe على شبكة locke أرسل لي رسالة، فإذا قمت بجلب هذه الرسالة على نظامي الشخصي في البيت snark و حاولت أن أرد عليها، سيقوم خادم البريد بإرسالها بكل سرور إلى joe والذي هو غير موجود على snark، مما يضطرني أن أعدّل عنوان البريدي بشكل يدوي بإضافة @ccil.org، وهذه عملية مزعجة بشكل فظيع ! | ||
+ | |||
+ | ومن الواضح أن هذه المهمة كان لابد أن يقوم بها الحاسوب بالنيابة عني. و لكن لم يكن أي عميل POP يعرف كيف يقوم بذلك، وهذا يقودنا إلى الدرس الأول : | ||
+ | |||
+ | * 1-إن كل عمل جيد للبرمجيات بدأ من تلبية حاجات المطور الشخصية. | ||
+ | |||
+ | ربما قد يكون هذا أمرا بديهيا (وهي حقيقة صيغت في مثل منذ زمن بعيد: الحاجة أم الاختراع) ولكن كثيرا من مطوري البرامج يمضون أيامهم في عمل شاق من أجل المال في برامج : إما أنهم لا يحبونها أو لا يحتاجون إليها، ولكن ليس في عالم لينكس ؛ الأمر الذي قد يفسر متوسط جودة البرامج التي نشأت في مجتمع لينكس عالية جدا. | ||
+ | لذا هل انخرطت على الفور في دوامة كتابة عميل POP3 جديد ينافس البرامج الموجودة ؟ بالتأكيد لا! بل تفحصت برامج POP الموجودة التي في يدي، و سألت نفسي " أي واحد أقرب لما أحتاج ؟" وذلك بسبب أن : | ||
+ | |||
+ | * 2- المبرمج الجيد يعرف ماذا يكتب، ولكن المبرمج العظيم هو الذي يعرف ما يحتاج أن تعاد كتابته (أو يعاد استخدامه) | ||
+ | |||
+ | |||
+ | أنا لا أدّعي أني مبرمج عظيم، ولكني سأحاول تقليد أحدهم. وأحد مزايا المبرمج العظيم هو الكسل البنّاء، إنهم يعرفون أنك ستحصل على درجة ( أ )ليس ب بسبب المجهود بل للنتائج، وأنه دائما أسهل أن تبدأ من حل جزئي جيد من أن تبدأ من الصفر. | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | إن تقليد مشاركة المصدر في عالم اليونكس كان دائما ودودا في إعادة استخدام الشفرة (لهذا السبب اختار مشروع جنو يونكس كنظام تشغيلي ينطلق منه، بالرغم من التحفظات الكبيرة حول النظام التشغيلي نفسه)، أخذ عالم لينكس هذا التقليد إلى حدوده التقنية القصوى تقريبا ؛ حيث أنه يملك تيرا بايتات من المصادر المفتوحة متوفرة بشكل عام، لذا فإن قضاء وقت للبحث عن شيء جيد يرجع لك نتيجة جيدة في عالم لينكس بالمقارنة مع الأنظمة الأخرى غالبا. | ||
+ | |||
+ | هذا ما حدث لي، فبالإضافة إلى البرامج التي حصلت عليها سابقا، ارتفع العدد إلى تسعة برامج مرشحة في البحث الثاني (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 في ذاك الوقت ذكيا ولكن ليس مبرمجا خبيرا، وانعكس ذلك على الشفرة ) بينما كانت | ||
+ | |||
+ | | ||
+ | كان الدافع العملي للانتقال هو دعم عدة بروتوكولات، كان POP3 هو أكثر بروتوكول خادم post-office استخداما، ولكن لم يكن الوحيد، لم يدعم Fetchpop ومنافسيه POP2 و RPOP و APOP، وكانت لدي أفكار غير واضحة لإضافة دعم IMAP (بروتوكول النفاذ لرسائل الإنترنت Internet Message Access Protocol المصمم حديثا وأقوى بروتوكولات البريد post-office ) من أجل المتعة. | ||
+ | |||
+ | كون كان لدي سببا نظريا أقوى وهو أن التغيير قد يكون جيدا بحد ذاته، وهو شيء تعلمته منذ فترة طويلة قبل لينكس. | ||
+ | |||
+ | * 3- " | ||
+ | |||
+ | أو بعبارة أخرى، في الغالب لن تفهم المشكلة بشكل جيد حتى تطبق لها حلا لأول مرة، في المرة الثانية قد يكون لديك المعرفة الكافية لتفعلها بشكل صحيح، لذا إذا رغبت أن تؤديها بشكل صحيح ؛ فلتستعد أن تبدأ من جديد مرة واحدة على الأقل . | ||
+ | |||
+ | حسنا (أخبرت نفسي) أن التغييرات التي أجريتها لـ fetchpop هي محاولتي الأولى، لذا قمت بالتغيير. | ||
+ | |||
+ | بعد أن أرسلت مجموعتي الأولى من الرقع الإصلاحية لـ popclient | ||
+ | |||
+ | وبدون أن ألاحظ بدأ المشروع في التصاعد، ولم أعد أفكر في كتابة رقع صغيرة لعملاء POP الموجودين، وأخذت مهمة صيانة البرنامج بالكامل، وكانت هناك أفكار تتفاعل في رأسي ، والتي كنت أعرف أنها ستؤدي إلى تغيرات كبيرة. | ||
+ | |||
+ | في ثقافة البرامج التي تشجع مشاركة الشفرات، هذه طريقة طبيعية لنمو مشروع، كنت أنفذ هذا القانون : | ||
+ | * 4- إذا كان لديك موقف جيد، فإن المشاكل المثيرة ستجدك | ||
+ | |||
+ | لكن كان موقف Carl Harris أكثر أهمية، للفهم بأنه : | ||
+ | * 5- عندما تفقد الاهتمام ببرنامج، فإن أخر مهمة لك نحوه أن تسلمه إلى خليفة متمّكن. | ||
+ | |||
+ | وحتى بدون أن نناقش المسألة، فإني أنا و Carl نعرف أنه لدينا هدف مشترك لامتلاك أفضل حل متوفر، كان السؤال الوحيد لكلينا هو إذا كنت أستطيع أن أثبت أني أستطيع العناية بالمشروع أم لا، و عندما حققت ذلك، قام هو بالرحيل بشرف، آمل أن أفعل ذلك أيضا عندما يحين دوري. | ||
+ | |||
+ | ===== أهمية المستخدمين : ===== | ||
+ | وهكذا ورثت popclient، وبنفس الأهمية ورثت قاعدة مستخدمي popclient، إن وجود المستخدمين من الأمور الرائعة التي يجب أن تملكها ليس فقط بسبب أنهم يثبتوا لك أنك تلبي حاجة ما، ولكن أيضا يبرهنوا أنك قمت بشيء ما بشكل صحيح، وبالرعاية الصحيحة قد يكونوا شركاء في التطوير. | ||
+ | |||
+ | ميزة أخرى قوية في تقليد اليونكس والتي أخذها لينكس إلى حدودها القصوى بسرور، هي أن كثيرا من المستخدمين هم أيضا هكر ، وبسبب أن شفرة المصدرية متاحة، فإنهم قد يكون هكر فعّالين، قد يكون هذا مفيد بشكل لا يتصور خصوصا في تقليص وقت التنقيح | ||
+ | |||
+ | *6- معاملة مستخدميك على أنهم شركاء في التطوير هو أسهل طريق لتحسين الشفرة بسرعة وجعل التنقيح فعالا. | ||
+ | |||
+ | من السهل تقليل قوة هذا التأثير، وفي الحقيقة أغلبنا في عالم المصادر المفتوحة قللنا بشدة كيف أنها ستناسب بشكل إيجابي بين عدد المستخدمين و تعقيد النظام، حتى أثبت لنا لينوس تورفالدس أن الأمر قد يكون مختلفا. | ||
+ | |||
+ | في الحقيقة، أنا أعتقد أن أذكى و أكثر هاك إنتاجية قام به لينوس ليس بناء نواة لينكس بنفسه، بل عوضا عن ذاك هو اختراعه لطريقة تطوير لينكس، وعندما عرضت أمامه هذه الفكرة في إحدى المرات، ابتسم وقال شيئا كان يكرره دائما: " أنا في الأساس شخص كسول جدا يحب أن يحصل على المديح على أشياء قام بها الآخرون" | ||
+ | |||
+ | وحين نستعيد الأحداث، نستطيع أن نرى سابقة لها علاقة بطريقة تطوير ونجاح لينكس في طريقة تطوير مكتبة جنو Emacs Lisp و أرشيف شفرة Lisp، فعلى خلاف طريقة بناء الكاتدرائية لنواة Emacs المكتوبة بلغة السي وأغلب أدوات جنو، نجد نمو | ||
+ | |||
+ | في الواقع، لربما كان أنجح هاك لي قبل fetchmail هو نمط Emacs VC (الخاص بإدارة الإصدارات) قمت باتباع نمط | ||
+ | |||
+ | قصة إيماكس ليست فريدة ، فقد كانت هناك منتجات برمجية أخرى تملك مستويين من البنية ومجتمعين من المستخدمين، يجمعان نمط الكاتدرائية للنواة ونمط السوق لصندوق الأدوات. وأحد الأمثلة هو برنامج MATLAB وهو أداة تجارية لتحليل البيانات وتجسيمها. دائما ما يلاحظ مستخدمو MATLAB والبرامج الشبيهة في البنية أن الإثارة والحماس والإبداع دائما ما يأخذ مكانه في الأجزاء المفتوحة من الأداة حيث يمكن للمجتمع الكبير والمتنوع أن يعدّل فيها. | ||
+ | |||
+ | ===== أطلق مبكرا، أطلق بشكل متكرر : ===== | ||
+ | إن الإصدارات المبكرة والمتكررة جزء مهم من استراتيجية تطوير لينكس. وقد اعتاد أغلب المطورين (بما فيهم أنا) | ||
+ | |||
+ | عزّز هذا الاعتقاد | ||
+ | |||
+ | توقع | ||
+ | |||
+ | |||
+ | بعد مرور سنة؛ وبعد أن أصبح لينكس ظاهرا بشكل كبير، كان من الواضح أن هناك شيء مختلف و أكثر صحة يجري هناك، فقد كانت سياسة تطوير لينوس المفتوحة على نقيض سياسة بناء الكاتدرائية، فقد كانت أرشيفات لينكس تزدهر، والعديد من التوزيعات بدأت تطفو على السطح، وكل هذا مبني على | ||
+ | |||
+ | كان لينوس يعامل مستخدميه كشركاء في التطوير بأكفأ طريقة ممكنة : | ||
+ | |||
+ | *7- أطلق مبكرا، وأطلق بشكل متكرر، و استمع لزبائنك. | ||
+ | |||
+ | لم يكن إبداع لينوس | ||
+ | |||
+ | ولكن كيف نحج ؟وهل هذا النجاح شيء يمكن أن أكرره، أم أنه يعتمد على عبقرية لينوس تورفالدس الفريدة ؟ | ||
+ | |||
+ | لا أعتقد ذلك، فمع تسليمنا أن لينوس هاكر ممتاز؛ فكم شخص منا يستطيع أن يبني نواة نظام تشغلي بجودة الإنتاج من الصفر؟ لكن لينكس لم يمثل أي قفزة رائعة للأمام من ناحية المفاهيم. ولينوس ليس عبقري مبدع في التصميم (ليس بعد على الأقل ) مثل ما كان رتشارد ستالمن أو جيمس جوسلنج (صاحب NeWS وجافا) على سبيل المثال، بل عوضا عن ذلك، يبدو لي أنه عبقري في الهندسة و التطبيق بحاسة سادسة لمنع العلل و النهايات المميتة في التطوير، و يمتلك موهبة حقيقية لإيجاد أسهل طريق من النقطة أ إلى النقطة ب، بالتأكيد تنفّس تصميم لينكس بالكامل هذه الجودة، وعكس تحفظات لينوس الضرورية وطريقة التصميم المبسطة. | ||
+ | |||
+ | إذاً، إذا كانت الإصدارات السريعة ودفع وسيط الإنترنت إلى أقصى حد ممكن لم تكن مصادفة بل كانت أجزاء متكاملة من هندسة لينوس العبقرية مستلهمة من أقصر الطرق الممكنة، فماذا كان يهدف؟ وما هي مخرجات تلك المكنة ؟ | ||
+ | |||
+ | في هذا السياق، فإن السؤال يجيب على نفسه، كان لينوس يبقي على هكره/ | ||
+ | |||
+ | كان لينوس يهدف بشكل مباشر لزيادة عدد ساعات الشخص التي يقضيها في التنقيح والتطوير، حتى لو كان الثمن هو عدم الاستقرار في الشفرة وإجهاد قاعدة المستخدمين إذا وجد علة خطيرة صعبة الحل، كان لينوس يتصرف كما لو كان يؤمن بشي مثل هذا : | ||
+ | |||
+ | *8- في حال وجود قاعدة من مختبرين البيتا وشركاء التطوير بشكل كاف، فإن أغلب المشاكل ستشخص بسرعة وسيصبح الحل ظاهرا لشخص ما. | ||
+ | |||
+ | أو بشكل أقل رسمية " إذا وجدت عيون كافية، فإن كل العلل ستصبح سطحية " وقد أسميته " قانون لينوس" | ||
+ | |||
+ | كان تأطيري الأصلي أن كل مشكلة " | ||
+ | |||
+ | تكمن الاختلافات الجوهرية بين أسلوب بناء الكتدرائية و السوق في قانون لينوس حسبما أظن، فنظرة بناء الكتدرائية لمشاكل البرمجة و العلل و التطوير، هي أنها ظاهرة مخادعة و غادرة و عميقة، وهي تأخذ أشهر من الفحص بواسطة مجموعة صغيرة مخصصة حتى تتأكد من أن جميع المشاكل تم إزالتها بالكامل، كل هذا يتطلب فترات إصدار طويلة مع إحباط لا بد منه عندما تكتشف أن الإصدارة التي طال انتظارها غير كاملة . | ||
+ | |||
+ | أما في نظرة السوق على الطرف الآخر، فإنك تفترض أن المشاكل هي ظاهرة سطحية أو على الأقل أنها ستصبح سطحية بسرعة لا بأس بها عندما يتم تعريضها للآلاف من شركاء التطوير المتحمسين في كل إصدارة جديدة، لذا فإنك تطلق إصدارات بشكل متكرر لتحصل على المزيد من التصحيحات، و كتأثير | ||
+ | |||
+ | هذه هي، وهذا يكفي، فإذا كان " | ||
+ | |||
+ | و ليس من المفترض أن نستغرب ذلك ، فمنذ سنوات اكتشف علماء الاجتماع أن متوسط رأي مجموعة كبيرة من المراقبين ذوي نفس المستوى من الخبرة أكثر مصداقية في التوقع من رأي مراقب واحد مختار بشكل عشوائي، وقد أطلقوا عليه تأثير دلفي Delphi، و يبدو أن ما أظهره لينوس هو أن هذا التأثير ينطبق حتى على تنقيح نظام تشغيلي، تأثير دلفي يستطيع ترويض التعقيد حتى لو كان مستوى التعقيد هو نواة نظام تشغيلي. | ||
+ | |||
+ | واحدة من أهم خصائص لينكس و التي ساعدت | ||
+ | |||
+ | يمكن إعادة صياغة قانون لينوس كالتالي " التنقيح عملية متوازية" | ||
+ | |||
+ | وفي الواقع ؛ فإن الخسارة النظرية للكفاءة بسبب تكرار عمل المنقحين في الغالب لم تكن مشكلة في عالم اللينكس، إن أحد تأثيرات سياسة " أطلق مبكرا، و أطلق بشكل متكرر" | ||
+ | |||
+ | حتى أن Brooks (مؤلف كتاب The Mythical Man-Month) وضع ملاحظة ليست بعيدة عن هذا الموضوع حيث قال :" إن التكلفة الإجمالية لصيانة برنامج مستعمل بشكل واسع تساوي 40% أو أكثر من كلفة تطويره، و بشكل مدهش فإن هذه الكلفة تتأثر بشدة بواسطة عدد المستخدمين، فكلما زاد عدد المستخدمين زاد عدد العلل المكتشفة" | ||
+ | |||
+ | كلما زاد عدد المستخدمين زاد عدد العلل بسبب أن زيادة عدد المستخدمين تضيف طرق أكثر لاختبار البرنامج، و يتعاظم هذا التأثير عندما يكون المستخدمين شركاء في التطوير، حيث أن كل واحد يؤدي مهمة تشخيص العلة بخلفيات و افتراضيات و أدوات مختلفة قليلا و من زوايا متعددة، و يبدو أن تأثير دلفي يعمل بشكل دقيق بسبب هذا التباين. و في سياق الخاص بالتنقيح، فإن هذا التباين يميل إلى تقليل تكرار الجهود. | ||
+ | |||
+ | لذا فإن زيادة عدد مختبري البيتا قد لا يؤدي إلى تقليل تعقيد " | ||
+ | |||
+ | لم ينس لينوس أن يحمي رهاناته، ففي حالة وجود علل خطيرة، فإن إصدارة نواة لينكس ترقم بطريقة يستطيع المستخدمون المحتملون أن يختاروا بين تشغيل آخر إصدارة مستقرة أو ركوب الحواف الحرجة و العلل الخطيرة من أجل الحصول على مزايا جديدة، وهذا التكتيك لم يقلده أغلب هكر اللينكس بشكل نظامي، ولكن ربما يجدر بهم ذلك، وحقيقة وجود كلا الخيارين على حدة، يجعل كلاهما أكثر جاذبية. | ||
+ | |||
+ | ===== كم من العيون تكبح التعقيد : ===== | ||
+ | يمكن ملاحظة شيء واحد في الصورة الكبيرة، وهو أن أسلوب السوق يسرع بشكل عظيم عملية تنقيح و تطوير الشفرة، ومن المهم أن نفهم بالضبط كيف ولماذا يفعل ذلك على المستوى الجزئي للمطور و سلوك المختبر. سنأخذ في هذا الفصل (الذي كتب بعد ثلاث سنوات من طرح الورقة الأصلية؛ باستخدام آراء المطورين الذين قرأوا هذه الورقة و أعادوا اختبار سلوكهم ) نظرة عميقة للآلية الحقيقية، مع ملاحظة أن القراء الذين | ||
+ | |||
+ | إحدى طرق الفهم هي إدراك بالضبط لماذا أن نوع تقارير العلل الذي يأتي من المستخدمين غير المطلعين على الشفرة يكون غير مفيد بدرجة كبيرة؛ حيث يميل المستخدمين غير المطلعين على الشفرة أن يبلغوا عن الأعراض السطحية و يفترضون أن البيئة التي يعملون عليها هي السائدة ؛ فلذا يقومون أ) بحذف خلفيات المشكلة المهمة، و ب) نادرا ما يقدموا وصفة موثوقة لكيفية إعادة إنتاج العلة. | ||
+ | |||
+ | المشكلة الأساسية هنا هي عدم التوافق بين النموذج العقلي للبرنامج بين المطورين و المختبرين، حيث ينظر المختبرون من الخارج إلى الداخل، بينما ينظر المطورون من الداخل إلى الخارج. وفي نموذج تطوير الشفرات المغلقة يصبح كلاهما عالقا في هذه الأدوار، ويميل كل طرف إلى أن يتجاهل الطرف الآخر، و يجد كلا الطرفين أنهما محبطين بدرجة عميقة. | ||
+ | |||
+ | يكسر التطوير المفتوح المصدر هذا الحاجز، جاعلا من السهولة لكل من المطور و المختبر تطوير أرضية تمثيل مشتركة للشفرة الكود الحقيقية و التواصل بشكل فعال حولها. عمليا، هناك فرق شاسع في التأثير على المطور بين ذلك النوع من تقارير العلل الذي يبلغ عن المشاكل الخارجية التي تظهر بشكل سطحي، و بين ذلك النوع الذي يعلق بشكل مباشر على التمثيل العقلي لبنية الشفرة المصدرية لدي المطور حول البرنامج. | ||
+ | |||
+ | في معظم الأوقات ، معظم العلل يسهل اكتشافها بسهولة حتى لو لم تكن مكتملة لكنها مشخصة بشكل تدل على شروط الخطأ على مستوى الشفرة المصدرية. فعندما يقوم شخص ما من بين مختبرين البيتا لبرنامجك بتوضيح أن " هناك مشكلة حدودية في السطر ص " أو حتى | ||
+ | |||
+ | وبالتالي ، فإن معرفة الشفرة المصدرية من كلا الفريقين تحسن بشكل كبير كل من طريقة التواصل الجيدة والتعاون بين | ||
+ | |||
+ | |||
+ | أحد خاصيات طريقة تطوير المصادر المفتوحة والتي تحافظ على وقت المطور هي بنية التواصل في مشاريع مفتوحة المصدر النموذجية. استخدمت عبارة " المطور الأساسي " سابقا، وهذا يعكس الفرق بين نواة المشروع ( في العادة صغيرة نوعا ما، مطور واحد في الغالب، وواحد إلى ثلاثة في العموم) وبين ما يحيط بالمشروع من مختبري البيتا والمشاركين متوفرين ( في العادة أعداد بالمئات). | ||
+ | |||
+ | المشكلة الأساسية التي تواجه مؤسسة تطوير البرمجيات التقليدية هي قانون بروك Brook' | ||
+ | |||
+ | وُجِدَ قانون بروك من تجربة أن العلل تتجه بقوة إلى التجمع حول الواجهات بين الشفرة المكتوبة بواسطة أشخاص مختلفين، وبين تكلفة التواصل/ | ||
+ | |||
+ | يعتمد تحليل قانون بروك (والخوف الناتج من الأعداد الكبيرة في مجموعات التطوير) | ||
+ | |||
+ | ما زال هناك المزيد من الأسباب التي تجعل تقارير العلل على مستوى الشفرة المصدرية أكثر إفادة وتأثيرا. وهي تتمركز حول الحقيقة أن الخطأ الواحد يمكن في العادة أن يملك عدة أعراض ممكنة، ويظهر بأشكال مختلفة تعتمد على التفاصيل نموذج استخدام العميل وبيئته. تتجه مثل هذه الأخطاء لأن تكون من نوع تلك العلل المعقدة و الماكرة ( مثل أخطاء إدارة الذاكرة دينامكية) والتي من الصعب إعادة إنتاجها أو اكتشافها بواسطة التحليل الثابت، و تخلق في الغالب مشاكل طويلة المدى في البرمجيات. | ||
+ | |||
+ | المختبر الذي يرسل توصيف غير مؤكد على مستوى الشفرة المصدرية لعلة متعددة الأعراض (مثل " | ||
+ | |||
+ | تنحو الأخطاء المعقدة ومتعددة الأعراض أيضا إلى امتلاك طرق اقتفاء متعددة من الأعراض السطحية رجوعا إلى العلة الحقيقة. ويمكن لطرق الاقتفاء المعطاة للمطور أو المختبر والتي نستطيع من خلالها اقتفاء العلة أن تعتمد على دقة بيئة ذلك الشخص، و يمكن أيضا أن تتغير عبر الوقت بطريقة غير ملحوظة. وكنتيجة لهذه، كل من عينات المطور و المختبر | ||
+ | |||
+ | للعلل البسيطة والسهلة والقابلة للإنتاج، إذن، فإن التركيز سيكون على " | ||
+ | |||
+ | سيكون هذا المؤثر عظيما إذا كانت صعوبة متابعة طرق التتبع من الأعراض السطحية المختلفة رجوعا إلى العلة تتفاوت بشكل ملحوظ في طريقة لا يمكن توقعها بواسطة النظر في الأعراض. فالمطور الواحد الذي يعاين هذه الطرق تسلسليا سينحو بشكل متوقع إلى اختيار أصعب طريق للتتبع في المحاولة الأولى بدلا عن أسهلها. في المقابل، وبافتراض أن العديد من الأفراد يحاولون تتبع الطرق بطريقة متوازية من خلال عمل إصدارات سريعة. لذا فمن المحتمل أن أحدهم سيجد أسهل طريق فورا، و يصطاد العلة في أقصر وقت. وسيلاحظ مدير المشروع أن إطلاق إصدارة جديدة، وبقية الناس يعملون على التتبع لنفس العلة سيمكنه من إيقافها قبل أن يبذل وقتا طويلا على طرق تتبعها الأكثر صعوبة. | ||
+ | |||
+ | ===== متى تكون وردة ليست بوردة؟ : ===== | ||
+ | بعد أن درست سلوك لينوس و كونت نظرية حول نجاحه، اتخذت قرارا واعيا بأن أختبر هذه النظرية على مشروعي الجديد ( أعترف بأنه أقل تعقيدا وطموحا). | ||
+ | |||
+ | أول شيء قمت به هو إعادة تنظيم popclient | ||
+ | |||
+ | وعلى كل حال، كان لي هدف آخر من إعادة كتابة البرنامج بالإضافة إلى تحسين الشفرة وتصميم هياكل البيانات، وهو أن أطور شيئا أنا أفهمه بالكامل، لأنه ليس ممتعا أن تكون مسؤولا عن إصلاح العلل في برنامج أنت لا تفهمه. | ||
+ | |||
+ | للشهر الأول أو نحو ذلك، كنت ببساطة أتابع نتائج تصميم كارل الأساسي. وكان أول تغيير مهم هو إضافة دعم IMAP. قمت بذلك بواسطة إعادة تنظيم آلية البرتوكول بداخل تعريف عام و ثلاثة جداول للمهام ( لأجل POP2 وPOP3 وIMAP). هذا التغيير والتغييرات السابقة رسمت مبدأ عاما من الجيد للمبرمجين أن يبقوه في أذهانهم، وخصوصا في لغة مثل سي والتي لا تقوم بالأنواع الدينامكية بشكل طبيعي: | ||
+ | |||
+ | *9- هياكل بيانات ذكية و شفرة غبية تعمل بشكل أفضل من الطرق الالتفافية الأخرى. | ||
+ | |||
+ | من كتاب Brooks الفصل 9:" أرني رسمك البياني و أخف جداولك، سأرتبك بلا شك. الآن أرني جداولك، ولن أحتاج في العادة إلى رسمك البياني، لأنها ستكون واضحة بنفسها." | ||
+ | |||
+ | في هذه النقطة ( بداية سبتمبر 1996، حوالي ستة أسابيع من البداية)، بدأت بالتفكير بأن الاسم في طريقة إلى التغيير، لأنه على كل حال لم يصبح عميل POP فقط من الآن. ولكني ترددت؛ بسبب أنه لم يكن هناك شيئا بحق جديدا في التصميم. كان على نسختي من popclient أن تطور هويتها الخاصة. | ||
+ | |||
+ | لقد تغير ذلك، بشكل أساسي، عندما تعلم popclient كيف يمرر البريد المجلوب إلى منفذ SMTP. سأشرح ذلك بعد قليل، ولكن أولا: قلت سابقا بأني فكرت في استخدام هذا المشروع لاختبار نظريتي حول تصرفات ليونس تورفالدس. قد تسأل كيف طبقت نظريتك؟ بهذه الطرق: | ||
+ | - أطلقت مبكرا و بشكل متكرر ( في العادة ليس أقل من من عشرة أيام، وفي مدة التطوير المكثف، مرة في اليوم). | ||
+ | - تنمية قائمة البيتا التابعة لي بواسطة إضافة أي شخص يتصل بي حول fetchmail إليها. | ||
+ | - أرسلت إعلانات مهذارة، إلى قائمة البيتا عندما أطلق أي إصدارة، مشجعا الناس على المشاركة. | ||
+ | - استمتعت إلى مختبري البيتا، أستطلع آرائهم حول قرارات التصميم، وأشجعهم كلما أرسلوا إصلاحات أو آراء. | ||
+ | |||
+ | |||
+ | كانت النتيجة من هذه الإجراءات البسيطة فورية. فمن بداية المشروع، حصلت على تقارير متعلقة بالجودة يرغب معظم المطورين بتلافيها، وفي العادة مع إصلاحات جيدة مرفقة بها، وحصلت على نقد بناء علمي، و حصلت على بريدا تشجيعيا، وحصلت أيضا على اقتراحات لمميزات ذكية، مما يقودنا إلى: | ||
+ | * 10 - إذا عاملت مختبري البيتا التابعون لك وكأنهم أثمن الموارد، فإنهم سيستجبون بأن يصبحوا أثمن الموارد لك. | ||
+ | |||
+ | أحد المقايس ذات الاهتمام لنجاح fetchmail هو الحجم الكبير لقائمة البيتا التابعة للمشروع (أصدقاء fetchmail). ففي آخر مراجعة لهذه الورقة( نوفمبر 2000) كانت تضم 287 عضوا و تزداد بمعدل شخصين إلى ثلاثة أسبوعيا. | ||
+ | |||
+ | في الحقيقة، عندما راجعت القائمة في أواخر مايو 1997 وجدت أن القائمة بدأت بفقدان أعضائها من ارتفاع يقارب 300 بسبب الاهتمام. كثير من الأفراد سألوني إلغاء اشتراكاتهم بسبب أن fetchmail كان يعمل بشكل جيد لهم وأنهم لا يرغبون برؤية رسائل القائمة المزدحمة بعد الآن. ربما أن هذا جزء من دورة الحياة العادية لمشروع ناضج في نظام السوق. | ||
+ | |||
+ | ===== Popclient يصبح Fetchmail : ===== | ||
+ | كانت نقطة التحول الحقيقة في المشروع عندما أرسل لي هاري هوشهيسر شفرته الجيدة لإعادة توجيه البريد إلى منفذ SMTP في جهاز العميل. لقد أدركت بسرعة أن أي تطبيقا موثوقا على هذه الميزة سيجعل كل أنماط توصيل البريد الأخرى في طي الهجران. | ||
+ | |||
+ | لعدة أسابيع التي ظللت أحسّن فيها fetchmail بدلا عن أن أزيد عليه شعرت بأن تصميم الواجهة كان مفيد ولكنه كان غير مقبولا أو جذابا بالإضافة إلى خياراته الهزيلة التي تستهلك وقتا في جميع أجزاءه. كانت خيارات جلب البريد إلى ملف صندوق البريد أو طريقة الخرج القياسية بالتحديد تضايقني، ولكني لم أستطع أفهم لماذا؟ | ||
+ | |||
+ | ( إذا لم تكن مهتما بالتفاصيل التقنية للبريد عبر الانترنت، يمكنك تخطي الفقرتين التاليتين بأمان) | ||
+ | |||
+ | ما الذي وجدته عندما فكرت حول تمرير SMTP أن popclient | ||
+ | |||
+ | لماذا نخوض في كل تعقيدات تشكيل عميل توصيل البريد أو إعداد عميلة قفل وإلحاق على صندوق البريد عندما يكون منفذ 25 متوفرا بشكل مضمون على أي منصة مع دعم برتوكول الشبكات TCP/ | ||
+ | |||
+ | ( عودة إلى مستوى أعلى...) | ||
+ | |||
+ | حتى ولم تكن قد تابعت المصطلحات التقنية السابقة، فإن هناك العديد من الدروس المهمة. أولا، كانت فكرة تمرير SMTP أكبر فائدة حصلت عليها من تجربة المدركة من محاكة طرق ليونس. مستخدم أعطاني هذه الفكرة الرائعة، وكل ما كان عليه أن أفعله هو فهم النتائج. | ||
+ | |||
+ | *11- الشيء المفضل التالي لامتلاك أفكار جيدة هو إدارك الأفكار الجيدة من مستخدميك. في العادة الأخير هو الأفضل. | ||
+ | |||
+ | ومن المثير للاهتمام، أنك سرعان ما تجد أنه إذا كنت صادقا بالكامل وغير مخادع لنفسك حول مديونيتك للناس الآخرين، فإن العالم بأسره سيعاملك كما لو أنك قمت بكل جزئية من الاختراع بنفسك، وأنك فقط بدأت تصبح متواضعا حول عبقريتك الفطرية. يمكننا جميعا أن نرى نجاح | ||
+ | |||
+ | (عندما كنت ألقي كلمتي في أول مؤتمر لبيرل في أغسطس 1997، كان الهاكر الرائع لاري وال جالسا في الصف الأمامي. وحالما وصلت إلى آخر سطر بالأعلى، نادى عاليا بأسلوب صحوة دينية، " قلها، قلها، أخي!" | ||
+ | |||
+ | بعد أسابيع قليلة من العمل بنفس الحيوية، بدأت بالحصول على مديح مشابه ليس فقط من مستخدمين البرنامج بل أيضا من أناس آخرين ممن وصلهم المديح. أخفيت بعض تلك الرسائل لأنظر إليها مرة أخرى في العادة عندما أبدأ أسائل نفسي ما إذا كانت حياتي مفيدة أو مهمة :-). | ||
+ | |||
+ | ولكن كان هناك درسين أساسين إضافيين غير سياسيين عاميين لكل أنواع التصميم. | ||
+ | |||
+ | *12- في العادة، أغلب الحلول الابتكارية والمميزة تأتي من إدراكك بأن فكرتك حول المشكلة كانت خاطئة. | ||
+ | |||
+ | لقد كنت أحاول أن أحل المشكلة بواسطة الاستمرار في تطوير popclient | ||
+ | |||
+ | عندما ترتطم بحاجز أثناء التطوير- عندما تجد نفسك في وضع صعب أن تفكر في الإصلاح القادم-، فإنه الوقت المناسب عادة لأن تسأل ليس ما إذا كنت قد حصلت على الجواب الصحيح، بل هل أنت تسأل السؤال الصحيح؟ فلربما أن المشكلة تحتاج أن تعاد صياغتها. | ||
+ | |||
+ | | ||
+ | |||
+ | لقد ترددت حول الخطوة الثالثة لبعض الوقت، خوفا من إزعاج مستخدمين popclient القدامى والذين يعتمدون على آلاليات توصيل بديلة. ونظريا، يمكنهم بشكل فوري التحول إلى ملفات .forward أو ما يكافئها للأنظمتهم التي ليست على نمط sendmail للحصول على نفس النتيجة. وعمليا، يمكن أن تصبح عملية التحول فوضوية. | ||
+ | |||
+ | ولكن عندما طبقتها، أثبتت فوائد ضخمة. لقد اختفت الأجزاء ضعيفة البنية من شفرة التعريف. والإعدادات أصبح أبسط بشكل جذري، ولا داعي للحلول الالتوائية بعد الآن من أجل نظام MDA و صناديق بريد المستخدمين، ولا داعي للقلق حول ما إذا كان النظام المضيف يدعم قفل الملفات. | ||
+ | |||
+ | أيضا لقد اختفت الطريق الوحيدة للفقدان البريد، حيث إن كنت قد حددت طريقة التوصيل إلى ملف و حدث أن القرص الصلب امتلء بالكامل، فإنك ستفقد بريدك. هذا سيناريو لن يحدث مع طريقة تمرير SMTP بسبب أن متنصت SMTP لن يرجع رسالة الموافقة ما لم يكن إيصال الرسالة ممكنا أو على الأقل يخزنها مؤقتا لتوصيلها في وقت لاحق. | ||
+ | |||
+ | أيضا، لقد تحسن الأداء (بالرغم أنك لن تلاحظه من تشغيلة واحدة). وفائدة أخرى وإن كانت غير جلية لهذا التغيير أن صفحة التعليمات أصبحت أبسط بشكل كبير. | ||
+ | |||
+ | لاحقا، أرجعت ميزة التوصيل عبر MDA المحلي المخصص من أجل السماح بإدارة بعض الحالات الغامضة الناتجة عن SLIP الحركي. ولكني وجدت طريقة أبسط بكثير لبرمجتها. | ||
+ | |||
+ | ما المغزى من هذا؟ لا تتردد باستبعاد المميزات القديمة وغير الصالحة عندما تستطيع أن تبرمجها من دون فقدان التأثير. يقول أنطوان دو سانت إكسبري(والذي كان طيارا ومصمم طائرات عندما كان لا يألف كتب الأطفال الكلاسيكية): | ||
+ | |||
+ | *13-" لا يتحقق الإتقان (في التصميم) عندما لا يوجد شيئا لإضافته، بل عندما لا يوجد شيئا لإزالته." | ||
+ | |||
+ | عندما تصبح شفرتك أفضل وأبسط، عندها تعرف أنها صحيحة. وفي هذه العملية، اكتسب fecthmail هويته الخاصة، مختلفا عن سلفه popclient. | ||
+ | |||
+ | لقد حان الوقت لتغيير الاسم، لقد أصبح التصميم الجديد يشبه sendmail أكثر مما يشابه popclient القديم، فكلاهما MTA، ولكن حيث أن سندميل يدفع الرسائل ثم يوصلها، فإن بوبكلاينت الجديد يسحب الرسائل ثم يوصلها. لذا بعد شهرين أعدت تسميته إلى فتشميل fetchmail. | ||
+ | |||
+ | هناك درس عام في هذه القصة حول كيفية وصول آلية SMTP إلى فيتشميل. إنه ليس فقط عملية التنقيح متوازية، بل أيضا التطوير و (إلى حد ربما يثير الدهشة) استكشفاف فضاء التصميم. عندما يكون نمطك في التطوير يتكرر بشكل سريع، فربما يصبح التطوير والتحسين حالات خاصة من التنقيح -- إصلاح العلل المغيبة في القدرات أو فكرة البرنامج الأصلية. | ||
+ | |||
+ | حتى في مستوى أعلى من التصميم، يمكن أن يكون قيّما للغاية أن تمتلك الكثير من شركاء التطوير يتجمعون عشوائيا حول فضاء التصميم بالقرب من منتجك. فكر بجدول لبركة من الماء وجد مصرفا، أو بشكل أفضل كيف تجد النمل طعامها: | ||
+ | |||
+ | ===== فيتشميل ينمو : ===== | ||
+ | |||
+ | لقد كنت مع تصميم أنيق ومبتكر، وشفرة التي أعرفها تعمل بشكل جيد لأني أستخدمها كل يوم، | ||
+ | |||
+ | وبميزة تمرير SMTP، أمكن له أن يسبق منافسيه بمراحل ليصبح برنامجا متفوقا (قاتل)، وهذا البرنامج يفي بحاجة المستخدم بشكل دقيق بحيث لا يهمش البدائل الاخرى فحسب بل يغيبها تماما. | ||
+ | |||
+ | اعتقد انك لاتستطيع ان تخطط لهذا الشي, بل يجب ان تنجذب له من واقع تصميم محكم وجبار بحيث تصبح النتيجة محتومة (لامفر منها) بل و مقدرة. و الطريقة الوحيدة لمحاولة شيء كهذا هو ان يكون لديك الكثير من الافكار, | ||
+ | |||
+ | |||
+ | كان Andy Tanenbaum يحمل الفكرة الاصلية لبناء حاسب بسيط يعمل على يونكس Unix للحواسيب الشخصية لـ IBM, للاستخدام كادوات للتعليم (اسماها مينكس Minix).. فقام.ليونس ترافلدس | ||
+ | على نفس المسار | ||
+ | كانت النتائج عنيدة بعض الشي في الواقع, | ||
+ | |||
+ | أول وأهم ميزة ساحقة كتبت بعد تحقيق هذا الدعم كانت multidrop | ||
+ | |||
+ | قررت اضافة دعم | ||
+ | |||
+ | |||
+ | و لكن ثبت اخيرا ان اختيار عنونة | ||
+ | |||
+ | 14. اي اداة جيدة يجب ان تفيد المجال الذي تستخدم به , ولكن الاداة الممتازة هي التي يمكن الاستفادة منها في اشياء كثيره لا تخطر علي البال. | ||
+ | |||
+ | الاستخدام الغير متوقع لــ multidrop في fetchmail هو لتفعيل قوائم البريد بينما لا تزال القائمة موجودة , و تفعيل الاسماء المعرفة للبريد | ||
+ | وهناك تغيير اخر مهم تم بواسطة المختبرين للنسخة الاولية فهم يوفرون الدعم | ||
+ | |||
+ | |||
+ | 15-عند تصيمم برنامج يعمل كبوابة | ||
+ | |||
+ | لم انصاع لهذا التطبيق من قبل, الدعم لــ | ||
+ | |||
+ | بعض المستخدمين في اوروبا طلبوا مني | ||
+ | |||
+ | |||
+ | ===== مزيد من الدروس في Fetchmail | ||
+ | قبل ان نعود الى دروس هندسة البرمجيات, | ||
+ | |||
+ | ملف التحكم ( rc control) | ||
+ | . | ||
+ | هذه بدأت كتجارب تتم في اواخر الليل عندها ادركت مدى | ||
+ | |||
+ | بدا يتضح لي انه اذا جعلنا هذه اللغة مبسطة | ||
+ | |||
+ | عادة يفضل المطورون اتباع نهج تركيب الجمل | ||
+ | |||
+ | و لكن هذا لم يكن السبب الوحيد الذي جعلني | ||
+ | |||
+ | و على اية حال الباقي يشكل اسبابا جيدة للقلق. الاول هو ثمن التعقيدات في مرحلة التوثيق, | ||
+ | |||
+ | التحكم بتركيب الجمل | ||
+ | |||
+ | 16-عندما تكون لغتك بعيدة عن الكمال استخدم التصريف اللغوي, | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | و لو قمنا بتشفير كلمات السر في .fetchmailrc لكان هذا اعطى احساسا وهميا بالأمان لهؤلاء الذين لا يفكرون بعمق. فالقاعدة العامة هي: | ||
+ | |||
+ | 17-النظام الامني يظل آمنا الى | ||
+ | |||
+ | |||
+ | ===== الشروط | ||
+ | عندما قام الجمهور بالمراجعة الأولية | ||
+ | |||
+ | | ||
+ | |||
+ | عندما تبدأ ببناء مجتمع اهم ما تحتاج ان تطرحه هو وعود معقولة, | ||
+ | |||
+ | لنكس و fetchmail طرحا للعموم وهما في حلة قوية و بتصميم بسيط و جذاب..و كثير من الناس يفكرون بنمط السوق (البازار) كما تم شرحه على اساس ان هذا حرج, واخيرا | ||
+ | |||
+ | ولكن لينوس توصل الى هذا التصميم من يونكس Unix و انا اخذت تصميمي من popclient (مع العلم انه تغير لاحقا بشكل كبير, و كمية التغير الذي حدثت في popclient اكثر من التغير الذي حدث في لينكس) | ||
+ | |||
+ | اعتقد انه من غير المهم ان يقوم قائد المشروع بأنشاء تصميم بالغ العبقرية, | ||
+ | |||
+ | و كما ذكرنا سابقا لينوس لم ينشيء تصميم مدهش, و لكن كان لديه القدرة البديهية للتعرف على تصميم ممتاز, و على مكاملة هذا التصميم في قلب لينكس (linux kernel), و قد شرحت قبل ذلك كيف ان اهم فكرة تصميم في ( fetchmail SMTP forwarding) اتت من شخص اخر. | ||
+ | |||
+ | المطلعين الاولين لهذه الوثيقة تذمروا من ميلي لتقليل أهمية انشاء التصميم في نمط السوق (البازار) بحجة ان لدي خبرة كثيرة في هذا المجال, | ||
+ | و المشكلة في كونك شخص فطن | ||
+ | |||
+ | لذللك كنت مؤمن ان مشروع | ||
+ | |||
+ | و هناك قاعدة مهمه على مستوى التصميم وهي المهارة والمعرفة و كتابة الشفرة لدي مدير المشروع, | ||
+ | كما ان هناك نوع اخر من المهارة غير مرتبط بتطوير البرمجيات و اللذي اعتقد انه اهم لبيئة السوق (البازار) وهيا لابد ان يتحلى اي مدير مشروع داخل بيئة السوق (البازار) بميزة ( مهارات الاتصال و حسن التعامل مع الناس ). | ||
+ | |||
+ | | ||
+ | |||
+ | انها ليست مصادفة ان لينوس هو رجل لطيف و عنده القدرة على ان يجعل الناس يحبونه و يرغبون في مساعدته, | ||
+ | |||
+ | |||
+ | ===== السياق الاجتماعي في البرمجيات الحرة: ===== | ||
+ | مكتوب انه : افضل التطويرات (الاختراقات - hacks) تبدأ كحل شخصي لمشكلة ما يواجهها المؤلف, | ||
+ | |||
+ | |||
+ | 18-لحل مشكلة مثيرة للاهتمام ، لابد من إيجاد هذه المشكلة المثيرة للاهتمام اولا. | ||
+ | |||
+ | لذلك كان هذا مع Carl Harris و الموروث | ||
+ | |||
+ | في The Mythical Man-Month, لاحظ المؤلف | ||
+ | |||
+ | و قد كان سابقا قانون بروكس قانونا مسلم به, ولكننا ناقشنا في هذه الوثيقة عدد من الطرق | ||
+ | |||
+ | مؤلفة Gerald Weinberg' | ||
+ | |||
+ | لربما كانت الصياغة التي اختارها Weinberg' | ||
+ | |||
+ | فتسخير القوة الكاملة للبرمجة " | ||
+ | |||
+ | |||
+ | من المفترض ان يكون تاريخ لينكس قد اعدنا لما سوف نتعلمه اليوم من لينكس (و ما قمت باثباته بالتجارب على منسوب صغير, و الذي تعمدت فيه ان اتبع نهج لينوس) هذا يعني بينما يظل اسلوب كتابة الشفرة عمل انعزالي (فردي) ياتي التطوير العظيم | ||
+ | |||
+ | |||
+ | مع العلم ان عالم يونكس unix منع من الاستفادة القصوى من هذة الممارسة بسبب تعقيدات قانونية في التراخيص و بسبب اسرار ومصالح تجارية ايضا بالاضافه | ||
+ | |||
+ | |||
+ | و قبل و جود الانترنت الرخيص كان هنالك اسااليب تواصل مربوطة بالمنطقة الجغرافية, | ||
+ | |||
+ | فلينكس كان اول مشروع يستفيد وبشكل واعي من الجهود و المواهب على مستوى العالم. و لا اعتقد انه كان من محض الصدفة ارتباط | ||
+ | |||
+ | |||
+ | | ||
+ | و لكن ماهو اسلوب الادارة هذا؟ | ||
+ | |||
+ | |||
+ | الكاتب | ||
+ | |||
+ | |||
+ | بحكم انني نشأت في في اسرة تدير اعمالها بنفسها, | ||
+ | |||
+ | . | ||
+ | فالعبارة التي تقول "لا تتحقق الاهداف الا من خلال الجهد الكبير و الإرادة" | ||
+ | |||
+ | |||
+ | في السابق كنت افضل مؤثرات دلفي Delphi effect كتفسير طبيعي لي قانون لينوس. و لكن هناك تفسيرات اشمل للتبني في علم الاحياء و الاقتصاد قد تكون اكثر ملائمة هنا. عالم لينكس يتصرف في اباعد كثيرة مثل بيئة السوق الحر. مجموعة من العملاء الانانين في طور تعضيم الفائدة ومن خلال هذا النهج ينتج وبشكل فوجائي الية للتصحيح الذاتي, | ||
+ | |||
+ | |||
+ | وظيفة الأداة التي يعظمها مطوري لينكس ليست اقتصادية تقليدية, | ||
+ | |||
+ | |||
+ | و قد نجح لينوس بتعيين نفسه حارس البوابة لمشروع | ||
+ | و قد ننظر لمبدأ لينوس على اساس انه خلق اسواق | ||
+ | |||
+ | |||
+ | |||
+ | كثير من الناس (خصوصا اولائك الذين لا يثقون في الاسواق الحرة) يتوقعون ان الثقافة المكونة من اصحاب | ||
+ | |||
+ | كلا المشروعين | ||
+ | |||
+ | 19 لنفترض ان مدير او منسق المشروع | ||
+ | |||
+ | و في اعتقادي ان مستقبل البرمجيات حرة المصدر هي في يد اولائك الذين يعرفون كيف يعملون على قوانين لينوس, و الذين يقيمون في بيئة الكتدرائية و يعتنقون مبدأ السوق " | ||
+ | |||
+ | ربما هذا ليس فقط مصير البرمجيات الحرة المصدر. فلا تستطيع | ||
+ | |||
+ | و في النهاية سوف ينتصر مبدأ البرمجيات الحرة, ليس لأن | ||
+ | |||
+ | |||
+ | ===== عن الادارة و خط ماجينوت : ===== | ||
+ | انتهت الوثيقة الاصلية (لللكتدرائية و السوق " | ||
+ | و لكن كثير من المشككين الجيدين لم يكونوا مقتنعين بذلك, و السؤال الذي تم طرحه يستحق المشاركة فعلا., فمعظم المعارضات التي قدمت حول مبدأ السوق " | ||
+ | |||
+ | | ||
+ | و في الواقع لقد قمت بتطوير فكرة ان الخدمات التقنية المستقبلية ذات القيمة المضافة هي المحرك الاقتصادي | ||
+ | |||
+ | و لكن هذا النقاش يحتوي على مشكلة كبيرة غير ظاهرة, لأن الفرضيات الضمنية لبيئة تطوير البرمجيات الحرة لا تستطيع ان تقدم | ||
+ | |||
+ | | ||
+ | |||
+ | مهما كان المقابل فهو بكل تاكيد ليس تحقيق موثوق للاهداف, | ||
+ | |||
+ | و كثير من الناس يعتقد عند تعاملهم مع برمجيات مغلقة المصدر, | ||
+ | |||
+ | اذا مالذي تحصل عليه بدفع تكليف الادارة؟ | ||
+ | |||
+ | لكي نفهم هذا لابد ان نفهم ماذا يعتقد مدراء تطوير | ||
+ | |||
+ | - تحديد الاهداف و جعل الجميع يركز على | ||
+ | - المراقبة و التدقيق للتأكد ان التفاصيل المهمة لا تهمل. | ||
+ | - تحفيز الناس لعمل المهام المملة. | ||
+ | - ترتيب و توزيع المهام بين الناس لضمان اعلى | ||
+ | - توفير الموارد اللازمة لدعم المشروع. | ||
+ | |||
+ | من الواضح ان هذه الاهداف مهمة جدا, و لكن تحت مظلة البرمجيات الحرة و البيئة الاجتماعية المحيطة بها, قد تبدو هذه الاهداف غير مهمة, ولكن دعونا نعاين هذة الاهداف بشكل عكسي. | ||
+ | |||
+ | صديقتي تقول ان تقديم الموارد هو تكتيك دفاعي, فبعد ان تحصل على الناس و الاجهزة و المساحة المكتبية, | ||
+ | |||
+ | و لكن مطورين المصادر الحرة هم في الاساس متطوعون, | ||
+ | |||
+ | علي اية حال في عالم يحتوي على اجهزة حاسوب رخيصة و شبكة اتصال عالية السرعة, | ||
+ | |||
+ | اذا كانت هذه هي الحالة, | ||
+ | | ||
+ | |||
+ | و نجاح مجتمع المصادر الحرة يستعرض ما ذكر بشكل واضح, عن طريق تقديم ادلة ملموسة | ||
+ | |||
+ | مما يضعنا امام التساؤل عن التحفيز. والطريقة المعروفة والمرادفه لرأي صديقتي, | ||
+ | هذا الجواب يحمل في طياته مضمون مهم و هو ان مجتمعات المصادر الحرة يمكن الاعتماد عليها للقيام بعمل ما اذا كان هذا العمل جميل او محبذ لدى التقنيين, | ||
+ | |||
+ | اذا كان النموذج التقليدي المغلق المصدر لتطوير البرمجيات و المدار بشكل مكثف محمي فقط بطريقة خط ماقينتو Maginot Line و التي تعني ان اكتشاف المشكلة يؤدي الى اكتشاف مشكلة اخرى, اذا سوف تكون هناك جزيئات في برنامج كل فرد تحتوي على علل كامنة لن تظهر الى ان يكتشفها شخصا ما و هذا قد لايحدث الا بعد فترة طويلة جدا مما قد لا يكون هناك اهتمام لاصلاحها بعد هذه المدة | ||
+ | و وجود الادارة التقليدية | ||
+ | |||
+ | لذلك يبدو ان الطريقة التقليدية لتطوير البرمجيات تخسر امام بيئة المصادر الحرة في نقطتين وهي (تقديم الموارد و التنسيق) و تبدو كما لو كانت تعمل في الوقت الضائع باستثناء حافز اخر. و يظل المدير التقليدي محاصر و بدون جدوى حقيقية. و تظل اقوى نقطة نقاش لبيئة المصادر الحرة هي مراجعة الاقران (الانداد) بحيث تضمحل جميع الطرق المرادفة لها لاصطياد العلل بشكل فعال. | ||
+ | هل نسطيع الحفاظ على تحقيق الاهداف كمبرر للتكلفة الناتجة من الادارة التقليدية للبرمجيات؟ ربما و لكن لكي نقوم بذلك | ||
+ | يظهر | ||
+ | |||
+ | و اجدة | ||
+ | ا – امكانية تحقيقها غير واقعية | ||
+ | ب – خاطئة تماما . | ||
+ | |||
+ | والاخيرة قد تكون | ||
+ | اذا ردنا سيكون وبكل بساطه | ||
+ | |||
+ | | ||
+ | |||
+ | بعد سنتين و نصف من كتابة النسخة الاولى من هذه الوثيقة, | ||
+ | |||
+ | بالأحرى, | ||
+ | |||
+ | و فيما يخص آلية عملك | ||
+ | |||
+ | قد يكون ان اهم درس يعلمنا اياة نهج المصادر الحرة, ان اللعب هو اكثر الطرق اقتصاديا و كفائة خصوصا في الاعمال التي تتطلب الابداع و الابتكار | ||
+ | |||
+ | |||
+ | |||
+ | ===== خاتمة الكتاب: | ||
+ | |||
+ | |||
+ | انه شعور غريب أن تدرك أنك تساعد على صنع التاريخ. | ||
+ | |||
+ | في 22 يناير 1998 و تقريبا بعد سبع اشهر من نشر هذه | ||
+ | . | ||
+ | ايرك هان 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' | ||
+ | |||
+ | وبعد بضعة أيام كتبت ما يلي : | ||
+ | |||
+ | نيتسكيب Netscape اوشك على توفير | ||
+ | | ||
+ | العام المقبل قد يكون تثقيفي و مثير. | ||
+ | |||
+ | و بالفعل كانت كذلك. فيما اكتب في منتصف عام 2000 التطوير الذي طرأ على ما سمي موزيلا Mozilla لاحقا لم يكن شيئا غير نجاح محقق. و قد حققت اهداف نيتسكيب Netscape' | ||
+ | |||
+ | على اية حال لم يحصل تبرع كبير للجهود من خارج نيتسكيب Netscape و التي تأمل لها الفريق المؤسس لموزيلا Mozilla و يبد ان المشكلة تكمن في ان فريق موزيلا خالف | ||
+ | |||
+ | و السلبيات | ||
+ | |||
+ | و في الوقت الحالي فكرة المصادر الحرة حققت نجاحا كبيرا ,, ووجد مؤيدين وانصار في كل مكان. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
docs/الكاتدرائية_والسوق.txt · آخر تعديل: 2015/04/23 03:19 (تحرير خارجي)