ओपन सोर्स maintainers को पैसे देना अच्छी बात है
(jacobian.org)- ओपन सोर्स ecosystem पर बहुत से लोग और कंपनियाँ निर्भर हैं, लेकिन जब maintainers commercial features, बड़े enterprise में नौकरी, या investment के जरिए अपनी आजीविका बनाते हैं, तो पहले आलोचना सामने आती है — यह एक विरोधाभास है
- यहाँ ओपन सोर्स शब्द OSI·FSF की सख्त परिभाषा से व्यापक अर्थ में इस्तेमाल हुआ है; अगर source code को पढ़ा, बदला और modified versions को वितरित किया जा सकता है, तो इसमें Polyform, JSON license, और BSL भी शामिल हैं
- सस्टेनेबिलिटी का मतलब सिर्फ governance या community health नहीं, बल्कि यह भी है कि maintainers housing, food, healthcare जैसी बुनियादी ज़रूरतें पूरी करते हुए आराम से जी सकते हैं या नहीं
- Django को हर दिन सैकड़ों हज़ार लोग इस्तेमाल करते हैं, लेकिन Django पर फुल-टाइम paid काम करने वाले लोग सिर्फ DSF के 1 full-time Fellow और 1 part-time Fellow हैं; Python को हर दिन लाखों लोग इस्तेमाल करते हैं, लेकिन paid maintainers 12 से भी कम हैं
- Patreon, GitHub Sponsors, VC, Open Core, और non-OSI licenses — इन सबमें कमियाँ हैं, लेकिन अगर गुस्सा individual maintainers पर निकले, तो ओपन सोर्स की सामाजिक उपयोगिता को बढ़ाना मुश्किल हो जाता है
maintainers को पैसे मिलना क्यों अच्छा है
- शुरुआत इस नज़रिये से होती है कि ओपन सोर्स maintainers को पैसे मिलना कोई अपवाद नहीं, बल्कि जश्न मनाने की बात है
- जो maintainers अपनी आजीविका चलाने का तरीका ढूँढ लेते हैं, उन्हें दोष देने के बजाय उन ढाँचों और systems की आलोचना करनी चाहिए जो पैसे कमाना मुश्किल बनाते हैं
- जो लोग ओपन सोर्स काम करके जीना चाहते हैं, उन्हें अपनी बुनियादी ज़रूरतें पूरी करते हुए आराम से जी पाने में सक्षम होना चाहिए
- ओपन सोर्स सबके हित में होने वाला सहयोग है, और यह आधारभूत मान्यता है कि ओपन सोर्स के बिना दुनिया आज से कहीं बदतर होती
व्यापक अर्थ में ओपन सोर्स और सस्टेनेबिलिटी
- ओपन सोर्स और free software का इस्तेमाल यहाँ OSI·FSF की सख्त परिभाषा में नहीं, बल्कि व्यापक अर्थ में किया गया है
- इसका मतलब है ऐसा software जिसका source code पढ़ा, बदला और modified versions के रूप में वितरित किया जा सके
- इसमें OSI·FSF licenses के साथ-साथ Polyform licenses, JSON license, और BSL भी शामिल हैं
- “सिर्फ OSI-approved license ही ओपन सोर्स है” या “सिर्फ GPL ही असली free software है” जैसी संकीर्ण परिभाषाओं को समस्या का हिस्सा माना गया है
- license experiments और विविधता की ज़रूरत है, और यह माना गया है कि “कोई भी किसी भी उद्देश्य के लिए इस्तेमाल कर सके” से अधिक प्रतिबंध होने पर भी कोई चीज़ ओपन सोर्स की श्रेणी में आ सकती है
- सस्टेनेबिलिटी का मतलब है कि maintainers free software लिखते हुए ठीक-ठाक या आरामदायक जीवन जी सकते हैं या नहीं
- न्यूनतम मानदंड यह है कि housing, food, और healthcare जैसी बुनियादी ज़रूरतें पूरी हों
- आदर्श रूप में, सिर्फ ओपन सोर्स काम के सहारे आरामदायक या शानदार जीवन भी संभव होना चाहिए
अभी ओपन सोर्स सस्टेनेबल नहीं है
- केवल free software लिखकर आजीविका कमाने वाले लोग पूरे software engineering पेशे में व्यवहारिक रूप से शून्य के करीब हैं
- Canonical, Red Hat, Hashicorp, Mozilla जैसी कंपनियाँ ओपन सोर्स पर काम करने वालों को नौकरी देती हैं, लेकिन proprietary software लिखने वाले लाखों engineers की तुलना में उनका पैमाना बहुत छोटा है
- इन संगठनों के सभी engineers सिर्फ ओपन सोर्स पर ही काम नहीं करते, और कई संगठन ऐसे business model पर निर्भर हैं जिनमें product का कुछ हिस्सा proprietary होता है
-
Django और Python के आँकड़े
- हर दिन सैकड़ों हज़ार engineers Django का इस्तेमाल करते हैं
- Django पर paid dedicated काम करने वाले लोग सिर्फ DSF द्वारा नियुक्त 1 full-time Fellow और 1 part-time Fellow हैं, यानी कुल 1.5 लोग
- हर दिन लाखों लोग Python का इस्तेमाल करते हैं, लेकिन Python पर काम करके पैसे पाने वाले लोग 12 से कम हैं
- इसमें PSF Developers-in-Residence और Google, Microsoft जैसी कंपनियों में Python को अपने काम का हिस्सा बनाने वाले कुछ maintainers शामिल हैं
- अगर स्थिति सस्टेनेबल हो, तो Django के लिए industry median के आसपास वेतन पाने वाले लगभग 12 full-time लोग होने चाहिए, और Python के लिए कई दर्जन लोग
- केवल PyPI को ही उसके scope, scale, और महत्व को देखते हुए कम से कम 10–15 लोगों की team चाहिए
- “Nebraska का कोई random व्यक्ति” अगर किसी critical dependency को अकेले maintain कर रहा है, तब भी सस्टेनेबिलिटी के लिए उसके पास ऐसे सहकर्मी होने चाहिए ताकि वह आराम से जी सके और छुट्टी पर जा सके
सार्वजनिक समर्थन के आदर्श और मौजूदा हक़ीक़त के बीच फ़ासला
- आदर्श स्थिति यह है कि free software को एक public good माना जाए और society व government उसकी उचित funding करें
- इसके साथ healthcare, housing access, public transport, और social safety net जैसी समस्याओं का समाधान भी जुड़ा हुआ है
- लेकिन यह माना गया है कि ऐसा बदलाव तुरंत नहीं आने वाला, और यह भी निश्चित नहीं कि जीवनकाल में आएगा
- “सरकार को funding करनी चाहिए, इसलिए private companies को maintainers को पैसे नहीं देने चाहिए” जैसी बात वास्तविक दुनिया में सिमटकर “जब तक सरकार funding न करे, maintainers को पैसे नहीं मिलने चाहिए” पर पहुँच जाती है
- आज की दुनिया में यह मानना ज़रूरी है कि maintainers को पैसे मिलने की ज़रूरत है
पैसे मिलने का हर तरीका फिलहाल एक जीत है
- वास्तविक दुनिया में ओपन सोर्स सस्टेनेबिलिटी का मतलब है कि maintainers को वास्तव में पैसे मिलें
- अगर किसी maintainer ने किराया भरते हुए free software लिखने का रास्ता ढूँढ लिया है, तो वह अपने आप में एक सकारात्मक उदाहरण है
- ऐसे सकारात्मक उदाहरण कई रूपों में हो सकते हैं
- Microsoft में नौकरी करके Python पर काम करना
- grant पाना
- Patreon पर sustainable sponsorship level तक पहुँचना
- free software development के लिए VC investment जुटाना
- Open Core model के जरिए sustainable business बनाना
- Hashicorp जैसी कंपनी में काम करना
- paid hosting option के जरिए open project को support करना
- Amazon-शैली के शोषण से बचने के लिए non-OSI-approved license का सफल इस्तेमाल करना
बार-बार दोहराई जाने वाली आलोचनाएँ और उनकी सीमा
- maintainers को पैसे मिलते ही funding के हर तरीके पर अलग-अलग तरह की आलोचना सामने आ जाती है
- non-OSI license ओपन सोर्स नहीं है
- Microsoft में नौकरी करने वाले corporate हितों के अधीन हैं, इसलिए उन पर भरोसा नहीं किया जा सकता
- Patreon भीख माँगना है
- GitHub Sponsors Microsoft की rent-seeking में मदद करता है
- VC funding आगे चलकर rug pull या enshittification में बदल जाएगी
- Open Core bait and switch है
- यहाँ तक कि एक maintainer को सिर्फ T-shirt बेचने के लिए भी आलोचना झेलनी पड़ी
- हर तरीके में वास्तविक समस्याएँ हैं
- VC investment शर्तों के साथ आता है और बाद में समस्या बन सकता है
- Patreon, GitHub, Stripe sponsorship का एक हिस्सा अपने पास रखते हैं
- PolyForm या BSL के अतिरिक्त प्रतिबंध Freedom 0 के आदर्श से टकराते हैं
- Open Core tools में जब मनचाही core functionality सिर्फ paid license में मिले, तो निराशा होना स्वाभाविक है
- इन systems की आलोचना की जा सकती है, लेकिन पैसे पाने वाले individual maintainer पर हमला करना गुस्से की गलत दिशा है
- यह वैसा ही है जैसे किसी ऐसे व्यक्ति पर चिल्लाना जिसके पास shopping के लिए सिर्फ Dollar General ही उपलब्ध हो; समस्या व्यक्ति में नहीं, बल्कि structure और policy में है
शुद्धता की माँग ओपन सोर्स के सामाजिक मूल्य को सीमित करती है
- बहुत अधिक लोगों को free software लिखते हुए पैसे मिलने चाहिए
- इसके लिए imperfect या पूरी तरह शुद्ध न माने जाने वाले funding models को भी स्वीकार करना होगा
- funding mechanisms और सामाजिक असमानता की आलोचना और सुधार जारी रहना चाहिए
- लेकिन जब कोई maintainer पैसे कमाने का रास्ता ढूँढ ले, तो उसे बधाई देना पूरे ओपन सोर्स ecosystem के लिए ज़्यादा फायदेमंद है
1 टिप्पणियां
Hacker News टिप्पणियां
“जो OSI-अप्रूव्ड लाइसेंस नहीं है” उसे open source की श्रेणी में रखने वाले हिस्से से सहमत होना मुश्किल है
OSI-अप्रूव्ड न होने की वजह यह है कि community ने बहुत पहले इसे परिभाषित किया था और आज भी वैध अर्थों में यह open source नहीं है
इसके अलावा, अलग-अलग प्रकृति की कई चीजों को सबको जीत मानने की दलील भी आकर्षक नहीं लगती। मसलन “Microsoft में नौकरी करके Python पर काम करना” भी job की खास शर्तों के हिसाब से जीत से ज्यादा जाल हो सकता है, और https://ghuntley.com/fracture/ देखें
यह पूरा लेख OSI definition को जानबूझकर खारिज करने की वजह समझाने वाला लेख है, जबकि विरोधी पक्ष का आधार सिर्फ उसी OSI definition की अपील लगता है जिसे वह स्पष्ट रूप से खारिज करता है
वह जानबूझकर lowercase “open source” / “free software” लिखता है, और बताता है कि उसका मतलब OSI के Open Source™ या FSF के Free Software™ से नहीं, बल्कि व्यापक अर्थ में “ऐसा software जिसका source code हो जिसे पढ़ा, बदला और शर्तों के साथ modified version के रूप में distribute किया जा सके” है
इसलिए वह OSI/FSF licenses के साथ-साथ Polyform, JSON license, BSL तक को अपने हिसाब के “open source” में शामिल करता है
बल्कि यह ज्यादा ऐसा लगता है कि वह पैसे लेकर किए जाने वाले कई तरह के कामों को “open source” मान लेने की बात कर रहा है
उदाहरण के लिए, अगर RHEL अब भी open source है तो Red Hat programmers paid open source developers हैं, लेकिन अगर RHEL अब proprietary software है तो open source काम के लिए पैसे पाने वालों की संख्या घटती है
लेकिन “क्या वह definition आज भी सबसे उचित है” यही बहस का मुख्य मुद्दा है
शायद वह उचित हो सकती है, लेकिन उस definition पर सवाल उठाना भी पूरी तरह वैध प्रश्न है, और मेरे हिसाब से लोग अभी यही कर रहे हैं
OSI अब नए licenses को सिर्फ तभी approve करता है जब उसे लगता है कि वे मौजूदा OSI-अप्रूव्ड licenses से न भर पाने वाली कमी को पूरा करते हैं, इसलिए अनगिनत संभावित licenses हो सकते हैं जो definition की सभी शर्तें पूरी करते हैं लेकिन approve नहीं हुए हैं
[1] https://opensource.org/osd/
कुछ हफ्ते पहले मैंने अमेरिका में independent engineers और छोटे FOSS projects के लिए सरकारी सहायता बिल्कुल न होने के बारे में अपने senator को पत्र भेजा था
EU का NLNet शानदार है, और अमेरिका में भी NLNet जैसी किसी चीज की सच में जरूरत है
हालांकि transport projects के execution को सीधे जानने के नाते, उनमें होने वाली भारी बर्बादी देखकर लगता है कि ऐसी सहायता उलटे हालात बिगाड़ भी सकती है, इसलिए मैं फैसला नहीं कर पा रहा
सहमत होना चाहता हूं और position भी समझता हूं, लेकिन “हमेशा” शब्द इस्तेमाल करने से nuance खत्म हो जाता है
अगर कोई company किसी व्यक्ति को open source काम के लिए pay कर रही हो और project को दूसरे users के हितों के खिलाफ दिशा में ले जा रही हो, तो क्या यह अच्छी बात हो सकती है? मुझे नहीं लगता
लोगों की रोजी-रोटी के पक्ष में हूं, लेकिन “कुछ हद तक free” source code बन जाने से बुरे व्यवहार को भी अच्छा नहीं माना जा सकता
मुख्य बात यह है कि perfection को good के रास्ते में न आने दें
हमें कोशिश करनी चाहिए कि open source codebase पर काम करना चाहने वाले सभी लोगों को उचित public funding मिले, लेकिन तब तक हमें यह reality भी स्वीकार करनी होगी कि companies कुछ FLOSS code को fund करती हैं
सरकार को support करना चाहिए, यह बात अच्छी लगती है, लेकिन अगर सरकार असल में ऐसा नहीं करती, तो अंत में बात “open source maintainers को पैसे नहीं मिलने चाहिए” पर आकर खत्म हो सकती है
अगर community और users funding नहीं करेंगे तो private companies funding करेंगी, और तब उन्हें बोलने का अधिकार मिलेगा
open source को बड़ी कंपनियों द्वारा सोखा जाने वाला outsourced “free labor” नहीं बनना चाहिए
WordPress ecosystem की तरह free GPL2+ version बनाए रखते हुए premium add-on downloads, update licenses और support बेचने वाला premium model सबसे अच्छी तरह काम करता आया है
open source राजनीति जैसा है: जो पैसा लगाता है, निर्णय की शक्ति उसी के पास होती है। अगर community आर्थिक रूप से आत्मनिर्भर नहीं हो पाती, तो बाहरी funding दिशा तय करेगी
open source में कई contributions गर्व करने और सराहे जाने लायक हैं, लेकिन दिन में ज्यादातर लोग market share और economic control बढ़ाने की कोशिश करने वाली private companies में काम करते हैं
एक हाथ से open source में योगदान करते हुए भी, दूसरे हाथ से private companies में किए काम के कारण उसके असर को कुछ हद तक उलट रहे होते हैं
इसलिए open source को खुद funding जुटानी चाहिए और एक स्वतंत्र economic और political force बनना चाहिए। वरना वह हमेशा नियम मानने वाले पक्ष में रहेगा, और open source को नुकसान पहुंचाने की private lobbying की कोशिशों से लगातार लड़ना पड़ेगा
आम तौर पर किसी तय अवधि के भीतर deliverables बनते हैं, और उस समय open source full-time hobby नहीं बल्कि job के स्तर पर पहुंच जाता है
company जिस दिशा में project को ले जा रही है, उसके अच्छे होने की संभावना कम है, लेकिन यह भी नहीं कहा जा सकता कि वह हमेशा बुरी ही होगी
ऐसी स्थिति भी सोची जा सकती है जहां company जिस दिशा को चाहती है वहां संभावित users कहीं ज्यादा हों, और मौजूदा थोड़े users fork कर सकते हों
Open Source Initiative और उसकी परिभाषा की शुरुआत याद करने के लिए यह अच्छा संदर्भ है
OSI ने 2007 में अपने इतिहास में बताया था कि उसने पहले “free software” से जुड़ी नैतिकतावादी और टकराव वाली सोच को छोड़कर, Netscape को प्रभावित करने वाले व्यावहारिक और कारोबारी तर्कों के आधार पर इसे बेचना तय किया, और “open source” शब्द तथा Raymond द्वारा विकसित व्यावहारिकतावाद और बाजार-अनुकूल बयानबाजी को अपनाया
दशकों बाद, बड़ी कंपनियों के शोषण को रोकने की कोशिश कर रहे गैर-OSI लाइसेंस उपयोगकर्ताओं को “असली open source” नहीं होने के कारण बेहद नैतिकतावादी ढंग से कोसा जाना थोड़ा मजेदार है
http://web.archive.org/web/20071115150105/https://opensource...
बाद वाले में अक्सर BUSL-licensed code इस्तेमाल करने वाली services होस्ट नहीं की जा सकतीं, जिससे business risk पैदा होता है
इसके साथ ऐसे सवाल आते हैं कि क्या किसी खास use case की अनुमति है, क्या वकील से सलाह लेनी चाहिए, अभी तो ठीक है लेकिन कब सीमा पार हो जाएगी यह कैसे पता चलेगा, क्या यह तब है जब service से revenue आ रहा हो या केवल तब जब वह सीधे customers को दी जा रही हो
IBM या Collins जैसी consulting-structure कंपनियों में, जहां internal teams के बीच services पर भी internal chargeback होता है, बाहरी customer के पैसे न देने पर भी समस्या हो सकती है
जब upstream bugs या feature requests पर प्रतिक्रिया नहीं देता, तो क्या developers को hire करके contribution किया जा सकता है, क्या इसे internal infrastructure और tools में integrate किया जा सकता है, और क्या इसे बड़े projects में आजादी से मिलाया जा सकता है—यह भी अस्पष्ट रहता है
इन licenses के नैतिक पहलू से अलग, सिर्फ business दृष्टिकोण से भी यह चिंता समझाई जा सकती है कि वे OSI के लिए अनुपयुक्त हैं और इसलिए भावना के स्तर पर भी “open source” नहीं हैं
पिछले कुछ वर्षों में जिस community से सबसे ज्यादा जुड़ा रहा, वह R/tidyverse थी
कुछ developers को RStudio (अब Posit), R Consortium जैसी organizations software, documentation और community गतिविधियों के लिए भुगतान करती हैं
इस क्षेत्र में programmer के तौर पर अनुभव शानदार रहा है। जब full-time funded OSS contributors होते हैं, तो जबरदस्त leverage वाला व्यक्ति project पर बहुत समय लगाता है और हजारों R enthusiasts को फायदा होता है
tidyverse packages, Shiny, RMarkdown जैसी libraries इस्तेमाल करने पर documentation बहुत अच्छी तरह व्यवस्थित मिलती है और examples भी सरल लेकिन बेहतरीन होते हैं
अंदाजा लगाएं कि शायद यह ऐसे काम करेगा, और अक्सर वही तुरंत सही निकलता है; कई बार functions या packages शुरू से ही उसी तरह design किए गए होते हैं
लगता है कि केवल कम-से-कम एक dedicated व्यक्ति होने से भी OSS की quality काफी बेहतर हो जाती है, शायद इसलिए कि वह छोटी-छोटी contributions करने वाले दर्जनों लोगों को organize करने में मदद करता है
open source projects अक्सर documentation और user experience जैसे मुख्य क्षेत्रों पर कम ध्यान देते हैं। मेरे पसंदीदा OSS projects में भी कुछ का user experience भयानक है, शायद इसलिए कि contributors features जोड़ना तो पसंद करते हैं, लेकिन उन्हें users के लिए एक consistent package में व्यवस्थित करने या अनावश्यक और confusing contributions हटाने की भूमिका कम ही निभाते हैं
उन communities की तुलना में जहां full-time funded OSS contributors बहुत कम हैं या बिल्कुल नहीं हैं, libraries, interoperability और खासकर documentation में छोटी परेशानियां और inconsistencies कहीं ज्यादा मिलती हैं
R community इस बात का अद्भुत उदाहरण रही है कि दर्जनों full-time OSS लोगों को भुगतान करना community को long-term में कितना बड़ा लाभ दे सकता है, और मैं आभारी हूं कि ऐसे विनम्र दिग्गजों के कंधों पर खड़ा हो सकता हूं
“जब भी maintainer को भुगतान पाने का तरीका मिलता है, वह जीत है” — इस बात से सहमत हूं
ऐसी बातें अब अधिक आम हो रही हैं, और celebrate करने लायक कई examples भी हैं [0]
[0] https://fossfox.com/
मैं कई open source projects को donate करता हूं
Linux kernel जैसे projects हैं जो मेरी donation के बिना भी ठीक दिखते हैं, लेकिन अगर मुझे लगे कि जरूरत है तो मैं बिना हिचक donate करूंगा
बाकी projects के लिए, मैं open source definition से समझौता करने की बजाय उनका fail होना देखना पसंद करूंगा। मेरे लिए दोनों का मतलब एक ही है
समझ नहीं आता FOSS को कब से “free as in free speech” के बजाय “free as in free beer” समझा जाने लगा
developer compensation से जुड़ी कई चर्चाएं इन दोनों को मिला देती हैं
open source का मतलब है कि source खुला है और उसे देखने व modify करने की freedom है, यह नहीं कि cost 0 रुपये है
code के मामले में software product बेचते हुए code को freely release करना बहुत practical business model न भी हो, फिर भी यह open source की definition में फिट बैठता है
hack और modify करने की freedom हमेशा 0 रुपये license fee से अलग न होने वाली चीज रही है
अगर शुरुआती free/open licenses source access और modification की अनुमति देते लेकिन license fee लेते, या शुरुआती FOSS free use की अनुमति देता लेकिन modification पर रोक लगाता, तो आज जैसी सफलता नहीं मिलती
“free software” की दो freedoms पहले से ही जुड़ी रही हैं
freedom में दिलचस्पी नहीं होती, लेकिन cost में सबकी दिलचस्पी होती है
यहां तक कि कई FOSS developers भी पैसे लेने से इनकार करते हैं और पैसे लेने वालों को अलग-थलग करते हैं। उनके लिए पैसा kryptonite जैसा है
यह philosophy उस बेहद बुनियादी नियम के खिलाफ जाती है कि हर चीज के लिए, इंसान के समय सहित, compensation चाहिए; और मेरे हिसाब से यही FOSS के commercial और proprietary/closed-source software से पीछे रह जाने की बड़ी वजहों में से एक है
user को investment नहीं करनी पड़ती, इसलिए यह paid होने पर जितने possible market तक पहुंच सकता था, उससे कहीं बड़े potential market तक expand हो जाता है
free होने में कुछ ऐसा है जो लोगों के judgement को बिगाड़ देता है
chocolate को free और 0.01 dollar में पेश करने वाली study में भी, 0.01 dollar वाली chocolate कहीं ज्यादा premium और बेहतर value वाली होने के बावजूद free option कहीं ज्यादा popular था
कई users बस कुछ download करके कुछ मिनट इस्तेमाल कर देखना और छोड़ देना चाहते हैं। या कम-से-कम try करना चाहते हैं, और worst case में free version पर लौट सकने की वजह से खराब investment करने जैसा feeling avoid करना चाहते हैं
यह लेख “फिर भी यह open source तो नहीं है” वाली बात को, अलग-अलग source-available licenses के तहत software distribute करने की आलोचना की तरह पढ़ता है
कुछ लोग शायद ऐसा मतलब निकालते हों, लेकिन मेरे लिए यह सिर्फ इतना है कि एक स्पष्ट अर्थ वाले term को dilute न किया जाए
कभी-कभी source-available license business के लिए बेहतर होता है, और companies ऐसा क्यों करती हैं यह समझ में आता है
यह कम उदार विकल्प है, लेकिन फिर भी अच्छी बात है। ठीक वैसे ही जैसे यह समझा जा सकता है कि हर software का source code public न किया जाए
सहकारी मॉडल वाले टेक्नोलॉजी संगठन ही भविष्य हैं, ऐसा लगता है
क्योंकि लोग मुफ्त में काम नहीं करना चाहते, इसलिए open source software में योगदान हमेशा निजी कंपनियों से पीछे रहने को मजबूर है
जानना चाहता/चाहती हूं कि क्या ऐसे open source projects हैं जो monetize करके योगदानकर्ताओं को भुगतान करते हैं
अगर कभी मैं एक सफल startup बनाता/बनाती हूं, तो इस model को explore करने का इरादा है