إزاي تبني مشروع Open Source الناس تستخدمه فعلاً، مش مجرد Repository على GitHub
- نُشر في
- مدة القراءة
- 12 دقائق قراءة
نشر الكود على GitHub سهل. الأصعب هو أن يجد المطور المشروع، يفهمه، يثق فيه، يثبته، ثم يظل يستخدمه. هذه أهم الدروس التي تعلمتها من بناء وصيانة مشاريع مفتوحة المصدر حقيقية.
في المقال السابق كتبت عن اللحظة التي بدأت فيها أرى مشاريعي المفتوحة المصدر كمنظومة واحدة بدلاً من مجموعة repositories منفصلة.
لكن قبل أن يكون لديك ecosystem، يجب أن يكون لديك مشروع يستحق أن يستخدمه الناس أصلاً.
نشر مشروع على GitHub سهل.
أن تجعل شخصاً لا يعرفك يجد المشروع، يفهمه، يثق فيه، يثبته، ثم يستخدمه في مشروع حقيقي — هذه قصة مختلفة تماماً.
عندي مشاريع مفتوحة المصدر كثيرة، وبعضها نجح أكثر من غيره. ومع الوقت اكتشفت أن الفرق لم يكن دائماً في جودة الكود.
أحياناً المشروع الذي كتبته بشكل أفضل لم يكن هو الأكثر استخداماً.
وأحياناً أداة صغيرة حلت مشكلة واضحة جداً انتشرت أسرع من مشروع قضيت فيه شهوراً.
هذا جعلني أعيد التفكير في معنى "نجاح" مشروع مفتوح المصدر.
الـrepository ليس المنتج.
الكود جزء من المنتج.
لكن التجربة التي تبدأ من اللحظة التي يسمع فيها المطور اسم المشروع، وحتى اللحظة التي يعمل فيها داخل تطبيقه، هي المنتج الحقيقي.
أول مستخدم للمشروع يجب أن تكون أنت
أكثر المشاريع التي أستمر في صيانتها هي المشاريع التي احتجتها أنا شخصياً.
هذا ليس لأن احتياجاتي أهم من احتياجات الآخرين، ولكن لأن استخدامك الحقيقي للمشروع يجبرك على مواجهة أشياء لا تظهر أثناء التطوير النظري.
عندما تستخدم package أنت الذي كتبتها داخل production application ستكتشف بسرعة:
- هل الـAPI مزعج؟
- هل هناك configuration غير ضروري؟
- هل تحتاج إلى قراءة documentation كل مرة؟
- هل upgrade صغير يكسر المشروع؟
- هل naming واضح؟
- هل error messages تساعدك فعلاً؟
هناك فرق كبير بين:
"الـfeature تعمل."
وبين:
"أنا سعيد باستخدام الـfeature كل يوم."
الـdogfooding بالنسبة لي أصبح واحداً من أهم اختبارات جودة الـopen source.
إذا كنت لا أحب استخدام الأداة التي بنيتها، لماذا سيتحمس شخص آخر لاستخدامها؟
لا تبدأ بالـFeatures، ابدأ بالمشكلة
من أسهل الطرق لتدمير مشروع صغير هي إضافة features بسرعة.
تبدأ بفكرة بسيطة.
ثم يأتي شخص ويطلب option.
وشخص آخر يريد integration.
ثم تضيف dashboard.
ثم API.
ثم events.
ثم plugin system.
وبعد عدة شهور تصبح المشكلة الأصلية التي كان المشروع يحلها مدفونة تحت عشرات الخيارات.
حدث معي هذا التفكير أكثر من مرة.
اليوم أحاول أن أسأل سؤالاً أبسط:
ما المشكلة الواحدة التي يجب أن يكون هذا المشروع ممتازاً في حلها؟
إذا لم أستطع الإجابة في جملة واحدة، غالباً الـpositioning نفسه غير واضح.
المشروع لا يحتاج أن يفعل كل شيء.
يحتاج أن يفعل شيئاً مهماً بشكل جيد جداً.
الـREADME ليس ملفاً تقنياً فقط
بالنسبة لعدد كبير من مشاريع الـopen source، الـREADME هو الصفحة الرئيسية الحقيقية للمنتج.
قد يأتي المستخدم من Google.
أو GitHub search.
أو رابط أرسله له شخص.
أو قائمة Awesome.
في كثير من الحالات، أول شيء سيراه هو README.
ومع ذلك نجد README يبدأ بهذه الطريقة:
composer require vendor/package
قبل أن يشرح أصلاً لماذا قد تحتاج إلى الـpackage.
أنا أفضل أن أجيب أولاً على أربعة أسئلة:
ما هذا؟
ما المشكلة التي يحلها؟
لمن هو؟
ما أسرع طريقة لأرى النتيجة؟
بعد ذلك يأتي installation.
لو احتاج المطور إلى النزول نصف الصفحة حتى يفهم لماذا المشروع موجود، لدينا مشكلة.
حاول الوصول لأول نتيجة في أقل وقت ممكن
هناك metric غير رسمي أحب التفكير فيه:
Time to First Useful Result.
كم يحتاج المطور من الوقت من لحظة اكتشاف المشروع حتى يرى شيئاً مفيداً يعمل؟
ليس حتى ينتهي من قراءة التوثيق.
وليس حتى يفهم architecture بالكامل.
بل حتى يقول:
"تمام، فهمت لماذا هذه الأداة مفيدة."
كل خطوة إضافية في البداية تقلل عدد الأشخاص الذين سيكملون.
إذا كان installation يحتاج:
- Install package.
- Publish config.
- تعديل ثلاثة ملفات.
- إضافة provider.
- تشغيل migration.
- نسخ component.
- تحديث JavaScript.
- إعادة build.
فكل خطوة فرصة جديدة لخسارة المستخدم.
هذا لا يعني إخفاء التعقيد.
لكن يعني أن نسأل باستمرار:
هل هذه الخطوة ضرورية فعلاً؟
أعطِ المستخدم Default جيداً
المطورون يحبون المرونة.
لكنهم لا يريدون اتخاذ عشرين قراراً قبل أن يبدأ المشروع.
واحد من الأشياء التي أحبها في Laravel مثلاً هو أن هناك opinion واضح في أشياء كثيرة.
يمكنك تغييرها.
لكن لا تحتاج أن تصمم architecture كاملة قبل كتابة أول feature.
أحاول تطبيق نفس الفكرة في مشاريعي.
اعطني default يعمل.
ثم اسمح لي بتغييره عندما أحتاج.
بدلاً من:
"اختر واحداً من سبعة drivers وأرسل لنا config من 40 سطراً."
ابدأ بأفضل اختيار لمعظم الناس.
الـconfiguration يجب أن يكون escape hatch، وليس requirement.
Documentation جيدة تجيب عن مهام، لا عن Classes
المطور الذي يدخل التوثيق غالباً لا يقول:
"أريد أن أعرف كل methods الموجودة في هذه class."
هو يقول:
"أريد أن أعمل X."
لذلك بدأت أحب documentation المبنية على tasks أكثر من documentation المبنية بالكامل على بنية الكود.
مثلاً:
- How to install
- How to create your first resource
- How to customize authentication
- How to connect an MCP server
- How to add persistent memory
- How to deploy
بعد ذلك يمكن أن يأتي API reference لمن يحتاج التفاصيل.
المثال الكامل أحياناً أهم من عشرة صفحات تشرح كل option على حدة.
لا تجعل المستخدم يخمن حالة المشروع
واحدة من المشاكل المتكررة في GitHub هي repository شكله ممتاز، لكنك لا تعرف:
هل ما زال المشروع maintained؟
هل يعمل مع آخر version؟
هل يصلح production؟
هل هو proof of concept؟
آخر commit منذ سنة، لكن ربما المشروع stable فعلاً.
أو آخر commit أمس، لكنه مجرد experiment.
المستخدم لا يجب أن يخمن.
اكتب بوضوح:
- Supported versions
- Current status
- Upgrade policy
- License
- Release history
وإذا توقفت عن صيانة مشروع، قول ذلك أيضاً.
Archive محترم أفضل من مشروع يبدو حياً وهو مهجور.
Compatibility أهم من feature مثيرة
عندما يبدأ الناس فعلاً في استخدام مشروعك، تتغير مسؤوليتك.
قبل ذلك تستطيع إعادة كتابة كل شيء يوم الخميس لأن architecture جديدة أعجبتك.
بعد أن يدخل المشروع production عند الآخرين، كل breaking change له تكلفة لا تدفعها أنت وحدك.
هذا شيء تعلمته أكثر مع الوقت.
ليس معنى ذلك ألا نطور المشروع.
لكن كلما زاد الاستخدام، زادت قيمة:
- Semantic versioning
- Migration guides
- Deprecation periods
- Changelogs
- Backward compatibility
المستخدم يحتاج أن يثق أن upgrade لن يحول صباحه إلى debugging session.
الثقة قد تكون feature أهم من feature جديدة.
Issues ليست Support Inbox فقط
GitHub Issues بالنسبة لي مصدر Product Research ممتاز.
خصوصاً الأسئلة المتكررة.
إذا ثلاثة أشخاص سألوا نفس السؤال، ربما المشكلة ليست أنهم لم يقرأوا documentation.
ربما documentation نفسها غير واضحة.
إذا مستخدمون كثيرون يطلبون نفس workaround، ربما هناك abstraction ناقصة.
ولو كل شخص يخطئ في نفس config، ربما الـAPI نفسه يحتاج إعادة تفكير.
أفضل feedback ليس دائماً:
"Great project!"
أحياناً أفضل feedback هو issue مزعج يكشف مشكلة تصميم حقيقية.
قل "لا" أكثر مما تقول "نعم"
هذه واحدة من أصعب الحاجات في الـopen source.
شخص أخذ وقتاً وفتح issue أو feature request.
طبيعي أن تريد مساعدته.
لكن كل feature تدخل المشروع تصبح شيئاً ستحتاج إلى:
- صيانته
- اختباره
- توثيقه
- الحفاظ على backward compatibility له
- الرد على مشاكله
ميزة مدتها ساعتان قد تصبح التزاماً لسنوات.
لذلك السؤال ليس فقط:
هل أستطيع بناءها؟
بل:
هل يجب أن تكون جزءاً من هذا المشروع أصلاً؟
أحياناً أفضل إجابة feature request هي أن المشكلة خارج scope المشروع.
وده ليس تجاهلاً للمستخدم.
ده حماية للمنتج.
Distribution جزء من Engineering
كنت لفترة طويلة مقتنعاً أن:
لو المشروع جيد، الناس ستجده.
هذا ليس صحيحاً بالكامل.
هناك آلاف المشاريع الجيدة التي لا يعرف أحد أنها موجودة.
ولذلك distribution ليس شيئاً نخجل منه كمطورين.
وجود package على Packagist أو npm أو pkg.go.dev مهم.
وجود documentation يمكن لمحركات البحث قراءتها مهم.
وجود description واضح في GitHub مهم.
أن يظهر المشروع في relevant directories أو Awesome Lists مفيد.
أن تكتب مقالاً حقيقياً عن المشكلة التي أدى المشروع لحلها مفيد.
وأن تربطه بمشاريع ذات علاقة عندما يكون الربط منطقياً مفيد.
المشكلة ليست في التسويق.
المشكلة في التسويق الذي لا يقدم قيمة.
النجوم ليست الـMetric الوحيدة
GitHub stars لطيفة.
وأنا أيضاً أحب رؤيتها تزيد.
لكنها لا تعني بالضرورة أن المشروع يُستخدم.
هناك projects عليها آلاف النجوم ولم يدخلها معظم من ضغط Star في مشروع واحد.
بالنسبة لي توجد إشارات أخرى أهم:
هل الناس ترجع للـdocumentation؟
هل هناك installations؟
هل هناك contributors؟
هل issues تحولت من "كيف أثبت المشروع؟" إلى أسئلة استخدام أعمق؟
هل الناس تبني integrations لم أطلبها؟
هل شخص يشرح المشروع لشخص آخر بدون تدخلي؟
هذه علامات أن المشروع بدأ يتحول من code repository إلى شيء له مستخدمون فعليون.
المجتمع يبدأ من أول شخص
كلمة Community أحياناً تجعلنا نفكر أننا نحتاج Discord فيه آلاف الأشخاص.
لكن community يمكن أن تبدأ بمستخدم واحد رجع للمشروع مرتين.
ثم شخص فتح pull request.
ثم شخص أصلح typo في documentation.
ثم شخص أجاب على issue قبل أن تصل أنت إليه.
هذه لحظات صغيرة، لكنها مهمة جداً.
الناس تساهم في المشاريع التي تشعر أن مساهمتها مرحب بها.
Contributor guide واضح.
Issues محددة.
رد محترم.
Architecture يمكن فهمها.
كل ذلك مهم أكثر من وضع badge مكتوب عليه "community driven".
المشروع المفتوح المصدر عقد طويل المدى
إنشاء repository مجاني.
صيانة repository ليست مجانية.
تأخذ وقتاً.
وتأخذ تركيزاً.
وأحياناً تتحول إلى مسؤولية نفسية أيضاً عندما يكون لديك عشرات issues وأنت تعمل أصلاً على منتجات أخرى.
وده سبب آخر جعلني أفكر مؤخراً في الـecosystem بدلاً من مجرد زيادة عدد repositories.
ليس الهدف أن أملك أكبر عدد ممكن من المشاريع.
الهدف أن تكون المشاريع التي أحتفظ بها جيدة، واضحة، ولها سبب للاستمرار.
أحياناً دمج مشروعين أفضل من صيانة الاثنين.
أحياناً archive أفضل من rewrite.
وأحياناً عدم بناء المشروع من البداية هو القرار الصحيح.
قبل أن تنشر مشروعك القادم
اليوم، لو بنيت مشروع open source جديد، أحب أن أراجع مجموعة أسئلة قبل أن أقول إنه جاهز:
هل أستطيع شرح المشكلة في جملة؟
هل استخدمته أنا فعلاً؟
هل README يشرح القيمة قبل installation؟
هل يستطيع شخص الوصول لأول نتيجة بسرعة؟
هل هناك default جيد؟
هل documentation مبنية حول ما يريد المستخدم فعله؟
هل الـversions المدعومة واضحة؟
هل أنا مستعد لصيانة هذا الـAPI؟
هل المشروع مختلف فعلاً عن شيء موجود بالفعل؟
وهل سأكون سعيداً إذا اضطررت لصيانة هذا المشروع بعد ثلاث سنوات؟
السؤال الأخير بالتحديد مهم جداً.
لأن النجاح أحياناً هو أن يستخدم الناس مشروعك.
وحينها ستحتاج أن تعيش مع القرارات التي اتخذتها في أول أسبوع.
في النهاية
أفضل مشاريع الـopen source بالنسبة لي ليست التي تحتوي على أكبر كمية code.
هي التي تختفي تقريباً أثناء الاستخدام.
تحل المشكلة.
تتصرف كما تتوقع.
تشرح نفسها جيداً.
ولا تجبرك على التفكير فيها أكثر من اللازم.
لو أردت أن يستخدم الناس مشروعك، لا تبدأ بمحاولة إقناعهم بأن الكود رائع.
ابدأ بجعل حياتهم أسهل.
حل مشكلة حقيقية.
اجعل أول تجربة بسيطة.
اكتب documentation تحترم وقت المطور.
حافظ على ثقته عندما يكبر المشروع.
واستمع لما يحدث بعد أن يخرج الكود من جهازك ويبدأ العمل داخل مشاريع لا تعرف عنها شيئاً.
لأن في اللحظة دي بالذات، مشروعك لم يعد مجرد repository على GitHub.
أصبح منتجاً.
التعليقات (0)