من أصعب مهام صيانة المشاريع المفتوحة المصدر هو قول "لا" لفكرة جيدة. عندما يقترح مستخدم ميزة مصممة بعناية، مفيدة، وخالية من عيوب تقنية واضحة، لكن الإجابة تظل "لا"، فإن ذلك قد يربك المستخدم، بينما يُعدّ لدى الصانع ضرورة حتمية للحفاظ على هوية المشروع. بعد سنوات من إنشاء وصيانة مشاريع ناجحة مثل Prefect وFastMCP، ومساهمة في Apache Airflow وTheano، تعلمت أن العمل الحقيقي ليس في إضافة الميزات، بل في الحفاظ على رؤية واضحة ومتماسكة. النجاح الحقيقي لا يقاس بعدد الميزات، بل بقدر ما تتطابق التصوّرات البرمجية مع التفكير البشري لدى المستخدمين. كما يشير كريس وايت، الرئيس التقني لـPrefect: "يختار الناس البرمجيات عندما تتطابق تصوراتها مع نموذجهم الذهني." لذلك، تبدأ الحماية من التوسع العشوائي بتوثيق "لماذا" المشروع موجود، لا فقط "كيف" يعمل. الدليل التقني والبيانات التأسيسية للرؤية تُشكّل الحدود الواضحة مسبقًا، وتُجذب المساهمين الذين يشتركون في هذه الرؤية. هذا يخلق دورة متجددة: كلما كانت الرؤية أوضح، زادت الالتزامات المتناغمة، مما يعزز الرؤية بدوره. وتتحول الإجراءات إلى أدوات للانسجام، لا إلى عبء إداري. والمسؤول هنا يُصبح قادرًا على رفض الاقتراحات بثقة، لأن عبء الإثبات يقع على المُساهم، لا على المشروع. لكن مع ظهور الذكاء الاصطناعي التوليدي، تغيرت المعادلة. لم تعد كتابة الكود مجهدة، بل أصبحت رخيصة وسريعة. فبدلاً من مناقشة الفكرة، نرى الآن ميزات كاملة مُعدّة مسبقًا في طلبات دمج (PR) دون أي تواصل مسبق. الكود "يعمل"، لكنه لا يُراعي الفلسفة العامة للمشروع. الهدف كان تلبية طلب المستخدم، لا تقوية الرؤية. لا يعني هذا رفض كل مساهمات غير مطلوبة. فهناك لحظات سعيدة عندما يظهر PR كامل ومتناغم، يُصلح عيبًا أو يضيف ميزة صغيرة بذكاء. لكن التوازن تغير: أصبحت طلبات الدمج غير المطلوبة أكثر شيوعًا، وغالبًا ما تكون مجهدة من حيث المراجعة، لكنها قليلة الجدوى. في FastMCP، حاولنا التحكم بذلك بفرض إنشاء مشكلة (Issue) قبل كل PR، لكن النتيجة كانت مشكلات مكونة من جملة واحدة تُفتح قبل لحظة من إرسال الـPR! الحل الأقوى هو الجملة البسيطة: "نحن غير مقتنعين بأن هذا يقع ضمن مسؤوليات الإطار." إذا أراد المساهم إقناعنا، فهذا يُفيد الجميع. كما أن هناك مخاطر مهنية: قبول ميزة يعني تحمّل مسؤولية صيانة الكود، حتى لو لم يكن المساهم مستعدًا لذلك. لحل هذه المشكلة، أدخلنا في FastMCP "وحدة مساهمات" (contrib module) تحتوي على ميزات مفيدة لكنها لا تناسب النواة، وتمّ توثيقها بوضوح: لا ضمانات بتوافقها مع الإصدارات المستقبلية، وتمّت صيانة بعضها من قبل مساهميها أنفسهم. في الممارسة، قد تكون هذه الوحدات أفضل كمشاريع مستقلة، لكنها تُمكّن من بدء التعاون بطريقة جماعية. أعترف بتحول في سلوكني: في بدايات Prefect، كنا نرد خلال 15 دقيقة على الاستفسارات. اليوم، إذا لم أرى محاولة حقيقية للتفاعل، أبدأ أُقلّد هذا السلوك. أمام خيار بين نص طويل من الذكاء الاصطناعي أو سؤال واضح مع مثال مصغر (MRE)، أختار الأخير بلا تردد. هذا النهج يُشبه العمل اليدوي، وقد يبدو غريبًا في عصر "البرمجة العفوية" و"الالتزامات العشوائية". لكن تجربتي تؤكد أن هذا التفكير العميق هو ما يُميّز المشاريع الجيدة عن مجرد أدوات مفيدة. ورغم التفاؤل المُتآكل، رأيت في لقاءات لجنة MCP في نيويورك أن هذه الحكمة ما زالت حية. رغم الضغوط المستمرة لتوسيع نطاق البروتوكول، كان هناك رفض صريح لفكرة "الحل لكل شيء"، مع التركيز على ما يجب أن لا يفعله البروتوكول، بجانب ما ينبغي أن يفعله. وصوت ديفيد كان ثابتًا: "هذه فكرة جيدة، لكن هل هذا ما يجب أن يفعله بروتوكول؟" هذا التمسك بالمبادئ هو العمل الحقيقي لتنضج التكنولوجيا بروح فلسفية. وغادرت نيويورك أكثر تفاؤلًا من أي وقت مضى، لأن الفريق يفهم أن مهمته ليست فقط بناء بروتوكول، بل أن يكون حارسًا واعيًا له. وهذا النوع من الحفظ، رغم صعوبته، هو ما يصنع فرقًا حقيقيًا في مستقبل البرمجيات المفتوحة المصدر.