مرحبًا @rishabh، @riking، @codinghorror،
(نعم، يوجد ملخص TL;DR في الأسفل)
منذ بعض الوقت، فهمت من @sl007 و @hellekin أنكم لن تواصلوا هذه المرحلة الأولى في المدى القصير، حتى مع تمويل NGI0. وكشريك في الترويج للتشغيل البنيوي القائم على ActivityPub، أجد ذلك مؤسفًا بطبيعة الحال. ولكن من منظور Discourse، وهو برنامج المنتدى الرائد والأكثر شعبية، هناك العديد من القوى والأولويات الأخرى التي يجب أخذها في الاعتبار، وهذا القرار التجاري في هذا السياق يبدو منطقيًا للغاية:
القرار: لم يكن هذا الطلب للمراجعة (RFC) المقترح جذابًا بما يكفي ليُمنح الأولوية ويُدرج في خارطة الطريق.
اتبع الطلب للمراجعة (RFC) نهج الحد الأدنى من المنتج القابل للتطبيق (MVP) مع “لنبدأ بإنشاء تغذية محتوى مجمعة تشبه فيسبوك عبر المنتديات” كما اقترح @Falco. إنها مجرد واحدة من العديد والعديد من الميزات التي قد تنتج عن وجود دعم أصلي لـ ActivityPub بشكل أو بآخر. ويمكن القول إن وجود مثل هذا الجدول الزمني هو نوع من التحوُّب عن ما تجده عادةً في منتدى، ولا يبدو لي ميزة أساسية حقيقية. بل هو أكثر من إضافة جانبية، وبالتالي فهو أمر مرغوب فيه ولكن ليس ضروريًا.
نهج مختلف
مع تجاوز الحاجة إلى الوصول بسرعة إلى الحد الأدنى من المنتج القابل للتطبيق (MVP) لدعم ActivityPub، ربما يمكننا اتباع العملية المعاكسة:
التفكير الإبداعي: العصف الذهني لحالات استخدام التشغيل البنيوي وتقييمها من حيث الفائدة التجارية والمزايا الفريدة (USP’s).
أي: أي الميزات ستكون جذابة حقًا في Discourse؟ أو حتى: أين قد يفوت Discourse الفرصة إذا لم يكن على اطلاع بما هو ممكن؟
في منشوره الأخير أعلاه، ذكر @Falco مشروع Lemmy الذي بُني من الصفر على أساس مفردات بيانات مرتبطة (Linked Data vocabulary) مخصصة تتوافق مع نطاق عملهم التجاري. لقد كان لديهم الحد الأدنى من المنتج القابل للتطبيق (MVP) جاهزًا ويعمل في الإنتاج، وهم الآن ينظرون في توسيع مجموعة ميزاتهم بناءً على نطاقهم الخاص. وقد يشمل ذلك التكامل مع النطاق الآخر للكتابة المختصرة (Microblogging) حيث حققت Mastodon و Pleroma وغيرها نجاحًا كبيرًا.
قد يكون نهج التفكير الإبداعي على النحو التالي:
تمارين: لنخيل كيف كان سيبدو Discourse لو كان مبنيًا منذ البداية على نطاق عمل تجاري خاص به قائم على ActivityPub (مُعرّف كمفردات بيانات مرتبطة).
دعونا نتحرر في جلسة العصف الذهني هذه، ونترك إبداعنا يتدفق بحرية.
قد تكون قائمة حالات الاستخدام الناتجة عن كل هذا مثيرة للاهتمام بما يكفي من الناحية التجارية لتصبح جزءًا من خارطة الطريق، ولكن إذا لم تكن كذلك، فقد تلهم المجتمع لبناء الإضافات والمكونات، ووضع بعض الأساس الذي يمكن البناء عليه في مرحلة لاحقة.
ActivityPub مقابل Fediverse
ألاحظ وجود سوء فهم واسع النطاق لما يعنيه وجود دعم لـ ActivityPub في تطبيق ما. يعتقد الكثير من الناس أن السبب في ذلك هو أن تصبح ‘جزءًا من Fediverse’. وهنا تذهب الفكرة فورًا إلى التكامل مع خوادم Mastodon، أي تنفيذ التشغيل البنيوي مع (أي للانضمام إلى) نطاق الكتابة المختصرة الموزع.
نعم، هذه فرصة جذابة جدًا بمجرد الحصول على دعم لـ ActivityPub، والعديد من التطبيقات الأخرى مثل PixelFed (بديل إنستغرام)، و PeerTube (بديل يوتيوب) وكذلك Lemmy (بديل ريديت) تسعى إلى ذلك. فهم يجعلون Fediverse مكانًا أكثر جاذبية للمشاركة فيه، وتظهر العديد من الابتكارات التي تجعل مستقبل Fediverse مثيرًا حقًا.
لكن…
يمكن القول إن المنظمات التي تستهدف قاعدة مستخدمين كبيرة مثل Discourse قد تطرح أسئلة مثل: “لماذا أريد التكامل مع Fediverse الذي يضم حوالي 4 ملايين مستخدم فقط؟” أو “لماذا أدمج الكتابة المختصرة في برمجيتي التي تعمل في نطاق مختلف تمامًا؟”. وسيكونون محقين في قول ذلك، والتخلي عن تنفيذ ActivityPub على هذا الأساس.
ومع ذلك…
إن تنفيذات ActivityPub تتعلق بأكثر من مجرد الانضمام إلى (الجزء الخاص بالكتابة المختصرة من) Fediverse. من المنطقي تمامًا تنفيذ مفردات بيانات مرتبطة (Linked Data vocabulary) مصممة بشكل فريد لنطاق عملك التجاري الخاص، وجعل نسخ منتجك الخاصة تتكامل مع بعضها البعض. أو جميع نسخ منتجك ونسخ المنافسين في صناعتك الذين يعتمدون نفس المفردات أيضًا.
مثال واحد هنا هو مشروع ForgeFed الذي يهدف إلى تعريف معايير التشغيل البنيوي لمواقع استضافة الأكواد (مثل GitHub، GitLab، Gitea، Sourcehut، إلخ) لتنفيذها. إن القيام بذلك له معنى هائل، خاصة للمشاريع الأصغر لمواقع استضافة الأكواد لتوفير بديل جذاب لـ GitHub (الذي أصبح مهيمنًا للغاية كمنصة مركزية ومحصورة بشكل متزايد). إذا تم اعتماده على نطاق واسع، فلن يحتاج المطورون بعد الآن إلى التعامل مع مجموعة من حسابات مواقع استضافة الأكواد الموزعة على خوادم متفرقة عبر الإنترنت للمشاركة في مشاريع أكواد مثيرة، أو رفع مشكلة، أو التعليق، أو تقديم طلبات السحب (PR’s).
(لاحظ أنه - كما هو موضح أعلاه - نفس المشكلة التي يواجهها الناس مع وجود مواقع استضافة أكواد مستقلة منتشرة في كل مكان، هي ما أعيشه أنا والآخرين أيضًا مع مشاركتنا في العديد من مجتمعات Discourse.)
الفرصة: يتوفر لـ Discourse موقع فريد لقيادة وضع معايير التشغيل البنيوي لبرمجيات المنتديات، وتشكيل المعيار بطريقة تتوافق تمامًا مع مجموعة ميزات Discourse الحالية.
هناك بعض المنافسين الصاعدين في صناعتك، وهم مبتكرون، ويتبعون أساليب جديدة، ويكررون بسرعة لإضافة ميزات جديدة (أنتم في Discourse تعرفون من هم أفضل 
). في رأيي، لا يزال Discourse يتفوق من حيث اكتمال الميزات على ما تقدمه منتجاتهم. ولديكم مجتمع لا مثيل له لمساعدتكم في تطوير المنتج.
ولكن فرصة التشغيل البنيوي الموجودة الآن قد تتحول أيضًا إلى تهديد. إما أن يقفز المنافسون على هذه الفرصة أولاً، أو - ربما بدافع من قانون الأسواق الرقمية في الاتحاد الأوروبي - تقوم منصات التكنولوجيا الكبرى بإنشاء شيء ما يتداخل مع نطاق برمجيات المنتديات. في كلتا الحالتين، سيكون من الصعب على Discourse المواءمة مع هذا المعيار وامتلاك الصوت الأكثر سلطة في تصميم مواصفاته.
TL;DR
أصبح هذا المنشور أطول مما كنت أعتزم. آسف على ذلك 
باختصار، أنا أدعو إلى أنه، بالنظر إلى الموقف الحالي بشأن وجود دعم لـ ActivityPub، قد يكون من الحكمة الانتقال من التركيز قصير المدى المشابه للحد الأدنى من المنتج القابل للتطبيق (MVP)، إلى تقييم أوسع لما يمكن أن يجلبه التشغيل البنيوي لـ ActivityPub لـ Discourse من حيث المزايا الفريدة (USP’s) والموقع على المدى الطويل. أي تطوير الحالة التجارية لاعتماد ActivityPub، بدءًا من مرحلة التفكير الإبداعي.
(كيف يتم إعداد هذا بشكل أفضل - بشرط أن تكون مهتمًا - أترك ذلك في المنتصف، ولكن قد يبدأ ببساطة بموضوع AP جديد يحتوي على ملخص ويكي لحالات الاستخدام المجمعة في الأعلى، مع مناقشة الناس لأفكار حالات الاستخدام في الموضوع)