هندسة برمجيات المصادر الحرة

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

و
علي الرغم من انتشار التفكير و المشاركة في مشاريع مفتوحة المصدر بين
المبرمجين العرب إلا أن هندسة البرمجيات التي تتناسب مع هذا النوع من
المشاريع البرمجية لا يوجد لها أثرٌ فيما أعلم في المؤلَّفات و المترجَمات !

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

و أذكر من أوجه الاختلاف بين عالم المصادر المفتوحة المصدر و عالم البرمجيات المغلقة المصدر ما يلي علي عجالة:

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

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

فهل من مُشَمِّر و متفرغ ؟

------------

روابط مفيدة:

عرضٌ تقديميٌ صغيرٌ بعنوان: [ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]
كتاب [ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]
[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]

رابط المقال علي مدونتي الشخصية:
[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]

» هو منتدانا _ منتدى هندسة اسوان ولا هندسة حلوان ؟؟؟
» مجموعة كتب الكترونية كهربائية عن الجهد العالى و هندسة التوزيع الكهربائي و الكيابل و هندسة القوى الكهربائية و صيانة الراديو والتلفزيون.
» فرصه عمل كمندوب لشركه برمجيات مصريه
» برنامج PolyBoard لصناعة برمجيات الخزائن (الدوايب)
» سلسلة تعليم برمجيات الجافا والجي ديفولبر - محمد ياسين