โอเพนซอร์สไม่ได้หมายถึงคอมมูนิตี้แบบเปิดเสมอไป

 (blog.feld.me)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ซอฟต์แวร์โอเพนซอร์สสามารถเผยแพร่ได้ตั้งแต่ก่อนยุค (D)VCS ผ่านหน้า HTML, ไฟล์ txt, tarball บน FTP และมีเพียงอีเมลสำหรับติดต่อเท่านั้น โดยยังเป็นโอเพนซอร์สได้แม้ไม่มีคอมมูนิตี้สาธารณะ
  • การมี mailing list หรือช่อง IRC ถือว่าโชคดีแล้ว แต่ pull request, issue, wiki, core team และ Code of Conduct ไม่เคยเป็นเงื่อนไขจำเป็นของโอเพนซอร์ส
  • Sourceforge ทำให้การพัฒนาแบบเปิดทำได้ง่ายขึ้นด้วยการให้บริการ CVS/SVN และ mailing list แบบแทบไม่เสียค่าใช้จ่าย และหลังจากนั้น git ก็ชนะการแข่งขันของ DVCS จนโลกค่อย ๆ มาบรรจบที่ GitHub
  • หลังยุค GitHub การดูแลโอเพนซอร์สได้กลายเป็นเหมือน งานที่ไม่ได้รับค่าจ้าง ซึ่งต้องแบกรับทั้ง issue, pull request ที่อยู่นอกขอบเขต, คำบ่นและคำเรียกร้อง ตลอดจนการดูแลกลุ่มแชต จนนำไปสู่ภาวะหมดไฟและการสูญเสียการควบคุม
  • โปรเจกต์ไม่ได้จำเป็นต้องพัฒนาแบบสาธารณะเสมอไป สามารถปิด issue tracker และ pull request หรือใช้ bare git server แล้วดูแล โอเพนซอร์ส กับกลุ่มเล็ก ๆ ที่ไว้ใจได้ หรือทำคนเดียวก็ได้

ภาระของการดูแลรักษาหลังยุค GitHub

  • GitHub ทำให้การดูแลโอเพนซอร์สรู้สึกเหมือน งานที่ไม่ได้รับค่าจ้าง สำหรับผู้ดูแลโครงการ
  • หลังจากต้องจัดการตั๋วงาน การประชุมกับผู้มีส่วนได้ส่วนเสีย โร้ดแมป การเมืองในองค์กร สิ่งรบกวน เดดไลน์ เมตริก KPI ความต้องการที่เปลี่ยนไป standup, one-on-one, Agile และ Waterfall ในที่ทำงานแล้ว พอกลับถึงบ้านก็ยังมีการแจ้งเตือนจากโอเพนซอร์สรออยู่
  • issue สะสมมากขึ้น มี pull request เข้ามาเพื่อออกแบบซอฟต์แวร์ใหม่ไปในทิศทางที่อยู่นอกขอบเขตของโปรเจกต์ และคำบ่นกับคำขอเพิ่มขึ้นเรื่อย ๆ
  • เมื่อมีกลุ่มแชตและ “คอมมูนิตี้” ผู้ดูแลก็ต้องรับภาระเพิ่มในการจัดการคนที่ใจร้อนและต้องคุยแบบตัวต่อตัว
  • ผลลัพธ์คือโอเพนซอร์สกลายเป็นเหมือน อาชีพที่สอง ผู้ดูแลเกิดภาวะหมดไฟ และอาจถึงขั้นสูญเสียการควบคุมกับทิศทางของโปรเจกต์ตัวเอง

กลับไปสู่การดูแลแบบเรียบง่ายอีกครั้ง

  • บางโปรเจกต์ใหญ่และซับซ้อนเกินกว่าจะไม่ต้องมีการบริหารทีม แต่กรณีแบบนั้นเป็นข้อยกเว้น ไม่ใช่เรื่องปกติ
  • ถ้ารู้สึกโกรธที่คนหน้าใหม่และบอต AI เข้ามาแย่งความสนใจ คุณก็สามารถกลับไปใช้วิธีแบบเดิมได้
  • สามารถปิด issue tracker และ pull request หรือจะเปิด bare git server ไว้เพื่อเผยแพร่โค้ดก็ได้
  • จะทำงานกับกลุ่มเล็ก ๆ ที่รู้จักและไว้ใจจริง ๆ หรือจะทำโปรเจกต์คนเดียวทั้งหมดก็ได้
  • ไม่มีความจำเป็นต้องยอมให้คนแปลกหน้าเข้ามารุกล้ำพื้นที่ของตัวเอง และ Code of Conduct หรือกฎเกณฑ์เกี่ยวกับ LLM ที่ทำไปเพื่อภาพลักษณ์ก็ไม่ใช่สิ่งจำเป็น
  • โอเพนซอร์สไม่จำเป็นต้อง พัฒนาแบบสาธารณะ เสมอไปเพื่อที่จะยังเป็น “โอเพนซอร์ส”
  • ใช้เครื่องมือที่ต้องการ สร้างสิ่งที่คุณชอบ และจะปล่อย code drop ตอนตีสองของคืนคริสต์มาสก็ได้ โดยไม่จำเป็นต้องถูกลากเข้าไปสู่รูปแบบการดูแลที่เหมือนเอาศูนย์บ่มเพาะเทคโนโลยีกับสถานรับเลี้ยงเด็กมาผสมกัน

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

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

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Lobste.rs

  • เพราะความคิดแบบนี้ เลยสร้าง https://casuallymaintained.tech/ ขึ้นมา และชอบมันมาก

  • ตัวอย่างที่มีชื่อเสียงที่สุดคือ SQLite ซึ่งปฏิเสธการมีส่วนร่วมจากภายนอก
    เมื่อคิดว่ามันถูกใช้แม้กระทั่งใน แอปพลิเคชันภารกิจสำคัญ อย่างเครื่องบินของ Airbus นี่ก็เป็นนโยบายที่สมเหตุสมผล

    • SQLite ไม่ได้ปฏิเสธการมีส่วนร่วมจากภายนอก ในหน้าลิขสิทธิ์ก็เขียนไว้ชัดเจน
      SQLite เป็นโอเพนซอร์ส จึงคัดลอกได้มากเท่าที่ต้องการและใช้งานได้โดยไม่มีข้อจำกัด แต่ไม่ใช่โครงการแบบเปิดรับการมีส่วนร่วมสาธารณะ (open-contribution)
      เพื่อคงให้ SQLite อยู่ใน public domain และป้องกันไม่ให้มีการปะปนกับโค้ดแบบกรรมสิทธิ์หรือโค้ดที่มีไลเซนส์ จึงไม่รับแพตช์จากผู้ที่ไม่ได้ยื่นคำแถลงว่ายกการมีส่วนร่วมนั้นให้เป็น public domain

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

  • บทความที่เกี่ยวข้อง: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/

  • เป็นแนวทางที่แข็งแรงดี และอยากให้คนจำนวนมากขึ้นใช้เป็นค่าเริ่มต้น
    การ สร้างชุมชน หรือการรับภาระรับผิดชอบบางอย่างควรเป็นการกระทำที่ตั้งใจและเป็นข้อยกเว้น
    ส่วนที่บอกว่า code of conduct และนโยบาย LLM เป็นการทำไว้โชว์ๆ ดูจะห่างจากประเด็นไปนิด แต่ก็เข้าใจได้เพราะเป็นหัวข้ออ่อนไหว

    • ไม่ได้หมายความว่า code of conduct หรือนโยบาย LLM ทุกอันเป็นการทำไว้โชว์
      แต่ถ้าเอาไปแปะไว้ในรีโปของคนเดียวที่ไม่มีทั้งผู้ใช้และชุมชน และก็ไม่ได้คิดจะสร้างในอนาคต มันก็กลายเป็นการทำไว้โชว์
      สำหรับรีโปที่ใช้คนเดียว ไม่จำเป็นต้องมี code of conduct สำหรับตัวเอง

  • คงจะดีมากถ้าการถกเถียงนี้มีแรงส่งและนำไปสู่ฉันทามติที่ใช้ได้จริง
    มีหลายวิธีในการสร้างซอฟต์แวร์และมีส่วนร่วมอย่างมีสุขภาวะ
    เพียงแต่บางวิธีเข้ากันไม่ได้ หรือไม่ตรงกับมาตรฐานสูงของโอเพนซอร์ส หรือมีต้นทุนด้านการมองเห็นและความนิยม หรือต้องใช้อุปกรณ์คนละแบบ เช่น ไลเซนส์, การโฮสต์เอง, หรือการไม่รับ code contribution
    อยากให้เราช่วยกันหาทางที่ดีซึ่งให้ ความสนุกและความยุติธรรม มาอยู่ข้างหน้าในซอฟต์แวร์ชุมชน

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

  • เห็นด้วยเลย
    เมื่อก่อนเคยมีโปรเจกต์ที่ดังอยู่บ้าง และต้องเครียดกับการจัดการบั๊กรายงานและ pull request สำหรับฟีเจอร์ที่ไม่ได้ต้องการ
    ถ้าตอนนั้นได้อ่านบทความแบบนี้ก็คงดี
    เพิ่มเติมคือ https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 ก็น่าอ่าน

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