โอเพนซอร์สไม่ได้หมายถึงคอมมูนิตี้แบบเปิดเสมอไป
(blog.feld.me)- ซอฟต์แวร์โอเพนซอร์สสามารถเผยแพร่ได้ตั้งแต่ก่อนยุค (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 ตอนตีสองของคืนคริสต์มาสก็ได้ โดยไม่จำเป็นต้องถูกลากเข้าไปสู่รูปแบบการดูแลที่เหมือนเอาศูนย์บ่มเพาะเทคโนโลยีกับสถานรับเลี้ยงเด็กมาผสมกัน
2 ความคิดเห็น
ความคิดเห็นจาก Lobste.rs
เพราะความคิดแบบนี้ เลยสร้าง https://casuallymaintained.tech/ ขึ้นมา และชอบมันมาก
ตัวอย่างที่มีชื่อเสียงที่สุดคือ SQLite ซึ่งปฏิเสธการมีส่วนร่วมจากภายนอก
เมื่อคิดว่ามันถูกใช้แม้กระทั่งใน แอปพลิเคชันภารกิจสำคัญ อย่างเครื่องบินของ Airbus นี่ก็เป็นนโยบายที่สมเหตุสมผล
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 สำหรับตัวเอง
คงจะดีมากถ้าการถกเถียงนี้มีแรงส่งและนำไปสู่ฉันทามติที่ใช้ได้จริง
มีหลายวิธีในการสร้างซอฟต์แวร์และมีส่วนร่วมอย่างมีสุขภาวะ
เพียงแต่บางวิธีเข้ากันไม่ได้ หรือไม่ตรงกับมาตรฐานสูงของโอเพนซอร์ส หรือมีต้นทุนด้านการมองเห็นและความนิยม หรือต้องใช้อุปกรณ์คนละแบบ เช่น ไลเซนส์, การโฮสต์เอง, หรือการไม่รับ code contribution
อยากให้เราช่วยกันหาทางที่ดีซึ่งให้ ความสนุกและความยุติธรรม มาอยู่ข้างหน้าในซอฟต์แวร์ชุมชน
สภาพที่บทความเสนอคือสภาพตามธรรมชาติของทุกโครงการโอเพนซอร์สส่วนตัวที่คนไม่ดังเพิ่งสร้างขึ้นมา
พวกเราทุกคนต่างก็มีโปรเจกต์จำนวนไม่น้อยที่ดำเนินไปในลักษณะนั้น
ปัญหาคือผู้คนไม่รู้ว่าตัวเองอยากได้อะไรจากโปรเจกต์ หรือคิดว่าการดูแลโปรเจกต์ดังๆ คงเท่ดีโดยไม่ได้ชั่งต้นทุนให้ดีพอ
เลยเริ่มเกิด การแสวงหาความสนใจ ไม่ว่าจะตั้งใจหรือไม่ก็ตาม
คำพูดที่ว่า “GitHub ทำให้โอเพนซอร์สทั้งหมดกลายเป็นงานไร้ค่าจ้างสำหรับผู้ดูแล” จะจริงก็ต่อเมื่อคุณยอมให้มันเป็นแบบนั้น
หากตัดคำสัญญาเรื่องชื่อเสียงลอยๆ ออกไป ในสถานการณ์ส่วนใหญ่ GitHub แทบไม่มีคานงัดอะไรที่จะบังคับให้คุณทำสิ่งที่แต่เดิมก็ไม่อยากทำ
เห็นด้วยเลย
เมื่อก่อนเคยมีโปรเจกต์ที่ดังอยู่บ้าง และต้องเครียดกับการจัดการบั๊กรายงานและ pull request สำหรับฟีเจอร์ที่ไม่ได้ต้องการ
ถ้าตอนนั้นได้อ่านบทความแบบนี้ก็คงดี
เพิ่มเติมคือ https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 ก็น่าอ่าน
สำหรับโปรเจกต์เล็กๆ ฉันเห็นด้วยกับบทความนี้อย่างมาก
แม้แต่โปรเจกต์ใหญ่กว่า หลายอันที่ประสบความสำเร็จที่สุดก็มักไม่ได้เริ่มจากการเป็นชุมชนเปิดตั้งแต่แรก
หลายโปรเจกต์ที่ชอบเริ่มพัฒนาในองค์กรขนาดใหญ่ และแก่นสำคัญคือซอฟต์แวร์นั้นถูก ใช้งานจริงอย่างหนักภายในองค์กร
ดังนั้นผู้ดูแลก็ได้รับค่าตอบแทนอยู่แล้ว
ไม่ว่าจะเป็นโปรเจกต์ส่วนตัวหรือทีมภายใน ซอฟต์แวร์ที่สร้างขึ้นเพื่อแก้ปัญหาในชีวิตประจำวันของนักพัฒนาเอง ดูจะประสบความสำเร็จมากกว่าและเอาเปรียบน้อยกว่าซอฟต์แวร์ที่ทำขึ้นเพื่อชื่อเสียงหรือการต่อยอดเชิงธุรกิจ
ความคิดเห็นใน Hacker News
แม้แต่ชุมชนที่ปิดมากที่สุดก็มักยอมรับการมีส่วนร่วม หากคุณส่งอีเมลอย่างสุภาพ
มีนักพัฒนาโอเพนซอร์สคนหนึ่งที่เคยปิด pull request และฟังก์ชันหลายอย่างของรีโพซิทอรีไป เพราะเหนื่อยล้าจากการถูกคุกคาม และในช่วงนั้นก็ได้ชื่อเสียงว่าเป็นคนเรื่องมากมากด้วย
ตอนนั้นฉันไม่รู้เบื้องหลัง แค่คิดว่าโปรเจกต์นี้คงทำงานแบบนี้อยู่แล้ว เลยไปหาอีเมลเขามาแล้วส่งแพตช์แบบไม่เป็นทางการพร้อมอีเมลสุภาพที่ไม่กดดัน โดยย้ำชัดว่าเขาจะใช้หรือจะเมินก็ได้
นักพัฒนาคนนั้นตอบกลับมาว่าขอบคุณ อธิบายสถานการณ์ และถึงขั้นขอโทษที่ทำให้ไม่สะดวก พร้อมบอกว่าไม่รู้จะรับมืออย่างอื่นได้นอกจากล็อกทุกอย่างไว้ แล้วก็รวมการแก้ไขนั้นเข้าไปตามคาด
ตอนแรกนึกว่าบทความนี้จะพูดถึงปัญหาที่แพร่หลาย คือโปรเจกต์ซอฟต์แวร์เสรีบังคับให้การคุยหรือรายงานบั๊กต้องทำผ่าน Discord
ช่วงหนึ่งถึงสองสัปดาห์เหมือนจะมีแรงผลักดันให้ย้ายไปใช้เครื่องมืออื่น แต่ตอนนี้เหมือนกระแสนั้นหมดไปแล้ว สุดท้ายทุกคนก็ดูเหมือนจะยอมแพ้และกลับไปใช้ Discord กันหมด
ไม่ถึงกับว่า Discord แย่สุดขั้ว แต่มันไม่คงอยู่ถาวรและบังคับให้ใช้เว็บแอปขนาดใหญ่เทอะทะ
ในมุมของคนรุ่นเก๋า ฉันชอบท่าทีของผู้เขียน
ฉันแก่พอจะจำยุคที่ได้นั่งต่อหน้ารุ่นบุกเบิก ARPANET จำยุคที่มีเลข 1 แค่อย่างเดียวจนต้องเหลาออกด้วยมือให้ครึ่งหนึ่งกลายเป็น 0 ได้
ในสมัยก่อนที่พัฒนาซอฟต์แวร์กันแบบเดิม โปรเจกต์ส่วนใหญ่เขียนหรือดูแลโดยคนหนึ่งหรือสองคน และทั้งอินเทอร์เน็ตก็รู้ที่อยู่อีเมลของพวกเขาแล้วส่งรายงานบั๊กตรงไปได้
บางโปรเจกต์คุยกันบน IRC หรือ mailing list และโดยมากทุกคนก็วางตัวแบบมืออาชีพ ถ้าไม่เป็นแบบนั้นก็จะถูกลบออกจาก mailing list หรือโดนใส่ในไฟล์บล็อกของ iirc กับ pine
ประเด็นสำคัญคือ ในช่วงเวลาใดก็ตาม กลุ่มนักพัฒนาที่ทำงานอยู่จริง มีขนาดเล็กมาก
ฉันกำลังพูดถึงยูทิลิตีเล็ก ๆ อย่าง make, Sendmail, sed, awk และแม้แต่ Perl ก่อนปี 1990 ก็ดูเหมือนจะมีแค่ Larry Wall กับ tchrist เป็นหลัก
gcc เป็นข้อยกเว้นสุดบ้าคลั่งที่มีคนส่งแพตช์กันเป็นพัน และถ้าอยากให้อัปสตรีมรับเข้าไปก็ต้องประสานกับ RMS ให้ดีด้วย
เครื่องมือใหม่ ๆ รองรับให้ทีมใหญ่โต้ตอบกันต่อเนื่องได้ดีกว่า และการทำงานแบบทีมเล็กที่ไม่ต้องสนใจคนทั้งอินเทอร์เน็ต เว้นแต่คนนั้นจะเอาไตข้างหนึ่งมาเดิมพันกับการส่งแพตช์ ก็มีข้อดีมากเหมือนกัน
เพียงแต่วิธีนั้นไม่ใช่ข้อดีในแง่การดึงคนเข้ามาทำงานด้วย ดังนั้นจะใช้วิธีแบบเก่าก็ได้ แต่ทีมจะเล็กลงและอาจดึงผู้ใช้ได้ยากขึ้น
ถึงอย่างนั้นผู้ใช้จะคิดยังไงก็ไม่ใช่เรื่องของฉัน ฉันใช้ซอฟต์แวร์เพื่อรองรับกรณีใช้งานของตัวเอง และเปิดเป็นโอเพนซอร์สไว้เผื่อจะมีประโยชน์กับคนอื่นด้วย
ถ้าจะพูดให้เฉพาะเจาะจงกว่านั้น โอเพนซอร์สรับประกันแค่เสรีภาพพื้นฐาน 4 ข้อ(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
นอกเหนือจากนั้นไม่ได้รับประกันอะไรเลยตามตัวอักษร และไม่ได้แปลว่าฟรีด้วย
ซอฟต์แวร์เสรีและโอเพนซอร์สสามารถคิดเงินได้ และก็ควรคิดเงินได้ คำว่า “free” ในที่นี้ไม่ได้พูดถึงเงิน
ฉันมองการโจมตี “ซัพพลายเชน” ของโอเพนซอร์สหลายครั้งที่เกิดขึ้นในชุมชนต่าง ๆ ช่วงหลังในแง่ค่อนข้างบวก เพราะอย่างน้อยในแง่ดีมันอาจช่วยให้คนตระหนักว่าโอเพนซอร์สไม่ใช่ซัพพลายเชน
รายละเอียดอยู่ที่ https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
ถ้าคุณไม่ได้จ่ายเงินให้ผู้ขาย หรือไม่มีสัญญาที่รับประกันกำหนดการต่าง ๆ ก็แปลว่าไม่ได้มีซัพพลายเชนอยู่
ไลเซนส์ FOSS แทบทั้งหมดมีข้อความทำนองว่า “ซอฟต์แวร์นี้ให้มาโดยไม่มีการรับประกัน” และซัพพลายเชนมีนัยว่าต้องมีการรับประกัน ดังนั้น FOSS จึงไม่ใช่ซัพพลายเชน
เบื่อมากที่เห็นคนที่นี่ทำเหมือน “โอเพนซอร์ส” มี “คุณค่าทางศีลธรรม” และจับแนวคิดที่ขโมยมาจากซอฟต์แวร์เสรีมาปนกันเหมือนเป็นเรื่องเดียวกัน
โอเพนซอร์สก็แค่สิ่งที่บริษัทซอฟต์แวร์ยักษ์ใหญ่ใช้เอาจากอาสาสมัครจำนวนมหาศาล
พวกสาย code of conduct มีอยู่เพื่อก่อปัญหาเท่านั้น
แค่ดูข้อถกเถียงปุ่มแดง/ปุ่มน้ำเงินก็พอ วาทะรุนแรงพวกนั้นจะฟังขึ้นก็ต่อเมื่อมีปุ่มนั้นอยู่จริง หรือผู้คนชอบทำตัวเลวกันอยู่แล้ว
ผู้สนับสนุน code of conduct ที่มีเจตนาดี กำลังพูดถึงเสรีภาพในการสมาคมและเสรีภาพในการแสดงออก
เช่น ถ้าแพลตฟอร์มไม่ชอบใครแล้วจะแบนเขาได้ไหม หรือควรจัดการแค่ด้วยธรรมเนียมเชิงปฏิบัติของ mailing list ที่ว่า “ทำตัวให้สุภาพ”
แน่นอนว่าสุดท้ายขึ้นอยู่กับว่าใครถืออำนาจตัดสินใจ แต่เรื่องนั้นก็เป็นจริงกับทุกโปรเจกต์อยู่แล้ว
จะไปเรียกร้องขอมีส่วนร่วมในโปรเจกต์ของคนอื่น พร้อมตั้งเงื่อนไขที่ขัดกับความต้องการของผู้นำโปรเจกต์ แล้วในขณะเดียวกันก็อ้างเสรีภาพในการสมาคมไม่ได้
ถ้าเดาเอา ความหมายที่ผู้เขียนบอกว่า “ไม่จำเป็นต้องมี Code of Conduct แบบแสดงออกเชิงสัญลักษณ์” อาจหมายถึงว่า ถ้าเป็นโปรเจกต์เล็ก ๆ ที่แค่อยากแชร์ให้โลกใช้ และอยากเปิดทางเลือกไว้เผื่อวันหนึ่งจะรับการมีส่วนร่วมจากภายนอก ก็ไม่จำเป็นต้องเตรียม code of conduct ตั้งแต่ก่อนจะเจอสถานการณ์จริง
ไม่จำเป็นต้องปวดหัวกับปัญหาสมมุติล้วน ๆ
เหตุผลที่ต้องมี code of conduct ก็เพราะทางเลือกอีกด้านคือการลงโทษการละเมิดแบบตามอำเภอใจ หรือไม่ก็ปล่อยเป็น อนาธิปไตยของสแปม เต็มรูปแบบ
ฉันไม่เข้าใจจริง ๆ ว่าคนที่เคยเทศนาเรื่อง netiquette ในอดีต ทำไมตอนนี้ถึงต่อต้านความชัดเจนและชุมชนที่ดีขนาดนี้
คิดอีกทีก็อาจเป็น Goomba fallacy หรือไม่ก็คนที่ดูแคลน code of conduct อาจเป็นพวกเดียวกับที่เคยก่อ flame war กับสแปมใน Usenet ยุค 1990 ก็ได้
โอเพนซอร์สไม่ใช่แค่การเลือกไลเซนส์
มันคือการนำ ซอฟต์แวร์เสรี มาปรับกรอบใหม่ให้ดูน่าดึงดูดต่อภาคธุรกิจมากขึ้น และหัวใจของโอเพนซอร์สคือความเชื่อว่าการพัฒนาซอฟต์แวร์ร่วมกับสาธารณะมีประสิทธิภาพกว่าการให้บริษัทพัฒนาแบบปิดเองล้วน ๆ
เพราะฉะนั้นโอเพนซอร์สจึงมีนัยของชุมชนที่เปิด
ถ้าคุณอยากปล่อยโค้ดให้สาธารณะภายใต้ไลเซนส์แบบ permissive แต่ไม่อยากทำงานพัฒนาแบบร่วมมือกัน แน่นอนว่าคุณก็ทำได้ และโค้ดนั้นก็ยังเป็นโค้ดโอเพนซอร์ส
การเปิดโค้ดเป็นเรื่องดี และคุณไม่ได้มีหน้าที่ต้องทำมากกว่านั้น แต่ก็ไม่ใช่การทำตามจุดประสงค์ที่โอเพนซอร์สถูกออกแบบมา และเป็นการมองข้ามส่วนสำคัญบางอย่างของมัน
คนที่เห็นโค้ดโอเพนซอร์สแล้วสมมุติว่ามีการพัฒนาแบบร่วมมือกันอยู่ ก็ไม่ได้ไร้เหตุผล
เพราะนั่นคือจุดมุ่งหมายของขบวนการโอเพนซอร์ส
กับซอฟต์แวร์ของคุณ สมมุติฐานนั้นอาจใช้ไม่ได้ ซึ่งก็ไม่เป็นไร แต่ฝ่ายที่กำลังทำลายบรรทัดฐานทางสังคมไม่ใช่พวกเขา แต่เป็นคุณ
ฉันนึกถึง Stallman, ไดรเวอร์เครื่องพิมพ์ และเรื่องที่ผู้ใช้ควรเป็นเจ้าของงานของตัวเอง ดังนั้นคำยืนยันเรื่องจุดประสงค์ของโอเพนซอร์สแบบนั้นฟังดูไม่ถูกนัก
https://en.wikipedia.org/wiki/The_Open_Source_Definition
ในนั้นไม่ได้พูดถึงการพัฒนาแบบร่วมมือกันเลย
คนมักใช้อารมณ์ และมักต้องมาคอยดูแลผู้ใช้ใหม่ที่ไม่อยากเรียนรู้พื้นฐาน หรือผู้ใช้ทั่ว ๆ ไป
ควรรักษาความสัมพันธ์แบบ แยกจากฟอรัมซัพพอร์ต แต่เข้มงวด ตอบตรงเวลาแต่ไม่สนิทสนม
coreboot หรือ MrChromebox เป็นตัวอย่างที่ดี เขาจะตอบเฉพาะเมื่อจำเป็น
เห็นด้วย และขอเสริมอีกข้อว่า ไม่จำเป็นต้องทำหน้าเว็บการตลาดเพื่อเกลี้ยกล่อมให้คนมาใช้ซอฟต์แวร์ของคุณ
จะทำแทนหรือทำควบคู่กันไปด้วยการอธิบายเหตุผลทุกข้อว่าทำไมไม่ควรใช้ซอฟต์แวร์นี้ก็ได้
ยิ่งมีผู้ใช้มาก ปัญหาก็มากขึ้น
แอปพลิเคชัน FOSS ไม่จำเป็นต้องเผยแพร่สู่สาธารณะเสมอไป นั่นเป็นแค่ความคาดหวังทางสังคมที่พบได้บ่อย
การเป็น FOSS ก็ไม่ได้แปลว่าต้องให้โค้ดกับคนที่ไม่ใช่ลูกค้า และใครเป็นลูกค้าก็เป็นคนพัฒนากำหนด
FOSS สนับสนุนให้ขายเพื่อเงินได้ และคุณยังสามารถขายซอฟต์แวร์ของคนอื่นที่เดิมแจกฟรีได้ด้วย (ดู https://www.gnu.org/philosophy/selling.en.html)
โอเพนซอร์สที่ติดไลเซนส์ไม่เสรียังคงเป็นโอเพนซอร์สได้ แต่ไม่ใช่ FOSS และนักพัฒนาไม่จำเป็นต้องอายที่จะเลือกใช้ไลเซนส์โอเพนซอร์สแบบไม่เสรี หากมันช่วยให้หาเงินจากซอฟต์แวร์ได้มากขึ้น หรือเพิ่มข้อจำกัดที่เป็นประโยชน์กับตัวเอง
มันอาจเป็น copyleft ได้ด้วย
สรุปคือ เราทำ LICENSE.md กันและพึ่งพามันมาก แต่ไม่เคยมีใครคิดจะทำ SOCIAL.md
พอมีใครบอกว่า “โอเพนซอร์ส” คนจำนวนมากก็จะสมมุติว่า “ผู้เขียนกำลังทำสิ่งนี้เพื่อผู้คน เพื่อสังคม และเพื่อโลกโดยรอบ และเขาสนใจการพัฒนาโปรเจกต์ การเพิ่มฟีเจอร์ใหม่ โดยเฉพาะฟีเจอร์ที่ฉันต้องการ รวมถึงการปรับปรุงเพื่อประโยชน์ของผู้ใช้ทุกคน ถ้าไม่ใช่อย่างนั้นแล้วจะเปิดมันออกมาทำไม?”
แต่นี่เป็นเพียงความคาดหวังทางสังคมที่พบบ่อยที่สุดต่อ FOSS เท่านั้น ห่างไกลจากการเป็นกรณีเดียว
การไม่มีเส้นแบ่งระหว่างโอเพนซอร์สเชิงเทคนิคกับโอเพนซอร์สเชิงสังคม คือสาเหตุหลักของความไม่ลงรอย การโต้เถียง และท้ายที่สุดคือ ภาวะหมดไฟ ที่เกิดจากความคาดหวังทางสังคมที่ไม่ตรงกัน
เมื่อก่อนฉันต้องอธิบายเรื่องนี้และความแตกต่างนี้ให้มวลชนที่โกรธแค้นฟัง แต่ล่าสุดฉันเห็นในบทความของ Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ ว่าเขาเปรียบโค้ดโอเพนซอร์สเหมือนของขวัญ
คำอธิบายของฉันสุดท้ายก็คือ “ถ้าไม่ชอบของขวัญชิ้นนั้นและมันไม่เหมาะกับคุณ ก็ทิ้งมันไปแล้วลืมมันเสีย”
มีไลเซนส์ที่ OSI อนุมัติแต่ FSF ไม่ถือว่าเป็นซอฟต์แวร์เสรีอยู่เพียงไม่กี่ตัวเท่านั้น
ดูรายชื่อยาว ๆ ของไลเซนส์ซอฟต์แวร์เสรีที่ไม่เข้ากันกับ GPL ได้ที่ https://www.gnu.org/licenses/license-list.html
อีกอย่าง “โอเพนซอร์สที่ไม่ใช่ FOSS” ก็ฟังไม่เข้าท่า เพราะ FOSS ย่อมาจาก Free and Open Source Software ตามตัวอักษร
ตอนนี้ใคร ๆ ก็ขึ้น GitHub ได้แทบจะทันทีพร้อมไฟล์รันได้ โดยไม่ต้องผ่านเว็บไซต์น่าสงสัยหรือ build pipeline แปลก ๆ อีกต่อไป
ไม่มี “ชุมชน” ไม่มีการเมือง ไม่มี code of conduct ไม่มี pull request หรือ issue ไม่มีวิกิ ไม่มีทีมแกนหลัก ฟังดูเหมือนสวรรค์เลย
เดี๋ยวนี้รู้สึกว่ามี ชุมชน มากเกินไปที่กลับกลายเป็นโทษกับตัวโปรเจกต์เอง
ยิ่งไปกว่านั้น ฉันนึกไม่ออกเลยสักครั้งว่าชุมชนเคยช่วยโปรเจกต์โอเพนซอร์สในทางใดทางหนึ่งจริง ๆ
ถ้าเป้าหมายคือเพิ่มอำนาจควบคุมให้สูงสุดโดยยอมแลกกับคุณภาพ ก็ถือว่าโอเค
แต่ในกรณีนั้นก็อดสงสัยไม่ได้ว่าคุณกำลังมองหา FLOSS อยู่จริงหรือเปล่า