Smppcube مقابل المصدر المفتوح (Kannel · Jasmin · PlaySMS)
لنُنهِ الجزء المحرج أولًا: تأتي Smppcube ومعها Kannel في داخلها. لسنا هنا لنقول لك إن المصدر المفتوح برمجيات رديئة، فنحن نشغّله في الإنتاج وسنختاره من جديد لو عاد بنا الأمر. فـ Kannel هو أكثر من عشرين عامًا من لغة C المُحكَمة، يمسك بروابط الـ bind مع مراكز SMSC أفضل من أي شيء كنا سنكتبه بأنفسنا. هذه المقارنة لا تتناول جودة البرمجيات الحرة. إنها تتناول سؤالًا أضيق بكثير وأغلى بكثير: كم يكلّف تحويل bearer مجاني إلى نشاط تجاري تستطيع أن تُصدر منه فواتير، وهل ذلك المشروع هو منتجك أم مجرد التفاف عن الطريق؟ في ما يلي الأرقام الصريحة، وجدول مقارنة جنبًا إلى جنب، والحالات التي يكون فيها الخيار المجاني هو الصحيح فعلًا، والتي ينبغي عندها أن تغلق هذه الصفحة وتذهب لتبني.
ماذا تعني كلمة “مجاني” فعلًا في هذا السوق
المجانية في الترخيص والمجانية في التكلفة الإجمالية عملتان مختلفتان، وقطاع المراسلة بارع على نحو غير عادي في الخلط بينهما. والسبب أن الجزء المجاني هو الذي يؤدي الدور الظاهر والمُبهر. إنه يتحدث SMPP. ويحرّك آلاف الرسائل في الثانية. وينجو من مشغّل يتصرف بفظاظة في الثالثة فجرًا. ورؤيته يعمل لأول مرة تقود بسهولة شديدة إلى استنتاج أن الجزء الصعب قد انتهى.
الجزء الصعب لم ينتهِ. الجزء الصعب هو الجزء الممل. الـ bearer يحرّك الرسائل؛ أما النشاط التجاري فيقرّر من رصيد أي عميل خرجت الرسالة، وبأي سعر وعلى أي مسار، وهل كان يحق لذلك العميل إرسالها، وماذا يحدث للمال حين تخفق الرسالة إخفاقًا نهائيًا بعد أربع ساعات، وماذا يرى العميل حين يسجّل الدخول ليتحقق، وماذا تعرض أنت على جهة تنظيمية أو على عميل يعترض بعد ستة أشهر. لا شيء من ذلك يقع ضمن نطاق الـ bearer، ولا شيء من ذلك اختياري إن كنت تتقاضى من الناس مالًا.
إذن لم يكن الخيار يومًا “أن تدفع أو ألّا تدفع”. الخيار هو: أن تدفع ترخيصًا مرة واحدة، أو أن تدفع لمطوّر ستة إلى اثني عشر شهرًا ثم تستمر في الدفع له إلى الأبد ليصون ما بناه. وكلا الخيارين مشروع. غير أنهما يكلّفان مبالغ متباينة تباينًا هائلًا، وواحد منهما فقط يضع الفاتورة حيث تراها.
ماذا يغطّي كل خيار مفتوح المصدر فعلًا
ثلاثة مشاريع تتكرر في كل نقاش من هذا النوع. الثلاثة جيدة، والثلاثة صريحة بشأن نطاقها، وكل واحد منها يتوقف عند نقطة مختلفة.
Kannel. بوّابة WAP وSMS مفتوحة المصدر الكلاسيكية، مكتوبة بلغة C، ومقسّمة إلى BearerBox (الاتصالات) وSMSBOX (واجهة HTTP) وSQLBOX (جداول الطابور). إنه bearer بأنقى معانيه: يمسك بروابط SMPP لديك، ويحرّك الرسائل، ويؤدي كليهما ببراعة شديدة عند أحجام تُخجل كثيرًا من البرمجيات التجارية. والإعداد ملف نصي يُحرَّر عبر SSH. لا واجهة رسومية، ولا مفهوم للعميل، ولا رصيد، ولا فاتورة، ولا بوّابة، ولا خط دعم. وليست هذه ثغرة في المشروع، بل هي حدوده المرسومة عن قصد.
Jasmin. بوّابة ومُوجِّه رسائل حديث بلغة Python، بمعمارية أنيقة بصدق: موجّه رسائل، وواجهة إدارة عبر سطر الأوامر (jCli)، وواجهة HTTP، وخلافًا لـ Kannel، مفهوم بدائي للفوترة يملك فيه المستخدم أرصدة يخصم منها كل إرسال بسعر مُعدّ سلفًا. هذه النقطة الأخيرة مهمة، وهي سبب وصول Jasmin كثيرًا إلى القائمة القصيرة. لكن لنكن دقيقين في وصفه: أرصدة لكل مستخدم، لا نظام فوترة. لا فاتورة، ولا تعدد عملات، ولا تمييز بين الدفع المسبق والدفع اللاحق، ولا قائمة أسعار لكل عميل حسب المسار والوجهة، ولا شجرة موزّعين، ولا بوّابة عميل. إنه نقطة انطلاق أفضل بكثير من bearer مجرّد، ويبقى نقطة انطلاق.
PlaySMS. الأقرب شبهًا بمنتج، لأنه تطبيق ويب بلغة PHP: واجهة متصفّح، وحسابات مستخدمين بمستويات تشمل درجة موزّع، ورصيد بسيط، ومجموعات جهات اتصال، ووحدات بوّابة تتيح له قيادة Kannel أو مودم من تحت. ولعملية صغيرة بحفنة مستخدمين قد يكفي فعلًا، ونحن نفضّل أن تعرف ذلك الآن على أن تكتشفه لاحقًا. أما حيث يتجاوزه المشغّلون فهو العمق والإيقاع: قوائم أسعار لكل مسار، ودفع مسبق ولاحق جنبًا إلى جنب، وفوترة متعددة العملات، وعزل حقيقي بين العملاء، وعلامة بيضاء لكل مستأجر، والقنوات الأحدث، وسرعة تطوير تواكب WhatsApp وRCS وهما يغيّران قواعدهما كل ربع سنة.
النمط واحد في الثلاثة جميعًا. طبقة الاتصالات محلولة ومجانية. أما الطبقة التجارية فغير محلولة وهي عليك.
المقارنة جنبًا إلى جنب
| Kannel | Jasmin | PlaySMS | Smppcube v9 | |
|---|---|---|---|---|
| تكلفة الترخيص | مجاني | مجاني | مجاني | 6,400 USD مرة واحدة |
| روابط SMPP مع مراكز SMSC | ممتازة | ممتازة | عبر وحدة بوّابة | Kannel، داخل الحزمة |
| واجهة إدارة | لا يوجد | سطر أوامر (jCli) | نعم، أساسية | واجهة ويب كاملة |
| حسابات العملاء | لا يوجد | مستخدمون بأرصدة | نعم، مستويات أساسية | تعدد مستأجرين مع شجرة موزّعين |
| ضبط الرصيد | لا يوجد | أرصدة لكل مستخدم | رصيد بسيط | مسارات رصيد ومحفظة وتلقائية |
| قوائم أسعار لكل مسار | لا يوجد | تسعير أساسي | محدودة | لكل عميل ومسار ووجهة |
| الفوترة | لا يوجد | لا يوجد | لا يوجد | مسبق ولاحق ومتكرر ومتعدد العملات |
| بوّابة عميل بعلامة بيضاء | لا يوجد | لا يوجد | جزئية | لكل مستأجر، بعلامته كاملة |
| تقارير يقرأها العميل | ملفات سجل | ملفات سجل | أساسية | لوحات معلومات وتصدير |
| WhatsApp وRCS والصوت | لا | لا | لا | في المنصّة نفسها |
| دعم بمسؤول محدد | مجتمع المستخدمين | مجتمع المستخدمين | مجتمع المستخدمين | الشركة المطوّرة، باتفاقية مستوى خدمة |
| الزمن حتى أول عميل يدفع | من 6 إلى 12 شهرًا | من 4 إلى 9 أشهر | أسابيع، ثم سقف | أيام |
اقرأ ذلك الجدول بنزاهة وسيقفز إليك أمران. الصفوف العليا، أي صفوف الاتصالات، متعادلة أو تكاد، لأننا جميعًا واقفون على البرمجية نفسها. وكل صف يظهر فيه المال أو العملاء أو العلامة التجارية هو حيث تتوقف الخيارات المجانية ويبدأ مشروع البناء. أما الصف الأخير فهو الذي ينتهي به الأمر ليكون الأهم، وسنضع له سعرًا بعد قليل.
الفجوات الأربع، ولكل واحدة سعر
يستعرض دليل بديل Kannel ما لن يفعله الـ bearer لك أبدًا. أما هذا المقال فيفعل الأمر الأقل راحة ويضع رقمًا على كل فجوة. والتقديرات أدناه تفترض مطوّرًا متكامل المهارات وكفؤًا يفهم أصلًا SMPP وإشعارات التسليم والمال، وهو حيوان أندر مما يبدو، ويُسعَّر تبعًا لذلك.
تعدد المستأجرين. نحو 1 إلى 2 شهر تطويري. حسابات، وشجرة موزّعين، ومجموعات صلاحيات، وعزل جهات الاتصال والحملات ومعرّفات المرسل لكل مستأجر، ومفتاح تعليق يوقف عميلًا واحدًا دون المساس بالآخرين. يبدو الأمر كعطلة نهاية أسبوع من عمليات إنشاء وتحرير، إلى أن يأتي اليوم الذي يسرّب فيه خطأ برمجي قائمةَ جهات اتصال عميل داخل تصدير عميل آخر، وهي مكالمة هاتفية لا تُجرى إلا مرة واحدة.
الفوترة. نحو 3 إلى 6 أشهر تطويرية، وهنا تموت المشاريع. حجز الرصيد قبل الإرسال، والتسعير حسب المسار المستخدم فعليًا، والاسترجاع الصحيح عند الإخفاق النهائي دون الإخفاق المؤقت، وجعل كل عملية غير قابلة للتكرار حتى لا تُحاسِب إعادةُ محاولة الطابور مرتين، والإبقاء على الدفع المسبق واللاحق معًا، والتعامل مع عملات متعددة، وإصدار فاتورة يقبلها قسم مالي. ويصف دليل نماذج الفوترة الانضباط المحاسبي الذي يقتضيه ذلك. النسخة الأولى تستغرق شهرًا وتبدو مكتملة. أما النسخة التي تصمد أمام عميل يعترض على بند بقيمة 50.00 USD فتستغرق ستة.
بوّابات العلامة البيضاء والتقارير. نحو 2 إلى 3 أشهر تطويرية. لوحة تحمل علامة كل عميل: يكتب، ويرفع قائمة، ويتحقق من رصيده، ويسحب تقرير تسليم، ويرى فاتورة. يُضاف إلى ذلك تحويل أحداث DLR الخام إلى شيء يستطيع العميل تصفيته وفهمه دون أن يتصل بك. هذا هو الجزء الذي يلمسه عملاؤك كل يوم، ولذلك هو أيضًا الجزء الذي لا يجوز أن يبدو كأداة داخلية.
التشغيل والضريبة الأبدية. نحو 20 إلى 30 بالمئة من كلفة البناء، كل عام، بلا نهاية. ترقيعات أمنية، وقاعدة قوالب في WhatsApp تغيّرت، ومشغّل بدأ يعيد رمز خطأ جديدًا، والمطوّر الذي كتب محرّك الفوترة لديك وقد قبِل وظيفة أخرى وترك لك دفتر أستاذ بلا توثيق. البرمجيات ليست شراءً رأسماليًا يحدث مرة واحدة، إنها حيوان أليف يحتاج إلى إطعام. الجميع يحسبون كلفة البناء. ولا أحد تقريبًا يحسب كلفة الطعام.
اجمع الأرقام: من ستة إلى اثني عشر شهرًا تطويريًا للوصول إلى نسخة أولى تضع عليها عميلًا يدفع، إضافة إلى بند صيانة دائم. وهو الرقم نفسه الذي يذكره دليل Kannel لدينا، وليس رقمًا للتخويف. إنه ما يكلّفه هذا المشكل تحديدًا، وهو سبب وجود المنصّات التجارية أصلًا.
التكلفة الإجمالية للملكية على مدى ثلاث سنوات
الأرقام إذن. العمودان أدناه يفترضان النشاط نفسه: موزّع لديه عملاء يفوترهم، ويعمل على خادمه الخاص. ومدى كلفة المطوّر يمتد من متعاقد كفؤ في سوق ناشئة بنحو 3,000 USD شهريًا، وصولًا إلى تعيين أوروبي أو أمريكي شمالي بنحو 8,000 USD شهريًا، وهو مدى هائل بحق، وهو السبب الأكبر في أن هذا القرار يبدو مختلفًا في القاهرة عنه في دبي.
| البند، 3 سنوات | المصدر المفتوح، مبنيًا ذاتيًا | Smppcube v9 |
|---|---|---|
| ترخيص البرمجية | 0 USD | 6,400 USD، مرة واحدة |
| الخادم، من 40 إلى 80 USD شهريًا | من 1,440 إلى 2,880 USD | من 1,440 إلى 2,880 USD |
| بناء الطبقة الغائبة، من 6 إلى 12 شهرًا تطويريًا | من 18,000 إلى 96,000 USD | 0 USD |
| الصيانة، السنتان 2 و3 | من 7,200 إلى 38,400 USD | وقت تشغيلك أنت |
| الدعم حين ينقطع الـ bind | حسن نية المجتمع | مشمول |
| الإجمالي النقدي على ثلاث سنوات | من 26,640 إلى 137,280 USD | من 7,840 إلى 9,280 USD |
قبل أن يكتب إلينا أحد: نعم، الطرف الأدنى من عمود المصدر المفتوح قابل للتحقق. فإن كنت أنت المطوّر، ولم يكن لوقتك سعر سوقي لأنك كنت ستجلس إلى ذلك المكتب على أي حال، فإن عمود البناء ينهار نحو كلفة خادمك وصبرك. وهذا سيناريو حقيقي ونقوله صراحةً بعد قسمين. لكن ما ليس عليه هو أنه مجاني. إنه ستة إلى اثنا عشر شهرًا من حياتك المهنية، تُنفَق على البنية التحتية بدل العملاء، وتُدفع بالعملة الوحيدة التي لن تستطيع أن تفوترها لاحقًا.
ولاحظ شكل العمودين، لا مجاميعهما فحسب. أحدهما رقم صغير وثابت، معلوم بالكامل من اليوم الأول. والآخر مدى بتشتّت يبلغ خمسة أضعاف، بلا تاريخ انتهاء، وبذيل لا يتوقف أبدًا. وفي نشاط قائم على هوامش رقيقة لكل رسالة، فإن العمود القابل للتنبؤ يساوي شيئًا بذاته.
البند الذي لا يضعه أحد في جدول البيانات
وهنا الرقم الذي يقزّم كل ما سبق، والذي لا يظهر أبدًا في مقارنات البناء مقابل الشراء التي ينشرها الناس في المنتديات.
خذ حساب المنديل من دليل إعادة البيع: عشرة عملاء متوسطي الحجم بمعدل 300,000 رسالة شهريًا يساوون 3,000,000 رسالة، وبفارق سعر قدره 0.0030 USD يصبح ذلك 9,000 USD هامشًا إجماليًا كل شهر. والآن أخّر ستة أشهر اليومَ الذي تستطيع فيه تفعيل العميل رقم واحد، بينما تبني محرّك فوترة. تلك 54,000 USD من الهامش لم توجد قط، وهذه هي الحالة المتفائلة، لأنها تفترض أن العملاء ينتظرونك. وهم لا ينتظرون. إنهم يوقّعون مع المشغّل الذي كان جاهزًا في مارس.
لهذا ينتمي الزمن حتى أول إيراد إلى جدول المقارنة، ولهذا وضعناه فيه. كل شهر بناء هو شهر بلا بيع، في سوق لا يكون فيه الخندق الدفاعي تقنيًا على الإطلاق: بل هو جودة المسارات، والخدمة، والتصاق عميل صارت أنظمته موصولة أصلًا بواجهتك البرمجية. ولا يُكتسب أيّ من هذه الثلاثة بكتابة دفتر أرصدة. إنها تُكتسب بامتلاك عملاء، وهو ما يقتضي القدرة على استقبال عملاء، وهو تحديدًا الشيء الذي يقف البناء أمامه.
والحجة المضادة، بصراحة: هذا المنطق لا يعضّ إلا إن كان لديك فعلًا عملاء ينتظرون. أما إن كنت لا تزال تثبت وجود الطلب، فالإطلاق المتأخر لا يكلّفك شيئًا لأنه لم يكن ثمة إيراد لتؤخّره. وهو ما يقودنا إلى القسم الذي كان هذا المقال كله يتجه نحوه.
متى يظل المصدر المفتوح هو الخيار الصحيح
نفضّل أن نخسر الصفقة على أن نبيعك 6,400 USD من البرمجيات لم تكن بحاجة إليها. أربع حالات يكون فيها المجاني هو الصحيح.
أنت مستأجر واحد وليس لديك من تفوتره. شركة واحدة، ومشغّل واحد، وأنظمتك الخاصة ترسل رسائلك الخاصة. لا شجرة موزّعين، ولا أرصدة عملاء، ولا فواتير، ولا بوّابة. عندها يكون Kannel مع بضعة سكربتات هو الجواب الصحيح، وتكون منصّة متعددة المستأجرين ثقلًا تحمله بلا مقابل. وهذه أكثر الحالات شيوعًا التي نقول فيها: لا تشترِ.
لا تزال تختبر السوق. لا عملاء بعد، ولا عقود موقّعة، مجرد فرضية. بوّابة مجانية وجدول بيانات تجربة محترمة تمامًا، وتكلّفك عطلة أسبوع لتكتشف إن كان أحد سيدفع لك أصلًا. اشترِ المنصّة حين يصبح الجواب نعم، لا قبل ذلك.
برمجيات البوّابة هي منتجك. ثمة فرق تبني منصّة مراسلة لتبيعها، أو لديها متطلب غير اعتيادي حقًا لا يجسّده أي منتج تجاري. فإن كانت البرمجية هي النشاط لا ضريبةً على النشاط، فبالطبع تبنيها. بناؤها هو المقصد.
أحجامك وهوامشك ضئيلة. بضعة آلاف رسالة شهريًا بفارق سعر صغير لن تُطفئ ترخيصًا في أي أفق معقول، ولن تُطفئ ستة أشهر تطويرية أيضًا. ابقَ صغيرًا، وابقَ مجانيًا، وكن صادقًا مع نفسك بشأن أيّهما أنت.
لاحظ أن ثلاثًا من هذه الأربع هي الاختبار ذاته بثياب مختلفة: هل الطبقة التجارية هي منتجك، أم هي الشيء الواقف بينك وبين منتجك؟
أن تحسم هذا في فترة بعد الظهر
لا تحتاج إلى مستشار. تحتاج إلى أربع إجابات صادقة، مكتوبة في مكان لا تستطيع تجميلها فيه لاحقًا.
أولًا، هل لديك عملاء تفوترهم؟ إن كان الجواب لا، فتوقّف، واستخدم Kannel، وعُد حين يتغير الجواب. وإن كان نعم، فالطبقة التجارية ليست اختيارية، والسؤال الوحيد هو من يكتبها.
ثانيًا، كم يساوي الشهر التطويري لك فعليًا؟ استخدم رقمًا حقيقيًا: إما ما ستدفعه لشخص ما، أو ما يمكنك كسبه بتلك الساعات في عمل آخر. وإن كان جوابك “لا شيء، أنا أفعل هذا للمتعة”، فتلك إجابة مشروعة، وعمود البناء قد صار للتو رخيصًا جدًا. اكتبها على أي حال، لأنها تتغيّر في اللحظة التي تنشغل فيها فعلًا.
ثالثًا، كم يكلّف شهر تأخير؟ اضرب هامشك الإجمالي الشهري المتوقع في عدد شهور البناء. فإن كان ذلك الرقم أكبر من ترخيص، فالنقاش قد انتهى أصلًا، ولن يعيده أي تجويد في جدول البيانات.
رابعًا، من يردّ في الثانية صباحًا؟ ليس من يرقّع الأمر في وقت ما. بل من يتحمّل المشكلة بينما إرسال كشوف حساب عميل الليلي يخفق الآن. فإن كان الجواب “أنا، وأنا أيضًا الشخص الوحيد الذي يفهم كود الفوترة الذي كتبته”، فسعّر ذلك بصدق. هذا شخص، لا بند في ميزانية، وهو القيد الذي يضع بهدوء سقفًا لحجم ما يمكنك أن تصير إليه.
ثم احسم أمرك، واطمئن إليه. فإن أشارت الإجابات الأربع إلى المصدر المفتوح، فلك بركتنا واحترامنا، وسيخبرك دليل البوّابة ذاتية الاستضافة بما تُقدم عليه تشغيليًا. وإن أشارت إلى الجهة الأخرى، فما تشتريه ليس برمجيات في الحقيقة. إنه الستة إلى اثنا عشر شهرًا التي تكسبها لتقضيها مع عملائك بدلًا من ذلك، مُسلَّمة على هيئة ترخيص لمرة واحدة على خادمك أنت، مع طبقة تعدد المستأجرين والفوترة والبوّابات مكتوبة سلفًا، وKannel لا يزال تحتها، يؤدي العمل الذي طالما أجاده.
أسئلة
هل Kannel مجاني فعلًا؟
التنزيل مجاني والترخيص لا يكلّف شيئًا، تمامًا كما هو معلن. أما غير المجاني فهو كل ما يحتاجه نشاط المراسلة حوله: واجهة إدارة، وحسابات عملاء، وضبط للرصيد، وفوترة، وبوّابات بعلامة بيضاء، وتقارير يقرأها العميل، وشخص مسؤول حين ينقطع الـ bind في الثانية صباحًا. لم يزعم Kannel يومًا أنه يقدّم أيًا من ذلك، فهذا ليس نقدًا للبرمجية. إنه توصيف لنطاقها. أنت لا تختار بين أن تدفع وألّا تدفع: أنت تختار بين أن تدفع ترخيصًا أو أن تدفع لفريق تطوير.
كم يستغرق بناء الفوترة وتعدد المستأجرين فوق Kannel؟
من ستة إلى اثني عشر شهرًا تطويريًا للوصول إلى نسخة أولى تطمئن لوضع عميل يدفع عليها، وهذا التقدير يفترض مطوّرًا يفهم أصلًا SMPP وإشعارات التسليم ومنطق القيد المزدوج. الثمانون بالمئة الأولى تمضي سريعًا وتبعث على التفاؤل. أما العشرون بالمئة الأخيرة، أي الاسترجاعات عند الإخفاق النهائي، وخاصية عدم التكرار حتى لا تُحاسِب إعادةُ المحاولة مرتين، وقوائم الأسعار لكل مسار، والفوترة متعددة العملات، وسجل التدقيق الذي يحسم نزاعًا، فهي حيث تذهب الشهور حقًا. ثم يحتاج الأمر إلى صيانة إلى الأبد.
ألا يمكنني استخدام PlaySMS ببساطة، فلديه واجهة ويب أصلًا؟
لعملية صغيرة، أحيانًا نعم، وهو يستحق تقييمًا نزيهًا. يمنحك PlaySMS واجهة ويب، وحسابات مستخدمين، ورصيدًا بسيطًا، ووحدات بوّابة يمكنها الاعتماد على Kannel من تحت، وهذا يغطي مساحة أوسع بكثير من bearer مجرّد. أما حيث يتجاوزه المشغّلون فهو العمق: قوائم أسعار لكل مسار، ودفع مسبق ودفع لاحق جنبًا إلى جنب، وفوترة متعددة العملات، وشجرة موزّعين بعزل حقيقي، وعلامة بيضاء لكل مستأجر، وWhatsApp وRCS والصوت في المنصّة نفسها، وإنتاجية على مستوى المجمّعين. فإن لم يكن أيّ من ذلك في خارطة طريقك، فقد يكون الخيار المجاني هو الصحيح فعلًا.
هل يستبدل Smppcube منصّة Kannel؟
لا، بل يجلس فوقها. يأتي Smppcube ومعه Kannel داخل حزمته، ويستخدمه في ما يجيده تمامًا: الإمساك بروابط الـ bind مع مراكز SMSC وتحريك الرسائل. أما المنصّة فتملك الطبقة التي لم تكن يومًا ضمن نطاق أي bearer، أي الواجهة الرسومية وحسابات تعدد المستأجرين والفوترة والبوّابات والتقارير، ثم تمرّر الرسائل إلى الأسفل. وإن كنت تشغّل Kannel بروابط مضبوطة تثق بها، فهي تبقى لك. لذلك تدور هذه المقارنة حول طبقة الأعمال الغائبة، لا حول استبدال قطعة برمجيات اتصالات تعمل جيدًا.