من مشاريع منفصلة إلى منظومة واحدة: ما تعلّمته من بناء أدوات للمطورين

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

مشكلة أراها، أبني لها حلاً، أنشره، أكتب التوثيق، ثم أنتقل إلى المشكلة التالية.

TomatoPHP بدأ من احتياجات متكررة أثناء بناء تطبيقات Laravel وFilament. أما Laravilt فجاء من رغبة مختلفة: بناء لوحات إدارة حديثة فوق Laravel باستخدام Inertia وVue أو React بدون أن تتحول بنية المشروع إلى شيء معقد يصعب التحكم فيه.

بعدها بدأت أعمل أكثر مع Go والأنظمة المعتمدة على الذكاء الاصطناعي، فظهر ToGO. ثم Orchestra MCP، ثم CaBrain، وحتى Mark It Down.

في البداية، كنت أرى هذه المشاريع كأدوات مختلفة.

لكن مع الوقت اكتشفت أن المشكلة لم تكن في بناء المشاريع نفسها.

المشكلة كانت أنني لم أكن أراها كمنظومة واحدة.

وهذا غيّر كثيراً من الطريقة التي أفكر بها اليوم في بناء المنتجات مفتوحة المصدر.

المشروع الجيد لا يبدأ من فكرة، بل من احتكاك حقيقي

معظم الأدوات التي أستمر في تطويرها لم تبدأ بجلسة brainstorming ولا بمحاولة العثور على "فكرة startup".

بدأت من شيء مزعج تكرر أكثر من مرة.

جزء من الكود أكتبه في كل مشروع.

طريقة عمل تحتاج إلى خطوات أكثر مما يجب.

أداة موجودة بالفعل، لكنها تفرض عليّ architecture لا أريدها.

أو فجوة بين أداتين جيدتين تجعل استخدامهما معاً أصعب مما ينبغي.

هذا النوع من المشاكل مهم لأنك عندما تبني حلاً لمشكلة واجهتها فعلياً، فأنت تعرف تفاصيلها الصغيرة.

تعرف أين تضيع الدقائق.

تعرف ما الذي يسبب الإحباط.

وتعرف أيضاً متى يكون الحل "تقنياً صحيحاً" لكنه سيئ من ناحية تجربة المطور.

وهذا فارق كبير.

المطور لا يحتاج فقط إلى library تعمل.

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

عندما تبدأ المشاريع في حل مشاكل متجاورة

مع الوقت، بدأت ألاحظ شيئاً مهماً.

المشاكل التي كنت أحلها لم تكن منفصلة كما كنت أعتقد.

في عالم Laravel مثلاً، TomatoPHP وLaravilt يبدوان مشروعين مختلفين، لكنهما يخدمان جزءاً متقارباً من رحلة المطور.

أحدهما يركز على plugins ومكونات يمكن إعادة استخدامها، والآخر يهتم ببناء admin applications وتجربة تطوير أكثر تنظيماً.

ثم انتقلت إلى Go.

لم يكن الهدف من ToGO أن أجعل Go يشبه Laravel شكلياً، بل أن أحاول الاحتفاظ ببعض الأفكار التي أحبها كمطور Laravel: الوضوح، conventions الجيدة، سرعة البدء، وتجميع الأدوات التي يحتاجها التطبيق في تجربة متماسكة.

بعد ذلك بدأت أنظمة الـAI Agents تتحول عندي من تجارب إلى بنية تحتية حقيقية.

هنا ظهرت أسئلة جديدة:

كيف أعطي الـagent أدوات كثيرة بدون أن يصبح النظام فوضوياً؟

كيف أجعل الأدوات قابلة للتركيب؟

كيف تتعامل IDEs المختلفة مع نفس القدرات؟

كيف يحتفظ الـagent بذاكرة لا تختفي بانتهاء المحادثة؟

كيف أجعل المعرفة التي أكتبها أو أجمعها متاحة لهذه الأنظمة؟

ومن هنا بدأت العلاقة بين Orchestra MCP وCaBrain وMark It Down وToGO تصبح أوضح.

لم يعد الأمر مجموعة repositories.

أصبح لدي طبقات مختلفة من نفس المشكلة.

النظام البيئي أهم من عدد المشاريع

واحد من الأخطاء التي أعتقد أن مطوري الـopen source يقعون فيها بسهولة هو قياس التقدم بعدد المشاريع.

عشرة repositories تبدو أفضل من ثلاثة.

مائة package تبدو أقوى من عشرة.

لكن العدد وحده لا يعني الكثير.

يمكنك أن تمتلك خمسين مشروعاً لا يعرف مستخدم أحدها أن المشاريع الأخرى موجودة.

ويمكن أن يكون لديك خمسة مشاريع فقط، لكن كل مشروع يقود بشكل طبيعي إلى الآخر.

الثاني أقوى بكثير.

بدأت لذلك أفكر في المشاريع كعلاقات، لا كقائمة.

إذا كنت تستخدم TomatoPHP، ما المشروع الآخر الذي قد يكون مفيداً لك؟

إذا كنت تبني تطبيقاً بـToGO، ما الذي تحتاجه عندما تبدأ في إضافة AI Agents؟

إذا كنت تستخدم Orchestra، ماذا يحدث عندما يحتاج الـagent إلى long-term memory؟

وإذا كانت لديك معرفة وملفات Markdown وملاحظات، كيف تصل هذه المعرفة إلى الـagent؟

عندما تكون الإجابات طبيعية، يصبح الربط بين المشاريع مفيداً للمستخدم، وليس مجرد cross-promotion.

وهذا هو الفرق بين ecosystem حقيقي وصفحة فيها مجموعة logos.

الـOpen Source ليس الكود فقط

من السهل جداً كمطور أن نقضي 90% من الوقت على الكود ثم نتساءل لماذا لا يستخدم المشروع إلا عدد محدود من الناس.

لكن استخدام المنتج يبدأ قبل تشغيل أول command.

يبدأ من أول مرة يرى فيها شخص اسم المشروع.

هل يفهم ماذا يفعل؟

هل يعرف إذا كان مناسباً له؟

هل يستطيع رؤية مثال حقيقي؟

هل التوثيق يشرح السبب قبل الـAPI؟

هل يمكنه الانتقال من الصفحة الرئيسية إلى installation في أقل من دقيقة؟

هل يعرف حالة المشروع: هل هو experimental؟ stable؟ production-ready؟

هذه الأشياء ليست "marketing" بالمعنى السطحي.

هي جزء من المنتج.

وهذا كان درساً واضحاً جداً أثناء مراجعتي لمواقعي مؤخراً.

بعض المشاريع كانت أقوى تقنياً بكثير مما توحي به مواقعها.

Orchestra مثال واضح.

لو كان المشروع يحتوي على architecture قوية، plugins، MCP tooling، agent workflows وقدرات كبيرة، بينما الموقع لا يشرح ذلك بوضوح، فأنت فعلياً تخفي قيمة المشروع عن الشخص الذي جاء ليكتشفه.

المشكلة هنا ليست SEO.

المشكلة أن الرسالة نفسها غير مكتملة.

الـSEO الجيد نتيجة للوضوح

خلال العمل على المواقع، حاولت ألا أتعامل مع SEO كعملية إضافة كلمات مفتاحية.

لأنك تستطيع كتابة كلمة "AI Agents" خمسين مرة ولن تجعل الصفحة أفضل.

السؤال الأهم بالنسبة لي أصبح:

لو جاء مطور من Google إلى هذه الصفحة، هل سيجد جواباً حقيقياً للسؤال الذي كان يبحث عنه؟

مثلاً اسم مثل ToGO وحده صعب جداً في البحث.

الاسم لا يخبر Google ولا المستخدم بما هو المنتج.

لكن عندما تربطه بوصف واضح مثل:

"Go framework for AI-native applications"

أو

"Laravel-inspired framework for Go"

فأنت لم تضف keyword فقط.

أنت شرحت المنتج.

نفس الشيء مع Mark It Down.

الاسم وحده واسع وعام، لكن عندما تصفه بأنه Markdown workspace يعمل مع MCP وAI agents، يصبح هناك معنى واضح يمكن للمستخدم ومحرك البحث فهمه.

أفضل SEO وجدته حتى الآن هو أن تجعل المنتج قابلاً للفهم.

لا تجعل كل مشروع مدونة

من الأشياء التي لا أريد عملها أن أضع blog في كل موقع ثم أبدأ في إنتاج عشرات المقالات فقط لأن "المحتوى مفيد للـSEO".

هذا غالباً سيؤدي إلى كمية كبيرة من المقالات المتشابهة والقليلة القيمة.

الأفضل بالنسبة لي هو أن يكون لكل مشروع مجال معرفي واضح.

TomatoPHP يمكن أن يتحدث عن Filament وLaravel plugin architecture.

Laravilt عن Laravel admin panels وInertia وVue وReact.

ToGO عن Go architecture وبناء التطبيقات الحديثة والـAI-native systems.

Orchestra عن MCP والـagents وdeveloper tooling.

CaBrain عن agent memory وRAG وretrieval وentity graphs.

Mark It Down عن Markdown وknowledge workflows وربط المعرفة بالـAI.

بهذه الطريقة، المحتوى لا يُكتب "للحصول على traffic".

يُكتب لأن هناك خبرة حقيقية داخل المشروع يمكن مشاركتها.

والـtraffic يأتي لاحقاً كنتيجة لذلك.

الأرقام بدون سياق لا تبني الثقة

درس آخر بسيط لكنه مهم: لا تستخدم metrics فقط لأنها تبدو جيدة.

عدد stars.

عدد downloads.

عدد users.

عدد tools.

هذه الأرقام مفيدة فقط إذا كانت صحيحة، محدثة، ويمكن تفسيرها.

أثناء مراجعة بعض المواقع، ظهرت اختلافات بين أرقام موجودة في النسخة الإنجليزية وأخرى في العربية، أو بين الموقع وGitHub.

حتى لو كان السبب cache أو content قديم، النتيجة بالنسبة للزائر واحدة:

هناك شيء غير متسق.

لهذا أصبحت أفضل أن أعرض رقماً أقل لكنه موثوق، على رقم أكبر يحتاج إلى تفسير.

ولو كان الرقم يتغير باستمرار، فالأفضل أن يأتي مباشرة من مصدره بدلاً من نسخه يدوياً في أكثر من مكان.

الثقة في مشروع open source تُبنى من التفاصيل الصغيرة.

التوثيق القديم أخطر مما يبدو

كل مشروع يعيش لسنوات سيغير تقنياته.

Framework يتغير.

Version جديد يظهر.

Architecture تتطور.

لكن صفحات التوثيق القديمة قد تظل في نتائج Google لسنوات أيضاً.

وهنا تحصل مشكلة غريبة.

أنت تطور المنتج، لكن Google يرسل المستخدم إلى نسخة قديمة منه.

وقد يحكم المستخدم على مشروعك كله من صفحة كتبتها منذ ثلاث سنوات.

لهذا أصبحت أرى documentation maintenance كجزء من product maintenance.

ليس ضرورياً حذف التاريخ.

أحياناً وجود docs لإصدارات قديمة مهم جداً.

لكن يجب أن يكون من الواضح أنها قديمة.

يجب أن يعرف المستخدم أي نسخة يقرأ.

ويجب ألا تتنافس صفحات قديمة وجديدة على نفس الـcanonical والـsearch intent.

ما الذي يجعل المشروع جزءاً من Ecosystem؟

بالنسبة لي، هناك عدة شروط بدأت أستخدمها.

أولاً، يجب أن يحل كل مشروع مشكلة حقيقية بمفرده.

لا أريد أن يكون المشروع موجوداً فقط ليجبرك على تثبيت مشروع آخر.

ثانياً، العلاقة بين المشاريع يجب أن تكون منطقية.

CaBrain لا يحتاج أن يكون داخل كل منتج أملكه.

لكن إذا كنت تبني AI agent ويحتاج إلى ذاكرة، يصبح ذكره منطقياً.

ثالثاً، كل مشروع يجب أن يحتفظ بهويته.

لا أريد تحويل TomatoPHP وToGO وOrchestra إلى منتجات تحمل نفس التصميم والاسم لأن صاحبها واحد.

المنتج يجب أن يكون له شخصية مستقلة.

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

رابعاً، الـecosystem يجب أن يقلل الاحتكاك، لا أن يزيده.

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

الشبكة التي أحاول بناءها

اليوم أرى المشاريع بهذه الطريقة تقريباً.

في جانب Laravel، توجد أدوات مثل TomatoPHP وLaravilt.

في جانب Go، يوجد ToGO.

في طبقة الـAI agent infrastructure، يوجد Orchestra MCP.

في طبقة الذاكرة والاسترجاع، يوجد CaBrain.

وفي طبقة المعرفة التي يكتبها ويستخدمها الإنسان والـagent معاً، يوجد Mark It Down.

لا يعني هذا أن الخطة كانت موجودة من اليوم الأول.

لم تكن موجودة.

وهذه ربما أهم نقطة في المقال كله.

الـecosystem لم يأت من roadmap عملاق رسمته قبل سنوات.

ظهر تدريجياً من المشاكل التي كنت أحلها.

وبعد فترة، كان المطلوب فقط أن أتوقف قليلاً وأنظر إلى الصورة كاملة.

لا تحتاج إلى بناء كل شيء

بناء ecosystem لا يعني أن تبني authentication library لأنك تستطيع.

ولا يعني أن تصنع database جديدة أو message queue أو UI framework فقط لتقول إن كل شيء "in-house".

العكس أقرب للصواب.

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

MCP مثال جيد.

بدلاً من اختراع protocol خاص لكل أداة تتعامل مع AI agents، يمكن البناء فوق standard بدأ يكتسب دعماً واسعاً.

نفس الشيء ينطبق على frameworks وdatabases وprotocols الأخرى.

ميزة الـecosystem ليست أنك تملك كل dependency.

ميزته أن القطع التي اخترت بناءها تعمل معاً بشكل جيد.

ما كنت سأفعله بشكل مختلف لو بدأت من جديد

لو رجعت عدة سنوات، هناك بعض الأشياء التي سأفعلها أبكر.

سأكتب positioning واضح لكل مشروع قبل أن يصبح المشروع كبيراً.

سأتعامل مع documentation كمنتج منذ اليوم الأول.

سأستخدم source of truth واحداً للmetrics.

سأربط المشاريع ذات الصلة مبكراً.

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

وسأقلل عدد الأشياء التي أحاول شرحها في نفس الوقت.

المطور عندما يدخل موقعك لا يريد معرفة كل شيء فعلته.

يريد أن يعرف شيئاً واحداً:

هل هذا المشروع سيحل مشكلتي أم لا؟

إذا استطعت الإجابة عن هذا السؤال بسرعة، فقد قطعت نصف الطريق.

ماذا بعد؟

المرحلة التالية بالنسبة لي ليست إنشاء المزيد من المشاريع لمجرد توسيع القائمة.

أريد أن تصبح المشاريع الحالية أفضل.

توثيق أقوى.

أمثلة production حقيقية.

تكامل أبسط بينها.

محتوى تقني مبني على مشاكل واجهتها فعلاً.

وأهم من كل ذلك، أريد أن تكون المشاريع مفيدة حتى لو لم يعرف مستخدمها أي شيء عن بقية المنظومة.

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

هذه بالنسبة لي هي الطريقة الصحية لبناء ecosystem مفتوح المصدر.

ابدأ بمشكلة.

ابنِ حلاً جيداً.

شاركه.

استمع لمن يستخدمه.

ثم انظر إلى المشاكل التي تظهر بجواره.

بعد فترة، قد تكتشف أنك لم تكن تبني مجموعة مشاريع منفصلة.

كنت تبني منظومة طوال الوقت.