ما هي العوامل التي تحدد نجاح المشروع مفتوح المصدر؟[مغلق]
https://stackoverflow.com/questions/80997
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لدينا سلسلة من التطبيقات والمكتبات مغلقة المصدر، والتي نعتقد أنه سيكون من المنطقي فتح كود المصدر لها.
ما يعوقنا حتى الآن هو الجهد اللازم لتنظيف قاعدة التعليمات البرمجية وتوثيق المصدر قبل الانفتاح.
لا نريد أن نفتح المصدر إلا إذا كانت لدينا فرصة معقولة لنجاح المشاريع - أي.وجود المساهمين.نحن مقتنعون بأن الكود سيكون مثيرًا للاهتمام لقاعدة كبيرة من المطورين.
العوامل التي باستثناء "أهمية" و"فائدة" المشروع، تحديد مدى نجاح مشروع مفتوح المصدر؟
أمثلة:
- نظافة الكود
- توافر تعليقات التعليمات البرمجية المصدر
- واجهات برمجة التطبيقات الموثقة كليًا أو جزئيًا
- اختيار الترخيص (GPL مقابل.LGPL مقابل.بي إس دي، الخ...)
- اختيار المستودع العام
- الاستثمار في موقع عام
المحلول
هناك العديد من الأشياء التي تهيمن على نجاح التعليمات البرمجية.ويجب تحقيق كل هذه الأمور من أجل أدنى فرصة لاعتمادها.
- السوق - يجب أن يكون هناك سوق لمشروعك مفتوح المصدر.إذا كان مشروعك عبارة عن عصارة برتقال في الفضاء، فأنا أشك في أنك ستحقق نجاحًا كبيرًا.يجب عليك التأكد من حصول مشروعك على اعتماد كبير بين المستخدمين والمطورين.من المرجح أن تنجح إذا تمكنت من إقناع الشركات الأخرى بتبنيها أيضًا.
- التوثيق - كما تطرقت إلى التوثيق السابق هو المفتاح.من بين هذه الوثائق التعليمات البرمجية المعلقة والقرارات المعمارية وملاحظات واجهة برمجة التطبيقات.حتى لو كانت وثائقك تحتوي على أخطاء، أو أخطاء تتعلق ببرنامجك، فلا بأس.تذكر أن الشفافية هي المفتاح.
- الحرية - يجب أن تسمح بأن يكون الكود الخاص بك "حرًا" - وأعني بهذا حرًا كما هو الحال في الكلام، وليس كما هو الحال في البيرة.إذا كان لديك شعور بأن السوق الخاص بك أصبح بمثابة مكتبة للشركات الأخرى، فإن ترخيص BSD هو الأمثل.إذا كان برنامجك سيتم تشغيله على أجهزة سطح المكتب، فإن GPL هي اختيارك.
- الشفافية - يجب عليك كتابة البرامج في بيئة شفافة.بمجرد أن تصبح مفتوح المصدر، لا توجد أسرار مخفية.يجب أن تشرح كل ما تفعله، وماذا تفعل.وهذا سوف يغضب المطورين بشكل لا مثيل له
- مجتمع المطورين - مطلوب مجتمع مطور قوي.يجب أن يكون هذا موجودا.يساهم حوالي 5٪ فقط من المستخدمين في المشروع.إذا لاحظ شخص ما أنه لم يكن هناك أي إصدارات لمدة عام ، فلن يفكروا في "واو ، تم تنفيذ هذا البرنامج ،" سوف يعتقدون أن "المطورين يجب أن يلقوه". احتفظ بمطوريك الذين يعملون على ذلك ، حتى لو كان ذلك يعني أنهم يكلفونك المال.
- الاتصالات - يجب عليك التأكد من أن مجتمعك قادر على التواصل.ويجب أن يكونوا قادرين على الإبلاغ عن الأخطاء ومناقشة الحلول ونشر التصحيحات.بدون ردود الفعل، فمن غير المجدي أن يكون المشروع مفتوح المصدر
- التوفر - من الضروري تسهيل الحصول على الكود الخاص بك، حتى لو كان ذلك يعني إثارة غضب المحامين.يجب عليك التأكد من سهولة تنزيل مشروعك واستخدامه.لا تريد أن يضطر المستخدم إلى الانتقال عبر 18 شاشة تذمر وتوقيع عقد من أجل القيام بذلك.عليك أن تجعل الأمور بسيطة ونظيفة
نصائح أخرى
أعتقد أن العامل الأكثر أهمية هو عدد المستخدمين الذين يستخدمون مشروعك.بخلاف ذلك، فهي مجرد مجموعة من الأشياء المكتوبة جيدًا والمفيدة والموثقة جيدًا والموجودة على خادم لا تفعل الكثير...
للحصول على المساهمين، تحتاج أولاً إلى المستخدمين، ثم تحتاج إلى بعض عدم الاكتمال.تحتاج إلى تشغيل "هذا رائع ، لكنني أتمنى حقًا أن يكون هذا أو كان مختلفًا بهذه الطريقة." إذا كنت تفتقد ميزة واضحة ، فمن المحتمل جدًا أن يصبح المستخدم مساهمًا في إضافتها.
الشيء الأكثر أهمية هو أن يكون البرنامج جيدًا.إذا لم تكن جيدة، فلن يستخدمها أحد.ولا يمكنك أن تأمل أن ينعكس اتجاه الدجاجة والبيضة وأن يعتبره الناس أمراً مفروغاً منه إلى أن يصبح جيداً.
بالطبع، كلمة "جيد" تعني فقط "أفضل من أي خيار عملي آخر لعدد كبير من الأشخاص"، وهذا لا يعني أنه الأفضل تمامًا، ولكن فقط أنه يحتوي على بعض الميزات التي تجعله، بالنسبة للعديد من الأشخاص، أفضل من خيارات أخرى.في بعض الأحيان البرنامج لديه لا يوجد ما يعادلها في أي مكان آخر، وفي هذه الحالة لا يوجد أي شرط تقريبًا في هذا الصدد.
عندما يكون البرنامج جيدًا، سيستخدمه الناس.من الواضح أنه يجب أن يكون له سوق بين المستخدمين - فالبرنامج الجيد الذي يفعل شيئًا لا يريده أحد ليس جيدًا حقًا بغض النظر عن مدى جودة تصميمه.يمكن للمرء أن يوضح نقطة ما حول التسويق، ولكن المنتجات الجيدة حقًا، إلى حد ما، لديها ميل لتسويق نفسها.من الصعب جدًا الترويج لشيء غير جيد، لذلك من الواضح أن الأولوية الأولى يجب أن تكون المنتج نفسه، وليس الترويج للمنتج.
السؤال الحقيقي إذن هو – كيف تجعله جيدًا؟والإجابة على ذلك هي فريق تطوير متخصص وماهر.نادرًا ما يستطيع شخص واحد إنشاء منتج جيد بمفرده؛حتى لو كانوا أفضل بكثير من المطورين الآخرين، فإن وجهات النظر المتعددة لها تأثير مفيد بشكل لا يصدق على المشروع.وهذا هو السبب في أن وجود رعاة من الشركات مفيد جدًا - فهو يضع عقول المطورين الآخرين (من الشركة) في المشكلة لإبداء رأيهم الخاص.يعد هذا مفيدًا بشكل خاص في حالة أن تطوير البرنامج يتطلب خبرة كبيرة غير متوفرة بشكل شائع في المجتمع.
وبطبيعة الحال، أقول هذا كله من التجربة.أنا أحد المطورين الرئيسيين لنظام x264 (الأكثر نشاطًا حاليًا)، وهو أحد أشهر برامج تشفير الفيديو.لدينا مطوران رئيسيان، والعديد من المطورين الصغار في المجتمع الذين يساهمون في التصحيحات، ورعاية الشركات من Joost (Gabriel Bouvigne، الذي يحافظ على خوارزميات التحكم في الأسعار)، من Avail Media (التي أعمل معها أحيانًا بموجب عقد والذين يقومون حاليًا بتعيين المبرمجين بموجب عقد) لإضافة دعم متشابك لـ MBAFF)، ومن بعض البرامج الأخرى التي تظهر من وقت لآخر.
مطور واحد جيد لا يصنع مشروعًا، بل العديد من المطورين الجيدين يفعلون ذلك.والنتيجة النهائية لهذا هي برنامج يقوم بترميز الفيديو بشكل أسرع وبجودة أفضل بكثير من معظم المنافسين التجاريين أو الأجهزة أو البرامج، حتى أولئك الذين لديهم ميزانيات تطوير هائلة تمامًا.
عند النظر في هذه المشكلات، قد تكون مهتمًا بمراجعة الإصدار عبر الإنترنت من a دورة حول المصادر المفتوحة في جامعة كاليفورنيا في بيركلي, يسمى تطوير المصادر المفتوحة وتوزيع المعلومات الرقمية:المنظورات الفنية والاقتصادية والاجتماعية والقانونية.وقد شارك في تدريسها ميتش كابور (مؤسس لوتس) وباولا سامويلسون، أستاذة في كلية الحقوق.لقد قمت برحلة طويلة إلى العمل ووضعت صوت الدورة على جهاز iPod الخاص بي في العام الماضي - يتحدثون كثيرًا عن ما يصلح وما لا يصلح ولماذا، من منظور واسع جدًا (رغم أنه أكاديمي بشكل واضح).
وقد تم تأليف كتب حول هذا الموضوع.في الواقع، يمكنك العثور على كتاب مجاني هنا: إنتاج البرمجيات مفتوحة المصدر
حقًا، أعتقد أن الإجابة هي "كيف تدير المشروع".
جميع الأمثلة التي ذكرتها مهمة، نعم، ولكن الأشياء الأساسية هي كيفية إدارة التفاعل بين المطورين، وكيفية التعامل مع/قبول التصحيحات وما إلى ذلك، ومن هو "المسؤول" وكيف يتعامل مع هذه المسؤولية، وما إلى ذلك وما إلى ذلك.
قارن وقارن (ليس من الصعب تتبع التاريخ!) إدارة تطوير Class::DBI وDBIx::Class في Perl.
لقد كنت أقرأ للتو تدوينة ممتازة الليلة حول جانب سهولة الاستخدام للمشاريع مفتوحة المصدر الناجحة مقابل غير الناجحة.
مقتطفات:
لقد تم إهدار الكثير من النطاق الترددي في الجدل حول عدم قابلية الاستخدام في البرمجيات مفتوحة المصدر/البرمجيات المجانية (من الآن فصاعدا "OSS").يستمر النقاش حتى هذه اللحظة على المدونات والمنتديات وسلاسل تعليقات Slashdot.يقول بعض الأشخاص أن قابلية الاستخدام السيئة مستوطنة في عالم برمجيات المصدر المفتوح بأكمله، بينما يقول آخرون أن قابلية استخدام برمجيات المصدر المفتوح رائعة ولكن المشكلة الحقيقية تكمن في المستخدمين ذوي العقول المنغلقة الذين يتوقعون أن يقوم كل برنامج باستنساخ Microsoft.يزعم بعض الأشخاص أن مشكلات واجهة المستخدم هي آلام مؤقتة، بينما يقول آخرون إن نموذج تطوير OSS ينتج عنه واجهة مستخدم سيئة بشكل منهجي.حتى أن بعض الأشخاص يجادلون بأن رخصة GPL تكافئ بشكل غير مباشر البرامج التي يصعب استخدامها!(للتسجيل، أنا لا أتفق مع ذلك).
فقط مفتوح المصدر.على الأرجح، لن يبدأ أحد بالمساهمة بعد.ولكن على الأقل يمكنك أن تكتب في النشرات الصحفية أن منتجك هو GPL أو أي شيء آخر.
الخطوة الأولى هي أن يبدأ الناس في استخدامه...
وربما بعد ذلك، بعد أن يشعر المستخدمون بالارتياح، سيبدأون في المساهمة.
لقد كانت إجابات الجميع جيدة حتى الآن، ولكن هناك شيء واحد مفقود وهو المراقبة الجيدة.لا شيء يقتل مشروعًا مفتوح المصدر بشكل أسرع من عدم وجود نوع من إدارة المشروع.لا تخبر الناس بما يجب عليهم فعله بقدر ما تضيف فقط بعض البنية والمهام للمطورين الذين تأمل في جذبهم.
المشاريع غير المنظمة تنهار بسرعة.إنه ليس طائرًا يمكنك تركه ومشاهدته وهو يطير بعيدًا.
