GitHub กำลังจม

• หลังจากถูก Microsoft เข้าซื้อกิจการ ความพร้อมใช้งาน (uptime) ของ GitHub แย่ลงอย่างเห็นได้ชัด แม้แต่หน้าสถานะอย่างเป็นทางการก็ยังแสดงตัวเลขที่น่ากังวล และหน้าสถานะแบบไม่เป็นทางการยิ่งสะท้อนสถานการณ์ที่หนักกว่า
• การใช้งาน Copilot อย่างพร่ำเพรื่อและการท่วมท้นของโค้ดคุณภาพต่ำที่สร้างโดย AI (slop) กำลังทำให้ GitHub เหมือน DDoS ตัวเอง ขณะที่บอตและเศรษฐกิจดาวปลอมก็บั่นทอนความน่าเชื่อถือของแพลตฟอร์ม
• Git เป็น ระบบควบคุมเวอร์ชันแบบกระจายศูนย์ แบบโอเพนซอร์ส และทำงานได้โดยไม่ต้องมี GitHub ดังนั้นควรเลิกมองว่า GitHub คือสิ่งเดียวกับตัว Git
• มี Git forge ทางเลือก หลากหลาย เช่น Codeberg, Tangled, Gitea, GitLab และ Forgejo แบบโฮสต์เอง ซึ่งควรเริ่มย้ายตั้งแต่ตอนนี้ทันที
• นักพัฒนาชื่อดังหลายคนทยอยเขียนประกาศเลิกใช้ GitHub ทำให้การลดการพึ่งพา GitHub กลายเป็น โจทย์ของทั้งระบบนิเวศ

---

เหตุผลที่ควรออกจาก GitHub

• GitHub ถูกวิจารณ์ว่าหลังจาก Microsoft เข้าซื้อแล้ว ทั้งอัตราการพร้อมใช้งานและประสบการณ์ใช้งานแย่ลง และมองว่า หน้าสถานะที่ตกหล่น เผยแนวโน้มที่เลวร้ายกว่าหน้าสถานะทางการ
• กราฟ GitHub’s Historic Uptime ถูกใช้เป็นข้อมูลแสดงให้เห็นว่าอัตราพร้อมใช้งานเฉลี่ยรายเดือนหลังการเข้าซื้อโดย Microsoft มีความไม่เสถียรมากขึ้น
• หลังการเข้าซื้อ Microsoft ได้เพิ่ม ชุดผลิตภัณฑ์ที่เกี่ยวกับ Copilot และ GitHub ก็อยู่ในสภาพที่ถูกรุมด้วย “slop” จนถึงขั้นต้องออก อัปเดตปัญหาด้านความพร้อมใช้งาน ด้วยตัวเอง
• ช่วงหลังมีบทความต่อเนื่องเกี่ยวกับการออกจาก GitHub หรือการหวนมองวิธีพัฒนาซอฟต์แวร์ก่อนยุค GitHub
  • Ditching GitHub - Lonami
  • Ghostty Is Leaving GitHub - Mitchell Hashimoto
  • Before GitHub - Armin Ronacher
  • From GitHub to Codeberg/Forgejo - Jonas Hietala
  • GitHub is dead, What’s next? - Alex Hyett

Git ≠ GitHub

• แม้ GitHub จะกลายเป็นคำพ้องกับ “การจัดการซอร์สโค้ด” แต่ผู้ใช้จำนวนมากเกินไปยังไม่รู้ว่า Git ไม่ใช่ GitHub
• Git และ GitHub ไม่ใช่สิ่งเดียวกัน และเทคโนโลยีแกนหลักของ Git เป็น โอเพนซอร์ส และเป็นแบบกระจายศูนย์ ดังนั้นทุกรีโพซิทอรีจึงเท่าเทียมกัน และทำงานได้โดยไม่ต้องมีบริการศูนย์กลาง
• บริการแบบรวมศูนย์เป็นผลผลิตของความสะดวกทางสังคม เดิมที GitHub เป็นเพียงเครื่องมือเสริมที่มีประโยชน์ แต่ Microsoft ได้เปลี่ยนมันให้กลายเป็น ภาระราคาแพง
• แม้พลังของ network effect จะสูง แต่ เศรษฐกิจดาวปลอม ของ GitHub ก็ไร้คุณค่า และเต็มไปด้วยบอตกับ slop
• GitHub Actions เป็นส่วนหนึ่งของ pipeline CI ที่ซับซ้อนเกินจำเป็น การหาทางออกอื่นอาจยุ่งยาก แต่ก็ควรถามตัวเองว่า ยังเชื่อถือเสถียรภาพของ GitHub ได้หรือไม่
  • GitHub Actions are killing your team
  • GitHub Actions is the weakest link
• เรือกำลังจม ดังนั้นแม้จะยังไม่ย้ายทุกอย่างในครั้งเดียว ก็ควร เริ่มกระบวนการย้ายทันที

ทางเลือกและวิธีย้าย

• เส้นทางหนีที่ใกล้ที่สุดคือการย้ายไปยัง Git forge แบบรวมศูนย์เจ้าอื่น โดยสมัครใช้งานแล้ว push รีโพซิทอรีไปเป็น upstream ใหม่
• บางบริการอาจช่วยทำ migration อัตโนมัติและรองรับการนำเข้า issue ได้ แต่ก็สามารถเลือกปล่อยให้ issue ของ GitHub คงอยู่ที่เดิมได้เช่นกัน
• ทางเลือกด้านล่างนี้ไม่มีตัวไหนสมบูรณ์แบบ จุดร่วมเดียวคือ มันไม่ใช่ GitHub

• ทางเลือก Git forge แบบรวมศูนย์

  • Codeberg — โครงการไม่แสวงกำไรที่ขับเคลื่อนโดยชุมชน เป็นทางเลือกที่ปลอดภัยและมีผลงานพิสูจน์แล้ว เป็นอินสแตนซ์หลักของ Forgejo
  • Tangled — สตาร์ตอัปช่วงอัลฟา และการผสานกับ AT protocol เป็นตัวเลือกที่น่าสนใจ น่าพิจารณาสำหรับโปรเจกต์ส่วนตัวขนาดเล็ก
  • Gitea — ให้บริการ Git hosting แบบคลาวด์ที่มีการจัดการ และเป็นโครงการโอเพนซอร์สดั้งเดิมที่ Codeberg/Forgejo แยกออกมา
  • GitLab — ระดับเอนเทอร์ไพรส์จึงค่อนข้างหนักและชวนสับสน แต่ก็อาจเหมาะกับการตัดสินใจในองค์กร
  • Bitbucket — ไม่ได้แนะนำเป็นพิเศษ แต่ก็อยู่ในหมวด “อะไรก็ได้ที่ไม่ใช่ GitHub”
  • Game of Trees, Radicle, Sourcehut — เป็นทางเลือกเพิ่มเติมที่ควรไปศึกษาด้วยตนเอง

• โฮสต์เอง

  • องค์กรหรือบุคคลสามารถโฮสต์ Git forge เองได้ และยังรัน actions กับ releases ได้ด้วย
  • ตัวเลือกแบบโฮสต์เองที่แนะนำคือ Forgejo
    • มีการพูดคุยเรื่อง federation ระหว่างอินสแตนซ์ของ Forgejo และ Tangled ก็มี บทความเกี่ยวกับ federation เช่นกัน แต่ดูไม่น่าจะเกิดขึ้นจริงในเร็ว ๆ นี้
  • หากต้องการการทำงานร่วมกันแบบสาธารณะ ก็สามารถใช้วิธี push สำเนาไปที่ Codeberg ได้
  • ทั้ง Gitea และ GitLab ก็มีตัวเลือกสำหรับโฮสต์เอง แต่ GitLab หนักกว่ามากเมื่อเทียบกัน
  • ไม่ใช่แค่ GitHub แต่ forge อื่น ๆ ก็แยกจากตัว Git เองเช่นกัน จึงควรพิจารณาว่าฟีเจอร์เสริมของ forge จำเป็นจริงหรือไม่
  • สามารถใช้ Git ตรง ๆ ผ่าน SSH ได้ด้วย

    git clone user@192.168.1.67:/path/to/repo  
    

• วิธีทำงานร่วมกันเป็นอีกประเด็นหนึ่ง แต่ถ้า Linux ยังดูแลรักษาได้ด้วยการส่งแพตช์ผ่านอีเมลเมลลิงลิสต์ ก็ยากจะสรุปว่าเป็นไปไม่ได้เพียงเพราะเรื่องขนาด
• Git forge แบบรวมศูนย์อาจเป็นทางประนีประนอมที่ใช้งานได้จริง แต่ก็ควรเผื่อความเป็นไปได้ว่าจะพังลงแบบ GitHub และมี แผนหนีทีไล่ ไว้เสมอ

[kimjoin2]

เมื่อคิดถึงฟีเจอร์ที่มีให้แล้ว ก็แทบน่าทึ่งเลยที่ดึงประสิทธิภาพออกมาได้เกิน 99%

[GN⁺]

ความเห็นจาก Hacker News

• ทุกคนอยากโทษเรื่องนี้ว่าเป็นเพราะ การเข้าซื้อโดย Microsoft หรือเพราะความไร้ความสามารถ แต่ถ้าดูข้อมูลที่ GitHub เผยออกมา จะเห็นค่อนข้างชัดว่าปริมาณโค้ดที่ถูกคอมมิตเข้า GitHub เพิ่มขึ้น 10 เท่าเพราะ AI และผลกระทบนั้นลามไปทั่วทั้ง CI, Actions, การเก็บรวบรวมโค้ด และส่วนอื่น ๆ
  ผู้เขียนชี้ไปที่ปัจจัยแปลก ๆ อย่าง MS Copilot ว่าเป็นสาเหตุ แต่ให้ความรู้สึกเหมือนกำลังไล่รายชื่อสิ่งที่ตัวเองไม่ชอบ มากกว่าจะพูดถึงความสัมพันธ์เชิงเหตุและผล
  ที่จริงกลับมองข้าม การระเบิดของโค้ดจาก AI ซึ่งเป็นช้างในห้องไปเสียอย่างนั้น

  • ถ้าดูกราฟในบทความ รูปแบบของการล่มเริ่มตั้งแต่ มกราคม 2020
    OpenAI ออก GPT-3.5 ในเดือนพฤศจิกายน 2022 หรือพูดตามจริงคือธันวาคม และการเขียนโค้ดด้วยโมเดลภาษา/เอเจนต์แบบที่อธิบายไว้นั้นเพิ่งเริ่มจริงจังในปี 2024 และในความเป็นจริงน่าจะใกล้กับปี 2025 มากกว่า
    ถ้าอย่างนั้น จะอธิบายเรื่องความพร้อมใช้งานที่แย่ลงตลอดราว 4 ปีหลังการเข้าซื้อ ก่อนที่คนจะเริ่มพูดถึง AI ได้อย่างไร?
  • พออ่านบทความแล้ว ฉันก็มีปฏิกิริยาเหมือนกันเป๊ะ
    จะกระโดดขึ้นขบวนวิจารณ์ Microsoft ก็ได้ แต่ห้ามมองข้ามช้างในห้อง
    ต่อให้พรุ่งนี้มีตัวแทน GitHub ที่สมบูรณ์แบบโผล่มา อะไรจะหยุด โค้ดที่ AI สร้าง หลายล้านบรรทัดไม่ให้พังโครงสร้างพื้นฐานของที่นั่นได้?
    โฮสติงโค้ดแบบรวมศูนย์ดูเหมือนจะใกล้ตายเพราะ AI คล้ายกับสิ่งที่เกิดขึ้นบนโซเชียลมีเดีย
  • หลังถูกซื้อไป GitHub ไม่มีอะไรดีขึ้นเลย
    10 ปีเป็นเวลาที่ยาวนาน และตอนนี้ผลลัพธ์มันก็ปรากฏแล้ว
    ทั้ง GitHub Actions, Copilot, การค้นหา AI หน้าตาน่าเกลียดที่ปิดก็ไม่ได้ รวมถึงการย้ายไป Azure
    Microsoft ประสบความสำเร็จในการทำลาย network effect และเหตุขัดข้องครั้งนี้ก็เป็นฟางเส้นสุดท้ายที่หักหลังอูฐ
  • ต่อให้เรื่องนั้นเป็นความจริง Microsoft ก็เป็นบริษัทที่มี แพลตฟอร์มคลาวด์ทั้งก้อน อยู่ในมือ
    มีโค้ดเบสขนาดมหึมาของตัวเอง และมีพนักงานราว 200,000 คน
    โดยเฉพาะเมื่อบริษัทตัดสินใจอย่างตั้งใจ เช่น การทำให้ private repository ใช้ฟรี เรื่องนี้จึงยากจะใช้เป็นข้ออ้าง
  • ฉันชอบจินตนาการว่า Microsoft รัน GitHub บน Windows ที่อยู่บน Azure cloud
    ทุกครั้งที่ GitHub ล่ม ฉันจะคิดว่า “สงสัยมีใครไปอัปเดต Windows Server ที่รัน GH อยู่แล้วต้องรีบูตทั้งกองแน่เลย”
    มั่นใจ 99% ว่าไม่จริง แต่พอคิดแบบนั้นแล้วสบายใจขึ้น และก็ตลกนิด ๆ ทุกครั้งที่มี outage

• วันนี้ฉันพยายามจะดู repository บน GitHub
  พอกดลิงก์ “xxx commits” เพื่อดูประวัติ commit ก็ขึ้นข้อความว่าติด secondary rate limit ให้รอก่อน
  ในเครือข่ายนี้คนที่ดู GitHub มีแค่ฉันคนเดียว และการเชื่อมต่อก็เป็น dedicated IP ไม่ใช่ CGN

  • วิธีเดียวที่จะใช้งานเว็บได้ดีจริง ๆ คือ ต้องล็อกอิน เข้าไปดู
  • ฉันก็เป็นเหมือนกันเป๊ะ และเจอบ่อยพอสมควร
  • บ่อยครั้งที่กดลิงก์ปกติจาก Slack แล้วของฉันขึ้น 404 แต่ของคนอื่นเปิดได้ปกติ
  • ถ้าเป็นเดสก์ท็อป ให้กด Ctrl + Shift + R เพื่อรีเฟรช page cache
    แล้วหน้าจะโหลดได้ตามปกติ
  • นี่คือ gaslighting สไตล์ tech bro แบบคลาสสิก
    ในความเป็นจริงมันแทบจะเป็นการปฏิเสธโดยปริยายมาหลายปีแล้ว ไม่ใช่ rate limit และพวกเขาก็ยังปฏิเสธจะเปลี่ยนข้อความให้ตรงกับความจริง

• “GitLab - คำว่า enterprise-grade หมายถึงมันทั้งเทอะทะและชวนสับสน แต่ดูน่าประทับใจในสายตาหัวหน้า ถ้าต้องประชุมหลายรอบกว่าจะเลือกอะไรสักอย่าง นี่แหละคือสิ่งที่ควรเลือก”
  ฮาดี

  • ที่บริษัทเราใช้ GitLab และพูดตรง ๆ ว่าผิดหวัง
    แค่จะทำเรื่องง่ายที่สุด UI ก็ซับซ้อนเกินไป เช่น ถ้าจะ approve MR ต้องกดปุ่มที่แทบจะเป็นเมนูอยู่แล้ว, diff ก็อ่านยาก, และใน ‘To-do list’ ยังมี MR ที่ merge ไปแล้วอยู่ด้วย แบบนั้นจะเป็นงานที่ทำต่อได้ยังไง?
    ปัญหาที่ MR ที่ merge แล้วค้างอยู่ใน ‘To-do list’ มีคนแจ้งมาหลายปีแล้ว แต่ก็ดูเหมือนจะปรับปรุงช้ามาก
    ในทางกลับกัน กระแสต้าน Bitbucket ทำให้ฉันแปลกใจนิดหน่อย UI ของมันเรียบง่ายและชัดเจนมาก และคนที่เพิ่งเข้ามาใหม่ก็มักรู้สึกแบบนั้นเหมือนกัน ถ้าใช้ Script Runner ก็ทำอะไรน่าทึ่งได้พอสมควร และมันก็รับมือกับ repository ขนาดใหญ่มากได้ดี
  • ตลกก็จริง แต่ไม่ใช่เรื่องจริง
    GitLab ไม่ได้เทอะทะหรือชวนสับสนกว่า GitHub เป็นพิเศษ
    และก็ยากจะเรียกว่าเป็น ซอฟต์แวร์ระดับองค์กร ของจริง ถ้าอยากได้แบบนั้นไปดู Jira หรืออะไรก็ตามที่ Microsoft ทำก็พอ
  • ฉันขำออกจมูกเลย
    เราใช้ GitLab แบบ self-hosted และฉันเลือกมันเพราะมีทั้ง git กับ container registry
    ถ้าไม่ได้ใช้เว็บ UI บ่อย อินเทอร์เฟซมันก็ชวนงงได้จริง

• เดือนละ 5 ดอลลาร์ก็โฮสต์เซิร์ฟเวอร์สักเครื่องแล้ววางหลายโปรเจกต์ไว้ได้
  repository อาจไม่ได้มีดาวเป็นล้าน แต่สำหรับความต้องการของฉันมันก็ทำงานได้ดี และยังให้สิทธิ์เข้าถึงกับคนที่อยากใช้ได้ด้วย

• ฉันไม่ค่อยแน่ใจว่าควรอ่านกราฟนี้ยังไง
  ด้านหนึ่ง ความพร้อมใช้งานของ GitHub อาจแย่ลงเพราะการเข้าซื้อก็ได้
  แต่อีกด้านหนึ่ง การที่ก่อนเข้าซื้อมีความพร้อมใช้งาน 100.00% มันก็ดูน่าสงสัย เลยอดคิดไม่ได้ว่าอาจเป็นเพียงเพราะหน้า status เริ่มอัปเดตได้ดีขึ้น
  ฉันรู้ว่าช่วงหลัง GitHub มีปัญหาเรื่องความพร้อมใช้งาน แต่จากกราฟดูเหมือนปัญหาจะเริ่มในปี 2020 และไม่ได้แย่ลงอย่างมาก

• รู้สึกเหมือนว่า repository โอเพนซอร์สหลัก ๆ สุดท้ายแล้วปล่อยทิ้งไว้เฉย ๆ ไม่ได้จริง ๆ
  ฉันยังจำตอนที่ SourceForge ค่อย ๆ พังได้อยู่ และการได้เห็นเรื่องเดียวกันเกิดกับ GitHub ก็ทั้งเศร้าและน่าเสียดายมาก
  เสริมอีกนิด ฉันอ่าน URL ว่า “dBus hell” ไปเสียอย่างนั้น ก็ทุกคนเคยผ่านอะไรแบบนี้มาสักครั้งไม่ใช่เหรอ

  • ไม่ใช่ มันคือ dBu Shell เพราะเป็น nushell ที่อิงหน่วย dBu

• ฉันชอบคิดบ่อย ๆ ว่าถ้าตัวเองบริหารบริษัทจะทำยังไง
  ฉันอยากเห็นจริง ๆ ว่าถ้าทำ code review ทั้งหมดผ่าน อีเมล จะเป็นยังไง
  repository ก็ใช้แค่เซิร์ฟเวอร์ VPS ธรรมดาที่เปิดให้เข้าผ่าน SSH สำหรับ git อย่างเดียวก็พอ แล้วมี namespace ของ branch ชื่อ for-review/ สำหรับโค้ดที่ต้องรีวิว ส่วน CI ก็ทำเป็นบอตที่รอให้ branch โผล่มา จากนั้นคอมเมนต์หรือแท็กไว้ที่ ref เพื่อบอกว่าผ่านหรือไม่ผ่าน จะตอบผลกลับไปในอีเมลเธรดด้วยก็ได้
  mailing list ก็แน่นอนว่าติดเว็บ archive viewer ไว้สำหรับดูรีวิวเก่า ๆ ได้อยู่แล้ว วิธีแก้แบบนี้มีเยอะแยะ มันก็แค่ HTML
  แชตก็ใช้ IRC แล้วให้บอตเก็บ log ของช่องก็พอ ง่ายมาก
  ทั้งระบบสามารถรันบนเซิร์ฟเวอร์ราคาถูกมากได้ ยกเว้น runner ของ CI ที่อาจต้องใช้ฮาร์ดแวร์แรงกว่า
  GitHub ถูกออกแบบมามากเกินความจำเป็นสำหรับการทำโปรเจกต์ซอฟต์แวร์อย่างชัดเจน ดู Linux kernel สิ ใช้แค่ mailing list ธรรมดา ๆ แต่ก็แทบไม่มีข้อโต้แย้งว่าเป็นโปรเจกต์ซอฟต์แวร์ที่ประสบความสำเร็จที่สุดตลอดกาล
  แต่อย่างเรื่อง issue/bug tracking นี่น่ากลัวกว่า เพราะฉันคงไปจมกับการทำทางแก้เองจนมากกว่างานหลักของบริษัทเสียอีก หรือบางทีอาจต้องกลายเป็นบริษัทซอฟต์แวร์ติดตามบั๊กไปเลย?

  • ในอุดมคติ ฉันก็อยากให้ code review มีการควบคุมเวอร์ชัน และมีบันทึกที่เข้าถึงได้ง่าย
    คืออยากเห็นได้ว่าคอมเมนต์นั้นผูกอยู่กับบรรทัดไหนแน่ บรรทัดนั้นถูกเปลี่ยนเมื่อไร และสามารถสลับดูบริบทก่อนหลังได้
    อีเมลอาจเพียงพอในฐานะโปรโตคอลสำหรับแลกเปลี่ยนข้อมูลพวกนี้ แต่ฉันไม่คิดว่าอีเมลไคลเอนต์เป็นวิธีที่ดีในการแสดงผลมัน
    บางทีเราอาจต้องมีระบบ code review แบบกระจายศูนย์ด้วย

• การอยู่ยุโรปตะวันออกก็มีข้อดีเหมือนกัน
  เพราะเรื่องเขตเวลา ฉันแทบไม่ทันสังเกตเหตุขัดข้องใหญ่ ๆ ของ GitHub เลย
  และก็พอใจกับการที่มันให้โฮสติงฟรีกับ Actions มาอย่างค่อนข้างใจกว้าง

• ตั้งแต่ติดตั้ง Forgejo บนโฮมเซิร์ฟเวอร์ ฉันก็ไม่เคยหันกลับไปอีกเลย
  ปัญหาเดียวคือเวลาจะโฮสต์แอปบน DigitalOcean App Platform หรือ Vercel ซึ่งพวกนี้เชื่อมกับ GitHub อย่างเดียว

  • DigitalOcean App Platform รองรับการ deploy จาก GitHub อย่างเดียวไม่ใช่ ยังรองรับ GitLab ด้วย
    เพียงแต่ต้องใช้ instance ที่โฮสต์บน gitlab.com ไม่ใช่ GitLab แบบ self-hosted
    ถ้าคุณ deploy forge แบบ self-hosted ไว้แล้ว ก็สามารถใช้ gitlab.com เป็นสะพานเพื่อเชื่อมกับ DigitalOcean App Platform ได้ แค่สร้างบัญชี gitlab.com หนึ่งครั้ง แล้วให้ forge แบบ self-hosted ส่ง mirror ไปที่ gitlab.com ก็พอ แทบไม่จำเป็นต้องใช้ GitLab จริง ๆ เลย
    ถึงอย่างนั้น DigitalOcean เป็นบริษัทที่ขาย IaaS/PaaS แต่กลับไม่ยอมให้เชื่อมกับของอย่าง Forgejo แบบ self-hosted ที่รันอยู่บนโครงสร้างพื้นฐานของตัวเอง มันก็ฟังไม่ขึ้น
    ที่จริงพอคิดว่ามีคนจำนวนมากอยากโฮสต์ forge ของตัวเอง แต่มีไม่กี่คนที่อยากตั้งค่าและดูแลเองทั้งหมด ก็ยิ่งแปลกที่ DigitalOcean ไม่หยิบ Forgejo หรือทางเลือกอื่นมาทำเป็นตัวเลือก deploy แบบ one-click กึ่งจัดการให้ ในราคาลดแรง ๆ อย่างปีละ 20 ดอลลาร์ และรองรับการเชื่อมกับ App Platform แบบ first-class
  • ทุกเหตุผลที่ควรหลีกเลี่ยง GitHub ก็เป็นเหตุผลเดียวกับที่ควรหลีกเลี่ยง DigitalOcean App Platform และ Vercel
    ฉันใช้ DigitalOcean เหมือนกัน แต่ใช้แค่ VPS
    อย่าไปผูกติดกับ vendor ในชั้นกลางพวกนี้ ควรรักษาการควบคุมไว้กับตัวเอง และมุ่งไปที่ชั้นของสแตกที่เป็นสากลให้มากที่สุด
  • ฉันก็อยู่ในสถานการณ์คล้ายกัน
    ฉันย้ายไปใช้ Gitea ตั้งแต่หลายปีก่อน ก่อนจะแตก fork เป็น Forgejo และไม่เคยเสียใจเลย
    ถ้าจำเป็นต้องใช้ GitHub ก็ยัง mirror repository ไปที่นั่นให้มันทำงานได้อยู่ เพียงแต่การซิงก์โค้ดค่อนข้างน่ารำคาญ
  • Xcode Cloud ของ Apple ก็คล้ายกัน

• GitHub กำลังลำบากเพราะการเขียนโค้ดที่เสริมพลังด้วย AI ทำให้จำนวน commit ในช่วง 1 ปีที่ผ่านมาเพิ่มขึ้น 14 เท่า และความเร็วนี้ก็ยังเร่งขึ้นอยู่
  ตัวเว็บกำลังตามไม่ทัน
  COO ของ GitHub ยืนยันเองที่นี่: https://x.com/kdaigle/status/2040164759836778878
  กิจกรรมบนแพลตฟอร์มกำลังพุ่งสูงมาก ในปี 2025 เคยมี 1 พันล้าน commit แต่ตอนนี้อยู่ที่ 275 ล้านครั้งต่อสัปดาห์ ดังนั้นต่อให้โตแบบเส้นตรงอย่างเดียว ปีนี้ก็จะอยู่ที่อัตรา 14 พันล้านครั้งแล้ว และแน่นอนว่าคงไม่ได้จบแค่เส้นตรง
  GitHub Actions เพิ่มจาก 500 ล้านนาทีต่อสัปดาห์ในปี 2023 เป็น 1 พันล้านนาทีต่อสัปดาห์ในปี 2025 และสัปดาห์นี้จนถึงตอนนี้ก็แตะ 2.1 พันล้านนาทีไปแล้ว
  เพราะงั้นตอนนี้พวกเขาเลยกำลังเร่งอย่างหนักทั้งเรื่อง CPU เพิ่ม, การขยายบริการ, และการเสริมความแข็งแรงให้ฟังก์ชันหลักของ GitHub