اختر نظام إدارة الوثائق (DMS) مفتوح المصدر إن كان لديك فريق يستطيع تشغيله وتأمينه وتحديثه بصفة دائمة، أو ميزانية لاشتراك دعم من الشركة المطوّرة، وكانت الميزات التي تحتاجها موجودة في الإصدار المجتمعي نفسه.
واختر نظامًا تجاريًا إن كنت تريد جهة واحدة مسؤولة بعقد عن التشغيل والتحديثات والدعم، أو إن كانت الميزات التي تحتاجها (سير العمل، أو إدارة السجلات) في الإصدارات المدفوعة فقط من المشروع المفتوح أصلًا.
السؤال الحاسم ليس «كم سعر الترخيص؟»، بل: من يتحمّل كل مسؤولية تشغيلية، وبأي ضمان؟
هذا دليل قرار لمدير تقنية المعلومات ومهندسي البنية ولجنة التقييم التقنية. نفترض أنك تعرف معنى «مفتوح المصدر»، وتحتاج أن تحسم أي الطريقين تقترحه على الإدارة، وبأي حجة. لن نقدّم هنا تقديرًا لتكلفة تشغيل النظام المفتوح بالريال، فذلك موضوع دليل مستقل: التكلفة التشغيلية لتحديث وصيانة DMS مفتوح المصدر. تركيزنا هنا على القرار نفسه: ما الذي يقدمه كل مشروع فعلًا بحسب مصادره الرسمية، ومتى يكون المفتوح خيارًا صحيحًا، وما الأسئلة التي تحسم الأمر.
القرار الحقيقي: من يحمل كل مسؤولية؟
الفرق بين المفتوح والتجاري ليس في وجود الكود أو غيابه، بل في توزيع المسؤوليات. المصفوفة التالية تقارن أربعة نماذج تشغيل شائعة:
| المسؤولية | مفتوح المصدر باستضافة ذاتية | مفتوح المصدر مع اشتراك دعم | تجاري سحابي | تجاري على خوادم الجهة |
|---|---|---|---|---|
| الخادم والتخزين والشبكة | فريقك | فريقك غالبًا | المورد | فريقك |
| التحديثات والترقيع الأمني | فريقك، وبحسب وتيرة إصدارات المشروع | فريقك، بإصدارات وإرشاد من المطوّر | المورد | مشتركة، وتُحدَّد في العقد |
| النسخ الاحتياطي واختبار الاستعادة | فريقك | فريقك | المورد، بحسب اتفاقية الخدمة | فريقك غالبًا |
| إعداد OCR العربي وقياس جودته | فريقك | فريقك بدعم المطوّر | المورد | المورد عند التركيب |
| ربط الدليل النشط والدخول الموحد | فريقك | فريقك بدعم المطوّر | المورد مع فريقك | المورد مع فريقك |
| الدعم عند العطل | منتدى مجتمعي بلا ضمان استجابة | بحسب عقد الدعم | المورد، بحسب مستوى الخدمة | المورد، بحسب مستوى الخدمة |
| التخصيص وتطويره | فريقك، مع حرية تعديل الكود بحسب الرخصة | فريقك أو المطوّر | المورد ضمن نطاق يُتفق عليه | المورد ضمن نطاق يُتفق عليه |
| الوصول إلى الكود المصدري | متاح بحسب الرخصة | متاح بحسب الرخصة | يُحدَّد في العقد | يُحدَّد في العقد |
اقرأ الجدول صفًا صفًا واسأل: هل لدى فريقي من يحمل هذه المسؤولية اليوم، وبعد ثلاث سنوات حين يتغير الفريق؟ إن كانت الإجابة «نعم» في أغلب الصفوف، فالمفتوح المصدر خيار واقعي. وإن كانت «لا» في صفوف الأمن والتحديثات والدعم، فإما اشتراك دعم، وإما نظام تجاري.
ما الذي يقدمه كل مشروع مفتوح المصدر فعلًا؟
المعلومات التالية من المستودعات والصفحات الرسمية لكل مشروع وقت إعداد المقال. الرخص وجداول الإصدارات تتغير، فتحقق منها قبل كراسة الشروط.
| المشروع | الرخصة كما في المستودع | ما يتضمنه الإصدار المفتوح | ما يجب التنبه إليه |
|---|---|---|---|
| Alfresco Community (Hyland) | GNU LGPL v3 | المستودع يتضمن وحدة إدارة السجلات، والتوثيق يغطي ربط LDAP والدخول الموحد الخارجي ونمذجة المحتوى | الفروق التفصيلية مع الإصدار التجاري (العنقدة، والدعم باتفاقية خدمة) لم نتحقق منها من صفحة رسمية مفتوحة، فاطلبها كتابة |
| Mayan EDMS | ملف الرخصة في المستودع الحالي GPL v2.0، بينما تصفها صفحة الميزات بأنها «متساهلة» | إصدارات، وبيانات وصفية حسب نوع المستند، ومحرك سير عمل، وسجل أحداث، وصلاحيات دقيقة، وOCR عبر Tesseract، ومصادقة ثنائية، وOpenID Connect | الدعم المجتمعي «بلا ضمان لأوقات الاستجابة»، والدعم المهني متاح من فريق Mayan. وحسم الرخصة يسبق أي تخصيص |
| Paperless-ngx | GNU GPL v3 | وسوم وأنواع مستندات وحقول مخصصة، وOCR عبر Tesseract لأكثر من 100 لغة، ونسخة PDF/A، وصلاحيات متعددة المستخدمين، وسير عمل | يحذّر المشروع من تشغيله على مضيف غير موثوق، لأن المعلومات تُخزَّن دون تشفير. وهو موجّه أساسًا للاستخدام الصغير. والعربية تحتاج تثبيت حزمة اللغة لأن الافتراضي الإنجليزية |
| OpenKM Community | GPL v2، ويصف المستودع الإصدار بأنه «Freeware» | OCR، وربط LDAP | سير العمل وإدارة السجلات في الإصدارات المدفوعة فقط، والتحديثات «سنوية» مقابل «شهرية» للمدفوعة، ومستودع GitHub مؤرشف |
| Nuxeo (Hyland) | معظم الكود Apache 2.0 | منصة إدارة محتوى قابلة للتخصيص والتوسيع | أحدث مصادر إصدارات LTS في مستودع خاص لمن لديه وصول، وتفاصيل الاشتراك غير متاحة في المصادر العامة |
خطأ شائع: تقييم المشروع بميزات إصداره التجاري ثم تنزيل إصداره المجتمعي. في OpenKM مثلًا، سير العمل غير موجود في Community. تحقق من جدول الإصدارات لكل ميزة إلزامية في متطلباتك قبل أن تبني الحجة على «مفتوح المصدر».
مسار القرار في أربع نقاط توقف
يبدأ المسار بالميزات، لأن غياب ميزة إلزامية عن الإصدار المفتوح يلغي الحجة من أساسها. ثم قدرة الفريق على التشغيل والتأمين، ثم وضوح الرخصة (وأهميتها تزداد إن كنت ستعدّل الكود)، ثم جودة OCR على مستنداتك العربية. إن اجتاز المشروع النقاط الأربع، انتقل إلى حساب تكلفة التشغيل. وإلا فالمقارنة الصحيحة بين عروض تجارية بنطاق متكافئ.
متى يكون المفتوح المصدر هو القرار الصحيح؟
فريق تطوير وتشغيل داخلي مستقر
جهة تقنية بطبيعتها، أو إدارة تقنية معلومات تشغّل أنظمة مفتوحة أخرى على Linux وقواعد بيانات، ولديها ممارسة ترقيع ومراقبة ونسخ احتياطي قائمة.
تخصيص عميق يمس جوهر النظام
نموذج محتوى أو منطق عمل لا يتسع له أي منتج تجاري، والجهة مستعدة لتحمّل صيانة هذا التخصيص مع كل ترقية.
قيود على الارتباط بمورد
سياسة تشترط امتلاك القدرة على تشغيل النظام وتعديله دون الاعتماد على جهة واحدة، مع قبول تحمّل المسؤولية التشغيلية.
نطاق صغير ومنخفض الحساسية
أرشيف فريق داخلي محدود لا يحتوي بيانات حساسة، مع وعي بتحذيرات المشروع نفسه بشأن الأمان.
وفي المقابل، يميل القرار إلى التجاري حين تكون الجهة حكومية أو شبه حكومية تحتاج مساءلة تعاقدية واضحة، أو حين يكون فريق التقنية صغيرًا ومشغولًا بأنظمة أخرى، أو حين يكون جدول الإطلاق قصيرًا ولا يحتمل منحنى تعلم منصة جديدة. هذه ليست قاعدة مطلقة، بل ما تكشفه مصفوفة المسؤوليات عادة.
إن اخترت التجاري: أسئلة تحميك من «القفل» على المورد
أقوى حجة للمفتوح المصدر هي الاستقلال عن المورد. يمكنك استعادة جزء كبير من هذه الميزة في العقد التجاري إن سألت الأسئلة الصحيحة:
أسئلة للمورد التجاري قبل التوقيع
- بأي صيغة تُصدَّر الوثائق وبياناتها الوصفية وسجل التدقيق عند انتهاء التعاقد؟ وهل جربتم ذلك مع عميل؟
- من يملك التخصيصات التي تُطوَّر لنا: الحقول، والنماذج، والمسارات، والتقارير؟
- هل تتيحون الكود المصدري أو جزءًا منه، أو ترتيب إيداع لدى طرف ثالث؟ وبأي شروط؟
- هل يتوفر النظام للتشغيل على خوادمنا إن احتجنا ذلك لاحقًا؟ وما متطلباته؟
- ما واجهات API المتاحة لأنظمتنا، وهل توثيقها متاح لفريقنا؟
- كيف تُدار التحديثات: من يقرر توقيتها، وهل تُختبر تخصيصاتنا قبلها؟
- ما مستوى الدعم وأوقات الاستجابة المتفق عليها، وكيف تُقاس؟
الأسئلة الثلاثة الأولى تفصّلها أدلة مستقلة: السورس كود والترخيص وحقوق التعديل قبل التعاقد، وتطوير نظام أرشفة خاص أم شراء حل قابل للتخصيص.
كيف تتعامل وثيقة مع هذه المسؤوليات؟
وثيقة نظام تجاري سعودي لإدارة الوثائق والأرشفة الإلكترونية. في مصفوفة المسؤوليات أعلاه يقع في عمودي «تجاري سحابي» و«تجاري على خوادم الجهة»:
- أربعة نماذج نشر: سحابة مشتركة، وسحابة خاصة، واستضافة محلية على خوادم الجهة، ونشر هجين يجمع بينها، مع خيار استضافة بخوادم داخل المملكة. التفاصيل في خيارات النشر والاستضافة.
- ما يأتي جاهزًا دون تطوير: OCR للعربية والإنجليزية، وسير عمل للموافقات متعدد المراحل، وسجل تدقيق محمي من التلاعب وقابل للتصدير، وصلاحيات حسب الأدوار على مستوى المجلد والمستند، وتكامل مع Active Directory وLDAP، ودخول موحد عبر SAML/OIDC. ويتوفر OCR وسير العمل من الباقة الاحترافية فما فوق.
- التكامل: تكاملات جاهزة مع Microsoft 365 وSAP وOracle والبريد، وREST API للأنظمة الأخرى، ويُحدَّد نطاق كل تكامل عبر API في العرض الفني.
- الدعم والتدريب بالعربية: مشمولان في كل الباقات، ويختلف مستوى الدعم بحسب الباقة، والدعم على مدار الساعة في المؤسسية.
- يُحدَّد في العرض: نموذج الترخيص التفصيلي، وشروط الكود المصدري، وملكية التخصيصات. اطرح عليها الأسئلة السبعة أعلاه واطلب إجاباتها مكتوبة.
الخطوة التالية
- املأ مصفوفة المسؤوليات بأسماء أشخاص من فريقك، لا بعبارة «فريق التقنية».
- تحقق من جدول الإصدارات لكل ميزة إلزامية في المشروع المفتوح الذي تفكر فيه.
- اختبر OCR العربي على 50 صفحة من مستنداتك في الخيارين.
- اطلب عرضًا تجاريًا بالنطاق نفسه لتقارن رقمًا برقم عبر نموذج طلب عرض السعر. وإن كان الخيار المجاني عمومًا هو ما يطرحه زملاؤك، فراجع نظام أرشفة مجاني أم مدفوع.
المصادر
اطلب تقديراً لنطاق مشروعك
أرسل عدد المستخدمين وحجم الأرشيف ونموذج الاستضافة المطلوب، ونعود إليك بعرض يوضّح ما يشمله السعر وما يحتاج نطاقاً إضافياً.
- عدد المستخدمين المتوقع والإدارات المشاركة
- حجم الأرشيف الحالي تقريباً (عدد الملفات أو الصفحات أو الحجم بالجيجابايت) ونسبة الورقي منه
- نموذج الاستضافة المفضل: سحابة داخل المملكة أو خوادم الجهة
- النظام الحالي للملفات والأنظمة المطلوب التكامل معها
الهاتف وواتساب: +966 56 533 0501 — الأحد إلى الخميس 9 صباحاً حتى 6 مساءً.