في المقال السابق تحدثتُ عن ثغرة “نزف القلب heartbleed” التي تم اكتشافها في الفترة الماضية في مكتبة OpenSSL مفتوحة المصدر و ذات الشهرة الفائقة في عالم التشفير، و تحدثتُ عن ردود الفعل المختلفة لاكتشاف الثغرة و التي صدرت من أفراد و هيئات مختلفين، ثم عبَّرتُ في نهاية الأمر عن رأيي القائم علي أن الثغرات البرمجية يكاد لا يخلو منها برنامج سواء أكان مفتوح المصدر أو مغلقه، و سواء أكان ضخماً أو صغير الحجم، و سواء أكان يتم الإنفاق عليه بالملايين أو لا يُنفق عليه أي شيء؛ فالأمر الذي يعلمه كل المبرمجين أنه مهما بلغ الواحد منهم من البراعة و الذكاء فإنه يظل مجرد بشري له أخطاؤه و خطاياه، و حتي أفضل تصميماته و أكواده يظل فيها و لو هامش صغير من الثغرات، التي يمكن لمن هو أكثر علماً و/أو ذكاءً (أو حتي أقل علماً و ذكاءً!) أن يكتشفها قبله و يستغلها.
و لكن بما أن المقال السابق كان قد حمل الكثير من الأفكار و المعلومات فقد آثرتُ أن أجعل له جزءً آخر؛ حتي أتحدث فيه عن بعض الأمور التي يجب التنبه لها في ظل هذه الأزمة شديدة الوطء، ثم اتضح لي بعد الانتهاء من كتابة هذا المقال أن الموضوع دسم للغاية لدرجة أنه قد يأخذ مقالين إضافيين للتحدث فيه باستفاضة. و لهذا فدعونا نركز علي ذِكر تلك الدروس التي يمكننا الاستفادة بها من الأزمة حتي لا يتورم المقال بلا فائدة.
من أهم الأمور التي كشفتها هذه الأزمة هي مدي المُبالغة في الدعاية للمصادر المفتوحة عن أنها أكثر أمناً بطبيعتها و أقوي بطبيعتها و أبسط بطبيعتها، أي أن نظن أن البرنامج حينما يكون مفتوح المصدر فإن هذا يجعله أكثر أمناً و قوة و بساطة من شبيهاته مغلقة المصدر، بدون بذل أدني جهد إضافي غير فتح المصدر!، و هذا الظن من أسخف الأمور التي يمكن للمرء أن يقنع نفسه بها و يجعلها من أصول تفكيره التي يبني عليها فروعه الفكرية؛ فالمعلوم من العقل بالضرورة أن البرنامج لكي يكون آمناً و أقل نصيباً من الثغرات الأمنية و الأغلاط البرمجية، و أكثر قوة و أشد بساطة، فإنه يجب أن يتوفر له الأمور التالية:
- فريق تطوير متميز، من حيث الاحترافية و المهارة، و الخبرة في مجال تخصص البرنامج، و العدد اللازم لإنجاز الأعمال المطلوبة بكفاءة،
- أدوات برمجية تساعد الفريق علي سرعة إنجاز أعمالهم و حل المشاكل التي تظهر في البرنامج،
- قاعدة واسعة من المختبِرين، و الذين يكون دورهم الرئيس هو اختبار النسخ الأولية من البرنامج قبل طرحه للاستخدام العام؛ حتي يتم اكتشاف أهم المشاكل و إصلاحها قبل وصول التطبيق لأيدي المستخدمين النهائيين،
- قاعدة واسعة من المستخدمين النهائيين الذين يقومون بالإبلاغ عن المشاكل التي تقابلهم أثناء استخدام التطبيق، سواء أكانت مشاكل أمنية أو عدم عمل البرنامج بشكل صحيح نتيجة لوجود بعض العِلل bugs البرمجية، أو مشاكل في تجربة المستخدم UX،
- دعم مادي يكفل لفريق العمل الاحترافي التفرغ كما ينبغي لتطوير البرنامج، و يكفل شراء الأدوات التي يحتاجها المطورون للتطوير، و تلك التي يحتاجها المختبرون لإجراء اختباراتهم، و كذلك التي يحتاجها من يتابعون ردود فعل المستخدمين ليقوموا بالمتابعة.
و لو نظرنا إلي تلك المعايير السابقة و حاولنا المفاضلة بين المصادر المفتوحة و المصادر المغلقة استناداً إليها، فسنري أنه بالنسبة لفريق التطوير فإن البرمجيات مفتوحة المصدر تمتاز بأنه يمكن لأي أحد أن يشارك بها حتي لو كان قليل العلم و/أو غير متخصص بما فيه الكفاية، و هذا رغم أنه يمكن اعتباره عيباً (بسبب أنه قد يعني ضعف مستوي الأكواد التي يتم المشاركة بها)، إلا أنني أري أيضاً أنه يمكن اعتباره ميزة لأنه يزيد من عدد الأيدي العاملة في البرنامج، و من الممكن تلافي عامل عدم التخصص عن طريق المُراجعات التي سيجريها القائمون علي العمل لتلك المشاركات (و بطبيعة الحال يُفترض أن القائمين علي المشروع خبراء و محترفون في ذلك المجال). بينما يقتصر فريق العمل في المشاريع مغلقة المصدر علي عدد محدود من المحترفين و هو ما قد يبدو بدوره عيباً إلا أنه في نظري ميزة (أيضاً !)؛ بسبب أنه يجعل أولئك المحترفين يركزون علي تطوير البرنامج بدون وجود مشاركات للآخرين يجب عليهم مراجعتها بدقة (بسبب احتمال كون أولئك الآخرين غير محترفين)، و هذا يحفظ كثيراً من الوقت الهام للقيام بالأمور التي قد تكون أكثر أهمية.
باختصار: يمكننا أن نقول أن كون فريق العمل صغيراً أو كبيراً لا يعني بالضرورة أن حجمه سيضره أو سينفعه، و بعض المشاريع قد تنتفع بالعدد الصغير للمبرمجين أكثر من العدد الكبير (كما تقول كتب هندسة البرمجيات التي تتحدث عن البرمجيات مغلقة المصدر)، و بعضها قد يستفيد بالعدد الكبير إلي أقصي حد ممكن بسياسات مختلفة لإدارة كل تلك العقول المُشارِكة (مثل مشروع نواة الـlinux الذي يُعتبر أبرز الامثلة علي ذلك؛ حيث أن آخر عدد أعلمه عن عدد المشاركين في المشروع -علي لسان linus torvalds نفسه- كان حوالي الـ2000 شخص -إن لم تخني الذاكرة- !)، و بذلك ينبغي علينا الانتباه لضرورة عدم التعميم في هذه الجزئية و التحدث عن كل مشروع بما يتفق مع حالته الخاصة.
لكن ذلك الأمر يعتمد اعتماداً تاماً علي الدعم المالي الذي يمكن توفيره للمشروع البرمجي؛ حيث لو توافرت المتطلبات المالية المرغوب فيها فسيكون بإمكان كل من القائمين علي المشاريع مغلقة المصدر و مفتوحة المصدر توظيف المبرمجين المحترفين المطلوبين بدوام كامل للعمل علي تطوير المشروع كما هو مخطط له، بينما إن لم تتوفر الإمكانات المادية فإن البرنامج مغلق المصدر لن يكون له الفرصة في التطوير إلا في أوقات فراغ العاملين عليه، و هذا لن ينجح تجارياً إلا إذا كان البرنامج صغير الحجم و لا تستخدمه كيانات ضخمة تتطلب تعاقدات قانونية يجب الوفاء بها بشكل احترافي.
بينما سيكون الباب مفتوحاً قليلاً أمام البرنامج مفتوح المصدر؛ لأنه ربما يقوم أحد الهواة، أو أحد المحترفين (في وقت فراغه)، أو أحد طلاب الدراسات العليا، أو أحد طلاب الجامعة ممن يعملون في مشروع دراسي بالعمل علي تطويره، و هكذا “ربما” يجد التطوير طريقه للبرنامج مفتوح المصدر، حتي و إن كان هذا عن طريق عمل اشتقاق fork منه؛ فالمهم هنا أنه بإمكان المطورين للنسخة الأصلية أن يقوموا بضم التغييرات التي أجراها أصحاب الاشتقاق الجديد إلي نسختهم (و هذا يجعل الاشتقاق من أكبر مناطق القوة في البرمجيات مفتوحة المصدر كما يقول linus torvalds، رغم أنني أري أنه يُعتبر في كثير من الأحيان نقطة ضعف كبيرة بسبب الإخلال بمبدأ التوحيد القياسي في الأحيان التي أري أنه يجب أن يتوافر فيها و لو الحد الأدني من المعايير القياسية).
و لو طبقنا تلك القواعد علي مشروع الـOpenSSL لرأينا أن كونه مفتوح المصدر جعله يعيش علي أقل القليل من الدعم المادي، بل و يصير قوياً لدرجة أن تعتمد عليه ملايين الشركات و الكيانات في برمجياتها، بشكل يجعلك تقلب كفيك تعجباً كيف لمشروع شديد الأهمية مثل هذا المشروع ألا يحصل إلا علي دعم مادي هزيل للغاية (أظن أن آخر مبلغ سنوي حصلوا عليه من التبرعات قبل أزمة نزف القلب كان 2000 دولار فقط !). لدرجة أن ذلك المشروع بالغ الأهمية لا يعمل عليه بدوام كامل إلا شخص واحد فقط، بينما البقية يقتطعون من أوقاتهم ما يستطيعون فيه العمل علي تطوير المشروع. و مثل هذا الأمر لا يمكن القبول به في عالم البرمجيات مغلقة المصدر؛ لأن توظيف مبرمج واحد ليعمل بمفرده بدون مساعدة الآخرين علي تطوير برنامج شديد التعقيد غير جائز منطقياً، و حتي و إن استمر لفترة من الفترات فيكاد يكون من المستحيل عملياً أن يكون هذا الأمر منطقياً من الناحية التجارية و عالم التعاقدات القانونية. و هذا كما نري نقطة تفوق للبرمجيات مفتوحة المصدر.
في النهاية و بما أن هناك نقاط أخري لم نتحدث عنها و لا يتسع لها هذا المقال، فسنكرر نفس ما فعلناه سابقاً و نتركها لمقال تال نتحدث فيه باستفاضة بمشيئة الله تعالي.
ليست هناك تعليقات:
إرسال تعليق