كيفية إنشاء مشروع مفتوح المصدر

بالفعل هذا الأسبوع في سانت بطرسبرغ ستستضيف مهرجان تكنولوجيا المعلومات TechTrain . سيكون أحد المتحدثين ريتشارد ستالمان. تشارك Embox أيضًا في المهرجان ، وبالطبع لم نستطع تجاهل موضوع البرنامج المفتوح المصدر. لذلك ، يسمى أحد تقاريرنا "من الحرف اليدوية إلى مشروع مفتوح المصدر. تجربة Embox . " سيتم تخصيصه لتاريخ Embox كمشروع مفتوح المصدر. في هذه المقالة أريد أن أتحدث عن الأفكار الرئيسية التي تؤثر في رأيي على تطوير مشاريع مفتوحة المصدر. يستند المقال ، مثل التقرير ، إلى تجربة شخصية.

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

لن نلمس مشاكل التراخيص المفتوحة. هذا موضوع كبير ومعقد يتطلب تحقيقًا عميقًا. تمت كتابة الكثير من المقالات والمواد الجيدة حول هذا الموضوع. ولكن نظرًا لأنني لست متخصصًا في مجال حقوق الطبع والنشر ، لا يمكنني إلا أن أقول إن الترخيص يجب أن يلبي أهداف المشروع. بالنسبة لـ Embox ، على سبيل المثال ، لم يكن اختيار BSD بدلاً من ترخيص GPL عشوائيًا.

حقيقة أن المشروع المفتوح يجب أن يجعل من الممكن إجراء تغييرات والتأثير على تطوير مشروع مفتوح يعني أن المشروع قد تم توزيعه. إن إدارته والحفاظ على النزاهة والكفاءة أصعب بكثير مقارنة بالمشروع ذي الإدارة المركزية. يطرح سؤال معقول: لماذا مشاريع مفتوحة المصدر على الإطلاق؟ تكمن الإجابة في مجال الجدوى التجارية ؛ فبالنسبة لفئة معينة من المشاريع ، تفوق فوائد هذا النهج التكاليف. هذا هو ، وليس لجميع المشاريع ، نهجا مفتوحا مقبول عموما. على سبيل المثال ، من الصعب تخيل تطوير نظام لتوليد الطاقة أو نظام التحكم في الطائرات على أساس مبدأ مفتوح. لا ، بالطبع ، يجدر إدراج الوحدات القائمة على المشاريع المفتوحة في تكوين مثل هذه الأنظمة ، لأن هذا سيوفر عددًا من المزايا. لكن يجب على شخص ما الإجابة عن المنتج النهائي. حتى إذا كان النظام يعتمد بالكامل على شفرة مفتوحة المصدر ، يقوم المطور ، بتعبئة كل شيء في نظام واحد وإنشاء تجميعات وإعدادات محددة ، بإغلاقه بشكل أساسي. قد يكون الرمز متاحًا للعامة.

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

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

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

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

وبالطبع ، يجب ألا ننسى أن مشروع المصادر المفتوحة هو وسيلة فعالة للإعلان عن نفسه بأنه الناقل لأي تخصص. في بعض الحالات ، تكون هذه هي الطريقة الوحيدة لدخول السوق. على سبيل المثال ، بدأت Embox كمشروع لإنشاء RTOS. ربما لا حاجة لشرح أن هناك مجموعة من المنافسين. بدون إنشاء مجتمع ، لن يكون لدينا ببساطة موارد كافية لإيصال المشروع إلى المستخدم النهائي ، أي لمطوري الطرف الثالث لاستخدام المشروع.

المجتمع هو المفتاح في مشروع مفتوح المصدر. إنها تتيح لك تقليل تكاليف إدارة المشروع بشكل كبير وتطوير المشروع ودعمه. يمكننا القول أنه بدون مجتمع لا يوجد مشروع مفتوح المصدر على الإطلاق.

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

القاعدة الرئيسية عند إنشاء مشروع مجتمع مفتوح المصدر - لا توجد قواعد. أعني أنه لا توجد قواعد عالمية ، تمامًا مثل الرصاصة الفضية ، إذا كان المشروع مختلفًا تمامًا. لا يمكن استخدام نفس القواعد عند إنشاء مجتمع لمكتبة تسجيل js وبعض برامج التشغيل عالية التخصص. علاوة على ذلك ، في مراحل مختلفة من تطوير المشروع (وبالتالي المجتمع) ، تتغير القواعد.

بدأت Embox كمشروع للطلاب ، حيث كان هناك وصول إلى الطلاب في قسم برمجة النظام. في الواقع ، ذهبنا إلى مجتمع آخر. المشاركون في هذا المجتمع ، الطلاب ، يمكن أن نكون مهتمين في الممارسة الصناعية الجيدة في تخصصهم ، والأعمال العلمية في مجال برمجة النظام ، ورقات الفصل الدراسي والدبلومات. هذا هو ، لقد التزمنا بأحد القواعد الأساسية لتنظيم المجتمع ، ويجب أن يحصل أفراد المجتمع على شيء ما ، ويجب أن يتوافق هذا السعر مع مساهمة المشارك.

كانت المرحلة التالية لـ Embox هي البحث عن مستخدمي الطرف الثالث. من المهم للغاية أن نفهم أن المستخدمين أعضاء كاملون في مجتمع المصادر المفتوحة. عادة ما يكون هناك عدد أكبر من المستخدمين من المطورين. ومن أجل الرغبة في أن تصبح مساهماً في المشروع ، يبدأون أولاً في استخدامه بطريقة أو بأخرى.

كان المستخدمون الأوائل لـ Embox هو قسم علم التحكم النظري. اقترحوا إنشاء برنامج ثابت بديل لـ Lego Mindstorm. وعلى الرغم من أنه كان لا يزال مستخدمين محليين (يمكن أن نلتقي شخصيا ومناقشة ما يريدون). ولكن لا يزال كان تجربة جيدة للغاية. على سبيل المثال ، قمنا بتطوير عروض توضيحية يمكن عرضها للآخرين ، لأن الروبوتات ممتعة وتجتذب الانتباه. نتيجة لذلك ، كان لدينا بالفعل مستخدمون من أطراف ثالثة بدأوا يسألون عن ماهية Embox وكيف يتم استخدامها.

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

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

من ناحية أخرى ، كان هناك عدد من النقاط الإيجابية. لقد حصلنا بالفعل على مستخدمين تابعين لجهة خارجية. لم يكن فقط العميل ، ولكن أيضًا أولئك الذين تم تصميم هذا النظام من أجلهم. زاد الدافع للمشاركة في المشروع. بعد كل شيء ، إذا كان يمكنك أيضًا كسب المال بشأن مسألة مثيرة للاهتمام ، فهذا أمر رائع دائمًا. والأهم من ذلك أننا سمعنا رغبة واحدة من العملاء ، والتي كانت في ذلك الوقت مجنونة بالنسبة لنا ، ولكنها الآن هي الفكرة الرئيسية لـ Embox ، وهي استخدام الكود الذي تم تطويره بالفعل في النظام. الفكرة الرئيسية لـ Embox الآن هي استخدام برنامج Linux بدون Linux. بمعنى أن العامل الإيجابي الرئيسي الذي ساهم في زيادة تطوير المشروع هو إدراك أن المستخدمين قد استخدموا هذا المشروع ، وأنه يجب أن يحل بعض مشاكلهم.

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

بشكل عام ، نحن ننتقل بسلاسة إلى النقطة الرئيسية ، والتي تتيح لنا التحدث عن إنشاء مشروع مفتوح المصدر - إنشاء منتج من شأنه أن يحل مشاكل مستخدميها. كما شرحت أعلاه ، فإن الخاصية الرئيسية لمشروع مفتوح المصدر هو مجتمعها. علاوة على ذلك ، أعضاء المجتمع هم المستخدمون بشكل أساسي. ولكن من أين أتوا حتى ماذا يستخدمون؟ لذلك اتضح أنه كما هو الحال مع مشروع غير مفتوح المصدر ، تحتاج إلى التركيز على إنشاء MVP (الحد الأدنى من المنتج القابل للتطبيق) ، وإذا كان يهم المستخدمين ، فسيظهر مجتمع حول المشروع. إذا كنت تشارك فقط في إنشاء مجتمع من خلال مجتمع العلاقات العامة ، أو كتابة ويكي بجميع لغات العالم ، أو سير العمل الصحيح على github ، فمن غير المرجح أن يكون هذا الأمر مهمًا في المراحل الأولى من المشروع. بالطبع ، في المراحل المناسبة ، هذه ليست مهمة فحسب ، بل هي ضرورية أيضًا.

في الختام ، أريد أن أقدم تعليقًا ، برأيي يعكس توقعات المستخدم من مشروع مفتوح المصدر:

أفكر بجدية في التبديل إلى نظام التشغيل هذا (على الأقل جربه. إنه نشط للغاية في نشره والقيام بأشياء رائعة).

ملاحظة: في TechTrain ، سيكون لدينا ما يصل إلى ثلاثة تقارير. واحد حول المصدر المفتوح واثنان حول المضمنة (والآخر عملي). في الحامل ، سنقوم بإجراء فصل دراسي رئيسي على برمجة المتحكمات الدقيقة باستخدام Embox . تقليديا ، سنأتي الغدد والسماح لهم البرنامج. سيكون هناك أيضا السعي وغيرها من الأنشطة. تعال إلى المهرجان ومعرضنا ، سيكون متعة.