Russ Cox ก้าวลงจากตำแหน่งผู้นำด้านเทคนิคของ Go
(groups.google.com)- โปรเจกต์ Go กำลังเปลี่ยนผ่านจากโครงสร้างผู้นำที่มี Russ Cox เป็นศูนย์กลางมานานกว่า 12 ปี ไปสู่โครงสร้างใหม่ที่มี Austin Clements และ Cherry Mui เป็นแกนหลัก
- ตั้งแต่วันที่ 1 กันยายน 2024 เป็นต้นไป Austin จะรับหน้าที่ผู้นำด้านเทคนิคของทั้งทีม Go ภายใน Google และโปรเจกต์ Go โดยรวม ส่วน Cherry จะนำ Go core ซึ่งครอบคลุมคอมไพเลอร์ รันไทม์ และรีลีส
- Cox มองว่าการมีผู้นำคนเดียวในระยะยาวให้ความมั่นคงได้ แต่ก็อาจลดพื้นที่ให้ผู้นำรุ่นใหม่เติบโต และมองว่าการเปลี่ยนผ่านผู้นำของ Python ในปี 2018 เป็นตัวอย่างเชิงบวก
- Cox จะไม่ออกจาก Go แต่จะยังคงมีส่วนร่วมในฐานะผู้มีส่วนร่วมรายบุคคล เช่น การร่วมถกเถียงด้านการออกแบบ รีวิว CL ส่ง issue ทำงานบางส่วนใน standard library และบรรยายที่ GoLab
- จากนี้เขาจะโฟกัสกับ Gaby and Oscar มากขึ้น เพื่อเพิ่มประสิทธิภาพการทำงานในตัวติดตาม issue ของ Go และผลักดันแนวทางที่ช่วยผู้ดูแลโอเพนซอร์สไปยังโปรเจกต์อื่น
การเปลี่ยนผ่านผู้นำของ Go
- ตั้งแต่วันที่ 1 กันยายน 2024 เป็นต้นไป Austin Clements จะรับตำแหน่งผู้นำด้านเทคนิคของ Go
- ครอบคลุมทั้งทีม Go ของ Google และโปรเจกต์ Go ทั้งหมด
- ปัจจุบัน Austin เป็นผู้นำด้านเทคนิคของส่วนที่เรียกว่า “Go core”
- Cherry Mui จะขยับขึ้นมารับบทบาทผู้นำของส่วน Go core
- Go core ครอบคลุม toolchain ของคอมไพเลอร์ รันไทม์ และรีลีส
- Russ Cox จะไม่ออกจากโปรเจกต์ Go แต่จะถอยออกจากจุดศูนย์กลางของการตัดสินใจหนึ่งก้าว
เหตุผลที่ต้องเปลี่ยนหลังจากการนำมา 12 ปี
- สำหรับ Cox ตำแหน่งผู้นำด้านเทคนิคไม่ใช่ตำแหน่งเชิงเกียรติยศ แต่ใกล้เคียงกับ บทบาทการรับใช้ มากกว่า
- ตลอดเวลากว่า 12 ปีที่นำโปรเจกต์ Go เขามุ่งสร้างเงื่อนไขให้สมาชิกสามารถทำงานที่ดีได้
- โปรเจกต์ขนาดใหญ่ได้ประโยชน์จากความมั่นคงของผู้นำ แต่เมื่อถึงจุดหนึ่งก็จำเป็นต้องมีจุดแข็งและมุมมองสดใหม่จากผู้นำคนใหม่
- Cox เห็นว่า Go ได้สั่งสมความมั่นคงจากการมีผู้นำคนเดียวมานานกว่า 12 ปีเพียงพอแล้ว
- เขามองว่าโมเดล BDFL ไม่ดีต่อทั้งตัวบุคคลและตัวโปรเจกต์
- ทำให้สร้างพื้นที่ให้ผู้นำคนใหม่ได้ยาก
- กลายเป็นจุดล้มเหลวเพียงจุดเดียว
- ลดโอกาสที่โปรเจกต์จะเติบโตต่อไป
- มีการยก Python เป็นตัวอย่างที่ได้รับประโยชน์อย่างมาก หลังจาก Guido van Rossum ก้าวลงในปี 2018 และเปิดทางให้ผู้อื่นเข้ามานำ
ความเชื่อมั่นต่อ Austin Clements และ Cherry Mui
- Austin ทำงานกับ Go ที่ Google มาตั้งแต่ปี 2014 และ Cherry ตั้งแต่ปี 2016
- Cox ประเมินว่าทั้งสองมีวิจารณญาณยอดเยี่ยม และมีความรู้ลึกทั้งเกี่ยวกับ Go และระบบที่ Go ทำงานอยู่บนมัน
- เมื่อต้องทำความเข้าใจคำถามด้านการออกแบบทั่วไป หรือรายละเอียดเชิงลึกของคอมไพเลอร์ ลิงเกอร์ และรันไทม์ เขามักพึ่งพา Austin และ Cherry
- ผู้นำเดิมในแต่ละด้านจะยังคงนำงานของตนต่อไป
- Roland Shoemaker จะยังคงนำด้านความปลอดภัยของ Go
- Rob Findley และ Hana Kim จะยังคงนำด้านเครื่องมือของ Go และการรองรับ IDE
บทบาทของ Russ Cox ต่อจากนี้
- Cox วางแผนจะถอยออกจากการตัดสินใจอย่างตั้งใจ เพื่อเปิดพื้นที่ให้ Austin และผู้นำคนอื่นก้าวขึ้นมานำ
- ภายใน Go เขาจะยังคงเป็นผู้มีส่วนร่วมรายบุคคลต่อไป
- เข้าร่วมการถกเถียงด้านการออกแบบของ Go
- รีวิว CL
- ตอบคำถามเกี่ยวกับประวัติเดิมที่เก่าแก่
- ช่วยเหลือเมื่อจำเป็น
- ส่ง issue และเขียน CL
- ทำงานในส่วนของ standard library ใหม่บางรายการที่เป็นไปได้
- สนับสนุน Go ในอุตสาหกรรมโดยรวม
- บรรยายเกี่ยวกับ Go ที่งาน GoLab ในอิตาลีเดือนพฤศจิกายน
- รายละเอียดของการเปลี่ยนผ่านยังไม่ได้กำหนดทั้งหมด และถูกนำไปแชร์ใน mailing list เพื่อเปิดให้มีการอภิปรายสาธารณะ
- Cox และ Austin ต้องการให้การเปลี่ยนแปลงครั้งนี้ถูกมองว่าเป็นเพียงการทำให้โปรเจกต์ Go แข็งแกร่งและดีขึ้น ไม่ใช่เหตุการณ์ใหญ่โตอย่างอื่น
การย้ายโฟกัสไปที่ Gaby และ Oscar
- จากนี้ Cox จะโฟกัสกับ Gaby and Oscar มากขึ้น
- เป้าหมายคือสร้างการมีส่วนร่วมที่เป็นประโยชน์ในตัวติดตาม issue ของ Go เพื่อช่วยให้ผู้ทำงานกับ Go ทำงานได้มีประสิทธิภาพมากขึ้น
- ผ่านงานด้าน Oscar เขาต้องการหาแนวทางที่ช่วยผู้ดูแลโอเพนซอร์ส และหวังว่าจะถูกนำไปใช้ในโปรเจกต์อื่นด้วย
- เป้าหมายระดับบนของ Oscar มี 3 ข้อ
- สร้างสิ่งที่มีประโยชน์
- เรียนรู้สิ่งใหม่
- วางเส้นทางสำหรับโปรเจกต์อื่น
- เป้าหมายเหล่านี้เชื่อมโยงกับเป้าหมายกว้างที่เขาไล่ตามมาโดยตลอดใน Go ทำให้ Oscar ดูเป็นก้าวถัดไปที่เป็นธรรมชาติสำหรับ Cox
ปฏิกิริยาจากชุมชนและคำขอเรื่องความโปร่งใส
- Daniel Martí ยก modules และ generics เป็นความเปลี่ยนแปลงและหมุดหมายสำคัญของ Go ในช่วง 10 ปีที่ผ่านมา และประเมินว่า Cox มีบทบาทสำคัญต่อความสำเร็จระยะยาว
- เขาเสนอแนวทางเพิ่มความโปร่งใสในงานด้านคอมไพเลอร์และรันไทม์ควบคู่ไปกับการหารือเรื่องการเปลี่ยนผ่าน
- เปิด compiler and runtime meeting notes thread อีกครั้ง
- เปิด compiler and runtime office hours calls อีกครั้ง
- พร้อมเปรียบเทียบว่าทีมเครื่องมือสื่อสารกับชุมชนอย่างโปร่งใสผ่าน Slack และ regular golang-tools calls
- Cherry Mui ตอบว่าบันทึกการประชุมและ office hours เป็นโอกาสที่ดีในการเพิ่ม ความโปร่งใส และการมีส่วนร่วมระหว่างทีมคอมไพเลอร์และรันไทม์ของ Google กับชุมชน
- เมื่อกำหนดตาราง office hours ครั้งถัดไปได้แล้ว จะมีการอัปเดตใน mailing list
- ผู้เข้าร่วมหลายคนแสดงความขอบคุณต่อการนำของ Cox ตลอด 12 ปี และการมีส่วนร่วมต่อ Go พร้อมร่วมแสดงความยินดีกับบทบาทใหม่ของ Austin และ Cherry
1 ความคิดเห็น
ความเห็นจาก Hacker News
rsc ขอบคุณสำหรับงานทั้งหมดที่ผ่านมา ตลอด 12 ปีที่ผ่านมา การพัฒนา Go สนุกขึ้นมากด้วย race detector, การ wrap error แบบมาตรฐาน, modules, generics, การอัปเดต toolchain และอื่น ๆ
ยังมีสิ่งที่อยากได้อยู่ ส่วนตัวแล้ว union types, enums/range types ที่ดีกว่า, immutability และ non-nilness อยู่ใน wishlist แต่ถึงอย่างนั้น Go ก็ยังเป็นหนึ่งใน ecosystem ที่สนุกที่สุดเท่าที่เคยพัฒนามา
https://research.swtch.com/vgo-intro
non-nilnessแล้วก็ยังจำเธรดนี้ได้อยู่https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
forแบบ 3 ส่วนดั้งเดิมด้วย: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...เพราะการเปลี่ยนแปลงนี้ ต่อให้ทางการ Go จะไม่ยอมรับ ผมก็มองว่า Go 1.22 เป็น Go เวอร์ชันแรกที่ทำลายความเข้ากันได้กับ Go 1 อย่างร้ายแรงในทางปฏิบัติ
ส่วนตัวมองว่า Go เป็นหนึ่งใน โปรเจกต์โอเพนซอร์ส ที่บริหารจัดการดีที่สุดเท่าที่เคยมีมา ขอคารวะ Google ที่สนับสนุนสิ่งนี้ด้วย
ในทางทฤษฎีอาจเป็นองค์กรอิสระหรือคณะกรรมการอะไรสักอย่าง แต่สงสัยว่าคนส่วนใหญ่ที่ทำงานจริง ๆ นั้นใครเป็นคนออกค่าใช้จ่าย Google ใช่ไหม?
ดังนั้นเป้าหมายของโปรเจกต์จึงไม่ใช่การครองโลกอีกต่อไป แต่สอดคล้องกับผู้ใช้ และสงครามนั้นก็กลายเป็นของ Rust, Zig และอื่น ๆ ไปแล้ว
ประโยคที่ว่า “ไม่เชื่อว่าโมเดล BDFL (เผด็จการใจดีตลอดชีพ) ดีต่อสุขภาพของคนหรือโปรเจกต์” น่าสนใจ โปรเจกต์ที่ดีที่สุดมักมี BDFL และ BDFL ที่ดีที่สุดก็ดูเหมือนจะกังขาในอำนาจของตัวเอง
ในทางกลับกัน คนที่อยากเป็น leader เพราะอยากถูกมองว่าเป็น “leader” บางทีก็ไม่มีทั้งความสามารถและความรับผิดชอบ
ผมมองว่าข้อดีหลักของอำนาจที่คนคนเดียวสามารถตัดสินใจฝ่ายเดียวได้ คือการเลี่ยง deadlock ที่เกิดขึ้นเมื่อมีผู้มีส่วนได้ส่วนเสียจำนวนมาก ถ้าเป็นโปรเจกต์ที่ผู้นำรู้สึกว่าตนมีความชอบธรรมในการกลับคำตัดสินที่มีฉันทามติแข็งแรงได้ ก็คงยากมากที่ชุมชนจะก่อตัวขึ้นจนเป็นที่รู้จัก
มองคร่าว ๆ แล้วเหมือนระบบราชการอีกแบบหนึ่งที่อาจลดดราม่าได้ แต่ไม่ได้ยกระดับคุณภาพอย่างเห็นได้ชัด ขณะเดียวกันมีโปรเจกต์ที่มีเจ้าของคนเดียวแล้วล้มเหลวเพราะไม่ยืดหยุ่นพออยู่เป็นกอง เพียงแต่เรื่องพวกนั้นถูกมองว่าไม่คุ้มจะพูดถึงเท่านั้น
เรื่องนี้ไกลเกินกว่าโปรเจกต์โอเพนซอร์สมาก
มันเป็นคำที่ยอมรับ “ความจริงหน้างาน” ของบทบาทที่ GvR มีในฐานะผู้สร้าง Python ไม่ได้ตั้งใจให้เป็นหลักการบริหารโปรเจกต์อย่างจริงจัง มันเป็นการบรรยาย ไม่ใช่ใบสั่งยา แต่แนวคิดนี้ถูกทำให้เป็นสิ่งจับต้องได้มากเกินไป
rsc ขอบคุณจริง ๆ สำหรับความพยายามทั้งหมดที่ทุ่มให้กับภาษานี้ ซึ่งพาผมเข้าสู่วิศวกรรมซอฟต์แวร์
ผมลองจับภาษาการเขียนโปรแกรมมาหลายภาษา แต่ Go ก็ยังรู้สึกเหมือนบ้าน developer experience ยอดเยี่ยม และผมชื่นชมมากที่ภาษาและผู้สร้างยืนหยัดกับ ความเรียบง่าย และความรับผิดชอบอย่างไม่ต้องแก้ตัว ขอให้โชคดีและประสบความสำเร็จกับทุกสิ่งต่อจากนี้
ตอนเริ่ม Go ผมไม่เคยคาดคิดเลยว่า Go จะส่งผลเชิงบวกต่อชีวิตผู้คนได้ขนาดนี้ และดึงคนหน้าใหม่เข้าสู่การเขียนโปรแกรมและวิศวกรรมซอฟต์แวร์ได้ ผลกระทบนั้นคือสิ่งที่ผมภูมิใจที่สุด
บล็อกของ RSC ดีมาก: https://research.swtch.com/
ขอบคุณสำหรับทุก contribution ต่อ Go
แต่มีเรื่องหนึ่งที่ไม่เกี่ยวกับ Go ที่ผมไม่เห็นด้วย Python ไม่ได้ดีขึ้นหลัง GvR ลงจากตำแหน่ง “leadership” ใหม่ไม่ใช่สายเทคนิคและกดขี่ ทำให้ contributor โอเพนซอร์สตัวจริงส่วนใหญ่ออกไป
การพัฒนาหยุดนิ่ง นอกจาก contribution จากบริษัทบางส่วนที่คุณภาพน่าสงสัย บรรยากาศกดดัน และสิ่งสำคัญมีแค่ว่าคุณอยู่ในตำแหน่งที่มีอำนาจใน Microsoft/Instagram/Bloomberg หรือไม่ อาจไม่จำเป็นต้องเป็นความผิดของบริษัทเหล่านี้ พวกเขาอาจไม่รู้ว่าความใจกว้างของตนถูกนำไปใช้ในทางที่ผิด
ดูสถิติ GitHub แล้วกิจกรรมดูแข็งแรง เดือนที่ผ่านมา merge PR มากกว่า 700 รายการจาก contributor กว่า 120 คน [1]
ในช่วงไม่กี่ปีมานี้ contributor ใหม่ก็ดูเหมือนเพิ่มขึ้นมาก [2]
[1] https://github.com/python/cpython/pulse/monthly
[2] https://github.com/python/cpython/graphs/contributors
แค่
gofmtอย่างเดียวก็น่าจะช่วยประหยัดเวลามหาศาลทั่วโลกแล้ว โดยพื้นฐานแล้วมันเป็นต้นน้ำที่ทำให้ ecosystem ภาษาอื่น ๆ ทุกภาษาพูดว่า “โอเค งั้นก็แค่ auto-format ไปเลย”ผมไม่ชอบสิ่งที่ auto formatter ทำกับโค้ดของผม แต่ก็ชอบที่ไม่ต้องพูดเรื่อง whitespace อีกต่อไป
gofmtformat โค้ดตั้งแต่แรกแล้วหลังจากนั้นก็รู้สึกขอบคุณที่ไม่ต้องใช้เวลากับเรื่องนั้นมากอีกต่อไป และอย่างน้อยสำหรับคนส่วนใหญ่ มันก็ไม่เป็นปัญหา
วันนี้ได้รู้จักโปรเจกต์ที่เขาจะโฟกัส: https://go.googlesource.com/oscar/+/refs/heads/master/README...
บอกว่าเป็น สถาปัตยกรรมที่ใช้ LLM เพื่อช่วยดูแลโปรเจกต์โอเพนซอร์ส ดูเจ๋งดี
https://www.youtube.com/watch?v=wwoWei-GAPo — ตั้งแต่นั้นมาโปรเจกต์มาไกลมากจริง ๆ
ดีใจที่มันยังมีชีวิตและเติบโตอยู่ ผมคิดว่าในปี 2009 คงไม่ได้คาดหวังว่าจะเป็นแบบนี้ ถ้าไม่มี Russ Go คงมาไม่ถึงจุดที่เป็นอยู่ตอนนี้ contribution ของเขาต่อโปรเจกต์นั้นมหาศาล
ขอบคุณ Russ การให้ การรองรับเครื่องมือ เป็นองค์ประกอบชั้นหนึ่งถือเป็นเรื่องปฏิวัติ และยังคงเป็นคุณสมบัติที่โดดเด่นที่สุดของ Go จนถึงตอนนี้