Yaak ไคลเอนต์เดสก์ท็อป API เปลี่ยนเป็นโอเพนซอร์ส

• เมื่อ 3 เดือนก่อน ได้เผยแพร่บทความชื่อ "Why Not Open Source" ที่อธิบายเหตุผลว่าทำไม Yaak จึงไม่เป็นโอเพนซอร์ส
• เนื่องจากเคยประสบภาวะหมดไฟจากโครงการโอเพนซอร์สในอดีต จึงคิดว่าการแบ่งปันกระบวนการตัดสินใจนี้น่าจะเป็นประโยชน์กับผู้อื่น
• ผู้ใช้ Yaak ส่วนใหญ่เห็นด้วย แต่ในชุมชนโอเพนซอร์สวงกว้างกลับคัดค้านเนื้อหาส่วนใหญ่อย่างรุนแรง

ปฏิกิริยาจากชุมชนโอเพนซอร์ส

• "อย่าสับสนโอเพนซอร์ส/ซอฟต์แวร์เสรีกับรูปแบบทางสังคมหรือการมีส่วนร่วมแบบเฉพาะของ GitHub" - lobste.rs

• "แต่สิ่งเหล่านั้นทั้งหมดก็ใช้ได้กับซอฟต์แวร์ปิดซอร์สเหมือนกัน" - ycombinator.com

• "ข้อโต้แย้งของบทความนี้ไร้สาระสิ้นดี ฉันไม่รู้ด้วยซ้ำว่า 'แอป' นี้คืออะไร ไม่จำเป็น ไปลงถังขยะแห่งประวัติศาสตร์เถอะ" - reddit.com

• คำตอบส่วนใหญ่ไม่ได้สร้างสรรค์นัก แต่คอมเมนต์ 500 คำบน lobste.rs ยอดเยี่ยมมาก พออ่านแล้วก็เริ่มคิดว่าฉันอาจเป็นฝ่ายผิด

ข้อดีของโอเพนซอร์ส

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

เปลี่ยนเป็นโอเพนซอร์ส แต่เปิดรับคอนทริบิวชันอย่างจำกัด

• มีโครงการอย่าง SQLite ที่เป็นโอเพนซอร์ส แต่ไม่รับคอนทริบิวชันจากภายนอก
• Litestream ช่วงแรกก็ไม่รับคอนทริบิวชันเช่นกัน แต่ภายหลังก็เปลี่ยนมาอนุญาตเฉพาะการแก้บั๊ก
• Yaak ก็เลือกใช้โมเดลนี้ โดยเปลี่ยนเป็นโอเพนซอร์สภายใต้ไลเซนส์ MIT และรับคอนทริบิวชันเฉพาะการแก้บั๊ก

[rmekdma]

ผมประทับใจที่เขาอ่านคอมเมนต์จำนวนมาก แล้วคัดเลือกเนื้อหาที่สร้างสรรค์มารับฟังและนำไปปรับใช้ได้ เขาเป็นคนที่เปิดใจกว้างจริง ๆ

[savvykang]

คอมเมนต์ที่สร้างสรรค์ก็ยอดเยี่ยมมากเช่นกัน

[xguru]

นี่คือสรุปของคอมเมนต์ 500 ตัวอักษรบน lobster.rs ที่รวมอยู่ในเนื้อหาบทความ
คอมเมนต์นี้เขียนเกี่ยวกับบทความต้นฉบับ Why Not Open Source ?

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

การโต้แย้งแต่ละประเด็น

สามารถเพิ่มฟีเจอร์ได้ - 🟥 ในทางปฏิบัติยาก

• ไม่จำเป็นต้องรับทุกสิ่งที่ใครก็ตามส่งมาเพื่อให้เป็นโอเพนซอร์ส

ความโปร่งใสสูงขึ้น - 🟧 เพื่อความโปร่งใสไม่จำเป็นต้องเป็นโอเพนซอร์ส อาจทำได้ด้วยโรดแมปสาธารณะนอกจากโค้ด

• เป็นข้อสังเกตที่ดี แต่ไม่ได้หมายความว่ามีแค่โค้ดเท่านั้น มันคือมีโค้ดด้วย คุณสามารถมีทั้งโค้ดที่โปร่งใสและโรดแมปได้

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

• อย่างน้อยการทำเป็นโอเพนซอร์สก็ไม่ได้ทำให้แย่ลง อาจไม่ได้ดีขึ้นมากนัก แต่ก็ไม่มีข้อเสีย

ชุมชนจะเติบโต - 🟧 ต้องลงทุนลงแรงถึงจะเกิดขึ้น และไม่ได้จำกัดอยู่แค่โอเพนซอร์ส

• เช่นกัน มันไม่ได้แย่ลง แต่ก็ยอมรับได้ว่าผู้เขียนเองก็บอกว่าไม่ได้เกี่ยวข้องกันมากนัก

การโต้แย้งข้อเสีย

รับมือกับฟีดแบ็กที่หยาบคายได้ยาก

• ต่อให้เป็นซอร์สปิดก็ยังต้องได้รับฟีดแบ็กอยู่ดี ไม่ว่ากรณีไหนก็ไม่จำเป็นต้องรับมันไว้

จัดการวงจรฟีดแบ็กที่ยาวนานได้ยาก

• ก็แค่ไม่ต้องรับการส่งฟีดแบ็ก/การเปลี่ยนแปลง วงจรการปรับปรุงก็จะหายไป

ปฏิเสธ contribution ที่ส่งมาโดยไม่ได้รับการอนุมัติล่วงหน้าได้ยาก

• เขียนไว้ใน readme ว่า "ไม่รับ contribution" และตั้งให้ปิดทุก PR อัตโนมัติก็พอ

เมื่อโปรเจกต์โตเต็มที่แล้ว จะปฏิเสธเกือบทั้งหมดได้ยาก

• ต่อให้เป็นซอร์สปิด ผู้ใช้ก็จะยังคงร้องขอต่อไป

ถ้าผู้มีส่วนร่วมที่ดีจากไปจะลำบาก

• ก็แค่ไม่ต้องรับผู้มีส่วนร่วมคนอื่น ไม่ต่างกันไม่ว่าจะโอเพนหรือซอร์สปิด

ยากที่จะยอมรับว่าผู้คนทำงานโดยไม่ได้รับค่าจ้าง

• ซอฟต์แวร์เสรีไม่ได้แปลว่าฟรีเสมอไป ซอฟต์แวร์เสรีเชิงพาณิชย์ก็เป็นไปได้ และไม่จำเป็นต้องยอมรับว่าคนอื่นทำงานฟรี

การมี issue ที่ยังไม่ปิดเกิน 1,000 รายการดูไม่ดี

• ปิดอัตโนมัติก็พอ

ความรู้สึกว่าไม่มีวันจบเป็นเรื่องยาก

• การมีผู้ใช้/ลูกค้าในซอร์สปิดก็ไม่ต่างกัน