Ghostty ออกจาก GitHub: ผลกระทบต่อผู้สร้างเครื่องมือสำหรับนักพัฒนา

เมื่อวันที่ 28 เมษายน 2026 มิตเชล ฮาชิโมโตะประกาศว่า Ghostty อีมูเลเตอร์เทอร์มินัลโอเพนซอร์สของเขา กำลังจะย้ายออกจาก GitHub หลังจากใช้งานแพลตฟอร์มนี้มาตั้งแต่ปี 2008 ในฐานะผู้ใช้ GitHub ลำดับที่ 1299 เหตุผลหลักไม่ใช่ฟีเจอร์หรือราคา แต่เป็นความน่าเชื่อถือ: เขาบันทึกเหตุการณ์ระบบล่ม “เกือบทุกวัน” และในวันประกาศ GitHub Actions ล่มจนเขาตรวจสอบ PR ไม่ได้ราวสองชั่วโมง

ลองใช้ Apidog วันนี้

หากคุณสร้างเครื่องมือสำหรับนักพัฒนา เหตุการณ์นี้ควรถูกอ่านเป็นกรณีศึกษา ไม่ใช่ข่าวแพลตฟอร์มทั่วไป ฮาชิโมโตะเคยใช้ GitHub เพื่อจัดส่ง Terraform, Vagrant, Vault, Consul และ Boundary ผ่าน HashiCorp มาก่อน เมื่อผู้ใช้ระดับนี้ตัดสินใจย้ายออกเพราะ “ทำงานจริงจังไม่ได้” ประเด็นสำคัญคือความน่าเชื่อถือ การผูกขาด และการออกแบบระบบให้ไม่พังตามผู้ให้บริการรายเดียว

สำหรับบริบทเพิ่มเติมเกี่ยวกับเวิร์กโฟลว์นักพัฒนาในยุค AI ที่ผูกกับ GitHub อ่านต่อได้ที่ วิธีการเขียนไฟล์ AGENTS.md, การใช้งานและ API การเรียกเก็บเงินของ GitHub Copilot สำหรับทีม และ บทความเกี่ยวกับบอทคัดแยก Clawsweeper

สรุป TL;DR

• มิตเชล ฮาชิโมโตะประกาศเมื่อวันที่ 28 เมษายน 2026 ว่า Ghostty จะย้ายการพัฒนาหลักออกจาก GitHub
• เหตุผลหลักคือ GitHub Actions และส่วนอื่นของแพลตฟอร์มล่มบ่อยจนกระทบงานประจำวัน
• Ghostty repository บน GitHub จะยังอยู่แบบอ่านอย่างเดียว ส่วน issues, PRs และ CI จะค่อย ๆ ย้ายไปแพลตฟอร์มใหม่
• ประเด็นไม่ใช่แค่ Ghostty จะย้ายไปไหน แต่คือผู้ใช้ GitHub รุ่นแรก ๆ ย้ายออกเพราะความน่าเชื่อถือ
• สำหรับทีมที่สร้าง dev tools บทเรียนคือ: ถ้าเครื่องมือของคุณอยู่ใน critical path ความเสถียรสำคัญกว่าฟีเจอร์ใหม่
• สำหรับทีม API ให้ลดการพึ่งพาผู้ให้บริการรายเดียวด้วย mock server, contract tests, provider adapters และแผน fallback ที่ซ้อมไว้ล่วงหน้า
• Apidog เป็นตัวอย่างเครื่องมือที่ช่วยแยก API workflow ออกจาก upstream service ผ่าน schema, mock และ testing workflow

สิ่งที่ฮาชิโมโตะกล่าวในโพสต์

โพสต์ประกาศ สั้นและตรงไปตรงมา เขาไม่ได้โจมตี Microsoft ไม่ได้ประกาศแพลตฟอร์มปลายทาง และไม่ได้พูดเรื่องราคา เขาเล่าว่าเริ่มจดบันทึกเหตุการณ์ GitHub ล่ม แล้วพบว่าบันทึกเต็มเร็วกว่าที่คาดไว้ เพราะมีปัญหา “เกือบทุกวัน”

วันที่เขาเขียนโพสต์ GitHub Actions มีปัญหาราวสองชั่วโมง ทำให้เขาตรวจสอบ PR ไม่ได้ นั่นเป็นจุดที่ทำให้เขาสรุปว่า GitHub ไม่เหมาะกับงานจริงจังของ Ghostty อีกต่อไป

ข้อมูลที่ต้องแยกให้ชัด:

• วันที่ 27 เมษายน 2026 GitHub มีเหตุการณ์ล่มใหญ่ กระทบ Actions, Packages และ API
• สมุดบันทึกของฮาชิโมโตะเริ่มก่อนเหตุการณ์นั้น แปลว่าเขาเห็น pattern มาหลายเดือน
• การล่มครั้งนั้นเป็นตัวเร่ง ไม่ใช่เหตุผลเดียว
• Ghostty จะย้ายแบบค่อยเป็นค่อยไป ไม่ใช่ cutover ครั้งเดียว
• repository เดิมที่ ghostty-org/ghostty จะคงอยู่แบบอ่านอย่างเดียว

ประโยคสำคัญคือเขาไม่ได้บ่นว่า GitHub ขาดฟีเจอร์ แต่บอกว่าแพลตฟอร์มที่เขาพึ่งพาหยุดทำงานนานพอที่จะขวางงานหลักของโครงการ

ทำไมประเด็นความน่าเชื่อถือสำคัญกว่าการย้ายแพลตฟอร์ม

คำถามที่ควรถามไม่ใช่ “Ghostty จะย้ายไปไหน” แต่คือ “ทำไมแพลตฟอร์มหลักของนักพัฒนาถึงทำให้ผู้ใช้ระดับนี้หมดความเชื่อมั่นได้”

เหตุการณ์นี้ต่างจากโพสต์ย้ายแพลตฟอร์มทั่วไปด้วย 3 ปัจจัย:

1. ตัวผู้ใช้
   
   ฮาชิโมโตะไม่ใช่ผู้ใช้ทั่วไป เขาเป็นผู้สร้างเครื่องมือ infrastructure ที่องค์กรขนาดใหญ่ใช้งานจริง เมื่อเขาบอกว่า GitHub ไม่น่าเชื่อถือ ข้อความนี้ส่งผลต่อทีมที่ตัดสินใจว่าจะเก็บ source code และ CI ไว้ที่ใด

2. เหตุผลในการย้าย
   
   เขาไม่ได้ย้ายเพราะ Copilot, AI training, ราคา หรือประเด็นการเมืองของแพลตฟอร์ม เขาย้ายเพราะบริการล่มบ่อยเกินไป

3. น้ำเสียง
   
   โพสต์ไม่ได้ดราม่า แต่มาในรูปแบบคล้าย incident review จากคนที่พยายามอยู่ต่อแล้วแต่ไปต่อไม่ได้

สำหรับผู้สร้าง dev tools สถานการณ์แบบนี้คือสัญญาณอันตรายที่สุด: ผู้ใช้ไม่ได้โกรธเสียงดัง แต่จดบันทึกเงียบ ๆ ว่าเครื่องมือคุณใช้งานไม่ได้กี่ครั้ง จนวันหนึ่งตัดสินใจย้ายออก

วิธี stress test เครื่องมือของคุณเอง

ถ้า product ของคุณอยู่ใน workflow ของนักพัฒนา ให้ลองตอบคำถามเหล่านี้แบบมีตัวเลข

1. ผู้ใช้ power user เสียเวลากับ downtime ของคุณกี่ชั่วโมงต่อสัปดาห์

ดึงข้อมูล 90 วันที่ผ่านมา:

• incident จาก status page
• degraded performance ที่ทีมรู้แต่ไม่ได้ประกาศ
• ช่วงเวลาที่ queue ล่าช้า
• API error rate ที่สูงกว่าปกติ
• CI job failure ที่เกิดจาก infrastructure ไม่ใช่โค้ดผู้ใช้

จากนั้น map กับช่วงเวลาทำงานของลูกค้าหลัก 20 รายแรก ถ้าผู้ใช้ heavy user เสียเวลามากกว่า 0 ชั่วโมงต่อสัปดาห์เพราะคุณ นั่นคือสัญญาณเตือน

2. ความน่าเชื่อถือของคุณกำลังดีขึ้นหรือแย่ลง

อย่าดูเฉพาะ uptime เฉลี่ย ให้ดู trend:

เดือน 1: incident 2 ครั้ง
เดือน 2: incident 4 ครั้ง
เดือน 3: incident 7 ครั้ง

แม้ SLA ยังผ่าน แต่ทิศทางแบบนี้คือปัญหาเดียวกับที่ฮาชิโมโตะจดไว้: ไม่ใช่ incident เดี่ยว แต่เป็น pattern

3. status page ของคุณบอกความจริงพอหรือไม่

ผู้ใช้เริ่มจดบันทึกเองเมื่อไม่เชื่อสัญญาณจากผู้ให้บริการ

status page ที่ดีควรบอก:

• component ใด degraded
• region ใดช้า
• queue ล่าช้ากี่นาที
• API endpoint ใด error สูง
• workaround ที่ใช้ได้ตอนนี้
• เวลาอัปเดตล่าสุด

การเขียนแค่ว่า “We are investigating” ซ้ำ ๆ ไม่ช่วยสร้างความเชื่อมั่น

4. คุณวัด reliability ตามเวลาของลูกค้าหรือเวลาของคุณ

Uptime 99.95% อาจดูดี แต่ถ้า downtime ทั้งหมดเกิดช่วงเวลาที่ลูกค้าตรวจ PR หรือ deploy production มันคือปัญหาใหญ่

ให้วัด availability ตาม user journey เช่น:

• เปิด PR
• run CI
• review
• merge
• release
• rollback

ถ้าเส้นทางใดหยุดกลางคัน เครื่องมือของคุณไม่พร้อมสำหรับงานจริงจัง

ต้นทุนของ “ต้องเป็น GitHub เสมอ”

ประโยคที่ฮาชิโมโตะพูดถึงตัวเองน่าสนใจมาก: “สำหรับผมแล้ว ไม่เคยมีคำถามเลยว่าจะวางโปรเจกต์ไว้ที่ไหน: ก็ต้อง GitHub เสมอ”

นี่คือต้นทุนของ default choice

GitHub ไม่ได้เป็นแค่ที่เก็บ git repo แต่รวมถึง:

• issues
• pull requests
• code review history
• discussions
• GitHub Actions
• releases
• packages
• secrets
• CODEOWNERS
• GitHub OAuth
• Marketplace integrations

คุณ clone git repo ไปที่อื่นได้ง่าย แต่ clone workflow ทั้งหมดไม่ได้ง่ายขนาดนั้น

สำหรับผู้สร้างเครื่องมือ ต้นทุนนี้หนักกว่าเดิม ถ้า product ของคุณ:

• ทำงานผ่าน GitHub Actions
• authenticate ด้วย GitHub OAuth
• เรียก GitHub API
• publish ผ่าน GitHub Packages
• distribute ผ่าน GitHub Marketplace

แปลว่า reliability ของคุณผูกกับ GitHub โดยตรง ลูกค้าอาจมองว่า product คุณล่ม แม้ root cause อยู่ที่ provider ที่คุณพึ่งพา

แนวทางลด vendor lock-in แบบลงมือทำได้

แนวคิดหลักคือ: ทำให้ provider เป็น adapter ไม่ใช่ core logic

ตัวอย่างโครงสร้างแบบง่าย:

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

จากนั้นแยก implementation:

class GitHubProvider implements SourceControlProvider {
  async listPullRequests(repo: string) {
    // call GitHub API
  }

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

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

class GitLabProvider implements SourceControlProvider {
  async listPullRequests(repo: string) {
    // call GitLab merge request API
  }

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

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

แล้วเลือก provider ผ่าน config:

const provider =
  process.env.SCM_PROVIDER === "gitlab"
    ? new GitLabProvider()
    : new GitHubProvider()

รูปแบบนี้ทำให้คุณทดสอบ fallback ได้จริง และลดการฝัง GitHub API ไว้ทั่ว codebase

แพลตฟอร์มทางเลือกโดยสังเขป

ฮาชิโมโตะยังไม่ได้ระบุปลายทางของ Ghostty แต่ตัวเลือกที่เป็นไปได้ ณ สิ้นเดือนเมษายน 2026 ได้แก่:

• Forgejo
  
  hard fork ของ Gitea เป็น FOSS ดูแลโดย Codeberg e.V. เหมาะกับโครงการที่ให้ความสำคัญกับซอฟต์แวร์เสรี

• Codeberg
  
  hosted Forgejo โดยองค์กรไม่แสวงหากำไร ฟรีสำหรับโอเพนซอร์ส แต่ยังไม่มี feature parity กับ GitHub Actions

• GitLab
  
  CI/CD แข็งแรง รองรับ workflow ส่วนใหญ่ที่ทีมคุ้นกับ GitHub มี commercial support แต่มีข้อถกเถียงในชุมชน FOSS จากการเปลี่ยนแปลงใบอนุญาต

• Sourcehut
  
  workflow เน้นอีเมล เรียบง่ายและเร็ว เหมาะกับผู้ใช้เฉพาะกลุ่ม

• Self-hosted Forgejo หรือ Gitea
  
  ควบคุมได้สูงสุด แต่รับภาระ operation เองทั้งหมด

• Radicle
  
  peer-to-peer ไม่มี host กลาง แนวคิดน่าสนใจแต่ยังอาจเร็วเกินไปสำหรับ project สาธารณะขนาดใหญ่

ประเด็นสำคัญคือไม่มีตัวเลือกใดแทน GitHub ได้ครบทุกพื้นผิวทันที นี่คือเหตุผลที่การย้ายแบบค่อยเป็นค่อยไปจึงสมเหตุสมผลกว่า big bang migration

บทเรียนสำหรับทีม API

ถ้าคุณสร้าง API หรือเครื่องมือ API ให้แทนคำว่า “GitHub Actions” ด้วย “upstream API ที่ product คุณพึ่งพา”

คำถามคือ: ลูกค้าของคุณยังทำงานต่อได้หรือไม่ เมื่อ upstream นั้นล่ม

Pattern 1: Mock ทุก dependency ที่สำคัญ

ทีมควรมี mock server สำหรับ API ต้นน้ำ เพื่อให้:

• local development ไม่ต้องรอ external service
• test suite รันได้แม้ provider ล่ม
• CI ไม่พังเพราะ network หรือ quota
• reproduce bug ได้ด้วย response เดิม

ตัวอย่าง response mock:

{
  "id": "chatcmpl_mock_001",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Mock response for local testing"
      }
    }
  ]
}

Apidog รองรับการสร้าง mock จาก schema เดียวกับที่ใช้ทดสอบ API จริง อ่านตัวอย่างการจำลองหลายผู้ให้บริการได้ใน วิธีใช้ GPT-5.5 API

Pattern 2: ทดสอบกับผู้ให้บริการหลายราย

ถ้า product ของคุณรองรับหลาย provider เช่น OpenAI, Anthropic, Mistral, DeepSeek, Google หรือ xAI อย่าทดสอบเฉพาะ provider หลัก

ตัวอย่าง environment config:

PROVIDER=openai
BASE_URL=https://api.openai.com/v1
API_KEY=...

PROVIDER=backup
BASE_URL=https://api.backup-provider.example/v1
API_KEY=...

จากนั้นให้ test suite เดิมรันซ้ำกับแต่ละ environment:

PROVIDER=openai npm run test:contract
PROVIDER=backup npm run test:contract

ใน Apidog สามารถใช้ environment variables เพื่อสลับ base URL, token และ mock/prod endpoint ได้โดยไม่ต้องแก้ request definition

Pattern 3: แยก release pipeline ออกจาก hosting platform

ถ้า CI ทั้งหมดอยู่บน GitHub Actions และ Actions ล่ม คุณ release ไม่ได้

ขั้นต่ำควรมี:

• mirror repo ไปแพลตฟอร์มที่สอง
• runner สำรอง
• manual release path
• artifact signing ที่ไม่ผูกกับ provider เดียว
• rollback procedure ที่ทำได้โดยไม่ต้องใช้ CI หลัก

ตัวอย่าง mirror job แบบง่าย:

git remote add backup [e-mail]:org/repo.git
git push backup main --tags

หรือใช้ scheduled CI รายสัปดาห์เพื่อ push mirror อัตโนมัติ

เวิร์กโฟลว์แบบ Apidog สำหรับ API ที่ยืดหยุ่น

รูปแบบการทำงานที่นำไปใช้ได้ทันที:

1. ดาวน์โหลด Apidog และสร้างหนึ่ง project ต่อ API ต้นน้ำที่คุณพึ่งพา
2. กำหนด request และ response schema เพียงครั้งเดียว
3. ใช้ schema เดียวกันสร้าง mock server
4. แยก environment เป็น dev, staging, prod และ mock
5. เก็บ credentials เป็น environment-scoped secrets
6. เขียน contract tests สำหรับ endpoint สำคัญ
7. รัน test เดิมกับ provider ทุกตัวที่รองรับ
8. เมื่อ upstream ล่ม ให้สลับ environment เป็น mock แล้วทำงานต่อ

ตัวอย่าง environment:

dev:
  base_url = https://mock.apidog.local
  auth = mock-token

staging:
  base_url = https://sandbox.vendor.com
  auth = staging-token

prod:
  base_url = https://api.vendor.com
  auth = prod-token

เป้าหมายไม่ใช่ทำให้ upstream ไม่ล่ม แต่ทำให้ทีมของคุณไม่หยุดทำงานเมื่อ upstream ล่ม

สิ่งที่นักพัฒนากำลังอ่านจากประกาศนี้

ปฏิกิริยาในช่วง 48 ชั่วโมงแรกแบ่งได้เป็นหลายกลุ่ม:

• กลุ่มที่เห็นด้วยกับฮาชิโมโตะ
  
  ผู้ใช้ GitHub ระดับสูงที่รู้สึกปัญหา reliability มานาน และมองว่าโพสต์นี้ยืนยันสิ่งที่ตนเจอ

• กลุ่มที่มองว่าเป็นแค่ incident เดียว
  
  คนกลุ่มนี้ชี้ว่า uptime รวมของ GitHub ยังแข่งขันได้ แต่ประเด็นของฮาชิโมโตะคือ trend ไม่ใช่ตัวเลขเฉลี่ย

• กลุ่มที่รู้ว่าการย้ายแพลตฟอร์มยาก
  
  วิศวกรที่เคย migrate ระบบรู้ว่าปัญหาไม่ได้อยู่ที่ git history แต่อยู่ที่ issues, PR history, CI, secrets และ workflow ทั้งหมด

• ผู้ดูแล project ขนาดเล็ก
  
  หลายคนเริ่มถามว่าควรย้ายหรือไม่ คำตอบคือ pattern เดียวกัน แต่ scale ต่างกัน สำหรับหลาย project การ mirror อาจพอ ส่วนการย้ายหลักอาจยังไม่คุ้ม

การสนทนาที่สำคัญที่สุดไม่ได้อยู่บน social media แต่อยู่ใน Slack และ meeting ของทีม engineering ที่ใช้ GitHub เป็นฐานของทุกอย่าง: เรามีแผนออกจากแพลตฟอร์มหรือยัง

Checklist เชิงปฏิบัติสำหรับทีมของคุณ

ใช้รายการนี้เป็น starting point:

• [ ] mirror repository สำคัญไปแพลตฟอร์มที่สองอย่างน้อยสัปดาห์ละครั้ง
• [ ] แยก provider API เป็น adapter ไม่ฝัง logic เฉพาะ GitHub/GitLab ไว้ทั่ว codebase
• [ ] ทำเอกสาร manual release path
• [ ] ทดสอบ rollback โดยไม่ใช้ CI หลัก
• [ ] ระบุ external service ทุกตัวใน critical path
• [ ] เขียนคำตอบสำหรับคำถาม: “ถ้าบริการนี้ล่ม 4 ชั่วโมง เราทำอะไรได้บ้าง”
• [ ] ติดตาม incident trend รายเดือน ไม่ใช่แค่ uptime เฉลี่ย
• [ ] ประกาศ degraded performance อย่างโปร่งใสบน status page
• [ ] มี mock server สำหรับ API ต้นน้ำที่สำคัญ
• [ ] มี contract tests ที่รันกับ provider หลักและ provider สำรอง

สำหรับตัวอย่างด้าน API เพิ่มเติม อ่าน การสร้างเวิร์กโฟลว์ที่ทนทานต่อการหยุดทำงานของผู้ให้บริการ ซึ่งใช้ DeepSeek และ OpenAI เป็นตัวอย่าง provider สองราย

คำถามที่พบบ่อย

Ghostty จะย้ายไปที่ใด

ฮาชิโมโตะยังไม่ได้ระบุปลายทาง เขากล่าวว่ากำลังพูดคุยกับผู้ให้บริการหลายราย ทั้งเชิงพาณิชย์และ FOSS การย้ายจะทำแบบค่อยเป็นค่อยไป และ GitHub repository เดิมจะคงอยู่แบบอ่านอย่างเดียว

GitHub ไม่น่าเชื่อถือขนาดนั้นจริงหรือ

ตัวเลข uptime รวมของ GitHub ยังแข่งขันได้ แต่ประเด็นของฮาชิโมโตะคือ partial outage และ degraded service ที่เกิดถี่พอจะกระทบงานประจำวัน โดยเฉพาะ GitHub Actions, Packages และ API

ฉันควรย้าย repo ออกจาก GitHub ตอนนี้ไหม

สำหรับทีมส่วนใหญ่ คำตอบที่ pragmatic คือเริ่มจาก mirror ก่อน ไม่จำเป็นต้องย้ายหลักทันที การ mirror มีต้นทุนต่ำและช่วยลดความเสี่ยง ส่วนการย้ายเต็มรูปแบบต้องคิดเรื่อง issues, PR history, CI, secrets และ workflow ทั้งหมด

สิ่งนี้เกี่ยวกับ GitHub Copilot หรือ GitHub Actions อย่างไร

โพสต์ของฮาชิโมโตะไม่ได้โจมตี Copilot โดยตรง แต่ incident ที่เป็นตัวเร่งคือ GitHub Actions หากทีมของคุณใช้ GitHub Copilot และต้องการดูเรื่อง usage หรือ billing API อ่านได้ที่ การใช้งานและ API การเรียกเก็บเงินของ GitHub Copilot สำหรับทีม

Dev tools ที่พึ่งพา GitHub API ควรทำอะไร

ให้ treat GitHub เป็น third-party dependency:

• cache ข้อมูลที่อ่านบ่อย
• degrade gracefully เมื่อ API error
• retry แบบมี backoff
• มี queue สำหรับงานที่ส่งไม่สำเร็จ
• mock GitHub API ใน test suite
• แยก provider เป็น adapter

ตัวอย่าง workflow ที่เกี่ยวข้องดูได้ใน บทความเกี่ยวกับบอทคัดแยก Clawsweeper

นี่เป็นแนวโน้มออกจาก GitHub หรือแค่เหตุการณ์ครั้งเดียว

น่าจะเป็นสัญญาณเริ่มต้นของแนวโน้มที่ช้า การย้าย project ขนาดจริงออกจาก GitHub ใช้เวลาและต้นทุนสูง จึงไม่น่าจะเกิดพร้อมกันจำนวนมาก แต่โพสต์นี้ทำให้หลายทีมเริ่มประเมินความเสี่ยงของการพึ่งพาแพลตฟอร์มเดียวอย่างจริงจัง

“ผู้สร้างเครื่องมือสำหรับนักพัฒนา” หมายถึงใคร

หมายถึงใครก็ตามที่สร้างซอฟต์แวร์ซึ่งนักพัฒนาใช้ใน workflow ประจำวัน เช่น terminal, editor, CI runner, API client, testing tool, package registry, review bot หรือ AI coding assistant ถ้าเครื่องมือของคุณอยู่ระหว่างนักพัฒนากับการจัดส่งซอฟต์แวร์ บทเรียนเรื่อง reliability จากกรณี Ghostty ใช้กับคุณโดยตรง