ओपन सोर्स रेज़िस्टेंस: काम के समय में ओपन सोर्स की रक्षा करें

• Open Source Resistance एक direct action manifesto है, जो यह कहता है कि जिन open source software पर कंपनियाँ निर्भर हैं, उनका maintenance चुपचाप, पेशेवर ढंग से, काम के समय के भीतर किया जाए
• हर कंपनी open source के बिना अपना व्यवसाय नहीं चला सकती, फिर भी maintainers को अलग अनुमति, donation button, या शुक्रवार दोपहर का समय माँगने पर मजबूर करने वाली संरचना को यह अस्वीकार करता है
• पहले से Open Source Pledge (प्रति developer प्रति वर्ष US$2,000 भुगतान का आग्रह) और Open Source Friday (हर शुक्रवार कम से कम 2 घंटे योगदान) जैसे विकल्प मौजूद थे, लेकिन यह उनसे अधिक प्रत्यक्ष अमल की बात करता है
• “समय की चोरी” जैसी आपत्ति पर इसका जवाब है कि कंपनियाँ पहले से मुफ्त OSS subsidy का लाभ लेती आई हैं, और जिस OSS पर वे निर्भर हैं उसका maintenance shared infrastructure work है
• रोजगार अनुबंध में मौजूद IP assignment clause को ज़रूर जाँचें, और open source carve-out को लिखित रूप में negotiate करना चाहिए

---

मैनीफेस्टो: जो काम पहले से ज़रूरी है उसे ठीक करने के लिए अनुमति मत माँगो

• Open Source Resistance एक direct action प्रस्ताव है: कंपनी जिन open source software (OSS) पर निर्भर है, उनके maintenance को रात-वीकेंड के शौक में धकेलने के बजाय, चुपचाप और पेशेवर तरीके से काम के समय में किया जाए
• open source software खाली समय का “शौक” नहीं है; कंपनियाँ हर घंटे open source से value निकालती हैं, लेकिन maintainers को बदले में बस शुक्रवार की एक दोपहर, एक donation button, या all-hands में धन्यवाद जैसा कुछ देती हैं
• maintainers को कंपनी के भीतर, कंपनी जिन OSS codebases पर पहले से निर्भर है, उन पर कागज़ी प्रक्रिया, internal program, या manager approval के बिना काम के समय में काम करना चाहिए
• यह कोई नया विचार नहीं है, बल्कि उस तरीके को खुले तौर पर कहना है जिससे ज़्यादातर open source हमेशा से बनता और चलता आया है
• maintainers ने meetings, sprints, या product managers की अनुमति का इंतज़ार किए बिना ही इंटरनेट को चलाए रखा है

मुख्य कार्य सिद्धांत

• अपने को सुरक्षित रखें

  • अपना employment contract जाँचें, confidential information कंपनी के भीतर ही रखें, और यह सुनिश्चित करें कि जो open source IP आप जारी कर रहे हैं उसका ownership आपके पास हो

• काम करें

  • PR review, dependency updates, और उन हिस्सों में bug fix करें जो पहले से OSS हैं

• लापरवाह मत बनें

  • काम के समय का 100% OSS पर खर्च करके नौकरी से निकलने के बाद दूसरों को दोष देना ठीक नहीं; balance सबसे महत्वपूर्ण है

मौजूदा विकल्प

• Open Source Pledge: कंपनियों से maintainers को भुगतान करने का आग्रह (प्रति developer प्रति वर्ष US$2,000)
• Open Source Friday: कंपनियों से समय देने का आग्रह (हर शुक्रवार कम से कम 2 घंटे)
• नियोक्ता को पहले मनाने वाला विनम्र रास्ता भी मौजूद है, और ये सभी सकारात्मक हैं तथा समर्थन के योग्य हैं
• Open Source Resistance इस धारा का अगला कदम है: dependency chain का maintenance, भले ही manager ने उसका नाम न दिया हो, पहले से ही काम का हिस्सा है
• कंपनी अपना budget कैसे बाँटती है, यह आपके control में नहीं हो सकता, लेकिन आप अपना काम का समय कैसे इस्तेमाल करते हैं, यह आपके control में है

संभावित आपत्तियाँ और जवाब

• “यह समय की चोरी है / shareholders के खिलाफ चोरी है”

  • कंपनियाँ पहले से हर दिन open source maintainers से value निकाल रही हैं, और shareholders दशकों से मुफ्त open source subsidy का लाभ लेते आए हैं
  • अगर नियोक्ता OSS पर निर्भर है, तो उसका maintenance करना public-good infrastructure work है, चोरी नहीं

• “अनुमति लेनी चाहिए”

  • अनुमति माँगना power imbalance को बनाए रखने का तरीका है
  • जिस infrastructure पर नियोक्ता पहले से निर्भर है, उसे बनाए रखने के लिए manager की कृपा की ज़रूरत नहीं होनी चाहिए

• “यह quiet quitting जैसा है”

  • quiet quitting काम कम करने के बारे में है, जबकि यह इंटरनेट की बुनियाद बने OSS infrastructure का उत्पादन है
  • समस्या खुद काम नहीं, बल्कि यह है कि कंपनियाँ इसे काम की श्रेणी में रखने से इनकार करती हैं

• “अच्छे नियोक्ता भी इससे प्रभावित होंगे”

  • अच्छे नियोक्ता काम के समय में open source maintenance की अनुमति देकर, maintainers को fund करके, या Open Source Pledge में शामिल होकर इस समस्या से बच सकते हैं

Mike McQuaid का अनुभव

• Open Source Friday और GitHub Sponsors के co-founder, और Homebrew project leader (2009 से maintainer)
• किसी भी नौकरी में Homebrew जैसे open source project पर काम को मुख्य नौकरी के रूप में वेतन नहीं मिला
• फिर भी उन्होंने हर नियोक्ता के साथ यह काम किया, IP agreements को negotiate कर इसे वैध बनाया, और अपने job commitments भी पूरे किए
• बच्चे होने के बाद उनका 90% से अधिक open source work काम के समय में होता है
• Open Source Maintainers Owe You Nothing की तरह उनका मानना है कि सिर्फ इसलिए कि किसी कंपनी का business model उनके code पर निर्भर है, किसी को भी maintainer के unpaid nights, weekends, या family time पर दावा करने का अधिकार नहीं है

सावधानियाँ और कानूनी सूचना

• यह कानूनी सलाह नहीं है

  • इसमें साफ कहा गया है कि यह कानूनी सलाह नहीं है, और न ही यह contracts, employer, immigration status, license obligations, या व्यक्तिगत परिस्थितियों पर सलाह है
  • अगर जोखिम बड़ा है, तो कदम उठाने से पहले किसी योग्य व्यक्ति से सलाह लेनी चाहिए
  • ज़्यादातर open source licenses की तरह, यह बिना किसी warranty के, “as is” आधार पर दिया गया है

• contracts, policies, ownership

  • employment contract, handbook policies, और invention assignment clauses, नौकरी के दौरान बनाए गए काम, employer के equipment पर बने काम, या job scope के भीतर आने वाले काम पर अधिकार जता सकते हैं
  • कुछ राज्यों में private time और private equipment पर बने काम पर ऐसे दावों को सीमित किया जाता है, लेकिन details बहुत महत्वपूर्ण हैं
  • कदम उठाने से पहले employment contract पढ़ना चाहिए और यह सुनिश्चित करना चाहिए कि जिस open source IP को आप सार्वजनिक करना चाहते हैं, उसका मालिक employer न हो
  • अगर device, network, या account ownership risk को बदलते हैं, तो अपनी चीज़ें इस्तेमाल करनी चाहिए

• IP agreement negotiation

  • IP assignment अक्सर negotiate किया जा सकता है; नौकरी का offer मिलने पर sign करने से पहले open source exception clause को लिखित रूप में माँगने की सलाह दी गई है
  • पहले employee IP agreements पढ़ें ताकि समझ सकें कि किन हिस्सों का विरोध करना है
  • Mike McQuaid का कहना है कि उन्होंने लगभग हर employer के साथ standard contract से अलग बदलाव negotiate किए, और ज़्यादातर मामलों में विरोध उम्मीद से बहुत कम था
  • आप संभावित employer को GitHub का Balanced Employee IP Agreement दिखा सकते हैं
  • यह agreement CC0 के तहत open source किया गया है, बड़ी listed companies द्वारा वास्तव में इस्तेमाल हुआ है, और इसे इस तरह design किया गया है कि employer वही रखे जिसका उसने भुगतान किया है, और employee वह open source work रखे जो business से प्रतिस्पर्धा नहीं करता

• गोपनीयता और सुरक्षा

  • private repository, credentials, incidents, customer data, roadmap, unpublished vulnerabilities, या internal discussions को सार्वजनिक नहीं करना चाहिए
  • security controls को bypass नहीं करना चाहिए, और न ही unauthorized access का उपयोग करना चाहिए
  • direct action का मतलब कंपनी की confidential information उजागर करना नहीं है, बल्कि public work को public ही रखना और उसे commercial secrets से साफ़ तौर पर अलग रखना है

• चुपचाप करना लापरवाही नहीं है

  • जब policies, contracts, customer obligations, या safety rules risk बदलते हों, तब अपना विवेक इस्तेमाल करना होगा
  • आपको अपने device, account, और network पर काम करना पड़ सकता है
  • यह कंपनी से “चोरी” करना नहीं, बल्कि कंपनी open source से जो लेती है और आप जो दे सकते हैं, उसके बीच संतुलन बनाना है
  • हो सकता है आपका performance review सहकर्मियों से कम हो, लेकिन टिकाऊ B-grade, उस A-grade के लिए अपनी ज़िंदगी झोंक देने से ज़्यादा स्वस्थ है जिसे कोई कंपनी कल ही नौकरी से निकालकर बेकार कर सकती है

• लागू होने की सीमाएँ

  • जब समय किसी खास customer, grant, government agency, defense project, या regulated environment को bill किया जाता हो, तब यह तर्क सबसे कमज़ोर पड़ता है
  • यह junior या अस्थिर engineers के लिए भी सबसे कमज़ोर है, जिनके पास नतीजों को झेलने की ताकत नहीं होती
  • यह सबसे मज़बूत रूप में उन senior maintainers पर लागू होता है जो employer द्वारा पहले से इस्तेमाल की जा रही public dependencies को ठीक करते हैं
  • इसका सबसे साफ रूप “काम के समय में जो चाहो करो” नहीं, बल्कि open source maintenance को engineering work का हिस्सा मानना है
  • जिन projects को आप पहले से maintain करते हैं उन्हें maintain करें, उन shared tools को बेहतर बनाएं जिनसे आपका काम जुड़ता है, और असंबंधित काम, proprietary code, या ऐसे काम से बचें जो आपके वास्तविक commitments को प्रभावित करे

स्रोत और प्रोजेक्ट

• इसे Mike McQuaid ने बनाया है, और source GitHub पर सार्वजनिक है

[GN⁺]

Hacker News टिप्पणियाँ

• कंपनियाँ आम तौर पर किसी खास open source प्रोजेक्ट में योगदान देने के लिए व्यापक अनुमति दे देती थीं
  बात कहने का तरीका महत्वपूर्ण है। “क्या मैं अच्छा महसूस करने के लिए थोड़ा charitable work कर सकता हूँ?” की बजाय, “क्या मैं इस क्षेत्र के विशेषज्ञों से मुफ़्त में कड़ा review ले सकता हूँ, और fixes को upstream open source प्रोजेक्ट में शामिल करके कंपनी के भविष्य के maintenance cost को खत्म कर सकता हूँ?” कहना चाहिए
  असल में बात यही है, और इस तरह कहने पर किसी employer ने कभी मना नहीं किया। यह पूरी तरह कंपनी के हित में है, बस उन्हें यह साफ़ दिखाना होता है

  • पिछली नौकरी से निकाले जाने की कई वजहों से अफ़सोस है, लेकिन एक बड़ा कारण यह भी था कि मैं Kafka Streams लाइब्रेरी में किए गए काफ़ी बड़े बदलाव को open source के रूप में जारी करने पर चर्चा कर रहा था
    API को ज़्यादातर compatible रखते हुए मैंने बहुत कुछ फिर से लिखा था, और ज़रूरत पड़ने पर backpressure semantics इस्तेमाल कर सकने वाले non-blocking I/O पर ज़ोर था। state stores और blocking/non-blocking I/O को मिलाकर भी काफ़ी performance बनाए रखी जा सकती थी, जिससे कुछ दिलचस्प चीज़ें संभव हुईं, और कई कम दिखने वाले बिंदुओं पर performance निकाला गया था, इसलिए यह प्रोजेक्ट मुझे ख़ास तौर पर गर्व देने वाला लगा
    मैंने इसे GitHub पर public करने या upstream Kafka Streams प्रोजेक्ट को PR भेजने के लिए ज़ोर लगाया, लेकिन उससे पहले layoffs हो गए, और बाद में उस काम को आगे बढ़ाने वाला कोई champion नहीं बचा, इसलिए वह proprietary code बनकर बंद हो गया
    मैं अब भी सोचता हूँ कि क्या इसे शुरुआत से फिर बनाकर free open source के रूप में जारी करूँ। काफ़ी समय बीत चुका है, इसलिए दोबारा लिखकर जारी करने में शायद दिक्कत नहीं होगी, patents जैसी कोई बात भी नहीं थी, और Vert.x dependency हटाने जैसी कुछ चीज़ें थीं जिन्हें मैं बदलना चाहता था। कभी एक हफ़्ते की छुट्टी मिली तो शायद करूँ
  • मुझे उन जगहों पर काम करने के दिन याद आते हैं जहाँ यह अनुमति थी
    कुछ कंपनियों में सिर्फ़ legal review process ही चीज़ों को उलझा देती है
    एक बार मैंने पूछा था कि क्या मैं किसी प्रोजेक्ट में patch भेज सकता हूँ, और उसके बाद एक दिलचस्प email thread चला। आख़िरकार सवाल सिर्फ़ एक था: अगर patch उस समय लिखा गया जब ग्राहक को bill किया जा रहा था, delivery product के bug को ठीक करने के लिए लिखा गया था, patched library को source code के साथ फिर compile करके deliver करना था, और contract में लिखा था कि product से जुड़े सारे deliverables और intellectual property ग्राहक को transfer होंगे, तो क्या हमें उस patch को public domain में जारी करने का अधिकार है?
    legal team जवाब देना ही नहीं चाहती थी
  • कुल मिलाकर यह अच्छा तरीका है, और काम को professional framing देने का बेहतरीन उदाहरण भी। लेकिन इससे मूल समस्या हल नहीं होती। ख़ासकर engineering-driven companies की leadership को तो ये फायदे तुरंत समझ आने चाहिए; अगर नहीं आते, तो वही समस्या है
    आप किस तरह approach कर सकते हैं, यह employer की किस्मत पर भी बहुत निर्भर करता है
  • “ठीक है, मैं इसे compliance team के पास घुमा देता हूँ। बस यह सुनिश्चित करना है कि कोई intellectual property infringement न हो। कौन-सा repository और issue है, ठीक-ठीक?”

• “और जो open source intellectual property आप distribute करते हैं, उस पर पक्का ownership रखिए” वाली बात के बारे में, जिन jurisdictions में मैंने काम किया वहाँ नौकरी के समय में लिखा और distribute किया गया code मेरा नहीं बल्कि employer का होता था
  मैं अपने-आप तय नहीं कर सकता था कि काम के समय योगदान करूँ, और open source code पर काम करने के लिए formal agreement चाहिए होता था। हर बार request करने पर legal department से गुजरने में महीनों लग जाते थे, इसलिए आख़िरकार मैंने छोड़ दिया, या तब तक कोई और contributor PR भेज चुका होता था और फिर request करने का मतलब नहीं रह जाता था

  • शायद मतलब यह रहा होगा कि “जो चीज़ आपकी नहीं है, उसे अपनी मर्ज़ी से donate करने की कोशिश मत कीजिए।” नीचे इससे जुड़ा अलग section है, लेकिन ऊपर वाला bullet अकेले पढ़ने पर भ्रम होता है
    अनुभवी developers के लिए यह obvious है, लेकिन कुछ कंपनियों में junior developers के लिए यह सचमुच समस्या रही है। कंपनी अगर किसी internal project में कुछ बढ़िया कर रही हो, तो लोग सोचते हैं कि उसे किसी open source project में contribute करना अच्छा होगा, लेकिन वे यह नहीं सोचते कि private code की जानकारी का इस्तेमाल करके substantially similar code submit करना, या कभी-कभी copy-paste कर देना, भी समस्या बन सकता है
  • मैंने ख़ुद verify नहीं किया, लेकिन मेरी समझ में जर्मनी में डिफ़ॉल्ट रूप से काम के समय लिखा गया सारा source code employer का होता है
    ज़्यादातर non-IT employers शायद open source क्या है और कैसे काम करता है, यह भी नहीं समझते होंगे। इसलिए बहुत लोगों से अनुमति लेना निराशाजनक हो सकता है
    linked site के लिए बेहतर होगा कि वह पहले employers को open source के फ़ायदे समझाए, और employers के लिए legal guidelines की वकालत करने पर ध्यान दे
  • अगर कोई कंपनी production में जाने वाले हिस्सों को छोड़कर बाकी चीज़ों को permissive license code के रूप में जारी नहीं करने देती, तो मैं ऐसी नौकरी नहीं करूँगा। मेरे लिए यह हतोत्साहित करने वाली बात है और मानसिक रूप से मुझे सीमा तक धकेल देगी। मैं इससे बेहतर ग़रीब रहना पसंद करूँगा

• विचार अच्छा है, बल्कि बहुत अच्छा है, लेकिन इसे resistance के रूप में पेश करना सही है या नहीं, यह पक्का नहीं
  नौकरी का उद्देश्य आम तौर पर किसी लक्ष्य को हासिल करना होता है। उस लक्ष्य तक कैसे पहुँचना है, यह expert developers तय कर सकते हैं। अगर उस फ़ैसले में open source software शामिल है, तो उसके maintenance का काम भी उसी फ़ैसले का हिस्सा होना चाहिए
  यह कोई radical बात नहीं है, बस अपने काम को इस तरह करना है कि जिन चीज़ों पर काम निर्भर है उनकी future stability और maintainability बनी रहे

  • यह बस अच्छी business sense भी है। जो कंपनियाँ open source के ज़रिए collaboration को बढ़ावा देती हैं, वे उस ecosystem को मज़बूत करती हैं जो उनके business को चलाता है
  • कही गई बातों से पूरी तरह सहमत हूँ, लेकिन आजकल ज़्यादातर tech companies की वास्तविकता, मेरे अनुभव में, अलग है। वे तब तक अपने infrastructure और libraries के maintenance में समय नहीं लगातीं जब तक मजबूर न किया जाए; open source तो और भी मुश्किल है
    metrics game के लिए बेकार features, enshittification, dark patterns, और malware जैसी लगने वाली trendy integrations को foundational infrastructure या libraries में निवेश से ऊपर रखा जाता है
  • सहमत। इस तरह का वर्णन ऐसा लगता है जैसे कोई social media पर ज़्यादा attention खींचना चाहता हो। अफ़सोस है कि हम उस बिंदु तक आ पहुँचे हैं जहाँ हर चीज़ को बढ़ा-चढ़ाकर पेश करना पड़ता है

• सामान्य सिद्धांत के तौर पर मैं पूरी तरह सहमत हूँ, लेकिन व्यवहार में इसे करना मुश्किल है। मैं lawyer नहीं हूँ, लेकिन आम तौर पर employer intellectual property का मालिक होता है, इसलिए उसे open source के रूप में जारी करने के लिए explicit permission चाहिए होती है
  और वह permission लेने की प्रक्रिया अक्सर कठिन होती है, जिसमें अंतहीन steps और legal department से गुज़रना पड़ता है
  “अमेरिका, ब्रिटेन और कई jurisdictions में, अगर कर्मचारी नौकरी के हिस्से के रूप में कोई रचना बनाता है, तो employer को legal author या initial copyright holder माना जाता है”
  https://en.wikipedia.org/wiki/Work_for_hire
  फिर भी मेरा मानना है कि open source पर काम, यानी maintenance और development, दान माँगने वाले volunteers नहीं बल्कि paid professionals को करना चाहिए। असली सवाल यह है कि इसे कैसे संभव बनाया जाए, और कंपनियाँ open source contributions को अलग-अलग negotiation वाली exception नहीं बल्कि standard practice के रूप में कैसे स्वीकार करें

  • बताए गए मुद्दे “व्यावहारिक समस्याएँ” कम और सैद्धांतिक समस्याएँ ज़्यादा लगते हैं
    व्यवहार में तो बस कर देना चाहिए। कंप्यूटर के अंदर git push को रोकने वाला कोई subroutine नहीं है। असल में employers employment contract में हर तरह की चीज़ लिख देते हैं। वे हर दिशा से liability से बचने के लिए जितना हो सके उतना लिखते हैं। अगर वे अपनी मर्ज़ी से लिख सकते हैं, तो हम बस कर क्यों नहीं सकते? कुछ भी मायने नहीं रखता
    वास्तव में ऐसे technical कारणों से intellectual property पर चुनौती झेलने वाले open source projects लगभग शून्य के बराबर हैं
  • अगर काम आपकी नौकरी से संबंधित है, तो employer के पास intellectual property rights होने की बात सही है
    अगर वह नौकरी से संबंधित नहीं है, तो यह state के हिसाब से बदलता है। कई states में इस बात पर सीमाएँ हैं कि employer किस हद तक किसी चीज़ को अपनी intellectual property बता सकता है। सामान्य contracts अक्सर भाषा को बहुत चौड़ा रखकर सब कुछ claim करना चाहते हैं, लेकिन क़ानून अक्सर कहता है कि कंपनी ऐसे free-time work पर अधिकार नहीं जता सकती जो employer से संबंधित ही न हो
    अगर आप काम ऑफिस समय में करते हैं या company laptop इस्तेमाल करते हैं, तो कंपनी के पास दावा करने की गुंजाइश बन जाती है। ज़्यादातर कंपनियाँ परवाह नहीं करेंगी, लेकिन विवाद होने पर चीज़ें साफ़ रखना हो तो लापरवाह नहीं होना चाहिए
    व्यक्तिगत समय, व्यक्तिगत उपकरण इस्तेमाल करें, और यह सुनिश्चित करें कि काम आपके hired duties या कंपनी में देखी गई चीज़ों से overlap न करे
  • मैं lawyer नहीं हूँ, लेकिन अगर आपने किसी सहकर्मी को चलाकर देखने के लिए उसकी copy दी, तो क्या वह अपने-आप में open source license का इस्तेमाल नहीं हुआ? उस सहकर्मी को license से मिले legal rights मिल जाते हैं, और क्या उसे changes redistribute करने का अधिकार भी नहीं होगा?
    changes को upstream भेजना maintenance सुनिश्चित करने का सबसे अच्छा तरीका है, और यह सब बहुत हास्यास्पद लगता है। internal proprietary forks को बनाए रखने से जुड़ी legal uncertainty भी उतनी ही हास्यास्पद है
  • लेख शायद सबसे कम resistance वाले रास्ते पर चलने का सुझाव देता है। यानी company time में काम करो, और बड़ा हंगामा मत करो। पकड़े जाओ तो माफ़ी माँग लो। कंपनी के लिए माफ़ कर देना आसान रास्ता है। lawyers को खींचने पर लागत बहुत बढ़ सकती है, और PR disaster भी बन सकता है
  • अगर मौजूदा programming की हालत ने कुछ दिखाया है, तो वह यह कि intellectual property और copyright law अब जैसे मौजूद ही नहीं हैं

• मैं काफ़ी बड़ी company में काम करता हूँ। हमारी open source policy मोटे तौर पर ऐसी है: “पहले manager से पूछो, company के नाम से मत करो, और confidential information disclose मत करो”
  कभी कोई समस्या नहीं हुई, और बड़े स्तर पर यह पूरी तरह उचित लगता है

• काम के समय किसी third-party open source project में bug fixes जैसा योगदान करना मुझे ठीक लगता है, लेकिन अपने open source का क्या किया जाए, यह समझ नहीं आता
  मान लीजिए मेरे पास निजी तौर पर बनाई गई एक छोटी library है, और कंपनी उसे इस्तेमाल करने लगती है, फिर काम के समय उसमें bug मिलता है। अगर मैं उसी काम के समय उसमें contribute करूँ, तो वह gray area लगेगा
  क्या किसी ने interview के दौरान इस तरह की चीज़ negotiate की है? कैसे किया, यह जानना चाहूँगा

  • मैंने कभी ऐसी कंपनी में काम नहीं किया जो सचमुच इसकी परवाह करती हो। मैं बस ज़रूरी काम करता था। “इसे सही तरीके से करना हो तो क्या करें?” पूछने पर भी मुझे कभी जवाब नहीं मिला

• जब मैं बड़े enterprise में काम करता था, तो आम तौर पर company codebase में सीधे code लिखने के अलावा किसी भी काम के request पर, चाहे वजह बताऊँ, direct manager कहता था “अपने free time में करो”
  profit-driven environment में सिर्फ़ वही चीज़ करने लायक मानी जाती है जिसकी immediate value दिखे। यह रवैया काफ़ी parasitic है, और ऊपर से आने वाली ज़्यादा efficiency व metrics competition इसे ऐसा बनाती है

• मैंने निश्चित ही work problem सुलझाने के लिए fork किया है, fixes किए हैं, और फिर नतीजे upstream को PR के रूप में भेजे हैं
  यही open source की अच्छी बातों में से एक है कि आप उसे इस्तेमाल भी कर सकते हैं और access भी कर सकते हैं। package.json और cargo.toml में git का लगभग first-class option होना भी इसी वजह से है। जब तक changes upstream न हो जाएँ, तब तक आप सीधे fork को point कर सकते हैं

• senior होने पर interview process में जब “क्या आपके पास हमारे लिए कोई सवाल है?” वाला चरण आता है, तो मैं पूछता हूँ: “जिन open source projects पर यह कंपनी निर्भर करती है, उन्हें मैं अपने समय का कुछ हिस्सा contribute करूँ, इस पर कंपनी का क्या रुख है?”
  जवाब देखकर तय किया जा सकता है कि आगे बढ़ना है या नहीं