مع زخم عام ٢٠١١، قمت برفقة نيكول سوليفان باستحداث أداة CSS Lint والتي كانت عبارة عن أول أداة لـCSS تعنى بجودة الكود البرمجي. لقد قضينا الأسبوعين السابقين في البرمجة مثل المجانين في محاولة منا من كتابة تطبيق يكون بالدرجة الأولى مفيدا للمستخدم النهائي وفي نفس الوقت يكون سهل التعديل والتغيير(مفتوح المصدر). الجميل في الأمر بأنه لم يكن لأي منا أي تجربة في إطلاق مشروع مفتوح المصدر (open-source) مثل هذا من قبل ، مما ساعدنا في تعلم الكثير من خلال هذه التجربة.
مصدر الصورة: opensourceway.
في البداية تعرقلنا ببعض الثغرات الأولية ، ولكن نستطيع القول أن المشروع أخيرا حقق النجاح المنشود ، وأصبحنا نتلقى العديد من رسائل الاطراء من مستخدمي الأداة والمشاركة في المساهمة في تطويرها. في الواقع ، ليس من الصعوبة بمكان أن تنشىء مشروع مفتوح المصدر ناجح عندما تنظر إلى أهدافك بصورة جدية..
ما هي أهدافك؟
من الأمور الشائعة في هذه الأيام ، أن أي شخص يكتب جزء من كود برمجي ، ينتهي به المطاف إلى رفعه على سيوفر GitHub تحت أحد الرخص المفتوحة المصدر ويتشدق فيما بعد: "لقد قدمت كودا مفتوح المصدر". في الواقع ، إنشاء مشروعا مفتوح المصدر لا يقتصر فقط على اصدار برنامجك تحت رخصة تتيح للأخرين أستخدام برنامجك بكل حرية وإنما الأمر أكبر من ذلك بكثير. لذلك وقبل أن تعلن للعالم أنك قد قدمت لهم برنامجا مفتوحا المصدر ولم يتم تجربته بعد من قبل أي شخص آخر غيرك في أوقات فراغك. هنا عليك التوقف قليلا وسؤال نفسك عن حقيقة أهدافك من مثل هكذا مشروع..
بداية ، يجب أن يكون الهدف الأول دائما: تقديم شيء مفيد. أما بالنسبة لأداة CSS Lint، فكان هدفنا الأساس هو توفير أداة أضافية لCSS code quality والتي من الممكن أن تندرج بكل سهولة في سير عمل مطوري البرنامج ، سواء أكان سير العمل يعمل بشكل تلقائي أما لا. ويمكنك التأكد من أهمية ما تقدمه من خلال عدة أمور كالنظر إلى مبرمجين آخرين يعملون على مشاريع مماثلة وكذلك التعرف على عدد المستخدمين النهائيين الذين تستهدفهم لاستخدام أداتك.
بعد ذلك ، عليك أن تحدد السبب الرئيس من تقديم أداة مفتوحة المصدر في المقام الأول؟ هل هو لأنك تريد فقط أن تشارك الآخرين بما قمت به؟ هل تنوي مواصلة تطوير الكود البرمجي ، أم أن الأمر يقتصر على ما تم تقديمه وسستوقف عند ذلك؟ لذا فإذا كنت لا تملك أية نية لمواصلة العمل على كودك البرمجي ، فأعلم أن بقية المقالة لا تنطبق عليك ولن تقدم لك شيئا. تأكد من أن ملف "أقرأني.." ضمن مستودعات البرنامج ينص وبكل وضوح على ذلك حتى يكون جليا لكل من يتعامل مع برنامجك منذ البداية.
أما إذا كانت لديك النية في مواصلة تطوير كودك البرمجي ، فهل ستقبل مساهمات الآخرين أو أضافاتهم البرمجية في برنامجك؟؟ إذا كانت أجابتك بلا ، فمرة أخرى هذه المقالة لا تنطبق عليك. أما إذا كان جوابك بنعم ، فسيتحتم عليك بالقيام بعمل إضافي، فإنشاء مشروع مفتوح المصدر يقبل مساهمات الآخرين يتطلب جهدا أكبر مما يبدو عليه. فعليك إنشاء بيئة مناسبة حتى يستطيع كل من لم يعتد على مشروعك على التأقلم على طبيعة البرنامج في وقت قصير ليكونوا منتجين بصورة سريعة نسبيا ، وكل هذه الأمور تحتاج بعض التخطيط المسبق. ل
لذا هذه المقالة على وشك البدء بمشروع مفتوح المصدر تتضمن الأهداف التالية:
تقديم شيئا مفيدا للعالم.
الاستمرار في تطوير البرنامج في المستقبل القريب.
قبول اسهامات المبرمجين الآخرين.
اختيار رخصة البرنامج..
قبل التفكير في مشاركة الكود البرمجي مع الآخرين ، عليك اختيار رخصة مناسبة للتطبيق ، حيث يمكن لهذا القرار أن يساعدك كثيرا أو يضرك في جذب اهتمام المبرمجين للمساهمة في البرنامج. كافة التراخيص تسمح لك بالابقاء على حق المؤلف في ما أنتجه من أكواد برمجية. في حين يعتبر مفهوم تراخيص البرامج من الأمور المعقدة جدا ، إلا أن هناك عدد من التراخيص والأمور الأساسية التي عليك الالمام بها. (ملاحظة: إن كنت بصدد أختيار رخصة برنامج نيابة عن شركة ما ، فعليك التحدث إلى مستشار الشركة القانوني قبل اتخاذ أي قرار بهذا الصدد).
تم إنشاء رخصة جنو العامة مبدئيا لمشروع GNU وكان لها الفضل في صعود نظام لينكس كنظام تشغيلي قادر على المنافسة. تشترط رخصة GPL بأن يصدر أي مشروع تم إنشائه باستخدام برنامج تحت رخصة GPL أن يكون تحت رخصة GPL كذلك. ولتوضيح هذه الجزئية ببساطة ، فإن أي مشروع يستخدم كود برمجي تحت رخصة GPL بأي شكل من الأشكال عليه أيضا أن يكون مفتوح المصدر تحت الرخصة GPL نفسها. ليست هناك أية قيود على استخدام التطبيقات الصادرة تحت ترخيص GPL العامة ، بينما التقييد فقط على القيام بتعديلات على هذه التطبيقات وطريقة توزيع التطبيقات المنبثقة وترخيصها.
تعتبر هذه الرخصة نسخة مصغرة عن نسخة GPL وهي أكثر تساهلا منها. حيث يمكن لأي تطبيق صادر تحت هذه النسخة من ربطه بأي تطبيق آخر دون اشتراط أن يكون مفتوح المصدر تحت رخصة GPL أو حتى LGPL نفسها. في ماعدا ذلك فإن رخصة LGPL هي نفسها GPL ، لذا فإن أي أعمال مشتقة يجب أيضا أن تكون مفتوحة المصدر تحت رخصة GPL أو LGPL.
تعتبر هذه الرخصة (أطلق عليها X11) من الرخص المتساهلة لأبعد الحدود حيث تسمح هذه الرخصة من استخدام وإعادة توزيع أي كود برمجي طالما يتضمن التطبيق على الرخصة وحقوق النشر جنبا على جنب. كما يمكن إضافة أي كود تحت هذه الرخصة ضمن تطبيق مغلق دون أية قيود إضافية. بالإضافة إلى ذلك ، فإن رخصة MIT متوافقة مع رخصة GPL ويمكن دمجها بأي كود برمجي صادر تحت هذه الرخصة لإصدار تطبيقات جديدة ضمن رخصة GPL.
تعتبر هذه الرخصة كذلك من الرخص المتساهلة التي تسمح لاستخدام واعادة توزيع الكود البرمجي طالما يتضمن على حقوق النشر بجانب الرخصة. وبالإضافة إلى ذلك ، فإن أي توزيع للكود في شكل ثنائي فلابد أن يشمل على الترخيص وحقوق النشر في ملفات التوثيق الخاصة. الجزئية التي تنفرد بها هذه الرخصة عن رخصة MIT هو حظر استخدام اسم صاحب حقوق النشر من الترويج لأي منتج يستخدم الكود البرمجي تحت هذه الرخصة. فعلى سبيل المثال ، إذا كتبت بعض الأكواد البرمجية تحت رخصة BSD3 ، ثم التطبيق الذي استخدم هذا الكود لا يمكنه من استخدام اسمي في الترويج عن تطبيقه دون إذن مسبق مني شخصيا. تعتبر هذه الرخصة أيضا من الرخص المتوافقة مع GPL.
هناك العديد من الرخص الأخرى المستخدمة في التطبيقات المفتوحة المصدر ، ولكن يعتبر مما ذكر سابقا من الرخص الأكثر شيوعا.
مصدر الصورة: opensourceway.
هناك أمرا واحدا علينا أن نأخذه بعين الإعتبار وهو أن رخص الابداع العامة (Creative Commons) لم تصمم ليتم استخدامها في ترخيص التطبيقات. حيث تهدف كل هذه الرخص لأي عمل يندرج ضمن قائمة "العمل الإبداعي" بما في ذلك الصوت والفيديو والصور والنصوص. حيث توصي منظمة العمل الإبداعي نفسها من عدم استخدام هذه التراخيص لترخيص البرامج أو الأكواد البرمجية وبدلا من ذلك يستحسن استخدام التراخيص التي صيغت خصيصا للتطبيقات البرمجية ، كما هو الحال في الخيارات الأربعة التي نوقشت أعلاه.
لذا السؤال الأن أي من الرخص السابقة ستختار؟؟ في الحقيقة ، كل ذلك يعتمد وإلى حد كبير على الهيئة التي من خلالها تنوي استخدام تطبيقك. ولأن كل من رخصة LGPL و MIT و BSD3 متطابقة مع رخصة GPL ، فلن يكون هذا الأمر مصدر قلق بالنسبة لك. ولكن في حالة رغبتك في استخدام نسخة معدلة من التطبيق كتطبيق مفتوح المصدر فقط فإن رخصة GPL هي المناسبة بلا أدنى شك. أما إن كان تطبيقك مصمم ليعمل كمنصة مستقلة يمكن ادراجه ضمن تطبيقات أخرى دون أي تعديلات ، فربما عليك اختيار LGPL. أما فيما عدا ذلك ، فإن كل من MIT و BSD3 هي الخيارات الأكثر شيوعا. المبرمجين الأفراد يفضلون استخدام MIT ، بينما تميل المؤسسات إلى استخدام رخصة BSD3 لضمان عدم استخدام اسم الشركة أو المؤسسة من دون إذن مسبق بأي حال من الأحوال.
ولمساعدتك في اتخاذ القرار المناسب لك ، انظر إلى تراخيص بعض البرامج المفتوحة المصدرالمعروفة:
jQuery : رخصة MIT
YUI : رخصة BSD3
Dojo Toolkit: ثنائي الترخيص بموجب رخصة BSD3 والرخصة الأكاديمية الحرة.
Backbone : رخصة MIT
من الخيارات الأخرى المتاحة لترخيص البرامج ، ترخيص برنامجك ضمن رخصة المجال المشاع حيث يمكن استخدام التطبيق الصادر بموجب هذا الترخيص بأي شكل من الأشكال دون قيود. لذا في حالة عدم رغبتك في السيطرة على طريقة استخدام تطبيقك أو كانت لديك الرغبة في مشاركة العالم بالتطبيق دون أية نية في تطوريه ، عليك التفكير في اصداره بمجوب هذه الرخصة.
وللإطلاع على المزيد عن التراخيص والقضايا القانونية المرتبطة بها والطريقة التي تعمل من خلالها هذه الرخص باختلاف أنواعها ، عليك الاطلاع على كتاب ديفيد بوشل في كتابه: " Understanding Copyright and Licenses ".
تنسيق الكود البرمجي
بعد الانتهاء من هذه الخطوة ، حان الوقت لنشر تطبيقك للمستخدمين والمبرمجين الاخرين. ولكن وقبل أن تخطوا هذه الخطوة عليك النظر في طريقة تنظيم الكود البرمجي ، حيث ليس كل الأكواد البرمجية مشجعة لمساهمات المبرمجين الآخرين. فعلى سبيل المثال ، إذا لم يستطع مبرمج ما من قرآءة كودك البرمجي ، فإنه من المستبعد جدا أن يساهم فيه تطوريه أو الاضافة إليه. فالطريقة التي ترتب بها تطبيقك البرمجي من حيث بنية الملفات والمجلدات وأسلوب البرمجة من الأمور الرئيسة في الاعتبار قبل نشر التطبيق ومشاركته بين المستخدمين. لا ترمي كودك البرمجي بأي شكل تمت كتابته إلى العالم الافتراضي هكذا وانما عليك قضاء بعض الوقت في تخيل نظرة الاخرين للتطبيق والأسئلة الممكنة أن تخطر على بالهم.
أما بالنسبة إلى تطبيق CSS Lint فقد قررنا الاعتماد على بنية دليل عالية المستوى من src للشفرة المصدرية و lib للمصادر الخارجية و tests لكل الأكواد التجريبية. تم تقسيم مجلد src إلى عدة مجلدات فرعية التي تضم الملفات المماثلة حيث ضمنت جميع قواعد التطبيق تحت المجلد الفرعي rules ومنسقات الاخراج تحت مجلد formatters وهكذا دواليك. مجلد tests كذاك فقد تم تقسيمه في شكل مماثل للمجلدات الفرعية في مجلد src مما يشير إلى العلاقة بين الأكواد التجريبية والشفرة المصدرية. مع مرور الوقت ، نضيف المجلدات الفرعية حسب الحاجة مع التأكد من اتباع نفس الأسلوب بالهيكل الأساسي المتبع منذ البداية.
التوثيق
واحدة من أكبر الشكاوى حول مشاريع المصادر المفتوحة افتقارها على التوثيق الجيد. كتابة شروحات التطبيقات ليست من المتعة أو الإثارة كما هي في كتابة الأكواد البرمجية ولكن وجودها من الأهمية بمكان لضمان نجاح أي مشروع مفتوح المصدر. ومن أفضل الوسائل للحد من استخدام البرنامج واستقطاب مساهمات المبرمجين الأخرين هو كتابته دون أية وثائق شارحة بطريقة عمله. وهذا كان من الأخطاء الأولية التي وقعنا فيها أثناء برمجتنا لتطبيق CSS Lint. حيث أطلقنا البرنامج لأول مرة دون أية وثائق مصاحبة والجميع يتسائل عن طريقة استخدامه. لذا لا تقع في الخطأ نفسه ، وقم بتجهيز الوثائق قبل نشر التطبيق للمستخدم النهائي.
ومع هذا كله على الوثائق أن تكون سهلة التحديث ولا تتطلب تغيير في الكود البرمجي لأنها سوف تحتاج إلى التغيير المستمر بناء على ملاحظات المستخدمين النهائيين. وهذا يعني أن أفضل مكان للتوثيق ليس في نفس مستودع الكود البرمجي. فعلى سبيل المثال ، إذا كنت قد استضفت التطبيق على GitHub ، فتأكد من ادراج ويكي مدمج لكل مشروع. كل الوثائق المتعلقة بتطبيق CSS Lint ضمن ويكي GitHub. أما إذا تمت استضافة تطبيقك على مكان آخر ، فعليك النظر في انشاء ويكي خاص بك أو أي نظام مماثل يمكنك من تحديث وثائق التطبيق في وقت قياسي. على نظام التوثيق الجيد أن يكون سهل التحديث وإلا فلن تشغل بالك بتحديثه.
وثائق المستخدم النهائي
سواء أكنت تقوم بإنشاء برنامج سطر الأوامر ، أو تطبيق ما أو أداة لمكتبة أو أي شي آخر ، عليك الأخذ بنظرة المستخدم النهائي في الاعتبار. المستخدم النهائي ليس هو الشخص الذي سيقوم بتعديل الكود البرمجي وانما سيكون الشخص الذي سيستخدم هذا الكود. في البداية كان المستخدمين مشوشين من غرض تطبيق CSS Lint وطريقة استخدامه بشكل فعال لعدم توفر الوثائق. لا يمكن لمشروعك أن يكسب ثقة المبرمجين الآخرين قبل الحصول على ثقة المستخدمين النهائيين حيث المستخدمين النهائيين الراضيين عن التطبيق هم الذين سيصبحون في نهاية المطاف المساهمين في الشفرة المصدرية لأنهم لمسوا قيمة ما قمت بإنشائه.
دليل المطور
حتى وإن قمت بوضع الشفرة المصدرية على أحسن شكل مع وثائق للمستخدم النهائي فلا يضمن ذلك حصولك على مساهمات من مبرمجين آخرين. وإنما عليك بتوفير دليل المبرمج للمساعدة في الحصول على مساهمين آخرين مستعدين للمساهمة في تطوير الشفرة المصدرية الأساسية. وعلى دليل المبرمج الجيد أن يغطي ما يلي:
طريقة الحصول على الشفرة المصدرية
ربما تتمنى أن يكون المساهمين على دراية كافية من طريقة الوصول إلى مستودعات الشفرة المصدرية ونسخها ولكن لا يكون الحال هكذا دائما. لذا من المستحسن اضافة مقدمة لطيفة تشرح طريقة الحصول على الشفرة المصدرية للبرنامج.
طريقة تنضيد وترتيب الشفرة المصدرية
على الرغم من أن طريقة ترتيب المجلدات شارحة لنفسها ولا تحتاج لأي شرح ، إلا أن كتابة وصف لمستودعات وأجزاء التطبيق يساعد المبرمجين ويسهل المهمة.
طريقة اعداد نظام البناء
إذا كنت تستخدم نظام لبناء التطبيق ، فسوف تحتاج إلى إدراج الارشادات اللازمة لطريقة عمل ذلك. يجب أن تتضمن هذه التعليمات على مكان الحصول على المستوداعات الخارجية المطلوبة لتشغيل التطبيق والغير مضمنة ضمن التطبيق نفسه.
طريقة تشغيل نظام البناء
هنا عليك شرح الخطوات الرئيسة لتشغيل البنية التطويرية وتشغيل وحدات الاختبار.
طريقة المساهمة في التطبيق
هنا عليك تحديد المعايير الأساسية لطريقة المساهمة في المشروع. فإذا كنت تحتاج إلى وحدات اختبار أذكر ذلك ، أما إذا كنت بحاجة إلى وثائق للتطبيق فإذكر ذلك أيضا. من الأفضل اعداد قائمة بمتطلبات المساهمة يستطيع المساهمين الاطلاع عليها قبل تقديم أي مساهمة واختيار المجال الملائم لهم.
قضيت الكثير من الوقت في صقل تطبيق "دليل المطورين لتطبيق CSS Lint" بناء على المحادثات المطولة التي أجريتها مع المساهمين والأسئلة التي طرحت علي من الكثيرين.وكما هو الحال مع جميع الوثائق ، يجب أن يكون دليل المطور وثيقة حية تنمو بصورة متزامنة مع نمو المشروع.
استخدام قائمة بريدية
كل مشاريع المصادر المفتوحة الجيدة توفر مكانا مناسبا لطرح الأسئلة وأسهل طريقة لتحقيق ذلك هي من خلال انشاء قائمة بريدية. وعندما أطلقنا برنامج CSS Lint لأول مرة استقبلنا أنا ونيكول الكثير من الأسئلة والمشكلة أن هذه الأسئلة كانت تأتي عبر قنوات مختلفة فهناك من يسألنا عبر تويتر وهناك من يراسلنا عبر البريد الألكتروني وهكذا.. وهذا بالضبط أحد المواقف التي لا تريد أن تورط نفسك بها.
يمكنك انشاء قائمة بريدية من خلال مجموعات ياهو أو مجموعات جوجل وهي سهلة ومجانية. وتأكد من وجود هذه القائمة قبل اطلاقك لمشروعك البرمجي مع تشجيع المستخدمين على استخدام هذه القائمة البريدية لطرح الأسئلة والاستفسارات. كذلك تأكد من أظهار القائمة البريدية في مكان بارز على موقعك (إذا كنت تملك واحدا) أو في ملفات التوثيق.
مراقبة القائمة البريدية المستمرة من الأمور المهمة في إدارة القائمة البريدية فليس هناك ما هو أكثر أحباطا للمستخدمين النهائيين والمبرمجين المساهمين من أن يتم تجاهلهم وتجاهل استفساراتهم. فإذا قمت باعداد قائمة بريدية فتأكد من صرف بعض الوقت في متابعتها والرد على أسئلة المستخدمين. فهذه من أفضل الطرق لانشاء مجتمع من المساهمين يساهمون في تطوير تطبيقك. يحتاج الحصول على مساهمات محترمة في القائمة البريدية على بعض الوقت ولكنه يستحق كل هذا الجهد المبذول بلا أدنى شك. عليك هنا تقديم المشورة المناسبة لمن أراد المساهمة في مشروعك ، واقترح للمستخدمين في كتابة tickets عند الحاجة (لا تدع القائمة البريدية تتحول إلى أداة تتبع العلل البرمجية) واستخدم كل ما يطرح في القائمة البريدية من معلومات في تحديث البرنامج وتحسين مستندات التوثيق.
مصدر الصورة: opensourceway.
استخدام أرقام الاصدارات
من الأخطاء الشائعة في البرامج المفتوحة المصدر هو تجاهل استخدام أرقام أصدار لكل نسخة من البرنامج وهي من الأمور المهمة للغاية لضمان استقرار طويل الأمد لتطبيقك وصيانة دورية للمشروع. لم يستخدم تطبيق CSS Lint هذه الخاصية في الأصداره الأولى ولكن سرعان ما تداركنا الخطأ بسرعة. فعند استلامنا لتقارير الأخطاء البرمجية لم يكن عندي أي فكرة إن كان المستخدمين يستخدمون الاصدارة الأخيرة لعدم وجود طريقة لمعرفة النسخة التي يستخدموها. وهناك الكثير من العلل التي تصلني تقارير بشأنها سبق وأن أصلحتها ولكن لم تكن خطأ المستخدم النهائي لعدم معرفته بذلك.
ختم كل اصدارة من البرنامج برقم اصدارة يسهل الأمور بشكل كبير. لذا عندما يرسل شخص تقريرا عن علة ما فيمكنك من سؤاله عن الاصدارة التي يستخدمها والتحقق ما إذا كان قد سبق وأن تم اصلاح تلك العلة. وهذا قلل لي الكثير أنا شخصيا من الوقت في مراجعة تقارير العلل لاني قادر على معرفة ما إذا كان المستخدم يستخدم أحدث اصدار من التطبيق أم لا.
اذا لم يسبق وأن تم استخدام التطبيق من قبل فمن الأفضل البدء برقم الاصدار 0.1.0 وبعدها ترتفع تدريجيا مع كل اصدارة جديدة. مع برنامج CSS Lint قمنا بزيادة الرقم الثاني في ترقيم الاصدارات ، فعلى سبيل المثال كانت النسخة الثانية من التطبيق تحمل الرقم0.2.0 والنسخة التي تلتها رقم 0.3.0 وهكذا دواليك. أما اذا أردنا اصدار نسخة بين النسخ الأساسية بسبب اصلاح بعض العلل على سبيل المثال فإننا نقوم بزيادة الرقم الثالث. لذا أذا كانت النسخة الثانية المخطط لها ستحمل رقم 0.2.0 فإن النسخة التي ستسبقها والتي لم تكن ضمن خطة البرنامج ستحمل رقم 0.2.2.
لا تفهموني بالخطأ: فلا توجد قواعد محددة في تحديد أرقام اصدارات برامجك ولكن هناك بعض المصادر التي تستحق الاطلاع عليها: قم باختيار طريقة واحدة واثبت عليها مع كل اصدارة جديدة من برنامجك Apache APR Versioning و Semantic Versioning .
بالاضافة إلى سهولة تتبع اصدارات البرنامج ، تقدم هذه الميزة العديد من الأمور المفيدة للمشروع الخاص بك.
وسم الاصدارات في الشفرة المصدرية
اذا اتخذت قرار باصدار نسخة جديدة من التطبيق ، عليك استخدام وسم مدير التحكم بالشفرة لتوضيح نسخة الكود المصدري لتلك الاصدارة. بدأت بتفعيل هذه الخاصية في تطبيق CSS Lint بمجرد أن بدأنا باستخدام ارقام الاصدارات في تعريف كل نسخة. في بداية الأمر لم أفكر في هذه النقطة في بداية الأمر حتى استلمت أحد تقارير العلل والتي توضح هذه النقطة. تبين لي فيما بعد أن المطورين الأخرين يرغبون في التحقق من اصدارات معينة من الشفرة المصدرية.
لذا قم بالحاق هذه العلامة برقم الاصدارة من خلال ادراج رقم تلك الاصدارة في حقل الوسم tag مباشرة. علامات تطبيق CSS Lint هي على شكل “v0.9.9.” مما سيسهل لكل من يبحث عن دلالة هذه العلامة وبما فيهم أنت لأنك ستكون قادرا على الحفاظ على التغييرات التي قمت بإجراءها مع كل اصدارة جديدة للتطبيق.
سجل متابعة التغييرات
من الفوائد الأخرى لترقيم الاصدارات هي كتابة سجلات التغييرات مع كل اصدارة جديدة لأهميتها في توضيح التحسينات والتغييرات التي تطرأ مع كل اصدارة جديدة من التطبيق سواء للمستخدمين النهائيين أو للمساهمين. ومن الفوائد الاضافية لعلامات الاصدارات والتحكم بالمصدر هو امكانية كتابة سجلات التغييرات المصاحبة لكل اصدارة بصورة تلقائية بناء على هذه العلامات. فعلى سبيل المثال ، لبرنامج CSS Lint نظام تلقائي بإنشاء سجل التغييرات لكل اصدارة جديدة من البرنامج والتي لا تحتوي فقط على رسالة المجتمع وانما على مساهمات المبرمجين الأخرين. ومن خلال هذه الطريقة ، سيصبح سجل متابعة التغييرات سجلا ليس فقط للتغييرات البرمجية ولكن أيضا لجميع المساهمات الأخرى.
مدى توافر الاعلانات
عليك بالاعلان عن توافر نسخة جديدة من كل اصدارة لبرنامجك في مكان ما. سواء أكنت تقوم بذلك على مدونتك أو على القائمة البريدية (أو في المكانيين معا). حيث يعتبر هذا الاعلان من الأمور المهمة لنجاح تطبيقك. وينبغي أن يتضمن هذا الاعلان عن أي تغييرات جذرية في الشفرة المصدرية بالاضافة إلى أسماء الأشخاص الذين قاموا بمثل هذه المساهمات في التطبيق. حيث يميل المساهمين إلى بذل المزيد من الجهد في حالة حصولهم على بعض التقدير لما قاموا به ، لذا عليك مكافأة الناس الذين بذلوا بعض الوقت للمساهمة في المشروع عن طريق الاعتراف بمساهماتهم.
ادارة المساهمات والمساعدات
وبعد الانتهاء من اعداد كل شيء ، عليك تحديد الآلية التي ستتم من خلالها استقبال المساهمات. وكل ذلك راجع إليك ، حيث يمكنك من اتباع نموذج رسمي أو غير رسمي ، وكل هذا يتوقف على أهدافك. بالنسبة للمشاريع الشخصية فربما لن يكون لك أي نموذج رسمي لذلك وعلى دليل المطور أن يبين الأمور الرئيسة التي تتوقف عليها قبول أي مساهمة ودمجها بالشفرة المصدرية أو بمستودعات التطبيق وكلما اتبع المساهمين هذه الشروط سيتم قبول مساهماتهم. أما بالنسبة للمشاريع الكبيرة ، فمن الافضل أن تكون لديك سياسة أكثر رسمية لقبول المساهمات.
ومن الأمور الأولية التي عليك أن تضعها بالحسبان هي مسألة حاجتك على اتفاقية ترخيص مساهم (CLA). حيث تستخدم هذه التراخيص بكثرة في مشاريع المفتوحة المصدر لحماية الحقوق القانوينة للمشروع. فعلى كل شخص يساهم في المشروع عليه أن يمليء استمارة CLA ويمثل ذلك اعترافا منه بأن أي شفرة مصدرية استخدمها هي عمل غير مقتبس من مكان آخر وأن حقوق ذلك العمل قد انتقل بصورة تلقائية للمشروع. تمنح هذه الاتفاقيات أيضا الحق لصاحب المشروع في استخدام هذه المساهمة كجزء من البرنامج وتصريح من المساهم بعدم وجود أي شفرة مصدرية لشخص آخر يمكن أن يطالبه فيما بعد بحق التأليف أو براءة الاختراع أو أي حق آخر تطال تلك المساهمة. كل من برنامج jQuery وYUI و Dojo يتطلب التوقيع على مثل هذه الاستمارة للمساهمة في المشروع. لذا في حالة التفكير في تطبيق هذا الأمر عليك الحصول على المشورة القانونية بشأن ذلك والترخيص المناسب لك.
من الأمور الأخرى في هذا المجال هو انشاء تسلسل هرمي للعاملين في المشروع وفي العادة تكون المسميات الأساسية للمساهمين في مشاريع المصار المفتوحة على ثلاثة أنواع:
المساهم
كل من يشارك بشفرة مصدرية للمستودع الاساسي للتطبيق يعتبر مساهم في المشروع. ولا يملك المساهم الصلاحية للوصول إلى مستودعات التطبيق بصورة مباشرة ولكنه قام بتزويد المشروع باضافات أو تصحيحات وقد تم قبولها واضافتها للشفرة الأساسية.
المتعهد
هم كل من يملك الامكانية للوصل إلى مستودعات التطبيق. حيث يعملوا على اضافة الميزات الجديدة للتطبيق واصلاح العلل بشكل منتظم. والتي تضاف إلى الشفرة الأساسية بشكل مباشر.
المراجع
يتربع المراجع على أعلى سلم المساهمين حيث يعتبروا القادة الذين يملكون التأثير المباشر على المشروع. سبب حصول المراجعين على لقبهم هذا بسبب ما يقومون به من أشراف ومراجعات على مساهمات المساهمين الأخرين وقراراتهم بالموافقة أو الرفض على أي مساهمة أو أصلاح علة. كما يقومون بترقية مساهم أو تخفيض رتبته كل حسب ما يساهم به. بصورة أو بأخرى يعتبر هذا النوع من المساهمين من يقومون بإدارة المشروع بشكل كلي.
لذا في حالة عزمك في تطبيق تسلسل هرمي مماثل عليك صياغة وثيقة تصف دور كل نوع من أنواع المساهمين وكيف يمكن لكل شخص أن يترقى إلى مستوى أعلى ضمن التسلسل الهرمي. أنشأ YUI نموذج رسمي " Contributor Model " بالاضافة إلى توثيق ممتاز للأدوار والمسؤؤليات المناطة لكل نوع.
في هذه المرحلة من المشروع فإن تطبيق CSS Lint لا يتطلب وثيقة ترخيص مساهم CLAولا يملك نموذج رسمي قيد التطبيق ومع ذلك على الجميع أن ينظر للمشروع باعتباره مشروعا مفتوح المصدر عاما للجميع والمساهمة في نموه.
الدليل
استغرق بنا الأمر ما يقارب على ستة أشهر من الأصدار الأول للوصول ببرنامج CSS Lint إلى حد كونه مشروعا مفتوحا المصدر بشكل كامل. ومنذ ذلك الحين ، قدمت ما يقارب من أكثر من اثني عشر مساهمة وتم تضمينها في المشروع. وفي حين أن هذا الرقم لا يعتبر كبيرا مقارنة مع مستوى المشاريع المفتوحة المصدر الكبيرة ولكننا نفتخر بتحقيق ذلك. في الحقيقة الحصول على مساهمة خارجية واحدة أمرا غير صعب ولكن الحصول على مساهمات على مدى فترة طويلة من الزمن أمرا أصعب بكثير.
وكنا على علم أننا على الطريق الصحيح من خلال الملاحظات وردود الأفعال التي نتلقاها بصورة مستمرة. فعلى سبيل المثال ، قام جونثان كلاين في الأونة الأخيرة باستخدام القائمة البريدية لطرح بعض الأسئلة وانتهى به الأمر بتقديم طلب تم قبوله في المشروع. وبعدها ارسل لي التقييم التالي عبر البريد الالكتروني:
"أردت فقط أن أقول بأنني أرى أن CSS Lint يمثل أحد المشاريع النموذجي للمشاريع المفتوحة المصدر لوثائقه التفصيلية وسهولة تطويره وشفرته المصدرية النظيفة والردود السريعة على القائمة البريدية وطلبات السحب. بالاضافة إلى امكانية تخصيصه بكل سهولة ليتناسب مع أي بيئة. وكانت سهولة تطوير CSS Lintكسهولة قرآءة بعض صفحات الويكي وفي الحقيقة فإن دعوتك الصريحة إلى المساهمة في المشروع قللت من الحاجز بين المشروع والمساهمين إلى أدنى مستوى. كما أتمنى من بقية المشاريع المفتوحة المصدر أن تحذو حذو هذا المشروع وتجعل من مسألة المساهمة في المشاريع المفتوحة أمرا سهلا للغاية."
أصبح الحصول على مثل هذه الأيميلات أمرا شائعا لبرنامج CSS Lint ويمكن أن يصبح أمرا مماثلا لمشروعك أنت إذا قضيت بعض الوقت في اعداد بيئة مناسبة لبرنامجك. جميعنا نريد أن تنجح مشاريعنا ونريد كذلك من المبرمجين الآخرين المساهمة في المشروع. لذا وكما قال جونثان في رسالته: اجعل حاجز المشاركة عند أدنى مستوى وسيجد المبرمجين طريقة أو أخرى للمساهمة في مساعدتك.
التعريف بالكاتب:
نيكولاس سي. زاكاس.
نيكولاس سي زاكاس تقني على شبكة الانترنت ، استشاري ، مؤلف ومحاضر. عمل لدى شركة ياهو لما يقارب من خمس سنوات حيث كان أحد المبرمجين المميزين لموقع ياهو ومكتبة YUI. بالاضافة إلى ذلك كان مؤلف لعدة كتب منها: Maintainable JavaScript (O’Reilly, 2012), Professional JavaScript for Web Developers (Wrox, 2012), High Performance JavaScript (O’Reilly, 2010), و Professional Ajax (Wrox, 2007). . يعتبر نيكولاس مدافعا قويا عن العديد من الممارسات البرمجية المحكمة بما فيها التحسين التدريجي و أمكانية الوصول وفعالية الأداء وقابلية الصيانة وجدوى الحلول حتى وإن تعاضمت المشكلة.
ترجمة: زاهر النوتكي.
المقال الأصلي: Starting An Open-Source Project