ترجمة: زاهر النوتكي
بعض النقاط المهمة:
عندما يتم إدارة البرمجيات المفتوحة المصدر وتطبيقها بشكل فعال ، فإنها من الممكن أن تكون بديلا ممتازا للتطبيقات المغلقة المصدر.
لا تمتلك البرمجيات المفتوحة المصدر في الكثير من الأحيان المصادر أو الدعم المالي ولكن لها إيجابيات محددة في الكثير من المواقف.
البرمجيات المفتوحة المصدر تأتي مع رخصة استخدام ، لذا فأن أي استخدام لمثل هذه البرمجيات يرافقه حقوق وواجبات معينة ، وعدم الالتزام بها لها تبعاتها القانونية والمالية.
على المؤسسة التعليمية أن تشرك مساهمين ذو خبرة بالمشاريع لصياغة الأطر الاستدلالية والتوجيهية الملائمة حتى تعود مثل هذه المساهمات بالنفع للمؤسسة نفسها.
تمتاز اليوم مؤسسات التعليم العالي بحس المسؤولية العالية وقلة الدعم المالي المخصص لها. وفي مثل هذه الحالات لا يمكن أبدا لمؤسسات التعليم العالي تجاهل تبني الحلول البديلة للبرمجيات مغلقة المصدر ، والتي من الإمكان أن تقدم حلول أكثر فاعلية بتكلفة منخفضة في الوقت نفسه. لذا يمكن للبرمجيات المفتوحة المصدر (OSS) اختصارا لمصطلح (Open source software) أن تكون بمثابة بديل حقيقي وفعلي للبرمجيات المغلقة المصدر التقليدية (PS) ، ولكن ولضمان اختيار واعتماد البرمجيات المفتوحة كبديل بصورة فعالة على المؤسسة القيام بالأمور التالية:
استيعابها لماهية رخص التطبيقات (OSS licensing model).
معرفتها بالوقت المناسب لتبني واستخدام البرمجيات مفتوحة المصدر.
إدارة عملية استخدام البرمجيات مفتوحة المصدر بطريقة فعالة.
وثّق تاريخ تطور البرمجيات المفتوحة المصدر بطريقة جيدة في العديد من المواقع والمنتديات الحوارية ، حيث كانت بدايتها في الأساس تقتصر على توفير أدوات البنية التحتية لتقنية المعلومات ، ولكنها ومع التطورات المتلاحقة أصبحت تستهدف لتوفير مجموعة كبيرة من الأدوات والحلول التقنية المصممة خصيصا لاستخدام المستخدم النهائي العادي. وخلال فترة تقلدي إدارة قسم تراخيص البرمجيات والتطبيقات بجامعة كاليفورنيا ، تطورت استخدامات مثل هذه التطبيقات المفتوحة المصدر من التحكم في سيرفر القسم الذي يعمل على نظام لينكس لتشمل لاحقا تطبيقات خدمية مثل كل من "Moodle" و "Shibboleth" والتي أصبحت لاحقا أحد الأساسيات في تقديم الخدمات التعليمية على مستوى المؤسسة.
يلخص هذا المقال بعض النقاط الرئيسية لتقييم إمكانية اعتماد البرمجيات مفتوحة المصدر كأحد الحلول البرمجية المعتمدة بالمؤسسة التعليمية. كتبت الطرق المقترحة في هذا المقال بطريقة تتناسب مع احتياجات مؤسسة تعليمية لامركزية مثل جامعة كاليفورنيا لوس أنجلوس (UCLA). لذا وتبعا للهيكل التنظيمي لمؤسستك ، فقد تحتاج إلى اعتماد منهج مغاير يتناسب مع متطلبات مؤسستك.
وكما سيتم توضيحه لاحقا في هذه المقالة ، فإنه لاستخدام البرمجيات المفتوحة المصدر آثار تتجاوز حدود قسم تقنية المعلومات بالمؤسسة ، لذا عليك إشراك العديد من الجهات ذات الصلة في اتخاذ القرار ومن مراحل المشروع الأولى ، بما في ذلك كل من المكتب المختص بتراخيص البرمجيات ومكتب حقوق الملكية الفكرية بالإضافة إلى الخبراء القانونيين لضمان تطبيق الحلول البرمجية المفتوحة المصدر كبديل بصورة ناجحة.
بالإضافة إلى ذلك قمت بتضمين هذه المقالة بالعديد من الجداول التوضيحية التي تبين السمات المشتركة بين مختلف البرامج والتطبيقات ، ولكنها تختلف في حالة كونها تطبيقات برمجية مفتوحة المصدر (OSS) أو تطبيقات مغلقة المصدر(PS). تختلف إيجابيات وسلبيات البرمجيات مفتوحة المصدر والمغلقة باختلاف المنتج أو التطبيق البرمجي. فعلى سبيل المثال ، النظام التشغيلي "لينكس" يختلف كليا من تطبيق مفتوح المصدر ناشئ كاختلاف نظام مايكروسوفت ويندوز عن أي تطبيق جديد ضمن قائمة برامج بدء التشغيل. ولهذا السبب نفسه، فإن بعض المعلومات الواردة في هذه الجداول تتضمن بعض التعميمات.
نموذج رخص البرمجيات مفتوحة المصدر
لا يتم تعريف التطبيقات البرمجية من خلال الإمكانيات التي تملكها وإنما من خلال المهام التي تقوم بها أو الحلول التي توفرها للمستخدم النهائي. ومن الأمور الأساسية التي تميز البرمجيات مفتوحة المصدر عن غيرها من البرمجيات المغلقة هي نموذج الرخصة البرمجية التي يندرج التطبيق تحتها. وحتى تستطيع فهم هذه البرمجيات فهما كاملا يحتاج المستخدم لاستيعاب بعض المصطلحات المتعلقة بتراخيص البرمجيات المفتوحة المصدر وأنواعها المختلفة.
ترتبط عادة مواضيع "ماهية" البرمجيات المفتوحة المصدر وإيجابياتها وسلبياتها لنقاشات حادة بسبب اختلاف آراء المستخدمين مع وجود بعض المفاهيم المغلوطة المرتبطة بمثل هذه التطبيقات. ومع وجود العديد من الأسباب الفلسفية التي تقف وراء استخدام مثل هذه البدائل ، ولكن بالنسبة للأشخاص الذين يبحثون عن مسؤوليات تشغيلية وحلول عملية فإن قرار اعتماد الحلول البرمجية مفتوحة المصدر يكون اختيارا حكيما إن كان مبنيا على أسباب عملية لا فلسفية تنظيرية.
ومن أكثر المفاهيم المغلوطة والمتعلقة باستخدام البرمجيات مفتوحة المصدر بأنها حلول وتطبيقات "مجانية". على الرغم من أن هذه التطبيقات تأتي في كثير من الأحيان من دون أي تكلفة تذكر وخاصة المتعلقة بالتراخيص ، إلا أن هناك تكاليف غير مباشرة تتعلق سواء بالدعم الفني أو غيرها من الأمور المرتبطة بالعديد من هذه التطبيقات. كما تتفاوت قيمة هذه التكاليف غير مباشرة حسب طبيعة المشروع أو التطبيق والتي سنتطرق لها في قادم هذه المقالة.
| الصفة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
| تكلفة رخصة التطبيق | على المستخدم دفع قيمة رخصة الاستخدام الأولية وأي زيادة محتملة في عدد الأجهزة المستخدمة للتطبيق والترقيات مع بعض التكاليف الإضافية المحتملة سواء لتجديد الرخصة أو التحديثات أو\و الاستخدام المنزلي. | لا توجد أي رسوم متعلقة بالتراخيص سواء رخصة استخدام التطبيق لأول مرة أو رخصة زيادة عدد الأجهزة المستخدمة للتطبيق أو لتجديد الترخيص ، والتحديثات ، والترقيات و/أو للاستخدام المنزلي. |
أثناء عملية التقييم لاختيار البرمجيات المناسبة ، عليك اعتبار البرمجيات المفتوحة المصدر (OSS) ببساطة عبارة عن خيار تجاري آخر (برخصة مختلفة) لمساواته مع البرامج المغلقة المصدر أثناء أي عملية شراء للبرمجيات. لذا ومن خلال النقاط التالية سنستوضح الجوانب التي تختلف فيها تراخيص البرامج المفتوحة المصدر عن البرامج المغلقة المصدر.
| السمة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
| شروط التراخيص |
|
|
تقع شروط تراخيص البرمجيات مفتوحة المصدر (توفر الشفرة المصدرية ، التوزيع ، أهلية الاستخدام) بشكل عام تحت بنود "تعريف البرمجيات مفتوحة المصدر" التي وضعتها مبادرة المصادر المفتوحة (OSI). وحتى الآن، قامت المبادرة بالموافقة على ٦٦ رخصة مختلفة.
تختلف تفصيلات كل رخصة عن غيرها من الرخص لذا فمن المهم أن تكون على اطلاع على تفاصيل كل منتج من منتجات البرمجيات المفتوحة المصدر. يذكر "لاورنس روسن" في كتابه "تراخيص المصادر المفتوحة" بأن تراخيص البرمجيات المفتوحة المصدر تندرج ضمن إحدى هاتين الفئتين:
التراخيص الأكاديمية مثل رخصة BSD والتي تتيح استخدامها لأي غرض كان دون التزام المرخص له بتوزيع الشفرة المصدرية لأعمال مشتقة ومبنية على هذه الرخصة. لذا فبإمكان لأي شخص من استخدام التطبيق لأي غرض كان بما في ذلك بناء تطبيقات غير مفتوحة المصدر.
التراخيص التبادلية: مثل رخصة GPL والتي تتيح استخدامها لأغلب الأغراض ولكنها تشترط نشر الأعمال المشتقة تحت الرخصة نفسها. وهذا ما يمنع لاحقا من دمج البرمجيات المفتوحة المصدر ضمن برامج مغلقة المصدر.
نتائج تراخيص منتجات البرمجيات مفتوحة المصدر المستخدمة فقط لأغراض داخلية ("الاستخدام الوارد") عادة ما تكون قليلة جدا. ولكن أغلب هذه المخاوف تتعلق "بالاستخدام الصادر" عندما تقوم مؤسسة ما من بناء أعمال مشتقة من برمجيات مفتوحة المصدر و أما تقوم بنشر الشفرة المصدرية للعامة أو إعادة توزيعها خارج المؤسسة التعليمية.
تعتبر كذلك البرمجيات مفتوحة المصدر برمجيات مرخصة ، لذا فإن أي استخدام لمثل هذه البرمجيات يرافقه العديد من الحقوق والالتزامات المحددة. والإخلال بهذه الالتزامات ينطوي على مخاطر قانونية ومالية خطيرة. لذا ومن الأمور المهمة أن تقوم المؤسسة بالإطلاع على بنود التراخيص المرافقة للبرمجيات المفتوحة المصدر واستيعابها والقيام بكل ما يلزم لضمان الامتثال لها بالشكل الصحيح. حيث أن المخاطر القانونية والمالية المرتبطة بانتهاك مثل التراخيص لكل من البرمجيات المفتوحة المصدر والبرمجيات المغلقة متطابقة مما يستوجب على المؤسسة التدقيق في بنود هذه التراخيص بشكل دقيق ومماثل لتراخيص البرمجيات المغلقة المصدر.
متى يكون استخدام البرمجيات مفتوحة المصدر أمرا معقولا؟؟
تبدي أغلب المؤسسات اهتماما مبدئيا للبرامج مفتوحة المصدر من أجل توفير المال المترتب من شراء التراخيص ، ولكن ومع ذلك فاستخدام هذه البرمجيات يوفر في الوقت نفسه الكثير من المزايا الأخرى مثل سهولة تخصيصها والتقليل من فرص احتكار الشركات الكبرى.
| الصفة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
| المرونة: مدى سهولة تخصيص التطبيق ليتناسب مع احتياجات المؤسسة الخاصة | لا تتيح البرامج المغلقة في العادة إمكانية تخصيصها حسب متطلباتك الشخصية. التطبيقات المغلقة المتقدمة تقدم ميزات وخصائص أكثر مقارنة مع نظيراتها من التطبيقات المفتوحة المصدر. توفر شركات التطبيقات برامجها في كثير من الأحيان على شكل حزم بدل توفيرها على شكل وحدات منفصلة مع تخزين بيانات المستخدم بصيغ مغلقة مما يجعل من الصعب بمكان استبدال المنتج بمنتج آخر مما يشجع الشركات على الاحتكار. | توفر الشفرة المصدرية للبرمجيات مفتوحة المصدر إمكانية التخصيص سواء باستخدام الموارد المحدودة بالمؤسسة أو بالاستعانة بخبرات خارجية. كما يسهل إمكانية الوصول للشفرة المصدرية للآخرين لتخصيص التطبيق وبالتالي يستطيع مجتمع البرمجيات الحرة الاستفادة من مثل هذه تغييرات. بالإضافة إلى ذلك ، يوفر استخدام البرمجيات المفتوحة المصدر خيارات عدة ليس فقط في اختيار المنتج وإنما أيضا في اختيار الدعم والعتاد وكلما توفرت خيارات عدة يصبح الأمر أكثر مرونة. |
لا يمكن اعتبار البرمجيات مفتوحة المصدر عصا سحرية ، ومع ذلك ومع الميزات المذهلة التي تتميز بها ، يرافق استخدامها بعض المخاطر التي تشمل زيادة الحاجة للدعم الفني بالإضافة إلى ذلك فإن القضايا المعقدة لحقوق الملكية الفكرية تؤثر سلبا على إمكانية دمج مثل هذه البرمجيات ضمن أعمال برمجية جديدة أو إدراج الشفرات المصدرية الجديدة بتطبيقات برمجية قائمة.
| الصفة | البرمجيات الاحتكارية | البرمجيات مفتوحة المصدر |
| تكلفة الدعم الفني | يتم إدراج تكاليف الدعم الفني ضمن تكلفة ترخيص المنتج أو في بعض الأحيان يتطلب دفع رسوم سنوية إضافية. يقدم الدعم الفني للمنتج في العادة من الشركة المنتجة مما يقلل من التنافسية لعدم توفر خيارات بديلة. يمكن توفير دعم فني محلي ولكن سيكون الأمر أكثر تحديا لعدم توفر الشفرة المصدرية للتطبيق. توفر بعض التطبيقات المغلقة قنوات لمجموعات مستخدمين مما يمثل أحد خيارات الدعم الفني المتوفرة.
| يتوفر الدعم الفني مقابل أجر مالي وقد يكون من الصعب في كثير من الأحيان تحديد الجهات التي تقدم الدعم الفني للبرمجيات مفتوحة المصدر غير المشهورة. توفر الشفرة المصدرية للبرمجيات يشجع تنافس السوق في تقديم الدعم الفني مما يؤدي إلى انخفاض تكاليف الدعم المقدم. وجود دعم فني داخلي بالمؤسسة أمر مهم ولكن توفر الشفرة المصدرية يسهل الأمر لموظفي تقنية المعلومات بالمؤسسة لمعرفة تفاصيل عمل التطبيق بشكل أسهل. يمكن الحصول على الدعم من خلال مجتمع مستخدمي التطبيق: "سرعة التجاوب ودقة الدعم الفني المقدم على القوائم البريدية أفضل بكثير من ما يقدم من قبل العديد من شركات البرامج المغلقة." |
كل التطبيقات بأنواعها عبارة عن شكل من أشكال الملكية الفكرية. وعند حصول المؤسسة على هذه البرمجيات فهي لا تمتلك حقوق المنتج وإنما حقوق استخدامه ضمن بنود محددة سلفا.
| الصفة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
الملكية الفكرية (IP): خطر انتهاك منتج ما براءات الاختراع لمنتج آخر أو حقوق الملكية الفكرية للآخرين. | يمكن التفاوض مع الشركة المنتجة لتوفير حقوق براءات الاختراع. | لا توفر تراخيص البرمجيات المفتوحة المصدر تأمين براءات اختراع ولكن يمكن توفيرها من خلال بعض الشركات مثل ريدهات أو نوفيل سوزي لقاء رسوم مالية.
تضيق بعض تراخيص البرمجيات المفتوحة المصدر الخناق على دمج البرمجيات الجديدة مع برمجيات موجودة سلفا بحيث تشترط إعادة نشر التطبيقات الجديدة بموجب بنود الرخصة الأصلية. يمكن إدراج الكود المصدري دون قصد في عمل جديد والذي يتم توزيعه لاحقا على نحو مخالف لبنود "الاستخدام الصادر" لترخيص التطبيق. |
يفضل تقييم كل الحلول المحتملة (برمجيات مفتوحة المصدر أو غيرها) بآلية "كل حالة على حدة" بناء على الاحتياجات المحددة لكل مشروع. وفي النقاط التالية تمثل السمات المطلوب أخذها بعين الاعتبار والمتشابهة جوهريا بين التطبيقات المفتوحة المصدر والتطبيقات المغلقة:
مدى ملائمتها.
الجودة
الموثوقية
مستوى الأمان
سهولة الاستخدام
| الصفة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
| مدى ملائمة التطبيق: هل يوفر التطبيق الميزات والوظائف المطلوبة؟ | تراخيص التطبيقات لها مدة محدودة وأحيانا ترتبط برسوم إضافية. يمكن للشركة المنتجة تغيير اتجاه منتج ما أو التوقف عن تطويره بسبب عدم وجود ربحية كافية أو بسبب عملية اندماج/استحواذ/او حتى إفلاس الشركة المنتجة. تملك البرامج المغلقة طرقا أكثر وضوحا لتحديد والحصول على مثل هذه البرمجيات مقارنة مع مثيلاتها من البرمجيات المفتوحة المصدر. | بما أن تراخيص البرمجيات المفتوحة المصدر بلا رسوم مالية فتقييم التراخيص بلا تكلفة تذكر وبدون تاريخ انتهاء صلاحية. المساهمة في نقاشات المجتمع يوفر للمؤسسة إمكانية التأثير في طريقة تطوير المنتج بالطريقة التي تتناسب مع احتياجات المؤسسة الخاصة. مسألة التعرف على حل تقني مفتوح المصدر والحصول عليه ليست بالأمر الواضح ، لذا من الممكن أن يتطلب الأمر الاستعانة ببعض الخبرات الداخلية للقيام بذلك. |
| الصفة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
الجودة: مدى تنظيم عملية تطوير البرنامج؟ و عدد الأخطاء التي يحتويها التطبيق؟
| غالبا ما يتم اعتبار مسألة تطوير البرمجيات المغلقة على أنها أكثر فعالية من ناحية الإدارة بسبب وجودها تحت راية عمل مؤسسي. عادة ما يتم توظيف العديد من المطورين بدوام كلي لضمان أن الشفرة المصدرية للتطبيق خالية من أية أخطاء برمجية ولكن ومع ذلك فمن النادر جدا أن لا يتطلب البرنامج إصدار بعض الترقيعات البرمجية أو حزم لإصلاح الأخطاء. تقوم الشركات المنتجة من توفير التحديثات والترقيات بشكل استباقي. عادة ما تكون الشركة المنتجة المصدر الوحيد الموثوق في إصدار تحديثات إصدارات تطبيقاتها. | من الأمور المقلقة في تطوير البرمجيات مفتوحة المصدر سوء إدارة بعض مشاريعها بسبب عدم ارتباطها بمؤسسة تتبنى المشروع بشكل كامل ولكن نلاحظ بأنه كلما كبر المشروع كلما كانت إدارته بشكل أفضل. بالإضافة إلى ذلك ، فهناك قلق من عدم وجود مسؤول محدد معني بتوفير معايير جودة التطبيق وجودة الشفرة المصدرية ولكن غالبا ما يشير مؤيدي البرمجيات المفتوحة المصدر إلى حقيقة أن هذه البرمجيات تكون ذا موثوقية أكثر من البرامج المغلقة لأن كل سطر برمجي يتم مراجعته بصورة مستمرة من قبل المجتمع وأثناء استخدام التطبيق نفسه. وفي حالة كان الدعم المقدم "داخلي" بالمؤسسة نفسها ، يتحتم على موظفي قسم الدعم الفني البقاء على اطلاع على التحديثات والترقيات بصورة مستمرة. صعوبة تحديد مصادر موثوقة للحصول على تحديثات إصدارات التطبيق بدون وجود دعم طرف ثالث. |
الصفة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
| الموثوقية: إلى متى سيظل التطبيق متوفرا؟ | استمرارية التطبيقات المغلقة تعتمد في الغالب على الجدوى الاقتصادية للتطبيق ، كما تملك الشركة المنتجة خيار إجبار المستخدم على ترقيات التطبيق للإصدارات الأخيرة دون السماح للبقاء على الإصدارات الأقدم من التطبيق.
| تتطلب التطبيقات البرمجية مفتوحة المصدر مشاركة مستمرة من المجتمع من مبرمجين ذو خبرة لضمان استمرارية توفر التطبيقات. وفي حين وجود إمكانية حدوث تغيير لاتجاه أي منتج كان ، يستطيع المستخدم اختيار الابقاء على أي نسخة من نسخ التطبيق إلى أجل غير مسمى. |
| الصفة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
| الأمان: من السمات المهمة هي مدى مقاومة التطبيق إلى أي محاولة اختراقات محتملة مثل الفيروسات وعمليات القرصنة ، ألخ) وهناك العديد من وجهات النظر المتعلقة بهذا الموضوع. | تملك الشركات الكبرى والمنتجة للبرمجيات المغلقة القدرة على استئجار عدد من مطوري البرمجيات بدوام كلي للتأكد من خلو برمجياتهم من أي علل برمجية محتملة. وبما أن الشفرة المصدرية غير مفتوحة فمن الصعب بمكان للمستخدمين المخربين معرفة نقاط ضعف البرمجيات لاستخدامها لأغراض تخريبية محتملة. ومع ذلك فمن غير الإمكان للمستخدم العادي من الإطلاع على الشفرة المصدرية للتطبيق لمراجعته وتحديد مستوى الأمان قبل تبنيه فعلا. | من الصفات الرئيسة للبرمجيات المفتوحة المصدر توفر الشفرة المصدرية للجميع مما يسهل اكتشاف مثل هذه الثغرات المحتملة واصلاحها بشكل أسرع. وفي الجانب المقابل بإمكان "الأشخاص المخربين" من الإطلاع على الكود البرمجي لأي تطبيق كان مما يسهل عملية تحديد نقاط الضعف المحتملة والتي من الممكن استخدامها للقيام بعمليات اختراق أو قرصنة. بالإضافة إلى هذا وذاك ، يستطيع المستخدم المتبني للتطبيق من مراجعة مستوى الأمان قبل تبني أي تطبيق. |
| الصفة | البرمجيات مغلقة المصدر | البرمجيات مفتوحة المصدر |
| سهولة الاستخدام: مدى سهولة استخدام التطبيق | مدى سهولة استخدام التطبيقات المغلقة تختلف من تطبيق إلى آخر ولكن عموما تتميز هذه التطبيقات بواجهات مستخدم احترافية مما توفر سهولة استخدام للمستخدم العادي. | أعطت البرمجيات المفتوحة المصدر في بداياتها تصورا عاما بأنها تفتقر إلى وجود واجهات مستخدم غير احترافية بسبب الفكرة السائدة بأن مثل هذه البرمجيات تصمم من قبل "مبرمجين" لاستخدام "المبرمجين" أنفسهم. ولكن ومع مرور الوقت وتطور هذه البرمجيات بدأت هذه الفكرة تتغير تدريجيا خاصة مع ظهور برمجيات مثل فايرفوكس وأوبن أوفيس ونظام اوبنتو لينكس. |
التوقيت المناسب لتبني البرمجيات المفتوحة المصدر
أنسب وقت لاعتبار البرمجيات المفتوحة المصدر أحد الحلول البرمجية في الأوقات التالية:
لا تملك أي نظام فعلي في الوقت الحالي.
النظام المطبق الحالي أو الحلول البرمجية الحالية قد قارب عمره الإنتاجي الافتراضي.
أما في غير هذه الأوقات فربما يكون تكلفة التحول إلى البرمجيات مفتوحة المصدر كبيرة نوعا ما، لذا عليك مقارنة هذه الحلول البرمجية بالوفورات المالية الموجودة.
تتميز أيضا الشركات البرمجية الكبرى بوجود استعداد جيد للاستجابة على طلبات الحصول على المعلومات أو الإجابة عن أي تساؤل يخص منتجاتها ، بينما عادة لا تتوفر مثل هذه الخدمات مع البرمجيات المفتوحة المصدر مما يؤدي إلى تجاهل لجنة الاختيار إلى الكثير من الحلول البرمجية المفتوحة المصدر أثناء عملية التقييم.
من الناحية التكتيكية ، يمكن لإضافة البرمجيات المفتوحة المصدر في عملية تقييم الشراء فوائد جمة حتى ولو كنت قد ارتأيت أن مثل هذه البرمجيات ليست بالخيار الأمثل. إضافتها لقائمة الاختيار ضمن عملية التقييم المبدئية تضيق الخناق على البرمجيات المغلقة وتوسع باب المنافسة مما يزيد الضغط على البرمجيات المنافسة من تخفيض التكاليف ومراعاة ضرورة زيادة قوة أداء برمجياتها أو على أقل تقدير التفكير في تخصيص مثل هذه البرمجيات حسب الاحتياجات الشخصية للمؤسسة.
ويتعين على المؤسسات تطوير عملية منظمة لتقييم البرمجيات المفتوحة المصدر بصورة عادلة أثناء عملية تقديم طلب الحصول على معلومات/اقتراحات/عروض (RFI/P/Q). ولتحقيق هذا الأمر قد يتطلب من المؤسسات إعادة النظر في السياسات والممارسات المتبعة أثناء عملية الشراء الحالية. تشمل الأهداف الرئيسية التالية:
ضمان حيادية وعدم انحيازية أسئلة كل من معلومات/اقتراحات/عروض (RFI/P/Q) حتى لا تظلم المنتجات مفتوحة المصدر. على سبيل المثال: إمكانية استخدام نفس الأجراء التقييمي لمدى نضج منتج ما مفتوح المصدر كأسئلة لتقييم مدى استقرار شركة برمجية لمنتجات مغلقة.
ضمان أن كل من العطاءات المقدمة سواء من البرمجيات مفتوحة المصدر أو البرمجيات المغلقة تم استلامها على أساس أنها عطاءات وردت ردا على معلومات/اقتراحات/عروض (RFI/P/Q). يمكن للمؤسسة القيام بتعيين مدققين محليين للقيام بتحديد استباقي لحل برمجي مفتوح المصدر وإجراء بعض التقييمات التقنية ردا على أي من معلومات/اقتراحات/عروض (RFI/P/Q).
في حالة تطلب الأمر طلب تقديم دعم خارجي ، على المؤسسة تنظيم العملية بشكل يمكن مقدمي الدعم الفني "طرف ثالث في كثير من الأحيان" للبرمجيات مفتوحة المصدر من الرد على مثل هذه العطاءات.
أما في حالة الاتفاق على توفير دعم محلي داخل المؤسسة نفسها ، ينبغي تحديد قيمة تكاليف هذا الدعم وتدرج ضمن إجراءات المقارنة في عملية الاختيار لضمان إجراء مقارنة عادلة.
تقييم مدى نضج البرمجيات مفتوحة المصدر
من المهم بمكان عند اعتبار البرمجيات المفتوحة المصدر كحلول برمجية بالمؤسسة تقييم مدى نضج مثل هذه المنتجات. ومثل هذه التقييمات يمكن أن تساعد في القيام بالتالي:
تحديد ما إذا كانت موثوقية المنتج وأدائه كافية لتلبية حاجات المؤسسة.
تحديد خيارات الدعم الفني المتوفرة
تحديد مدى استمرارية المنتج في السوق.
الأطر التالية من أكثر الأطر المستخدمة في تقييم مدى نضج المنتج:
كما يمكنك الاطلاع على التالي للحصول على بعض النصائح المفيدة في تقييم المنتجات البرمجية مفتوحة المصدر.
إدارة استخدام البرمجيات المفتوحة بصورة فعالة
في حالة قيام مؤسسة ما باختيار أحد البرمجيات المفتوحة المصدر وتبنيه ، فمن الأهمية بمكان وضع آليات الاستخدام المناسبة والتي من خلالها تسطيع المؤسسة من الاستفادة من إيجابيات ذلك المنتج بالشكل المناسب وتفادي أي سلبية محتملة.
سيناريوهات استخدام البرمجيات مفتوحة المصدر
يمكن استخدام التطبيقات مفتوحة المصدر في كثير من الجوانب المختلفة ضمن مؤسسات التعليم العالي والسيناروهات التالية توضح أمثلة لبعض هذه الاستخدامات:
السيناريو الأول: البحث العلمي
يمكن استخدامها مثلا ضمن مشروع بحثي علمي لتطوير نوع جديد من التطبيقات والتي تحتاج لإدراج بعض الأكواد البرمجية من برنامج مفتوح المصدر موجود فعلا ضمن المشروع الجديد. لذا فعلى أعضاء الهيئة التدريسية التأكد من إمكانية توفير البرمجيات مفتوحة المصدر للمميزات والوظائف ومستوى نضج البرنامج لاحتياجات المؤسسة الخاصة.
وربما لا يكون أعضاء هيئة التدريس على دراية تامة بما يتعلق ببنود تراخيص مثل هذه البرمجيات ، لذا على المؤسسة مراعاة مسألة تقييم هذه البرمجيات بعناية تامة قبل أن يتم دمجها ضمن أعمال برمجية بحثية جديدة مع إمكانية إعادة توزيعها لمستخدمين آخرين خارج الإطار البحثي للبرنامج ومن الأمور المهمة التي يجب وضعها في عين الاعتبار سواء من قبل أعضاء الهيئة التدريسية أو من قبل المؤسسة نفسها الأمور التالية:
هل البحوث ممولة من قبل جهة خارجية؟ إذا كان الأمر كذلك ، هل هناك أي تعارض بين شروط تراخيص هذه البرمجيات والشروط المرتبطة بمثل هذا التمويل؟؟
هل هناك أية نية أو شرط ضمن البرنامج الجديد أن يتم تسويقه بشكل تجاري؟ إذا كان الأمر كذلك ، فهل شروط ترخيص البرنامج تسمح لمثل هذه الأمور لإدراجها ضمن حقوق الملكية الفكرية للمنتج نفسه؟
لذا فالحاجة إلى آليات مؤسسية للتخفيف من مثل هذه القضايا المتعلقة بمثل هذا السيناريو مهم جدا.
السيناريو الثاني: تطبيق برمجي على مستوى المجتمع ـ النية بالمساهمة
عندما تقرر أي من مؤسسات التعليم العالي بأنه لا يوجد أي من التطبيقات البرمجية المغلقة المتوفرة تلبي حاجيات المؤسسة ، لذا من الإمكان أن تتبنى المؤسسة مسألة تطوير وتطبيق حل برمجي يتم تصميمه وتعديله محليا ولكن هناك بعض المخاطر العالية المتعلقة بمثل هكذا توجه. لذا فمن الأمور التي تعتبر حلا لهكذا موقف وأقل خطرا هو أن تصبح المؤسسة عضوا فاعلا ضمن مشروع "Kuali". ولكن وقبل أن تصبح المؤسسة عضو فعال في هذا المشروع ، على المؤسسة أن تقوم بتقييم عادل لمستوى نضج مشروع "Kuali" كحل قابل للتطبيق لتغطية الاحتياجات البرمجية للمؤسسة.
ومن خلال المساهمة في هذا المشروع ، تستطيع المؤسسة مشاركة الجامعات الأخرى الأعباء والمخاطر المتعلقة بمثل هكذا توجه على مستوى أوسع وأشمل. بالإضافة إلى كل ذلك ، تستفيد المؤسسة من استخدام القاعدة البرمجية الموجودة والأكواد البرمجية المطورة من قبل الجامعات الأخرى المشاركة. وكتعهد من المؤسسة نفسها عليها أن تعيين موظفين لتطوير جانب معين من جوانب مشروع Kuali بقصد المساهمة للمجتمع البرمجي المشارك. ينبغي أيضا تحديد الموارد المؤسسية واتاحتها للمراجعة وتنسيق هذه العملية بشكل مستمر.
هناك حاجة فعلية إلى آليات معينة على المستوى المؤسسي للتخفيف من القضايا المتعلقة بمثل هكذا سيناريو عالية وذلك في المقام الأول لأن المؤسسة ستقدم الكثير من حقوق الملكية الفكرية للمجتمع.
السيناريو الثالث: حل على نطاق الحرم الجامعي ـ المساهمة محتملة
تحدد المؤسسة التعليمية الحاجة إلى تطبيق أداة برمجية على مستوى المؤسسة بشكل عام ، لذا تقوم بتطوير RFI/P/Q لتقييم وتحديد أفضل حل لهكذا توجه. لذا ينبغي إعادة النظر في الممارسات الحالية والمتبعة في عملية الشراء وتعديلها للتأكد من أن يتم تقييم الحلول البرمجية المفتوحة المصدر بشكل موضوعي للتأكد من صلاحيات الحلول البرمجية المقترحة وأنها ناضجة بما فيه الكفاية لتلبية حاجات المؤسسة التعليمية.
وبسبب تأثيرات طول مدة تطبيق المشروع وتطبيقه على نطاق واسع نوعا ما ، على المؤسسة أن تقرر وبدقة مسألة مستوى مشاركتها بالمجتمع التطويري للتطبيق سواء من حيث كونها متبني للمشروع فقط أو أنها تريد تقديم مشاركة فاعلة بالمجتمع.
الحاجة الفعلية إلى أليات معينة على المستوى المؤسسي للتخفيف من القضايا المتعلقة بمثل هكذا سيناريو معتدلة إلى عالية.
السيناريو الرابع: حل على مستوى القسم ـ بدون نية للمساهمة
عندما يقرر القسم استخدام منتج برمجي مفتوح المصدر معروف وذو إمكانيات مثل نظام linux كجزء من البنية التحتية لقسم تقنية المعلومات بالمؤسسة. القسم يمكن الإمكانيات اللازمة لتحديد مدى إمكانية البرنامج في توفير الميزات والوظائف ومستوى النضج المطلوب من خلال استخدام بنود تقييم منتجات البرمجيات المفتوحة المصدر المذكورة أعلاه.
كما يمتلك موظفي القسم الخبرة الكافية لخصخصة كود برمجي معين والمساهمة به إلى المجتمع ولكن من المستبعد أن يقوموا بمثل هذا بسبب تبنيهم لنظام لينكس فقط لاستخدامه كحل برمجي لبنية تحتية محددة تحتاج إليها المؤسسة. لذا فليست هناك أية حاجة أو هدف معين من تخصيص منتج برمجي مفتوح المصدر موجود فعليا وأي فائدة مرجوة من هكذا تصور تعود إلى القسم هي قليلة جدا.
الحاجة الفعلية إلى أليات معينة على المستوى المؤسسي للتخفيف من القضايا المتعلقة بمثل هكذا سيناريو منخفضة.
السيناريو الخامس: المستخدم النهائي
يقرر مسؤول القسم بدون استشارة القسم تنزيل تطبيق متصفح الأنترنت فيرفوكس. هذا الفعل من تحميل وتثبيت واستخدام البرنامج يعني بصورة تلقائية موافقة الإدارة على الشروط الواردة ضمن اتفاقية ترخيص استخدام تطبيق فيرفوكس من شركة موزيلا. وحتى لو قام بممارسة البرمجة وإنشاء برمجيات كهواية في وقت الفراغ ، فإن حقيقة أن مسؤولياته الوظيفية ليست ذات صلة بتكنولوجيا المعلومات تجعل الأمر واضحا بأن أي مساهمة محتملة من قبله عبارة عن مساهمة شخصية منه وليست من المؤسسة التي يعمل بها.
ليست هناك أي حاجة لوجود آلية معينة لمراجعة هكذا سيناريو على المستوى المؤسسي.
إرشادات استخدام البرمجيات مفتوحة المصدر
من الأمور المهمة لضمان الاستخدام المناسب لمثل هذه البرمجيات على نطاق المؤسسة تطوير ونشر مبادئ توضيحية وتوجيهية تبين آلية الاستخدام المناسب. وينبغي لهذه المبادئ أن تناقش القضايا المطروحة سابقا مثل:
تقييم مدى نضج المنتج فيما يتعلق بالاحتياجات الفردية لكل مشروع على حده.
اعتبار منتجات البرمجيات المفتوحة المصدر كحلول برمجية مجدية على مستوى واحد جنبا إلى جنب مع منتجات الشركات البرمجية الأخرى لتغطية احتياجات المؤسسة التعليمية.
بالإضافة إلى ذلك ينبغي على هذه الإرشادات التوضيحية أن تغطي كل من:
التأكد من أن كل المساهمات المقدمة لمجتمع البرمجيات المفتوحة المصدر تتوافق مع مصلحة المؤسسة.
تحديد رخص البرمجيات التي لا تتوافق مع توجهات المؤسسة أو تحتوي على شروط غير مقبولة.
كما يجب على المؤسسة أن تشكل لجنة مكونة من صناع القرار بالمؤسسة بما في ذلك الخبراء المتخصصين بكل من مجالات رخص البرمجيات وحقوق الملكية الفكرية وبراءات الاختراع والجوانب القانونية المتعلقة بمثل هذه الأمور من أجل صياغة الإرشادات التوجيهات. وللتأكد من تحقيق أقصى قدر من الفعالية ، يفضل صياغتها صياغة واضحة وسهلة المتابعة مما يجعل الامتثال سهلا قدر الإمكان للمستخدم النهائي.
ينبغي مراجعة النسخة الأولى من هذه الإرشادية من قبل جهات مؤسسية أخرى مثل أعضاء الهيئة التدريسية وصناع القرار بقسم تقنية المعلومات وذو العلاقة بالأمور الإدارية ويتم التعديل على النسخة الأولى بناء على التغذية الراجعة المقدمة. وفي الأخير ينبغي بعد ذلك مراجعة الإرشادات التوجيهية للتأكد من مدى موافقتها لمعايير المؤسسة التعليمية.
المساهمة بمجتمع البرمجيات مفتوحة المصدر
ينبغي على قسم تقنية المعلومات بالمؤسسة شرح هذه المسألة مع التأكيد على أهمية مثل هكذا توجه لما له من فوائد جمة تعود سواء للمجتمع أو للمؤسسة التعليمية. فعلى سبيل المثال ، فمن الأسهل أن تحصل على المساعدة المطلوبة في الوقت المطلوب من أحد أعضاء المجتمع إذا كنت أنت أيضا تقدم مثل هكذا مساعدات ومساهمات. ومن أحد الطرق الرئيسية لرد الجميل لمجتمع البرمجيات المفتوحة المصدر هي المساهمة بتقديم شفرة مصدرية جديدة.
كما يمكن للمساهمة أن يساهم في تقديم الكثير للمؤسسة أكثر من تبيان حسن نيتها لمجتمع البرمجيات المفتوحة المصدر مثل السماح للمؤسسة بالتأثير في توجهات منتج برمجي ما للتأكد من استمرارية تماشيه مع أهداف المؤسسة. كما تعتبر مسألة اختيار تطبيق برمجي مفتوح المصدر استثمارا مهما على المدى الطويل ، وكل جهد تقدمه المؤسسة يساعد على ضمان نجاح التطبيق المستمر وحماية استثمارات المؤسسة التعليمية.
كما أوضح "لويس بروكس" قائلا: "المساهمة الفاعلة بالمجتمع مثل شراء منتج شركة ما ، ولكن بدلا من دفع رسوم الترخيص والصيانة ، يتم استعاضة ذلك ببعض من وقت موظفيك". وفي الغالب عندما يتم تطوير شفرة مصدرية لتطبيق معين يتم تخصيصها لتتناسب مع احتياجات المؤسسة.
وفي كل مرة تقوم المؤسسة بترقية التطبيق إلى نسخة أعلى ، على المؤسسة أن تنفق موارد إضافية لضمان أن التخصيص السابق يعمل على هذه النسخة من التطبيق بعد الترقية. أما في حالة مشاركة المؤسسة لذلك التخصيص ونشره في المجتمع ليتم دمجه ضمن الشفرة المصدرية الأساس ، فسيغني المؤسسة عناء القيام بمثل هذه التخصيصات لأي إصدارات لاحقة من نفس التطبيق.
إدارة عملية المساهمة
هناك العدد من القضايا الحساسة تتعلق بالمساهمة في مشاريع برمجية مفتوحة المصدر ، لذا يجب أن تدار العملية بشكل فعال. فعلى سبيل المثال ليس كل ما تشارك به من أكواد برمجية للمجتمع سيتم الموافقة عليها ودمجها ضمن الشفرة المصدرية الأساس لذا من الضروري القيام بتدقيق لكل الأكواد البرمجية لضمان تلبية الحد الأدنى لاشتراطات الشفرة المصدرية الأساس سواء من ناحية الجودة أو الفائدة المرجوة. وبعد القيام بذلك ، ستكون لدى المؤسسة سمعة جيدة داخل مجتمع البرمجيات المفتوحة المصدر كمساهم أساسي وفعال.
ومن الجوانب الحساسة الأخرى المتعلقة المتعلقة ببراءات الاختراع وحقوق الملكية الفكرية. فعندما تساهم في مشروع برمجي مفتوح المصدر ، فربما يطلب من المساهم الفردي أو المؤسسي التوقيع على اتفاقية ما توضح آلية المساهمة وشروطها وخير مثال مستندات اتفاقية مؤسسة أباتشي للبرمجيات سواء للمساهمات الفردية أو مساهمات الشركات. لذا فمن المهم أن تقوم المؤسسة بالتدقيق على بنود مثل هذه الاتفاقيات للتأكد من أن الشروط مقبولة لدى المؤسسة وغير مجحفة.
ولضمان الامتثال لاتفاقيات المساهمين وضمان الموافقة على المساهمات الملائمة فقط ، على المؤسسة أن تنشئ إرشادات توضيحية توضح الظروف التي يمكن من خلالها تتطلب استقبال مساهمات برمجية والتي تحدد كل النقاط التالي:
الجهة التي تقوم بتقديم المساهمات (الموظفين/أعضاء هيئة التدريس/ استشاريين). حيث قد تختلف القوانين والسياسات من مساهم إلى مساهم آخر.
سياسات الملكية الفكرية الداخلية للمؤسسة وكيف تتعامل مع مثل هذه المساهمات.
ضمان أن المساهمة المقدمة قد تم إنشاءها بالكامل من قبل المؤسسة أو ممثليها ولا تحتوي على حقوق ملكية فكرية لأي طرف آخر.
ضمان أن الشفرة المصدرية المقدمة لا تحتوي على أي أكواد برمجية سابقة تتعارض مع شروط الرخصة المستخدمة ومن أشكال الأكواد البرمجية المحتمل وقوعها تحت هذه الإشكالية تلك التي تمت برمجتها من قبل جهات خارجية.
التأكد عن مدى إمكانية مطالبة المؤسسة بحقوق الملكية الفكرية للشفرة المصدرية المقدمة في حالة رغبة المؤسسة الاحتفاظ بمثل هكذا حقوق.
مدى جدوى الاحتفاظ بحقوق الملكية الفكرية خاصة للمؤسسة بالنسبة إلى القيمة التجارية المحتملة للعمل الجديد والذي قد يتطلب تحديا وجهدا إضافيا بالإضافة إلى استغراقه لوقت طويل.
وللحصول على مثل هذه المعلومات بشكل بسيط نسبيا هي التواصل مع الشخص الذي أنشأ المشروع في بداية الأمر ويمكن استخدام الاستمارة التالية والتي صممت من قبل جامعة كاليفورنيا.
الكلمة النهائية..
تمثل البرامج والتطبيقات أساس البنية التحتية لقسم تقنية المعلومات بالمؤسسة وتمثل عملية شراء وصيانة برامج الكمبيوتر ما يقارب من ٢٠٪ من ميزانية قسم تقنية المعلومات. لذا أصبحت هذه المؤسسات غير قادرة على تحمل مثل هذه التكاليف بسبب حصر خياراتها على استخدام الحلول البرمجية الاحتكارية التقليدية. لذا يمكن للبرمجيات المفتوحة المصدر أن تقدم للمؤسسة بدائل برمجية أكثر فعالية وأقل تكلفة بشرط أن تتم إدارتها بصورة ملائمة.