من مكتب ألماني صغير إلى المسرح العالمي

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

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

لفهم SUSE، عليك أولاً أن تفهم العالم الذي وُلدت فيه؛ فقد كان ذلك العالم ساحة قتال.

وُلد نظام التشغيل يونكس (Unix) في مختبرات “بيل” عام 1969 على يد كين طومسون ودينيس ريتشي، وكان يتسم بالرصانة والقابلية للنقل والانسجام المنطقي. كانت مبادؤه التصميمية — أدوات صغيرة تؤدي مهمة واحدة بإتقان، والنص كواجهة عامة، والبرامج القابلة للتركيب — مقنعة لدرجة أنها لا تزال بعد نصف قرن، تشكل ركيزة الحوسبة الحديثة. وعندما مُنعت شركة AT&T من تسويق “يونكس” بموجب قرار قضائي، انتشر نظام التشغيل في الجامعات، يُنقل من قسم إلى آخر ويُشارك مجاناً. وأنشأت جامعة كاليفورنيا في بيركلي نسختها الخاصة (BSD)، وعلى مدى عقد من الزمن ازدهر يونكس في أجواء من التعاون الأكاديمي التي بشّرت بحركة المصادر المفتوحة قبلها بعشرين عاماً.

ثم رُفع قرار الحظر، وآلت الأمور إلى الفوضى.

بدأت AT&T تفرض رسوم تملك، فاشتقّت الشركات نسخاً من الشيفرة المصدرية (Forks)، وأضافت ملكيتها إليها، لربط العملاء بأنظمتها. كان لشركة Sun نظام SunOS، ولدى IBM نظام AIX، ولدى HP نظام HP-UX. كان كل نظام منها غير متوافق مع الآخر، وكان كل واحد منها يكلف عشرات أو مئات الآلاف من الدولارات.

وفي الوقت نفسه، رفعت AT&T دعوى على جامعة كاليفورنيا بسبب BSD، مما خلق غموضاً قانونياً خيّم على عالم البرمجيات الحرة لسنوات. لولا تلك الدعوى، لربما التفّ العالم حول FreeBSD، لكن الغيمة القانونية خلقت فراغاً، ودخل لينكس من خلاله.

بحلول عام 1991، إذا أردت تشغيل نظام شبيه بيونكس على حاسوبك الشخصي، كانت خياراتك بائسة. في هذه الفجوة ظهر “لينوس تورفالدس”، الطالب الفنلندي البالغ من العمر 21 عاماً، الذي أراد تشغيل يونكس على حاسوبه ولم يملك ثمنه. نشر تورفالدس رسالته الشهيرة في 25 أغسطس 1991:

“مرحبًا بالجميع.. أنا أعمل على نظام تشغيل (حر) (مجرد هواية، ولن يكون كبيراً واحترافياً مثل GNU) لأجهزة 386 المقلدة..”

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

في الولايات المتحدة، أنشأ باتريك فولكيردينغ نظام Slackware، وبدأ إيان موردوك مشروع Debian. أما في ألمانيا، فقد قرر أربعة رجال أنهم يستطيعون تقديم ما هو أفضل.

أربعة رجال في نورمبرغ

تُختزل قصة تأسيس SUSE عادة في جملة واحدة: أربعة ألمان أسسوا شركة في عام 1992. لكن من كانوا حقاً؟

• رولاند دايروف (Roland Dyroff): كان عقل المجموعة التجاري؛ امتلك خلفية في الرياضيات والأعمال، وفهم أن التكنولوجيا العظيمة بلا نموذج عمل هي مجرد هواية.

• توماس فيهر (Thomas Fehr): كان خبير الأنظمة، مطلعاً بعمق على إدارة يونكس والشبكات.

• بورتشارد شتاينبيلد (Burchard Steinbild): جلب عمقاً تقنياً إضافياً؛ وكان، كالبقية، نتاج النظام التعليمي الألماني الصارم.

• هوبير مانتل (Hubert Mantel): كان أعمق العقول التقنية؛ أصبح فيما بعد المدير التقني لـ SUSE، وكان مسؤولاً عن تخصيصات النواة لسنوات.

ما جمعهم لم يكن رؤية كبرى، بل ملاحظة عملية: يونكس قوي ولكنه باهظ الثمن، ولينكس حر ولكنه غير قابل للاستخدام. الفجوة بينهما كانت الفرصة.

أسسوا شركة S.u.S.E. (Software und Systementwicklung — تطوير البرمجيات والأنظمة) في 2 سبتمبر 1992 في نورمبرغ، بافاريا. سُجلت الشركة كشركة ذات مسؤولية محدودة (GmbH) برأس مال ضئيل. لم يكن هناك رأس مال مغامر، ولا استثمار جريء، ولا اجتماعات في وادي السيليكون؛ مجرد أربعة رجال ومكتب صغير وقناعة بأن لينكس يمكن أن ينجح للمحترفين.

حمل الاسم صدى قد يكونون قصدوه أو لم يقصدوه؛ “كونراد زوسه” (Konrad Zuse) — الذي يُنطق قريباً من S.u.S.E — كان المهندس الألماني الذي بنى Z3 عام 1941، أول حاسوب رقمي قابل للبرمجة وآلي بالكامل في العالم. قدم المؤسسون روايات متباينة حول ما إذا كان الاسم تحية متعمدة، لكن الصدى الصوتي كان واضحاً للآذان الألمانية، وأضفى على الشركة الناشئة وزناً تاريخياً وارتباطاً بالهندسة الألمانية المبتكرة.

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

لم يكن أول منتج لـ S.u.S.E بالمعنى الدقيق ملكاً لها. في عام 1993، بدأت الشركة ببيع نسخة مترجمة (ألمانية) من Slackware، التوزيعة الأمريكية التي أنشأها باتريك فولكيردينغ. أخذت S.u.S.E نظام Slackware، وترجمته للألمانية، وأضافت التوثيق، وأصلحت الأخطاء، وغلّفته في صندوق ليُباع في المكتبات وعبر البريد.

لم يكن هذا انتحالاً، بل هكذا يعمل المصدر المفتوح. كانت Slackware متاحة تحت تراخيص حرة، وإضافة القيمة عبر الترجمة والتوثيق والتغليف كان أمراً مشروعاً تماماً. ما قدمته S.u.S.E هو سهولة الوصول؛ ففي عام 1993، واجه مسؤول الأنظمة الألماني حاجزين: التعقيد التقني، والحاجز اللغوي للتوثيق الإنجليزي. أزالت S.u.S.E الحاجز الثاني وخفّضت الأول كثيراً. هكذا كسبت SUSE ولاءها الأول: بجعل لينكس قابلاً للعيش.

خلال العامين التاليين، استبدل المؤسسون تدريجياً مكونات Slackware بمكوناتهم الخاصة، وبحلول عام 1996، أنشأوا شيئاً لا يخطئه أحد: S.u.S.E. Linux. كان منذ البداية ذو طابع أوروبي واضح: منهجي، موثق جيداً، مدفوع بالهندسة، ويركز على الاعتمادية لا البهرجة.

لفهم كيف بنت SUSE الولاء، تخيل متجر كمبيوتر في التسعينيات. بينما كانت مايكروسوفت تسيطر، كانت SUSE توفر صناديق تضم أقراصاً مدمجة وأدلة مطبوعة سميكة. كانت هذه الأدلة تعكس مفهوم الـ Gründlichkeit (الإتقان المتناهي)؛ فبينما كانت التوزيعات الأخرى تكتفي بملفات نصية بسيطة، كانت SUSE توفر مراجع تصلح ككتب جامعية، مما جعل مسؤولي الأنظمة يأخذونها على محمل الجد.

YaST جوهرة التاج

بين عامي 1993 و1996، استبدلت SUSE مكونات Slackware بمكوناتها الخاصة، وكان قلب هذا التحول هو أداة YaST (Yet another Setup Tool) التي قُدمت عام 1994.

لم يكن YaST مجرد مُثبّت، بل كان إطاراً كاملاً لإدارة النظام. قبل YaST، كان عليك تحرير ملفات نصية خطيرة يدوياً، مثل:

• /etc/fstab لربط الأقراص (أي خطأ يمنع الإقلاع).

• /etc/XF86Config لإعدادات الشاشة (أي خطأ قد يتلف الشاشة مادياً).

غيّر YaST هذا كله عبر واجهات قائمة على القوائم. كانت الفلسفة هي: نظام التشغيل لا يكتمل بمجرد بدء تشغيله، بل يكتمل عندما يمكن إدارته بمنطقية ويسر.

هناك قصة تُروى في أوساط SUSE عن تحدي مسؤول انظمة متشكك لفريق S.u.S.E لتثبيت لينكس على حاسوب محمول (وهي مهمة مستحيلة آنذاك)؛ فقام YaST بفحص العتاد، وضبط الشاشة والشبكة في أقل من ساعة، ليتحول ذلك المسؤول إلى عميل فوري. حوّل YaST لينكس من هواية للمخترقين إلى نظام محترف.

جدل ترخيص YaST

أطلقت S.u.S.E أداة YaST في البداية بموجب ترخيص احتكاري، حيث سُمح باستخدامه فقط مع SUSE Linux. كان قراراً تجارياً لحماية ميزتها التنافسية، لكنه أثار غضب مجتمع البرمجيات الحرة؛ جادل مجتمع البرمجيات الحرة بأن هذا ينتهك روح الحرية، ورفضت دبيان (Debian) تضمينه. حُلّ التوتر عام 2004 بعد استحواذ نوفيل (Novell) وإعادة ترخيص YaST تحت رخصة GPL، لكن بحلول ذلك الوقت كانت التوزيعات الأخرى قد طورت أدواتها، مما حال دون تحول YaST إلى معيار عالمي.

البوتقة الأوروبية

لم يكن ظهور SUSE في ألمانيا صدفة؛ فقد كانت ألمانيا بيئة خصبة لأسباب عديدة:

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

2. ضرورة الخصوصية: التاريخ الألماني مع قوى الأمن “الغستابو” و"الشتازي" جعل الشعب الألماني شديد الحساسية تجاه الخصوصية والمراقبة. المصادر المفتوحة تتيح فحص الشيفرة والتأكد من عدم وجود تجسس، وهو ما ناسب المؤسسات الألمانية تماماً.

3. المسار الأكاديمي: الجامعات الألمانية تبنت لينكس مبكراً، مما خلق جيلاً من الخبراء الذين نقلوا SUSE إلى سوق العمل.

4. السيادة التقنية: قلق الحكومات الأوروبية من التبعية لشركات أمريكية (مثل مايكروسوفت) دفع المكتب الاتحادي لأمن المعلومات (BSI) للتوصية بالمصدر المفتوح منذ التسعينيات.

وتُعد قوانين حماية البيانات الاتحادية الألمانية، Bundesdatenschutzgesetz، التي صدرت لأول مرة في 1977 وشُددت مرارًا، من الأكثر صرامة في العالم. وكانت البلاد قوة دافعة وراء اللائحة العامة لحماية البيانات في الاتحاد الأوروبي، GDPR. وكانت البرمجيات مفتوحة المصدر تتوافق طبيعيًا مع هذه القيم. فعندما تستخدم برمجيات مفتوحة المصدر، يمكنك فحص الشيفرة المصدرية. ويمكنك التحقق مما تفعله، وما البيانات التي تجمعها، وأين ترسلها. أما عندما تستخدم برمجيات احتكارية، فأنت تثق بالمورّد. وبالنسبة للجهات الألمانية، ولا سيما الوكالات الحكومية والمؤسسات المالية والشركات التي تتعامل مع بيانات حساسة، لم تكن هذه الشفافية مجرد تفضيل فلسفي، بل كانت مطلبًا عمليًا.

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

وكان لثقافة الحوسبة في ألمانيا حسّ أوسع أيضًا: Gründlichkeit، أي الشمول والدقة والاهتمام بالتفاصيل. وعكست SUSE Linux هذا الحس. فبينما كانت التوزيعات الأمريكية غالبًا خشنة بعض الشيء ومحسّنة لسرعة التطوير، كانت SUSE مصقولة، موثقة جيدًا، ومختبرة بعناية. وقد لاقى ذلك صدى عميقًا لدى المهندسين ومسؤولي الأنظمة الألمان الذين قدّروا الاعتمادية والوضوح على حساب الحداثة.

بِاخْتِصَار، شكّلت أوروبا SUSE بخمس طرق رئيسية: اللغة والترجمة اللذان بنيا الثقة في الأسواق الناطقة بالألمانية؛ والتوجه نحو القطاع العام والمؤسسات بما يلائم المنظمات الأوروبية المستقرة والحساسة للمعايير؛ وثقافة هندسية تضع العمق فوق المسرح التسويقي؛ ونمو أقل اعتمادًا على رأس المال المخاطر، مما حفظ الجدية التقنية لكنه حدّ من التوسع العدواني؛ والانفتاح على التعددية في بيئات تقنية المعلومات، مما علّم SUSE أن تعيش في عالم متعدّد بدلًا من افتراض شركة تجارية واحدة كقصة كونية.

المنافسون (Red Hat)

تأسست Red Hat في مارس 1993، وكانت المنافس المباشر لـ SUSE، لكن المسارات تباعدت، بسبب:

• الاكتتاب العام (IPO): طرحت Red Hat أسهمها في البورصة عام 1999 وحصدت مليارات الدولارات، مما منحها قوة مالية هائلة للتوسع.

• الفجوة المالية: في ألمانيا، لم يكن هناك سوق رأس مال مخاطر يضاهي وادي السيليكون؛ لذا نمت SUSE بشكل طبيعي وبطيء، مما حدّ من توسعها العالمي مقارنة بـ Red Hat.

• الشهادات: استثمرت Red Hat في بناء نظام شهادات (RHCE) أصبح المعيار العالمي، مما جعل أصحاب الأعمال يفضلون RHEL لأنهم يجدون خبراء معتمدين له بسهولة.

لماذا لم تفعل SUSE ذلك؟ الأسباب تشمل: ضعف سوق رأس المال التكنولوجي في ألمانيا (Neuer Markt)، غياب ثقافة رأس المال المخاطر الهجومية في أوروبا آنذاك، والنزعة الألمانية التي تفضل الاستقرار والربحية على النمو الممول بالخسائر.

كما طورت Red Hat نظام RPM الذي أصبح معياراً، وأطلقت RHEL عام 2002 بضمانات دعم طويلة الأمد طلبتها الشركات الكبرى. كما استثمرت بكثافة في الشهادات المعتمدة (RHCE) التي أصبحت الأشهر في المجال، وبنت ماكينة مبيعات ضخمة في أمريكا وآسيا لم تستطع SUSE مجاراتها.

بينما نجد Debian: النقيض الأيديولوجي. تأسست Debian عام 1993 كمشروع مجتمعي خالص يقوده المتطوعون بصرامة أيديولوجية تجاه البرمجيات الحرة. احتلت SUSE منطقة وسطى بين طموح Red Hat المؤسسي ونقاء Debian الأيديولوجي؛ كانت شركة تجارية لكنها تقدّر الهندسة على التسويق، مما أكسبها مصداقية لدى الشركات والمجتمعات معاً، لكنه حرمها من الهيمنة التجارية المطلقة أو الولاء المطلق للمتطرفين للمصدر المفتوح.

دور الحكومة الأمريكية والسياسة الأمنية

المنافسة لم تكن تقنية فحسب. الحكومة الأمريكية هي أكبر مشترٍ للتقنية في العالم، وهناك قوانين مثل (Buy American Act) وتفضيلات المشتريات الفيدرالية التي منحت Red Hat ميزة هيكلية. الحصول على شهادات أمنية مثل (DISA STIGs) كان أسهل لشركة أمريكية تملك موظفين بتصاريح أمنية أمريكية. هذا الثقل الحكومي لم يكن مؤامرة بل واقعاً هيكلياً استفادت منه Red Hat ولم تستطع SUSE (الألمانية) الوصول إليه من نورمبرغ.

نظام SELinux مقابل AppArmor

طورت وكالة الأمن القومي الأمريكية (NSA) نظام SELinux ودمجته Red Hat في نظامها. ورغم قوته التقنية، إلا أن أصوله الاستخباراتية أثارت الريبة في أوروبا.

• SELinux: يعتمد على الملصقات (Labels)، وهو قوي جداً ولكنه معقد لدرجة أن الكثير من مسؤولي الأنظمة يغلقونه بدلاً من إصلاحه.

• AppArmor: يعتمد على المسارات (Paths)، وهو أسهل في الفهم والتهيئة.

اختارت SUSE نظام AppArmor؛ وهو نظام أمني أكثر بساطة ووضوحاً من الناحية الإدارية، ولم يكن يحمل شبهة التعاون الاستخباراتي، مما جعله الخيار المفضل في البيئات الأوروبية الحساسة للخصوصية.

الابتكارات التقنية

إدارة الحزم وZypper

بينما اعتمدت SUSE صيغة حزم RPM، فقد بنت فوقها أدواتها الخاصة لإدارة الحزم. وكان أهمها Zypper، وهو مدير حزم سطري يستخدم محلّل تبعيات يسمى libzypp، قائمًا على خوارزمية SAT solver، وهو على الأرجح أكثر تعقيدًا من الأدوات المكافئة في توزيعات أخرى. وحيث كان yum لدى Red Hat أحيانًا يواجه صعوبة مع سلاسل التبعيات المعقدة، كان محلل Zypper القائم على SAT قادرًا على التعامل معها بسلاسة. وكانت هذه ميزة تقنية تكاد تكون غير مرئية للمستخدم النهائي، لكنها كانت موضع تقدير عميق لدى مسؤولي الأنظمة الذين يديرون مئات الأجهزة.

Btrfs وابتكار نظم الملفات

كانت SUSE من أوائل الداعمين والمتحمسين لنظام الملفات Btrfs، وهو نظام ملفات من الجيل التالي في لينكس يوفّر اللقطات snapshots ، والتحقق بالمجموعات checksumming، وإدارة الأحجام الديناميكية dynamic volume management. وبدأت SUSE بتضمينه كنظام ملفات جذري افتراضي في SUSE Linux Enterprise Server 12 في 2014، لتصبح أول توزيعة لينكس مؤسسية كبرى تفعل ذلك. أما Red Hat فاتخذت نهجًا أكثر حذرًا، فأدرجت Btrfs كنسخة تجريبية في RHEL 7، لكنها لم ترفعه إلى دعم كامل، ثم أزالته بالكامل في RHEL 8.

وكان تنفيذ SUSE لـ Btrfs مقترنًا بأداة Snapper، وهي أداة لإدارة لقطات Btrfs مدمجة مع YaST ونظام إدارة الحزم. وقبل كل تحديث للنظام، كانت Snapper تنشئ لقطة تلقائيًا. وإذا تسبب التحديث في مشاكل، استطاع المدير الرجوع إلى الحالة السابقة للتحديث بأمر واحد. وحوّل ذلك التحديثات من عمليات مثيرة للقلق إلى إجراءات روتينية قابلة للرجوع.

كما أتاح اقتران Btrfs وSnapper ما يُعرف بـ التحديثات المعاملاتية transactional updates، حيث تُطبَّق تغييرات النظام ككتلة واحدة Atomic. فإما أن ينجح التحديث كله، أو يعود النظام إلى الحالة السابقة. وكانت هذه الفكرة، التي رائدتها SUSE، ستصبح لاحقًا مركزية في تصميم الأنظمة غير القابلة للتغيير والمنصات المحسّنة للحاويات.

استثمرت SUSE كثيرًا في تطوير Btrfs، ووظفت عدة من المطورين الأساسيين للنظام. وقد خفف هذا من مخاطر أن تكون من أوائل المتبنين، لكنه تطلب التزامًا مستمرًا لم تكن Red Hat مستعدة لتقديمه.

خدمة البناء المفتوحة Open Build Service (OBS)

من أهم إسهامات SUSE في منظومة المصادر المفتوحة الأوسع، والتي لا تحظى بالتقدير الكافي، Open Build Service، التي طُورت أصلًا بوصفها openSUSE Build Service. وتقوم OBS بأتمتة إنشاء البرمجيات وحزمها: يرسل المطور الشيفرة المصدرية، ثم تقوم OBS ببنائها لعدة توزيعات ومعماريات وإصدارات، وتنتج حزمًا جاهزة للتثبيت.

كان قرار جعل OBS أداة عابرة للتوزيعات، لا أداة محصورة بـ openSUSE، قرارًا مقصودًا يعكس فلسفة SUSE القائمة على مشاركة تطويراتها مع مجتمع المصدر المفتوح الأوسع. ومن خلال جعل OBS مفيدة للمنظومة بأكملها، خلقت SUSE حسن نية، وجذبت مساهمين، وأثبتت نفسها كمواطن صالح في مجتمع المصادر المفتوحة. وتستخدمها الآن آلاف المشاريع عبر النظام البيئي الكامل للينكس.

KIWI وAppArmor ومساهمات أخرى

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

كما كانت SUSE من أكثر الجهات إسهامًا في نواة لينكس نفسها. فقد قدّم مهندسو SUSE إسهامات أساسية في إدارة الذاكرة، وتطوير أنظمة الملفات، ولا سيما Btrfs وXFS، واختبار النواة، ودعم العتاد. ويُعد Greg Kroah-Hartman، الذي عمل في SUSE قبل انتقاله إلى مؤسسة Linux Foundation، من أكثر المساهمين إنتاجًا في تاريخ النواة. كما قدم Jeff Mahoney وTakashi Iwai، الصيانة الأساسية لمنظومة الصوت ALSA، وغيرهما كثير من مهندسي SUSE إسهامات دائمة. وكانت SUSE أيضًا من كبار المساهمين في systemd وGCC وglibc وQEMU/KVM.

علاقة KDE

تستحق علاقة SUSE ببيئة سطح المكتب KDE ذكرًا خاصًا. فبينما اصطفّت Red Hat مع GNOME، أصبحت SUSE البيت الروحي لـ KDE. وكان KDE نفسه مشروعًا أوروبيًا بدأ عام 1996 على يد ماتياس إتريش Matthias Ettrich، طالب علوم حاسوب ألماني في جامعة توبنغن. وكانت نزعة KDE التصميمية، الغنية بالميزات والقابلة للضبط والشاملة، تتوافق تمامًا مع ثقافة SUSE الهندسية.

وظّفت SUSE عددًا كبيرًا من مطوري KDE، وأسهمت كثيرًا في تطويره، وجعلته سطح المكتب الافتراضي. وكان الانقسام بين KDE وGNOME، في جوانب كثيرة، انعكاسًا لانقسام ثقافي أعمق. فـ GNOME مثّل فلسفة التبسيط، أي إزالة الميزات وتقليل الخيارات. أما KDE فمثّل فلسفة التمكين، أي توفير أكبر قدر ممكن من الخيارات والثقة بأن المستخدمين سيضبطون الأشياء بما يلائمهم. وإن اصطفاف SUSE مع KDE وRed Hat مع GNOME يعكس رؤيتين مختلفتين جذريًا للعلاقة بين البرمجيات ومستخدميها.

الرحلة المؤسسية

Novell 2003–2010

في 4 نوفمبر 2003 أعلنت Novell استحواذها على SUSE Linux AG مقابل نحو 210 ملايين دولار. وبالنسبة إلى موظفي SUSE، كانت تلك لحظة امتزج فيها الأمل بالقلق.

كان الأمل حقيقيًا. فـ Novell، رغم تراجع أعمال NetWare لديها، كانت شركة كبيرة تملك موارد مهمة، ومبيعات عالمية، وعلاقات عميقة مع عملاء المؤسسات. وكان رئيسها التنفيذي يتحدث بحماس عن تحويل Novell إلى شركة لينكس.

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

هناك حكاية يرويها أكثر من واحد من قدامى SUSE عن الاجتماع العام الأول بعد الاستحواذ. فقد جاء مسؤولو Novell إلى نورمبرغ، وتحدثوا بالإنجليزية، وتكلموا عن “التآزر” و"فرص السوق" و"المواءمة الاستراتيجية". واستمع مهندسو SUSE بأدب، ثم عادوا إلى مكاتبهم. وكان الشعور غير المعلن واضحًا: الأميركيون يستطيعون الحديث عن الاستراتيجية كما يشاؤون، ونحن سنواصل فعل ما اعتدنا عليه، أي بناء برمجيات جيدة.

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

مشروع openSUSE في 2005

كان من أهم قرارات عصر Novell إنشاء مشروع المجتمع openSUSE في أغسطس 2005، على غرار مشروع Fedora لدى Red Hat. وقد رسخ openSUSE الفصل بين توزيعة مجتمعية حرة، يشرف عليها مجلس مجتمعي، وبين SUSE Linux Enterprise، المنتج التجاري الذي يحصل على اختبارات إضافية وشهادات ودعم طويل الأمد.

ولم يكن openSUSE مجرد تمرين تسويقي. فقد فتحت SUSE فعليًا عمليات التطوير، ونقلت الشيفرة إلى مستودعات عامة، ودعت المجتمع إلى المشاركة. وكانت Open Build Service مساهمة سخية بشكل خاص، صممت منذ البداية لتكون مفيدة لمنظومة لينكس بأسرها.

كما ابتكر openSUSE مشروع Tumbleweed، وهو إصدار يُحدّث باستمرار إلى أحدث الإصدارات من دون الحاجة إلى إعادة تثبيت دورية، وكان في الأصل من بنات أفكار Greg Kroah-Hartman. وقد منح الجمع بين openSUSE Leap، وهو إصدار منتظم يتماشى مع SUSE Linux Enterprise، وopenSUSE Tumbleweed، وهو إصدار مستمر، المستخدمين خيارًا فريدًا بين الاستقرار والحداثة.

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

صفقة مايكروسوفت: يوم انقلب المجتمع

في 2 نوفمبر 2006 أعلنت Novell ومايكروسوفت معًا شراكة هزّت مجتمع لينكس. تضمنت الصفقة ثلاثة عناصر: تعاونًا تقنيًا حول التوافق البيني، وتعهدات متبادلة بشأن براءات الاختراع، وتعاونًا في المبيعات بحيث يوصي مندوبو مبيعات مايكروسوفت بـ SUSE Linux Enterprise للعملاء.

كان التعاون التقني والتجاري أقل إثارة للجدل نسبيًا. أما اتفاق براءات الاختراع فكانت القُنبُلة.

وقد غطى التعهد عملاء Novell فقط، لا مستخدمي توزيعات لينكس الأخرى. وخلق ذلك ما سماه النقاد نظام حماية مفاده: استخدم SUSE وستكون آمنًا من مطالبات مايكروسوفت ببراءات الاختراع، واستخدم أي شيء آخر وستكون وحدك. وبدا الأمر كأنه يثبت صحة ادعاءات الرئيس التنفيذي لمايكروسوفت ستيف بالمر Steve Ballmer السابقة، بأن لينكس ينتهك أكثر من 200 براءة اختراع لمايكروسوفت.

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

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

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

هل استقال مهندسون بسبب الصفقة؟ نعم، بعضهم فعل ذلك، وإن كان العدد الدقيق يصعب تحديده. وغادر خصوصًا من كان أكثر نشاطًا في المجتمع وأكثر التزامًا بمبادئ البرمجيات الحرة خلال الأشهر التالية للإعلان، بعضهم إلى Red Hat وبعضهم إلى شركات مصادر مفتوحة أخرى. وكان قانون العمل الألماني، الذي يوفر حماية قوية للموظفين عبر Betriebsräte، أي مجالس العمال، سيمنح آليات للعمل الجماعي، لكن استخدامها كان سيشكّل تصعيدًا دراميًا لم يرغب معظم الموظفين فيه. وما حدث بدلًا من ذلك كان أكثر تشتتًا: محادثات خاصة، وانتقادات هادئة، وتغير ملموس في المعنويات.

وقد وصف عدة موظفين سابقين الفترة اللاحقة لصفقة مايكروسوفت بأنها الأصعب في مسيرتهم المهنية، لا بسبب العمل نفسه، بل بسبب التوتر الدائم بين الولاء لصاحب العمل والولاء للمجتمع. واضطرت SUSE إلى سنوات من إعادة بناء الثقة.

ومن الحكايات الدالة، ما جرى في قمة نواة لينكس لعام 2006، حين واجه عدد من مطوري النواة موظفي Novell، مطالبين بمعرفة ما إذا كانت Novell تعتقد أن لينكس ينتهك براءات اختراع مايكروسوفت. وقيل إن أحدهم أجاب: “نحن مهندسون. نحن نكتب الشيفرة. نحن لم نبرم هذه الصفقة، وإن سألتمونا بشكل خاص فسوف نقول لكم رأينا فيها.”

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

Attachmate 2010–2014

في 22 نوفمبر 2010 أعلنت مجموعة Attachmate، وهي شركة تقنية مدعومة برأس مال خاص، استحواذها على Novell مقابل نحو 2.2 مليار دولار. واكتمل الاستحواذ في أبريل 2011.

وأعادت Attachmate تنظيم Novell فورًا إلى أربع وحدات أعمال، كانت إحداها SUSE. وأعطى ذلك SUSE استقلالية أكبر مما كانت عليه تحت Novell، مع قيادة وميزانية واتجاه استراتيجي خاص بها. وعُيّن التنفيذي الألماني نيلس براوكمان Nils Brauckmann رئيسًا لـ SUSE، وقاد الشركة خلال السنوات التالية من التحول.

لكن الانتقال كان صعبًا أيضًا. فقد سرحت Attachmate عددًا كبيرًا من موظفي Novell. وأصبح مشروع Mono، وهو تنفيذ مفتوح المصدر لإطار مايكروسوفت .NET طُوّر تحت قيادة ميغيل دي إيكاثا Miguel de Icaza، شبه مهمل عندما سُرّح فريقه بالكامل. وانتقل ميغيل دي إيكاثا وعدة زملاء لتأسيس Xamarin، التي استحوذت عليها مايكروسوفت لاحقًا.

وكانت عمليات التسريح صعبة على مجتمع SUSE لأن بعض من تم الاستغناء عنهم كانوا من المساهمين المعروفين في مشاريع المصادر المفتوحة. لكن قيادة براوكمان ثبتت الشركة. فقد ركز SUSE على كفاءاته الأساسية، أي لينكس المؤسسي وإدارة الأنظمة، وبدأ بإعادة بناء العلاقات التي تضررت في عهد Novell.

Micro Focus 2014–2018

في سبتمبر 2014 اندمجت Attachmate مع Micro Focus Group، وهي شركة تقنية بريطانية متخصصة في البرمجيات القديمة وإدارة بنية تقنية المعلومات. وأصبحت SUSE قسمًا داخل Micro Focus.

وكان عصر Micro Focus، بحسب معظم الروايات، فترة من الاستقرار النسبي والنمو الهادئ. فقد كانت Micro Focus شركة منضبطة ماليًا، تركز على الربحية والتدفق النقدي، واستفادت SUSE من هذا الانضباط. وارتفعت الإيرادات. واتسعت قاعدة العملاء. واكتسب SUSE Linux Enterprise Server أرضًا خاصة في بيئات SAP، إذ إن SAP، عملاق البرمجيات المؤسسية الألماني، اعتمد SLES منصة مفضلة لتطبيقاته.

لكن Micro Focus استمدت معظم عائداتها من صيانة البرمجيات القديمة، ولم تكن بيتًا طبيعيًا لشركة لينكس مفتوحة المصدر. ولم تكن ثقافة SUSE الهندسية، المبتكرة والمتصلة بالمجتمع، دائمًا منسجمة مع ثقافة Micro Focus المحافظة والفعّالة إداريًا.

EQT Partners 2018 حتى الآن

في مارس 2018 أعلنت Micro Focus بيع SUSE إلى EQT Partners، وهي شركة رأس مال خاص سويدية، مقابل 2.535 مليار دولار، وكان ذلك في حينه أكبر استحواذ لرأس مال خاص على شركة مفتوحة المصدر في التاريخ.

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

وعُينت ميليسا دي دوناتو Melissa Di Donato رئيسة تنفيذية لـ SUSE في 2019، لتكون أول امرأة تقود شركة كبرى في مجال المصادر المفتوحة. وتحت قيادتها تسارع تطوير المنتجات في مجالات Kubernetes وإدارة الحاويات، وتهيأت الشركة للإدراج العام.

وفي 19 مايو 2021 أدرجت SUSE أسهمها في بورصة فرانكفورت بتقييم أولي يقارب 5 مليارات يورو، وهو أكبر طرح عام أولي لشركة تقنية أوروبية في سنوات. لكن الإدراج العام لم يدم طويلًا نسبيًا. ففي أغسطس 2023 أعادت EQT الشركة إلى الملكية الخاصة في صفقة قيّمتها بنحو 2.7 مليار يورو، بما عكس هبوط السوق التقنية الأوسع وتحديات SUSE في تسريع نمو الإيرادات.

وعبر كل هذه التغيرات في الملكية، Novell وAttachmate وMicro Focus وEQT والإدراج العام ثم العودة إلى الخاصة، فإن المدهش هو أن فريق SUSE الهندسي وجودة المنتج ظلّا إلى حد كبير على حالهما. فقد واصل مكتب نورمبرغ إنتاج برمجيات ممتازة. وبقيت القيم الأساسية قائمة.

الكلفة العاطفية للاستحواذات المتكررة

تتناول معظم التواريخ المؤسسية الاستحواذات من زاوية استراتيجية. أما الموظفون فيعيشونها وجوديًا.

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

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

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

وكان أحد عوامل التثبيت هو نظام Betriebsräte الألماني، أي مجالس العمال. فبموجب قانون العمل الألماني، يجب على الشركات فوق حجم معين أن تتيح للموظفين انتخاب مجلس عمالي يتمتع بحقوق مهمة: استشارته في القرارات الكبرى، والتفاوض بشأن ظروف العمل، والمشاركة في قرارات التسريح. ولعب مجلس العمال في SUSE دورًا مهمًا أثناء عمليات الاستحواذ، ولا سيما في التفاوض على مكافآت نهاية الخدمة وضمان المعاملة العادلة، وهو فارق كبير عن البيئة المؤسسية الأمريكية حيث يمكن تنفيذ التسريحات بسرعة وبأقل قدر من مشاركة الموظفين.

“لا نكون الأعلى صوتًا أبدًا. ولا الأغنى. ولا الأسرع. لكننا كنا هنا دائمًا، وسنبقى.” مهندس في SUSE، في احتفال الذكرى الثلاثين، نورمبرغ، 2022

سؤال openSUSE ومن يملك السلطة؟

تُعد العلاقة بين openSUSE المجتمعي وSUSE الشركة من أكثر جوانب قصة SUSE تعقيدًا وأقلها بحثًا. فعندما تصادمت مصالح المجتمع والشركة، من كان ينتصر؟

كان openSUSE يُدار بواسطة مجلس يضم أعضاء منتخبين من المجتمع وأعضاء تعيّنهم SUSE. وكان رئيس المجلس يُعيَّن من قبل SUSE، وهي نقطة مهمة لأنها تعني أن SUSE احتفظت بالسلطة النهائية على هيكل حوكمة المشروع. وفي التطبيق العملي، كانت العلاقة تعمل جيدًا خلال فترات الاستقرار: كانت SUSE توفر البنية التحتية، مثل خوادم البناء والاستضافة وموارد الشبكة، وتوظف مساهمين أساسيين، وتموّل السفر؛ بينما يقدّم المجتمع الشفرة البرمجية والاختبار والتوثيق.

لكن التوترات كانت تظهر من حين إلى آخر:

جدل Evergreen. عندما أعلنت SUSE أن بعض إصدارات openSUSE ستصل إلى نهاية العمر التشغيلي، نظّم أعضاء المجتمع Project Evergreen لتمديد الدعم. ولم تعارض SUSE ذلك بنشاط، لكنها لم توفر له الموارد، وكافح المشروع لأن المتطوعين وحدهم لم يستطيعوا مواكبة حجم تصحيحات الأمان المطلوبة.

مواءمة Leap/Enterprise. عندما أُطلق openSUSE Leap في 2015، وجرى مواءمته صراحة مع SUSE Linux Enterprise، أصبح المستخدمون الذين أرادوا دورات إصدار أسرع مقيدين بضرورة البقاء متزامنين مع المنتج المؤسسي.

التحول نحو ALP. أثار تطوير SUSE لمنصة Adaptive Linux Platform (ALP)، التي صُمّمت لتكون الجيل التالي من SUSE Linux Enterprise، أسئلة مهمة حول مستقبل openSUSE. فقد اعتمد ALP على نموذج تطوير مختلف عن النموذج التقليدي المفتوح، مما أثار مخاوف بعض أعضاء المجتمع من تراجع دورهم وتركّز القرارات داخل فريق SUSE الهندسي.

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

وهذه الديناميكية لم تكن فريدة من نوعها لـ openSUSE، إذ يعمل Fedora ضمن قيود مشابهة مع Red Hat. لكن وضع openSUSE تعقّد بسبب تغيّر الملكية المتكرر، حيث كان كل مالك جديد يجلب أولويات جديدة، ويجبر المجتمع على إعادة التفاوض بشأن موقعه.

LiMux في ميونخ ولماذا اختارت المدينة الألمانية Debian

مشروع LiMux، أي هجرة ميونخ الشهيرة لأربعة عشر ألف جهاز مكتبي من Windows إلى لينكس، يُذكر كثيرًا في قصة SUSE، لكن تفصيلًا حاسمًا غالبًا ما يُمرّ عليه مرور الكرام: ميونخ اختارت Debian، لا SUSE، كأساس لهجرتها إلى لينكس. كانت هذه مدينة ألمانية تنتقل إلى لينكس، لكنها اختارت توزيعة غير ألمانية بدلًا من أبرز شركة لينكس ألمانية. لماذا؟

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

الاستقلال عن المورّد. كان الهدف الكامل من LiMux تقليل اعتماد ميونخ على مورّد واحد. وكان من غير المنطقي استبدال الاعتماد على مايكروسوفت بالاعتماد على SUSE أو على Novell التي كانت تملك SUSE آنذاك. فـ Debian، بوصفها مشروعًا مجتمعيًا بلا مالك مؤسسي، لم تطرح هذا الخطر. ولو غيّر مشروع Debian اتجاهه، لكان بإمكان ميونخ عمل fork للكود. أما إذا غيّرت SUSE مالكيها، وهو ما حدث فعلًا مرارًا، فقد يتزعزع أساس المنصة بسبب قرارات صادرة من قاعة مجلس في يوتا أو بنك استثماري في لندن.

نقاء الترخيص. كان التزام Debian بالبرمجيات الحرة أكثر من SUSE. فالمستودع الرئيسي في Debian لا يضم إلا البرمجيات المطابقة لـ Debian Free Software Guidelines. أما SUSE، فكانت تضم مكونات احتكارية، بما فيها ترخيص YaST الاحتكاري حينها، إلى جانب تعريفات وكودات احتكارية.

التكلفة. كانت Debian مجانية بالكامل. أما SUSE فكانت معروضة أساسًا كمنتج تجاري قائم على رسوم الاشتراك.

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

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

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

وتوضح ملحمة LiMux حقيقة كانت SUSE تعرفها جيدًا: إن قرارات التقنية في المؤسسات والقطاع العام ليست أبدًا تقنية بحتة. إنها سياسية وثقافية ومؤسسية. فالأفضل تقنيًا لا ينتصر دائمًا؛ بل تنتصر التقنية التي تحظى بأفضل دعم مؤسسي.

نقاط قوة SUSE المميزة

رغم هيمنة Red Hat على سوق المؤسسات عمومًا، كانت هناك مجالات كانت SUSE فيها الرائدة بوضوح.

بيئات SAP

وكان الأهم هو SAP. فقد أقامت SAP، عملاق البرمجيات المؤسسية الألماني، وSUSE شراكة عميقة وطويلة الأمد، جذورها مشتركة في الجغرافيا والثقافة، لكنها استمرت بفضل التميز التقني. وعمل مهندسو نواة SUSE مع مطوري SAP على تحسين لينكس لأنماط أعباء العمل الخاصة بـ SAP، مثل الذاكرات الكبيرة، والإدخال/الإخراج الكثيف، والتطبيقات متعددة الخيوط المعقدة، فحققوا تحسينات خاصة بـ SAP لا يستطيع أي توزيع لينكس آخر مجاراتها.

وكانت شراكة SAP أيضًا حيوية تجاريًا. ففي السنة المالية 2022، أعلنت SUSE عن إيرادات إجمالية تقارب 580 مليون دولار، وإيرادات متكررة سنوية تقارب 590 مليون دولار. وقدرت تحليلات الصناعة أن بيئات SAP تمثل 30 إلى 40 بالمئة من إجمالي إيرادات SUSE، وهي إلى حد بعيد أكبر حالة استخدام منفردة. وعادة ما يكون عملاء SAP شركات كبيرة ذات إنفاق تقني مرتفع، تستخدم SAP لعقود طويلة، ما يجعل الاشتراكات المرتبطة بـ SAP أكثر قطاعات SUSE ربحية وولاءً.

الحوسبة عالية الأداء

صنعت SUSE لنفسها موقعًا قويًا في الحوسبة عالية الأداء (HPC). فقد كانت العديد من أسرع الحواسيب العملاقة في العالم، المستخدمة في نمذجة المناخ، واكتشاف الأدوية، ومحاكاة الأسلحة النووية، تعمل على SUSE Linux Enterprise. وشملت قدرات SUSE في HPC ضبطًا أمثل للنواة، ودعمًا لوصلات خاصة مثل InfiniBand، وأدوات لإدارة الخوادم الضخمة.

وفي نوفمبر 2017 أظهر تصنيف TOP500 أن لينكس يعمل 100% على أسرع 500 حاسوب عملاق في العالم، وهي المرة الأولى التي تحقق فيها عائلة أنظمة تشغيل واحدة هيمنة كاملة. وكانت SUSE تدعم نسبة مهمة من هذه الأنظمة، بما فيها الأنظمة في المركز السويسري للحوسبة الفائقة (CSCS) وLeibniz Supercomputing Centre في ألمانيا.

وقد قاد عمل HPC إلى ابتكارات أفادت جميع مستخدمي SUSE. فإصلاحات النواة المطورة للحواسيب العملاقة، مثل إدارة ذاكرة أفضل تحت الحمل الشديد وجدولة عمليات أكثر كفاءة، انتقلت إلى SUSE Linux Enterprise Server القياسي.

الحواسيب المركزية

كانت SUSE من أوائل توزيعات لينكس التي دعمت معمارية IBM System z للحواسيب المركزية، المعروفة الآن باسم IBM Z، وحافظت على هذا الدعم بشكل متواصل لأكثر من عقدين. وتملك معمارية z خصائص فريدة، مثل I/O عبر القنوات، ومسرعات التشفير العتادية، وإدارة الأقسام الديناميكية، مما تطلب عملًا كبيرًا في النواة والتعريفات. وحافظت SUSE على فريق من المهندسين المتخصصين في لينكس للحواسيب المركزية، وكان عملهم حاسمًا في قطاعي الخدمات المالية والحكومة حيث كانت الحواسيب المركزية شائعة. وكان عمق SUSE في هذا المجال يُنظر إليه على أنه أفضل من Red Hat.

الحكومة والقطاع العام الأوروبي

في أسواق الحكومة والقطاع العام الأوروبي، جعل مزيج SUSE من الملكية الأوروبية، والاعتمادات القوية في سيادة البيانات، والقدرات التقنية، منها الخيار المفضل لدى كثير من الوكالات الحكومية الأوروبية والمنظمات العسكرية ومشغلي البنى التحتية الحرجة. وكانت الحكومة الألمانية من العملاء المهمين لـ SUSE. وقد شكّل عملاء الحكومة والقطاع العام، ولا سيما في أوروبا، ما يُقدّر بـ 15 إلى 20 بالمئة من إيرادات SUSE.

التوزيع الجغرافي

عكس توزيع إيرادات SUSE الجغرافي تاريخها: إذ شكّلت منطقة أوروبا والشرق الأوسط وأفريقيا نحو 55 إلى 60 بالمئة من الإيرادات، بينما قاربت الأمريكيتان 30 بالمئة، وشكّلت آسيا والمحيط الهادئ الباقي. والمقارنة مع Red Hat دالة: فقبل استحواذ IBM عليها، كانت إيرادات Red Hat من الأمريكيتين وحدها تتجاوز إجمالي إيرادات SUSE العالمية. وكان السوق الأمريكي، الذي لم تخترقه SUSE على نطاق واسع، هو السبب الرئيسي في هذا الفارق.

استحواذ Rancher وعصر Kubernetes

في ديسمبر 2020 استحوذت SUSE على Rancher Labs مقابل 600 مليون دولار، وكان ذلك أكبر استحواذ لها، وأحد أهم التحركات الاستراتيجية في تاريخ الشركة.

وقد أسس شنغ ليانغ Sheng Liang وشانون ويليامز Shannon Williams شركة Rancher Labs في 2014، وبنوا منصة مفتوحة المصدر شهيرة لإدارة حاويات كوبيرنيتيس Kubernetes. وكان Kubernetes، الذي طورته Google أصلًا، قد أصبح المنصة المهيمنة لتنظيم الحاويات. وكانت قدرات SUSE الاساسية في Kubernetes محدودة، فجاء الاستحواذ على Rancher ليمنحها حضورًا فوريًا وموثوقًا في السوق.

وشملت منتجات Rancher: Rancher لإدارة Kubernetes عبر عناقيد متعددة multi-cluster، وK3s، وهو Kubernetes خفيف الوزن مصمم للحوسبة الطرفية وإنترنت الأشياء، وRKE، أي Rancher Kubernetes Engine، لنشر العناقيد cluster وإدارتها. وقد كملت هذه المنتجات عروض SUSE الحالية في البنية التحتية.

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

أما استحواذ NeuVector، الذي اكتمل في أكتوبر 2021، فأضاف أمن الحاويات إلى المحفظة. وأظهر قرار SUSE بفتح مصدر NeuVector، وإصدار المنصة كلها تحت رخصة Apache 2.0، التزامها بمبادئ المصادر المفتوحة حتى مع المنتجات المستحوذ عليها.

“في عالم المصادر المفتوحة، الشيفرة هي الثقافة. وشيفرة SUSE تقول لك كل ما تحتاج إلى معرفته عن SUSE: إنها حذرة، شاملة، موثقة جيدًا، ومبنية لتدوم. وبكلمة واحدة: ألمانية.” مهندس في SUSE، في مؤتمر مجتمعي، 2018

المؤسسون، أين ذهبوا؟

يغيب المؤسسون الأربعة لـ S.u.S.E. بشكل لافت عن الفصول اللاحقة من قصة SUSE. وهذا الغياب بحد ذاته ذو دلالة.

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

أما هوبير مانتل فكان المدير التقني في SUSE وأحد أكثر المؤسسين تأثيرًا تقنيًا. وقد بقي مع SUSE بعد استحواذ Novell واستمر في الإسهام في الاتجاه التقني للتوزيعة. ثم تراجع لاحقًا عن القيادة النشطة.

وبقي توماس فيهر مرتبطًا بـ SUSE لفترة طويلة، مسهمًا في التطوير والتواصل المجتمعي. وكان معروفًا داخل المجتمع كشخصية متاحة وعارفة.

أما بورتشارد شتاينبيلد فكان أقل المؤسسين ظهورًا للعلن، ومساره بعد SUSE هو الأصعب تتبعًا في السجلات العامة.

والمثير في قصص المؤسسين أنها تختلف جدًا عن السردية المعتادة في وادي السيليكون. ففي الصناعة الأمريكية، المؤسسون مشاهير. أما في حالة SUSE، فقد بنى المؤسسون شيئًا رائعًا، وأداروه لعقد، ثم باعوه، ثم اختفوا إلى حد كبير من الواجهة العامة. أما القرارات التي شكّلت المسار اللاحق لـ SUSE، مثل صفقة مايكروسوفت وبيع Attachmate واندماج Micro Focus، فقد اتخذها أشخاص لم يبنوا SUSE، وفي بعض الحالات لم يفهموا تمامًا ما كانت عليه.

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

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

SUSE والسيادة الرقمية الأوروبية

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

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

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

وكانت GAIA-X في 2019 مبادرة فرنسية ألمانية لإنشاء بنية سحابية أوروبية اتحادية قائمة على المعايير المفتوحة ومبادئ السيادة الأوروبية على البيانات. وشاركت SUSE فيها، مسهمة بخبرتها في السحابة والبنية التحتية. وقد مرّت GAIA-X بمسار معقد، وانتقدها البعض لفرط طموحها، وانتقدها آخرون لأن مشاركة عمالقة السحابة الأمريكيين شوّهت رؤيتها، لكنها تمثل أهم محاولة أوروبية لإنشاء بديل للبنية السحابية التي تهيمن عليها الشركات الأمريكية.

وتنص استراتيجية الاتحاد الأوروبي للمصادر المفتوحة، في نسختها الأحدث لعام 2020، صراحة على التزام المفوضية الأوروبية بتفضيل الحلول مفتوحة المصدر، وتصف المصادر المفتوحة بأنها أساسية للسيادة الرقمية الأوروبية.

أما قرارات Schrems، أي Schrems I في 2015 وSchrems II في 2020، التي رفعها الناشط النمساوي في الخصوصية ماكس شريمس Max Schrems، فقد أبطلت الأطر القانونية التي تسمح للشركات الأمريكية بنقل البيانات الشخصية الأوروبية إلى الولايات المتحدة، على أساس أن قوانين المراقبة الأمريكية لا توفر الحماية الكافية لمواطني أوروبا. وقد خلق ذلك فرصة لمزودي السحابة والبنية التحتية الأوروبيين لتقديم بدائل سيادية تحتفظ بالبيانات داخل الولايات القضائية الأوروبية. ووضعت SUSE منتجاتها صراحة في هذا السوق: شيفرة مفتوحة المصدر قابلة للفحص والتحقق، وعمليات أوروبية خاضعة للقانون الأوروبي، وبنية قابلة للنشر على عتاد أوروبي داخل مراكز بيانات أوروبية.

هل مارست SUSE ضغطًا سياسيًا لصالح هذه السياسات؟ كانت SUSE عضوًا في عدة جمعيات صناعية تدعو إلى سياسات داعمة للمصادر المفتوحة، بما فيها Linux Foundation وOpen Source Business Alliance الألمانية وOpen Forum Europe. وتواصلت SUSE مباشرة مع صناع السياسات الأوروبيين، لكن بحذر، فالممارسة المباشرة للضغط المؤسسي في أوروبا أقل شيوعًا وأقل قبولًا منها في الولايات المتحدة. وكان نهج SUSE عادة أن تقدم نفسها مساهمًا في منظومة المصادر المفتوحة الأوسع لا مجرد مستفيد مباشر من سياساتها، وهو موقف نابع من روح عامة صادقة ومن فطنة تجارية في آن واحد.

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

حكايات من الميدان

الاستجابة لثغرة Heartbleed

عندما أُعلنت ثغرة Heartbleed، المعروفة بالرمز CVE-2014-0160، في 7 أبريل 2014، كانت فرق أمن SUSE قد أُخطرت عبر عملية الإفصاح المنسق وبدأت في إعداد التصحيحات قبل الإعلان العام. وعندما أُعلن Heartbleed، كانت تصحيحات SUSE جاهزة. وأُمنت الأنظمة التي طبق أصحابها التصحيحات في الساعات الأولى بعد الإعلان.

وقد وصف مهندس أمني قديم في SUSE، الاستجابة لـ Heartbleed في مؤتمر لاحقًا قائلاً: “كنا نعرف عن الثغرة قبل الإفصاح العلني بعدة أيام. كانت التصحيحات جاهزة. لكننا كنا نعرف أيضًا أنه في اللحظة التي يُعلن فيها عنها سيبدأ كل مسؤول نظام في العالم بسؤالنا: هل أنا متأثر؟ وماذا أفعل؟ كان علينا أن نكون مستعدين ليس فقط بالتصحيحات، بل بالإجابات.”

كما دفعت حادثة Heartbleed SUSE إلى الاستثمار أكثر في Core Infrastructure Initiative، التي أصبحت لاحقًا Open Source Security Foundation، وهي مبادرة أُنشئت لتوفير التمويل والموارد لمشاريع المصادر المفتوحة الحرجة التي كانت تُدار بواسطة فرق صغيرة ومحدودة التمويل. وكانت SUSE عضوًا مؤسسًا فيها.

وتكررت ديناميكية مشابهة مع ثغرة Log4Shell في ديسمبر 2021، وهي ثغرة حرجة في Apache Log4j سمحت بتنفيذ أوامر عن بُعد واستُغلت بنشاط خلال ساعات من الكشف عنها. واستجاب فريق الأمن في SUSE مرة أخرى بسرعة، مؤكّدًا أهمية العمل على أمن سلسلة التوريد.

الاستجابة لثغرة Dirty Pipe (CVE-2022-0847) - الثغرة التي لم تصب SUSE

في 7 مارس 2022، عندما أعلن باحث الأمن ماكس كيلرمان Max Kellermann عن ثغرة Dirty Pipe، وهي ثغرة خطيرة في نواة لينكس تسمح لمستخدمين غير مميزين بكتابة بيانات في ملفات قراءة فقط، مُحدثة حالة الارتقاء للحقوق (privilege escalation)، دخلت فرق SUSE في حالة تأهب فوري. لكن ما ميّز SUSE هو أن منتجاتها المؤسسية المدعومة لم تتأثر أصلاً، لأنها تستخدم إصدارات نواة أقدم من 5.8 (الإصدار المتضرر).

ما الفريد هنا؟ بدلاً من التركيز على رقعة عاجلة فقط، أصدرت SUSE بيانًا رسميًا يشرح لماذا لم تتأثر، مع التزامها بإصدار تحديثات وقائية للثغرة الأساسية (التي وُجدت منذ نواة 4.9). كان هذا درسًا في الاستباقية الهندسية:

“منتجاتنا الحالية غير متأثرة لأننا نستخدم نوى مثبتة بعناية. لكننا سنُصدر تحديثات وقائية لأن أمن عملائنا يأتي أولاً.”

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

أزمة XZ Utils (2024) - كشف تلاعب سلسلة التوريد

أبريل 2024 شهد أخطر أزمة سلسلة توريد في تاريخ لينكس الحديث: محاولة اختراق مُمنهجة لمشروع XZ Utils، مكتبة الضغط الأساسية، تحتوي على باب خلفي مخفي ببراعة في الإصدارات 5.6.0 و5.6.1. كان المهاجم قد تسلل لسنوات، بنى ثقة داخل المشروع، وأصبح مُحافظًا رسميًا قبل إدخال الرمز الخبيث الذي كان سيُطْرِح على OpenSSH عالميًا.

دور SUSE الفريد: كانت من أوائل المتحركين في عزل الحزم المتضررة، وإصدار تنبيهات فورية، وتفعيل بروتوكولات التدقيق التلقائي لسلسلة التوريد. لكن الأهم، استخدمت SUSE خبرتها في Open Build Service (OBS) للتحقق من سلامة ملايين الحزم المبنية يوميًا.

اللحظة الدرامية: اكتشف فريق SUSE أن XZ 5.6.1 كانت قد دُخِلَت فعلاً في مستودعات التطوير لبعض الإصدارات القادمة. توقّفت عملية البناء فورًا، عُزِلَتْ الحزمة، وأُعْلِنَتْ حالة الطوارئ الداخلية قبل أن تُصْلَ إلى أي عميل إنتاجي.

الدرس المُستفاد: أثبتت OBS قيمتها كـدرع سلسلة التوريد، حيث منعت توزيع ملايين الحزم الملوثة. بينما اضطرّت توزيعات أخرى لسحب الحزم المنشورة بالفعل، كانت عملاء SUSE محميين تمامًا.

“في عالم حيث يُخْرَجُ المهاجمون ثقتهم قبل رموزهم الخبيثة، OBS ليست أداة بناء، بل نظام دفاع.” — تقرير داخلي SUSE، 2024

ماذا تمثل SUSE

قصة SUSE، على مستوى، هي مجرد تاريخ شركة. لكن على مستوى آخر، هي قصة عن التقنية والأسواق والعلاقة بين التقنية والثقافة.

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

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

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

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

لكن ما بنوه ما زال قائمًا.

في مكان ما الآن، يستخدم مسؤول نظام في وكالة حكومية ألمانية YaST لتهيئة خادم. ويشغّل باحث في مركز حوسبة سويسري عملاق محاكاة على عنقود مدعوم بـ SUSE. وتدير مصنعًا في بافاريا خطوط الإنتاج عبر نظام مدمج قائم على SUSE. وتعالج مؤسسة مصرفية في فرانكفورت المعاملات على حاسوب مركزي يعمل بـ SUSE. وتنشر شركة ناشئة في برلين الحاويات على عناقيد Kubernetes تُدار عبر Rancher.

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

فهي تفعل ذلك دائمًا.