هل يصبح المصدر المفتوح مُنصِفًا حقًا؟

كما هو الحال مع معظم الأمور، فالصورة ليست بالأبيض والأسود.
 

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

شهدنا مشاريع شهيرة مثل «ريديس» تتخلّى عن رخصها مفتوحة المصدر التقليدية وتستبدِلها برُخَص أكثر تقييدًا، تاركةً خلفها مجتمعات كاملة من المستخدمين غاضبين بلا دعم أو سَنَد.

اختُطِفَت المحادثات البنّاءة التي كان من المفترض أن تُعالِج هذه القضايا —كحوكمة المصدر المفتوح واستدامته— من شخوص مثل مات مولينويغ الذي استشاط غضبًا لمجرّد أن منافسيه استفادوا (بشكل مشروع) من مزايا «ووردبريس» مفتوح المصدر.

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

ما الذي يحدث بالضبط؟!

أولاً

اختلقت برمجيات المصدر المفتوح واقعًا جديدًا، اختلفَت فيه توقعات الناس والشركات منه.

عندما بدأتُ مسيرتي المهنية كمبرمج، كنت أنشر كل مشاريعي الأولى على «غيت هاب» كطريقة لاستعراض مهاراتي أمام الشركات (ولنكن صادقين، يعود هذا إلى نصائح مؤثري «يوتيوب» من موظفي FAANG السابقين). لم أكن أتوقع شيئًا من فتح مصدر هذه المشاريع سوى أن تكون مراجع علنية لعرض أعمالي. (وبصراحة، معظم هذه المشاريع لم تكن ذات فائدة عدا عن ذلك).

مع مرور الوقت، تحسّنَت مهاراتي البرمجية وتحسنت جودة مشاريعي. وهذه المشاريع كانت مفتوحة المصدر لذات الأسباب الشخصية المذكورة. نال أحد هذه المشاريع شعبية لا بأس بها: حصَّل ١٧٠٠ نجمة على «غيت هاب»، وظهر في الصفحة الأولى على منصة «هاكر نيوز» وجذبَ ٤٠ ألف مستخدم. نجح المشروع لأنه كان مجانيًا للمستخدمين ومفتوح المصدر للمساهمين المحترفين الذين يريدون تحسينه.

مرة أخرى، لم تكن لديّ توقعات غير شخصية. نما قسم "المشاريع الشخصية" في سيرتي الذاتية فجنيت وظيفة رائعة، جميل! ولم يتوقع مستخدمو المشروع الكثير —نظرًا لأن المشروع مجاني ومفتوح المصدر— وبعضهم تحوَّل لاحقًا إلى مساهمين، إذ بدأوا بِحَل مشكلاتهم الخاصة، مما عاد بالنفع لاحقًا على الآخرين. جميل جدًا!

يسمي دافيد هاينماير هانسون هذا النموذج بـ "تبادل الهدايا"؛ أي أن تُهدي مشروعك للمستخدمين، وخيارهم الوحيد قبول الهدية أو رفضها.

’’وهنا تبرز أهمية هذه الاستعارة؛ فتُوضِّح التوقعات لدى طرفَي عملية التبادل. إذا تلقيت هدية دون التزامات، لن تُطالَب بأكثر من الاختيار بين قبولها أو رفضها. وإذا كنت المانح، فسيكون من السذاجة أن تتوقع نوعًا من المقابل.‘‘
David Heinemeier Hansson The open source gift exchange

التوقعات واضحة، أو بالأحرى، التوقعات متوازنة.

لم تَغِب فوائد المصدر المفتوح عن الشركات؛ كزيادة تبنّي البرمجيّات، والمجتمع النشط، وتحسين جودة المُنتَج. الأمر المفاجئ أن هذه الفوائد دفعت العديد من الشركات لاستثمار وقتها، وجهدها، ومالها في مشاريع مفتوحة المصدر، حتى لو استفاد منها المنافسون أيضًا.

تعتبر «كوبيرنيتيس» Kubernetes ومعها Cloud Native Computing Foundation مثالاً جيداً، إذ يستفيد الجميع من انفتاح مصدر برمجيّة «كوبيرنيتيس». الشركات الضخمة مثل «غوغل» و«مايكروسوفت» و«أمازون» تضخ المال، لكنها تستفيد من الخدمات المبنية على «كوبيرنيتيس». تجذب هذه الشركات العملاء بفضل الانتشار الواسع لـ«كوبيرنيتيس».

يستفيد الكل من ذلك؛ والأهم هو أن لدى كل الأطراف دافع حقيقي لتحسين مشاريع المصدر المفتوح.

في عملي السابق لدى API7.ai، كنا نقدِّم حلولًا مدفوعة مبنية على مشروع Apache APISIX. مشروع APISIX مفتوح المصدر ويخضع لإشراف مؤسسة Apache Software Foundation (ASF). بإمكان أي شخص أن يستخدم APISIX بحُرِّيّة أو أن يعدله، والعديد منهم يستخدمونه في البيئات الإنتاجية. تستهدف API7.ai شريحةً صغيرة ممن يريدون ميزات إضافية ودعمًا مؤسسيًّا.

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

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

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

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

انظر كيف انقلبت الموازين.

تُعَدّ تغييرات التراخيص مجرد أعراض لمشكلة أعمق تتعلق باستدامة المصدر المفتوح. لخَّص دريس بويترت —مبتكِر منصة «دروبال»— الأمر بدقّة حين قال:

يُضِرُّ المنتفعون الأنانيون —مثل «غوغل» و«أمازون»— بمشاريع المصدر المفتوح؛ إذ قد يدفع استغلالهم المساهمين المنتجين (مثل ريديس لابز) إلى التصرف بطريقة أكثر أنانية تقلل أو تمتنع كلياً عن الإسهام في المصدر المفتوح. يستطيع المنتفعون الأنانيون أن يُحوِّلوا المساهمين المنتجين إلى نسخة عنهم.
Dries Buytaert Balancing Makers and Takers to scale and sustain Open Source

التوازن مفقود؛ أي يأخذ المستفيد أكثر ممّا يعطي، ويَشعر المُنتِج بالخذلان. كانت «إلاستيك» في نفس الموقف الذي واجهته «ريديس»، وانتهى بها الأمر إلى نفس المصير. حتى النسخة المتفرِّعة التي أطلقتها «أمازون» لم تُفِدها كثيرًا.

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

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

وهذا بدوره... غير عادل.
 

ثانيًا

مشكلات الاستدامة ليست محصورة بالمصدر المفتوح، بل ترتبط جوهرًا بكيفية تعاملنا مع أي سلعٍ مشتركة؛ في الحالتين نتصرّف وفقًا لما يحفزنا.

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

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

ونرى محاولات للخصخصة بالفعل في تغييرات التراخيص، حيث تسعى الشركات —بوصفها الجهات التي طوَّرت المشروع مفتوح المصدر— إلى أن تكافئ نفسها بمزايا حصرية. تُعدّ مؤسسات المصدر المفتوح مثل Apache Software Foundation ومؤسسة «لينكس» أمثلة جيدة على المركزية، على غرار الطريقة التي تدير بها الحكومات السلع المشتركة.

أظهر استطلاع حديث أجرته منظمة Open Source Initiative (OSI) أنّ رُخَص "المصدر التجاري"، —مثل تلك التي اعتمدَتْها وأبرزتها MariaDB— تشهد نموًا سريعًا. ومؤخرًا، تشكَّل ائتلاف من الشركات التي تستخدم هذه الرُخَص وتدافع عنها، وأطلِق عليه اسم Fair Source. وتقوم الأفكار الأساسية وراء هذه الرُخَص على شروط الاستخدام غير التنافسي، والنشر المؤجَّل للكود.

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

يمكن أن يقع الاعتماد القسري على مزوِّد واحد (Vendor lock-in) حتى في مشاريع المصدر المفتوح. لقد عمِلْت على ما لا يقل عن ثلاثة مشاريع حاولَت أن تتجنب هذا الأمر. يحضر إلى الذهن كاريكاتير XKCD عن توحيد المعايير... التي تنتهي بإضافة معيار جديد! سنغضّ الطرف عن هذه النقطة في الوقت الحالي.

في نموذج Fair Source وغيره من رُخَص عدم التنافس، يُمكن للشركة أن توضِّح نواياها وتوقعاتها منذ البداية. ويعود ذلك بالنفع عليهم؛ فيحصلون على أذونات حصرية لتحقيق الدخل من مشاريعهم عبر أدوات وخدمات مكمِّلة مدفوعة، أو استضافة سحابية، أو غيرها من المنتجات والخدمات.

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

يُعرَف هذا النموذج أيضًا باسم نموذج الأعمال التجاري مفتوح المصدر ذو المزوِّد الواحد.

ومع ذلك، تظل الحقيقة قائمة؛ سواءً في المصدر المفتوح أو في نماذج قريبة منه مثل Fair Source، سيظلّ هناك منتفعون أنانيون ممن يستفيدون دون أن يعطوا شيئًا بالمقابل. ما يميِّز Fair Source أنه لن يؤثِّر على استدامة المشروع.

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

لكن بعدما قرأت وتعمَّقت، اتضح لي أن الفائدة متوازنة أكثر مما هو ظاهر. إذ تُعيد هذه الرُخَص التوازن بين العطاء والأخذ. والخلاصة: قد لا يكون المصدر المفتوح منصِفًا دائمًا، ولكن البدائل القريبة —مثل Fair Source— قد تكون كذلك. علينا أن نعتمِد ما يُجدي نفعًا، وأن نُعطي الأولوية للاستدامة على حساب المثالية المطلقة لفكر المصدر المفتوح.

ثالثًا

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

يُعَدّ نموذج Fair Source حلّاً أفضل ولو بدرجة هامشيّة. إذ يضع توقعات واضحة تجعله بديلًا للبرمجيات مغلَقة المصدر، لا للمصدر المفتوح. الغرض منه هو منح بعض الحقوق الحصرية لمطوِّري البرمجيّات المفتوحة لضمان استدامتها، وهذا يوازي ما نعرفه عن إدارة السلع المشتركة.

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

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

لا نزال في بداية طريق إدراك ما يُجدي نفعًا وما لا يُجدي في بيئة المصدر المفتوح. والأهم من ذلك، أن نستمِرّ في تجربة حلول أفضل ولو بدرجة طفيفة، لمواجهة مشكلاتنا الحالية والمستقبلية.

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

تمت إعادة نشر هذا المقال وفقاً لرخصة المشاع الإبداعي - Creative Commons، للإطلاع على المقال الأصلي.