مقارنة بدائل Slack المستضافة ذاتياً

ما بديل Slack المستضاف ذاتياً الذي ينبغي تشغيله

البدائل المستضافة ذاتياً لـSlack التي تستحق وقت فريق صغير هي Mattermost وRocket.Chat وMatrix مع Synapse وZulip. إذا كنت تحتاج إلى أداة فريق داخلية على خادم واحد، فشغّل Mattermost. وإذا كنت تدير مجتمعاً عاماً، فشغّل Zulip. استخدم Matrix مع Synapse عندما تحتاج إلى التواصل مع خوادم يملكها أشخاص آخرون، وفقط عندها، لأن federation هي الميزة الوحيدة التي لا تستطيع البدائل الأخرى محاكاتها، وهي أيضاً الميزة التي تغيّر مهامك كمسؤول نظام.

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

ما هي هذه الخيارات الأربعة فعلياً

Mattermost هو خادم مكتوب بلغة Go ويستخدم قاعدة بيانات PostgreSQL. يتكوّن من ملف ثنائي واحد، وقاعدة بيانات واحدة، وملف إعداد واحد. يعمل بطريقة مشابهة لـSlack، بما في ذلك سلاسل المحادثات وأوامر slash، وهو الأقل إثارة للاهتمام من حيث التشغيل بين الخيارات الأربعة، وهذا أمر إيجابي.

Rocket.Chat هو تطبيق Node.js يستخدم MongoDB. يوفّر أكبر مجموعة من الميزات هنا، بما في ذلك المكالمات الصوتية والمرئية، وصندوق وارد متعدد القنوات يجمع محادثات العملاء من البريد الإلكتروني والقنوات الاجتماعية في الواجهة نفسها. إذا كان هذا الصندوق هو سبب بحثك عن حل، فقارنه أولاً بـمكتب دعم Chatwoot مخصص، لأن خادم المحادثة الذي ينفّذ مهام الدعم يختلف عن خادم المحادثة المخصص لعمل الفريق.

Matrix هو بروتوكول وليس منتجاً. Synapse هو الخادم المرجعي، وهو مكتوب بلغة Python ويستخدم PostgreSQL، بينما Element هو العميل الذي يستخدمه معظم الأشخاص. هذا هو الخيار الوحيد هنا الذي يستطيع فيه خادمك الاتصال بخوادم لا تديرها أنت.

Zulip هو خادم Python يستخدم Django وTornado، وتقف خلفه PostgreSQL وRabbitMQ وmemcached وRedis. يثبّته البرنامج النصي الخاص به كوحدة واحدة. يعتمد نموذجه على وجود مواضيع داخل القنوات، لذلك تظل محادثة جرت يوم الثلاثاء قابلة للعثور عليها يوم الجمعة. صدر الإصدار 12.0 في April 2026.

كمية RAM وقاعدة البيانات المناسبة عند 10 مستخدمين وعند 100

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

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

لا تتبع الصفوف البنية نفسها، وهذه أول نتيجة مفيدة. تمثّل قيمة 1 GB الخاصة بـSynapse حداً أدنى لعملية Synapse، مع شرط مرفق: تطلب الوثائق توفر هذه الكمية على الأقل من RAM الحرة إذا أردت الانضمام إلى غرف عامة كبيرة. وتكون PostgreSQL خارج هذه القيمة. أما قيمة 2 GB الخاصة بـMattermost فتمثّل كامل الخادم، بما في ذلك قاعدة البيانات، وهي تغطي من 1 إلى 1,000 مستخدم على vCPU واحد. وتوثّق Zulip مقدار 2 GB ومعالجاً واحداً لأقل من 100 مستخدم، إضافة إلى 2 GB من swap، ثم 4 GB ومعالجين عند 100 مستخدم أو أكثر. وتنشر Rocket.Chat أكبر قيمة هنا، وهي 8 GB، لأنها تحدد حجم التطبيق عند 4 GiB وMongoDB عند 4 GiB، وهذا المستوى مصنّف لما يصل إلى 500 مستخدم متزامن.

عند 10 مستخدمين، تعمل جميع هذه المشاريع وعددها 4 على عتاد لن تضطر إلى التفكير فيه مرتين. وعند 100 مستخدم، تتباين النتائج: يظل Mattermost ضمن مستوى 2 GB، ويتطلب Zulip مقدار 4 GB ومعالجاً ثانياً، بينما يظل أصغر مستوى موثّق لـRocket.Chat عند 8 GB، لأن استهلاك MongoDB للذاكرة تحدده مواصفات الجهاز لا عدد المستخدمين لديك.

يحدد اختيار قاعدة البيانات ترقياتك المستقبلية أكثر مما يحدد أداءك اليومي. يتطلب Mattermost الإصدار PostgreSQL 14 أو أحدث، وقد أوقف دعم MySQL بدءاً من v11، لذلك فإن تثبيت MySQL اليوم يعني إجراء ترحيل غداً. يعمل Synapse على SQLite، وتوضح وثائقه صراحةً أن SQLite مقبولة للاختبار فقط، لأنها ذات أداء ضعيف في الغرف الكبيرة. يتطلب Rocket.Chat 8 الإصدار MongoDB 8.0، ما يعني أن ترقية قاعدة البيانات وترقية الدردشة تشكلان مشروعاً واحداً بدلاً من مشروعين.

ما الذي يوفّره VPS بسعة 2 GB فعلياً

تُعد خطة 2 GB أقل سعة لدى معظم المزوّدين، وهي مناسبة فعلياً لاثنين من هذه الخيارات الأربعة.

• Mattermost مناسب. وهو الوحيد الذي توثّق شركته المصنّعة هذه السعة تحديداً، لما يصل إلى 1,000 مستخدم، مع تشغيل PostgreSQL على الخادم نفسه. ويكون تشغيل عشرة أشخاص على 2 GB مريحاً.
• Zulip مناسب مع swap. توصي الوثائق باستخدام swap على أي خادم تقل سعته عن 5 GB، وتحذّر من أن الأجهزة ذات الذاكرة المحدودة تواجه أخطاء نفاد الذاكرة أثناء الترقية، حيث تكون tools/webpack هي الخطوة التي تفشل. وهذا فشل فعلي ستواجهه وقت الترقية، لا وقت التثبيت.
• Synapse مناسب ما دام الحمل منخفضاً. استهلاكه في وضع الخمول منخفض. لكن المشكلة هي الارتفاع المفاجئ في الاستهلاك، ويشرح القسم الخاص بالاتحاد أدناه مصدره.
• Rocket.Chat هو الخيار الذي ينبغي تجنّبه عند استخدام 2 GB، والسبب هو محرّك تخزين MongoDB. يضبط WiredTiger حجم ذاكرته المخبئية الداخلية على القيمة الأكبر بين 50% من (RAM ناقص 1 GB) أو 256 MB، ولذلك يحجز على جهاز بسعة 2 GB نحو 512 MB قبل بدء Node.js. لا تكون النتيجة رفضاً واضحاً للتشغيل. بل يُثبَّت التطبيق ويعمل، ثم يتباطأ مع ازدياد السجل، وفي النهاية يوقف قاتل نفاد الذاكرة في kernel العملية الأكبر حجماً في ذلك الوقت.

تحقق مما لديك فعلياً قبل اتخاذ القرار، لأن المزوّدين يحسبون RAM بطرق مختلفة عن free:

free -h
swapon --show

تذكّر أن خادم الدردشة ليس المكوّن الوحيد على الجهاز. إذ تحتاج إنهاء TLS (أمن طبقة النقل)، والنسخ الاحتياطية، وبيئة تشغيل الحاويات إلى الذاكرة أيضاً. ضع الخادم الذي تختاره خلف Reverse Proxy تفهمه، مثل Nginx أو Caddy أو Traefik، وإذا نشرت التطبيق باستخدام الحاويات، فستكون أساسيات Docker Compose لـ VPS هي الجزء الذي يستحق الإعداد الصحيح أولاً.

هل تحتاج تطبيقات الهاتف إلى خادم إشعارات فورية خاص بك

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

إليك الآلية. لا تقبل Apple Push Notification service (APNs) وFirebase Cloud Messaging (FCM) الإشعار إلا من الجهة التي تملك بيانات الاعتماد الخاصة بتوقيع التطبيق المعني. لا يستطيع خادمك إرسال إشعار إلى تطبيق لم تبنه. لذلك، يجب على خادم محادثة مستضاف ذاتياً يستخدم إصدار التطبيق من App Store تمرير إشعاراته إلى بوابة المورّد، ويحدد المورّد الشروط.

• Mattermost. المسار المجاني هو Test Push Notification Service (TPNS) على https://push-test.mattermost.com، وتذكر الوثائق أنه غير موصى به للبيئات الإنتاجية ولا يتضمن اتفاقية مستوى خدمة (SLA). يعمل هذا المسار فقط مع إصداري App Store وPlay Store. أما Hosted Push Notification Service (HPNS) فهو مناسب للبيئات الإنتاجية ويتطلب اشتراكاً مدفوعاً. والمسار الثالث هو تجميع وكيل الإشعارات الفورية بنفسك، ويتطلب عندها إنشاء إصدارات تطبيقاتك الخاصة باستخدام بيانات اعتماد APNs وFCM الخاصة بك.
• Rocket.Chat. تتطلب الإشعارات الفورية تسجيل مساحة العمل لدى Rocket.Chat Cloud، وتقتصر مساحات العمل المجتمعية على 10,000 إشعار فوري شهرياً. يعادل ذلك نحو 330 إشعاراً يومياً لمساحة العمل بأكملها. عند استهلاك الحصة، تتوقف الإشعارات عن الوصول حتى إعادة ضبط الشهر، ما يجعل التطبيق يبدو للمستخدمين معطلاً.
• Matrix مع Element. يرسل Synapse الإشعارات إلى بوابة للإشعارات الفورية، وتُوجَّه تطبيقات Element الرسمية إلى البوابة التي يشغّلها matrix.org على https://matrix.org/_matrix/push/v1/notify. تحمل الحمولة معرّفات الحدث والغرفة بدلاً من نص الرسالة، ويجلب التطبيق المحتوى من خادمك، لذلك ترى البوابة البيانات الوصفية بدلاً من المحادثات. تشغيل بوابة Sygnal الخاصة بك مدعوم، لكنه يعني إنشاء تطبيقاتك الخاصة وتوزيعها. على Android يوجد مسار وسط: استخدام UnifiedPush مع خادم ntfy تستضيفه.
• Zulip. تتضمن الخطة المجانية خدمة الإشعارات الفورية للهاتف لما يصل إلى 10 مستخدمين. تحتاج إلى خطة عند تجاوز 10 مستخدمين، وتغطي خطة Community المجانية العديد من المؤسسات غير التجارية. أضاف Zulip 12.0، في أبريل 2026، تشفيراً شاملاً لحمولات الإشعارات الفورية.

عند 10 مستخدمين، توفر لك جميع هذه الخيارات إشعارات عاملة دون تكلفة. عند 100 مستخدم، يتغير الوضع: يتطلب Zulip خطة، ويستمر Mattermost في العمل على الخدمة التجريبية دون SLA أو دعم، وتصبح الحصة الشهرية في Rocket.Chat هي القيد، بينما لا يتأثر Matrix لأن استخدام البوابة مجاني.

ما الخيارات التي توفّر تسجيل دخول موحّداً مجاناً

يظهر نموذج الأعمال ذي النواة المفتوحة بأوضح صورة في تسجيل الدخول الموحّد (SSO).

• Zulip يتضمن SAML (لغة ترميز تأكيدات الأمان) وLDAP (بروتوكول الوصول إلى الدليل الخفيف) في الخادم المستضاف ذاتياً من دون تكلفة. لا توجد فئة منفصلة يجب شراؤها.
• Synapse يدعم OpenID Connect (OIDC) وSAML وCAS في ملف الإعداد الخاص به مجاناً. تستخدم عمليات النشر الأحدث بشكل متزايد Matrix Authentication Service، وهي خدمة منفصلة توفّر ترحيلًا باتجاه واحد من مصادقة Synapse التقليدية. لذلك خطط لهذا الانتقال مسبقاً بدلاً من اكتشافه لاحقاً.
• Rocket.Chat يوفّر إصدار المجتمع تسجيل الدخول الأساسي عبر LDAP وSAML. تتطلب مزامنة سمات المستخدم الموسّعة، وربط المجموعات والفرق، والمزامنة في الخلفية ترخيصاً للمؤسسات.
• Mattermost يوفّر Team Edition المجاني GitLab OAuth ولا يوفّر شيئاً غيره. أما SAML وAD/LDAP وOpenID Connect فهي ميزات مدفوعة.

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

ما الذي تكلّفك إياه federation فعلياً

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

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

حدّد سياسة الاحتفاظ في اليوم الأول، لا في اليوم الذي يمتلئ فيه القرص:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

أضاف Synapse ميزة media_retention في الإصدار 1.61، مع فترات احتفاظ منفصلة للوسائط المحلية والبعيدة. الوسائط البعيدة عبارة عن ذاكرة تخزين مؤقت، لذلك إذا طلب المستخدم ملفاً محذوفاً مرة أخرى، يعيد Synapse طلبه من الخادم الذي جاء منه. أما الوسائط المحلية فليست ذاكرة تخزين مؤقت، ولذلك يؤدي إعداد local_media_lifetime قصير إلى حذف تحميلات مستخدميك نهائياً.

الخلاصة الصريحة: إذا كان مستخدموك يتحدثون فقط مع بعضهم، فلن تمنحك federation أي فائدة، وستستهلك مساحة القرص وعرض النطاق الترددي وتفرض مسار ترقية أكثر تعقيداً. عطّلها، أو اختر خادماً مختلفاً.

كيف تتم الترقيات

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

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

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

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

تتم الترقيات اللاحقة باستخدام ملف tarball نفسه مع أمر واحد:

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost يمكن التنبؤ بترقياته. استبدل الملف التنفيذي، ثم أعد التشغيل، وتُنفَّذ عمليات الترحيل عند بدء التشغيل. منذ إصدارات August 2025، يصدر مسار Extended Support Release (ESR) إصداراً كل 9 أشهر مع دعم لمدة 12 شهراً، وتُعد الترقية من ESR إلى ESR المسار المختبَر. الترقية مع تخطي عدة إصدارات ESR دفعة واحدة مدعومة، لكنها غير مختبَرة. وهذا يعني عملياً أنك ستكون المسؤول عن اختبارها.

Rocket.Chat يربط 3 ترقيات معاً. اعتباراً من August 2026، يُعد خط 8.x هو الحالي، وقد صدر 8.7.0 في 6 August 2026، ويتطلب MongoDB 8.0 وإصداراً مطابقاً من Node.js. يؤدي تخطي إصدار رئيسي إلى وصول المستخدمين إلى قاعدة بيانات يرفض التطبيق فتحها. يثبت دليل تثبيت Rocket.Chat باستخدام Docker Compose هذه المكونات معاً نيابةً عنك، وهذا هو السبب الرئيسي لاختيار مسار الحاويات هنا.

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

شروط الترخيص بلغة واضحة

توزّع Mattermost الإصدارات المترجمة من Team Edition بموجب ترخيص MIT، بينما يتوفر المصدر بموجب AGPLv3 أو ترخيص تجاري. وتخضع أجزاء من المستودع لـMattermost Source Available License، التي تتطلب ترخيصاً مدفوعاً لتشغيلها في بيئة الإنتاج. يخضع Rocket.Chat لترخيص MIT باستثناء الأدلة ee/، التي لديها ترخيص مؤسسي مستقل. انتقلت Synapse من Apache 2.0 إلى AGPLv3 مع الإصدار 1.99.0، ويوقّع المساهمون على CLA يتيح لـElement بيع استثناءات من هذا الترخيص. تخضع Zulip لترخيص Apache 2.0 ولا تحتوي على دليل مؤسسي، ولذلك لا توجد علامة نجمية في دعمها لـSSO.

المعنى العملي هو أن AGPL يهمك فقط إذا كنت تخطط لتعديل الخادم وتقديمه إلى الآخرين كخدمة. أما ما يهم فريقاً صغيراً بدرجة أكبر فهو حدود open core، أي الميزات غير المتوفرة في الإصدار المجاني. لدى Zulip أقل عدد منها، بينما لدى Mattermost أكبر عدد.

أي خيار تختار

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

خادم لمجتمع. Zulip. تحافظ الموضوعات على قابلية قراءة قناة عامة نشطة بعد مرور أشهر، ولا تكلّف SAML وLDAP شيئاً، ولا تحتاج الترقية إلا إلى أمر واحد. إذا كان مجتمعك أقرب إلى المنشورات والردود منه إلى الدردشة المباشرة، فقارن أولاً برمجيات المنتديات المستضافة ذاتياً، لأن المنتدى تتم فهرسته في محركات البحث بصورة أفضل ولا يحتاج إلى بنية تحتية لدفع الإشعارات على الإطلاق. اختر Rocket.Chat بدلاً منه عندما تريد ميزات الصوت والفيديو والقنوات متعددة الوسائط، ويمكنك تخصيص 8 GB التي تطلبها وثائقه الخاصة.

شبكة يجب أن تتكامل مع شبكات أخرى. Matrix مع Synapse وElement. تقبّل نمو الوسائط، واضبط سياسة الاحتفاظ منذ اليوم الأول، ووفّر له PostgreSQL ومساحة تخزين أكبر مما تتوقع، واستفد فعلياً من التواصل مع خوادم لا تتحكم فيها. اختيار Synapse لفريق لا يستخدم federation مطلقاً يعني دفع هذه التكلفة دون فائدة.

FAQ

ما أفضل بديل مستضاف ذاتياً لـSlack لفريق صغير؟

Mattermost، لمعظم الفرق الداخلية. تغطي وثائقه من 1 إلى 1,000 مستخدم على vCPU واحد و2 GB من RAM مع PostgreSQL على الجهاز نفسه، لذلك يناسب خطة VPS الابتدائية التي يبيعها معظم المزوّدين. لكن تسجيل الدخول الأحادي يمثل قيداً: تدعم Team Edition المجانية GitLab OAuth فقط، بينما تتطلب SAML وAD/LDAP وOpenID Connect كلها خطة مدفوعة. إذا كان SSO المجاني أهم من الواجهة المشابهة لـSlack، فاستخدم Zulip بدلاً منه.

هل يمكنني تشغيل خادم محادثة مستضاف ذاتياً على VPS بسعة 2 GB؟

نعم مع Mattermost، ونعم مع Zulip إذا أضفت swap، إذ توصي وثائق Zulip نفسها بذلك عندما تكون الذاكرة أقل من 5 GB. أما Rocket.Chat فسيخيّب توقعاتك، لأن محرّك WiredTiger في MongoDB يحجز لذاكرة التخزين المؤقت القيمة الأكبر من 50% من (RAM ناقص 1 GB) أو 256 MB، ما يعني أن نحو 512 MB من جهاز سعته 2 GB تُستهلك قبل بدء التطبيق. سيُثبَّت التطبيق، ثم يتدهور أداؤه مع نمو السجل، وينتهي الأمر بإنهائه بسبب نفاد الذاكرة. أصغر مستوى منشور لدى Rocket.Chat هو 4 GiB للتطبيق و4 GiB لـMongoDB.

هل تحتاج خوادم المحادثة المستضافة ذاتياً إلى خادم خاص بها لإشعارات الدفع على الأجهزة المحمولة؟

عادةً لا، لأن APNs من Apple وFCM من Google لا يقبلان الإشعارات إلا من الجهة التي وقّعت التطبيق، ولذلك يستخدم تطبيق المزوّد بوابة المزوّد. لكن الشروط تختلف. يوفّر Mattermost خدمة اختبار مجانية بلا SLA، إضافة إلى خدمة مستضافة مدفوعة. يحدّ Rocket.Chat مساحات العمل المجتمعية بـ10,000 إشعار دفع شهرياً، وبعد ذلك يتوقف التسليم حتى يُعاد ضبط الشهر. يضمّن Zulip خدمة الدفع مجاناً لما يصل إلى 10 مستخدمين، ويتطلب خطة أعلى من ذلك. تدفع خوادم Matrix الرئيسية الإشعارات عبر البوابة التي تستخدمها تطبيقات Element دون تكلفة. لا تحتاج إلى بوابتك الخاصة إلا إذا كنت ستوزّع أيضاً إصداراتك الخاصة من التطبيق.

هل ينبغي أن أستضيف Matrix وSynapse ذاتياً لفريق لا يتحدث مطلقاً إلى خوادم أخرى؟

لا. Federation هي الوظيفة الأساسية لـSynapse، وهي أيضاً ما يجعل تشغيله أثقل. يؤدي الانضمام إلى غرف على خوادم أخرى إلى جلب حالتها وتخزين وسائطها مؤقتاً على قرصك، لذلك تزداد مساحة التخزين لأسباب لا تتعلق بمستخدميك. اضبط media_retention باستخدام remote_media_lifetime قصير قبل حدوث ذلك. يتحمل الفريق الذي يتحدث مع أفراده فقط تكلفة التشغيل من دون أي فائدة، بينما ينفذ Mattermost أو Zulip المهمة نفسها على عتاد أقل.

ما بديل Slack المستضاف ذاتياً الذي يوفّر تسجيل الدخول الأحادي مجاناً؟

Zulip وSynapse. يضمّن Zulip كلاً من SAML وLDAP في الخادم المستضاف ذاتياً دون تكلفة، ويدعم Synapse ‏OpenID Connect وSAML وCAS في إعداداته، مع انتقال عمليات التثبيت الأحدث إلى Matrix Authentication Service المنفصل. يوفّر الإصدار المجتمعي من Rocket.Chat تسجيل دخول أساسي عبر LDAP وSAML، لكنه يضع مزامنة السمات، وربط المجموعات، والمزامنة في الخلفية خلف ترخيص مؤسسي. تدعم Team Edition المجانية من Mattermost GitLab OAuth فقط.