الخلاصة

  • يحتسب Premium مستخدم Guest ضمن المقاعد المدفوعة. ويستثني Ultimate الضيف المستوفي للشروط، وكذلك الدور المخصص المبني على Guest إذا اقتصرت الصلاحية المضافة على read_code.
  • مهمة «القراءة فقط» لا تكفي لإثبات الإعفاء؛ فدور Reporter مدفوع، وقد تؤثر صلاحية أعلى في مشروع آخر داخل نطاق الاشتراك نفسه في وضع المستخدم.
  • المستخدم الذي يصبح قابلاً للاحتساب قد يشغل أولاً مقعداً مشترى وشاغراً. وعند تجاوز العدد المشترى، يبقى لأعلى عدد مسجل خلال فترة الحساب أثره حتى بعد تقليص الصلاحيات.

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

تجعل قواعد GitLab هذه العلاقة واضحة على نحو لافت. فوفق وثيقة إدارة المقاعد، التي جرت مراجعتها في 30 أكتوبر 2026، يدخل Guest في عدد المستخدمين المدفوعين على Premium. أما Ultimate فيتيح إعفاء الضيوف الذين تنطبق عليهم الشروط. الاسم الوظيفي واحد، لكن الباقة تغيّر مكانه في عملية الضرب التي تنتج السعر.

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

للقراءة بابان، وقد تختلف فاتورتهما

يتيح Guest العادي مشاركة محدودة، منها النقاش حول المسائل والملاحم. وتوضح صفحة الضيوف ومصفوفة الصلاحيات أنه لا يمنح الوصول المعتاد إلى شيفرة المستودعات الخاصة ولا حق دفع التعديلات إليها. يمكن منح من يحتاج إلى قراءة الشيفرة دور Reporter، وهو دور يحتسب مقعداً، رغم أنه لا يسمح بدفع التغييرات.

عبارة «سيطّلع فقط» تصف نية المستخدم. التسعير يتعامل مع صلاحيات الدور.

وفي Ultimate استثناء محدد في وثيقة الأدوار المخصصة: الدور المبني على Guest لا يستهلك مقعداً إذا كانت read_code هي الصلاحية الإضافية الوحيدة. بذلك يصبح ممكناً منح قراءة الشيفرة من خلال تركيب ضيق يبقى ضمن الإعفاء، بينما يُحتسب Reporter ضمن المقاعد المدفوعة.

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

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

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

الضيف قد يحمل دوراً آخر في الغرفة المجاورة

النظر إلى عضوية مشروع واحد لا يكفي. في GitLab.com، يتعلق الحكم بنطاق مساحة الأسماء التابعة للاشتراك. قد يظهر شخص بصفة Guest هنا ويحمل دوراً أعلى ومدفوعاً في مكان آخر داخل النطاق نفسه. يلزم جمع الصورة قبل احتسابه ضمن الضيوف المعفيين.

وفي الاتجاه المقابل، لا تُضاعف عضوية الشخص في عدة مشاريع أو مجموعات فرعية داخل المجموعة العليا المشتركة عدد مقاعده. يُحتسب المستخدم مرة واحدة. تجميع صفوف العضويات في جدول ثم تسميتها «مقاعد» ينتج رقماً لا يطابق منطق التسعير.

يتسع النطاق في Self-Managed ليشمل المثيل كله. وتشير الوثيقة إلى أن إنشاء المستخدم مشروعاً قد يمنحه دور Maintainer أو Owner ويجعله مستهلكاً لمقعد. لذلك يحتاج التدقيق في الاستضافة الذاتية إلى حدود مختلفة عن مراجعة مجموعة الاشتراك على GitLab.com. التشابه بين الشاشات لا يوحّد نطاق المحاسبة.

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

سحب الصلاحية لا يمحو الذروة

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

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

وفي الوقت نفسه، يمكن إعادة استخدام المقاعد ضمن العدد المشترى؛ فلا تُجمع إلى الأبد أسماء كل من مر بالاشتراك. التمييز بين العدد الحالي والذروة وتاريخ جميع المشاركين يمنع ثلاث قوائم مختلفة من التنكر في هيئة مؤشر واحد.

تشرح قواعد تسوية الزيادة أن التسوية تكون ربع سنوية أو سنوية بحسب الأهلية. تعتمد التسوية الربع سنوية على أعلى عدد في الربع وعلى الحساب النسبي للمدة المتبقية من الاشتراك وفق القواعد. أما التسوية السنوية فتطبق رسم الاشتراك السنوي على المستخدمين المضافين. افتراض رسم يومي موحد لكل العقود سيعطي ميزانية مبنية على قاعدة غير موجودة.

وتضع وثيقة إدارة الاشتراك خفض عدد المقاعد المشتراة عند التجديد. يمكن لمسؤول النظام تعديل الوصول اليوم، بينما ينتظر مسؤول المشتريات موعداً مختلفاً لتقليص الالتزام. سرعة الزر لا تنتقل تلقائياً إلى مدة العقد.

الباقة الأعلى تبيع طريقةً مختلفة للعد

بحسب السعر العام المنشور، يبلغ Premium مبلغ 29 دولاراً أميركياً لكل مستخدم شهرياً مع الدفع السنوي، بينما يتطلب Ultimate عرض سعر خاصاً. تنقص المقارنةَ الماليةَ قيمةُ العرض الفعلي لـUltimate وتوزيعُ المستخدمين بحسب الصلاحيات المطلوبة.

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

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

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