لينوس تورفالدز: كيف يقود صانع Linux وGit مشروعه

كل مرة تكتب فيها git commit أو ترفع Container على سيرفر Linux فأنت تستخدم عمل شخص واحد بدأ مشروعين من أكبر مشاريع البرمجيات في التاريخ، فالنواة Kernel التي تشغل أغلب سيرفرات الإنترنت والهواتف بدأها طالب في هلسنكي سنة 1991، وأداة Git التي يستخدمها كل فريق برمجي تقريباً كتب نسختها الأولى الشخص نفسه في أيام قليلة من أبريل 2005. وهذا الشخص هو لينوس تورفالدز Linus Torvalds، وهو ما زال حتى اليوم الشخص الوحيد الذي يدمج التعديلات في الفرع الرئيسي من النواة، لذلك فإن فهم طريقته في القيادة ليس فضولاً تاريخياً، وإنما فهم لكيف يدار أكبر مشروع مفتوح المصدر يعتمد عليه عملك كل يوم.

ولكن الحديث عن لينوس لا يكتمل بدون الوجه الآخر، فهو معروف أيضاً برسائل قاسية على القوائم البريدية استمرت سنوات، حتى اعتذر عنها بنفسه في 2018 وأخذ إجازة ليغير أسلوبه. لذلك سوف نحاول في هذا المقال أن نكون منصفين: كل معلومة مربوطة بمصدرها، من رسائله نفسها في أرشيف lore.kernel.org ومن وثائق النواة الرسمية ومن مقابلاته ومن الصحافة التقنية المعروفة مثل LWN، ولن نتحدث عن حياته الخاصة إطلاقاً، ومن يريد القصة بصوته فقد كتبها مع الصحفي David Diamond في كتاب «Just for Fun».

وسوف نناقش في هذا المقال ما يلي:

• سيرة مختصرة: من هلسنكي إلى كاليفورنيا ثم إلى Linux Foundation، والجوائز التي حصل عليها.
• قصة Git في 2005، ولماذا سلمه بعد أقل من أربعة أشهر إلى Junio Hamano.
• كيف يدير النواة: نافذة الدمج Merge Window، وسلسلة الثقة في المشرفين، وقاعدة «لا تكسر برامج المستخدمين»، وما يسميه الذوق الجيد في الكود.
• الخلافات المشهورة بالتواريخ والمصادر: نقاش Tanenbaum في 1992، وملاحظته عن NVIDIA، ولغته القاسية على القوائم البريدية، واعتذار 2018.
• ما بعد 2018: خلافات Rust في النواة، وخروج bcachefs، وحذف مشرفين بسبب العقوبات.
• ما الذي يستحق أن ننقله إلى فرقنا ومشاريعنا في المنطقة، وما الذي لا يجب أن ننقله.

الصورة التالية تبين أهم المحطات التي سوف نمر عليها مرتبة حسب السنة:

من هلسنكي: طالب ونواة لحاسبه الشخصي

ولد لينوس تورفالدز في هلسنكي عاصمة فنلندا في 28 ديسمبر 1969، والتحق بجامعة هلسنكي University of Helsinki في 1988 ودرس علوم الحاسب، وأكمل فيها لاحقاً درجة الماجستير برسالة عنوانها «Linux: A Portable Operating System»، كما يذكر متحف تاريخ الحاسب Computer History Museum الذي اختاره زميلاً Fellow في 2008 «لإنشاء نواة Linux وإدارة تطويرها المفتوح».

أما قصة البداية نفسها فقد شرحناها في مقال البرمجيات مفتوحة المصدر وتراخيصها، ولن نعيدها هنا إلا بالقدر الذي يخدم موضوعنا: في 25 أغسطس 1991 نشر لينوس رسالته المشهورة في مجموعة comp.os.minix يسأل فيها مستخدمي Minix عما يحبونه وما يكرهونه في نظامهم، ووصف مشروعه بأنه هواية لن تكبر، ثم رفع الإصدار 0.01 في سبتمبر بملاحظات ما زالت موجودة على kernel.org. وكانت الرخصة الأولى رخصة كتبها بنفسه تمنع البيع، ثم أعلن في ملاحظات الإصدار 0.12 أن النواة سوف تنتقل إلى رخصة GPL، وكان ذلك في بداية 1992.

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

إلى كاليفورنيا: Transmeta ثم OSDL ثم Linux Foundation

في 1996 زار لينوس مقر شركة Transmeta في كاليفورنيا، وهي شركة ناشئة كانت تطور معالجات قليلة الاستهلاك للطاقة، فقبل العمل فيها وانتقل مع عائلته إلى الولايات المتحدة كما يذكر ملفه في IEEE Computer Society، وبقي يقود تطوير النواة في الوقت نفسه. وفي 16 يونيو 2003 كتب على القائمة البريدية للنواة رسالة الإصدار 2.5.72 يقول فيها إنه يأخذ إجازة من Transmeta بعد أكثر من ست سنوات فيها، أي أن عمله فيها بدأ في 1997، لكي يعمل على النواة بدوام كامل في مختبرات Open Source Development Labs واختصاراً OSDL، وهي منظمة تمولها شركات تعتمد على Linux.

وفي يناير 2007 اندمجت OSDL مع Free Standards Group فولدت Linux Foundation، وما زال لينوس حتى اليوم على صفحة قيادة المؤسسة بصفة زميل Fellow، أي أن المؤسسة تدفع راتبه لكي يعمل على النواة وحدها دون أن يكون موظفاً عند شركة تبيع منتجاً. وقد شرحنا ما تملكه المؤسسة وما لا تملكه في النواة، ومن يملك العلامة التجارية Linux، في قسم ما علاقة المؤسسة بـ Linus Torvalds؟.

ومن الجوائز التي حصل عليها، وكلها منشورة على مواقع الجهات التي منحتها:

• زميل متحف تاريخ الحاسب Computer History Museum Fellow في 2008، كما ذكرنا أعلاه.
• جائزة الألفية للتقنية Millennium Technology Prize في 2012 من فنلندا عن «نظام التشغيل مفتوح المصدر»، وتقاسمها في تلك السنة مع العالم الياباني Shinya Yamanaka عن أبحاث الخلايا الجذعية، كما تبين صفحة الفائزين بالجائزة.
• جائزة رواد الحاسب Computer Pioneer Award من IEEE Computer Society في 2014 «لريادته في تطوير نواة Linux بطريقة المصادر المفتوحة»، كما يذكر ملفه في الجمعية.
• جائزة IEEE Masaru Ibuka للإلكترونيات الاستهلاكية في 2018، والصورة التالية من حفل تسليمها.

Git: أداة كتبها لأنه لم يجد بديلاً

شرحنا في مقال إدارة النسخ وGit للمبتدئين كيف ولد Git من انهيار العلاقة بين مجتمع النواة والشركة التي تطور BitKeeper، وهو نظام تحكم بالنسخ موزع Distributed VCS تجاري استخدمته النواة منذ 2002، أما هنا فسوف ننظر إلى القصة من زاوية لينوس نفسه. ففي 6 أبريل 2005 كتب رسالة عنوانها «Kernel SCM saga..» يعلن فيها أنه توقف عن استخدام BitKeeper بعد خلاف استمر شهرين، وطلب من الجميع ألا يلوموا الشركة، وقال إن صاحبها حاول فعلاً أن ينجح الاتفاق، ثم ذكر شيئاً مهماً لموضوعنا: أن سنوات BitKeeper الثلاث غيرت طريقة عمله، فصار يثق بالمشرفين الفرعيين في تغييرات أكبر بكثير بدل أن يعمل تعديلاً بتعديل.

وبعد يوم واحد، في 7 أبريل 2005، سجل أول Commit في تاريخ Git، وفي 26 يوليو 2005، أي بعد أقل من أربعة أشهر، كتب على قائمة Git البريدية رسالة عنوانها «Meet the new maintainer..» يعلن فيها أن المشرف الجديد هو Junio C Hamano، وقال إنه كان يقول دائماً إنه لا يريد أن يصون الأداة على المدى البعيد، وإنه سوف يستمر في إرسال التعديلات إلى Junio كأي مساهم. وما زال Junio Hamano يصون Git حتى اليوم، أي منذ أكثر من عشرين سنة.

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

كيف يدير النواة اليوم؟

في مقال حوكمة المشاريع مفتوحة المصدر شرحنا نموذج الشخص الواحد BDFL بمثال curl، ونواة Linux هي أشهر مثال على هذا النموذج في مشروع ضخم، ولكن بتفصيل مهم: القرار الأخير عند لينوس، والعمل اليومي عند مئات المشرفين. وتقول وثيقة عملية التطوير في النواة إن شخصاً واحداً فقط يستطيع أن يدمج التعديلات في المستودع الرئيسي Mainline وهو لينوس، ولكنها تذكر أيضاً أن من أكثر من 9,500 تعديل دخلت الإصدار 2.6.38 اختار لينوس بنفسه 112 تعديلاً فقط، أي نحو 1.3%.

طريق التعديل: من البريد إلى Mainline

الصورة التالية تبين الطريق الذي يمر به تعديل Patch من مطور إلى النواة الرئيسية:

في الصورة أعلاه لاحظ التالي:

• التعديل يرسل بالبريد الإلكتروني نصاً عادياً إلى القائمة البريدية المختصة وإلى المشرف، كما تشرح وثيقة إرسال التعديلات، وليس عبر Pull Request في GitHub. والسبب أن البريد لا يحتاج حساباً عند أي شركة، وأن كل نقاش يبقى مؤرشفاً علناً في lore.kernel.org، وأن المراجع يستطيع أن يعلق على السطر نفسه داخل الرد. ولينوس نفسه قال في مقابلة TED إنه يحب التعامل مع الناس عبر البريد لأنه يعطيه مسافة Buffer.
• كل نظام فرعي Subsystem له مشرف Maintainer مذكور في ملف MAINTAINERS، وهو الذي يقبل التعديل في شجرته Tree، ثم يطلب من لينوس أن يسحب Pull هذه الشجرة. والوثيقة تسمي هذا سلسلة الثقة Chain of Trust: لينوس يثق بالمشرف، والمشرف يثق بمن يسحب منهم.
• الشجرة linux-next تدمج أشجار المشرفين كل يوم لكي تظهر التعارضات والأخطاء قبل نافذة الدمج، والوثيقة تقول إن كل ما يدخل في نافذة الدمج يجب أن يكون قد مر بها قبل ذلك.

وقد شرحنا من يكتب هذه التعديلات فعلاً، وأي الشركات تدفع رواتب أغلب المطورين، بالأرقام في قسم من يكتب نواة Linux فعلاً؟.

دورة الإصدار: نافذة الدمج ثم أسابيع الإصلاح

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

وتفاصيل الدورة كما في الوثيقة: نافذة الدمج Merge Window تستمر نحو أسبوعين، وفيها يرسل المشرفون طلبات السحب بالميزات الجديدة، ثم يغلقها لينوس بإصدار rc1، وبعدها يصدر إصدار rc جديداً كل أسبوع تقريباً، وتصل السلسلة في العادة إلى ما بين rc6 وrc9، ثم يصدر الإصدار النهائي، فيصدر إصدار رئيسي جديد كل شهرين إلى ثلاثة أشهر. والجملة المهمة في الوثيقة أن من يحاول إدخال ميزة جديدة بعد إغلاق النافذة يلقى في العادة استقبالاً غير ودي، وسوف ترى في قصة bcachefs وقصة RISC-V أدناه أن هذه الجملة تطبق فعلاً.

القاعدة الأولى: لا تكسر برامج المستخدمين

إذا كانت هناك قاعدة واحدة يعرفها كل من يعمل على النواة فهي «لا نكسر مساحة المستخدم» We do not break userspace، ومعناها أن أي تغيير في النواة يجعل برنامجاً كان يعمل يتوقف عن العمل يعتبر خطأ في النواة، حتى لو كان البرنامج يعتمد على سلوك غريب، وحتى لو كان التغيير صحيحاً نظرياً. ووثيقة التعامل مع التراجعات Regressions في النواة تجمع أقواله عن هذه القاعدة بتواريخها، ومنها رسالته في مايو 2024 التي يقول فيها إنه وضع قاعدة «لا تراجعات» قبل نحو عشرين سنة لأن الناس يجب أن يستطيعوا تحديث النواة دون خوف من أن يتوقف شيء يعتمدون عليه، ورسالته في أكتوبر 2017 التي يقول فيها:

"If the kernel used to work for you, the rule is that it continues to work for you."

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

الذوق الجيد في الكود Good Taste

في مقابلة TED سنة 2016 عرض عليه مقدم الحوار Chris Anderson مثالين لدالة تحذف عنصراً من قائمة مترابطة أحادية Singly-linked List، وسأله عن الفرق بينهما، فشرح لينوس أن الطريقة الأولى، وهي الطريقة التي يتعلمها الطلاب، فيها حالتان مختلفتان: إذا كان العنصر أول القائمة يجب تعديل مؤشر البداية، وإذا كان في وسطها يجب تعديل مؤشر العنصر الذي قبله، لذلك تحتاج جملة if في النهاية. والمثال التالي يبين الفكرة بكود قريب من الذي عرض في المقابلة:

/* الطريقة البسيطة: حالة خاصة لأول عنصر */
void remove_entry(struct list *l, struct entry *target)
{
    struct entry *prev = NULL;
    struct entry *walk = l->head;

    while (walk != target) {
        prev = walk;
        walk = walk->next;
    }
    if (!prev)
        l->head = target->next;
    else
        prev->next = target->next;
}

/* الطريقة الثانية: مؤشر إلى المؤشر، فلا توجد حالة خاصة */
void remove_entry(struct list *l, struct entry *target)
{
    struct entry **indirect = &l->head;

    while (*indirect != target)
        indirect = &(*indirect)->next;
    *indirect = target->next;
}

في الكود أعلاه لاحظ التالي:

• في الدالة الثانية لا نمشي على العناصر وإنما على أماكن المؤشرات التي تشير إليها، فمؤشر البداية head والمؤشر next في أي عنصر صارا شيئاً واحداً بالنسبة للكود، لذلك اختفت جملة if.
• والفكرة التي قالها لينوس في المقابلة ليست هذه الحيلة نفسها، وإنما أن تنظر إلى المشكلة بطريقة أخرى فتتحول الحالة الخاصة Special Case إلى حالة عادية، وقال إن هذا هو الكود الجيد، وإن ما يبحث عنه في الأشخاص الذين يثق بهم هو هذا الإحساس بالتفاصيل.

وهذا يشرح لماذا يرفض أحياناً تعديلات تعمل فعلاً: العمل وحده ليس المعيار، وإنما أن يكون الكود بسيطاً بحيث يستطيع غيرك أن يصونه بعد عشر سنوات.

نقاشات مبكرة صنعت سمعته

نقاش Tanenbaum في 1992: Monolithic أم Microkernel؟

في 29 يناير 1992 كتب الأستاذ Andrew Tanenbaum، صاحب نظام Minix الذي تعلم عليه لينوس، رسالة في مجموعة comp.os.minix عنوانها «LINUX is obsolete»، قال فيها إن النواة المتجانسة Monolithic Kernel التي تضع كل شيء في برنامج واحد خطوة إلى الوراء، وإن المستقبل للنواة المصغرة Microkernel وللأنظمة التي تنقل بسهولة بين المعالجات، ورد عليه لينوس في اليوم نفسه، وتجد النقاش كاملاً في ملحق كتاب Open Sources من O'Reilly. وكانت حجة لينوس أن النواة المصغرة أصعب في التنفيذ لأنها تحتاج خوارزميات موزعة معقدة، وأن Linux يعمل الآن ومتاح مجاناً، أما Tanenbaum فكان يدافع عن تصميم أنظف من الناحية الأكاديمية. ولم يتحول الخلاف إلى عداوة، فقد كتب Tanenbaum لاحقاً على صفحته عن الأنظمة الموثوقة أنهما ليسا عدوين، واستمر في الدفاع عن فكرة النواة المصغرة بمشروع Minix 3.

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

NVIDIA في 2012: محاضرة وليس قائمة بريدية

في 14 يونيو 2012 كان لينوس يتحدث في جامعة Aalto في فنلندا، وفي فقرة الأسئلة سئل عن دعم بطاقات NVIDIA في Linux، فقال إن NVIDIA أسوأ شركة تعامل معها مطورو Linux، وأضاف أن ذلك مؤسف أكثر لأن الشركة تبيع شرائح كثيرة لأجهزة Android، ثم ختم بشتيمة وإشارة بيده أمام الكاميرا. والمقطع كاملاً موجود في تسجيل المحاضرة، وقد نشرت Ars Technica القصة في 19 يونيو 2012. ولاحظ أن هذه الحادثة كانت في محاضرة عامة وليست على القائمة البريدية، وأن الخلاف الحقيقي خلفها كان تقنياً: أن الشركة لم تكن تنشر وثائق ولا درايفرات مفتوحة لشرائحها، فيتحمل مطورو النواة مشكلات لا يستطيعون إصلاحها.

اللغة القاسية على القوائم البريدية

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

1. سبتمبر 2007، قائمة Git البريدية: في نقاش عن سبب كتابة Git بلغة C وليس C++، رد لينوس على المطور Dmitry Kakurin برسالة بدأها بأن C++ لغة مريعة "C++ is a horrible language"، وأن اختيار C وحده يبعد المبرمجين الذين يكتبون كوداً سيئاً. والرأي في اللغة رأي تقني يستطيع أن يقوله أي شخص، ولكن الرسالة شملت إهانة لمن يختلف معه.
2. 23 ديسمبر 2012، القائمة البريدية للنواة: دخل تعديل في نظام الوسائط Media يجعل أحد الأوامر يرجع خطأ ENOENT فتعطلت برامج المستخدمين، ودافع مشرف النظام الفرعي Mauro Carvalho Chehab عن التعديل، فرد عليه لينوس برسالة بدأها بعبارة «SHUT THE F*** UP» بحروف كبيرة، ثم كتب «WE DO NOT BREAK USERSPACE!»، وشرح أن أي تغيير يكسر برامج المستخدمين خطأ في النواة. والمحتوى التقني هنا صحيح تماماً، وهو القاعدة التي شرحناها أعلاه، ولكن الطريقة جعلت هذه الرسالة أشهر مثال على أسلوبه.
3. يوليو 2013، نقاش Sarah Sharp: كتبت Sarah Sharp، وكانت مشرفة دعم USB 3.0 في النواة، رسالة علنية في 15 يوليو تطلب فيها أن يبقى النقاش مهنياً على القوائم البريدية، فرد لينوس في 16 يوليو بأنه يشتم المشرفين الذين يقدمون الأعذار بدل إصلاح التراجعات، وغطى موقع LWN النقاش في يومه. وفي أكتوبر 2015 نشرت Sharp مقالاً بعنوان «Closing a door» شرحت فيه سبب ابتعادها عن تطوير النواة، وقالت إنها تحتاج تواصلاً قاسياً تقنياً ولكنه محترم شخصياً، والمقال محفوظ في أرشيف الإنترنت.
4. 2 أبريل 2014، Kay Sievers: في نقاش عن خيار debug في سطر إقلاع النواة وتأثيره على systemd، أعلن لينوس في رسالة أنه لن يدمج أي كود من Kay Sievers حتى يتغير أسلوبه في التعامل مع الأخطاء التي يسببها ويتركها لغيره. والقرار هنا موجه لشخص بالاسم وعلناً، وهذا ما جعل كثيرين يرونه عقاباً شخصياً وليس قراراً تقنياً.
5. 17 نوفمبر 2017، Kees Cook: في رده على طلب سحب تعديلات تقوية الأمان Hardening من Kees Cook، وصف لينوس في رسالته أسلوب التعديلات بكلمات قاسية، وطلب من مطوري الأمان أن يكرروا أن المشكلات الأمنية مجرد أخطاء "security problems are just bugs"، أي أن الحل أن تحذر وتسجل المشكلة أولاً بدل أن توقف النظام فجأة وتكسر برامج المستخدمين.
6. 21 يناير 2018، تعديلات Intel لثغرة Spectre: رد لينوس على تعديلات IBRS من Intel برسالة وصفها فيها بأنها «COMPLETE AND UTTER GARBAGE»، أي قمامة كاملة، لأنه رأى أنها تجعل الحماية خياراً بدل أن تكون افتراضية. والرسالة كانت موجهة إلى شركة وتصميم أكثر منها إلى شخص.

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

سبتمبر 2018: الاعتذار والإجازة وقواعد السلوك

في 16 سبتمبر 2018 أصدر لينوس الإصدار 4.19-rc4 كالعادة، ولكن رسالة الإصدار حملت عنواناً غير معتاد: «Linux 4.19-rc4 released, an apology, and a maintainership note». وقال فيها إن أشخاصاً في المجتمع واجهوه بأنه لا يفهم مشاعر الناس، وإنه ليس شخصاً متعاطفاً بطبعه، وإنه أساء فهم أشخاص لسنوات وساهم في بيئة غير مهنية، وكتب:

"My flippant attacks in emails have been both unprofessional and uncalled for."

أي أن هجماته المستخفة في الرسائل كانت غير مهنية ولا مبرر لها، واعتذر لمن آذاهم سلوكه وربما أبعدهم عن تطوير النواة، وأعلن أنه سوف يأخذ إجازة ليتعلم كيف يفهم مشاعر الناس ويرد بشكل مناسب، وطلب من Greg Kroah-Hartman أن يكمل الإصدار 4.19 بدلاً منه. ولاحظ أنه قال صراحة إنها ليست إجازة بسبب الإرهاق Burnout، وإنه يريد أن يستمر في قيادة المشروع.

وفي الإصدار نفسه دخل تعديل من Greg Kroah-Hartman عنوانه «Code of Conduct: Let's revamp it»، استبدل وثيقة قديمة اسمها Code of Conflict بقواعد سلوك مبنية على Contributor Covenant، وهي القواعد التي شرحنا فكرتها وسلم العقوبات فيها في قسم قواعد السلوك والإشراف على النقاشات. وأثار التعديل نقاشاً واسعاً، فرأى بعض المطورين أنه فرض بسرعة ودون نقاش كاف، وغطى LWN هذا النقاش في 18 سبتمبر، ونشرت مجلة The New Yorker في 19 سبتمبر مقالاً عن سنوات الرسائل المسيئة. وبعد ذلك أضيفت وثيقة تفسير توضح كيف تطبق القواعد في النواة، ومنها أن المشرفين يقودون بالقدوة.

وفي 22 أكتوبر 2018 أصدر Greg الإصدار 4.19 وكتب في رسالة الإصدار أنه يعيد شجرة النواة إلى لينوس، وفي اليوم التالي نشر LWN ما دار عن قواعد السلوك في قمة المشرفين Maintainers Summit. ومنذ ذلك الوقت تعمل لجنة لقواعد السلوك وتنشر تقارير دورية على صفحة قواعد السلوك في kernel.org.

بعد 2018: خلافات حاسمة بلغة أهدأ

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

Rust في النواة: من التجربة إلى القرار

بدأ دعم لغة Rust في النواة كتجربة، وقد تابع LWN النقاش حول الالتزام بها في 2024، وسوف نشرح لماذا تهم سلامة الذاكرة Memory Safety ولماذا تنتقل المشاريع من C وC++ إلى Rust في مقال خاص، أما هنا فيهمنا كيف أدار لينوس الخلاف حولها:

• في 28 أغسطس 2024 أعلن Wedson Almeida Filho، أحد مشرفي مشروع Rust for Linux، تقاعده من المشروع، وقال إنه لم يعد يملك الطاقة للرد على ما سماه هراء غير تقني "nontechnical nonsense"، وأشار إلى مقطع من مؤتمر LSFMM في مايو 2024 قال فيه Ted Ts'o مشرف نظام الملفات ext4 إنهم لن يجبروا الجميع على تعلم Rust، وكان قلقه أن تغييرات C سوف تكسر واجهات Rust ثم يضطر هو لإصلاحها. وغطى القصة LWN وThe Register.
• في 28 يناير 2025 رفض Christoph Hellwig، مشرف نظام DMA Mapping، واجهة Rust لنظامه، ووصف انتشار الكود متعدد اللغات في الأنظمة الأساسية بأنه سرطان، وأوضح في الرسالة نفسها أنه يقصد قاعدة الكود متعددة اللغات وليس Rust نفسها، وشرح LWN وجهة نظره بأن صيانة كود بلغتين أصعب على المشرف.
• في فبراير 2025 لجأ Hector Martin، مشرف دعم أجهزة Apple في مشروع Asahi Linux، إلى وسائل التواصل الاجتماعي للضغط في هذا الخلاف، فرد لينوس في 6 فبراير برسالة قال فيها إن عملية التطوير تعمل، وإن الحشد في وسائل التواصل يجعله لا يريد أي علاقة بهذا الأسلوب، وسأله إن كانت المشكلة فيه هو. وفي اليوم التالي أزال Hector Martin اسمه من قائمة المشرفين.
• في 20 فبراير 2025 كتب لينوس إلى Hellwig أنه يحترمه تقنياً ويحب العمل معه، ولكن طلب السحب المرفوض لم يلمس كود DMA أصلاً، وأن المشرف لا يملك أن يقرر من يستخدم كوده:

"if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG."

وبعد أيام، في 24 فبراير 2025، أرسل Hellwig تعديلاً يسلم فيه صيانة DMA Mapping إلى Marek Szyprowski. وفي ديسمبر 2025 خرجت قمة المشرفين بقرار أن التجربة انتهت بنجاح كما يذكر LWN، وأرسل Miguel Ojeda قائد مشروع Rust for Linux تعديلاً يزيل وصف التجربة ويقول إن Rust باقية.

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

bcachefs وKent Overstreet: عندما لا تحترم دورة الإصدار

نظام الملفات bcachefs من تطوير Kent Overstreet، ودمج في النواة في نافذة الدمج للإصدار 6.7 في أكتوبر 2023، وصدر الإصدار 6.7 في يناير 2024. ثم تكررت الخلافات حول إرسال تعديلات كبيرة في مرحلة rc التي تقبل الإصلاحات فقط، وفي 22 نوفمبر 2024 قررت لجنة قواعد السلوك رفض كل طلبات السحب من Kent خلال دورة الإصدار 6.13 بسبب أسلوبه مع مطور آخر.

وفي 26 يونيو 2025 سحب لينوس إصلاحات bcachefs للإصدار 6.16-rc4، ولكنه كتب في رده أنهما سوف يفترقان في نافذة دمج 6.17، وقال إن Kent أوضح له أنه لا يستطيع حتى أن يسأل عن أي إصلاح. وفي 28 أغسطس 2025 غير لينوس حالة bcachefs في ملف MAINTAINERS إلى «يصان خارجياً» Externally Maintained، وفي 29 سبتمبر 2025، في نافذة دمج 6.18، حذف كود bcachefs من النواة، لأنه صار يوزع كوحدة DKMS خارج النواة كما أعلن Kent نفسه، وغطى LWN هذا القرار.

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

حذف مشرفين بسبب العقوبات في أكتوبر 2024

في 18 أكتوبر 2024 دخل تعديل من Greg Kroah-Hartman يحذف عدداً من المشرفين من ملف MAINTAINERS بعنوان «متطلبات امتثال» Compliance Requirements، وذكر LWN أن James Bottomley ربط ذلك بقوائم العقوبات الأمريكية، وذكرت Ars Technica أن أغلب من حذفت أسماؤهم يعملون لدى شركات روسية. وعندما أرسل بعض المطورين تعديلاً يطلب التراجع عن هذا الحذف، رد لينوس في 23 أكتوبر برسالة رفض فيها التراجع، وقال إنه فنلندي ولن يدعم العدوان الروسي "I'm Finnish. Did you think I'd be *supporting* Russian aggression?"، وإن القرار لن يتغير. ويرى المنتقدون أن الحذف تم دون إعلان واضح للأسباب ودون شكر لمن خدموا المشروع سنوات، ويرى المؤيدون أن المؤسسات القانونية خلف المشروع ملزمة بالقوانين التي تعمل في ظلها، وقد أعيدت بعض الأقسام لاحقاً بمشرفين جدد.

طلب RISC-V في أغسطس 2025

في 9 أغسطس 2025 رفض لينوس طلب سحب RISC-V للإصدار 6.17 من المشرف Palmer Dabbelt برسالة بدأها بأن هذا الطلب قمامة وقد جاء متأخراً "This is garbage and it came in too late"، ثم شرح بالتفصيل الكود الذي اعترض عليه. ولاحظ الفرق عن أمثلة ما قبل 2018: الكلمة قاسية والسبب هو نفسه، أي احترام نافذة الدمج وجودة الكود، ولكن الرسالة لا تحتوي شتائم شخصية.

ماذا نتعلم منه كقادة ومشرفين في المنطقة؟

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

• معيار تقني مكتوب وواضح: قاعدة «لا تكسر برامج المستخدمين» مكتوبة في وثائق النواة بأقواله وتواريخها، فلا يحتاج أحد أن يخمن ما المقبول. اكتب معايير مشروعك في ملفات CONTRIBUTING وفي وثائق المراجعة، وطبقها على الجميع.
• القدرة على قول لا: المشروع الذي يقبل كل شيء يفقد شكله، ولينوس يرفض تعديلات تعمل فعلاً لأنها معقدة أو جاءت في الوقت الخطأ، والسبب أن الصيانة لعشر سنوات أهم من ميزة اليوم.
• تفويض الثقة Delegation: سلم Git لـ Junio Hamano بعد أقل من أربعة أشهر، ويدمج اليوم من مشرفين يثق بهم بدل أن يراجع كل سطر. إذا كان كل قرار في فريقك يمر بك فأنت عنق الزجاجة، والحل أن تختار أشخاصاً تثق بذوقهم ثم تتركهم يعملون.
• الثبات Consistency: دورة الإصدار نفسها كل شهرين إلى ثلاثة أشهر منذ سنوات، والقواعد نفسها على Intel وعلى متطوع يرسل أول تعديل، وهذا الثبات هو ما يجعل الشركات تبني على النواة دون خوف.
• العمل في العلن: كل نقاش وكل قرار مؤرشف في lore.kernel.org، فتستطيع أن تقرأ لماذا رفض أي تعديل قبل عشرين سنة. وهذا يحمي المشروع من القرارات الشخصية الخفية.

وما لا يجب أن ننقله:

• اللغة المسيئة: لا تقم بإهانة شخص لأنه أخطأ، والسبب ليس المجاملة وإنما أن الإهانة تطرد الأشخاص الذين تحتاجهم، ولينوس نفسه قال في 2018 إن أسلوبه ربما أبعد أشخاصاً عن تطوير النواة واعتذر عن ذلك. فإذا كان صانع Linux قد اعتذر، فلا يوجد سبب لأن يقلد أحد الأسلوب الذي اعتذر عنه.
• الخلط بين الشخص والتعديل: انتقد الكود بقسوة إذا لزم الأمر، كما في مثال RISC-V، ولكن لا تحكم على الشخص أمام الجميع، وإذا احتاج الأمر قراراً بحق شخص فاجعله عبر جهة مثل لجنة قواعد السلوك وليس في رسالة غاضبة.
• الاعتماد على شخص واحد: نموذج BDFL نجح في النواة لأن خلفه مئات المشرفين وسلسلة ثقة ومؤسسة تدفع الرواتب، أما في مشروع صغير فهو خطر، لذلك اكتب خطة لما بعدك من البداية كما شرحنا في مقال الحوكمة.

والقاعدة التي تجمع كل ما سبق هي الجملة التي كتبتها Sarah Sharp، وهي تصلح لكل فريق في أي بلد: تواصل قاس تقنياً ومحترم شخصياً.

الخلاصة

• ولد لينوس تورفالدز في هلسنكي في 28 ديسمبر 1969، وبدأ نواة Linux وهو طالب في جامعة هلسنكي في 1991، ونقلها إلى رخصة GPL في 1992.
• عمل في Transmeta في كاليفورنيا منذ 1997، ثم تفرغ للنواة في OSDL منذ يونيو 2003، وهو اليوم زميل Fellow في Linux Foundation، وحصل على جائزة Millennium Technology Prize في 2012.
• كتب Git بعد سحب الرخصة المجانية لـ BitKeeper في أبريل 2005، وسلمه إلى Junio Hamano في 26 يوليو 2005.
• يدير النواة بنافذة دمج مدتها أسبوعان ثم أسابيع من إصدارات rc للإصلاحات فقط، وبسلسلة ثقة في المشرفين، وبقاعدة «لا تكسر برامج المستخدمين».
• كانت لغته على القوائم البريدية قاسية ومسيئة لسنوات، واعتذر عنها في 16 سبتمبر 2018 وأخذ إجازة، ودخلت قواعد السلوك إلى النواة في الإصدار 4.19.
• بعد 2018 بقي حازماً في قرارات Rust وbcachefs والعقوبات وطلبات السحب المتأخرة، ولكن بلغة أهدأ بكثير.
• انقل منه المعيار الواضح والقدرة على الرفض والتفويض والثبات، واترك اللغة التي اعتذر عنها بنفسه.

وإذا أردت أن تكمل من هنا، فهذه مقالات تشرح المشروع والأدوات والحوكمة التي مر ذكرها:

دليلما هي البرمجيات مفتوحة المصدر؟ القصة وأشهر الرخصكيف بدأت البرمجيات الحرة والمفتوحة، وما الفرق بين الحر والمجاني، وكيف تعرف ما تسمح به رخصة أي مشروع قبل أن تبني عليه.دليلإدارة النسخ وGit للمبتدئين: لماذا نحتاجها وكيف تعمللماذا تضيع الملفات بأسماء final_v2 ويمسح الزملاء عمل بعضهم، وكيف يحل Git ذلك على مشروع حقيقي من أول commit.دليلمن يدير المشروع مفتوح المصدر؟ نماذج الحوكمة Governanceمن يقرر في مشروع يساهم فيه آلاف الأشخاص، ومن يستطيع تغيير رخصته، وما الذي تفحصه قبل أن تعتمد على أي مشروع.دليلمشاريع Linux Foundation خارج CNCFكيف تحولت Linux Foundation إلى مظلة فوق OpenJS وPyTorch وOpenSSF وValkey وغيرها، ومن يمولها ويقرر فيها، وكيف تقارن بمؤسسات Apache وEclipse وPython.دليللماذا تساهم الشركات الكبيرة في المصادر المفتوحة، ولماذا نغيب نحن عنها؟موظفو Intel وGoogle وRed Hat يكتبون جزءاً كبيراً من نواة Linux وKubernetes، ولذلك أسباب اقتصادية مكتوبة. أعرض الأدلة والأسباب وأرقام منطقتنا، ثم رأيي فيما يكلفنا غيابنا وما تستطيع شركتك أن تبدأ به هذا الربع.دليلأمان الذاكرة Memory Safety: لماذا تدفع الحكومات نحو Rust؟ماذا طلبت الحكومات فعلاً بشأن C وC++، ولماذا تسبب أخطاء الذاكرة أغلب الثغرات الخطيرة، ومتى يكون Rust هو الاختيار الصحيح.دليلقصص لغات البرمجة ومن صنعها، من Fortran إلى Rustمن صنع اللغات التي نكتب بها كل يوم، وما المشكلة التي دفعته إلى ذلك، وكيف تشرح قصة كل لغة قراراتها.

سجل التحديثات (Changelog)

• أكتوبر 2026: كتابة المقال اعتماداً على رسائل لينوس تورفالدز في أرشيف lore.kernel.org ووثائق النواة الرسمية ومقابلته في TED ومواقع الجهات التي منحته الجوائز وتغطية LWN والصحافة التقنية، مع صور من Wikimedia Commons برخص حرة تم التحقق منها، ورسوم توضيحية من عملنا.