كانت شركتنا شبحاً للمطورين: كيف أنقذنا المصدر المفتوح من جحيم تجاهل المواهب؟

يا هلا بيكم يا جماعة الخير، معكم أبو عمر.

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

بعد يومين، وصلني الرد من أحمد. رسالة قصيرة ومؤدبة لكنها كانت زي الكف على وجهي: “شكراً لاهتمامكم، لكن بعد البحث عن شركتكم، لم أجد أي معلومات تقنية أو مشاريع تثير اهتمامي. أتمنى لكم التوفيق”.

قعدت صافن في الشاشة. “لم يجد أي معلومات تقنية؟”. إحنا بنبني أنظمة معقدة وبنستخدم أحدث التقنيات! كيف يعني ما في إشي يثير اهتمامه؟ وقتها، فهمت المشكلة. أحمد ما كان غلطان. إحنا كنا بنشتغل في الظل، زي الأشباح. بالنسبة للعالم الخارجي، وخاصة مجتمع المطورين، شركتنا كانت مجرد اسم في سجل تجاري، صندوق أسود ما حدا بيعرف شو جواته. كانت هاي اللحظة اللي “ولّعت” فيها لمبة في راسي: سمعتنا التقنية في الحضيض، ولازم نعمل إشي، وبسرعة.

تشخيص المشكلة: لماذا كنا شركة “شبح” في نظر المطورين؟

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

1. الاعتماد الكلي على طرق التوظيف التقليدية

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

2. غياب “العلامة التجارية التقنية” (Employer/Tech Branding)

شو يعني علامة تجارية تقنية؟ ببساطة، هي سمعة شركتك في أوساط المطورين والمهندسين. هل مهندسينك بيكتبوا مقالات تقنية؟ هل بتشاركوا في مؤتمرات؟ هل عندكم أي مشاريع مفتوحة المصدر؟ هل اسم شركتك بيظهر لما مطور يبحث عن حل لمشكلة معينة على GitHub أو Stack Overflow؟

جوابنا على كل هاي الأسئلة كان “لأ”. كنا مجرد مستهلكين للتقنية، مش مساهمين أو مشاركين فيها. وهذا خطأ قاتل في عالم اليوم.

3. المنافسة الشرسة من الشركات الكبرى والناشئة المعروفة

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

الوصفة السحرية: المصدر المفتوح كأداة لبناء الهوية والثقة

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

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

كيف بدأنا؟ الخطوات الأولى العملية

البداية دايماً صعبة، والكل كان خايف. “شو بدنا ننشر؟ كودنا مش مثالي!”، “ما عنا وقت لهيك قصص!”. هون بيجي دور الخبرة والقيادة. أقنعتهم بالمبدأ التالي: “ابدأ صغيراً، لكن ابدأ الآن”.

  1. تحديد “المرشح” الأول: بحثنا في أدواتنا الداخلية اللي طورناها لتسهيل شغلنا. لقينا أداة صغيرة كتبناها بـ (Node.js) عبارة عن CLI tool بسيط بيعمل validation لملفات الترجمة (i18n files) قبل ما ندمجها في المشروع الرئيسي عشان نتأكد إنه كل الـ keys موجودة في كل اللغات. كانت أداة مفيدة جداً إلنا.
  2. التنظيف والتوثيق (The Hard Part): هاي أهم خطوة. أخذنا الأداة، نظفنا الكود، أضفنا تعليقات واضحة، وكتبنا ملف README.md مفصل جداً بيشرح كيف تثبتها وكيف تستخدمها مع أمثلة. التوثيق الجيد أهم من الكود نفسه في البداية.
  3. النشر على GitHub و NPM: أنشأنا حساب لمنظمتنا (Organization) على GitHub، ورفعنا المشروع. ثم نشرناه كـ package على NPM عشان أي حدا يقدر ينزله بسهولة.

نصيحة من أبو عمر: لا تنتظر حتى يصبح الكود “مثالياً”. لا يوجد كود مثالي. انشر النسخة الأولى (v0.1.0)، واحصل على آراء المجتمع، وقم بتحسينها. “Done is better than perfect”.

للتوضيح، لم يكن المشروع معقداً. كان شيئاً بسيطاً مثل هذا الهيكل:

/my-i18n-validator
├── /bin
│   └── validate-i18n
├── /lib
│   └── validator.js
├── package.json
└── README.md

والأمر الأساسي في package.json الذي يجعله أداة CLI قابلة للتنفيذ:

{
  "name": "@our-company/i18n-validator",
  "version": "0.1.0",
  "description": "A simple CLI to validate i18n JSON files.",
  "main": "lib/validator.js",
  "bin": {
    "validate-i18n": "./bin/validate-i18n"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/our-company/i18n-validator.git"
  },
  "license": "MIT"
}

هذا كل ما لزم الأمر للبدء. مجرد خطوة رمزية، لكنها كانت بداية كل شيء.

الحصاد: كيف تغيرت اللعبة بعد المصدر المفتوح؟

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

1. تحولنا إلى مغناطيس للمواهب (ببطء ولكن بثبات)

بعد حوالي شهرين، فتح أحدهم Issue على GitHub يقترح فيها تحسيناً. بعد فترة قصيرة، جاء أول Pull Request من مطور من الهند! احتفلنا في الشركة وكأنه فوز في كأس العالم. بدأ اسم شركتنا يظهر في أماكن جديدة.

الأثر الأكبر كان في عملية التوظيف. بدأنا نضع رابط حسابنا على GitHub في إعلانات الوظائف. تغيرت نوعية المتقدمين بشكل جذري. صار يجيك ناس بحكولك في المقابلة: “شفت مشروعكم تبع الـ i18n، فكرته حلوة، بس ليش ما عملتوا كذا وكذا؟”. النقاش صار تقنياً وحقيقياً. صار المتقدم يختبرنا بقدر ما إحنا بنختبره.

2. تحسين جودة الكود والثقافة الداخلية

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

3. بناء جسور الثقة مع المجتمع التقني

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

الخلاصة: من شبح إلى شريك في المجتمع 💡

قصة “أحمد” كانت نقطة التحول. اليوم، أحمد لا يعمل معنا (وجد وظيفة أحلامه في مكان آخر)، لكني ممتن له لأنه فتح أعيننا على حقيقة مؤلمة. تحولنا من شركة تنتظر المواهب أن تجدها بالصدفة، إلى شركة تبني منارة تقنية تجذب السفن من بعيد.

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

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

بالتوفيق يا جماعة الخير.

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

الحوسبة السحابية

كانت خوادمنا تستهلك وقتنا ومواردنا: كيف أنقذتنا ‘الحوسبة بدون خوادم’ (Serverless) من جحيم إدارة البنية التحتية؟

أنا أبو عمر، مبرمج فلسطيني، وأروي لكم قصتنا مع إدارة الخوادم التي كادت أن تقتل مشروعنا. اكتشفوا كيف حولت الحوسبة بدون خوادم (Serverless) هذا الكابوس...

6 مايو، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

كان طلب واحد يُجمّد النظام بأكمله: كيف أنقذتنا ‘طوابير الرسائل’ من جحيم المهام المتزامنة؟

أشارككم قصة حقيقية عن يوم كاد فيه طلب واحد أن يُسقط نظامنا بالكامل، وكيف كانت "طوابير الرسائل" (Message Queues) هي طوق النجاة. سنتعمق في فهم...

6 مايو، 2026 قراءة المزيد
التكنلوجيا المالية Fintech

كان المحتالون يسبقوننا بخطوة: كيف أنقذنا ‘التعلم الآلي’ شركاتنا من جحيم الخسائر المالية؟

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

6 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

كانت الترقية تعني التخلي عن الكود: كيف أنقذنا ‘المسار الوظيفي المزدوج’ من جحيم فقدان أفضل مبرمجينا؟

في عالم البرمجة، الترقية لا تعني بالضرورة الإدارة. أروي لكم قصتنا وكيف أنقذنا "المسار الوظيفي المزدوج" أفضل مهندسينا من ترك شغفهم بالكود، وحوّلنا بيئة العمل...

6 مايو، 2026 قراءة المزيد
أتمتة العمليات

كانت خوادمنا كائنات أليفة: كيف أنقذتنا ‘البنية التحتية كشيفرة’ (IaC) من جحيم التكوينات اليدوية؟

أنا أبو عمر، وهذه قصتي مع ليلة لا تُنسى أجبرتنا على التخلي عن خوادمنا "الأليفة" وتبني مفهوم "البنية التحتية كشيفرة" (IaC). رحلة من الفوضى اليدوية...

6 مايو، 2026 قراءة المزيد
نصائح برمجية

كانت بياناتنا تتغير من تحت أقدامنا: كيف أنقذتنا ‘اللامتغيرية’ (Immutability) من جحيم الآثار الجانبية؟

أشارككم قصة حقيقية من ميدان البرمجة، عن ليلة طويلة قضيتها في تصحيح خطأ غامض كان سببه "التغييرية" (Mutability). سنغوص في مفهوم "اللامتغيرية" (Immutability) وكيف يمكن...

6 مايو، 2026 قراءة المزيد
البودكاست