سيقام مهرجان لتكنولوجيا المعلومات في سان بطرسبرج هذا الأسبوع . أحد المتحدثين سيكون ريتشارد ستالمان. كما تشارك في المهرجان، وطبعاً لا يمكن أن نتجاهل موضوع البرمجيات الحرة. ولهذا السبب تم استدعاء أحد تقاريرنا . سيتم تخصيصه لتاريخ تطوير Embox كمشروع مفتوح المصدر. أريد في هذه المقالة أن أتحدث عن الأفكار الرئيسية التي، في رأيي، تؤثر على تطوير المشاريع مفتوحة المصدر. المقالة، مثل التقرير، مبنية على تجربة شخصية.
لنبدأ بشيء بسيط، مع تعريف مصطلح المصدر المفتوح. من الواضح أن المشروع مفتوح المصدر هو مشروع يحتوي على أحد التراخيص التي تسمح بالوصول إلى الكود المصدري للمشروع. بالإضافة إلى ذلك، يعني المشروع المفتوح أن مطوري الطرف الثالث يمكنهم إجراء تغييرات. أي أنه إذا قامت إحدى الشركات أو المطورين بنشر الكود الخاص بمنتجها، جزئيًا أو كليًا، فهذا لا يجعل هذا المنتج مشروعًا مفتوح المصدر بعد. وأخيرا، يجب أن يؤدي أي نشاط مشروع إلى نتيجة معينة، وانفتاح المشروع يعني أن هذه النتيجة لا تستخدم فقط من قبل المطورين أنفسهم.
لن نتطرق إلى مشاكل التراخيص المفتوحة. هذا موضوع كبير جدًا ومعقد ويتطلب تحقيقًا متعمقًا. تمت كتابة الكثير من المقالات والمواد الجيدة حول هذا الموضوع. ولكن بما أنني لست خبيرا في مجال حقوق الطبع والنشر، سأقول فقط أن الترخيص يجب أن يلبي أهداف المشروع. على سبيل المثال، بالنسبة لـ Embox، لم يكن اختيار BSD بدلاً من ترخيص GPL عرضيًا.
حقيقة أن المشروع مفتوح المصدر يجب أن يوفر القدرة على إجراء التغييرات والتأثير على تطوير المشروع مفتوح المصدر يعني أن المشروع يتم توزيعه. تعد إدارتها والحفاظ على النزاهة والأداء أكثر صعوبة مقارنة بالمشروع ذي الإدارة المركزية. يطرح سؤال معقول: لماذا المشاريع المفتوحة أصلا؟ تكمن الإجابة في مجال الجدوى التجارية، فبالنسبة لفئة معينة من المشاريع، فإن فوائد هذا النهج تفوق التكاليف. أي أنها ليست مناسبة لجميع المشاريع والنهج المفتوح مقبول بشكل عام. على سبيل المثال، من الصعب تصور تطوير نظام تحكم لمحطة توليد كهرباء أو طائرة على أساس مبدأ مفتوح. لا، بالطبع، يجب أن تتضمن هذه الأنظمة وحدات تعتمد على المشاريع المفتوحة، لأن ذلك سيوفر عددًا من المزايا. ولكن يجب أن يكون شخص ما مسؤولاً عن المنتج النهائي. حتى لو كان النظام يعتمد بالكامل على كود المشاريع المفتوحة، فإن المطور، بعد أن قام بتجميع كل شيء في نظام واحد وإنشاء تصميمات وإعدادات محددة، يقوم بإغلاقه بشكل أساسي. قد يكون الرمز متاحًا للعامة.
هناك أيضًا الكثير من الفوائد لهذه الأنظمة من إنشاء المشاريع مفتوحة المصدر أو المساهمة فيها. وكما قلت سابقًا، قد يظل رمز النظام النهائي متاحًا للعامة. لماذا، لأنه من الواضح أنه من غير المرجح أن يكون لدى أي شخص نفس الطائرة لاختبار النظام. هذا صحيح، ولكن قد يكون هناك شخص ما يريد التحقق من أقسام معينة من التعليمات البرمجية، أو، على سبيل المثال، قد يكتشف شخص ما أن المكتبة المستخدمة لم يتم تكوينها بشكل صحيح تمامًا.
تظهر فائدة أكبر إذا قامت الشركة بتخصيص جزء أساسي من النظام في مشروع منفصل. على سبيل المثال، مكتبة لدعم نوع ما من بروتوكول تبادل البيانات. في هذه الحالة، حتى لو كان البروتوكول خاصًا بموضوع معين، يمكنك مشاركة تكاليف صيانة هذا الجزء من النظام مع شركات أخرى في هذا المجال. بالإضافة إلى ذلك، يحتاج المتخصصون الذين يمكنهم دراسة هذا الجزء من النظام الموجود في المجال العام إلى وقت أقل بكثير لاستخدامه بفعالية. وأخيرًا، فإن فصل جزء إلى كيان مستقل يستخدمه مطورو الطرف الثالث يسمح لنا بتحسين هذا الجزء، لأننا نحتاج إلى تقديم واجهات برمجة تطبيقات فعالة، وإنشاء وثائق، وأنا لا أتحدث حتى عن تحسين تغطية الاختبار.
يمكن للشركة الحصول على فوائد تجارية دون إنشاء مشاريع مفتوحة المصدر، ويكفي أن يشارك متخصصوها في مشاريع الطرف الثالث المستخدمة في الشركة. بعد كل شيء، تبقى جميع الفوائد: يعرف الموظفون المشروع بشكل أفضل، وبالتالي يستخدمونه بشكل أكثر فعالية، ويمكن للشركة التأثير على اتجاه تطوير المشروع، ومن الواضح أن استخدام التعليمات البرمجية الجاهزة والمصححة يقلل من تكاليف الشركة.
فوائد إنشاء مشاريع مفتوحة المصدر لا تنتهي عند هذا الحد. لنأخذ عنصرًا مهمًا في العمل مثل التسويق. بالنسبة له، يعد هذا بمثابة صندوق رمل جيد جدًا يسمح له بتقييم متطلبات السوق بشكل فعال.
وبالطبع، يجب ألا ننسى أن المشروع مفتوح المصدر هو وسيلة فعالة لإعلان نفسك كحامل لأي تخصص. في بعض الحالات، هذه هي الطريقة الوحيدة لدخول السوق. على سبيل المثال، بدأ Embox كمشروع لإنشاء نظام RTOS. ربما ليست هناك حاجة لتوضيح أن هناك الكثير من المنافسين. بدون إنشاء مجتمع، لم يكن لدينا ببساطة ما يكفي من الموارد لتوصيل المشروع إلى المستخدم النهائي، أي أن يبدأ مطورو الطرف الثالث في استخدام المشروع.
المجتمع هو المفتاح في مشروع مفتوح المصدر. يتيح لك تقليل تكاليف إدارة المشروع بشكل كبير وتطوير ودعم المشروع. يمكننا القول أنه بدون مجتمع لا يوجد مشروع مفتوح المصدر على الإطلاق.
تمت كتابة الكثير من المواد حول كيفية إنشاء وإدارة مجتمع مشروع مفتوح المصدر. من أجل عدم إعادة سرد الحقائق المعروفة بالفعل، سأحاول التركيز على تجربة Embox. على سبيل المثال، تعد عملية إنشاء مجتمع مسألة مثيرة للاهتمام للغاية. وهذا هو، يخبر الكثيرون كيفية إدارة المجتمع الحالي، لكن لحظات إنشائه يتم التغاضي عنها في بعض الأحيان، معتبرا ذلك أمرا معطى.
القاعدة الأساسية عند إنشاء مجتمع مشروع مفتوح المصدر هي عدم وجود قواعد. أعني أنه لا توجد قواعد عالمية، تمامًا كما لا توجد حل سحري، وذلك فقط لأن المشاريع مختلفة تمامًا. من غير المحتمل أن تتمكن من استخدام نفس القواعد عند إنشاء مجتمع لمكتبة تسجيل js وبعض برامج التشغيل المتخصصة للغاية. علاوة على ذلك، في مراحل مختلفة من تطوير المشروع (وبالتالي المجتمع)، تتغير القواعد.
بدأ Embox كمشروع طلابي لأنه كان بإمكانه الوصول إلى الطلاب من قسم برمجة الأنظمة. في الواقع، كنا ندخل مجتمعًا آخر. يمكننا أن نثير اهتمام المشاركين في هذا المجتمع، الطلاب، بالممارسات الصناعية الجيدة في تخصصهم، والعمل العلمي في مجال برمجة الأنظمة والدورات الدراسية والدبلومات. أي أننا اتبعنا إحدى القواعد الأساسية لتنظيم المجتمع: يجب أن يحصل أفراد المجتمع على شيء ما، ويجب أن يتوافق هذا السعر مع مساهمة المشارك.
كانت المرحلة التالية لـ Embox هي البحث عن مستخدمي الطرف الثالث. من المهم جدًا أن نفهم أن المستخدمين مشاركين بشكل كامل في مجتمع المصادر المفتوحة. عادةً ما يكون عدد المستخدمين أكبر من عدد المطورين. ولكي يرغبوا في أن يصبحوا مساهمين في مشروع ما، فإنهم يبدأون أولاً في استخدامه بطريقة أو بأخرى.
أول مستخدمي Embox كانوا قسم علم التحكم الآلي النظري. اقترحوا إنشاء برنامج ثابت بديل لـ Lego Mindstorm. وعلى الرغم من أن هؤلاء كانوا لا يزالون مستخدمين محليين (كان بإمكاننا مقابلتهم شخصيًا ومناقشة ما يريدون). لكنها كانت لا تزال تجربة جيدة للغاية. على سبيل المثال، قمنا بتطوير عروض توضيحية يمكن عرضها للآخرين، لأن الروبوتات ممتعة وتجذب الانتباه. ونتيجة لذلك، حصلنا على مستخدمين خارجيين حقيقيين بدأوا في التساؤل عن ماهية Embox وكيفية استخدامه.
في هذه المرحلة، كان علينا أن نفكر في التوثيق، وفي وسائل التواصل مع المستخدمين. لا، بالطبع، فكرنا في هذه الأمور المهمة من قبل، لكنها كانت سابقة لأوانها ولم تعطي أثراً إيجابياً. وكان التأثير سلبيا إلى حد ما. اسمحوا لي أن أقدم لكم بضعة أمثلة. استخدمنا googlecode، الذي يدعم موقع wiki الخاص به تعدد اللغات. أنشأنا صفحات بعدة لغات، ليس فقط الإنجليزية والروسية، حيث لم نتمكن من التواصل بصعوبة، ولكن أيضًا الألمانية والإسبانية. ونتيجة لذلك، يبدو الأمر سخيفًا جدًا عند السؤال بهذه اللغات، لكننا لا نستطيع الإجابة على الإطلاق. أو قاموا بإدخال قواعد حول كتابة الوثائق والتعليق، ولكن بما أن واجهة برمجة التطبيقات (API) تغيرت كثيرًا وبشكل ملحوظ، فقد تبين أن وثائقنا كانت قديمة وكانت مضللة أكثر مما ساعدت.
ونتيجة لذلك، أدت كل جهودنا، حتى الخاطئة منها، إلى ظهور مستخدمين خارجيين. وحتى ظهر عميل تجاري أراد تطوير نظام RTOS الخاص به. وقمنا بتطويره لأن لدينا الخبرة وبعض الأعمال الأساسية. هنا تحتاج إلى التحدث عن اللحظات الجيدة والسيئة. سأبدأ بالأشرار. نظرًا لأن العديد من المطورين شاركوا في هذا المشروع على أساس تجاري، فقد كان المجتمع بالفعل غير مستقر ومنقسم تمامًا، الأمر الذي لا يمكن بالطبع إلا أن يؤثر على تطوير المشروع. كان العامل الإضافي هو أن اتجاه المشروع تم تحديده من قبل عميل تجاري واحد، ولم يكن هدفه مواصلة تطوير المشروع. على الأقل لم يكن هذا هو الهدف الرئيسي.
ومن ناحية أخرى، كان هناك عدد من الجوانب الإيجابية. لقد حصلنا حقًا على مستخدمين من جهات خارجية. لم يكن الأمر يتعلق بالعميل فحسب، بل أيضًا أولئك الذين كان هذا النظام مخصصًا لهم. وقد زاد الدافع للمشاركة في المشروع. بعد كل شيء، إذا كان بإمكانك أيضًا كسب المال من عمل مثير للاهتمام، فهذا أمر جيد دائمًا. والأهم من ذلك أننا سمعنا رغبة واحدة من العملاء، والتي بدت لنا في ذلك الوقت مجنونة، ولكنها أصبحت الآن الفكرة الرئيسية لـ Embox، وهي استخدام التعليمات البرمجية التي تم تطويرها بالفعل في النظام. الآن الفكرة الرئيسية لـ Embox هي استخدام برنامج Linux بدون Linux. وهذا هو، الجانب الإيجابي الرئيسي الذي ساهم في مواصلة تطوير المشروع هو إدراك أن المشروع يستخدم من قبل مستخدمين خارجيين، وينبغي أن يحل بعض مشاكلهم.
في ذلك الوقت، كانت شركة Embox قد تجاوزت بالفعل نطاق مشروع الطلاب. العامل المحدد الرئيسي في تطوير المشروع وفقًا لنموذج الطالب هو تحفيز المشاركين. يشارك الطلاب أثناء الدراسة، وعندما يتخرجون، يجب أن يكون هناك دافع مختلف. إذا لم يظهر الدافع، يتوقف الطالب ببساطة عن المشاركة في المشروع. إذا أخذنا في الاعتبار أن الطلاب يحتاجون أولاً إلى التدريب، يتبين أنهم يصبحون متخصصين جيدين بحلول وقت التخرج، لكن مساهمتهم في المشروع، بسبب قلة الخبرة، ليست كبيرة جدًا.
بشكل عام، ننتقل بسلاسة إلى النقطة الرئيسية التي تسمح لنا بالحديث عن إنشاء مشروع مفتوح المصدر - إنشاء منتج من شأنه أن يحل مشاكل مستخدميه. كما أوضحت أعلاه، فإن الخاصية الرئيسية لأي مشروع مفتوح المصدر هي مجتمعه. علاوة على ذلك، فإن أعضاء المجتمع هم في المقام الأول مستخدمون. ولكن من أين يأتون عندما لا يكون هناك شيء يمكن استخدامه؟ لذلك اتضح أنه، تمامًا كما هو الحال مع مشروع غير مفتوح المصدر، تحتاج إلى التركيز على إنشاء MVP (الحد الأدنى من المنتج القابل للتطبيق)، وإذا كان ذلك يثير اهتمام المستخدمين، فسيظهر مجتمع حول المشروع. إذا كنت منخرطًا في إنشاء مجتمع فقط من خلال العلاقات العامة المجتمعية، أو كتابة ويكي بجميع لغات العالم، أو سير عمل git الصحيح على github، فمن غير المرجح أن يكون هذا مهمًا في المراحل الأولى من المشروع. بالطبع، في المراحل المناسبة، هذه ليست أشياء مهمة فحسب، بل ضرورية أيضًا.
وفي الختام أود أن أشير في رأيي، يعكس توقعات المستخدمين من مشروع مفتوح المصدر:
أفكر جديًا في التحول إلى نظام التشغيل هذا (على الأقل حاول. إنهم يسعون إليه بنشاط ويقومون بأشياء رائعة).
ملاحظة على سيكون لدينا ما يصل إلى ثلاثة تقارير. واحد عن المصدر المفتوح واثنان عن المضمن (وواحد عملي). سنقوم في الجناح بإجراء فصل دراسي رئيسي حول برمجة وحدات التحكم الدقيقة باستخدام . كالعادة، سوف نحضر الأجهزة ونتيح لك برمجتها. سيكون هناك أيضًا مهمة وأنشطة أخرى. تعالوا إلى المهرجان ومنصتنا، سيكون الأمر ممتعًا.
المصدر: www.habr.com