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

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

---

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

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

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

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

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

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

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

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

npm และการระเบิดของ dependency

• ปัญหา micro dependency ไม่ได้หยุดอยู่แค่การมีแพ็กเกจเล็กจำนวนมาก แต่รุนแรงขึ้นเพราะ GitHub และ npm ทำให้ต้นทุนของการสร้าง เผยแพร่ ค้นหา ติดตั้ง และพึ่งพาแพ็กเกจดูเหมือนแทบเป็นศูนย์
• ก่อน GitHub ความน่าเชื่อถือและความยั่งยืนเป็นองค์ประกอบจำเป็นของการเลือก dependency และเพราะเชื่อถือความพร้อมใช้งานของบริการอื่นได้ยาก การใส่โค้ดภายนอกไว้ในรีโพซิทอรีโดยตรงแบบ vendoring จึงเป็นเรื่องปกติ
• ก่อนยุค API การดูแลสคริปต์ที่ดึงโค้ดภายนอกเข้ามาก็ยุ่งยาก และแรงเสียดทานนี้ทำให้คนต้องคิดอีกครั้งก่อนเพิ่ม dependency
• ใน ecosystem แบบ npm กราฟของแพ็กเกจสามารถเติบโตได้เร็วกว่าที่มนุษย์จะไล่เหตุผลตามทัน
• GitHub ยังเคยพยายามแก้ปัญหาสถานะ license ที่ไม่ชัดเจนด้วย การแก้ไขข้อกำหนดการให้บริการ
• แม้จะพึ่งพาแพ็กเกจเล็ก ๆ วัฒนธรรมการตรวจดูรีโพซิทอรี การมีอยู่ของผู้ดูแล issue การเปลี่ยนแปลงล่าสุด การใช้งานโดยโปรเจกต์อื่น และความสอดคล้องกันของโค้ดกับคำอธิบายแพ็กเกจบน GitHub ก็ได้หยั่งรากขึ้น
• 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 มากกว่าสุขภาพจิตของผู้ดูแล
• แต่อีกด้านหนึ่ง หากย้ายไปใช้ self-hosted forge, เซิร์ฟเวอร์ Mercurial ของตนเอง หรือเซิร์ฟเวอร์ cgit แม้โค้ดจะกระจายตัวมากขึ้น แต่ บริบททางสังคม ก็อาจกระจัดกระจายหายไปได้ง่าย
• issue, review, การถกเถียงเชิงออกแบบ, release note, ประกาศความปลอดภัย และ tarball เก่า ๆ หายไปได้ง่ายกว่าที่คิดมาก
• mailing list ที่เคยเก็บบริบทแบบนี้ไว้ในอดีตไม่สามารถตอบโจทย์ความต้องการปัจจุบันได้แล้ว และประสบการณ์ใช้งานก็ไม่ดี
• ธรรมชาติที่ซอฟต์แวร์ถูกลืมอาจมีผลแบบการชำระล้างอยู่บ้าง แต่ถ้าความเสี่ยงของการสูญหายสูงขึ้น ก็ต้องกลับมาคิดใหม่ว่าเราจะใช้ระบบควบคุมเวอร์ชันแบบกระจายอย่างไรในทางปฏิบัติ

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

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

[ndrgrd]

จริง ๆ แล้วปัญหาคือการพูดคุยใน issue กับ PR มากกว่า ส่วน git เองย้ายไปบริการอื่นเมื่อไรก็ได้ มีโปรเจกต์ที่เอาสามอย่างนี้ใส่ไว้ใน git ด้วยเหมือนกัน ถ้าใช้แบบนั้นก็น่าจะย้ายเมื่อไรก็ได้เลย

[GN⁺]

ความคิดเห็นจาก 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 จะพลาดโอกาสครั้งใหญ่ขนาดนั้นได้
  • ชวนคิดถึงจริง ๆ
    ผมอยู่ในทีมนั้นก่อนที่บริการจะปิดตัวลง