> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# علاقات المطورين DevRel: ماذا يفعل الفريق وكيف يقاس؟
- URL: https://arabroot.io/articles/علاقات-المطورين-devrel/
- Published: 2026-10-25T05:24:00.000Z
- Updated: 2026-10-25T13:19:46.000Z
- Description: ما الذي يفعله فريق علاقات المطورين في التوثيق والمحتوى والمجتمع، وأين يوضع في الشركة، وكيف يقاس عمله بأمثلة GitLab وHacktoberfest.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, التسويق والمبيعات, الفرق والمنتج, DevRel

في المقال السابق من هذه السلسلة وصلنا إلى أن المطور يتعلم من التوثيق أولاً، ويثق في رأي مطور آخر أكثر من رأي الشركة، ويجرب المنتج قبل أن يوصي به. والسؤال الذي يأتي بعد ذلك مباشرة: من في الشركة يكتب هذا التوثيق ويجيب في المنتدى ويتحدث في المؤتمرات ويحمل ملاحظات المطورين إلى فريق المنتج؟ في الشركات التقنية هذا عمل فريق اسمه علاقات المطورين Developer Relations، واختصاراً DevRel، وهو فريق يصعب على كثير من الشركات أن تحدد مكانه وطريقة قياسه، فبعضها يضعه في التسويق ويحاسبه بعدد العملاء المحتملين Leads، وبعضها يضعه في الهندسة ثم لا يعرف ماذا ينتج.

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

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

[![](https://arabroot.io/content/images/2026/10/developer-marketing-cover-cover.webp)دليلالتسويق للمطورين Developer Marketing: لماذا يتجاهلون الإعلانات؟لماذا لا يقتنع المطور بالإعلان، وما الذي يجعله يجرب أداة ويوصي بشرائها، بأرقام استبيان Stack Overflow 2025 وأمثلة حقيقية.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D9%82-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-developer-marketing/)

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

- تعريف DevRel، والاتجاهين اللذين يعمل فيهما الفريق.
- أعمال الفريق الأربعة، مع مثال حقيقي لكل منها.
- أين يوضع الفريق في الشركة، وماذا فعلت GitLab بفريقها.
- كيف يقاس عمل الفريق، بمؤشرات GitLab المنشورة.
- ماذا حدث عندما كافأ برنامج Hacktoberfest العدد بدل الجودة.
- خطة DevRel بسيطة لشركة ناشئة ليس عندها فريق.

## ما هو DevRel؟

أوضح تعريف وجدناه منشوراً هو تعريف GitLab في [دليلها الداخلي المفتوح](https://handbook.gitlab.com/handbook/marketing/developer-relations/?ref=arabroot.io)، حيث يعمل الفريق عند تقاطع التقنية والمجتمع والمناصرة Advocacy، ويصفه الدليل بأنه صوت الشركة وأذنها في عالم التقنية. والكلمة المهمة هنا «وأذنها»، فالفريق لا ينقل رسالة الشركة إلى المطورين فقط، وإنما ينقل ما يقوله المطورون إلى الشركة أيضاً، والشكل التالي يبين الاتجاهين:

![فريق DevRel في المنتصف بين الشركة بفرق المنتج والهندسة والتسويق على جهة، ومجتمع المطورين على الجهة الأخرى. من الشركة إلى المطورين يخرج التوثيق والمحتوى والفعاليات، ومن المطورين إلى الشركة تعود الملاحظات والمشكلات Issues والمساهمات Contributions](https://arabroot.io/content/images/2026/10/devrel-01-devrel-bridge.webp)

صوت الشركة وأذنها: ما يخرج إلى المطورين وما يعود منهم

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

## ماذا يفعل الفريق؟

تختلف أسماء الأدوار من شركة لأخرى، ولكن عمل الفريق يقع غالباً في أربعة أجزاء:

| العمل                                      | ماذا يشمل                                                                    | مثال حقيقي                                                                                                                                                                                                                                                                                                        |
| ------------------------------------------ | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| المناصرة Developer Advocacy                | المحتوى التقني، والمحاضرات، ومقاطع الفيديو، والأمثلة البرمجية                | فريق Developer Advocacy في GitLab، وله [طريقة عمل منشورة](https://handbook.gitlab.com/handbook/marketing/product-and-technical-marketing/developer-advocacy/community-response/?ref=arabroot.io) للرد على المجتمع عند الإعلانات المهمة، تبدأ بإبلاغ الفريق مبكراً وتجهيز الأسئلة المتوقعة وردودها مع أصحاب القرار |
| تجربة المطور Developer Experience والتوثيق | صفحة البداية، ومرجع الـ API، والأمثلة، وإزالة العوائق من أول تجربة           | [صفحة البداية في Stripe](https://docs.stripe.com/payments/quickstart?ref=arabroot.io)، وهي موضوع المقال القادم                                                                                                                                                                                                    |
| المجتمع Community                          | المنتدى أو قناة المحادثة، والإجابة عن الأسئلة، ورعاية المساهمين Contributors | تذكر GitLab أنها تتعامل مع أكثر من 3000 مطور شهرياً على GitLab.com، وتصلها أكثر من 250 مساهمة كل شهر                                                                                                                                                                                                              |
| البرامج Programs                           | برامج السفراء، وبرامج التعليم، والفعاليات والمسابقات                         | [Google Developer Experts](https://developers.google.com/community/experts?ref=arabroot.io)، و[AWS Heroes](https://aws.amazon.com/developer/community/heroes/?ref=arabroot.io)، و[GitHub Stars](https://stars.github.com/?ref=arabroot.io)                                                                        |

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

## أين يوضع الفريق في الشركة؟

لا توجد إجابة واحدة، ولكل مكان ثمنه:

- **تحت التسويق Marketing**: يحصل الفريق على ميزانية الفعاليات والمحتوى، ولكنه يتعرض للمحاسبة بعدد العملاء المحتملين Leads، فيتحول المحتوى التقني إلى إعلان ويفقد ثقة المطورين.
- **تحت المنتج أو الهندسة Product, Engineering**: يقترب الفريق من الكود والقرار، ويصل صوت المطورين إلى من يبني المنتج مباشرة، ولكنه قد يفقد الوصول إلى الجمهور لأن هذه الفرق لا تقيس الوصول أصلاً.
- **فريق مستقل**: يحمي الفريق من الطرفين، ولكنه يحتاج إلى مدير يدافع عن ميزانيته بأرقام يفهمها مجلس الإدارة.

وأوضح مثال منشور هو GitLab نفسها، فالدليل يذكر أن فريق Developer Relations قسم إلى فريقين: فريق Developer Advocacy انتقل إلى التسويق التقني وتسويق المنتج Product and Technical Marketing، وفريق المساهمات والمجتمع Co-Create and Community Engineering انتقل إلى تسويق النمو Growth Marketing، والدليل نفسه ما زال في طور النقل وقت كتابة هذا المقال. أي أن شركة كبيرة لها سنوات في هذا العمل ما زالت تعيد ترتيب مكان الفريق، فلا تقلق إذا لم تجد المكان المثالي من أول مرة، والأهم أن تحدد ما الذي سوف يقاس به الفريق قبل أن تحدد لمن يتبع.

## كيف يقاس عمل الفريق؟

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

![سلم من خمس درجات لقياس DevRel: النشاط Activity مثل المقالات والمحاضرات، ثم الوصول Reach مثل المشاهدات، ثم التفاعل Engagement مثل الأعضاء النشطين والأسئلة المجابة، ثم المساهمة Contribution مثل المساهمين ومساهماتهم المقبولة، ثم أثر العمل Business مثل التفعيل والعملاء المساهمين، مع أمثلة من مؤشرات GitLab على كل درجة](https://arabroot.io/content/images/2026/10/devrel-02-metrics-ladder.webp)

كلما صعدت درجة صار القياس أصعب وصار الرقم أقرب إلى ما يهم الشركة

وتنشر GitLab [مؤشرات أداء فريقها](https://handbook.gitlab.com/handbook/marketing/developer-relations/performance-indicators/?ref=arabroot.io) علناً، وهي مثال جيد لأن كل مؤشر فيها يقع على درجة من هذا السلم:

| المؤشر                                        | تعريفه بحسب GitLab                                                                                                                                           | الدرجة    |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------- |
| Developer Relations Monthly Outreach          | مشاهدات مقالات الفريق ومقاطع الفيديو التي ينشرها ووصول منشوراته في وسائل التواصل                                                                             | الوصول    |
| Active Community Members                      | عدد من ينشرون أو يعلقون أو يتفاعلون مع محتوى GitLab في عدة قنوات                                                                                             | التفاعل   |
| Unique Wider Community Contributors per Month | عدد المساهمين من خارج الشركة الذين قبلت لهم مساهمة في الشهر، ويحسب كل مساهم مرة واحدة. والهدف أكثر من 200 مساهم، وأعلى رقم وصلوا إليه 184 في يناير 2025      | المساهمة  |
| Wider Community merged MRs per release        | عدد طلبات الدمج Merge Requests المقبولة من المجتمع في كل إصدار                                                                                               | المساهمة  |
| MRARR                                         | عدد طلبات الدمج من العملاء مضروباً في الإيراد السنوي Annual Recurring Revenue لكل عميل، ووحدته MR$، والفكرة أن العميل الكبير الذي يساهم في الكود أقرب للبقاء | أثر العمل |

ولاحظ أن MRARR مؤشر غريب للوهلة الأولى، ولكنه يربط عمل المجتمع بالإيراد بطريقة يفهمها المدير المالي، وهذا ما تحتاجه عندما تدافع عن ميزانية الفريق. ولاحظ أيضاً أن الصفحة نفسها تصف بعض المؤشرات بأنها طريقة جديدة في القياس وأن الفريق ما زال يتعلم أفضل طريقة لتتبعها، وهذا طبيعي، فقياس DevRel صعب حتى على شركة بحجم GitLab التي بلغت إيراداتها 955.2 مليون دولار في السنة المالية 2026 بحسب [إعلان نتائجها](https://s204.q4cdn.com/984476563/files/doc%5Ffinancials/2026/q4/Gitlab-4Q26-Earnings-Press-Release.pdf?ref=arabroot.io).

⚠️

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

## عندما كافأ البرنامج العدد بدل الجودة

برنامج Hacktoberfest من أشهر برامج DevRel، وهو شهر في أكتوبر من كل سنة للمساهمة في المصادر المفتوحة ترعاه DigitalOcean، وكانت المكافأة فيه قميصاً لمن يرسل عدداً معيناً من طلبات الدمج Pull Requests إلى أي مستودع مفتوح المصدر.

📌

في أكتوبر 2020 انتشر مقطع فيديو يشرح كيف ترسل طلب دمج سريعاً، فأرسل آلاف المشاركين تعديلات بلا قيمة إلى مستودعات لم يطلب أصحابها المشاركة أصلاً حتى يحصلوا على القميص، وغضب المشرفون Maintainers على هذه المشاريع. وبحسب [دراسة حالة](https://developerrelations.com/case-studies/overcoming-hacktoberfest-spam?ref=arabroot.io) شاركت فيها مسؤولة البرنامج في DigitalOcean، تشكل فريق للأزمة في الأيام الأولى من الشهر، وتغيرت القواعد: صار المشروع يشارك فقط إذا أضاف المشرف وسم `hacktoberfest` إلى مستودعه، ولا يحسب طلب الدمج إلا إذا وسمه المشرف بأنه مقبول `hacktoberfest-accepted`، ثم في 2021 خفضت مدة المراجعة من 14 يوماً إلى 7 أيام واستبعدت الطلبات الموسومة بأنها Spam. وكان عدد المشاركين في 2020 قرابة 170 ألفاً.

والدرس هنا يتجاوز Hacktoberfest: البرنامج كافأ عدد الطلبات، فحصل على طلبات كثيرة، ودفع ثمنها المشرفون الذين يفترض أن البرنامج يخدمهم. وفي نسخة 2026 تذكر [صفحة البرنامج](https://hacktoberfest.com/?ref=arabroot.io) أن طلبات الدمج لم تعد تحسب في المكافآت أصلاً، وأن المشاركة صارت بالانضمام إلى الفعاليات وجمع ملصقات افتراضية. لذلك عندما تصمم برنامجاً أو مسابقة، اسأل نفسك: ما أرخص طريقة لتحقيق الرقم الذي أكافئ عليه؟ فإذا كانت الطريقة تضر مجتمعك فغير الرقم قبل أن تبدأ.

## خطة DevRel بسيطة لشركة ناشئة

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

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

وأما مكان المجتمع، فابدأ بما يستخدمه جمهورك أصلاً، مثل نقاشات GitHub Discussions إذا كان المنتج مفتوح المصدر، وإذا أردت قناة محادثة على سيرفرك فقد شرحنا [تثبيت Mattermost](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-mattermost-%D9%88%D8%AA%D8%B1%D9%82%D9%8A%D8%AA%D9%87/)، ولخدمة العملاء والأسئلة من الموقع [تثبيت Chatwoot](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-chatwoot-%D9%84%D8%AE%D8%AF%D9%85%D8%A9-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D8%A7%D8%A1/). ولا تقم بفتح خمس قنوات في نفس الوقت، والسبب أن القناة الفارغة تقول للزائر إن لا أحد هنا.

## أخطاء شائعة

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

## الخلاصة

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

وفي المقال القادم بإذن الله سوف نتحدث عن أهم ما ينتجه هذا الفريق، وهو صفحة البداية Quickstart. والمقالات المرتبطة:

[![](https://arabroot.io/content/images/2026/10/docs-as-marketing-cover-cover.webp)دليلالتوثيق أداة تسويق: صفحة البداية Quickstart التي تقنعكيف تبني صفحة بداية Quickstart توصل المطور إلى أول نتيجة في دقائق، بما تفعله صفحات Stripe وTwilio وSupabase وقالب تبدأ منه.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D8%AF%D8%A7%D8%A9-%D8%AA%D8%B3%D9%88%D9%8A%D9%82-%D8%B5%D9%81%D8%AD%D8%A9-%D8%A7%D9%84%D8%A8%D8%AF%D8%A7%D9%8A%D8%A9-quickstart/)[![](https://arabroot.io/content/images/2026/10/oss-growth-cover-cover.webp)دليلالمصادر المفتوحة قناة للنمو: من المستخدم إلى العميلكيف تحول الشركات مستخدمي مشروعها المفتوح إلى عملاء، ونماذج الربح من الخدمة المستضافة إلى Open Core، ودروس تغيير الرخص بعد النمو.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B5%D8%A7%D8%AF%D8%B1-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D9%82%D9%86%D8%A7%D8%A9-%D9%84%D9%84%D9%86%D9%85%D9%88/)[![](https://arabroot.io/content/images/2026/10/marketing-plan-cover-cover.webp)دليلخطة التسويق Marketing Plan لشركة تقنية ناشئةكيف تكتب خطة تسويق في صفحة واحدة لتسعين يوماً، من هدف مرتبط بالإيراد إلى القنوات والميزانية والمراجعة، مع قالب جاهز.](https://arabroot.io/articles/%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D9%82-marketing-plan-%D9%84%D8%B4%D8%B1%D9%83%D8%A9-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D9%86%D8%A7%D8%B4%D8%A6%D8%A9/)

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

- أكتوبر 2026: كتابة المقال، ومراجعة دليل GitLab ومؤشرات أداء فريقها وصفحات برامج Google Developer Experts وAWS Heroes وGitHub Stars وHacktoberfest في 25 أكتوبر 2026.