ขณะนี้ GitHub กำลังเกิดเหตุขัดข้อง

• กำลังเกิดประสิทธิภาพลดลงของ Pull Requests และอาจมองไม่เห็น pull request ที่ถูกทำดัชนีทั้งหมดบนหน้า /pulls และ /repo/pulls
• ขณะนี้ในคลัสเตอร์ Elasticsearch ยังมีเอกสารที่ทำดัชนีไม่ครบทั้งหมด แต่ข้อมูล pull request เองไม่ได้สูญหาย และจะถูกทำดัชนีใหม่เมื่อมีการอัปเดต
• กำลังดำเนินการทั้งการทำดัชนีใหม่สำหรับดัชนีที่เหลืออยู่ และเร่ง full reindex เพื่อกู้คืนผลลัพธ์ทั้งหมด โดยให้ความสำคัญกับความถูกต้องและการหลีกเลี่ยงผลกระทบเพิ่มเติมเป็นอันดับแรก
• ในตารางสถานะคอมโพเนนต์ แสดงว่าเฉพาะ Pull Requests เท่านั้นที่อยู่ในสถานะลดประสิทธิภาพ ส่วน Git Operations, Webhooks, API Requests, Issues, Actions, Packages, Pages, Copilot, Codespaces และ Copilot AI Model Providers อยู่ในสถานะ Operational
• ในประวัติล่าสุดยังมีการเปิดเผยหลายกรณีเหตุขัดข้องและการกู้คืน เช่น การค้นหาทำงานลดลง, งาน Actions ล้มเหลว, เริ่มต้นเซสชัน Copilot agent ไม่สำเร็จ, merge queue regression, Projects หน่วงเวลา, และการเชื่อมต่อ Codespaces ล้มเหลว

---

สถานะเหตุขัดข้องปัจจุบัน

• กำลังเกิดประสิทธิภาพลดลงใน Pull Requests และมีการเผยแพร่ไว้ในรายการ Incomplete pull request results in repositories
• บนหน้า /pulls และ /repo/pulls อาจมองไม่เห็นผลลัพธ์ pull request ที่ถูกทำดัชนีทั้งหมด
  • ขณะนี้ในคลัสเตอร์ Elasticsearch ยังมีเอกสารที่ทำดัชนีไม่ครบทั้งหมด
  • ข้อมูล pull request เอง ไม่ได้สูญหาย
  • เมื่อ pull request ถูกอัปเดต จะถูกทำดัชนีใหม่อีกครั้ง
  • เพื่อกู้คืนผลลัพธ์ทั้งหมด ก็กำลังดำเนินการ เร่ง full reindex ควบคู่กันไป
• กำลังทำดัชนีใหม่ให้กับ Elasticsearch index ที่เหลืออยู่ โดยให้ความถูกต้องเป็นอันดับแรกและหลีกเลี่ยงผลกระทบเพิ่มเติม
  • ยังคงใช้แนวทางอย่างระมัดระวังในการ backfill ข้อมูลอย่างปลอดภัย

สถานะคอมโพเนนต์

• ในตารางสถานะปัจจุบัน มีเพียง Pull Requests ที่แสดงเป็น Degraded Performance
• คอมโพเนนต์หลักที่เหลืออยู่ในสถานะ Operational
  • Git Operations
  • Webhooks
  • API Requests
  • Issues
  • Actions
  • Packages
  • Pages
  • Copilot
  • Codespaces
  • Copilot AI Model Providers
• มีการแสดงอัตราการให้บริการย้อนหลัง 90 วันด้วย
  • Pull Requests 99.58% uptime
  • API Requests 99.95% uptime
  • Packages 99.97% uptime
  • Copilot AI Model Providers 100.0% uptime

หน้าสถานะแยกตามภูมิภาคและช่องทางติดตาม

• มีการให้บริการหน้าสถานะตามภูมิภาคสำหรับ GitHub Enterprise Cloud แยกต่างหาก
  • Australia: au.githubstatus.com
  • EU: eu.githubstatus.com
  • Japan: jp.githubstatus.com
  • US: us.githubstatus.com
• มีช่องทางสำหรับติดตามการแจ้งเตือนสถานะด้วย
  • Slack: Subscribe via Slack
  • บัญชี X: @githubstatus
  • เว็บไซต์ซัพพอร์ต: support site
  • ฟีด: Atom Feed, RSS Feed

ประวัติเหตุขัดข้องล่าสุด

• Apr 28 บริการ GitHub บางส่วนขัดข้อง

  • รายการ Disruption with some GitHub services ได้รับการแก้ไขแล้ว
  • ในงาน Actions hosted Ubuntu เกิดการเริ่มต้นล่าช้าและล้มเหลว
    • การรันบางส่วนของ ubuntu-latest และ ubuntu-24.04 ล่าช้าหรือล้มเหลว
    • ช่วงหนึ่งมีงานได้รับผลกระทบราว 5% จากนั้นลดลงเหลือ ต่ำกว่า 2% และต่อมาลดลงอีกเป็น ต่ำกว่า 1%
  • มีการบรรเทาปัญหาที่ขัดขวางการรัน Actions และสุดท้ายกู้คืนกลับสู่การทำงานปกติ

• Apr 27 การค้นหาของ GitHub ลดประสิทธิภาพ

  • รายการ GitHub search is degraded ได้รับการแก้ไขแล้ว
  • ปัญหาการเชื่อมต่อ Elasticsearch และภาระเพิ่มเติมทำให้เกิดการค้นหาล้มเหลวและปัญหากับบริการย่อยหลายรายการพร้อมกัน
    • Issues, Pull Requests, Packages และ Actions ได้รับผลกระทบ
    • เกิด workflow run ล้มเหลว, โหลด projects ไม่สำเร็จ และ search timeout
  • หลังจากปิดกั้นสาเหตุของภาระเพิ่มเติม ก็เริ่มมีสัญญาณการฟื้นตัว และจากนั้นเปลี่ยนไปสู่การเฝ้าติดตามเสถียรภาพ

• Apr 27 เหตุขัดข้องของเซสชัน Copilot Cloud Agent Codex

  • รายการ Disruption with some GitHub services ได้รับการแก้ไขแล้ว
  • ใน Copilot Cloud Agent เกิดการเริ่มต้นเซสชัน Codex agent ล้มเหลว
    • ไม่สามารถเริ่มต้นได้จากทุกช่องทางเข้า เช่น การ assign issue และการเมนชันคอมเมนต์ @copilot
    • มีผลกระทบต่อ 0.5% ของงาน Copilot Cloud Agent ทั้งหมด หรือราว 2,000 งานที่ล้มเหลว
    • เซสชัน agent อื่นของ Copilot ไม่ได้รับผลกระทบ
  • สาเหตุคือ model resolution mismatch ของเซสชัน Codex agent ทำให้มีการเลือกโมเดลที่ไม่เข้ากันใน runtime
  • มีการปล่อยมาตรการบรรเทาให้เซสชัน Codex agent เลือกโมเดลตั้งต้นที่เสถียร

กรณีสำคัญที่มีการเปิดเผยสาเหตุราก

• Pull Requests merge queue regression

  • Incident with Pull Requests ได้รับการแก้ไขแล้ว
  • เมื่อใช้ squash merge ใน merge queue หากใน merge group มี PR มากกว่าหนึ่งรายการ จะมีการสร้าง merge commit ที่ไม่ถูกต้อง
    • ในการ merge ภายหลัง อาจทำให้การเปลี่ยนแปลงของ PR ก่อนหน้าและการเปลี่ยนแปลง commit ก่อนหน้าถูกย้อนกลับ
    • ในช่วงที่ได้รับผลกระทบ มี 2,092 pull request ที่ได้รับผลกระทบ
  • PR ที่ merge นอก merge queue และบางกลุ่มที่ใช้วิธี merge หรือ rebase ไม่ได้รับผลกระทบ
  • สาเหตุคือมีการใช้ code path ใหม่สำหรับปรับการคำนวณ merge base ภายใต้สถานะ feature flag gating ที่ไม่สมบูรณ์
  • มีการย้อนการเปลี่ยนแปลงโค้ดและบังคับ deploy ไปทั่วทั้งระบบ พร้อมทั้งส่งขั้นตอนการกู้คืนแยกให้ผู้ดูแล repository ที่ได้รับผลกระทบ
  • หลังจากนั้นกำลังขยายขอบเขตการทดสอบความถูกต้องของ mergeให้ครอบคลุมถึง squash group แบบหลาย PR ด้วย

• ไม่สามารถเริ่ม Claude·Codex agent จากเว็บได้

  • Disruption with users unable to start Claude and Codex agent task from the web ได้รับการแก้ไขแล้ว
  • ไม่สามารถเริ่ม agent task ใหม่ด้วย Claude หรือ Codex agent จาก github.com ได้
  • สาเหตุคือการเปลี่ยนแปลงโค้ด routing ของ task creation request ใน Copilot mission control
  • agent task ที่กำลังดำเนินอยู่และความสามารถ agent อื่นของ Copilot ไม่ได้รับผลกระทบ
  • มีการย้อนการเปลี่ยนแปลงที่ก่อปัญหาเพื่อกู้คืน และกำลังเพิ่มmonitoring และ integration test ในเส้นทางการสร้าง task

• การประมวลผล @mention ของ Copilot ตกหล่น

  • Disruption with some GitHub services ได้รับการแก้ไขแล้ว
  • การเมนชัน @copilot ในคอมเมนต์ pull request ไม่ส่งผลให้มีการรัน Copilot coding agent
    • จากคอมเมนต์ pull request และ issue ทั้งหมด มีการเรียกใช้ประมาณ 23,000 ครั้ง หรือ 0.5% ที่ไม่ได้รับการประมวลผล
    • การสร้าง, ดู, และตอบกลับคอมเมนต์เองไม่ได้รับผลกระทบ
  • สาเหตุคือ serialization error ที่ทำให้ไม่สามารถ publish event ไปยัง downstream consumer ได้
  • หลัง deploy การแก้ไขเพื่อกู้คืนการ publish event ก็กลับมาทำงานปกติ และกำลังตรวจสอบ event schema ที่เกี่ยวข้องพร้อมปรับปรุง monitoring

• Copilot Chat และ Cloud Agent หยุดชะงัก

  • Disruption with Copilot chat and Copilot Coding Agent ได้รับการแก้ไขแล้ว
  • เกิดข้อผิดพลาดใน Copilot Chat และ Copilot Cloud Agent บน github.com และไม่สามารถใช้งานได้ในช่วงเวลาดังกล่าว
  • Copilot Memory ที่อยู่ในสถานะ preview ก็ไม่สามารถใช้งานได้ในเซสชัน agent เช่นกัน
  • สาเหตุคือการเปลี่ยนแปลงการตั้งค่าโครงสร้างพื้นฐานที่ทำให้เกิดปัญหาการเชื่อมต่อฐานข้อมูล
  • github.com ฟื้นตัวก่อน และ deployment ในภูมิภาคอื่นค่อย ๆ กู้คืนตามลำดับ

• Projects service หน่วงเวลา

  • Disruption with projects service ได้รับการแก้ไขแล้ว
  • Projects อาจไม่ซิงก์หรือสะท้อนการเปลี่ยนแปลงล่าช้า
    • ความล่าช้าในการสะท้อนการเปลี่ยนแปลงเพิ่มขึ้นได้สูงสุดราว 45 นาที
  • สาเหตุคือ serialization error ทำให้ event ล้มเหลวและ resync พุ่งสูงขึ้น จนทำให้ชั้นประมวลผล event รับภาระเกิน
  • มีการบรรเทาโดยเพิ่มความเร็วในการประมวลผลการเปลี่ยนแปลงขาเข้า และจากนั้นกู้คืนด้วยการเคลียร์ backlog

• การตั้งค่าเริ่มต้นของ code scanning·Code Quality ลดประสิทธิภาพ

  • Partial degradation for code scanning default setup and for code quality ได้รับการแก้ไขแล้ว
  • ใน pull request ใหม่ code scanning default setup และ การวิเคราะห์ code quality ไม่ถูก trigger
  • ยังเกิดปัญหาที่ issue ที่สร้างใหม่ไม่แสดงใน project board ด้วย
  • สาเหตุคือ serialization error ที่ทำให้ code scanning, การวิเคราะห์ code quality และการอัปเดต project board ไม่ถูก trigger อย่างถูกต้อง
  • มีการกู้คืนการ publish event ของ code scanning และ code quality แล้ว ส่วนฝั่ง project board กู้คืนด้วยการเปลี่ยนโค้ดเพิ่มเติมและ reindex
  • PR ที่ไม่ได้รับการประมวลผลก่อนหรือระหว่าง incident จะต้องมี push ใหม่ จึงจะ trigger การวิเคราะห์อีกครั้ง

เหตุขัดข้องล่าสุดอื่น ๆ

• Disruption with some GitHub services
  • ประสบการณ์ใช้งานเว็บ GitHub.com ลดลง และมีคำขอเว็บราว 1.5% จบลงด้วยข้อผิดพลาด
  • ในบางช่วงเวลา ประมาณ 10% ของทราฟฟิกเว็บช้าลงหรือล้มเหลว
  • สาเหตุคือ ความจุของคอมโพเนนต์แคชอิ่มตัวในภูมิภาคดาต้าเซ็นเตอร์แห่งหนึ่ง
  • มีการกู้คืนโดยเบี่ยงทราฟฟิกไปยังภูมิภาคที่ไม่กระทบและ rollback deployment ล่าสุด
• Incident with Codespaces
  • การเชื่อมต่อ GitHub Codespaces ผ่าน VS Code editor ล้มเหลว
  • งาน codespace start ราว 40% ล้มเหลว
  • การเชื่อมต่อ SSH ไม่ได้รับผลกระทบ
  • สาเหตุคือบริการดาวน์โหลด upstream ขัดข้อง ทำให้ไม่สามารถดาวน์โหลด VS Code Server ที่จำเป็นตอนเริ่มต้นได้
  • มีการบรรเทาด้วยวิธีเลี่ยงโดยใช้เส้นทางดาวน์โหลดทางเลือกเมื่อ endpoint หลักลดประสิทธิภาพ
• Disruption with some GitHub services
  • เกิดข้อผิดพลาด 500 เมื่อเข้าถึงหน้า Copilot Insights ของ GitHub Enterprise Cloud
  • มีผู้ใช้ได้รับผลกระทบราว 709 คน และระยะเวลารวมที่ได้รับผลกระทบราว 5 ชั่วโมง 10 นาที
  • สาเหตุคือความล้มเหลวในการยืนยันตัวตนของ metrics pipeline และการเปลี่ยนแปลง tenant credential
  • กำลังดำเนินการเพิ่มเครื่องมือวินิจฉัย, monitoring ที่ละเอียดขึ้น, และการเสริมความเข้มของ alerting

[GN⁺]

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

• ตอนนี้การ ล้มเหลวแบบเงียบๆ ยิ่งเป็นปัญหามากกว่าอีก
  อย่างเช่นมี PR อยู่เป็นสิบอันแท้ๆ แต่กลับแสดงว่า "There aren’t any open pull requests." ซึ่งทำให้คนเข้าใจผิดอย่างชัดเจน

  • อาทิตย์ก่อนตอนใช้ merge queue ก็เคยมีกรณีที่เผลอลบ trunk ไปโดยไม่ตั้งใจ และมันก็ล้มเหลวแบบเงียบๆ เหมือนกัน
  • ฝั่งเรากลับถึงขั้นเอามาแซวกันว่าดูเหมือนในที่สุดเราจะปิด PR หมดแล้ว เลยต้องฉลองกัน
  • ต่อให้รายการ PR ขึ้นมา บางครั้งก็ยัง แสดง PR ในหมวดที่กำลังดูไม่ครบทั้งหมด ซึ่งแย่มากจริงๆ

• เรื่องนี้โดนใจผมมากจริงๆ
  เมื่อไม่กี่เดือนก่อน $PARENT_CONGLOMERATE บังคับให้ทุกหน่วยงานในเครือย้ายไปใช้ GitHub โดยอ้างเรื่อง synergy และ efficiency และตอนนี้ที่ $DAYJOB ของผมก็มาถึงคิวต้องย้ายออกจาก self-hosted GitLab แล้ว
  ตอนนี้ก็มีเรื่องน่าหงุดหงิดอยู่หลายอย่างแล้ว
  นโยบาย IT เรื่อง บัญชี GH ก็ขัดกันเองไปหมด ไม่ว่าจะเป็นบัญชีส่วนตัวหรือบัญชีที่เคยสร้างแยกไว้สำหรับ $DAYJOB มาก่อน ก็ใช้บัญชีเดิมไม่ได้เลย ต้องสร้างบัญชีใหม่ให้ตรงตามกฎของ IT เท่านั้น
  เราไม่ได้ใช้ monorepo เลยพึ่ง groups กันเยอะมาก แต่ใน GitHub ไม่มีแนวคิดที่เทียบตรงๆ ได้ เลยต้องมานั่งจัด namespace ของโปรเจ็กต์ด้วยมือ
  แล้วยังมาเจอสภาพความพร้อมใช้งานของ GitHub แบบนี้อีก
  ทีมเรามีกำหนดปล่อยงานที่อ่อนไหวต่อรายได้มาก แค่เลื่อนวันสองวันก็อาจตัดสินได้เลยว่าจะถึงเป้ารายเดือนหรือไม่
  ถ้าเป็นสถานการณ์อื่น เราคงทำมิเรอร์โค้ดที่เกี่ยวกับรายได้ไว้ล่วงหน้าแล้ว แต่ดูแล้วมันไม่คุ้มจะเสี่ยงทำทางลัดแบบกองโจรขนาดนั้น
  อยากจะโทษ The Synergy Mandate ได้ใน postmortem อันใกล้นี้เหมือนกัน แต่ลึกๆ ก็รู้ดีว่าในความเป็นจริงคงไม่มีทาง
  ได้แต่หวังว่าจะยังทำเป้ารายได้ได้ต่อไป และโปรดักต์จะไม่โดนตัดเพราะผลงานต่ำกว่าเป้า
  พอเขียนแบบนี้ออกมา ยิ่งทำให้รู้สึกว่าตอนผมเข้าทำงานใหม่ๆ กับตอนนี้ งานมันเปลี่ยนไปมากแค่ไหน

• อยากจะพูดกับ โปรเจ็กต์ OSS ทุกโปรเจ็กต์อีกครั้ง
  การซิงก์โค้ดข้ามหลาย forge ด้วยงาน CI ง่ายๆ นั้นทำได้ง่ายมาก และการเปิดรับอีเมลแจ้งเตือนจาก forge ที่สองก็แทบไม่มีภาระเพิ่มเลย
  อย่างน้อยก็ควรเปิดทางเลือกให้คนมีที่ไปมีส่วนร่วมนอก GitHub ได้ และสุดท้ายแล้วมันดีกับ ecosystem โดยรวมมากกว่า

  • ตัว การซิงก์โค้ด เองเป็นส่วนที่ง่ายและเล็กน้อยมาก งาน CI จริงๆ ก็แก้แค่ส่วนนั้น
    สำหรับโปรเจ็กต์ส่วนใหญ่ แม้แต่สิ่งนั้นอาจไม่ได้จำเป็นมากด้วยซ้ำ
    ของยากคือสิ่งรอบๆ โค้ด
    ทั้ง tickets กับ PR รวมถึงประวัติของสิ่งที่ปิดไปแล้ว
    ลิงก์ต่างๆ ที่อ้างถึงโปรเจ็กต์
    การตั้งค่า CI
    ถ้าเป็นโปรเจ็กต์ใหญ่ก็รวมถึงการจัดสิทธิ์ committer
    ถ้าจำเป็นก็ต้องย้ายกฎเรื่อง push/commit/branch ทั้งหมดด้วย
    พวกนี้ย้ายทีละโปรเจ็กต์แล้วน่าปวดหัวมาก และบางอย่างอาจหายไประหว่างทาง
    แต่ปัญหาที่ใหญ่กว่าคือการสูญเสีย แพลตฟอร์มหลักสำหรับการค้นหาซอฟต์แวร์
    ไม่รู้เมื่อไรจะมี fediverse สำหรับโลกซอฟต์แวร์เสียที
  • การซิงก์เป็นเรื่องเล็ก แต่หัวใจจริงๆ คือ CI
    ทุกวันนี้ GitHub Actions ก็ยังเป็นตัวเลือกที่ดีที่สุด และไม่ว่าจะ FSF หรือแล็บ OSS ที่ไหนก็ยังให้ CI ที่ดีพอแก่ผู้ดูแลโอเพนซอร์สไม่ได้
    แถมภาระงาน CI ก็หนักขึ้นกว่าเมื่อก่อนมาก
  • การตั้ง GitLab instance เองก็อาจเป็นทางออกที่ดีได้เหมือนกัน

• ตอนนี้เริ่มรู้สึกจริงจังแล้วว่าต้องผลักดัน ทางเลือกอื่น
  มันเริ่มกระทบธุรกิจของเราจริงๆ แล้ว และก็ไม่เห็นวี่แววว่าจะดีขึ้นเลย

  • ถ้าอยากได้ UI แบบ GitHub ก็ใช้ Forgejo หรือ Gitea ได้
    แค่ต้องยอมรับข้อจำกัดของโครงสร้าง org/repo
    ถ้าอยากได้ประสบการณ์ที่คล้ายแต่ต่างออกไปนิดหน่อย GitLab ก็ตอบโจทย์
    ถ้าอยากได้แนวใกล้เคอร์เนล คือเน้นโฮสติ้งกับโครงสร้าง repository ที่ยืดหยุ่น การยืนยันตัวตนผู้ใช้ด้วย ssh key และเว็บ UI เรียบง่าย ก็ใช้ gitolite คู่กับ cgit หรือใช้ gitweb ก็ได้
  • เรา self-host Gitea กับ Drone/Woodpecker มาหลายปีแล้ว และมันทำงานได้ดีมาก
    จะเป็น Gitea หรือ Forgejo ก็เพียงพอทั้งคู่ ถ้าฟีเจอร์ที่มีตรงกับความต้องการ
    บางทีก็แวะมาอ่านเธรด GitHub ล่มแล้วขำๆ เพราะ Gitea instance ของเราตลอดหลายปีที่ผ่านมามี downtime รวมกันแค่ไม่กี่นาที และทั้งหมดก็เป็นการอัปเกรดตามแผนตอนดึก
  • น่าแปลกที่ GitLab ไม่ได้รับความสนใจมากกว่านี้
    มันอาจไม่ใช่ของก็อปที่เหมือนเป๊ะ แต่ก็ใกล้พอ และผมมองว่ามันต่างกันประมาณแอปเปิลกับลูกแพร์ มากกว่าจะเป็นส้มกับแอปเปิล
  • ผมก็คิดเหมือนกัน
    แค่ GitHub เป็น แพลตฟอร์มที่เหนียวติดมาก พอลง actions กับ integration สารพัดไปแล้ว ก็ย้ายออกยาก
    ถึงอย่างนั้นการล่มบ่อยขนาดนี้ก็เริ่มเกินจะรับไหวแล้ว
  • ตอนนี้ผม self-host Git กับ CI บน Forgejo อยู่ และพอใจมาก มันทำงานได้ดีสุดๆ

• ดูเหมือนจะไม่ใช่แค่ GitHub แต่เป็นการล่มวงกว้างกว่านั้น: https://downdetector.com

  • ตัวหารร่วมที่น่าจะใช่มากที่สุดคือ Azure

• วันนี้ก็เป็นอีกวันที่ลงท้ายด้วย y เพราะงั้นก็แปลว่า GitHub ล่ม อีกตามเคย

• ตอนนี้ Codeberg.org ก็มีปัญหาเหมือนกัน

  https://status.codeberg.org/status/codeberg

  https://social.anoxinon.de/@codebergstatus/11647770704799298...

• ถ้าไม่ชอบทั้งการที่ GitHub ล่ม และไม่ชอบให้ AI มาขโมยโค้ด ลองใช้ sourcehut ดูก็ดี
  สำหรับผมมันเหมาะมาก และก็หวังว่าในฐานะแพลตฟอร์มมันจะเติบโตยิ่งขึ้น

  • ผมชอบประสบการณ์การออกไปสำรวจ repository ใหม่ๆ เลยย้ายทั้งหมดไป Codeberg และโปรเจ็กต์ส่วนใหญ่ที่ผมสนใจก็อยู่ที่นั่น
  • ผมไม่ค่อยเข้าใจว่า sourcehut ต่างตรงไหน
    สุดท้ายแล้วมันก็เป็นแค่ บริการแบบรวมศูนย์ อีกเจ้าไม่ใช่หรือ

• รอบนี้รู้สึกว่าใช้เวลานานผิดปกติ
  ทำให้นึกถึงมุกประมาณว่าทีมที่กำลังแก้อยู่ดันชน ขีดจำกัด session ของ Claude เลยทำอะไรต่อไม่ได้จนกว่าจะหมดช่วงคูลดาวน์ และคนเดียวที่ยังแก้เองได้โดยไม่พึ่ง AI ดันไม่อยู่เพราะไปผ่าตัด
  แล้วก็อดคิดไม่ได้ว่าพอคนรุ่นที่ยังแก้เองได้โดยไม่ใช้ AI เกษียณกันหมดแล้ว หลังจากนั้นจะเป็นยังไง

• ทุกครั้งที่ GitHub ล่ม ก็จะมีคนเพิ่มขึ้นอีกนิดที่ย้ายไปหา ทางเลือกที่มีจริยธรรมกว่า และโครงสร้างที่ชุมชน FOSS ไปพึ่งพา SPOF เดียวอย่าง Microsoft ก็จะอ่อนกำลังลงทีละหน่อย

  https://sfconservancy.org/GiveUpGitHub/

  • ผมเห็นด้วยกับเจตนานั้น แต่ก็ต้องยอมรับว่าด้าน สังคม ของการที่หลายโปรเจ็กต์มารวมกันอยู่บน GitHub มีข้อดีชัดเจน
    มันทำให้การร่วมงานกันง่ายขึ้น และตอนนี้ด้วยหลายเหตุผล แรงเสียดทานก็กำลังเพิ่มขึ้น
    การใช้ issues เป็นสแปมก็มีมากขึ้น และกิจกรรมที่มุ่งร้ายยิ่งกว่านั้นก็เริ่มเห็นมากขึ้นเรื่อยๆ
  • SPOF ย่อมาจาก Single Point of Failure