برمجيات مفتوحة المصدر (OSS) تجربة بنية إنتاجية خارج بُنى الحداثة

في برقية مسربة لشركة مايكروسوفت عام 1998، تحت عنوان “برمجيات مفتوحة المصدر منهجية جديدة للتطوير البرمجي”، جاء على لسان أحد مديري الشركة ما يلي: “نظام التشغيل لينكس “Linux” وغيره من برمجيات مفتوحة المصدر “Open Source Software OSS”، تقدم بشكل متدرج حُجة أكثر مصداقية، أن برمجيات مفتوحة المصدر قوية بنفس القدر إن لم تكن أقوى من مثيلاتها من البرمجيات الربحية”.

في نفس العام وصلت إيرادات مايكروسوفت إلى 14.5 مليار دولار^{^[1]}، من بيع برمجياتها المطورة داخلها، في حين لم يكن هناك إيرادات للبرمجيات المطورة بشكل مفتوح، كالتي ذكرت في هذه البرقية المسربة، لينقدح في الذهن سؤال بديهي: كيف خرجت منتجات “OSS” بجودة وقوة تضاهي ما تطوره شركة هادفة للربح؟ أظن أن السؤال الأعمق من ذلك هو؛ كيف تمت عملية الإنتاج البرمجي نفسها التي نتج عنها هذا المنتج المفتوح الذي يتحدى مثيله الربحي المغلق؟

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

نموذج الشركة الرأسمالي الحداثي

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

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

أصبحت الشركات مستودع كبير للخبرات البشرية، كما راكمت أموالًا طائلة، وتصدرت شركات البرمجة وتكنولوجيا المعلومات أعلى سُلم الشركات^{^[2]}.

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

ما هو حجم وتأثير برمجيات مفتوحة المصدر؟

يمكن أن نقول بكل وضوح؛ أن نسبة كبيرة من البنية التحتية البرمجية للإنترنت وتكنولوجيا المعلومات عموما، طورت عن طريق برمجيات مفتوحة المصدر، حيث أن أكثر من 68٪ من أنظمة تشغيل خوادم الإنترنت “Internet Servers” مفتوحة المصدر^{^[3]}، وأول نظام تشغيل للحاسب الآلي في التاريخ طور مفتوح المصدر عام 1969، أنظمة التشغيل الرسمية لشركة “آبل” طور من خلال نظام مفتوح المصدر، كما أن نظام تشغيل الهواتف “أندرويد” مفتوح المصدر، أعلى من 500 حاسوب عملاق “Supercomputer”، يعمل بنظام تشغيل لينكس مفتوح المصدر^{^[4]}.

وبعيدا عن عالم البرمجة؛ فمعظم شركات هوليود، مثل ديزني “Disney”، وبيكسار “Pixar”، ودريم ووركس “DreamWorks”، يستخدمون برمجيات مفتوحة^{^[5]}، بجانب ذلك كله، البتكوين ومعظم الأصول الرقمية مفتوحة المصدر.

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

تجربة برمجيات مفتوحة المصدر كتنظيم اجتماعي للإنتاج مختلف عن الشركة

يُعرف ستيفن ويبر ظاهرة المصدر المفتوح، أنها تجربة في التنظيم الاجتماعي للإنتاج حول مفهوم مميز للملكية، واقترح في كتابه “نجاح المصدر المفتوح” نموذج وصفي يمكن من خلاله فهم خصائص عملية الإنتاج البرمجي، الذي ينتهجه المطورون أثناء عملهم^{^[6]}، يقسم النموذج إلى أربع عوامل رئيسية:

الدوافع الفردية
المنطق الاقتصادي
التعاون لتنسيق الجهود
التعقيد

يقسم العوامل إلى مساحتين للتأثير، فالعاملان الأول والثاني مرتبطان بطبيعة الفاعلين، في حين العاملان الثالث والرابع مرتبطين بطبيعة المهمة نفسها.

الدوافع الفردية

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

أولها: الفن والجمال، فعملية كتابة الكود البرمجي عملية فنية تحتاج قدرا من الإبداع، المبرمجون يتكلمون دوماً عن الكود “النظيف”، والكود “القبيح”، وليس عن الكود “الفعال أو الكفء”، والكود “غير الفعال أو غير الكفء”.

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

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

ثالثها: مجابهة العدو المشترك، ويقصد به البرامج الاحتكارية الهادفة للربح.

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

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

سادسها: الانتماء لهوية مميزة، وهو شعور جمعي لمجتمع المساهمين بالانتماء لهوية مشتركة، تحمل قيما أخلاقية ومعيارية عميقة.

المنطق الاقتصادي

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

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

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

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

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

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

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

التعاون لتنسيق الجهود

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

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

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

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

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

ثاني هذه العوامل هي الثقافة العامة الضابطة: بمعنى؛ ما هي الأعراف العامة التي تلزم مجتمع مبرمجين معين بشكل غير رسمي؟ فمثلاً في مجتمع نظام التشغيل “لينكس” لماذا استحق لينوس تورفالدس “Linus Torvalds” ملكية المشروع؟ وكيف تتم نقل ملكيته هو أو غيره من المشاريع؟ ومن الذي يملك شرعية اتخاذ القرارات داخل مجتمع لينكس؟

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

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

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

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

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

التعقيد

تعتبر البرمجة عملية ضخمة ومعقدة للغاية من الناحية الفنية، تحتوي نواة نظام التشغيل لينكس على 27.5 مليون سطر من الأكواد^{^[7]}، فما هي طبيعة الحوكمة في عملية المصدر المفتوح التي تمكن هذا المجتمع من إدارة هذه الأنظمة المعقدة بنجاح؟ اقترح ستيفن ويبر أربعة عوامل مؤثرة في حوكمة عملية التعقيد: التصميم الفني “Technical Design”، سياسة المعاقبة “Sanctioning”، الترخيص “Licenses”، وهيكل الحوكمة الرسمي “Formal Governance”.

التصميم الفني

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

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

سياسة المعاقبة

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

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

الترخيص

تعتبر ترخيص المصدر المفتوح عبارة عن مستندات ذات نمط قانوني، توضح شروط استخدام البرنامج الذي تغطيه، طَور مجتمع المصدر المفتوح عشرات التراخيص أشهرها “General Public License GPL”، و”Berkeley Software Distribution BSD”.

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

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

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

هيكل الحوكمة الرسمي

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

خاتمة

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