في 28 أبريل 2026، أعلن ميتشل هاشيموتو أن Ghostty، محاكي الطرفية مفتوح المصدر الخاص به، سيغادر GitHub. وهو مستخدم GitHub رقم 1299. انضم في فبراير 2008. وقد استخدم المنصة بشكل شبه يومي لأكثر من 18 عامًا. لم يكن أي من ذلك مهمًا في اليوم الذي كتب فيه المنشور؛ فقد كان يحتفظ بالفعل بمذكرات "كل يوم تقريبًا به تعطيل X"، وأدى فشل في GitHub Actions في يوم الإعلان إلى منع مراجعات طلبات السحب (PR) الخاصة به لمدة ساعتين. كان حكمه مباشرًا: "لم يعد هذا مكانًا للعمل الجاد إذا كان يعيقك لساعات في اليوم، كل يوم."
إذا كنت تبني أدوات للمطورين، فهذا هو الإعلان الذي يجب قراءته مرتين. هاشيموتو ليس مستخدمًا عاديًا لـ GitHub؛ فقد شارك في تأسيس HashiCorp على GitHub، وقد أطلق Terraform، وVagrant، وVault، وConsul، وBoundary من خلاله، وهو مستخدم GitHub رقم 1299. عندما يبتعد هذا النوع من المستخدمين عن منصة المطورين المهيمنة على الأرض، تكون القصة أكبر من مجرد محاكي طرفية واحد يختار منزلًا جديدًا. إنها إشارة حول الموثوقية، والارتباط بالمنصة (lock-in)، وما يكلفه بناء أداة يعتمد عليها المطورون الآخرون كل يوم. سيتناول هذا المقال ما قاله هاشيموتو، وما يعنيه ذلك لأي شخص يشحن أدوات للمطورين، والأنماط التي تحمي مكدسك الخاص من نفس الفخ.
للحصول على السياق الأوسع حول كيفية تغيير أدوات المطورين في عصر الذكاء الاصطناعي لسير عمل GitHub الأصلي، راجع كيفية كتابة ملفات AGENTS.md واستخدام GitHub Copilot وفاتورة API للفرق. للحصول على نظرة فريق واحد حول الأتمتة حول فجوات موثوقية GitHub، راجع تقرير روبوت الفرز Clawsweeper.
باختصار
- أعلن ميتشل هاشيموتو في 28 أبريل 2026 أن Ghostty سيغادر GitHub إلى منصة تطوير (forge) لم يتم تسميتها بعد.
- السبب الذي ذكره: انقطاعات مزمنة في GitHub Actions والمنصة قام بتوثيقها في مذكراته الشخصية على أنها "كل يوم تقريبًا به تعطيل X". وشهد يوم الإعلان انقطاعًا في Actions لمدة ساعتين منع مراجعات طلبات السحب (PR).
- احتفظ بنسخة مطابقة (mirror) لقراءة فقط من Ghostty على GitHub وينقل التطوير النشط تدريجيًا؛ وتبقى مشاريعه الأخرى على GitHub في الوقت الحالي.
- تكمن أهمية القصة في أن هاشيموتو، مستخدم GitHub رقم 1299، ابتعد لأسباب تتعلق بالموثوقية، وليس لأسباب تتعلق بالميزات، وليس في المكان الذي سينتقل إليه Ghostty.
- بالنسبة لبناة أدوات المطورين، الدرس هو أن الموثوقية تتفوق على الميزات بمجرد أن تصبح أداتك جزءًا من المسار الحرج لشخص ما. مسرح صفحة الحالة وتغريدات "نحن نحقق" لا تعيد لك الثقة.
- بالنسبة لفرق API على وجه الخصوص، فإن استراتيجية العمل هي الفصل: عملاء مستقلون عن المزودين، واعتمادات وهمية أثناء الانقطاعات، ومسارات ترحيل تقوم بتدريبها قبل أن تحتاج إليها. Apidog مبني على هذا النمط.
ما قاله هاشيموتو في المنشور
منشور الإعلان قصير، وهذا جزء من الرسالة. لا يوجد بيان، ولا نقد لـ Microsoft، ولا ترويج لمنصة بديلة. يوضح هاشيموتو الجدول الزمني ببساطة: بدأ في الاحتفاظ بمذكرات لانقطاعات GitHub، وامتلأت المذكرات أسرع مما توقع، وفي صباح اليوم الذي كتب فيه المنشور، منعه فشل في GitHub Actions من مراجعة طلبات السحب (PRs) لمدة ساعتين. وخلص إلى أن المنصة لم تعد موثوقة بما يكفي للنوع الذي يقوم به على Ghostty.
الأرقام المحيطة بالإعلان تستحق التدقيق. شهد يوم 27 أبريل 2026، وهو اليوم السابق لمنشور هاشيموتو، انقطاعًا كبيرًا في GitHub أثر على Actions، والحزم، وواجهة API. المذكرات التي يشير إليها في المنشور تسبق هذا الانقطاع؛ فقد كان يتتبع النمط لأشهر. ويؤطر هذه الخطوة على أنها شيء تم التخطيط له بهدوء، وليس رد فعل على يوم سيء واحد. أثر انقطاع 27 أبريل على التوقيت، وليس القرار.
وهو صريح أيضًا بشأن الحدود. يغادر Ghostty؛ وتبقى مشاريعه الأخرى على GitHub في الوقت الحالي. سيظل مستودع Ghostty كنسخة للقراءة فقط على العنوان الحالي؛ وستستضيف منصة تطوير جديدة التطوير النشط، بما في ذلك المشكلات، وطلبات السحب، وCI. وهو في محادثات مع مزودين متعددين، تجاريين ومفتوحي المصدر، ولم يلتزم بوجهة بعد. سيتم تنفيذ الهجرة تدريجيًا، وليس دفعة واحدة.
الاستبعاد يخبرك بقدر الكلمات. لا يذكر هاشيموتو الميزات، أو التسعير، أو اتجاه المنتج. الشكوى هي أن الواجهة التي اعتمد عليها تتوقف عن الاستجابة لساعات في كل مرة، ولا يمكن لمشروع يشحن برمجيات أن يعمل على أساس غير مستقر.
لماذا زاوية الموثوقية أهم من الهجرة
معظم التغطية للإعلان تطرح السؤال الخاطئ. السؤال المثير للاهتمام ليس أين سيستقر Ghostty؛ السؤال المثير للاهتمام هو كيف وصلت منصة بهذا العمق الهندسي مثل GitHub إلى النقطة التي ابتعد فيها ثاني أبرز مستخدميها لأسباب تتعلق بالموثوقية. السؤال الثاني الأكثر إثارة للاهتمام هو ما الذي يقوله ذلك عن الأدوات التي يبنيها بقيتنا.
ثلاثة أشياء تجعل هذا الإعلان مختلفًا عن منشورات "أنا أغادر X" المعتادة.
المستخدم. هاشيموتو ليس مطورًا جديدًا؛ لقد بنى أدوات بنية تحتية تستخدمها شركات Fortune 500. عندما يقول إن GitHub غير موثوق به، فإن الجمهور الذي يتلقى هذه الرسالة يشمل الأشخاص الذين يقررون أين تعيش شفرة مصدر شركتهم. كانت قوائم البريد الإلكتروني للمديرين التقنيين (CTO) ممتلئة بالفعل بالمنشور بحلول صباح 29 أبريل.
السبب. لم يغادر بسبب Copilot، أو Microsoft، أو تدريب الذكاء الاصطناعي، أو عقود ICE، أو التسعير، أو أي من مواضيع المغادرة المعتادة. لقد غادر لأن الخدمة كانت تتعطل باستمرار. هذا يختصر النقاش إلى المحور الوحيد الذي يتفق الجميع على أهميته: هل تعمل الأداة عندما تحتاج إليها؟
اللهجة. لا يوجد غضب. يُقرأ المنشور وكأنه تقرير ما بعد الوفاة كتبه شخص حاول جاهدًا البقاء. عدم وجود الدراما هو ما يجعله يؤثر بقوة أكبر من أي منشور آخر أكثر صخبًا. الناس يصدقونه.
بالنسبة لأي شخص يدير أداة للمطورين، فإن هذا المزيج هو صوت أسوأ سيناريو لديك. مستخدم قديم، لا توجد دوافع سياسية، لا شجار علني، فقط تراكم هادئ لإدخالات "الشيء لم يعمل اليوم" حتى لم يعد الحساب منطقيًا. لا يوجد رد علاقات عامة على مذكرات.
ماذا يعني هذا إذا كنت تبني أدوات للمطورين
إذا كان منتجك يقع ضمن المسار الحرج للمطور، فإن إعلان هاشيموتو هو محفز لاختبار الضغط. قم بتشغيله على خدمتك الخاصة.
السؤال الأول: ما هو عدد المستخدمين الذين يمكنهم كتابة نفس المذكرات عنك؟
اسحب آخر 90 يومًا من حوادث صفحة الحالة الخاصة بك، بالإضافة إلى الأعطال غير المبلغ عنها التي يعرفها فريقك ولكن صفحة الحالة لا تعرفها. قارنها بساعات عمل أهم 20 عميلًا لديك. احسب عدد الساعات التي ضاعت في انتظارك. إذا كانت الإجابة "أكثر من صفر في الأسبوع لكل مستخدم كثيف"، فأنت على نفس المسار.
السؤال الثاني: ما هو المشتق الثاني لموثوقيتك؟
الموثوقية التي تستقر جيدة. الموثوقية التي تتدهور بصمت هي الفخ. وثقت مذكرات هاشيموتو نمطًا، وليس حدثًا واحدًا. إذا لم يكن لديك ميزانية خطأ لكل مكون يقرأها شخص ما صباح يوم الاثنين، فلن تتمكن من معرفة الاتجاه الذي تتحرك فيه أرقامك.
السؤال الثالث: هل تنشر ما يكفي لكي لا يحتاج المستخدمون إلى مذكرات؟
توجد المذكرات لأن المستخدمين لا يثقون في الإشارة العامة. يجب أن تكون صفحة الحالة الخاصة بك نشطة، لا باردة. إذا كانت هناك ميزة متدهورة، فضع علامة عليها. إذا كانت منطقة بطيئة، فضع علامة عليها. إذا كانت قائمة الانتظار الخلفية الخاصة بك متأخرة 30 دقيقة، فضع علامة عليها. المستخدمون الذين يمكنهم رؤية الحقيقة في الوقت الفعلي لا يبدأون في كتابة المذكرات.
السؤال الرابع: هل أنت موثوق به للعمل الجاد أم للعرض التوضيحي؟
وقت تشغيل بنسبة 99.95% يجمع كل وقت التوقف في ساعات عمل المطورين أسوأ من وقت تشغيل بنسبة 99.9% موزع بالتساوي. إذا كان عبء عملك عبارة عن جلسة مراجعة طلب سحب (PR) مدتها أربع ساعات، فإن ساعتين من أي انقطاع في أي وقت غير ذات صلة؛ ساعتان من الانقطاع خلال تلك الجلسة تعني الجلسة بأكملها. قم بقياس التوفر مقابل منحنى الاستخدام الحقيقي للعميل، وليس منحناك أنت.
الارتباط بالمنصة وتكلفة "دائمًا GitHub"
العبارة التي استخدمها هاشيموتو عن نفسه هي الاقتباس الأكثر قابلية للاستشهاد في المنشور: "لم يكن هناك شك بالنسبة لي أبدًا في المكان الذي سأضع فيه مشاريعي: دائمًا GitHub." هذه هي تكلفة العادة، وهي التكلفة التي لا يقدرها معظم المطورين بشكل صحيح.
عندما تكون منصة واحدة هي الافتراضية للمستودعات، والمشكلات، وطلبات السحب (PRs)، والتكامل المستمر (CI)، وتوزيع الحزم، والإصدارات، والهوية، فإن مساحة سطح "الارتباط بالمنصة" أكبر بكثير من مساحة سطح "تاريخ Git". يمكنك استنساخ مستودع Git إلى أي مكان؛ لا يمكنك استنساخ متتبع للمشكلات، أو سجل مراجعة طلب سحب (PR)، أو موضوع مناقشات، أو مخزن أسرار GitHub Actions، أو سير عمل المراجعة المرتبط بـ CODEOWNERS بأمر واحد. تكلفة الهجرة تأخذ شكل جبل جليدي.
تتضاعف هذه التكلفة بالنسبة لبناة الأدوات. إذا كانت أداة المطور الخاصة بك تعيش داخل GitHub Action، وتوزع من خلال Marketplace، وتصادق باستخدام GitHub OAuth، وتشحن الإصدارات عبر GitHub Packages، فإن موثوقية أداتك مشتقة من موثوقية GitHub. ميزانية أخطائك هي جزء من ميزانيتهم. يعاني عملاؤك من توقفك عندما يصلون إلى أداتك، لكنهم يعانون أيضًا من توقفك عندما يتعطل GitHub وتتوقف أداتك عن الاستجابة. لا يكون إسناد اللوم دقيقًا دائمًا؛ ولكن تجربة العميل هي كذلك.
عمل الفصل غير جذاب وهو العمل نفسه. اجعل كل تبعية قابلة للاستبدال. تعامل مع GitHub كمزود واحد من بين عدة مزودين، وليس كبنية تحتية. اختبر المسار البديل ربع سنويًا. قم بترحيل الأجزاء التي تناسب منصة تطوير مختلفة بشكل أفضل؛ واحتفظ بالأجزاء التي لا تناسب. عبارة هاشيموتو "الهجرة التدريجية" هي الشكل الصحيح للجميع، وليس له وحده.
بدائل منصة التطوير، باختصار
وجهات Ghostty المحتملة هي معلومات عامة من حيث الشكل وليس الاسم. الخيارات الموثوقة اعتبارًا من أواخر أبريل 2026:
- Forgejo. نسخة مفتوحة المصدر (Hard fork) من Gitea، مفتوحة المصدر بالكامل، تحتفظ بها منظمة Codeberg e.V. غير الربحية. الاتحاد عبر ActivityPub قيد التنفيذ وتم شحن جزء منه. الخيار الافتراضي للمشاريع المتوافقة مع FOSS.
- Codeberg. نسخة مستضافة من Forgejo تديرها منظمة غير ربحية. مجانية للمصدر المفتوح، لا يوجد ما يعادل Actions على نطاق GitHub بعد.
- GitLab. تكامل مستمر/نشر مستمر قوي (CI/CD)، تكافؤ كامل للميزات مع GitHub في معظم مسارات العمل، دعم تجاري. خيار مثير للجدل لجمهور FOSS نظرًا لخطوات الترخيص الأخيرة.
- Sourcehut. سير عمل يعتمد على البريد الإلكتروني، بسيط، سريع. جمهور متخصص، لكن الجمهور الذي يستخدمه يحبه. سياسات درو ديفولت هي ميزة أو عيب حسب أولوياتك.
- Forgejo أو Gitea المستضاف ذاتيًا على جهاز خام. أقصى قدر من التحكم، أقصى قدر من المسؤولية التشغيلية. خيار "الانتقال إلى الظلام".
- Radicle. نظير إلى نظير، لا يوجد مضيف مركزي. مبكر ولكن حجة الاتحاد هي الأقوى هنا. ربما مبكر جدًا لمشروع موجه للجمهور.
لم يلتزم هاشيموتو صراحةً بأي منها. الإشارة في هذا الصمت هي أن أيًا من الخيارات ليس بديلاً مباشرًا لكل ما يفعله GitHub، وهذا هو بيت القصيد: عندما تمتص منصة واحدة المكدس بأكمله، فإن استبداله بشكل نظيف أمر صعب بطبيعته.
الدرس لفرق API
إذا كنت تبني واجهات برمجة تطبيقات (APIs) أو أدوات API بدلاً من محاكيات الطرفية، فإن نفس النمط ينطبق مع تغيير الأسماء. استبدل "GitHub Actions" بـ "الـ API الأساسي الذي يعتمد عليه منتجك". استبدل "المشكلات وطلبات السحب (PRs)" بـ "صندوق الوارد حيث يخبرك عملاؤك بوجود خطأ ما". السؤال الهيكلي هو نفسه: كم يعتمد عمل عميلك على خدمة لا تتحكم فيها، وكيف تظل مفيدًا عندما تتعطل تلك الخدمة؟
ثلاثة أنماط تصمد أمام الاتصال بالواقع.
قم بمحاكاة كل ما تعتمد عليه. يجب أن يتمكن عملاؤك من الاستمرار في البناء عندما يكون الـ API الأساسي معطلاً. وهذا يعني أن مجموعة الاختبار، وحلقة التطوير المحلية، وخط أنابيب التكامل المستمر (CI) كلها تحتاج إلى خادم وهمي (mock server) يعيد استجابات واقعية بدون استدعاء شبكة. يقدم Apidog هذا كميزة أساسية؛ نفس تعريفات البيانات التي تستخدمها لاختبار الـ API الحي تولد الوهمية (mock). النمط بسيط وتكلفته تُدفع مرة واحدة. انظر المقارنة مع نظام OpenAI البيئي في كيفية استخدام GPT-5.5 API لما تبدو عليه قصة المحاكاة متعددة المزودين في الممارسة.
اختبر مقابل مزودين متعددين. OpenAI، Anthropic، Mistral، DeepSeek، Google، وxAI جميعها تكشف عن نقاط نهاية لإكمال الدردشة بأشكال متداخلة. إذا كان منتجك يغلف أيًا منها، فإن الفرق بين "نحن معطلون لأن OpenAI معطل" و "لقد وجهنا بشفافية إلى مزود احتياطي" هو يومان من عمل التكامل. قم بتشغيل مجموعة الاختبار الخاصة بك مقابل كل مزود تدعمه، وليس فقط الأساسي. متغيرات بيئة Apidog تجعل التبديل تغييرًا في سطر واحد من التكوين.
افصل خط أنابيب الإصدار الخاص بك عن منصة الاستضافة الخاصة بك. إذا كان CI الخاص بك يعتمد بالكامل على GitHub Actions وتعرض GitHub Actions لعطل بعد الظهر، فلن يتم الإصدار الخاص بك. عكس CI إلى مشغل ثانٍ، أو الاستضافة الذاتية للمسارات الحرجة على الأقل، يزيل نقطة الفشل الواحدة. التكلفة حقيقية؛ البديل هو عدم القدرة على الشحن بينما تتغير ألوان صفحة حالة المزود الأساسي الخاص بك.
كيف يبدو سير عمل بأسلوب Apidog لعمل API المرن
بشكل ملموس، هذا هو النمط الذي تستخدمه معظم الفرق لعزل نفسها عن انقطاعات المزودين الأساسيين.
- قم بتنزيل Apidog وأنشئ مشروعًا واحدًا لكل واجهة API أساسية تعتمد عليها.
- حدد مخططات الطلب والاستجابة مرة واحدة. يولد Apidog خادمًا وهميًا من المخطط بحيث لا تتوقف حلقة التطوير أبدًا بسبب الخدمة الأساسية.
- قم بتخزين بيانات الاعتماد كأسرار ذات نطاق بيئي. يتم تشغيل نفس شكل الطلب مقابل
dev(وهمي)، وstaging(بيئة تجريبية)، وprod(مباشر) عن طريق تبديل البيئة. - اكتب اختبارات التعاقد التي تعمل مع كل إصدار؛ يتم تشغيل نفس الاختبارات مقابل كل مزود تدعمه، بحيث يظهر التراجع في المزود A قبل أن يراه العملاء.
- عندما يكون الـ API الأساسي متدهورًا، قم بتبديل البيئة إلى وضع الوهمية واستمر في العمل. لا يزال المنتج يشحن حتى لو لم يكن الـ API الأساسي.
هذا النمط ليس خاصًا بـ Ghostty أو بالذكاء الاصطناعي؛ إنه نمط API المرن الذي أتى بثماره لكل فريق اعتمده قبل أن يحتاج إليه. منشور هاشيموتو هو أحدث تذكير بأنك تعتمده قبل أن تحتاج إليه، وليس بعده.
ماذا يقرأ المطورون من الإعلان
ردود الفعل في أول 48 ساعة تقع في عدة فئات.
معسكر "خير له". مستخدمو GitHub الأقوياء القدامى الذين كانوا محبطين بصمت لأشهر ورأوا المنشور بمثابة إذن بنشر شكواهم الخاصة. العديد منهم قاموا بالفعل بمطابقة لـ forge ثانٍ؛ وقد دفعهم المنشور إلى جعل النسخة المطابقة هي الأساسية.
المتشككون في "هذا انقطاع واحد". يشير الأشخاص إلى أن وقت تشغيل GitHub العام منافس للمعايير الصناعية وأن أي منصة كبيرة تمر بأيام سيئة. إنهم ليسوا مخطئين في الرقم الكلي، لكنهم يفوتون نقطة المشتق الثاني: الاتجاه، وليس العدد المطلق، هو ما دفع هاشيموتو.
البراغماتيون "مغادرة المنصة صعبة، أراك بعد ستة أشهر". المهندسون الذين أجروا ترحيل forge ويعرفون أن متتبع المشكلات، وسجل طلبات السحب (PR)، ومساحة سطح CI هي حيث تكمن تكلفة الترحيل. إنهم على حق، وخطة هاشيموتو "التدريجية، مع مرآة للقراءة فقط" هي الشكل الصحيح لهذا القيد.
القلقون بشأن "ماذا عن مستودعاتي". القائمون على الصيانة الصغار يتساءلون عما إذا كانت مشاريعهم معرضة لنفس المخاطر. الإجابة هي نعم من حيث الشكل، لا من حيث الحجم؛ انقطاع قد يكلف هاشيموتو يوم عمل مدفوع الأجر في HashiCorp هو إزعاج بسيط لمشروع عطلة نهاية الأسبوع. حسابات الهجرة الخاصة بك مختلفة.
ردود الفعل المهمة ليست على وسائل التواصل الاجتماعي. إنها داخل المنظمات الهندسية التي اختارت GitHub كقاعدة لكل ما يشحنونه. المحادثات تدور على Slack الآن: كيف نقلل من المخاطر، كيف تبدو سياستنا الداخلية بشأن مطابقة forge الثانية، وما هي خطة الخروج؟
الدروس العملية لمكدسك الخاص
قائمة تحقق موجزة ومحددة:
- اعكس مستودعاتك النشطة إلى منصة تطوير ثانية أسبوعيًا. Forgejo و Codeberg مجانيان للمصدر المفتوح. التكلفة هي وظيفة CI واحدة؛ القيمة هي النوم الهادئ خلال الانقطاع التالي لمدة أربع ساعات.
- ثبّت التبعية. إذا كنت تشحن أداة للمطورين تستدعي واجهات برمجة تطبيقات GitHub، فتعامل مع عميل GitHub كمحول قابل للتبديل، وليس استيرادًا صارمًا. أضف محول Forgejo أو GitLab خلف نفس الواجهة.
- وثّق الحل البديل اليدوي. عندما لا يمكن تشغيل مسار الإصدار التلقائي، ما هو المسار اليدوي؟ إذا لم يكن موثقًا، فإن الإجابة هي "لا يمكننا الإصدار"، وهذه الإجابة غير مقبولة لأي أداة لديها عملاء يدفعون.
- راجع ما تعتمد عليه. قم بإدراج كل خدمة خارجية في المسار الحرج. لكل منها، اكتب الإجابة على "ماذا نفعل إذا كانت هذه الخدمة معطلة لمدة أربع ساعات؟" وقم بإظهار الثغرات للقيادة.
- راقب المشتق الثاني. إذا كان تكرار الحوادث يتزايد شهرًا بعد شهر حتى في خدمة لا تزال تلبي اتفاقية مستوى الخدمة الخاصة بها، فخطط للهجرة قبل أن تفرض عليك.
للحصول على مثال عملي خاص بأدوات API، يشرح المنشور حول بناء مسارات عمل متينة تصمد أمام انقطاعات المزودين نفس النمط مع الكود، باستخدام DeepSeek و OpenAI كمثال لمزودين مزدوجين. تتغير الأشكال؛ المبدأ لا يتغير.
الأسئلة الشائعة
إلى أين ينتقل Ghostty؟لم يلتزم هاشيموتو بوجهة في منشور الإعلان. قال إن المناقشات مستمرة مع مزودين متعددين، تجاريين ومفتوحي المصدر، وأن الهجرة ستكون تدريجية، وليست تبديلًا واحدًا. سيظل مستودع Ghostty GitHub الحالي كنسخة مطابقة للقراءة فقط حتى تستمر النسخ الحالية والروابط والمراجع في العمل.
هل GitHub غير موثوق به إلى هذا الحد؟أرقام وقت تشغيل GitHub الرئيسية تنافسية مع منصات مماثلة، ولكن المنصة شهدت عدة انقطاعات ممتدة في عامي 2025 و 2026 أثرت على Actions، و Packages، وواجهة API. شكوى هاشيموتو هي أن نمط الانقطاعات الجزئية، حتى عندما يكون كل منها قصيرًا، يتراكم إلى ساعات عمل ضائعة متعددة أسبوعيًا للمستخدمين على المسار الحرج.
هل يجب أن أنقل مستودعاتي من GitHub الآن؟المطابقة (Mirroring) تستحق العناء بالتأكيد. وظيفة CI أسبوعية تدفع إلى منصة تطوير ثانية لا تكلف شيئًا تقريبًا وتمنحك نسخة احتياطية عاملة في المرة القادمة التي يتعطل فيها GitHub Actions لبضع ساعات. ما إذا كنت ستجعل المنصة الثانية هي الأساسية يعتمد على مدى تحملك لتكلفة الهجرة على المشكلات، وسجل طلبات السحب (PR)، وتكوين CI؛ بالنسبة لمعظم الفرق، لم تبرر فجوة الموثوقية هذه التكلفة بعد.
هل يؤثر هذا على استخدامي لـ GitHub Copilot أو GitHub Actions؟لم يذكر منشور هاشيموتو أيًا من المنتجين على وجه التحديد، على الرغم من أن انقطاع Actions في يوم المنشور كان المحفز المباشر. Copilot هو سطح منتج منفصل عن المنصة؛ يتم تتبع موثوقيته بشكل منفصل. إذا كان فريقك يستخدم GitHub Copilot، فإن تغييرات الفوترة ذات الصلة موثقة في استخدام GitHub Copilot وواجهة برمجة تطبيقات الفوترة للفرق.
ماذا يعني هذا لأدوات المطورين في عصر الذكاء الاصطناعي التي تعتمد على واجهات برمجة تطبيقات GitHub؟الأدوات التي تغلف واجهة برمجة تطبيقات GitHub (روبوتات المراجعة، فرز المشكلات، خوادم MCP) ترث ملف موثوقية GitHub بحكم تصميمها. الحل هو نفسه لأي تبعية خارجية: التخزين المؤقت بشكل مكثف، الفشل المفتوح (fail open)، ومحاكاة الواجهة الأساسية في مجموعة الاختبار الخاصة بك. نمط خادم Apidog الوهمي هو طريقة رخيصة للقيام بذلك؛ يغطي تقرير روبوت الفرز Clawsweeper مثالًا عمليًا.
هل هذا اتجاه "مغادرة GitHub" أم حدث لمرة واحدة؟ربما بداية لاتجاه، ولكنه بطيء. ترحيل أي مشروع غير تافه من GitHub هو مشروع يستغرق عدة أسابيع؛ قليل من الفرق تفعل ذلك من أجل المتعة. الإشارة في منشور هاشيموتو هي أن المقايضة قد تغيرت بما يكفي لدرجة أن أحد أقدم مستخدمي المنصة قرر أن تكلفة الهجرة تستحق الدفع. من المرجح أن تحذو مشاريع أخرى رفيعة المستوى حذوها خلال الـ 12 شهرًا القادمة.
ماذا يعني مصطلح "باني أدوات المطورين" في هذا السياق؟أي شخص يشحن برمجيات يستخدمها مطورون آخرون كجزء من سير عملهم اليومي. يشمل ذلك الحالات الواضحة مثل الطرفيات، والمحررات، ومشغلات CI؛ ويشمل أيضًا عملاء API، وأدوات المراقبة، وسجلات الحزم، ومساعدي ترميز الذكاء الاصطناعي. إذا كان عميلك مطورًا وأداتك تقف بينهم وبين الشحن، فأنت باني أدوات للمطورين، ودروس الموثوقية من منشور هاشيموتو تنطبق مباشرة.