Dormant at the core: Inactivity, dependence and exit among the most downloaded npm packages

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

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

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

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

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

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

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