Removing Noise or Introducing Bias? The Hidden Cost of MSR Filtering

تخيل الإنترنت كمكتبة ضخمة وفوضوية حيث يمكن لأي شخص بناء رف كتب وتسميته مكتبة. هذا هو عالم البرمجيات مفتوحة المصدر (OSS)، وهو ساحة لعب رقمية هائلة حيث يخزن ملايين الأشخاص — من الطلاب الذين يختبرون أفكاراً برمجية جديدة إلى المطورين المحترفين الذين يبنون التطبيق الكبير القادم — مشاريعهم. الباحثون، الذين يشبهون المحققين الذين يحاولون حل الألغاز حول كيفية عمل البرمجيات، يحبون زيارة هذه المكتبة. إنهم ينقبون في الرفوف، باحثين عن عدد المرات التي "أعجب" فيها الناس بمشروع ما (النجوم)، وعدد المرات التي غير فيها الناس الكتب (التعديلات/Commits)، وعدد الأشخاص الذين ساعدوا في كتابتها. هذه الأدلة تساعدهم على فهم أسرار هندسة البرمجيات. ولكن هنا تكمن المشكلة: المكتبة ضخمة جداً لدرجة أنها مليئة بالصناديق الفارغة، والدمى الاختبارية، والرسومات غير المكتملة. وللعثور على الكتب "الحقيقية"، يقوم الباحثون عادةً بالتخلص من أي شيء لا يبدو شعبياً أو نشطاً بما يكفي. يستخدمون قواعد مثل: "إذا لم يكن للمشروع 10 نجوم على الأقل، فهو مجرد ضجيج، لذا دعونا نتخلص منه".

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

الفلتر العظيم: تنظيف البيانات أم إخفاء الحقيقة؟

في هذه الدراسة، قرر المؤلفان لعب لعبة "ماذا لو؟" مع كومة هائلة من البيانات. لقد نظروا في 1.57 مليون مستودع برمجيات من منصة تسمى SEART. فكر في مجموعة البيانات هذه كدلو ضخم من قطع الليغو المختلطة؛ بعضها مجموعات قلاع كبيرة وملونة؛ والبعض الآخر عبارة عن قطع حمراء صغيرة مفردة؛ والعديد منها مجرد قطع مكسورة لم يكملها أحد.

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

التكلفة الخفية لـ "الشعبية"
عندما طبق الباحثون "فلتر الشعبية" (النظر فقط في المشاريع التي تمتلك المزيد من النجوم)، وجدوا شيئاً مفاجئاً. عندما رفعوا حد النجوم من 10 إلى 1,000، لم يصبح المشروع "المتوسط" في عيّنتهم أفضل قليلاً فحسب، بل أصبح أكبر بـ 7 مرات. أصبحت المشاريع أقدم، وهناك المزيد من الأشخاص يعملون عليها، وكانت أكثر عرضة لامتلاك رخصة رسمية (مثل كتاب قواعد).

ولكن إليكم المفاجأة: من خلال مطاردة المشاريع الشعبية، فقدوا الرؤية للواقع تماماً. في دلوهم الأصلي غير المفلتر، كانت 73.42% من المشاريع في الواقع غير نشطة أو "مهجورة". ومع ذلك، عندما قاموا بالفلترة بحثاً عن الشعبية، انخفض هذا الرقم. وبحلول الوقت الذي نظروا فيه فقط إلى المشاريع فائقة الشعبية (1,000 نجمة فأكثر)، جعلت البيانات تبدو وكأن 50.65% فقط هي المهجورة. لم يقم الفلتر بإزالة الضجيج فحسب؛ بل أخفى حقيقة أن معظم المشاريع تفشل أو تُترك خلفها. الأمر يشبه إذا سألت فقط الأشخاص الأكثر نجاحاً في مدينة ما عن وظائفهم، ثم استنتجت أن "البطالة منخفضة" لأنك لم تتحدث أبداً مع الأشخاص الذين فقدوا وظائفهم.

فخ "النشاط"
اختبر المؤلفون أيضاً "فلاتر النشاط"، والتي تحتفظ فقط بالمشاريع ذات العدد العالي من التعديلات (commits). كان هذا أكثر تطرفاً. فعندما قاموا بفلترة المشاريع ذات النشاط العالي، نما حجم المشروع المتوسط بمقدار 18 مرة! غيرت هذه الفلاتر أيضاً "شخصية" البرمجيات. على سبيل المثال، كانت المشاريع التي تستخدم لغة ++C شائعة في المجموعات ذات العتبة المنخفضة، لكنها اختفت من قائمة الخمس الأوائل عندما أصبح الفلتر صارماً. وفي الوقت نفسه، أصبحت لغتا TypeScript و Go أكثر شيوعاً في القوائم المفلترة.

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

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

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

الحكم النهائي: لا تتخلصوا من الضجيج فحسب

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

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

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