نادراً ما يشتكي الباحثون من نقص البرمجيات. بل على العكس، هم يواجهون المشكلة المعاكسة: الكثير من الأدوات غير المترابطة التي يتم ربطها معاً باستخدام نصوص shell والأمل. يسعى مشروع جديد مفتوح المصدر يسمى OpenScience إلى استبدال هذا المزيج غير المتجانس بمنصة عمل واحدة مدعومة بالذكاء الاصطناعي ومصممة خصيصاً للاكتشاف العلمي. بُني المشروع بلغة TypeScript وقد جمع بالفعل أكثر من 2,167 نجمة على GitHub، وهو يطمح لتزويد المختبرات ببيئة مشتركة يساعد فيها الذكاء الاصطناعي على أتمتة سير العمل، وإدارة البيانات التجريبية، وإبقاء المتعاونين على توافق تام. الطموح واضح، ولكن يبقى السؤال عما إذا كان بإمكانه الصمود أمام واقع صيانة المشاريع مفتوحة المصدر والمنافسة الشرسة.
لماذا يحتاج البحث العلمي إلى منصة عمل خاصة به
يعتمد التقدم العلمي على قابلية التكرار (reproducibility). فلا معنى لأي نتيجة إذا لم يتمكن فريق آخر من إجراء نفس التحليل والوصول إلى نفس الاستنتاج. ومع ذلك، فإن مسارات تعلم الآلة (machine learning pipelines) الحديثة تتسم بالفوضوية بشكل ملحوظ؛ حيث تختبئ خطوات المعالجة المسبقة داخل خلايا Jupyter مبعثرة، وتُكتب المعلمات الفائقة (hyperparameters) بشكل ثابت داخل نصوص برمجية غير موثقة، وتُنسخ مجموعات البيانات وتُعاد تسميتها وتُفقد عبر محركات الأقراص المشتركة. وعندما يغادر طالب دراسات عليا، فإن سير عمله غالباً ما يغادر معه.
يهدف OpenScience إلى مواجهة هذه الفوضى مباشرة. فمن خلال تقديم منصة موحدة بدلاً من مجموعة مفككة من المكتبات، يأمل المشروع في فرض الاتساق في كيفية إعداد التجارب وتتبعها ومشاركتها. ويعد التعاون محوراً أساسياً في هذا الطرح؛ فبدلاً من إرسال الأكواد عبر البريد الإلكتروني ذهاباً وإياباً أو الصراع مع أنظمة التحكم في الإصدارات (version control)، سيعمل الباحثون داخل بيئة مشتركة تسجل من قام بتغيير ماذا ومتى. وبالنسبة للمجالات التي قد تستهلك فيها تجربة واحدة أسابيع من الحوسبة، فإن هذا النوع من الشفافية ليس رفاهية، بل هو ضرورة.
الرهان على TypeScript للأكواد العلمية
إن قرار بناء هذا المشروع باستخدام TypeScript هو أمر غير متوقع. فتعلم الآلة يعتمد على Python، نقطة انتهى. فمكتبات TensorFlow وPyTorch والغالبية العظمى من قواعد الأكواد البحثية مكتوبة بها. وعادة ما يكتب العلماء نصوصهم البرمجية بلغة Python أو R، وكثير منهم لا يعرف من JavaScript سوى ما يكفي لتعديل تصور مرئي للويب. فما الداعي لاستخدام TypeScript إذاً؟
يجادل فريق التطوير بأن التنميط الثابت (static typing) يحافظ على تنظيم الكود وموثوقيته. ففي العمل العلمي، يمكن لخطأ واحد صامت في نوع البيانات (type error) أن يبطل شهوراً من العمل المختبري. تكتشف TypeScript فئات كاملة من الأخطاء وقت التجميع (compile time) بدلاً من تركها تنفجر أثناء مهمة تدريب طويلة الأمد. وبالنسبة لمنصة تسعى لضمان قابلية التكرار، فإن هذه الدقة تعد أمراً جذاباً.
ومع ذلك، هناك مقايضات حقيقية. تجذب TypeScript المطورين الذين يقدرون الأدوات الاحترافية، ولكنها قد تنفر الباحثين أنفسهم الذين يأمل OpenScience في خدمتهم. فالعالم البيولوجي الذي تعلم أساسيات JavaScript لتنسيق بيانات الاستطلاع، سيتعين عليه الآن التعامل مع الواجهات (interfaces)، والأنماط العامة (generics)، ومسارات البناء (build pipeline). منحنى التعلم حاد، وإذا أجبرت المنصة كل مستخدم على أن يصبح مهندس برمجيات قبل أن يتمكن من تدريب نموذج، فسوف يتوقف تبنيها. الرهان هو أن العائد طويل الأمد في الاستقرار يفوق الصعوبات قصيرة المدى في عملية التهيئة.
ما يعد به OpenScience
يريد المشروع تبسيط مهمتين تستهلكان حالياً قدراً هائلاً من الجهد الذهني: تدريب النماذج وتتبع التجارب. وبدلاً من مطالبة الباحثين بربط نصف درزن من أدوات سطر الأوامر (command-line utilities) معاً، يخطط OpenScience لتقديم واجهة متماسكة. كما ينوي التكامل مع العمالقة في هذا المجال، وتحديداً TensorFlow وPyTorch، حتى لا يضطر العلماء إلى التخلي عن المكتبات المألوفة لديهم.
ومن المفترض أن يقوم الذكاء الاصطناعي نفسه ببعض المهام الشاقة. تهدف منصة العمل إلى أتمتة سير العمل المتكرر؛ فكر في خطوط أنابيب تنظيف البيانات المولدة تلقائياً، أو الاقتراحات الذكية للمعلمات الفائقة بناءً على عمليات التشغيل السابقة، أو التسجيل الآلي الذي يسجل بالضبط أي إصدار من مجموعة البيانات أنتج نتيجة معينة. إذا تحقق هذا التصور، فقد يحرر الباحثين للتركيز على الفرضيات بدلاً من البنية التحتية.
خطر تضخم التكامل
كل عملية تكامل مخططة هي وعد يتطلب صيانة. فمكتبات TensorFlow وPyTorch تصدر تحديثات متكررة. وأي تغيير جذري واحد في تبعية أساسية يمكن أن يمتد عبر طبقات التجريد (abstraction layers) في OpenScience ويترك المستخدمين يواجهون تتبعات مكدس (stack traces) غامضة بدلاً من تشغيل التجارب. كما أن المزيد من المكتبات يعني المزيد من التصحيحات الأمنية، والمزيد من تعارض الإصدارات، والمزيد من الفرص للمنصة لتفقد التزامن مع الأدوات التي من المفترض أن تخدمها.
تعقيد الإعداد هو القاتل الصامت لبرمجيات الأبحاث. إذا كان تثبيت OpenScience يتطلب صراعاً مع تعريفات CUDA، وإصدارات محددة من Node.js، وبيئات Python متضاربة، فإن طلاب الدراسات العليا المشغولين سيتوجهون ببساطة إلى علامة تبويب Google Colab حيث تكون بيئة التشغيل مهيأة مسبقاً. الأبحاث تتم ضمن جداول زمنية ضيقة، ولا أحد ينال منشوراً علمياً بقضاء ثلاثة أسابيع في تصحيح أخطاء سلسلة الأدوات.
يبدو أن المطورين مدركون لهذا التوتر؛ فتحديهم يكمن في توفير قوة كافية لتكون الأداة مفيدة دون أن تصبح ثقيلة لدرجة تنهار معها تحت وطأة وزنها.
الاستدامة في العالم المفتوح
لقد جعلت البرمجيات مفتوحة المصدر كل شيء في متناول الجميع، بدءاً من تطوير الويب وصولاً إلى تحليل البيانات. يمكن لأي شخص فحص الكود، أو المساهمة في إصلاح، أو اشتقاق المشروع (fork) لحالة استخدام متخصصة. هذا الانفتاح يعمل بشكل جيد عندما تعتمد مجتمعات كبيرة من المحترفين المأجورين على قاعدة الكود في وظائفهم اليومية.
لكن الأدوات العلمية مفتوحة المصدر تواجه واقعاً مختلفاً. قد تبدو تلك الـ 2,167 نجمة على GitHub واعدة، لكن النجوم لا تمول القائمين على الصيانة. دورات المنح تنتهي، وطلاب الدراسات العليا يمضون في مساراتهم. وبدون دعم مؤسسي مستقر أو فريق أساسي مخصص، حتى المشاريع العبقرية تتصلب وتتوقف عن التطور. يظل المستودع (repository) خاملاً لمدة عام، وتتقادم التبعيات (dependencies)، ويُترك المتبنون الأوائل مع كود مهجور لم يعد قابلاً للتشغيل على الأجهزة الحديثة. بالنسبة لمنصة تطمح لاستضافة علم قابل لإعادة الإنتاج، فإن الهجر أسوأ من عدم الوجود من الأساس. تحتاج OpenScience إلى دعم طويل الأمد من الجامعات أو المختبرات أو هيئات التمويل إذا أرادت البقاء والاستمرار لما بعد العناوين الصحفية.
المنافسة مع Jupyter و Colab و MATLAB
تدخل OpenScience إلى ساحة مزدحمة. تُعد Jupyter Notebooks هي المسودة الافتراضية للأبحاث الاستكشافية في Python. وقد أزال Google Colab حاجز الأجهزة من خلال توفير وحدات معالجة رسومية (GPUs) مجانية داخل علامة تبويب المتصفح. ولا يزال MATLAB يهيمن على الأقسام الهندسية التي تقدر صناديق أدواته المدعومة بضمانات وعقود، وخبراته المؤسسية الممتدة لعقود.
ولجذب المستخدمين بعيداً عن هذه الأدوات الراسخة، يجب أن تقدم OpenScience شيئاً لا توفره. ربما يكون ذلك تعاوناً حقيقياً بين عدة مستخدمين دون تأخير (latency) المذكرات المشتركة. أو ربما يكون هيكل حوكمة يقود فيه العلماء، وليس المطورون فقط، خارطة الطريق. أو ربما يكون مستوى من إصدار التجارب (versioning) يجعل إعادة الإنتاج عملية تلقائية بدلاً من كونها فكرة لاحقة.
ومهما كانت الميزة التنافسية، يجب أن تظل الأداة سهلة الوصول. فإذا كانت تتطلب محطات عمل محلية عالية الأداء أو تفترض أن كل مستخدم مرتاح لتشغيل خادم تطوير، فلن تغادر أبداً صفحة GitHub الرائجة. فالباحثون يسعون لتحقيق الإجابات، وليس لتهيئة البرمجيات.
الاختبار الحقيقي: الحوكمة فوق الكود
لن يدفع TypeScript النظيف وقائمة الميزات الطموحة بالمشروع إلا لمسافة محدودة. إن تاريخ البرمجيات العلمية مليء بقواعد برمجية جميلة فشلت لأنها بُنيت من قبل مطورين لأجل المطورين. لا يحتاج عالم المختبر إلى واجهة مستخدم براقة إذا كان مستورد ملفات CSV يتعطل عند التعامل مع بيانات من العالم الحقيقي. هم بحاجة إلى أدوات تحترم المشقة الفعلية للبحث: انقطاع الإنترنت في المحطات الميدانية، وتنسيقات الملفات غير المنظمة من الأجهزة القديمة، والمتطلب الأساسي لإثبات أي كود أنتج أي شكل بياني بالضبط أمام مراجع متشكك.
يعتمد النجاح على حوكمة المجتمع. يحتاج الباحثون الرئيسيون، ومديرو المختبرات، وطلاب الدراسات العليا إلى صوت حقيقي في تقرير ما سيتم بناؤه. يجب أن تلتقي OpenScience بالعلماء حيث يتواجدون، وليس حيث يفترض المطورون أنهم يجب أن يكونوا.
الخلاصة
تعد OpenScience تجربة مثيرة للاهتمام حقاً؛ فهي تطبق صرامة هندسة البرمجيات المعتمدة على الأنواع (typed software engineering) على عالم الاكتشاف العلمي الفوضوي والتكراري. هذا المزيج نادر في مجال تهيمن عليه سكربتات Python السريعة. لكن الخيارات التقنية تحمل مخاطر، والمنافسة شرسة، والطريق من نجوم GitHub إلى بنية تحتية مستدامة هو طريق وعر. الكود مفتوح. النجوم تتراكم. التحدي الحقيقي الآن هو بناء الـ