ผู้ร่วมก่อตั้ง HashiCorp กล่าวว่า GitHub 'ไม่ใช่ที่สำหรับงานจริงจังอีกต่อไป'

 (theregister.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • terminal emulator ที่เพิ่มมิติใหม่ให้กับหมวดหมู่ซอฟต์แวร์ที่ทั้งรวดเร็วและสุกงอม กำลังย้ายจาก GitHub ไปยังที่เก็บโค้ดสำหรับการทำงานร่วมกันแห่งอื่น
  • Mitchell Hashimoto สมัครเป็นผู้ใช้ GitHub หมายเลข 1299 ตั้งแต่เดือนกุมภาพันธ์ 2008 และใช้งานมาแทบทุกวัน โดยครั้งหนึ่งเคยมองว่า GitHub เป็น สถานที่ที่ทำให้มีความสุขที่สุด
  • ในช่วงหนึ่งเดือนที่ผ่านมา เกือบทุกวันมีการบันทึกวันที่ ความน่าเชื่อถือของบริการลดลง ส่งผลกระทบต่องาน และแม้แต่ในวันที่เขียนบทความก็ไม่สามารถรีวิว PR ได้ราว 2 ชั่วโมงเพราะ GitHub Actions outage
  • GitHub ไม่ใช่สถานที่ที่สนุกอีกต่อไป และหลังใช้งานมา 18 ปี เขาตัดสินใจจะจากไป แต่ยังเปิดโอกาสที่จะกลับมาหากมี real results and improvements
  • การย้าย Ghostty กำลังดำเนินแบบ incremental โดยหารือกับทั้งผู้ให้บริการเชิงพาณิชย์และ FOSS หลายราย และจะคง read-only mirror ไว้บน GitHub

ภูมิหลังการใช้ Ghostty และ GitHub

  • โปรเจ็กต์หลักในปัจจุบันคือ Ghostty ซึ่งเป็น terminal emulator ที่เติม “interesting new wrinkles” ให้กับหมวดหมู่ซอฟต์แวร์ที่ทั้งรวดเร็วและสุกงอม
  • การพัฒนา Ghostty ใช้ GitHub มาโดยตลอด และ Mitchell Hashimoto สมัครเป็นผู้ใช้ GitHub หมายเลข 1299 ตั้งแต่เดือนกุมภาพันธ์ 2008 ก่อนจะใช้งานมาแทบทุกวัน
  • GitHub เคยเป็น “สถานที่ที่ทำให้มีความสุขที่สุด” และเป็นบริการที่เขาผูกพันมานานถึงขั้นยังหาเวลาใช้ระหว่างฮันนีมูน
  • แทนที่จะ doom scrolling บนโซเชียลมีเดีย เขามักเปิดดู GitHub issues มานานแล้ว และแม้ในช่วงวันหยุดก็ยังศึกษาซอร์สโค้ด กระบวนการ OSS และการตอบสนองของ maintainer ในโปรเจ็กต์บน GitHub

ปัญหาขัดข้องที่ขวางงานทุกวัน

  • ช่วงหลังความรู้สึกที่มีต่อ GitHub เปลี่ยนไปมาก และกลายเป็นสภาวะที่ GitHub ทำให้เขาล้มเหลวทุกวัน โดยปัญหานั้นให้ความรู้สึกกระทบในระดับส่วนตัว
  • สาเหตุหลักคือ ความน่าเชื่อถือของบริการลดลง โดยในช่วงเดือนที่ผ่านมา ทุกวันที่ GitHub ขัดข้องและส่งผลลบต่อความสามารถในการทำงาน จะถูกทำเครื่องหมาย “X” ไว้ในบันทึกประจำวัน
  • ในบันทึกนั้นมี “X” เกือบทุกวัน และแม้แต่ในวันที่เขียนบทความ ก็ยังรีวิว PR ไม่ได้ราว 2 ชั่วโมงเพราะ GitHub Actions outage
  • บทความดังกล่าวถูกเขียนขึ้นไม่กี่วันก่อน incident วันที่ 28 เมษายน ซึ่ง pull request ไม่สามารถเสร็จสมบูรณ์ได้เพราะ Elasticsearch SNAFU
  • หากปัญหาขัดข้องแบบนี้ขวางการทำงานวันละหลายชั่วโมง GitHub ก็ไม่ใช่ที่สำหรับ “serious work” อีกต่อไป

เวิร์กโฟลว์การพัฒนาและการตัดขาดทางอารมณ์

  • GitHub ไม่ใช่สถานที่ที่สนุกอีกต่อไป และกลายเป็นสิ่งที่ขัดขวางการปล่อยซอฟต์แวร์ ดังประโยค “I want to ship software and it doesn't want me to ship software”
  • เขาหวังว่า GitHub จะดีขึ้น แต่ในขณะเดียวกันก็ยังต้องเขียนโค้ด และอยู่ในสภาพที่ไม่สามารถเขียนโค้ดบน GitHub ต่อไปได้อีกแล้ว
  • หลังใช้งานมา 18 ปี เขาจึงสรุปว่าต้องจากไป แม้ยังเปิดโอกาสสำหรับการกลับมาหากมี real results and improvements
  • เงื่อนไขของการกลับไปใช้ GitHub ไม่ใช่แค่คำพูดหรือคำสัญญา แต่ต้องเป็นผลลัพธ์และการปรับปรุงที่เกิดขึ้นจริง

วิธีการย้าย Ghostty

  • Ghostty กำลังอยู่ระหว่างการย้ายไปยัง collaborative code locker แห่งอื่น
  • ขณะนี้มีการหารือกับผู้ให้บริการหลายราย ซึ่งรวมทั้งผู้ให้บริการเชิงพาณิชย์และผู้ให้บริการ FOSS
  • การถอดการพึ่งพา GitHub ออกทั้งหมดต้องใช้เวลา และมีแผนจะดำเนินการแบบ incremental ให้มากที่สุด
  • บน GitHub จะยังคงมี read-only mirror ของ Ghostty ไว้ และโปรเจ็กต์ส่วนตัวของเขาก็ยังจะอยู่บนบริการของ Microsoft ต่อไป
  • Ghostty เป็นโปรเจ็กต์ที่ส่งผลกระทบต่อเขาเอง, maintainer และ open source community มากที่สุด จึงเป็นจุดโฟกัสของการเปลี่ยนแปลงครั้งนี้

สถานะของ GitHub และบริบทของ Microsoft

  • หลัง Microsoft เข้าซื้อ GitHub เคยมีความกังวลว่ามันจะกลายเป็นบริการที่มี Redmond เป็นศูนย์กลางมากขึ้น และสะดวกน้อยลงสำหรับนักพัฒนาที่ไม่ได้อยู่ในระบบนิเวศ Windows หรือ Azure
  • ความกังวลนั้นส่วนใหญ่ไม่ได้กลายเป็นจริง และ GitHub ก็ได้กลายเป็น de facto place สำหรับการทำงานและแชร์โค้ด
  • ประสบการณ์ของ Hashimoto แสดงให้เห็นว่าสถานะนั้นอาจสั่นคลอนได้ และยังเกิดขึ้นในช่วงเวลาใกล้เคียงกับที่ Microsoft ยอมรับว่า Windows has serious quality problems
  • หนึ่งในสาเหตุของปัญหาคุณภาพ Windows คือการยัด AI เข้าไปในเครื่องมือมากเกินไป และการสั่นคลอนของ GitHub ที่ Hashimoto สังเกตเห็นก็เกิดขึ้นในช่วงเวลาเดียวกับความหมกมุ่นเรื่อง AI ของ Microsoft

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

  • หงุดหงิดมากที่เสถียรภาพของ GitHub พังลงพอดีกับจังหวะที่บริษัทกำลังย้ายทุกอย่างจาก CircleCI ไป GitHub Actions
    ที่น่าขำที่สุดคือกลายเป็นว่าแม้แต่ Azure Repos/Pipelines ยังดีกว่านี้
    เคยได้ยินเหมือนกันว่า GitHub อาจอยู่ในสภาพครึ่งๆ กลางๆ เพราะยังย้ายไป Azure infrastructure ไม่เสร็จ แต่ก็ไม่ได้ทำให้เชื่อมั่นขึ้นเลย

    • GitHub อ้างว่าทราฟฟิกเพิ่มขึ้นมากเพราะโปรเจกต์ vibe coding
      อาจเป็นข้ออ้างก็ได้ แต่ฟังดูมีเหตุผลพอสมควร
    • เมื่อ 2 สัปดาห์ก่อน ฉันได้รับมอบหมายให้ประเมินการย้ายจาก self-hosted GitLab ไป GitHub เพื่อให้ผสาน AI ได้ดีกว่า แต่เมื่อคืนโปรเจกต์นั้นโดนยกเลิกเพราะ GitHub ล่ม และเปลี่ยนไปอัปเกรดเซิร์ฟเวอร์ที่โฮสต์เองแทน
      อยากใช้พวก Forgejo เหมือนกัน แต่ทีมนักพัฒนามีราว 12 คน และพูดตรงๆ คือมีแค่ฉันคนเดียวที่เคยใช้มัน
    • Azure Repos ค่อนข้างโอเค
      มันพื้นฐานมากจนแทบไม่มีอะไรให้พัง และด้วยเหตุผลเดียวกันฉันก็ชอบระบบ ticket ของมันมาก
      มีแต่ฟีเจอร์ที่จำเป็น และผู้จัดการก็ไม่สามารถเพิ่มฟิลด์เป็นล้านช่องเพื่อเอาไว้ทำรีพอร์ตหรือ burndown chart มากดดันคนอื่นได้
    • ไม่จำเป็นต้องติดกับดัก sunk cost fallacy การย้ายระบบยกเลิกได้
    • อาจเป็นแค่การโยงเรื่องที่ไม่เกี่ยวกันเข้าด้วยกันก็ได้ แต่พอเห็นคำว่า การย้ายไป Azure ก็ทำให้นึกถึงอันนี้
      https://news.ycombinator.com/item?id=47616242
      https://isolveproblems.substack.com/p/how-microsoft-vaporize...

  • GitLab ก็ไม่ได้ดีกว่าเท่าไร
    ดูเหมือนจะมีงบไม่จำกัดสำหรับการแก้ UI งี่เง่าที่แทบไม่ช่วยอะไรจริงเลย ขณะที่บั๊กหนักๆ ในรีลีสกลับถูกมองข้าม

    • น่าเสียดายจริงๆ
      ตอนเริ่มใช้ GitLab ครั้งแรกราว 8~9 ปีก่อน ฉันชอบมันมาก และอีกไม่กี่ปีต่อมาพอบริษัทเปลี่ยนไป GitHub ก็รู้สึกเหมือนถอยหลังครั้งใหญ่
      GitLab มี ความสะดวกด้าน UX เล็กๆ น้อยๆ เยอะมาก และถึงจะมีส่วนที่ยังหยาบอยู่บ้าง แต่โดยรวมก็ดูเหมือนออกแบบมาดี
      แต่หลังจากนั้นสถานการณ์กลับแย่ลงมาก UX ถูกเปลี่ยนจนแทบนับไม่ถ้วน และทุกครั้งที่เปลี่ยนก็ดูเหมือนจะแย่ลง
      ส่วนที่หยาบก็ไม่เคยถูกแก้ มีแต่ส่วนหยาบใหม่ๆ เพิ่มเข้ามาเรื่อยๆ
      ช่วงไม่กี่ปีมานี้นึกไม่ออกเลยว่ามีฟีเจอร์อะไรที่เพิ่มเข้ามาหรือถูกปรับปรุงแล้วมีประโยชน์จริงๆ และในเมื่อ GitHub ก็เละพอๆ กัน ก็ยิ่งน่าเสียดายที่ GitLab ไม่กลายเป็นทางเลือกที่ดีกว่าอย่างชัดเจนแล้วชิงตลาดไป
    • ที่แย่กว่านั้นคือ ในเวอร์ชัน self-hosted มีอัปเดตหนึ่งที่ ทำให้ migration พังแต่ไม่แจ้ง error ทำให้ระบบติดตั้งเสียแบบแปลกๆ และละเอียดอ่อน
      ฉันงมหาสาเหตุอยู่หลายวันโดยไม่รู้ว่าเกิดอะไรขึ้น กว่าจะมีคำเตือนออกมาในอัปเดตถัดไป แล้วค่อยรัน repair command เพื่อจัดการให้กลับมาเรียบร้อย
      เป็นเซิร์ฟเวอร์เล็กมาก มีผู้ใช้ประมาณ 10 คน และรีโปไม่เกิน 50 อัน
    • ตอนกำลังอัปเดต SSH key ของหลายบัญชี ฉันหมดความอดทนกับ GitLab ไปเลย
      GitHub, Bitbucket, Codeberg และเจ้าอื่นๆ ใช้งานได้ดี แต่ GitLab มีบั๊กเยอะมาก และบน Firefox นั้นอัปเดต SSH key ไม่ได้เลย โดยไม่มีข้อความชัดเจนด้วยซ้ำว่าเป็นบั๊กความเข้ากันได้ระหว่าง GitLab กับ Firefox
      ฉันเสียเวลาเกือบชั่วโมงกว่าจะนึกได้ว่าควรลองอัปโหลด SSH key ใหม่ด้วย Chrome แล้วหลังจากนั้นก็คิดว่า GitLab น่าจะไม่แตะอีกแล้ว

  • ตอนนี้ Ghostty กลายเป็นโปรเจกต์ล่าสุดที่ออกจาก GitHub ก็เลยสงสัยว่ารายต่อไปจะเป็นใคร
    ฉันไม่ได้คิดว่าทุกคนจะย้ายออกจาก GitHub ภายในวันพุธหน้าแล้วไปเปิด Forgejo server ของตัวเองหรอก แต่แค่คนเริ่มพิจารณาเรื่องการออกจาก GitHub อย่างจริงจังก็น่าจะเป็นสิ่งที่ GitHub ต้องกังวลแล้ว

    • แรงเฉื่อยจากการยึดติดกับของเดิม ตรงนี้หนักมากแบบเหลือเชื่อ
      วิศวกรซอฟต์แวร์ทั่วไปแทบไม่ได้สนใจ VCS หรือ forge เลย และความรู้เกี่ยวกับสองเรื่องนี้ก็ตื้นมาก
      สำหรับคนที่แค่อยากทำงานแล้วกลับไปใช้ชีวิตของตัวเอง มันไม่ใช่เรื่องสำคัญมากนัก
    • ฉันตามกระแสช่วงนี้ไม่ค่อยทัน ทำไมคนถึง ย้ายออกจาก GitHub กัน?
    • มีคนบน HN ทำ who-left-gh.net อะไรแบบนี้ไปแล้วหรือยัง? โดเมนยังว่างอยู่

  • มีแค่ฉันหรือเปล่าที่รู้สึกว่าหลัง MSFT เข้าซื้อกิจการ แล้วปัญหาต่างๆ แย่ลงมาก?

    • การเข้าซื้อกิจการไม่ได้เกิดขึ้นเมื่อปีที่แล้วนะ แต่เกิดเมื่อ 8 ปีก่อน
      ตลอดเวลานั้นมันโตขึ้นแค่ไหนแล้ว? 10 เท่า? 100 เท่า? หรือมากกว่านั้น?
    • เรื่องแบบนี้เกิดขึ้นได้หลายครั้งในกระบวนการควบรวมกิจการ
      เวลาบริษัทหนึ่งซื้ออะไรสักอย่าง ปัญหาถัดมาก็คือใครกันแน่ที่เป็นเจ้าของมัน
      ประเด็นสำคัญคือในบริษัทใหม่ ใครจะรับผิดชอบเรื่อง “รักษาให้มันยังดีอยู่” และถึงแม้คนเดิมที่เคยทำหน้าที่นั้นจะยังอยู่หลังการซื้อกิจการ ปัญหาเรื่องแรงจูงใจก็เป็นอีกเรื่องหนึ่ง
      Microsoft มีปัญหาร้ายแรงตรงนี้
      มันดูเหมือนมีช่องโหว่แบบบริษัทอย่างน้อย 10 แห่งถูกเอากาวแปะรวมกันแล้วเรียกว่า Microsoft และยังมี ความเสี่ยงด้านชื่อเสียง สูงด้วย เช่น ปัญหาของฝั่ง Xbox อาจกระทบเครื่องมือฝั่งนักพัฒนา หรือกลับกัน
      หลายอย่างขาดการโฟกัส และหลังจากเลิกประกาศข่าวสวยหรู ก็ควรมีช่วงเวลาแบบ “service pack 2” เพื่อไปแก้ หนี้ทางเทคนิค กองมหึมานี้เสียที
    • ดูเหมือนเรื่องนี้จะเกี่ยวกับ vibe coding มากกว่า
    • ใช่ แน่นอน และช่วงหลังมานี้ก็น่าจะใช่ภายใต้องค์กร CoreAI ใหม่ด้วย: https://www.businessinsider.com/microsoft-ai-coding-rivals-o...
    • ผ่านไปกี่สิบปี นโยบายก็ยังเหมือนเดิม
      Embrace, extend, and extinguish

  • เขาบอกว่า “GitHub user 1299, สมัครเมื่อกุมภาพันธ์ 2008” แล้วคนทั่วไปจะรู้ได้ยังไงว่าตัวเองเป็น GitHub user # เท่าไร?

    • รัน curl [https://api.github.com/users/YOUR_USER_HERE](<https://api.github.com/users/YOUR_USER_HERE>;) แล้วดู id ใน payload ก็ได้
      "id": 2851
      หรือดูจาก HTML source ของ avatar ก็ได้: https://avatars.githubusercontent.com/u/2851?v=4
    • ของฉันอยู่ช่วงหลักแสนตอนปลาย
      พูดตามตรงนึกว่าอย่างน้อยคงหลักล้านแล้ว
    • ถ้าเปิดรูปในโปรไฟล์ในแท็บใหม่ URL จะเป็นรูปแบบ /u/#
      ของฉันอยู่ประมาณหลัก 4 ล้าน
    • ถ้าดึงข้อมูลผู้ใช้ของตัวเอง ก็จะเห็นใน API response

  • ถ้าดูจากสถิติกิจกรรมผู้ใช้ที่สะสมมาราว 20 ปีที่ผ่านมา ฉันมั่นใจว่าตัวเองน่าจะเป็นผู้ใช้ระดับ top 1% หรือใกล้เคียง ในแง่ของปริมาณงานที่ทำต่อเนื่องยาวนานและการเขียนซอฟต์แวร์ทุกวันที่คนอื่นใช้งานจริง
    ฉันก็เป็นผู้ใช้ GitHub ค่อนข้างยุคแรกๆ เหมือนกัน แม้จะไม่ใช่ยุคบุกเบิกสุดๆ และถึงตัวชี้วัดของ GitHub จะแย่ลง ฉันก็ยังส่งของออกไปได้อยู่
    เพราะ การเขียนซอฟต์แวร์ไม่ได้ต้องพึ่ง GitHub
    คอมเมนต์ของ Hashimoto ดูเหมือนมีความไม่มั่นคงทางอารมณ์ และหวังว่าเขาจะพบความสงบ แต่ถ้าคนพูดไม่ใช่เขา ฉันก็คงอ่านแล้วคิดว่ามีบางอย่างผิดปกติ และจึงคิดว่ามันก็เป็นแบบนั้นจริงๆ

    • ฟังดูเหมือนพูดว่า “ฉันไม่ใช้ ฟีเจอร์ที่ไม่ใช่ git ของ GitHub เลย ดังนั้นคนที่ใช้มีปัญหาเอง”
    • การบอกว่า “การเขียนซอฟต์แวร์ไม่ได้ต้องพึ่ง GitHub” ถ้าหมายถึง workflow ที่ไม่ต้องใช้ฟีเจอร์ซึ่งมีปัญหาด้านความน่าเชื่อถือในช่วงหลัง หรือแม้แต่ฟีเจอร์พื้นฐานด้านการทำงานร่วมกันบางอย่าง ก็ทำให้น่าสงสัยว่า GitHub เคยเป็นเครื่องมือที่เหมาะกับงานนั้นตั้งแต่แรกหรือเปล่า
      ถ้าไม่ใช่ การไปตัดสินคนที่บ่นเรื่องระบบล่มก็ดูวางท่าและน่ารำคาญมาก
    • การทำให้คนดูเหมือนเป็นคน “disturbed” ด้วย ความห่วงสุขภาพจิตแบบเสแสร้ง ทำนองว่า “คอมเมนต์ของ Hashimoto ดูไม่มั่นคงและหวังว่าเขาจะพบความสงบ” เป็นการโจมตีตัวบุคคลแบบหลงประเด็นสุดๆ ซึ่งไม่ค่อยเห็นบน HN
      ปกติจะเจอสไตล์นี้ใน Reddit มากกว่า
    • การล่มของ GitHub กระทบงานหลายอย่าง เช่น การติดตาม issue, การ merge PR, การ contribute, การ review PR
      มันเดาง่ายเกินไปว่าจะมีคนพลาดประเด็นแล้วพูดว่า “แต่มันไม่ได้ขัดขวางการเขียนโค้ดบนเครื่องของคุณนี่” จนในบล็อกต้นฉบับก็พูดดักไว้แล้ว
      ไม่ควรมีการโจมตีตัวบุคคลน่ารังเกียจแบบไปพาดพิงสุขภาพจิตของใคร
    • ตอนแรกฉันนึกว่าเขากำลังลดทอน Hashimoto เพื่อปกป้อง GitHub
      แต่พออ่านแล้วก็ยอมรับได้ว่าปฏิกิริยาทางอารมณ์ของเขาดูไม่ค่อยสอดคล้องกับสถานการณ์จริง
      ถึงอย่างนั้น ขึ้นอยู่กับขนาดของโปรเจกต์ งานอย่างการจัดการ issue หรือการรีวิวต่างๆ ก็อาจทำให้ GitHub กลายเป็นงานเต็มเวลา ได้ และการใช้คำอธิบาย PR กับคอมเมนต์แทน commit message ในฐานะส่วนหนึ่งของเอกสารก็ไม่ใช่เรื่องแปลก
      เพราะงั้นความพร้อมใช้งานของ GitHub จึงอาจเป็นปัญหาใหญ่มากสำหรับหลายบริษัทจริงๆ

  • แม้แต่ตอนนี้เอง ปัญหาของ GitHub API ก็ยังเกิดอยู่

  • คำถามสำคัญคือ ทางเลือก ที่ดีที่สุดคืออะไร

    • เราใช้ self-hosted GitLab
      ถึงจะเป็นเวอร์ชันฟรีก็แทบไม่มีอะไรให้บ่นมาก
    • ถ้าแค่หาที่เก็บโค้ด ก็เก็บไว้บน GitHub เฉยๆ ก็ได้
      จะ mirror โค้ดสาธารณะทั้งหมดไปไว้ที่นั่นก็ไม่เป็นไร
      ถ้าต้องการที่รันเทสต์ ก็สร้าง infrastructure ของตัวเอง ขึ้นมาได้
      ทุกวันนี้มันง่ายกว่าที่เคย แล้วจะไปพึ่งกล่องดำแบบนั้นทำไม?
    • ฉันใช้แค่งานอดิเรกหรือโปรเจกต์ข้างๆ แต่ก็เข้าใจว่าทำไมคนที่พึ่งพามันในงานอาชีพถึงโมโห
    • มี Forgejo
      เร็วกว่า GitLab มาก
    • ถ้าเป็นองค์กร ก็มี GitHub Enterprise