โลกโอเพนซอร์ซก่อนยุค GitHub

 (lucumr.pocoo.org)
4 คะแนน โดย GN⁺ 21 일 전 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • ก่อนที่ GitHub จะกลายเป็น โครงสร้างพื้นฐานทางสังคม ของโอเพนซอร์ซ นักพัฒนามักบริหารโครงการบนโครงสร้างพื้นฐานที่ดูแลกันเอง เช่น Trac, คลัง Subversion และเมลลิงลิสต์ และแม้แต่การเพิ่ม dependency ก็มีแรงเสียดทานและต้องพิจารณาอย่างรอบคอบพอสมควร
  • GitHub ทำให้การสร้าง ค้นพบ และมีส่วนร่วมกับโครงการง่ายขึ้นอย่างก้าวกระโดด พร้อมทำให้ issue tracker, pull request, CI ฯลฯ กลายเป็นมาตรฐาน และยังทำหน้าที่เป็น คลังเก็บถาวร ของโอเพนซอร์ซด้วย
  • เมื่อผนวกรวมกับระบบนิเวศแพ็กเกจอย่าง npm ก็เกิด การระเบิดของ micro dependency และ GitHub กลายเป็นแกนหลักของระบบความเชื่อถือ แต่ปัจจุบันความเชื่อถือนี้กำลัง ถูกกัดกร่อน จากความไม่เสถียร ความสับสนในทิศทางผลิตภัณฑ์ และสัญญาณรบกวนจาก AI
  • มีการเคลื่อนไหวอย่าง Ghostty ที่ย้ายออก และ Strudel, Tenacity ฯลฯ ที่ ย้ายไป Codeberg โดยแม้การกระจายศูนย์จะเพิ่มความเป็นอิสระ แต่ก็มีความเสี่ยงที่จะสูญเสียบริบททางสังคม เช่น issue, รีวิว และคำแนะนำด้านความปลอดภัย
  • ท่ามกลางสัญญาณล่าสุดว่าความเป็นศูนย์กลางของ GitHub กำลังอ่อนลง คลังเก็บถาวรสาธารณะที่ เก็บรักษาความทรงจำแต่ลดการพึ่งพา จึงยิ่งสำคัญขึ้น ยุคถัดไปของโอเพนซอร์ซควร รักษาความทรงจำไว้แต่ลดการพึ่งพา

สภาพแวดล้อมโอเพนซอร์ซก่อนยุค GitHub

  • ก่อน GitHub จำนวนโครงการที่ น่าเชื่อถือพอให้พึ่งพาได้มีจำกัด และ ชื่อเสียงกับความต่อเนื่อง ของแต่ละโครงการเชื่อมโยงโดยตรงกับการเลือก dependency
  • dependency ไม่ได้เป็นแค่ชื่อแพ็กเกจ แต่พ่วงมาพร้อมประวัติของโครงการ เว็บไซต์ ผู้ดูแล กระบวนการรีลีส และบริบทของชุมชน
  • โครงการใหญ่จำนวนมากมักดูแลโครงสร้างพื้นฐานของตัวเอง ส่วนโครงการเล็กอาจอยู่บนเซิร์ฟเวอร์มหาวิทยาลัยหรือ SourceForge
  • มีแรงเสียดทานแบบกระบวนการแพ็กเกจของ Debian ที่มีการตรวจสอบแม้กระทั่งไลเซนส์และ copyright header และแรงเสียดทานนี้ก็ทำหน้าที่เป็นส่วนหนึ่งของการตัดสินความน่าเชื่อถือด้วย

ความย้อนแย้งของการดูแลโครงสร้างพื้นฐานเองและระบบควบคุมเวอร์ชันแบบกระจาย

  • โครงการโอเพนซอร์ซยุคแรกมักทำงานอยู่บนเซิร์ฟเวอร์ที่ดูแลเอง ซึ่งรันทั้ง Trac, Subversion, tarball และเอกสาร
  • มีโครงสร้างแบบ Pocoo ที่หลายโครงการช่วยกันแบ่งภาระค่าเซิร์ฟเวอร์ รวมถึงภาระการดูแล Subversion, Trac และเมลลิงลิสต์
  • Subversion เป็น คลังแบบรวมศูนย์ ดังนั้นการดูแลเซิร์ฟเวอร์จึงตามมาโดยธรรมชาติ และบ้านของโครงการก็มีตัวตนชัดเจนในเชิงกายภาพ เช่น hostname, ไดเรกทอรี, Trac instance และคลังเมลลิงลิสต์
  • Mercurial และ Git เป็น ระบบแบบกระจาย ที่ทุกคนสามารถมีคลังเต็มรูปแบบ branch และประวัติทั้งหมดได้ แต่ในทางปฏิบัติศูนย์กลางก็กลับมารวมที่ GitHub อีกครั้ง
  • หลังจากระบบควบคุมเวอร์ชันแบบกระจายเป็นฝ่ายชนะ โลกทั้งโลกกลับถูกทำให้เป็นมาตรฐานบน บริการศูนย์กลางขนาดมหึมาเพียงแห่งเดียว ซึ่งยังคงเป็นความย้อนแย้งครั้งใหญ่ของโอเพนซอร์ซยุคใหม่

การเปลี่ยนแปลงที่ GitHub สร้างขึ้น

  • GitHub ทำให้การสร้างและค้นพบโครงการง่ายขึ้น และช่วยให้แม้แต่คนที่ไม่เคยมีประสบการณ์กับเมลลิงลิสต์ของนักพัฒนาก็เข้าใจ กระบวนการมีส่วนร่วม ได้ง่าย
  • ด้วยการมี issue tracker, pull request, หน้ารีลีส, wiki, หน้า organization, API, webhook และต่อมารวมถึง CI จึงได้เปลี่ยน ค่าเริ่มต้นของการทำงานร่วมกันแบบสาธารณะ ไปโดยสิ้นเชิง
  • การทำงานร่วมกันของโอเพนซอร์ซจึงกลายเป็นรูปแบบที่ดำเนินไปบนประวัติที่มองเห็นได้และการสนทนาที่มองเห็นได้
  • อยู่ช่วงหนึ่ง GitHub ทำหน้าที่เป็น ตัวเลือกพื้นฐานที่สมเหตุสมผลมาก สำหรับการนำโครงการโอเพนซอร์ซขึ้นเผยแพร่
  • ดังเช่น นโยบายที่พยายามคงการเข้าถึง GitHub ไว้ให้ประเทศที่ถูกสหรัฐคว่ำบาตร การรวมศูนย์นี้จึงทำหน้าที่เกินกว่าโฮสติงธรรมดา และเป็นโครงสร้างพื้นฐานสาธารณะที่เข้าถึงได้ด้วย

GitHub ในฐานะคลังเก็บถาวร

  • หน้าที่ที่คนพูดถึงน้อยกว่าของ GitHub คือ บทบาทในฐานะคลังเก็บถาวร ซึ่งทำให้แม้โครงการที่ถูกปล่อยทิ้งไว้ก็ยังค้นหาเจอ และทำงานเหมือนดัชนีของทรัพย์สินสาธารณะด้านซอฟต์แวร์
  • การที่ fork, issue เก่า และบันทึกการสนทนายังคงอยู่ ทำให้การรวมศูนย์สร้าง ความทรงจำที่ค้นพบได้
  • ในทางกลับกัน ก่อนยุคแพลตฟอร์มขนาดใหญ่ เป็นเรื่องปกติที่ไฟล์และบริการของโครงการจะหายไปพร้อมกับการหมดอายุของโดเมนส่วนตัว การยุติ VPS หรือการหายไปของนักพัฒนา
  • อย่างเช่น โครงการยุคแรกที่เหลือเพียง metadata บน PyPI แต่แพ็กเกจจริงหายไปแล้ว ก็มีสถานการณ์ที่ที่อยู่คลังชี้ไปยังเซิร์ฟเวอร์ส่วนตัวเก่าซึ่งใช้งานไม่ได้อีกต่อไป
  • โครงการจำนวนมากในอดีตจึงต้องพึ่งพาวิธีการเก็บรักษาภายนอกอย่าง Internet Archive อย่างมากในท้ายที่สุด

npm และการพุ่งขึ้นของ dependency

  • ปัญหา micro dependency ไม่ได้หยุดแค่การมีแพ็กเกจเล็กจำนวนมาก แต่ยิ่งใหญ่ขึ้นเพราะ GitHub และ npm ทำให้การสร้าง การเผยแพร่ การค้นหา การติดตั้ง และต้นทุนของการพึ่งพาดูเหมือนแทบไม่มีเลย
  • ก่อน GitHub ความน่าเชื่อถือและความต่อเนื่องเป็นองค์ประกอบจำเป็นของการเลือก dependency และเพราะยากจะเชื่อถือความพร้อมใช้งานของบริการอื่น การนำโค้ดภายนอกมาเก็บไว้ในคลังเองแบบ vendoring จึงเป็นเรื่องปกติ
  • ก่อนยุค API การดูแลสคริปต์ที่ใช้ดึงโค้ดภายนอกก็ยุ่งยาก และแรงเสียดทานนี้ทำให้ต้องคิดอีกครั้งก่อนเพิ่ม dependency
  • ในระบบนิเวศแบบ npm กราฟของแพ็กเกจสามารถเติบโตได้เร็วเกินกว่าที่มนุษย์จะไล่เหตุผลตามทัน
  • เพื่อรับมือกับปัญหาสถานะไลเซนส์ที่เริ่มไม่ชัดเจน GitHub ยังพยายาม แก้ไขข้อกำหนดการให้บริการ ด้วย
  • แม้จะพึ่งพาแพ็กเกจเล็ก ผู้คนก็สร้างวัฒนธรรมการตรวจสอบบน GitHub ว่ามีคลังอยู่จริงหรือไม่ มีผู้ดูแลหรือไม่ มี issue อะไรบ้าง มีการเปลี่ยนแปลงล่าสุดเมื่อไร มีโครงการอื่นใช้อยู่หรือไม่ และคำอธิบายแพ็กเกจกับโค้ดสอดคล้องกันหรือไม่
  • GitHub ยังกลายเป็นหนึ่งในไม่กี่ระบบที่รับหน้าที่ trusted publishing ให้กับ registry อย่าง npm ด้วย และเมื่อความเชื่อถือใน GitHub อ่อนลง ผลกระทบจึงลามไกลกว่าการโฮสต์ซอร์สโค้ด ไปถึงวัฒนธรรมทั้งระบบของ supply chain

การอ่อนแรงของ GitHub และสัญญาณการย้ายออก

  • ช่วงหลัง GitHub กำลังสูญเสียความเป็นสิ่งที่หลีกเลี่ยงไม่ได้แบบเดิมไปส่วนหนึ่ง เพราะ ความไม่เสถียร การเปลี่ยนผลิตภัณฑ์ซ้ำๆ เสียงรบกวนจาก Copilot AI และภาวะผู้นำที่ไม่ชัดเจน
  • แม้จะอยู่ท่ามกลางกระแส agentic coding จนแรงกดดันภายในเพิ่มขึ้น แต่สถานะปัจจุบันก็ถูกอธิบายว่ารู้สึกถึงการขาดผู้นำอย่างมาก
  • ช่วงหนึ่งการออกจาก GitHub ดูเป็นเพียงการเคลื่อนไหวเชิงสัญลักษณ์ แต่ตอนนี้แม้แต่โครงการที่มีอิทธิพลสูงก็เริ่มพิจารณาหรือดำเนินการย้ายออกอย่างเปิดเผย
  • การประกาศออกจาก GitHub ของ Ghostty ถูกมองเป็นสัญญาณที่ชัดเจน แม้จุดหมายปลายทางจะยังไม่ชัดนัก
  • Strudel moved to Codeberg
  • Tenacity moved to Codeberg
  • แม้อาจยังไม่ถึงระดับที่ทำให้กระแสหลักเปลี่ยนทิศ แต่ก็เริ่มเห็นแนวโน้มที่จะได้พบพื้นที่โฮสต์นอก GitHub บ่อยขึ้นอีกครั้ง
  • เมื่อ Git เองถูกออกแบบมาโดยมี หลายบ้าน เป็นสมมติฐานตั้งแต่แรก การยุติสภาวะที่บริษัทเดียวกลายเป็นบ้านเริ่มต้นของทุกสิ่งจึงอาจเป็นเรื่องดีต่อสุขภาพของโอเพนซอร์ซ

ต้นทุนของการหวนกลับสู่ความกระจายตัว

  • หากกลับไปสู่หลาย forge, หลายเซิร์ฟเวอร์ และหลายชุมชนขนาดเล็ก ก็จะได้ การกระจายอำนาจและความเป็นอิสระ มากขึ้น และลดการพึ่งพาการเปลี่ยนแปลงผู้นำของ Microsoft ได้
  • อีกข้อดีคือแต่ละชุมชนสามารถเลือก workflow ของตัวเองได้
  • ปัญหา issue tracker ปัจจุบันของ Pi แสดงให้เห็นว่าการตัดสินใจเชิงผลิตภัณฑ์ของ GitHub อาจนำไปสู่ผลลัพธ์ที่ไม่สอดคล้องกับความเป็นจริงของการดูแลโอเพนซอร์ซในปัจจุบัน
  • GitHub เผยให้เห็นด้านที่ถูกออกแบบมาโดยให้ความสำคัญกับ engagement มากกว่าสุขภาพจิตของผู้ดูแล
  • แต่อีกด้านหนึ่ง หากย้ายไปใช้ forge แบบ self-hosted, เซิร์ฟเวอร์ Mercurial ของตนเอง หรือเซิร์ฟเวอร์ cgit แม้โค้ดจะกระจายออกไป แต่ บริบททางสังคม อาจกระจัดกระจายหายไปได้ง่าย
  • issue, รีวิว, การถกเถียงด้านการออกแบบ, release note, ประกาศความปลอดภัย และ tarball เก่า สามารถหายไปได้ง่ายกว่าที่คิดมาก
  • เมลลิงลิสต์ซึ่งเคยเก็บบริบทแบบนี้ไว้ในอดีต ก็ไม่สามารถตามความต้องการของวันนี้ได้แล้ว และประสบการณ์ใช้งานก็ไม่ดีนัก
  • ลักษณะที่ซอฟต์แวร์ถูกลืมเลือนไปอาจมีผลในเชิงชำระล้างอยู่บ้าง แต่ถ้าความเสี่ยงจากการสูญหายเพิ่มสูงขึ้น ก็จำเป็นต้องกลับมาทบทวนใหม่ว่าเราจะใช้ระบบควบคุมเวอร์ชันแบบกระจายอย่างไรในทางปฏิบัติ

สิ่งที่ต้องการคือคลังเก็บถาวรสาธารณะ

  • ไม่ว่า GitHub จะยังอยู่ หรือโครงการจะย้ายไปที่อื่น โอเพนซอร์ซก็ต้องการ คลังเก็บถาวรสาธารณะที่น่าเบื่อแต่มั่นคง
  • ไม่ใช่บริการที่สร้างมาเพื่อชนะตลาดเครื่องมือเพิ่มผลิตภาพของนักพัฒนา แต่เป็นโครงสร้างที่ทำให้ซอฟต์แวร์สำคัญไม่สูญหาย
  • มันควรดำเนินอยู่บนฐานที่ยั่งยืนระยะยาว เช่น endowment หรือเงินทุนสาธารณะ
  • ซอร์สอาร์ไคฟ์ ผลลัพธ์จากการรีลีส metadata และบริบทของโครงการ ควรถูกเก็บรักษาไว้ในที่ที่ไม่ผูกกับ โมเดลธุรกิจหรืออารมณ์ของผู้นำของบริษัทใดบริษัทหนึ่ง
  • GitHub กลายเป็นศูนย์กลางของกิจกรรมโอเพนซอร์ซและรับบทเป็นคลังเก็บถาวรนั้นไปโดยบังเอิญ แต่เมื่อความเป็นศูนย์กลางเริ่มอ่อนลง ก็ไม่อาจสมมติได้ว่าหน้าที่นี้จะยังคงอยู่โดยอัตโนมัติ
  • เซิร์ฟเวอร์ส่วนตัวและความหวังดีเพียงอย่างเดียวไม่เคยเพียงพอสำหรับการเก็บรักษา และช่องว่างหลังการปิดแพลตฟอร์มก็เคยปรากฏชัดแล้วทั้งใน Google Code และ Bitbucket
  • ระบบในอนาคตควรมุ่งไปในทิศทางที่ เก็บรักษาความทรงจำแต่ลดการพึ่งพา โดยการย้ายโครงการ การทำ mirror ของบริบททางสังคม และการเก็บรักษารีลีสควรทำได้ง่ายขึ้น และไม่ควรให้การล่องลอยของบริษัทเดียวกลายเป็นวิกฤตทางวัฒนธรรมของทุกคนได้ง่าย
  • ความตึงเครียดยังคงอยู่พร้อมกันทั้งในแง่ที่เราไม่อยากกลับไปสู่ยุคของลิงก์ tarball ที่เสียและ Trac instance ที่ถูกทิ้งร้าง และก็ไม่อาจยอมรับโครงสร้างแบบ GitHub-centric ตลอด 20 ปีที่ผ่านมาเป็นสภาวะปกติถาวรได้

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

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

 
runableapp 16 일 전

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

ผมจำได้ว่าจุดเริ่มต้นคือบรรยากาศในแวดวงนักพัฒนาเริ่มเปลี่ยนไป มีการปล่อยซอฟต์แวร์สาธารณะออกมาและใช้มันเป็นช่องทางให้คนยอมรับความสามารถของตัวเอง และท้ายที่สุดก็มีโชคหลายอย่างเข้ามาประกอบกัน เช่น ในบรรดา DVCS ไม่กี่ตัว git กลายเป็นตัวที่ถูกใช้อย่างแพร่หลายมากกว่าเดิมด้วย คู่แข่งก็เคยให้บริการคล้าย ๆ กันเหมือนกัน ผมจึงมองว่าไม่ใช่เพราะ GitHub ทำได้พิเศษเหนือกว่าคนอื่นเป็นพิเศษนัก
 
ndrgrd 20 일 전

จริง ๆ แล้วปัญหาคือการพูดคุยใน issue กับ PR มากกว่า ส่วน git เองย้ายไปบริการอื่นเมื่อไรก็ได้ มีโปรเจกต์ที่เอาสามอย่างนี้ใส่ไว้ใน git ด้วยเหมือนกัน ถ้าใช้แบบนั้นก็น่าจะย้ายเมื่อไรก็ได้เลย
 
GN⁺ 21 일 전
ความคิดเห็นจาก Hacker News
  • หนึ่งในการเปลี่ยนแปลงที่ใหญ่ที่สุดที่ GitHub มอบให้คือมันเป็นโครงสร้างแบบ ยึดคนเป็นศูนย์กลาง ไม่ใช่ ยึดโปรเจ็กต์เป็นศูนย์กลาง
    การที่สามารถเอารีโพซิทอรีไปผูกกับชื่อของตัวเองได้ทันทีและเริ่มทำอะไรได้อย่างรวดเร็วนั้นให้ความรู้สึกเป็นอิสระกว่าขั้นตอนอันหนักหน่วงของ SourceForge ที่ต้องตั้งชื่อโปรเจ็กต์ จองชื่อ แล้วค่อยมีทั้งที่เก็บ CVS หรือ SVN เว็บไซต์ เมลลิงลิสต์ และ issue tracker
    มันช่วยลดภาระทางความคิดแบบ “นี่ก็แค่ของที่ทำชั่วคราว” ลงได้มาก
    ไม่ใช่ว่า GitHub จะมีทั้ง issue tracker, PR, หน้ารวม release, wiki, หน้า organization, API, webhook และ CI มาให้พร้อมกันตั้งแต่แรก
    สมัยก่อนยังไม่มีฟีเจอร์ organization เลยต้องสร้างบัญชีผู้ใช้ใหม่เพื่อ เลียนแบบ organization กันเอง และก็เคยผัดวันประกันพรุ่งไม่ยอมติดตั้ง bug tracker แยก เพราะคิดว่า “GitHub คงปล่อยออกมาในอีกไม่กี่เดือน” สุดท้ายเลยต้องจัดการด้วยไฟล์ข้อความในรีโพซิทอรีแทน
  • ปกติแล้วผมยังเสียดายอยู่ที่ในหลายโปรเจ็กต์ Git ชนะ Fossil
    สำหรับโค้ดเบสขนาดมหึมาอย่าง Linux kernel ข้อได้เปรียบด้านประสิทธิภาพของ Git อาจมีความหมาย แต่สำหรับโปรเจ็กต์ส่วนใหญ่แทบไม่มีวันชนเพดานประสิทธิภาพของ VCS
    Fossil มีจุดที่มีประโยชน์มากคือเครื่องมือภายในอย่าง wiki, forum, ticket ถูกจัดการเวอร์ชันรวมไว้กับโค้ดในไฟล์เดียว
    ในงานฟรีแลนซ์ Fossil ทำให้ย้อนกลับไปทำความเข้าใจบริบทของโปรเจ็กต์ รายละเอียด และข้อตกลงกับลูกค้าได้ง่ายมาก
    ไม่ต้องทำให้โค้ดเบสรก หรือไปคุ้ยอีเมลกับเครื่องมือจดโน้ตหลายที่เพื่อกู้บริบทกลับมา
    ผมก็ไม่ชอบแนวคิดที่ว่าพอ Git ฝังรากทางวัฒนธรรมลึกเกินไปแล้วเลยเปลี่ยนไม่ได้
    Fossil เปลี่ยนไปใช้ก็ง่าย และถ้าย้ายมาจาก Git workflow กลับยิ่งง่ายกว่าเดิมด้วยซ้ำ
    • จริง ๆ แล้วก็สร้างเครื่องมือคล้ายกันบนฐานของ Git protocol และรีโพซิทอรีได้ และก็เคยมีของอย่าง distributed code review อยู่จริง
      แค่คนส่วนใหญ่ไม่ต้องการมัน เลยไม่ได้รับแรงส่ง
      มีหลายกรณีเหมือนกันที่การเก็บ issue ไว้กับโปรเจ็กต์ไม่สะดวก
      ถ้าลูกค้าส่ง screenshot หรือไฟล์วิดีโอสำหรับทำซ้ำบั๊กมาเยอะ รีโพซิทอรีก็จะพองเร็วมาก และถ้าผูกไว้กับโค้ด ทุกคนก็ต้องดึงรีโพซิทอรีก้อนใหญ่โตลงมาแค่เพื่อจะดู ticket ในเครื่อง ซึ่งยุ่งยากมาก
      สุดท้ายก็มักไหลไปสู่ข้อสรุปว่า “อย่าใช้เลย มันซับซ้อนเกินและมีแต่ทำให้รีโพซิทอรีบวม”
      ฟีเจอร์ส่วนใหญ่ของ Fossil ดูเหมือนจะทำบน Git backend ได้เหมือนกัน และพวก wiki หรือ issue ก็น่าจะแยกเป็นชั้นของ parallel branch ต่างหากได้
    • ดูเหมือนว่า จังหวะเวลา ก็มีผลเหมือนกัน
      ถ้าจำไม่ผิด แม้ตอนที่ Git เสถียรแล้วและใช้งานประจำวันได้ Fossil ยังมีบางครั้งที่เวลาออกรุ่นใหม่ต้องสร้างรีโพซิทอรีขึ้นมาใหม่ทั้งก้อน
      Git มี UX ที่แย่กว่าและอาจยังเป็นแบบนั้นอยู่ แต่ไม่ว่าอย่างไรมันใช้งานได้ และให้ความรู้สึกว่าพร้อมลงสนามจริงมากกว่า
      แถมยังถูกใช้โดยหนึ่งในโปรเจ็กต์โอเพนซอร์สที่ใหญ่ที่สุดในโลกด้วย ซึ่งในแง่ภาพลักษณ์แล้วความต่างจุดนี้ชี้ขาดมาก
    • ตอนนี้นี่แหละน่าจะเป็นช่วงที่ดีสำหรับใครสักคนจะไปซื้อ fossilhub.com แล้วสร้างคอมมูนิตี้ใหม่
    • ผมก็สงสัยเหมือนกันว่าทำไม Git ถึงเร็วกว่าใน รีโพซิทอรีขนาดใหญ่
      แต่ก็จำได้ว่าช่วงหนึ่งข้อได้เปรียบนั้นไม่ได้ชัดนักเวลาจัดการ blob ขนาดใหญ่
  • ผมกลับมองว่าการที่ GitHub ทำหน้าที่เป็น archive นั้นเป็นเรื่องไม่ดี
    พอมีบริการศูนย์กลางที่สะดวกอยู่ตลอด 99% ของเวลา ความสามารถในการเก็บรักษาของชุมชนโดยรวมก็ถดถอยลง
    ถ้าการจะทำให้บางอย่างยังมีชีวิตอยู่ต้องมีใครสักคนคอย seed เอง ผู้คนก็คงเก็บสำเนาของสิ่งที่พวกเขาเห็นว่าสำคัญจริง ๆ ไว้ดีกว่านี้
    การที่เราสามารถสมมติได้ง่าย ๆ ว่า “ไว้ค่อย checkout ใหม่ทีหลังก็ได้” นั่นแหละที่กลับเป็นปัญหา
    ไม่ควรมีที่เดียวที่สามารถเอาบางอย่างลงได้
    ถ้าโปรเจ็กต์บน GitHub โดน DMCA แม้แต่ fork ก็หายไปพร้อมกัน
    ตอนที่ Nintendo สั่งถอด Switch emulator ยอดนิยมในปี 2024 การเก็บรักษาและการทำงานต่อก็ทำได้แค่ตามหาว่าใคร checkout revision ล่าสุดเก็บไว้ แล้วค่อยเอามาหมุนต่อ
    ที่ทำได้ก็เพราะมันเป็นโปรเจ็กต์ที่ดังมากเท่านั้น: https://news.ycombinator.com/item?id=40254602
    เพิ่มเติมอีกนิด ผมชอบแอนิเมชันส่วนหัว/ส่วนท้ายสไตล์ Splatoon ของเว็บนี้มาก
    มันไม่รบกวน แต่ช่วยสร้างบรรยากาศ และพอเลื่อนหน้าจอก็หลบให้ทันที จนผมอยากขโมยไปใช้ตามเลย
    • เลยทำให้เกิดบรรยากาศแบบ ถ้าไม่อยู่บน GitHub ก็เหมือนไม่มีอยู่จริง ด้วย
      ดูเหมือนจะมีนักพัฒนาจำนวนมากเกินไปที่ไม่รู้ด้วยซ้ำว่าโค้ดสามารถเก็บไว้ที่อื่นได้
    • การทำ archive เองนั้นง่าย แต่ กฎหมายลิขสิทธิ์ และ กฎหมายทรัพย์สินทางปัญญา ต่างหากที่คอยขัดขวาง
      ถ้าลดอุปสรรคในการทำให้ข้อมูลเข้าถึงได้ การรวมศูนย์อำนาจก็คงลดลงด้วย
    • ผมไม่เห็นด้วยกับเรื่องนี้
      เหตุผลหนึ่งที่ GitHub ได้รับความไว้วางใจมาหลายปีก็เพราะจนถึงตอนนี้มันยังไม่ได้หารายได้จาก บทบาทการเป็น archive นี้โดยตรง
      แน่นอนว่าพอดูฟีเจอร์ใหม่ ๆ ที่เกี่ยวกับ Copilot ก็ไม่แน่ใจว่าอนาคตจะยังเป็นแบบนั้นไหม
      ถ้าทางเลือกคือการแตกออกเป็นหลายเว็บไซต์ แต่ละที่ก็แค่มีข้อบังคับ DMCA คนละแบบเท่านั้น
      มันเลยชวนให้ถามกลับว่าทางเลือกที่ดีกว่านั้นคืออะไรกันแน่
  • พออ่านบทความแบบนี้ก็ทำให้ผมหวนมองเส้นทางของโปรเจ็กต์ต่าง ๆ ที่ตัวเองเคยมีส่วนร่วม
    งานโอเพนซอร์สของผมส่วนใหญ่เกิดขึ้นบน infrastructure ที่โฮสต์เอง และตัวอย่างเด่นคือ Xfce
    ตอนที่ผมเข้าร่วมครั้งแรกในปี 2004 เท่าที่จำได้มีแค่เซิร์ฟเวอร์ SVN และอาจมีเว็บอินเทอร์เฟซสำหรับ SVN ที่เพิ่งรองรับใหม่ของ CVSweb
    หลังจากผมเข้าทีมแกนหลักแล้ว เหมือนผมจะเป็นคนตั้ง Bugzilla แต่ก็อาจเป็นคนอื่นก็ได้
    ตอนที่ Git เริ่มกลายเป็นกระแสหลัก ผมเป็นคนนำการย้ายจากรีโพซิทอรี SVN ขนาดใหญ่ไปเป็นรีโพซิทอรี Git หลายตัว และติดตั้งเว็บอินเทอร์เฟซ cgit เพิ่มด้วย
    จนถึงตอนนั้นก็ยังใช้ Bugzilla อยู่
    ราวปี 2009~2010 ผมเข้าสตาร์ตอัปเล็ก ๆ เลยมีเวลาให้ OSS น้อยลงและออกจากโปรเจ็กต์ไป ก่อนจะกลับมาในปี 2022 แล้วพบว่าในระหว่างนั้นมีการตั้ง GitLab instance กับ CI runner และย้าย Bugzilla ไปเป็น GitLab issue แล้ว
    ทุกวันนี้คนที่ยัง active ก็มีอยู่หยิบมือเดียว และงานดูแล infrastructure ก็แทบจะเป็นหน้าที่ของคนคนเดียว แต่ถึงจะเป็นทีมเล็กก็ยังรันกันได้สบาย
    การที่ infrastructure ได้รับการสนับสนุนเป็นเรื่องโชคดีมาก และแม้แค่เงินสนับสนุนรายเดือนก็น่าจะพอให้จ่ายเองได้หากจำเป็น
    เหนือสิ่งอื่นใด สิ่งที่ดีมากคือมันไม่ต้องพึ่ง GitHub/Microsoft
    ถ้ามีใครบอกเมื่อ 20 ปีก่อนว่า Microsoft จะได้เป็นเจ้าของ code forge สำหรับ OSS ที่ใหญ่ที่สุดในโลก ผมคงแทบอาเจียน และทุกวันนี้มันก็ยังทำให้รู้สึกไม่สบายใจอยู่ดี
  • สิ่งหนึ่งที่มักถูกมองข้ามคือ ระบบล็อกอินร่วม ก็สำคัญมากจริง ๆ
    Rust ใช้เครื่องมือชื่อ crater เพื่อรันทดสอบทั้งโลกของโปรเจ็กต์ Rust และตอนที่ต้องไล่หาพวกโปรเจ็กต์ที่พึ่งพา implementation ภายในของ Cargo แล้วเปิด issue ทีละหลายร้อยรายการด้วยมือ การมี flow ที่เสียดทานต่ำช่วยได้มาก
    ถ้ามี credential ของไซต์นั้นอยู่แล้ว และยังยอมให้ใช้ template ว่างได้ การเปิด 200 issue จะง่ายขึ้นมาก
    ในทางกลับกัน ถ้าเจอ instance ที่โฮสต์เอง ส่วนมากผมก็มักยอมแพ้ตรงนั้นเลย
  • ผมเคยโพสต์บน Planet Source Code มาตั้งแต่ก่อนที่ SourceForge จะถือกำเนิด
  • ผมชอบ Trac มากจริง ๆ
    การเริ่มโปรเจ็กต์โอเพนซอร์สใหม่แล้วขั้นแรกต้องไปตั้ง Trac นั้นมีแรงเสียดทานสูงจนน่าเหลือเชื่อ แต่ถึงอย่างนั้นมันก็ยังดีมาก
    Django ก็ยังคงรันอยู่บน Trac มานานกว่า 20 ปีแล้ว: https://code.djangoproject.com/timeline
    ผมไม่ได้เป็นคนตั้งอันนั้น แต่ก็อาจเคยช่วยเปิด Trac แบบ private ที่มาก่อนหน้านั้น
    • Trac ดีจริง ๆ
      แต่ issue tracker ตัวแรกของผมคือ Bugzilla ซึ่งการตั้งค่านั้นทรมานพอสมควร และการผสานเข้ากับเครื่องมืออื่นก็ไม่ดีนัก
      ถึงอย่างนั้นการได้เห็น Zarro Boogs ก็เป็นความสุขเฉพาะตัวเหมือนกัน
    • Trac เป็นต้นเหตุสำคัญในหลายด้านที่ทำให้ผมหันไปทำแอปสำหรับ deploy ด้วย Python แทน PHP
      ระบบปลั๊กอิน ของมันยอดเยี่ยมมาก
    • ผมชอบ Bitbucket
      มันทำหน้าที่ของมันได้ดี ไม่เคยพังอะไรสำหรับผม และผมก็ชอบฝั่ง Mercurial มากกว่า
      พอบริษัทต่าง ๆ ใช้ GitHub ผมก็เลยย้ายตาม แต่จนถึงตอนนี้ผมก็ยังใช้ GitHub แค่เหมือน Git endpoint ทื่อ ๆ ส่วน build/deploy ก็จัดการด้วย Docker กับ shell script เลยทำให้ต้นทุนการย้ายออกต่ำมาก
      ในงาน ถ้าผมไม่มีอำนาจตัดสินใจ ผมก็คิดว่าเหมือนสมัย SVN คือใช้เครื่องมือที่บริษัทจ่ายเงินให้ใช้ไปก็พอ
    • แปลกดีที่ตอนนั้นผม เกลียด Trac มาก แต่ตอนนี้กลับจำมันในแง่ดี
      ตอนนั้นผมรู้สึกว่ามันพยายามทำหลายอย่างเกินไปจนไม่มีอะไรโดดเด่นสักอย่าง
      ตอนนี้ตำแหน่งนั้นน่าจะตกเป็นของ GitLab แล้ว และอีกหน่อยก็คงถูกจดจำในแง่ดีแบบเดียวกัน
  • ผมลองไปหาบริการ archive โค้ดเพราะสงสัย ก็เจออยู่หลายอย่าง
    มีทั้งโปรแกรมของ GitHub เอง: https://archiveprogram.github.com/
    และยังมี Software Heritage ซึ่งเป็นองค์กรไม่แสวงกำไรที่ได้รับการสนับสนุนจาก UNESCO: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
    แต่ฝั่งนี้จะเน้นไปที่การเก็บรักษาโค้ดและประวัติ commit เป็นหลัก และยังไม่ได้ครอบคลุม metadata รอบข้างอย่าง issue, PR, การสนทนา หรือ wiki มากนัก
  • ผมน่าจะเป็นหนึ่งในคนที่ได้ใช้ Flask ตั้งแต่ช่วงเกือบแรก ๆ
    ผมเรียน Python เพื่อใช้ประโยชน์จาก AppEngine ซึ่งเป็นโฮสติ้งสมัยใหม่ที่ฟรีและใช้ง่าย และนั่นก็ทำให้ผมอยู่ในจุดที่เหมาะพอดีตอนที่ Flask ออกมา
    ผมชื่นชม Armin มานานมาก และก่อนจะกดลิงก์เสียอีก แค่เห็นโดเมนก็จำได้ทันที
    ผมก็เห็นด้วยกับที่เขาพูดว่าสมัยนั้น GitHub ยังไม่ใช่ตัวเลือกพื้นฐาน
    และยังประทับใจที่บทความนี้เป็นการตอบโพสต์ของ Mitchell ที่ออกมาเมื่อไม่กี่ชั่วโมงก่อน แถมยังเขียนออกมาได้ยาว มีคุณภาพ และวางโครงได้ดีเร็วขนาดนี้
  • ทำให้นึกถึง code.google.com
    ผมยังไม่อยากเชื่อเลยว่า Google จะพลาดโอกาสครั้งใหญ่ขนาดนั้นได้
    • ชวนคิดถึงจริง ๆ
      ผมอยู่ในทีมนั้นก่อนที่บริการจะปิดตัวลง