المصادر المفتوحة قناة للنمو: من المستخدم إلى العميل

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

المواضيع في سلسلة التسويق للمطورين DevRel:

• التسويق للمطورين Developer Marketing: لماذا يتجاهلون الإعلانات؟
• علاقات المطورين DevRel: ماذا يفعل الفريق وكيف يقاس؟
• التوثيق أداة تسويق: صفحة البداية Quickstart التي تقنع
• المصادر المفتوحة قناة للنمو: من المستخدم إلى العميل (الموضوع الحالي)

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

دليلما هي البرمجيات مفتوحة المصدر؟ القصة وأشهر الرخصكيف بدأت البرمجيات الحرة والمفتوحة، وما الفرق بين الحر والمجاني، وكيف تعرف ما تسمح به رخصة أي مشروع قبل أن تبني عليه.دليللماذا تساهم الشركات الكبيرة في المصادر المفتوحة، ولماذا نغيب نحن عنها؟موظفو Intel وGoogle وRed Hat يكتبون جزءاً كبيراً من نواة Linux وKubernetes، ولذلك أسباب اقتصادية مكتوبة. أعرض الأدلة والأسباب وأرقام منطقتنا، ثم رأيي فيما يكلفنا غيابنا وما تستطيع شركتك أن تبدأ به هذا الربع.دليلمن يدير المشروع مفتوح المصدر؟ نماذج الحوكمة Governanceمن يقرر في مشروع يساهم فيه آلاف الأشخاص، ومن يستطيع تغيير رخصته، وما الذي تفحصه قبل أن تعتمد على أي مشروع.

وفي هذا المقال سوف نتناول:

• القمع من النجمة على GitHub إلى العميل الذي يدفع، وما يقاس في كل خطوة.
• أرقام عامة لمشاريع تجارية مفتوحة المصدر، وما تقوله وما لا تقوله.
• نماذج الربح: الخدمة المستضافة، وOpen Core، والرخص المتاحة المصدر Source-available.
• القاعدة التي تستخدمها GitLab لتقرر ما هو مجاني وما هو مدفوع.
• ماذا حدث عندما غيرت HashiCorp وRedis وElastic رخصها بعد أن كبرت.
• هل تفتح كود منتجك أصلاً؟ أسئلة قبل القرار.

من النجمة إلى العميل

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

1. الاكتشاف Discover: المطور يجد المستودع على GitHub أو في نتائج البحث، والمقياس الشائع هنا عدد النجوم Stars، وهو مقياس للاهتمام وليس للاستخدام.
2. التشغيل Run: يثبت المنتج على سيرفره، والمقياس المتاح عدد مرات تنزيل الـ Image من Docker Hub، وهو أقرب للاستخدام ولكنه يحسب كل تنزيل في خط CI/CD أيضاً.
3. الاستخدام المستمر Retain: المنتج يبقى يعمل أسابيع وأشهراً، ولا تعرف ذلك إلا إذا أرسل المنتج بيانات استخدام Telemetry، وهذا يجب أن يكون اختيارياً وموثقاً كما سيأتي.
4. الحاجة Need: الفريق يكبر فيحتاج ما لا يحتاجه الفرد: الدخول الموحد SSO، والصلاحيات، وسجل التدقيق Audit Log، والتوافرية العالية High Availability، والدعم.
5. الدفع Pay: يشتري ترخيص Enterprise لنسخته على سيرفره، أو ينتقل إلى الخدمة المستضافة Cloud لأنه لا يريد إدارة السيرفر.

أرقام عامة، وما لا تقوله

جمعنا في 25 أكتوبر 2026 أرقاماً منشورة لعدد من الشركات التي بنت أعمالها على مشروع مفتوح، من واجهة GitHub العامة ومن Docker Hub ومن ملفات الرخص في مستودعاتها:

ولاحظ هنا ثلاثة أشياء قبل أن تبني خطتك على أرقام مثل هذه:

• النجوم ليست مستخدمين: النجمة تضغط مرة وتبقى إلى الأبد، ولا تقول هل شغل صاحبها المنتج أصلاً.
• التنزيلات ليست نسخاً نشطة: كل خط CI/CD يبني Container جديداً يحسب تنزيلاً، فمئات ملايين التنزيلات قد تأتي من آلاف المستخدمين فقط.
• «مفتوح المصدر» ليست صفة واحدة: n8n وSentry ينشران الكود ولكن رخصتيهما ليستا من الرخص التي توافق عليها مبادرة المصادر المفتوحة OSI، فهي رخص متاحة المصدر Source-available، وهذا يهم عميلك إذا كانت سياسته تشترط رخصة مفتوحة.

كيف تربح هذه الشركات؟

هناك ثلاثة نماذج رئيسية، وأغلب الشركات تجمع بين اثنين منها، والشكل التالي يقارنها:

• الخدمة المستضافة Hosted Cloud: الكود كله مفتوح، والشركة تبيع التشغيل والتحديث والنسخ الاحتياطي، ومثاله Supabase وPlausible Analytics الذي ينشر كوده برخصة AGPL-3.0 ويبيع اشتراك الخدمة المستضافة. وهذا يعمل عندما يكون تشغيل المنتج صعباً بما يكفي ليدفع الناس مقابل ألا يفعلوه بأنفسهم، وقد رأيت مثلاً في دليل تثبيت Supabase كم خدمة تحتاج لتشغيله على سيرفرك.
• النواة المفتوحة Open Core: الأساس مفتوح، وميزات معينة مدفوعة. والسؤال الصعب هنا هو أين تضع الخط، وسوف نرى بعد قليل قاعدة GitLab.
• الرخص المتاحة المصدر Source-available: الكود منشور ويمكن تشغيله، ولكن الرخصة تمنع استخدامه لمنافسة الشركة. ومثاله Functional Source License التي تستخدمها Sentry، وهي تسمح بكل شيء تقريباً عدا ما يضر الشركة المنتجة، ثم يتحول كل إصدار إلى Apache 2.0 أو MIT بعد سنتين من نشره.

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

أين تضع الخط بين المجاني والمدفوع؟

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

ولنأخذ مثالاً بمنتج افتراضي لإدارة السجلات Logs:

والسبب في نجاح هذه القاعدة أنها لا تحرم المطور من شيء يحتاجه ليقتنع، فهو الذي يجرب ويوصي، وتجعل المدفوع هو ما تحتاجه المؤسسة عندما تكبر، فيدفع من يملك الميزانية مقابل ما يهمه هو.

عندما تغير الشركة الرخصة بعد أن تكبر

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

والدرس للشركة الناشئة ليس «لا تغير رخصتك أبداً»، وإنما: اختر نموذج الربح ورخصته من أول يوم، لأن تغيير الرخصة بعد أن يبني المجتمع عليها يحول بعض المساهمين إلى منافسين، والنسخة المنشقة Fork قد تحصل على دعم شركات أكبر منك كما حدث مع Valkey وOpenTofu. فإذا كنت تخشى أن يبيع مزود سحابي منتجك، فرخصة مثل AGPL أو FSL من البداية أوضح لمجتمعك من رخصة متساهلة تغيرها لاحقاً.

كيف تعرف عدد من يستخدم منتجك؟

ذكرنا أن النجوم والتنزيلات لا تقول لك عدد النسخ النشطة، والطريقة الوحيدة لمعرفة ذلك أن يرسل المنتج بيانات استخدام Telemetry، وهنا يجب أن تكون حذراً لأن المطور الذي يكتشف أن المنتج يرسل بيانات دون علمه يفقد ثقته فيه ويكتب عن ذلك علناً. ولذلك:

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

وإذا كان عملاؤك في السعودية فتذكر أن بيانات الاستخدام التي تربط بشخص محدد تخضع لنظام حماية البيانات الشخصية PDPL، فالأسلم أن تكون مجمعة لا تعرف الشخص من الأساس.

هل تفتح كود منتجك أصلاً؟

المصادر المفتوحة قناة قوية، ولكنها ليست مناسبة لكل منتج، وقبل القرار أجب عن هذه الأسئلة:

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

أخطاء شائعة

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

الخلاصة

• المصادر المفتوحة قناة تصل بها إلى المطور الذي يجرب قبل أن يقتنع، والبيع يأتي عندما يحتاج الفريق ما لا يحتاجه الفرد.
• النجوم والتنزيلات تقيس الاهتمام، وعدد النسخ النشطة يحتاج بيانات استخدام اختيارية وموثقة.
• النماذج الرئيسية ثلاثة: الخدمة المستضافة، والنواة المفتوحة Open Core، والرخص المتاحة المصدر مثل FSL.
• قاعدة GitLab: ما يهتم به المطور الفرد مفتوح، وما يهتم به المدير والتنفيذي مدفوع.
• تغيير الرخصة بعد النمو أنتج OpenTofu وValkey وOpenSearch، فاختر رخصتك ونموذجك من أول يوم.

وبهذا نكون قد أنهينا سلسلة التسويق للمطورين. والمقالات المرتبطة:

دليلالتسويق للمطورين Developer Marketing: لماذا يتجاهلون الإعلانات؟لماذا لا يقتنع المطور بالإعلان، وما الذي يجعله يجرب أداة ويوصي بشرائها، بأرقام استبيان Stack Overflow 2025 وأمثلة حقيقية.دليلعلاقات المطورين DevRel: ماذا يفعل الفريق وكيف يقاس؟ما الذي يفعله فريق علاقات المطورين في التوثيق والمحتوى والمجتمع، وأين يوضع في الشركة، وكيف يقاس عمله بأمثلة GitLab وHacktoberfest.دليلالتوثيق أداة تسويق: صفحة البداية Quickstart التي تقنعكيف تبني صفحة بداية Quickstart توصل المطور إلى أول نتيجة في دقائق، بما تفعله صفحات Stripe وTwilio وSupabase وقالب تبدأ منه.دليلالمصادر المفتوحة في الشركة الناشئة: ماذا تستضيف بنفسك ومتى؟دليل للمدير التقني في الشركة الناشئة يبين ما تستضيفه بنفسك من اليوم الأول، وما تتركه للخدمات المدارة حتى يكبر الفريق.دليلميزانية التسويق وتكلفة العميل CAC والعائد ROIكيف تحسب تكلفة اكتساب العميل وقيمته وفترة الاسترداد والعائد لكل قناة، وكيف تحدد حجم الميزانية من هدفك لا من نسب الشركات الكبيرة.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وجمع أرقام النجوم من واجهة GitHub والتنزيلات من Docker Hub ورخص المستودعات في 25 أكتوبر 2026.