جاستي يغادر GitHub: ماذا يعني لبُناة أدوات المطورين

في 28 أبريل 2026، أعلن ميتشل هاشيموتو أن Ghostty، محاكي الطرفية مفتوح المصدر الخاص به، سيغادر GitHub. هاشيموتو مستخدم GitHub رقم 1299، انضم في فبراير 2008، واستخدم المنصة شبه يوميًا لأكثر من 18 عامًا. لكن في يوم الإعلان كان قد بدأ بالفعل بتوثيق ملاحظات من نوع: "كل يوم تقريبًا به تعطيل X". وفي نفس اليوم، عطّل فشل في GitHub Actions مراجعات طلبات السحب الخاصة به لمدة ساعتين. كان حكمه مباشرًا: "لم يعد هذا مكانًا للعمل الجاد إذا كان يعيقك لساعات في اليوم، كل يوم."

جرّب Apidog اليوم

إذا كنت تبني أدوات للمطورين، فاقرأ هذا الإعلان كاختبار ضغط لمكدسك. هاشيموتو ليس مستخدمًا عاديًا؛ فقد شارك في تأسيس HashiCorp على GitHub، وأطلق عبره Terraform وVagrant وVault وConsul وBoundary. عندما يترك مستخدم بهذا التاريخ منصة المطورين المهيمنة بسبب الموثوقية، فالموضوع لا يتعلق فقط بمحاكي طرفية يبحث عن منزل جديد. إنه تنبيه حول الاعتمادية، والارتباط بالمنصة، وتكلفة بناء أداة يعتمد عليها مطورون آخرون يوميًا.

للسياق الأوسع حول كيف تغيّر أدوات المطورين في عصر الذكاء الاصطناعي سير عمل GitHub، راجع كيفية كتابة ملفات AGENTS.md واستخدام GitHub Copilot وفاتورة API للفرق. ولرؤية مثال على الأتمتة حول فجوات موثوقية GitHub، راجع تقرير روبوت الفرز Clawsweeper.

باختصار

• أعلن ميتشل هاشيموتو في 28 أبريل 2026 أن Ghostty سيغادر GitHub إلى منصة تطوير لم تُسمَّ بعد.
• السبب المعلن: انقطاعات مزمنة في GitHub Actions والمنصة، وثّقها في مذكراته الشخصية على أنها "كل يوم تقريبًا به تعطيل X".
• في يوم الإعلان، منع انقطاع في Actions مراجعات طلبات السحب لمدة ساعتين.
• سيبقى مستودع Ghostty على GitHub كنسخة مطابقة للقراءة فقط، بينما ينتقل التطوير النشط تدريجيًا.
• مشاريعه الأخرى ستبقى على GitHub في الوقت الحالي.
• الدرس لبناة أدوات المطورين: عندما تصبح أداتك جزءًا من المسار الحرج، تصبح الموثوقية أهم من الميزات.
• بالنسبة لفرق API، الحل العملي هو الفصل: عملاء مستقلون عن المزودين، خوادم وهمية أثناء الانقطاعات، ومسارات ترحيل يتم اختبارها قبل الحاجة إليها. Apidog مبني حول هذا النمط.

ما قاله هاشيموتو في المنشور

منشور الإعلان قصير ومباشر. لا توجد حملة ضد Microsoft، ولا ترويج لمنصة بديلة، ولا بيان طويل. الفكرة الأساسية:

1. بدأ بتوثيق انقطاعات GitHub.
2. امتلأت المذكرات أسرع مما توقع.
3. في صباح يوم الإعلان، عطّل فشل في GitHub Actions مراجعة طلبات السحب لمدة ساعتين.
4. خلص إلى أن GitHub لم يعد موثوقًا بما يكفي للعمل اليومي على Ghostty.

الأهم أن القرار لم يكن رد فعل على حادث واحد. انقطاع 27 أبريل 2026 أثّر في التوقيت، لكنه لم يصنع القرار. هاشيموتو كان يتتبع النمط منذ أشهر.

الحدود واضحة أيضًا:

• Ghostty فقط هو الذي سيغادر الآن.
• بقية مشاريعه ستبقى على GitHub في الوقت الحالي.
• مستودع Ghostty سيبقى كنسخة قراءة فقط.
• المشكلات، وطلبات السحب، وCI ستنتقل إلى منصة تطوير جديدة.
• الهجرة ستكون تدريجية، لا تبديلًا مفاجئًا.

الشكوى ليست من التسعير أو الميزات أو اتجاه المنتج. الشكوى هي أن الأداة لا تعمل بثبات عندما يحتاجها المستخدم.

لماذا زاوية الموثوقية أهم من الهجرة

السؤال المهم ليس: "إلى أين سينتقل Ghostty؟"

السؤال الأهم: "كيف وصلت منصة بحجم GitHub إلى نقطة يقرر فيها مستخدم قديم مثل هاشيموتو المغادرة بسبب الموثوقية؟"

هذا الإعلان مختلف لثلاثة أسباب.

1. المستخدم

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

2. السبب

لم يغادر بسبب Copilot، أو Microsoft، أو تدريب الذكاء الاصطناعي، أو التسعير. غادر لأن الخدمة كانت تتعطل بطريقة تؤثر على العمل اليومي.

هذا يحوّل النقاش إلى سؤال واحد:

هل تعمل الأداة عندما يحتاجها المطور؟

3. اللهجة

المنشور هادئ. لا يوجد غضب أو دراما. يبدو كتقرير ما بعد حادث كتبه شخص حاول البقاء طويلًا ثم نفد رصيده من الثقة.

وهذا أسوأ سيناريو لأي أداة مطورين: مستخدم قديم، لا خلاف علني، فقط تراكم هادئ لأيام "الأداة لم تعمل اليوم".

اختبار ضغط سريع لأداتك

إذا كانت أداتك تقع في المسار الحرج للمطورين، نفّذ هذا التقييم داخليًا.

1. احسب ساعات التعطيل الفعلية

لا تعتمد فقط على صفحة الحالة. اجمع:

• حوادث صفحة الحالة خلال آخر 90 يومًا.
• الأعطال الجزئية التي يعرفها الفريق ولم تُنشر.
• فترات البطء التي أثّرت على المستخدمين.
• أوقات الذروة لدى أهم العملاء.

ثم اسأل:

كم ساعة عمل خسرها المستخدمون بسببنا؟

إذا كان مستخدم كثيف يخسر أكثر من صفر ساعة أسبوعيًا بسببك، فأنت تقترب من نفس المشكلة.

2. راقب الاتجاه، لا الرقم فقط

وقت التشغيل العام قد يبدو جيدًا، لكن عدد الحوادث قد يكون في ازدياد.

مثال عملي:

يناير: 2 حوادث جزئية
فبراير: 4 حوادث جزئية
مارس: 7 حوادث جزئية
أبريل: 9 حوادث جزئية

حتى لو بقيت ضمن SLA، فالمنحنى سيئ. هذا هو "المشتق الثاني" للموثوقية: هل تتحسن أم تتدهور؟

3. انشر الحقيقة قبل أن يكتبها المستخدمون

المستخدمون يبدؤون بتوثيق الأعطال بأنفسهم عندما لا يثقون في إشارتك الرسمية.

اجعل صفحة الحالة عملية:

• ميزة متدهورة؟ اذكرها.
• منطقة بطيئة؟ اذكرها.
• قائمة CI متأخرة 30 دقيقة؟ اذكرها.
• API يعمل لكن بزمن استجابة مرتفع؟ اذكره.

صفحة حالة صادقة تقلل الحاجة إلى "مذكرات أعطال" خاصة لدى المستخدمين.

4. قِس التوفر مقابل وقت استخدام العميل

وقت تشغيل 99.95% لا يعني الكثير إذا تركز الانقطاع داخل ساعات عمل المطورين.

مثال:

الانقطاع A: ساعتان يوم الأحد 03:00
الانقطاع B: ساعتان الثلاثاء 10:00 أثناء مراجعات PR

الرقم نفسه، لكن الأثر مختلف تمامًا.

قِس التوفر مقابل منحنى الاستخدام الحقيقي، لا مقابل متوسطاتك الداخلية فقط.

الارتباط بالمنصة وتكلفة "دائمًا GitHub"

كتب هاشيموتو أن GitHub كان دائمًا المكان الافتراضي لمشاريعه. وهذه هي المشكلة: العادة تتحول إلى اعتماد بنيوي.

Git نفسه قابل للنقل بسهولة:

git remote add mirror git@example.com:org/repo.git
git push --mirror mirror

لكن ما لا ينتقل بسهولة:

• سجل المشكلات.
• مراجعات طلبات السحب.
• تعليقات التصميم.
• GitHub Actions.
• أسرار CI.
• CODEOWNERS.
• GitHub Packages.
• OAuth.
• Marketplace.
• سياسات الحماية على الفروع.

إذا كانت أداتك تعتمد على GitHub Action، وتوزّع عبر Marketplace، وتصادق عبر GitHub OAuth، وتنشر عبر GitHub Packages، فموثوقية أداتك مشتقة من موثوقية GitHub.

هذا لا يعني أن GitHub خيار سيئ. يعني فقط أنه يجب التعامل معه كمزود، لا كبنية تحتية لا يمكن استبدالها.

نمط عملي: اجعل GitHub مزودًا قابلًا للاستبدال

إذا كانت أداتك تتعامل مع GitHub API، لا تكتب المنطق مباشرة حول عميل GitHub الرسمي فقط. استخدم واجهة داخلية.

مثال TypeScript مبسط:

export interface ForgeClient {
  listPullRequests(repo: string): Promise<PullRequest[]>;
  getIssue(repo: string, id: number): Promise<Issue>;
  createComment(repo: string, issueId: number, body: string): Promise<void>;
}

ثم اجعل GitHub مجرد تطبيق واحد:

export class GitHubClient implements ForgeClient {
  async listPullRequests(repo: string) {
    // GitHub API call
  }

  async getIssue(repo: string, id: number) {
    // GitHub API call
  }

  async createComment(repo: string, issueId: number, body: string) {
    // GitHub API call
  }
}

لاحقًا يمكنك إضافة GitLab أو Forgejo خلف نفس الواجهة:

export class GitLabClient implements ForgeClient {
  async listPullRequests(repo: string) {
    // GitLab merge requests API call
  }

  async getIssue(repo: string, id: number) {
    // GitLab issue API call
  }

  async createComment(repo: string, issueId: number, body: string) {
    // GitLab comment API call
  }
}

الفكرة ليست دعم كل المنصات من اليوم الأول. الفكرة أن لا تجعل GitHub متغلغلًا في كل طبقة من المنتج.

بدائل منصات التطوير، باختصار

لم يعلن هاشيموتو وجهة Ghostty بعد. الخيارات المعقولة في هذا النوع من الهجرة تشمل:

• Forgejo: تفرع مفتوح المصدر من Gitea، تديره منظمة Codeberg e.V. غير الربحية. مناسب للمشاريع التي تعطي أولوية للبرمجيات الحرة.
• Codeberg: استضافة مبنية على Forgejo وتديرها منظمة غير ربحية. جيدة للمصدر المفتوح، لكنها لا تملك مكافئًا كاملًا لـ GitHub Actions على نفس النطاق.
• GitLab: CI/CD قوي، ميزات واسعة، ودعم تجاري. قد يكون مثيرًا للجدل داخل بعض مجتمعات FOSS بسبب قرارات الترخيص.
• Sourcehut: سير عمل يعتمد على البريد الإلكتروني، بسيط وسريع، لكنه يستهدف جمهورًا أكثر تخصصًا.
• Forgejo أو Gitea ذاتي الاستضافة: أقصى تحكم مقابل أعلى عبء تشغيلي.
• Radicle: نموذج نظير إلى نظير بدون مضيف مركزي. واعد، لكنه قد يكون مبكرًا لمشروع عام كبير.

عدم وجود بديل مباشر لكل ما يفعله GitHub هو جوهر المشكلة. عندما تمتص منصة واحدة المستودعات، والمشكلات، وCI، والحزم، والهوية، تصبح الهجرة مشروعًا حقيقيًا.

الدرس لفرق API

إذا كنت تبني واجهات API أو أدوات API، فاستبدل أسماء المكونات فقط:

• بدل "GitHub Actions"، فكر في "API الأساسي الذي يعتمد عليه منتجك".
• بدل "المشكلات وطلبات السحب"، فكر في "قنوات دعم العملاء والتنبيهات".
• بدل "منصة التطوير"، فكر في "مزود البنية التحتية أو نموذج الذكاء الاصطناعي أو بوابة الدفع".

السؤال نفسه:

كيف تظل أداتك مفيدة عندما تتعطل خدمة لا تتحكم فيها؟

1. حاكِ كل API تعتمد عليه

يجب أن يستمر المطورون في العمل حتى لو كان API الأساسي معطلًا.

هذا يعني أن لديك:

• خادمًا وهميًا للاستجابات.
• بيانات اختبار واقعية.
• اختبارات عقد لا تحتاج إلى الشبكة دائمًا.
• بيئة محلية لا تتوقف بسبب مزود خارجي.

مثال بسيط لاستجابة وهمية:

{
  "id": "chatcmpl_mock_001",
  "status": "completed",
  "model": "mock-model",
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "هذه استجابة وهمية للاختبار المحلي."
      }
    }
  ]
}

في Apidog، يمكن استخدام نفس تعريفات الطلب والاستجابة لتوليد خادم وهمي، بحيث لا تتوقف حلقة التطوير المحلية عند تعطل المزود الأساسي. راجع مثالًا قريبًا في كيفية استخدام GPT-5.5 API.

2. اختبر ضد أكثر من مزود

إذا كان منتجك يغلف مزودات مثل OpenAI أو Anthropic أو Mistral أو DeepSeek أو Google أو xAI، لا تجعل الاختبارات مرتبطة بمزود واحد.

استخدم متغيرات بيئة واضحة:

API_PROVIDER=openai
API_BASE_URL=https://api.openai.com/v1
API_KEY=...

ثم بدّل المزود دون تغيير الكود الأساسي:

API_PROVIDER=backup
API_BASE_URL=https://api.backup-provider.example/v1
API_KEY=...

في الكود، اجعل التوجيه قائمًا على التكوين:

const baseUrl = process.env.API_BASE_URL;
const apiKey = process.env.API_KEY;

export async function sendRequest(payload: unknown) {
  const res = await fetch(`${baseUrl}/chat/completions`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${apiKey}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(payload)
  });

  if (!res.ok) {
    throw new Error(`Provider request failed: ${res.status}`);
  }

  return res.json();
}

الهدف: عندما يتعطل المزود الأساسي، يكون التحويل إلى مزود احتياطي إجراءً معروفًا، لا مشروعًا طارئًا.

3. افصل الإصدار عن منصة الاستضافة

إذا كان مسار الإصدار يعتمد بالكامل على GitHub Actions، فتعطل Actions يعني أنك لا تستطيع الإصدار.

على الأقل، وثّق مسارًا بديلًا:

npm ci
npm test
npm run build
npm publish

أو شغّل CI ثانويًا في منصة أخرى للمسارات الحرجة.

مثال لفكرة النسخ المطابق الأسبوعي:

name: Mirror repository

on:
  schedule:
    - cron: "0 3 * * 1"
  workflow_dispatch:

jobs:
  mirror:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout full history
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Push mirror
        run: |
          git remote add mirror "$MIRROR_URL"
          git push --mirror mirror
        env:
          MIRROR_URL: ${{ secrets.MIRROR_URL }}

حتى لو كانت هذه الوظيفة تعمل على GitHub Actions، فهي تمنحك نسخة خارجية محدثة. وللمسارات الأهم، شغّل النسخ من نظام CI مستقل أيضًا.

كيف يبدو سير عمل بأسلوب Apidog لعمل API مرن

النمط العملي:

1. قم بتنزيل Apidog وأنشئ مشروعًا لكل API أساسي تعتمد عليه.
2. عرّف مخططات الطلب والاستجابة مرة واحدة.
3. استخدم الخادم الوهمي لتشغيل التطوير المحلي حتى عند تعطل المزود الأساسي.
4. خزّن بيانات الاعتماد كأسرار حسب البيئة.
5. شغّل نفس الطلبات ضد:
   • dev للخادم الوهمي.
   • staging للبيئة التجريبية.
   • prod للمزود الحي.
6. اكتب اختبارات عقد تعمل مع كل إصدار.
7. عند تدهور API الأساسي، بدّل البيئة إلى الوضع الوهمي أو مزود احتياطي واستمر في التطوير.

مثال بيئات:

dev:
  base_url = https://mock.example.local

staging:
  base_url = https://staging-api.example.com

prod:
  base_url = https://api.example.com

هذا النمط ليس خاصًا بـ Ghostty أو الذكاء الاصطناعي. إنه نمط عام لأي فريق يعتمد على خدمات خارجية ويريد تقليل أثر الانقطاعات.

ماذا يقرأ المطورون من الإعلان

ردود الفعل يمكن تلخيصها في أربع فئات.

"خير له"

مستخدمون قدامى كانوا محبطين بصمت من GitHub ورأوا المنشور كإذن للتحدث أو البدء في النقل.

"هذا مجرد انقطاع واحد"

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

"الهجرة صعبة"

وهذا صحيح. نقل المستودع سهل، لكن نقل المشكلات، وPRs، وCI، والصلاحيات، وسجل المراجعات صعب. لذلك اختار هاشيموتو هجرة تدريجية مع نسخة قراءة فقط على GitHub.

"ماذا عن مستودعاتي؟"

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

لكن النسخ المطابق يستحق التنفيذ في كل الحالات تقريبًا.

قائمة تحقق عملية لمكدسك

نفّذ هذه الخطوات قبل الانقطاع التالي:

• [ ] اعكس المستودعات النشطة إلى منصة ثانية أسبوعيًا.
• [ ] احتفظ بنسخة خارجية من إعدادات CI الحرجة.
• [ ] وثّق مسار إصدار يدوي.
• [ ] اجعل عملاء GitHub أو GitLab أو Forgejo خلف واجهة داخلية.
• [ ] لا تخلط منطق المنتج مباشرة مع API مزود واحد.
• [ ] أنشئ خوادم وهمية لكل API خارجي تعتمد عليه.
• [ ] اختبر ضد مزود احتياطي إن وجد.
• [ ] راقب تكرار الحوادث، لا وقت التشغيل فقط.
• [ ] اربط قياسات التوفر بساعات استخدام العملاء.
• [ ] اكتب خطة: "ماذا نفعل إذا تعطلت هذه الخدمة 4 ساعات؟"

مثال لتوثيق اعتماد خارجي:

## Dependency: GitHub Actions

Impact if down:
- لا يمكن تشغيل CI.
- لا يمكن نشر إصدار تلقائي.
- تتأخر مراجعات PR.

Fallback:
- تشغيل الاختبارات محليًا.
- استخدام CI ثانوي للمسارات الحرجة.
- إصدار يدوي عبر npm publish بعد موافقة Maintainer.

Drill frequency:
- مرة كل ربع سنة.

للحصول على مثال عملي خاص بأدوات API، يشرح منشور بناء مسارات عمل متينة تصمد أمام انقطاعات المزودين نفس النمط باستخدام DeepSeek وOpenAI كمثال لمزودين مزدوجين.

الأسئلة الشائعة

إلى أين ينتقل Ghostty؟

لم يلتزم هاشيموتو بوجهة في منشور الإعلان. قال إن المحادثات مستمرة مع مزودين متعددين، تجاريين ومفتوحي المصدر، وإن الهجرة ستكون تدريجية. سيظل مستودع Ghostty الحالي على GitHub كنسخة قراءة فقط حتى تستمر الروابط والمراجع الحالية في العمل.

هل GitHub غير موثوق إلى هذا الحد؟

أرقام وقت تشغيل GitHub العامة ما زالت منافسة لمنصات مماثلة. لكن المنصة شهدت عدة انقطاعات ممتدة في 2025 و2026 أثرت على Actions وPackages وAPI. شكوى هاشيموتو هي أن الانقطاعات الجزئية المتكررة، حتى لو كانت قصيرة منفردة، تتراكم إلى ساعات عمل ضائعة للمستخدمين على المسار الحرج.

هل يجب أن أنقل مستودعاتي من GitHub الآن؟

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

هل يؤثر هذا على GitHub Copilot أو GitHub Actions؟

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

ماذا يعني هذا لأدوات المطورين في عصر الذكاء الاصطناعي التي تعتمد على GitHub API؟

الأدوات التي تغلف GitHub API، مثل روبوتات المراجعة وفرز المشكلات وخوادم MCP، ترث جزءًا من ملف موثوقية GitHub. الحل العملي: التخزين المؤقت، الفشل المفتوح عند الإمكان، ومحاكاة الواجهة الأساسية في الاختبارات. يغطي تقرير روبوت الفرز Clawsweeper مثالًا عمليًا.

هل هذه بداية اتجاه "مغادرة GitHub"؟

ربما، لكنه سيكون بطيئًا. ترحيل مشروع غير بسيط من GitHub يستغرق أسابيع أو أشهر، وليس قرارًا عابرًا. الإشارة المهمة في منشور هاشيموتو أن تكلفة البقاء، بالنسبة له، أصبحت أعلى من تكلفة الهجرة.

من هو "باني أدوات المطورين" هنا؟

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