Ghostty กำลังออกจาก GitHub
(mitchellh.com)- ปัญหาขัดข้องของ GitHub ที่เกิดซ้ำ รุนแรงถึงระดับที่ขัดขวางการรีวิว PR และงานประจำวันจริง ๆ ทำให้เห็นชัดถึง การพึ่งพา issues, PR และ Actions ที่ไม่สามารถแก้ได้ด้วยการมีเพียง Git repository แบบกระจายศูนย์
- ตลอดหนึ่งเดือนที่ผ่านมา ปัญหาของ GitHub กระทบการทำงานแทบทุกวัน และในวันที่เขียนบทความก็ยังเกิด ปัญหาขัดข้องของ GitHub Actions ที่ทำให้รีวิว PR ไม่ได้ราว 2 ชั่วโมง
- ขณะนี้ยังไม่ได้ตัดสินใจว่าจะย้ายไปที่ใด แต่มีแผนจะค่อย ๆ ลดการพึ่งพา GitHub ลง ขณะเดียวกันก็พิจารณาทั้ง บริการเชิงพาณิชย์ และ ผู้ให้บริการ FOSS หลายแห่ง
- จะคง มิเรอร์แบบอ่านอย่างเดียว ไว้ที่ URL ปัจจุบัน และการเปลี่ยนแปลงครั้งนี้จะมีผลกับ Ghostty ก่อนเท่านั้น โดยโปรเจกต์ส่วนตัวอื่น ๆ จะยังคงอยู่บน GitHub ไปก่อน
- การตัดสินใจครั้งนี้ไม่ได้เกิดขึ้นอย่างเร่งด่วนเพราะเหตุขัดข้องครั้งใหญ่เมื่อ 27 เมษายน 2026 แต่มีการพูดคุยกันมา หลายเดือนแล้ว และการกลับไปใช้อีกครั้งจะเกิดขึ้นได้ก็ต่อเมื่อเห็น การปรับปรุงที่เป็นรูปธรรม เท่านั้น ไม่ใช่แค่คำสัญญา
เหตุผลของการย้าย
- Ghostty ตัดสินใจออกจาก GitHub โดยมองว่า ปัญหาขัดข้อง ที่เกิดซ้ำในช่วงหลังรุนแรงถึงระดับที่ขัดขวางการทำงานจริง
- ได้มีการบันทึกแยกไว้ว่าในช่วงหนึ่งเดือนที่ผ่านมา วันใดบ้างที่ปัญหาของ GitHub ส่งผลต่อการทำงาน และระบุว่าแทบทุกวันมีปัญหาต่อเนื่อง
- ในวันที่เขียนบทความเองก็ยังไม่สามารถรีวิว PR ได้ราว 2 ชั่วโมง เพราะ GitHub Actions ขัดข้อง
- โครงสร้างประกอบอย่าง issues, PRs และ Actions คือศูนย์กลางของปัญหา และย้ำว่าการที่ Git เป็นระบบกระจายศูนย์เพียงอย่างเดียวไม่ได้ช่วยแก้ปัญหานี้
- เมื่ออยู่ในสภาพที่การทำงานถูกขัดขวางวันละหลายชั่วโมงอย่างต่อเนื่อง จึงมองว่าไม่อาจนับเป็น พื้นที่ทำงานที่จริงจัง ได้อีกต่อไป
แผนและขอบเขต
- ปลายทางการย้ายของ Ghostty ยังไม่แน่นอน และกำลังหารือกับทั้ง บริการเชิงพาณิชย์ และ ผู้ให้บริการ FOSS หลายแห่ง
- มีแผนจะ ค่อย ๆ เลิกพึ่งพา GitHub แทนที่จะตัดออกทั้งหมดในครั้งเดียว
- ที่ URL ปัจจุบันบน GitHub จะยังคงมี มิเรอร์แบบอ่านอย่างเดียว อยู่
- การเปลี่ยนแปลงครั้งนี้จะใช้กับ Ghostty ก่อนเท่านั้น ส่วนโปรเจกต์ส่วนตัวและงานอื่น ๆ จะยังคงอยู่บน GitHub ไปก่อน
- เนื่องจาก Ghostty เป็นโปรเจกต์ที่ส่งผลต่อทั้งตัวเขา ผู้ดูแลรักษา และชุมชนโอเพนซอร์สมากที่สุด จุดโฟกัสของการเปลี่ยนแปลงครั้งนี้จึงอยู่ที่โปรเจกต์นี้
บริบทเพิ่มเติม
- แม้ช่วงเวลาจะตรงกับเหตุขัดข้องครั้งใหญ่ในวันที่ 27 เมษายน 2026 แต่แผนออกจาก GitHub ถูกพูดคุยกันมา หลายเดือนแล้ว และเพิ่งตัดสินใจขั้นสุดท้ายในสัปดาห์นี้
- เนื้อหาหลักถูกเขียนขึ้นก่อนเหตุ Elasticsearch ขัดข้องครั้งใหญ่ และเหตุขัดข้องในวันนั้นที่กล่าวถึงในบทความก็เป็น เหตุขัดข้องอีกเหตุหนึ่งที่แยกจากกัน
- หาก GitHub ปรับปรุงได้จริง ก็อาจกลับไปใช้อีกครั้งในอนาคตได้ แต่เงื่อนไขในการกลับไปจะต้องเป็น ผลลัพธ์และการปรับปรุงที่เป็นรูปธรรม ไม่ใช่เพียงคำพูดหรือคำมั่นสัญญา
3 ความคิดเห็น
คนที่ย้ายไปที่อื่นอยู่แล้ว (เช่น Codeberg) พอเห็นเหตุการณ์ครั้งนี้ก็คงยิ่งมั่นใจขึ้นว่าตัดสินใจย้ายได้ถูกแล้ว
Mitchell Hashimoto เขียนไว้ในคอมเมนต์บน HN ด้วยว่าถึงกับน้ำตาไหลจริง ๆ พอไปดูก็เลยเห็นว่า
https://x.com/mitchellh/status/2049213597419774026
เขาเป็นผู้ใช้ GitHub หมายเลข 1299 และสมัครตั้งแต่เดือนกุมภาพันธ์ 2008 เลยครับ
ช่วงนี้ดูเหมือน GitHub จะมีปัญหาเยอะพอสมควรนะครับ ไม่กี่ชั่วโมงก่อนก็ยังมีโพสต์ ขณะนี้ GitHub กำลังเกิดเหตุขัดข้อง ขึ้นมาด้วย
ความคิดเห็นจาก Hacker News
mitchellh: ตอนเขียนโพสต์นี้ผม ร้องไห้จริงๆ และไม่ได้พูดเกินจริง
GitHub ไม่ได้เป็นแค่ SaaS สำหรับผม แต่มันมีความหมายมากกว่านั้นมาก เลยทำให้ความผูกพันมันลึกจนออกจะไม่ค่อยเฮลตี้นัก
คุยกันเป็นพักๆ มาหลายเดือน แล้วช่วงไม่กี่สัปดาห์ที่ผ่านมาเพิ่งคุยกันอย่างจริงจัง ตัดสินใจกันสุดท้ายเมื่อไม่กี่วันก่อน แต่พอผมโพสต์ออกไปเอง มันถึงได้รู้สึกจริงขึ้นมามาก
บางคนอาจหัวเราะเยาะ แต่ผม แคร์ GitHub มากจริงๆ และหวังว่ามันจะกลับไปอยู่ในทางของตัวเองได้อีกครั้ง
ผมเป็น GitHub User 22723 พอคิดว่าตอนนี้มีบัญชีอยู่ราว 180 ล้านบัญชี ก็แทบจะเรียกได้ว่าอยู่มาด้วยกันตั้งแต่ยุคเดียวกัน
ถ้าพูดในแบบของผม GitHub จะดีขึ้นได้ก็ต่อเมื่อ คนที่ยังแคร์มันอยู่เลือกจะอยู่ต่อ และช่วยกันทำให้มันดีขึ้น
ตอนผมเลิกใช้ Heroku เมื่อราว 6 ปีก่อน ทั้งที่ใช้มาเกือบ 10 ปีอย่างพอใจ ผมไม่เคยเปิดแดชบอร์ดอีกเลย และสุดท้ายก็รู้สึกว่า Salesforce ทำมันพังจริงๆ
แต่กับ GitHub ผมเหมือนจะตัดไม่ขาดแบบนั้น
มันมีส่วนที่เละจากการต้องเจอกับ agentic coding และการเติบโตแบบระเบิดพร้อมกันก็จริง แต่ก็ดูไม่ใช่หายนะแบบ Heroku/Salesforce
แทนที่จะอธิบายว่าเป็นเพราะ AI coding มากขึ้นหรือเพราะ Microsoft ชั่วร้ายอย่างเดียว ดูน่าเชื่อกว่าว่ามันเกิดจากสเกลและภูมิประเทศใต้เท้านักพัฒนาที่เปลี่ยนไปเอง
หวังว่ามันจะทำได้ดีจนทำให้อยากกลับไปอีกครั้ง และการมีความรู้สึกแรงๆ กับสิ่งที่อยู่ใจกลางชีวิตนักพัฒนาไม่ใช่เรื่องโง่เลย
ความรู้สึกแบบ อยากทำงานแต่โดนขัดขวาง อยาก deploy ซอฟต์แวร์แต่เหมือนบริการไม่ต้องการให้ทำ โดยเฉพาะอันนี้โดนมาก
ความรู้สึกแบบนี้ไม่ได้มีแค่กับ GitHub ทุกวันนี้เหมือนเว็บโดยรวมกำลังแย่ลงและคุณภาพต่ำลง
มี outage ตลอดเวลา มีบั๊ก มี UI ที่กวนใจ มีฟีเจอร์ไม่เสร็จเต็มไปหมด จนไม่รู้ว่าเกิดอะไรขึ้นกันแน่
ขอบคุณที่ทำ ergonomic software สำหรับมนุษย์จริงๆ
คือมันเป็นอุปมาว่า ของที่คนอื่นมองว่าไร้ค่า สำหรับเจ้าของกลับเต็มไปด้วยความรักและความทรงจำที่สะสมมานาน
https://knowyourmeme.com/memes/spool-of-wire-guy
ในชีวิตเรามีสิ่งที่ชอบและรักอยู่ และถ้าฝั่งที่เราเชียร์มันแย่ลง ก็เป็นธรรมดาที่จะเสียใจ
ผมเองก็ไม่หัวเราะเยาะเรื่องแบบนี้ และจะโกรธด้วยซ้ำถ้าใครมาหัวเราะ
แต่ถ้าจะบอกว่า GitHub จะหาทางกลับมาได้ไหม พูดตรงๆ ว่าผม ไม่ได้มองโลกในแง่ดีนัก
ค่อนข้างน่าตกใจที่ได้เห็น GitHub พังทลายในระดับองค์กร
จะอธิบายด้วยการถูกรวมเข้า Microsoft การย้ายทรัพยากรไปทาง Copilot โครงสร้างองค์กร หรือ vibe coding ก็ได้ แต่ไม่ว่าจะด้วยเหตุผลไหน ก็ยากจะปฏิเสธว่ามีปัญหาร้ายแรงอยู่จริง
บันทึกที่หน้า status แบบไม่เป็นทางการแสดงไว้ก็ค่อนข้างสยดสยอง
ผมก็อยากฟังมุมมองจากคนในเหมือนกัน แต่ตอนนี้มันดูเหมือน เรือที่กำลังจมแต่ยังลอยต่อได้ด้วยแรงเฉื่อย และในช่วงที่วงการซอฟต์แวร์ทั้งอุตสาหกรรมกำลังสั่นคลอน แรงเฉื่อยอย่างเดียวคงไม่พอ
มันถูกบริหารแบบที่บริการจำนวนมากมักเจอหลังถูกซื้อโดยบริษัทใหญ่
ตอนแรกยังโอเค แล้วค่อยๆ แย่ลง สุดท้ายก็พัง และทุกอย่างกลายเป็น เกมตัวเลข
Microsoft, Oracle, VMware, CA, Salesforce ก็มีเคสคล้ายๆ กันมากมาย และทีมที่จัดการ M&A ได้ดีจริงๆ มีน้อยมาก
https://onlineornot.com/uptime-calculator/87.25
ถ้าโตเกินไปโดยไม่มีผู้นำที่เหมาะสม สุดท้ายมันก็พังอยู่ดี
ตัวเลขจริงจากความรู้สึกน่าจะแย่กว่านี้อีก
ก่อนถูกซื้อ GitHub เองก็เคยมีช่วงที่เหมือนต้องโยนเหรียญดูว่าวันนี้เว็บจะทำงานได้ดีไหม
มันสำเร็จเพราะอยู่ถูกที่ถูกเวลา แต่โดยเนื้อแท้ก็เป็นระบบที่ปะติดปะต่อแบบลวกๆ อยู่แล้ว
ผมเข้าใจถึง ความรักอย่างจริงใจ ที่ Hashimoto มีต่อ GitHub และโลกโอเพนซอร์ส
แต่ผมก็คิดว่าถ้ามีท่าทีแบบ Richard Stallman ที่มองว่าซอฟต์แวร์ไม่เสรีนั้นน่ากังขาและไร้จริยธรรมโดยเนื้อแท้เพิ่มมาอีกหน่อย ความเจ็บปวดแบบนี้อาจน้อยลง
GitHub ไม่ว่าจะในปี 2008 หรือวันนี้ ก็เป็นซอฟต์แวร์ไม่เสรีที่รันบนเซิร์ฟเวอร์ของคนอื่น ภายใต้กติกาของคนอื่น และสุดท้ายถูกเดินเกมเพื่อผลประโยชน์ของเจ้าของ
ผมเองก็ใช้มานาน และหลายครั้งก็ต้องใช้เพราะงาน แต่ไม่เคยผูกพันทางอารมณ์กับมัน
ทั้งที่มันถูกสร้างอยู่บน git ซึ่งเป็น free-software แต่โครงสร้างกลับพยายามผูกผู้ใช้ติดกับแพลตฟอร์มอยู่เสมอ นั่นเป็นสิ่งที่ขัดใจผมมาตลอด
ผมคงรักซอฟต์แวร์ที่ต้องมีบัญชีอีเมล ต้องกดยอมรับข้อกำหนด และใช้ไม่ได้ในอิหร่านเพราะกฎหมายคว่ำบาตรของสหรัฐไม่ได้หรอก
เพราะงั้นการที่ ghostty ออกจาก GitHub เลยเป็นเรื่องที่ผมยินดีอย่างไม่มีความลังเล
ฝั่ง KDE แทบไม่เคยพิจารณา GitHub อย่างจริงจัง เราดูแล git infra ของตัวเอง และต่อมาก็ร่วมมือกับ Gnome และ GitLab เพื่อผลักฟีเจอร์ Enterprise Edition ที่จำเป็นจริงๆ บางส่วนลงมาอยู่ใน Community edition
ตลอด 16 ปีที่ผ่านมา ผมจำได้ว่ามี git outage ระดับหลายชั่วโมงอยู่ครั้งเดียวเอง
แค่ดูว่ามันคุ้มค่ากับเวลาและเงินของผมหรือไม่
มันอาจทำให้เปลืองอารมณ์ได้เหมือนเวลาพูดถึง Netflix ขึ้นราคา หรือเรื่องเกม แต่ถ้าไม่คุ้มก็แค่ย้ายออก
แน่นอนว่าผมเข้าใจได้ถ้ามันมีสายใยทางอารมณ์แบบความทรงจำในยุคคอมพิวเตอร์ยุคแรกๆ
ผมเริ่มรู้สึกว่าการ ฝัง issue tracker ไว้ใน git repo เองมันสมเหตุสมผลขึ้นเรื่อยๆ
ผมมองว่าความเจ็บปวดแบบนี้เกิดจากการไม่ยอมมองปัญหาของ closed source software ให้สุดทาง
หลังจากขาย Hashicorp ไป ความเคารพที่ผมมีให้ก็ลดลงมาก
ก่อนหน้านี้ในเธรดบน X ที่ Mitchell วิจารณ์ GitHub ผมเห็นมีคนตอบว่า GitHub ควร ดึงเขาไปเป็น CEO ซึ่งก็รู้สึกว่ามีเหตุผลไม่น้อย
ผู้นำที่จะพลิกเรือลำนี้ได้ต้องไม่ใช่แค่ผู้จัดการ แต่ต้องเป็นคนที่มีทั้งความเชื่อมั่นแรงกล้า ความสามารถในการลงมือทำ และพลังดึงดูดคนเก่ง
ผมคิดว่าสุดท้ายแล้วจะมี GitHub ใหม่เกิดขึ้น และถ้าจังหวะลงตัวก็อาจโตเร็วได้ เหมือนที่ OpenClaw หรือ GitHub ยุคก่อนเคยทำในสมัย SVN·SourceForge
ดูเหมือนตอนนี้ก็มีความพยายามหลายแบบที่กำลังชิงตำแหน่งนั้นอยู่แล้ว
ทั้งอย่างนั้น ถ้ามองจากบริการหลัก ผมก็ยังรู้สึกว่ายังไม่มี UI ที่ดี โดยเฉพาะสำหรับโปรเจ็กต์ที่ซับซ้อน
ส่วน jujutsu แม้ทิศทางพื้นฐานจะดูดีมาก แต่ก็ยังไม่มี forge ที่ดีพอ
โค้ด วิกิ และ issue ถูกจัดการแบบกระจายอยู่ในเครื่องมือเดียวกันแทบทั้งหมด
ถ้า AI มาแทนการพัฒนาซอฟต์แวร์ได้จริงแบบที่ผู้บริหารบิ๊กเทคอยากให้เป็น มันอาจกลับมาสอดคล้องกันอีกครั้ง แต่ตอนนี้คนต้องการ git remote ที่เสถียร ขณะที่ของจริงกลับเป็นโฮสต์ที่ไม่เสถียรปนฟีเจอร์ vibe coding ครึ่งๆ กลางๆ
เหตุผลใหญ่ที่สุดที่ทุกคนไปรวมกันที่ GitHub คือ ต่อให้ forge แบบ self-hosted แต่ละแห่งไม่เปิดให้สมัครสมาชิก ก็ยังทำงานร่วมกันผ่าน issue และ PR ได้ง่าย ซึ่งเรื่องนั้นแก้ได้โดยไม่จำเป็นต้องเอาโค้ดทั้งหมดไปกองไว้บนโครงสร้างพื้นฐานเดียวที่กำลังเสื่อมสลาย
อาจเป็นเรื่องยากที่จะเกิดขึ้นจริง แต่ถ้าเกิดได้ก็คงดีมาก
ผมค่อนข้างอยากรู้ว่าอีก 5 ปีข้างหน้า ecosystem นักพัฒนาจะเปลี่ยนไปอย่างไร และ GitHub จะมีหน้าตาแบบไหนในอีก 5 ปี
ผมแทบไม่ค่อยเปิดเว็บ GitHub แล้ว และใช้ github cli เยอะมาก
แค่ gh ก็ทำสิ่งที่ต้องการได้เกือบหมด Actions ก็รันอยู่บน GitHub แล้ว agent ก็มาดึงผลลัพธ์ ไปดู issue แล้วแก้โค้ด ทำให้ทั้ง workflow เปลี่ยนไปแล้วจริงๆ
ถ้ามีคนจำนวนมากเห็นตรงกันว่า GitHub ไม่ใช่ที่ที่สนุกอีกต่อไป และให้ความรู้สึกเหมือนขัดขวางจนทำงานหรือ deploy อะไรไม่ได้ Redmond ก็ควรต้องตอบสนองอย่างจริงจัง
ถ้าความรู้สึกนี้แพร่กระจายเป็นวงกว้างจริง มันอาจเป็นเรื่องร้ายแรงมากสำหรับ Microsoft
เมื่อ 8 ปีก่อนบริษัทจ่ายเกือบ 8 พันล้านดอลลาร์เพื่อยึดนักพัฒนาเป็นเสาหลัก และยังจ่ายอีก 2 พันล้านดอลลาร์ซื้อ Minecraft เพื่อผูกฐานนักพัฒนารุ่นเยาว์ไว้ด้วย
ตอนนี้พวกเขาเสียทั้ง OS และเซิร์ฟเวอร์ไปแล้ว ถ้ายังเสียนักพัฒนาอีก ก็อาจลงเอยคล้าย Xerox แห่งศตวรรษที่ 21
Microsoft อาจไม่ได้เหนือชั้นมากในเกม มือถือ หรือ AI หรืออาจแพ้ได้ด้วยซ้ำ แต่ก็ยังยึดคนทำงานออฟฟิศสาย white-collar ทั่วไปจำนวนมหาศาลไว้ได้ ตราบใดที่ยังมี Word กับ Excel
มีผู้คนมากเกินไปที่ไม่สนใจเทคโนโลยีแต่ถูกผูกไว้กับ Office
แค่ความจริงที่ว่า Claude หนึ่งในทักษะใช้งานจริงชุดแรกที่เรียนรู้ได้ดีคือการเขียน .docx ก็สะท้อนเรื่องนั้นแล้ว
ปัญหาไม่ใช่ Git เอง แต่เป็นโครงสร้างพื้นฐานอย่าง issue, PR, Actions ที่ครอบอยู่ด้านบน
ถ้าจะเสนอแนะ ต่อให้ย้ายไป forge อื่นก็ควรใช้ git-bug ควบคู่ไปด้วย
มันเก็บ issue, PR ฯลฯ ลงใน git เองผ่าน ref พิเศษแทนที่จะเก็บใน branch และยังซิงก์สองทางกับผู้ให้บริการหลายรายได้ด้วย
VCS อื่นอย่าง fossil ก็เก็บ issue ไปพร้อมกับ repo เช่นกัน และผมคิดว่านั่นสมเหตุสมผล เพราะ issue ก็เป็นส่วนหนึ่งที่ให้ความหมายกับโค้ด เหมือนเอกสารนั่นเอง
ถ้าทุกอย่างอยู่ใน repo มันก็สะดวกจริง
แต่ตอนนี้พอมี LLM coding agent ที่แทบไม่มีข้อจำกัดเข้ามาจัดการทุกอย่างร่วมกัน การล็อกขอบเขตการเข้าถึงก็ยิ่งยากขึ้น
อย่างหลังผมเข้าใจว่ากำลังทำอยู่ในทิศทางอย่าง web UI แต่ก่อนจะถึงจุดนั้น ถ้าอยากให้ผู้ใช้ทั่วไปเปิด issue ได้ ก็สุดท้ายยังต้องมีโครงสร้างพื้นฐานสาธารณะอยู่ดี
ในโปรเจ็กต์ของผม ผมใช้มันกับ https://github.com/stryan/materia และมันดีมากสำหรับการรวมศูนย์ทั้ง repo และ issue
แต่ถ้าเป็นข้อมูลจากผู้ใช้สุ่มๆ ผมก็ยังใช้ GitHub Discussions เป็น ตัวติดตามบั๊กแบบกึ่งๆ อยู่
ถ้าเป็นบั๊กก็จะเพิ่มเข้า git-bug แล้วซิงก์กับ GitHub issues เพื่อให้มองเห็นได้สาธารณะ แต่กับบั๊กรายงานจากผู้ใช้จำนวนมาก วิธีนี้ยังไม่ค่อยเหมาะ
น่าแปลกที่ผมได้ไอเดีย workflow นี้มาจาก ghostty กับ mise เอง เพราะทั้งคู่รับบั๊กผ่าน discussion ก่อน แล้วค่อยสร้าง issue ที่ติดแท็กเมื่อมัน actionable จริง
เป็นทิปที่ดีมาก
ผมสงสัยว่าต้นเหตุที่ต้องรับผิดชอบมากที่สุดต่อการที่คุณภาพ GitHub ตกลงหนักๆ คืออะไร
มีทั้งคำอธิบายว่า โค้ดที่ AI สร้าง ทำให้คุณภาพ codebase แย่ลง และคำอธิบายว่าหลัง Microsoft เข้าซื้อก็เกิด วัฒนธรรมวิศวกรรมที่แย่ แพร่กระจาย
สองอย่างนี้อาจผสมกันอยู่บ้างก็ได้
https://news.ycombinator.com/item?id=45517173
https://github.blog/news-insights/company-news/an-update-on-github-availability/
ดูเหมือนเป็นผลลัพธ์ของการผสมกันระหว่าง วัฒนธรรมและโครงสร้างพื้นฐานของ Microsoft และตอนนี้คุณภาพก็เริ่มให้ความรู้สึกเหมือนบริการ Microsoft อื่นๆ
เพิ่มเติมคือไบนารี dotnet CLI โฮสต์ได้ไม่เสถียรมากจน CI พังบ่อย ผมเลยต้องเอาไปโฮสต์ใหม่เอง
บนหน้า Pull Request เราเห็นผลลัพธ์ไม่ครบ และก็มีเหตุการณ์ประเภทที่ข้อมูลไม่ได้หายไป แต่ระหว่างที่ Elasticsearch กำลัง reindex รายการต่างๆ ก็แสดงไม่ถูกต้องจนกว่าจะทำเสร็จ แบบนี้เกิดขึ้นจริงอยู่เรื่อยๆ
เขาบอกว่าจะมาแชร์รายละเอียดมากขึ้นในอีกไม่กี่เดือนข้างหน้าว่าจะย้ายโปรเจ็กต์ Ghostty ไปไหน ซึ่งฟังดูเหมือนรับมือกับปัญหาที่ GitHub Issues หรือ PR บางครั้งเข้าไม่ได้ในบางช่วงของวัน ด้วยการทำให้มัน เข้าไม่ได้ไปอีกหลายเดือน แทน
มันดูเป็นการตัดสินใจที่ค่อนข้างเร่งรีบทางอารมณ์อยู่บ้าง และผมไม่แน่ใจว่ามันจะดีต่อเจ้าตัว Ghostty หรือชุมชนจริงๆ
อย่างน้อยก็น่าจะเตรียม เส้นทางสำรอง เอาไว้ก่อนแล้วค่อยขยับ