- 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 बनाना नहीं चाहता, और कोड सभी के लिए स्वतंत्र रूप से उपलब्ध है, इसलिए कोई भी इसे खुलकर इस्तेमाल कर सकता है। क्योंकि कोड वितरित करने की अतिरिक्त लागत लगभग 0 होती है। लेकिन maintainers यह नहीं चाहते कि वे कंपनियों को बिना भुगतान के किसी charity की तरह सेवा दें। उनका समय सीमित है, इसलिए अगर वे किसी revenue-generating गतिविधि में योगदान दे रहे हैं, तो बदले में कुछ कमाई चाहना स्वाभाविक है। यह ठीक है, भले ही यह तरीका पूरी तरह enforce न हो। अब maintainers को claims के जवाब में यह कहने की स्वतंत्रता मिलती है: “अगर आप चाहते हैं कि हम इसकी परवाह करें, तो भुगतान करें।” भुगतान करने वाली कंपनियों को एक निश्चित स्तर का support मिलेगा, और सामान्य users का अनुभव वैसा ही रहेगा। केवल वे कंपनियाँ परिणाम भुगतेंगी जो इस चेतावनी को नज़रअंदाज़ करती हैं, और यह खास तौर पर तब असरदार है जब वे “बहुत से महत्वपूर्ण users प्रभावित हो रहे हैं” जैसी अपील करती हैं। अगर सच में ज़रूरत है, तो भुगतान करना ही सही है। ऐसे समय में जब AI-generated code, reports वगैरह बढ़ रहे हैं, मुझे लगता है कि यह open source में अक्सर आने वाली समस्या का काफ़ी साफ़-सुथरा समाधान है
इस हिस्से को लेकर मेरी भावनाएँ मिली-जुली हैं। मैं Wix user नहीं हूँ, और यह इस मामले पर एक सामान्य राय है। किसी open source project को कोई भी मजबूर करके maintain नहीं करवा सकता। हर fix स्वैच्छिक होती है। कोई भी कंपनी maintainers को PR स्वीकार करने या काम करने के लिए मजबूर नहीं कर सकती। FOSS developers अक्सर stress महसूस करते हैं, लेकिन अगर financial motivation नहीं है, तो वे बस मना कर सकते हैं। शिकायतें हो सकती हैं, पर किसी समस्या को ठीक करना उनकी बाध्यता नहीं है। sponsorship model अंततः FOSS को एक business model में बदल देता है। फिर वह FOSS नहीं रह जाता। FOSS का सार यह है कि कोई भी उसे copy कर सकता है, modify कर सकता है, और business में बदल सकता है। ज़्यादातर licenses में आप इसी बात से सहमत होते हैं। मेरी राय लोकप्रिय न हो, लेकिन मुझे नहीं लगता कि इस मामले पर गुस्से से प्रतिक्रिया देने की ज़रूरत है
मैं इस policy के बारे में दो पहलुओं से नकारात्मक बात करना चाहता हूँ। पहला, contributors जुटाना और मुश्किल हो सकता है। paid contributors और unpaid contributors की 2-tier संरचना बन सकती है। “मैं unpaid bug fixes कर रहा हूँ, जबकि दूसरे लोग पैसे कमा रहे हैं” जैसी नाराज़गी पैदा हो सकती है। दूसरा, जैसे ही पैसे लिए जाते हैं, रिश्ता ज़्यादा transactional हो जाता है। पैसे लिए हैं, तो उसके बदले demands और work expectations भी आएँगी। हालाँकि volunteer model में भी sustainability की समस्या रहती है
मुझे यह इतना innovative नहीं लगता। पहले product मुफ्त में दिया जा रहा था, अब उसे paid model में बेचा जा रहा है। यानी यह एक सामान्य business की तरह operate करता दिखता है
मुझे लगता है कि किसी को भी अपनी मनचाही feature या support के लिए भुगतान करने की सुविधा होनी चाहिए, और code को एक निश्चित threshold तक closed source रखा जाना चाहिए। यह threshold interest और income के हिसाब से कुछ महीनों या कुछ सालों का हो सकता है। आखिरकार वह open source हो जाएगा। नहीं तो सब लोग इंतज़ार करते रहेंगे कि कोई और पैसे दे। बेशक, structure ऐसा होना चाहिए कि बहुत ज़्यादा forks न बनें, लेकिन यह काफ़ी संभव तरीका है
मुझे लगा था कि कई open source projects पहले से ही यह तरीका अपना रहे हैं। मुझे लगा Busybox maintain करने वाले consultant का मामला ऐसा ही था, लेकिन हो सकता है कि मैंने स्थिति को गलत समझा हो
इसका Wix website builder से कोई संबंध नहीं है; यहाँ बात WiX Toolset की हो रही है
“सबसे शक्तिशाली Windows installation experience बनाने वाला toolset. 2004 से open source!” — यही उसका परिचय है
धन्यवाद। मैंने भी पहले इसे Wix समझ लिया था। Wix सच में बहुत high-quality React Native libraries बनाता है
कुछ महीने पहले मैं अपने open source project के लिए installer देख रहा था, तभी संयोग से मुझे इस policy के बारे में पता चला। अगर source code OSI license के तहत है, तो binaries बेचने को लेकर मुझे समस्या नहीं है। लेकिन README में लिखी यह पंक्ति मुझे खटकी: "इस project की long-term sustainability के लिए, WiX Toolset के उपयोग पर open source maintenance fee लागू होती है। source license के तहत freely available है, लेकिन issue बनाना, comment करना, discussion में भाग लेना, release download करना जैसी बाकी सभी सुविधाएँ भी maintenance fee के अधीन हैं। यानी revenue purpose के उपयोग में maintenance fee देनी होगी।" मुझे लगा कि यह ऐसा concept है जिसे छोटे वाक्य में समझाना मुश्किल है, इसलिए इसे अच्छे इरादे से पढ़ा जा सकता है। लेकिन “revenue use पर भुगतान करो” जैसा सारांश उल्टा गलतफहमी पैदा कर सकता है। MS-RL license के तहत अगर आप खुद build करके इस्तेमाल करें तो commercial use पर कोई रोक नहीं है, इसलिए यह मुझे commercial users को sponsor बनाने की एक तरह की “धमकाने वाली” चाल लगी। मैं समझता हूँ कि open source maintainers किन मुश्किलों से गुजरते हैं, लेकिन यह approach मुझे ethical नहीं लगी। इसलिए, commercial user न होते हुए भी मैंने WiX का उपयोग छोड़ दिया
यह commercial users को free support न देने का स्पष्ट संकेत है। तुमने कहा कि wording साफ़ नहीं है, लेकिन जिस पंक्ति का तुमने quote किया, उसमें साफ़ लिखा है कि 'source license के अनुसार freely usable है'
startups या fund की कमी वाले छोटे businesses अक्सर open source project लेकर खुद build करते हैं, उसे distribution artifact बनाते हैं, और खुद maintain करते हैं। जब वे एक स्तर पर पहुँचते हैं, तो पूरे process को manage करने वाले official support पर खर्च करना ज़्यादा मूल्यवान हो जाता है। यह policy कंपनियों को official support की लागत चुकाने की ओर धकेलती है, जब वे सिर्फ open source binaries लेकर इस्तेमाल करने के direct support risk को उठाना नहीं चाहतीं
इस विचार को एक छोटे वाक्य में समझाना सच में बहुत मुश्किल है। क्योंकि हर open source project की expectations बहुत अलग होती हैं। अगर text को बेहतर बनाने के लिए कोई सुझाव हो, तो मैं हमेशा सुनना चाहूँगा
मेरे हिसाब से, अगर आप किसी revenue-generating organization की ओर से कुछ मांग रहे हैं, तो बातचीत करने के लिए भुगतान करना होगा। revenue interest के लिए communication करने पर fee देनी होगी
अगर आप GitHub issue के comments पढ़ें, तो टीम काफ़ी reasonable लगती है। मेरी समझ के मुताबिक, वे केवल उन्हीं मामलों में पैसे चाहते हैं जहाँ सच में revenue बन रहा हो। अगर आप सच में एक solo developer हैं या बहुत शुरुआती product stage में हैं, तो शायद वे ज़्यादा परवाह नहीं करेंगे। उनकी sponsorship page भी है
यह https://opensourcemaintenancefee.org/ homepage के बारे में है। यह केवल dark mode में ठीक दिखता है, और light mode में लगभग पढ़ा ही नहीं जाता। repo में issue भी नहीं खोला जा सकता। शायद author यहाँ comments पढ़ ले (संभावना कम है)
issue दर्ज करने के लिए maintenance fee देनी पड़ती होगी! मज़ाक कर रहा हूँ
ओह, यह सच में गंभीर समस्या थी। अब किसी random contributor की वजह से यह ठीक हो गया है!
मेरी कंपनी की legal team अगर ऐसा EULA (End User License Agreement) देखे, तो वह हमें भुगतान करने के बजाय इस tool का उपयोग तुरंत बंद करने को कहेगी। मुझे लगता है ज़्यादातर कंपनियाँ भी यही करेंगी। maintainers के नज़रिए से यह ठीक भी हो सकता है, लेकिन मैं हमेशा कहता आया हूँ कि अगर आप commercial use को इस तरह सीमित करते हुए open source बनाए रखना चाहते हैं, तो AGPL लगा दें। AGPL enterprise के लिए लगभग ज़हर जैसा है। जिन कंपनियों में मैं रहा हूँ, उनमें से किसी ने भी commercial product में AGPL code की अनुमति नहीं दी। उसके बाद आप commercial license बेच सकते हैं
open source projects अक्सर charity और honor system की तरह काम करते हैं। contributors को प्रतिष्ठा मिलती है, और इस्तेमाल करने वाली कंपनियों को revenue। यह ऐसा मॉडल है जिसमें दोनों पक्ष लाभ उठाते हैं, और परोक्ष रूप से मानवता को भी मदद मिलती है। मैं व्यक्तिगत रूप से—शायद भोलेपन से—मानता हूँ कि इस charity का लाभ पूरी मानवता तक थोड़ा और सीधे और स्पष्ट रूप में पहुँचना चाहिए। उदाहरण के लिए, जब कोई project public license के तहत जारी हो, तो उससे revenue कमाने वाली कंपनियाँ अपनी sales का लगभग 1% किसी global fund में दें, यानी "Decentralized Universal Kindness Income" (DUKI)। lead contributor companies को पूरे या आंशिक donation exemption का विशेषाधिकार मिल सकता है, ताकि अगर दूसरी बड़ी कंपनियाँ उसी का उपयोग करके प्रतिस्पर्धा करें, तो उन्हें कुछ बढ़त मिले (शायद इसी कारण Redis ने भी license बदला)। contributors को दुनिया भर से ज़्यादा recognition और prestige मिलेगा, और donate करने वाली कंपनियाँ open source resources का व्यापक उपयोग करने के साथ marketing में reputation boost भी पाएँगी। वे सिर्फ profit-driven कंपनियों की तुलना में ज़्यादा competitive हो सकती हैं। मैं इसे “DUKI license” कहता हूँ। मूल बात यह है कि MIT license में profit-sharing की एक शर्त जोड़ दी जाए। अफ़सोस, मेरे पास इसे market करने लायक influence नहीं है, और यह भी पता नहीं कि open source ecosystem के प्रमुख maintainers और founders इसे अपनाएँगे या नहीं
इसमें लिखा है, “source code license के तहत freely available है, लेकिन issue दर्ज करना, comment करना, discussion में भाग लेना, release download करना जैसी बाकी सभी गतिविधियाँ maintenance fee compliance मांगती हैं।” इसमें release downloads भी शामिल हैं, यह देखकर मैं हैरान था। मैं lawyer नहीं हूँ, लेकिन मुझे यह license से टकराता हुआ लगा। खास तौर पर यह clause: “प्रत्येक contributor non-exclusive, worldwide, royalty-free copyright license देता है ताकि आप उसके contribution और derivative works को distribute/use/modify कर सकें।” इस तरह तो उल्टा confusion बढ़ेगा, और व्यवहार में release auto-mirroring करने वाले forks बनाने की automation को बढ़ावा मिलेगा। repo में उसके लिए GitHub actions भी पहले से दिए गए हैं
जिस license clause को तुमने quote किया, उसका मतलब सिर्फ इतना है कि तुम्हें उस code को copy, modify (या compile), और distribute करने का अधिकार है। binaries distribute करना कोई बाध्यता नहीं है। असल में यह तरीका काफ़ी आम है। open source licenses ज़्यादातर source पर ही लागू होते हैं। “auto mirror/fork को बढ़ावा” वाली बात में दम है, लेकिन software developers के लिए खुद clone करना और build करना शुरू से ही आसान और स्वाभाविक काम रहा है। पहले भी source को copy करके इस्तेमाल करना ही मूल तरीका था, और इसी वजह से FOSS लोकप्रिय हुआ। यह कोई “bypass” नहीं, बल्कि FOSS का मूल स्वभाव है
मैं पूरी तरह सहमत हूँ। लेकिन व्यवहार में ऐसा नहीं हुआ। ज़्यादातर कंपनियों ने हमारी maintenance fee को काफ़ी reasonable माना, और project को maintain करने या fork risk लेने के बजाय official support लेना पसंद किया
मुझे समझ नहीं आता कि इस मामले में इतना “hype” क्यों है। license तो नहीं बदल रहा, बस maintenance fee न देने पर support नहीं मिलेगा? अगर कोई vulnerability report करे, तो क्या report करने वाले को पहले maintenance fee देनी होगी तभी WiX patch करेगा? या अगर किसी enterprise user ने कोई अच्छी feature idea दी, तो क्या maintenance fee देने तक उसे ignore किया जाएगा? यह तो बहुत obvious बात लगती है। open source authors हमेशा से खुद तय करते हैं कि कौन-सा PR लेना है और किन issues पर ध्यान देना है। वे support के लिए शुल्क भी ले सकते थे। maintenance fee system को innovative क्यों माना जा रहा है, यह मुझे समझ नहीं आता। मैं इसकी आलोचना नहीं कर रहा। open source license के तहत tool बनाना शानदार है, और funding लेना भी बिल्कुल जायज़ है। अगर contributors को अलग-थलग महसूस हो, तो वे fork कर सकते हैं। यह कोई नया concept नहीं है। हाँ, fork करना पैसे और लोगों दोनों के हिसाब से बड़ा फैसला होता है। Amazon जैसी बड़ी कंपनी के लिए भी मूल लेखक को पैसे देकर उसका ध्यान पाना ज़्यादा efficient हो सकता है। LibreOffice, io.js, OpenTofu, neovim जैसे उदाहरण भी हैं। LibreCAD की तरह अगर ठीक से split हो, तो वह भी एक क्षमता है। io.js ने nodejs को ज़्यादा healthy बनाया, इसलिए वह meaningful था। community की यही ताकत open source का बड़ा फायदा है। code, docs, funds, ideas—कोई भी योगदान दे सकता है। WiX भी इस तरह community में शामिल है, इसके लिए धन्यवाद, और आगे भी इसके अच्छे होने की कामना है
WiX installer एक जटिल और समझने में कठिन tool है। मैंने इसे सिर्फ इसलिए इस्तेमाल किया क्योंकि यह मुफ्त था। अगर यह paid होता, तो मैं कोई आसान और बेहतर support वाला commercial product चुनता। Rob Mensching पहले $5,000 प्रति वर्ष की consulting और support service से कमाई की कोशिश कर चुके थे, पर लगता है वह पर्याप्त नहीं था
“इसका एकमात्र लाभ मुफ्त होना था” — यह उन लोगों के लिए सही हो सकता है जो installation tool पर पैसा नहीं खर्च करना चाहते थे। लेकिन WiX की सबसे बड़ी value सिर्फ free होना नहीं है। WiX Toolset Windows Installer की क्षमता का उपयोग ऐसे तरीकों से करने देता है, जैसा कोई और installation tool नहीं कर पाता। अगर आपको साधारण सुविधाओं से काम चल जाता, तो यह निश्चित रूप से असुविधाजनक और कई मायनों में कमजोर लगता। लेकिन कठिन installation problems में यही तेज़ और गहराई वाली क्षमताएँ ज़रूरी थीं। “$5,000 per year consulting monetization” की बात करें, तो मैं सिर्फ WiX से सालाना $5,000 नहीं कमाता। मैं अपनी team और अपने दशकों के installation packaging experience, और FireGiant के advanced tools का उपयोग करके “WiX Developer Direct” program के माध्यम से high-end customized services देता हूँ। इसमें monthly office hours, SLA guarantees, annual code reviews, advanced tools जैसी high-end services शामिल हैं, और customers इन्हें काफ़ी महत्व देते हैं। बात यह नहीं है कि यह पर्याप्त नहीं है, लेकिन हाल का XZ Utils incident देखकर मुझे open source sustainability की गंभीरता सच में महसूस हुई। इसलिए मैं कोई रास्ता खोजने की कोशिश कर रहा था, और Open Source Maintenance Fee मुझे अपने जैसे projects के लिए काफ़ी अच्छा समाधान लगा। WiX Toolset फिलहाल इस model को अपनाने वाला पहला project है, इसलिए यह trial and error के साथ यह भी परख रहा है कि यह व्यवहार में कैसे चलता है। अभी तक यह काफ़ी अच्छी तरह काम कर रहा है
WiX असल में एक ऐसा tool है जिससे आप Windows Installer में इस्तेमाल होने वाली underlying database structure को सीधे XML में लिख सकते हैं। MSI format और Windows Installer खुद इतने जटिल हैं कि ऐसी राय बनना स्वाभाविक है, लेकिन यह WiX की नहीं, बल्कि MSI format की मूल “complex maze” जैसी प्रकृति है
मुझे लगा था कि इसका license MS के पास है, लेकिन license text देखने पर लिखा है, "GitHub और NuGet.org पर प्रकाशित binary releases पर maintenance fee payment की मांग करने वाला EULA लागू होता है।" मैं lawyer नहीं हूँ, लेकिन इस हालत में अगर कोई खुद build करके distribute करे, तो क्या maintenance fee को bypass करना संभव नहीं होगा? और क्या उस build को मुफ्त में बाँटना भी संभव नहीं होगा?
code Microsoft का नहीं, बल्कि .NET Foundation का है (कहानी लंबी है)। खुद build करके maintenance fee को bypass करना वास्तव में पूरी तरह allowed है। अब बस 500,000 lines वाले codebase की ज़िम्मेदारी तुम्हारी होगी। अपने असली fork का आनंद लो!
repo readme के अनुसार, source code open source है, लेकिन repo के issues और releases features का उपयोग maintenance fee payment पर निर्भर है