- โครงการ WiX Toolset ได้นำนโยบาย Open Source Maintenance Fee (ค่าบำรุงรักษาโอเพนซอร์ส) มาใช้ เพื่อให้มั่นใจถึง ความยั่งยืนในการบำรุงรักษา ในระยะยาว
- แม้ซอร์สโค้ดจะเปิดให้ใช้ฟรีตาม ไลเซนส์ แต่ งานส่วนใหญ่ เช่น การเปิด issue, การเขียนความเห็น, การดาวน์โหลดรีลีสใหม่ จะอยู่ภายใต้นโยบายค่าบำรุงรักษานี้
- โดยเฉพาะกรณีที่มีการนำโครงการนี้ไปใช้เพื่อ สร้างรายได้ จะต้องชำระค่าบำรุงรักษาดังกล่าว
- สามารถสนับสนุนการชำระค่าใช้จ่ายได้ด้วยการเป็น GitHub Sponsor
- องค์กรขนาดเล็ก (น้อยกว่า 20 คน): $10/mo
- องค์กรขนาดกลาง (20-100 คน): $40/mo
- องค์กรขนาดใหญ่ (มากกว่า 100 คน): $60/mo
- ดูรายละเอียดนโยบายเพิ่มเติมได้ที่ เว็บไซต์ทางการ Open Source Maintenance Fee
2 ความคิดเห็น
โดยพฤตินัยแล้วก็เหมือนกับ RHEL นั่นแหละ
ความคิดเห็นบน Hacker News
ฉันชอบความเปลี่ยนแปลงครั้งนี้ แนวคิดพื้นฐานคือ ไม่มีใครอยากให้สิ่งนี้กลายเป็น closed source และโค้ดก็เปิดให้ทุกคนใช้อย่างเสรีอยู่แล้ว เพราะต้นทุนในการแจกจ่ายโค้ดแทบเป็นศูนย์ แต่ผู้ดูแลโครงการก็ไม่ได้อยากทำงานให้บริษัทแบบฟรี ๆ ราวกับเป็นงานการกุศล เวลาของพวกเขามีจำกัด ดังนั้นถ้าต้องมีส่วนร่วมกับกิจกรรมที่สร้างรายได้ ก็เป็นเรื่องธรรมดาที่จะอยากได้ส่วนแบ่งรายได้บ้าง แม้ระบบนี้จะบังคับใช้ไม่ได้สมบูรณ์ก็ไม่เป็นไร อย่างน้อยตอนนี้ผู้ดูแลสามารถตอบข้อเรียกร้องได้ว่า “ถ้าอยากให้เราใส่ใจ ก็จ่ายเงินมา” บริษัทที่จ่ายเงินก็จะได้การสนับสนุนในระดับหนึ่ง ส่วนผู้ใช้ทั่วไปก็ยังได้ประสบการณ์แบบเดิม มีแต่บริษัทที่เมินคำเตือนนี้เท่านั้นที่จะต้องรับผลตามมา และมันมีประสิทธิภาพมากโดยเฉพาะเวลาเจอคำพูดแนว ๆ “มีผู้ใช้สำคัญจำนวนมากได้รับผลกระทบ” ถ้าจำเป็นจริงก็ควรจ่ายเงิน ตอนนี้ที่มีโค้ด รายงาน ฯลฯ จาก AI เพิ่มขึ้นเรื่อย ๆ ฉันคิดว่านี่เป็นวิธีรับมือกับปัญหาที่เจอในโอเพนซอร์สบ่อย ๆ ได้ค่อนข้างสะอาด
ฉันรู้สึกก้ำกึ่งกับประเด็นนี้ ไม่ได้ใช้ Wix และนี่เป็นความเห็นทั่วไปต่อเรื่องนี้ ไม่ใช่ต่อกรณีนี้โดยเฉพาะ โปรเจกต์โอเพนซอร์สไม่มีใครบังคับให้ต้องดูแลต่อได้ ทุกการแก้ไขเป็นความสมัครใจ ไม่มีบริษัทไหนบังคับให้รับ PR หรือให้ลงมือทำงานได้ นักพัฒนา FOSS มักเครียดกันบ่อย แต่ถ้าไม่มีแรงจูงใจทางการเงิน ก็แค่ปฏิเสธได้เลย จะมีคนบ่นก็ได้ แต่ก็ไม่ได้มีหน้าที่ต้องแก้ให้ โมเดลแบบสปอนเซอร์ทำให้รู้สึกเหมือนกำลังเปลี่ยน FOSS ให้กลายเป็นโมเดลธุรกิจ แล้วแบบนั้นมันก็ไม่ใช่ FOSS แล้ว แก่นของ FOSS คือใครก็อปปี้ ดัดแปลง และพัฒนาไปเป็นธุรกิจได้ ซึ่งใบอนุญาตส่วนใหญ่ก็ยอมรับตรงนี้ ฉันรู้ว่าความเห็นนี้อาจไม่เป็นที่นิยม แต่ก็ไม่คิดว่าจำเป็นต้องโกรธกันขนาดนั้นในเรื่องนี้
ผมอยากพูดถึงข้อเสียของนโยบายนี้ในสองมุม มุมแรกคือมันอาจทำให้ดึงผู้ร่วมพัฒนามาเพิ่มได้ยากขึ้น เพราะอาจเกิดโครงสร้างสองชั้นระหว่างผู้มีส่วนร่วมที่ได้เงินกับคนที่ไม่ได้ เช่น ความรู้สึกว่า “ฉันแก้บั๊กฟรี แต่คนอื่นได้เงิน” มุมที่สองคือพอเริ่มรับเงิน มันก็มีลักษณะเป็นธุรกรรมมากขึ้น เมื่อรับเงินแล้วก็ย่อมมีความคาดหวังและงานตามมา แน่นอนว่าโมเดลอาสาสมัครเองก็มีปัญหาเรื่องความยั่งยืนเหมือนกัน
ฉันไม่ได้คิดว่านี่จะเป็นนวัตกรรมอะไรขนาดนั้น มันก็แค่เปลี่ยนจากการให้ของฟรีมาเป็นขายแบบเสียเงิน ซึ่งก็รู้สึกว่าแค่ดำเนินการเหมือนธุรกิจทั่วไป
ผมคิดว่าน่าจะดีกว่าถ้าเปิดให้ใครก็ได้จ่ายเงินเพื่อฟีเจอร์หรือการสนับสนุนที่ต้องการ แล้วเก็บโค้ดไว้เป็น closed source จนกว่าจะถึงเกณฑ์หนึ่ง เกณฑ์นั้นอาจใช้เวลาหลายเดือนหรือหลายปีขึ้นกับความสนใจและรายได้ สุดท้ายค่อยปล่อยเป็นโอเพนซอร์ส ไม่อย่างนั้นทุกคนก็จะรอให้คนอื่นเป็นฝ่ายจ่ายแทน แน่นอนว่าต้องออกแบบโครงสร้างให้ดีเพื่อไม่ให้แตก fork กันเยอะเกินไป แต่ผมคิดว่าทำได้แน่
ผมนึกว่าโปรเจกต์โอเพนซอร์สหลายตัวก็ใช้วิธีนี้กันอยู่แล้ว ผมนึกถึงกรณีของที่ปรึกษาที่ดูแล Busybox ว่าเข้าข่ายนี้ แต่อาจเป็นผมเข้าใจสถานการณ์ผิดก็ได้
เรื่องนี้ไม่เกี่ยวอะไรกับ Wix ที่เป็นเว็บสร้างเว็บไซต์เลย สิ่งที่พูดถึงที่นี่คือ WiX Toolset
คำโปรยคือ “ชุดเครื่องมือสำหรับสร้างประสบการณ์การติดตั้งบน Windows ที่ทรงพลังที่สุด Open Source มาตั้งแต่ปี 2004!”
ขอบคุณ ตอนแรกฉันก็เข้าใจว่าเป็น Wix เหมือนกัน Wix ทำไลบรารี React Native คุณภาพสูงไว้เยอะมากจริง ๆ
เมื่อไม่กี่เดือนก่อน ตอนผมกำลังพิจารณา installer สำหรับโปรเจกต์โอเพนซอร์สของตัวเอง ผมก็ไปเจอนโยบายนี้เข้าโดยบังเอิญ ถ้าซอร์สโค้ดอยู่ภายใต้ใบอนุญาตของ OSI ผมไม่มีปัญหากับการขายไบนารี แต่ผมติดใจกับข้อความนี้ใน README: "เพื่อความยั่งยืนระยะยาวของโปรเจกต์นี้ การใช้งาน WiX Toolset ต้องมีค่าบำรุงรักษาโอเพนซอร์ส ซอร์สโค้ดให้ใช้งานได้อย่างเสรีภายใต้ใบอนุญาต แต่ฟังก์ชันอื่นทั้งหมด เช่น การเปิด issue/คอมเมนต์ การเข้าร่วม discussion และการดาวน์โหลด release ก็ต้องปฏิบัติตามค่าบำรุงรักษาเช่นกัน กล่าวคือ หากใช้เพื่อวัตถุประสงค์แสวงหากำไร จะต้องมีค่าบำรุงรักษา" ผมคิดว่านี่เป็นแนวคิดที่อธิบายสั้น ๆ ได้ยาก จึงอาจตีความด้วยเจตนาดีได้ แต่การสรุปว่าให้จ่ายเมื่อใช้เชิงพาณิชย์กลับอาจทำให้คนเข้าใจผิดมากกว่า เพราะภายใต้ใบอนุญาต MS-RL ถ้าคุณ build ใช้เอง ก็ไม่มีข้อจำกัดแม้ใช้เชิงพาณิชย์ มันเลยให้ความรู้สึกเหมือนเป็นกลยุทธ์ “ขู่ให้กลัว” เพื่อผลักให้ผู้ใช้เชิงพาณิชย์กลายเป็นผู้สนับสนุน ผมเข้าใจความลำบากของผู้ดูแลโอเพนซอร์ส แต่แนวทางนี้ในเชิงจริยธรรมมันไม่ค่อยถูกจริตผม สุดท้ายเลยเลิกใช้ WiX ทั้งที่ผมไม่ได้เป็นผู้ใช้เชิงพาณิชย์ด้วยซ้ำ
นี่คือการแสดงจุดยืนอย่างชัดเจนว่าจะไม่ให้การสนับสนุนผู้ใช้เชิงพาณิชย์แบบฟรี ๆ คุณบอกว่าคำอธิบายไม่ชัด แต่ในข้อความที่คุณยกมาก็เขียนชัดอยู่แล้วว่า “ซอร์สสามารถใช้งานได้อย่างเสรีตามใบอนุญาต”
สตาร์ทอัพหรือบริษัทเล็กที่เงินไม่มากมักจะหยิบโปรเจกต์โอเพนซอร์สมาสร้างเอง ทำเป็นอาร์ติแฟกต์สำหรับแจกจ่าย และดูแลกันเอง พอถึงระดับหนึ่ง การจ่ายเงินเพื่อให้มีการสนับสนุนอย่างเป็นทางการที่ดูแลกระบวนการทั้งหมดให้จะคุ้มค่ากว่า นโยบายนี้คือการผลักให้บริษัทต่าง ๆ ยอมจ่ายค่าซัพพอร์ตอย่างเป็นทางการ เมื่อพวกเขาไม่อยากรับความเสี่ยงของการพึ่งพาโอเพนซอร์สไบนารีแบบไม่มีซัพพอร์ตโดยตรง
ไอเดียนี้อธิบายให้สั้นในประโยคเดียวได้ยากจริง ๆ เพราะความคาดหวังต่อโปรเจกต์โอเพนซอร์สแตกต่างกันมาก ถ้าคุณมีข้อเสนอว่าควรปรับข้อความอย่างไร ผมยินดีฟังเสมอ
ในมุมผม มันคือถ้าคุณมาพูดคุยเพื่อเรียกร้องอะไรบางอย่างในนามขององค์กรที่แสวงหารายได้ คุณต้องจ่ายเงินก่อนถึงจะคุยได้ เป็นโครงสร้างที่การสื่อสารเพื่อผลประโยชน์ทางธุรกิจต้องมีค่าใช้จ่าย
ถ้าไปอ่านคอมเมนต์ใน GitHub issue ผมว่าทีมนี้ค่อนข้างมีเหตุผล จากที่ผมเข้าใจ พวกเขาอยากได้เงินเฉพาะกรณีที่มีรายได้จริง ๆ ถ้าเป็นนักพัฒนาเดี่ยวจริง ๆ หรือเป็นโปรดักต์ระยะเริ่มต้น ก็คงไม่ได้ซีเรียสขนาดนั้น นอกจากนี้ยังมี หน้า sponsorship ด้วย
ผมอยากพูดถึงตัวเว็บไซต์ https://opensourcemaintenancefee.org/ เอง มันดูได้ดีเฉพาะใน dark mode แต่ใน light mode แทบอ่านไม่ออกเลย และก็เปิด issue ใน repo ไม่ได้ด้วย เผื่อคนเขียนจะมาเห็นคอมเมนต์นี้ที่นี่บ้าง(แม้โอกาสจะน้อย)
อ้อ ต้องจ่ายค่าบำรุงรักษาก่อนถึงจะเปิด issue ได้สินะ! ล้อเล่นนะ
โอ้ เป็นปัญหาร้ายแรงจริง ๆ ตอนนี้มีผู้ร่วมพัฒนาแบบสุ่มช่วยแก้ให้แล้ว!
ถ้าเป็นทีมกฎหมายของบริษัทผม เจอ EULA แบบนี้แทนที่จะจ่ายเงินให้ ก็คงสั่งให้หยุดใช้เครื่องมือนี้ทันที ผมคิดว่าบริษัทส่วนใหญ่ก็น่าจะตอบสนองแบบนี้เหมือนกัน ซึ่งบางทีในมุมผู้ดูแลอาจโอเคก็ได้ แต่ส่วนตัวผมพูดมาตลอดว่า ถ้าอยากคงความเป็นโอเพนซอร์สไว้พร้อมจำกัดการใช้เชิงพาณิชย์ ก็ควรใช้ AGPL ไปเลย AGPL แทบเป็นยาพิษสำหรับองค์กร ไม่มีบริษัทไหนที่ผมเคยทำงานด้วยยอมให้ใช้โค้ด AGPL ในผลิตภัณฑ์เชิงพาณิชย์ หลังจากนั้นก็ค่อยขาย commercial license แยกแบบมีค่าใช้จ่าย
โปรเจกต์โอเพนซอร์สมักทำงานเหมือนระบบการกุศลและระบบเกียรติยศ ผู้ร่วมพัฒนาได้ชื่อเสียง ส่วนบริษัทที่นำไปใช้ก็ได้กำไร เป็นโมเดลที่ทั้งสองฝ่ายได้ประโยชน์ และทางอ้อมก็ช่วยมนุษยชาติด้วย ส่วนตัวผม—ซึ่งอาจจะไร้เดียงสา—คิดว่าความเป็นการกุศลนี้น่าจะส่งผลกลับสู่มนุษยชาติโดยตรงและชัดเจนกว่านี้ได้ เช่น เมื่อโปรเจกต์ถูกปล่อยภายใต้ไลเซนส์สาธารณะ บริษัทที่นำมันไปสร้างรายได้ก็ควรบริจาคราว 1% ของรายได้เข้ากองทุนระดับโลกชื่อ "Decentralized Universal Kindness Income" (DUKI) บริษัทที่เป็นผู้มีส่วนร่วมหลักอาจได้รับสิทธิยกเว้นการบริจาคทั้งหมดหรือบางส่วน จึงยังคงได้เปรียบบ้างแม้บริษัทใหญ่รายอื่นจะเอาไปใช้แข่งด้วย(และนี่ก็เป็นเหตุผลที่ Redis เปลี่ยนไลเซนส์) ผู้ร่วมพัฒนาก็จะได้รับการยอมรับและชื่อเสียงในระดับโลกมากขึ้น ส่วนบริษัทที่บริจาคก็ไม่เพียงใช้ทรัพยากรโอเพนซอร์สได้กว้างขวางขึ้น แต่ยังได้ผลเชิงภาพลักษณ์ด้านการตลาดด้วย อาจแข่งขันได้ดีกว่าบริษัทที่สนใจแต่กำไรอย่างเดียว ผมเรียกสิ่งนี้ว่า “DUKI license” แก่นของมันคือเพิ่มเงื่อนไขแบ่งผลประโยชน์เข้าไปข้อเดียวบน MIT license น่าเสียดายที่ผมไม่มีอิทธิพลพอจะทำการตลาดให้มัน และก็ไม่รู้ว่าผู้ดูแลหลักกับผู้ก่อตั้งที่ขับเคลื่อนระบบนิเวศโอเพนซอร์สจะยอมรับหรือเปล่า
มีข้อความว่า “แม้ซอร์สโค้ดจะเปิดให้ใช้อย่างเสรีภายใต้ใบอนุญาต แต่กิจกรรมอื่นทั้งหมด เช่น การเปิด issue/คอมเมนต์ การเข้าร่วม discussion และการดาวน์โหลด release ต้องปฏิบัติตามค่าบำรุงรักษา” ผมแปลกใจตรงที่รวมการดาวน์โหลด release เข้าไปด้วย ผมไม่ใช่ทนาย แต่ดูแล้วมันเหมือนขัดกับตัวไลเซนส์เอง โดยเฉพาะข้อความที่ว่า “ผู้มีส่วนร่วมแต่ละรายให้สิทธิ์ลิขสิทธิ์แบบไม่ผูกขาด ทั่วโลก และไม่คิดค่าลิขสิทธิ์ เพื่อแจกจ่าย/ใช้งาน/แก้ไขงานต้นฉบับและงานดัดแปลง” แบบนี้ยิ่งสร้างความสับสน และในทางปฏิบัติก็เหมือนบังคับให้คนทำ automation สำหรับสร้าง fork ที่ mirror release เอง ซึ่งใน repo ก็มี github actions สำหรับเรื่องนี้ให้อยู่แล้ว
ข้อความในไลเซนส์ที่คุณยกมา แปลเพียงว่าคุณมีสิทธิ์คัดลอก แก้ไข(หรือคอมไพล์) และแจกจ่ายโค้ดนั้นได้เท่านั้น มันไม่ได้บอกว่ามีภาระหน้าที่ต้องแจกจ่ายไบนารีด้วย จริง ๆ วิธีแบบนี้พบได้บ่อยพอสมควร ไลเซนส์โอเพนซอร์สส่วนใหญ่ใช้กับซอร์สเป็นหลัก ประเด็นเรื่อง “ผลักให้ mirror/fork อัตโนมัติ” ก็มีเหตุผลอยู่ แต่สำหรับนักพัฒนาซอฟต์แวร์แล้ว การ clone แล้ว build เองเป็นเรื่องที่ง่ายและเป็นธรรมชาติอยู่แล้ว สมัยก่อนการคัดลอกซอร์สมาใช้เองก็เป็นวิธีปกติ และนั่นแหละคือสิ่งที่ทำให้ FOSS ได้รับความนิยม นี่ไม่ใช่ “ทางเลี่ยง” แต่เป็นแก่นแท้ของ FOSS เอง
เห็นด้วยเต็มที่ แต่ความจริงในภาคปฏิบัติไม่ได้เป็นแบบนั้น บริษัทส่วนใหญ่เห็นว่าค่าบำรุงรักษาของเราสมเหตุสมผลพอ และก็อยากได้การสนับสนุนอย่างเป็นทางการมากกว่ารับความเสี่ยงเรื่องการดูแลโปรเจกต์หรือความเสี่ยงจากการ fork เอง
ผมไม่แน่ใจว่าผมไม่เข้าใจ “กระแส hype” ของเรื่องนี้หรือเปล่า ไลเซนส์ก็ไม่ได้เปลี่ยน เพียงแต่ถ้าไม่จ่ายค่าบำรุงรักษาก็ไม่ได้รับการซัพพอร์ตงั้นหรือ? ถ้ามีคนรายงานช่องโหว่ ผู้รายงานต้องจ่ายค่าบำรุงรักษาก่อน WiX ถึงจะยอมแพตช์ให้เหรอ? หรือถ้าผู้ใช้ระดับองค์กรเสนอไอเดียฟีเจอร์ดี ๆ แต่จะถูกเมินจนกว่าจะจ่าย? มันฟังดูเป็นเรื่องปกติมาก ผู้เขียนโอเพนซอร์สมีสิทธิ์เลือกอยู่แล้วว่าจะรับ PR ไหน จะสนใจ issue ไหน และจะคิดเงินค่าซัพพอร์ตเมื่อไรก็ได้ ผมเลยสงสัยว่าระบบค่าบำรุงรักษานี้มันใหม่หรือนวัตกรรมตรงไหน ไม่ได้จะโจมตีนะ การทำเครื่องมือภายใต้ไลเซนส์โอเพนซอร์สเป็นเรื่องดีมาก และการรับเงินสนับสนุนก็สมเหตุสมผล ถ้าผู้ร่วมพัฒนารู้สึกถูกกันออกไป ก็ fork ได้เสมอ นี่ไม่ใช่แนวคิดใหม่ เพียงแต่การ fork เองก็ต้องใช้ทั้งเงินและคนพอสมควร ต่อให้เป็นบริษัทใหญ่ระดับ Amazon การจ่ายเงินให้ผู้สร้างดั้งเดิมเพื่อให้เขาหันมาสนใจก็คุ้มกว่าด้วยซ้ำ ก็มีตัวอย่างอย่าง LibreOffice, io.js, OpenTofu, neovim ถ้าจะแตกสายกันจริงแบบ LibreCAD แล้วทำออกมาได้ดี นั่นก็ถือว่าเก่ง io.js ก็มีความหมายเพราะช่วยให้ nodejs แข็งแรงขึ้น พลังของชุมชนนี่แหละคือจุดแข็งใหญ่ของโอเพนซอร์ส ใครก็มีส่วนร่วมได้ทั้งโค้ด เอกสาร เงินทุน หรือไอเดีย ขอบคุณ WiX ที่เข้ามามีส่วนร่วมกับชุมชนในรูปแบบนี้ และขอให้ไปได้สวยต่อไป
ตัวติดตั้งของ WiX เป็นเครื่องมือที่ซับซ้อนและเข้าใจยาก ผมใช้มันเพราะจุดเด่นอย่างเดียวคือมันฟรี ถ้าต้องเสียเงิน ผมคงไปใช้ผลิตภัณฑ์เชิงพาณิชย์ที่ง่ายกว่าและมีซัพพอร์ตดีกว่า Rob Mensching เคยพยายามสร้างรายได้ด้วยบริการที่ปรึกษาและซัพพอร์ตปีละ $5,000 แต่ดูเหมือนแค่นั้นจะยังไม่พอ
คำพูดว่า “ข้อดีอย่างเดียวคือมันฟรี” อาจจริงสำหรับคนที่แค่อยากได้เครื่องมือทำ installer แบบไม่ต้องเสียเงิน แต่คุณค่าหลักของ WiX ไม่ได้อยู่ที่ความฟรีอย่างเดียว WiX Toolset ช่วยให้ใช้ศักยภาพของ Windows Installer ได้ในแบบที่เครื่องมือ installer อื่นทำไม่ได้ ถ้าคุณไม่ต้องการความสามารถซับซ้อน มันก็แน่นอนว่าใช้งานยากและมีข้อเสียเยอะ แต่เมื่อเจอปัญหาการติดตั้งที่ยาก ฟีเจอร์ที่เฉียบคมเหล่านี้กลับจำเป็นมาก ส่วนเรื่อง “หารายได้จากที่ปรึกษาปีละ $5,000” นั้น ผมไม่ได้หาเงินแค่ $5,000 ต่อปีจากตัว WiX อย่างเดียว ผมให้บริการระดับพรีเมียมผ่านโปรแกรม “WiX Developer Direct” โดยอาศัยทั้งความรู้ด้านแพ็กเกจติดตั้งที่ทีมและผมสั่งสมมาหลายสิบปี และเครื่องมือขั้นสูงจาก FireGiant มีทั้ง monthly office hours, การรับประกัน SLA, การรีวิวโค้ดประจำปี, เครื่องมือขั้นสูง ฯลฯ ซึ่งลูกค้าก็ให้คุณค่าสูง ไม่ใช่ว่าสิ่งนี้ไม่พอ แต่หลังเหตุการณ์ XZ Utils ผมรู้สึกชัดมากว่าความยั่งยืนของโอเพนซอร์สเป็นปัญหาร้ายแรงจริง ๆ เลยพยายามหาวิธีบางอย่าง และผมคิดว่า Open Source Maintenance Fee เป็นหนึ่งในทางออกที่ค่อนข้างใช้ได้สำหรับโปรเจกต์แบบของผม ตอนนี้ WiX Toolset เป็นรายแรกที่นำโมเดลนี้มาใช้ จึงทำหน้าที่เหมือนสนามทดลองว่าเมื่อผ่านการลองผิดลองถูกแล้วมันจะเวิร์กจริงแค่ไหน ซึ่งจนถึงตอนนี้มันไปได้ดีมาก
WiX จริง ๆ แล้วก็คือเครื่องมือสำหรับเขียนโครงสร้างฐานข้อมูลภายในที่ใช้ใน Windows Installer ออกมาเป็น XML โดยตรง ตัวฟอร์แมต MSI และ Windows Installer เองซับซ้อนมาก เลยทำให้ถูกมองแบบนั้น แต่ปัญหาไม่ได้อยู่ที่ WiX เท่าไร แต่อยู่ที่ฟอร์แมต MSI เองที่เดิมทีก็เหมือน “เขาวงกตที่ซับซ้อน” อยู่แล้ว
ผมเข้าใจมาตลอดว่าไลเซนส์อยู่กับ Microsoft แต่ถ้าดู ข้อความเต็มของไลเซนส์ จะเห็นว่าระบุว่า “binary release ที่เผยแพร่บน GitHub และ NuGet.org อยู่ภายใต้ EULA ที่กำหนดให้ต้องจ่ายค่าบำรุงรักษา” ผมไม่ใช่ทนายเหมือนกัน แต่ถ้าอย่างนั้น ถ้าสร้างเองแล้วนำไปแจกต่อ ก็เลี่ยงค่าบำรุงรักษาได้ไม่ใช่เหรอ? แล้วจะเอา build นั้นไปแจกฟรีก็ยังได้ด้วยหรือเปล่า?
โค้ดนี้ไม่ได้เป็นของ Microsoft แต่เป็นของ .NET Foundation(เรื่องราวค่อนข้างยาว) และการ build เองเพื่อเลี่ยงค่าบำรุงรักษาก็ได้รับอนุญาตเต็มที่จริง ๆ จากนี้คุณก็แค่ต้องรับผิดชอบโค้ด 500,000 บรรทัดด้วยตัวเอง ขอให้สนุกกับการ fork อย่างแท้จริง!
ตาม README ของ repo ระบุชัดว่าซอร์สโค้ดเป็นโอเพนซอร์ส แต่ฟีเจอร์ issue/release ของ repo ต้องจ่ายค่าบำรุงรักษาก่อน