- 1986 में रिलीज़ हुए PostgreSQL के मुख्य कोड को वास्तव में मेंटेन करने वाले लोगों की परत अब उम्रदराज़ हो रही है, और 20 साल बाद यह काम कौन आगे बढ़ाएगा, इस पर sustainability का सवाल उभर रहा है
- 2022 के आँकड़ों के अनुसार कम-से-कम एक commit के principal author रहे डेवलपर्स की संख्या 192 थी, और नए कोड का 66% केवल 14 लोगों ने, जबकि 90% केवल 40 लोगों ने लिखा — यानी कुछ लोगों पर अत्यधिक निर्भर संरचना
- मुख्य डेवलपर समुदाय की औसत आयु लगभग 50 वर्ष है, और Tom Lane 68 वर्ष की उम्र में भी प्रोजेक्ट की केंद्रीय धुरी बने हुए हैं
- Neon ने मौजूदा top talent को hire करने के बजाय juniors को लेकर उन्हें contributor से committer और maintainer तक विकसित करने में अगली पीढ़ी तैयार करने के लिए जानबूझकर निवेश किया है
- प्रोजेक्ट के दीर्घकालिक मेंटेनेंस के लिए इरादतन प्रयास, फंडिंग, और enlightened self interest की ज़रूरत है
PostgreSQL की बढ़ती उम्र और मेंटेनेंस प्रतिभा की समस्या
- 1986 में रिलीज़ हुआ PostgreSQL आधुनिक सॉफ़्टवेयर डेवलपमेंट के बड़े हिस्से में एक डिफ़ॉल्ट विकल्प बन चुका है, लेकिन इतने लंबे समय बाद अब यह सवाल उठ रहा है कि डेटाबेस को वास्तव में बनाने और सँभालने वाले लोगों की निरंतरता कैसे बनी रहेगी
- बहुत से लोगों द्वारा इस्तेमाल किए जाने वाले इस हाई-प्रोफ़ाइल कोडबेस के heavy lifting को ये लोग और कितने समय तक करते रहेंगे, यह एक अहम प्रश्न है
- Postgres एक छोटा लेकिन बहुत घनिष्ठ रूप से जुड़ा हुआ प्रोजेक्ट है
2022 के contributor आँकड़े
- EnterpriseDB के chief database scientist और Postgres committer Robert Haas ने अपनी नियमित योगदान-स्थिति पोस्ट "Who Contributed to PostgreSQL Development in 2022?" में ये आँकड़े साझा किए
- 2022 में कम-से-कम एक PostgreSQL commit के principal author 192 लोग थे
- नई कोड लाइनों का 66% 14 लोगों में से किसी एक ने लिखा
- नई कोड लाइनों का 90% 40 लोगों में से किसी एक ने लिखा
मुख्य समुदाय की आयु संरचना
- मुख्य डेवलपमेंट समुदाय कुछ हद तक उम्रदराज़ हो चुका है और उसकी औसत आयु लगभग 50 वर्ष है
- Crunchy Data से जुड़े Tom Lane 68 वर्ष के हैं और अब भी Postgres प्रोजेक्ट की केंद्रीय धुरी की भूमिका निभा रहे हैं
ओपन गवर्नेंस और 20 साल बाद का सवाल
- Postgres का Open governance एक भरोसेमंद आधार है, और ऐसे समय में जब commercial open source licenses में एकतरफ़ा बदलाव आम होते जा रहे हैं, यह एक ताज़गी भरा उदाहरण है
- open source sustainability के नज़रिए से, अगर माना जाए कि Postgres 20 साल बाद भी मज़बूती से मौजूद रहेगा, तो सवाल यह है कि 2043 में यह काम कौन करेगा
Neon और Nikita Shamgunov की चर्चा
- Neon के CEO Nikita Shamgunov के साथ बातचीत में तकनीकी प्रोजेक्ट्स की बढ़ती उम्र और उसका प्रोजेक्ट sustainability से संबंध चर्चा का विषय रहा
-
Neon परिचय
- Neon serverless apps के लिए optimized एक fully managed Postgres database है, जो storage और compute को अलग करके "database is a URL" का डिज़ाइन सिद्धांत अपनाता है
- यह preview deployments के लिए branching को सपोर्ट करता है, और इसी के ज़रिए Vercel के साथ साझेदारी बनी
- इसका लक्ष्य है चीज़ों को "आसान, आधुनिक, और zero config API" के रूप में बनाना
- कंपनी में 62 कर्मचारी हैं, कुल फंडिंग $108m है, और यह Supabase जैसी कंपनियों से प्रतिस्पर्धा करती है
-
committer और contributor का अंतर
- Shamgunov के अनुसार, "Postgres committer परत में 50s, 60s और 40s के लोग हैं, जबकि 30s बहुत कम हैं"
- committer बनना बहुत मेहनत माँगता है, लेकिन contributor बनने के लिए सिर्फ अच्छा कोड लिखना काफ़ी है
अगली पीढ़ी के committers तैयार करने में निवेश
- Neon contributor, committer और maintainer की अगली पीढ़ी में जानबूझकर निवेश कर रहा है
- कई कंपनियों का स्वाभाविक विकल्प नए लोगों को विकसित करने के बजाय पहले से स्थापित top talent को hire करना होता है
- Shamgunov ने कहा, "हमने और Postgres committers को ढूँढकर hire करने पर चर्चा की, लेकिन यह साफ़ नहीं था कि यही फंड का सबसे अच्छा उपयोग है"
- "नए लोगों को तैयार करना बेहतर है, और उसी तरीके से हम Postgres टीम को लगातार बढ़ा सकते हैं"
- Shamgunov ने ज़ोर देकर कहा कि juniors को hire और train करके उन्हें committer, और आगे चलकर maintainer बनाना Postgres engine के निरंतर विकास के लिए महत्वपूर्ण है
लाइसेंस और enlightened self interest
- Neon का IP अभी permissive license के तहत है, लेकिन Shamgunov open source purist नहीं हैं
- भविष्य में Neon के पास Redis, MongoDB, और Elastic की तरह relicense करके अधिक प्रतिबंधात्मक शर्तों में जाने का अधिकार हो सकता है
- हालांकि, Postgres में पहले से योगदान किया गया कोड ऐसे किसी फ़ैसले से प्रभावित नहीं होगा
- कंपनी के भीतर मुख्य Postgres maintainers का होना enlightened self interest का एक उदाहरण है; यह कंपनी को ईमानदार बनाए रखने का एक तंत्र है, और कंपनी कोई भी फ़ैसला ले, समुदाय और मुख्य कोडबेस को उससे लाभ मिलता है
cohort aging की व्यापकता
- cohort aging केवल Postgres तक सीमित समस्या नहीं है; पहले Y2K के उदाहरण की तरह, समुदाय और ecosystem भी उम्रदराज़ होते हैं, और इससे तकनीक, प्रतिभा, और पीढ़ीगत बदलाव के स्तर पर समस्याएँ पैदा हो सकती हैं
- IBM ने विश्वविद्यालय-आधारित vocational programs आदि के माध्यम से युवा डेवलपर्स को mainframe क्षेत्र में आकर्षित करने में सफलता पाई है
- Postgres या Kubernetes जैसी बड़ी परियोजनाओं के अलावा, ऐसे भी कई प्रोजेक्ट हैं जिन्हें बिना corporate backing के केवल एक-दो लोग चलाते हैं, जबकि उनके उपयोगकर्ता लाखों में हैं
निष्कर्ष — मेंटेनेंस में इरादतनता
- Postgres को नए उपयोगकर्ता जुटाने में कोई कठिनाई नहीं है, और आज के 22 वर्षीय डेवलपर्स भी इसे डिफ़ॉल्ट रूप से चुनते हैं — यह एक बेहद लोकप्रिय platform है
- लेकिन प्रोजेक्ट के निरंतर मेंटेनेंस को सुनिश्चित करने के लिए intentionality, funding, और enlightened self interest की ज़रूरत है
खुलासा
- Neon, RedMonk का ग्राहक नहीं है, जबकि Crunchy Data, IBM, और Vercel सभी RedMonk के ग्राहक हैं; यह लेख ग्राहक संबंधों से स्वतंत्र रूप से प्रकाशित किया गया है
1 टिप्पणियां
Hacker News की टिप्पणियां
46 साल का हूं, लेकिन अगली पीढ़ी में शामिल होना चाहता हूं, और पक्का लगता है कि मुझसे कम उम्र के लोग भी होंगे
PGCon में मेरी आखिरी presentation उन कमियों पर थी जिन्हें Postgres को hack करने के लिए जानना जरूरी है, खासकर executor चरण और TupleTableSlot को भरने की कोशिश
मैं शायद सबसे उपयुक्त व्यक्ति नहीं हूं, लेकिन कभी-कभी सीख रहा व्यक्ति बेहतर समझता है कि learners को क्या चाहिए
कुछ समय पहले मैंने Postgres में contribute करने के तरीकों पर एक किताब की table of contents भी लिखी थी, और लगता है कम से कम 10 copies तो बिकेंगी
शायद online serial ज़्यादा बेहतर हो, लेकिन दोनों में से किसी भी रूप में, सोच रहा हूं कि क्या कोई interested होगा
अभी Postgres मेरे लिए hobby जैसा है, लेकिन अगर कोई ऐसी जगह हो जो open source Postgres contribution को full-time करने के लिए किसी को ढूंढ रही हो, तो बात करने को तैयार हूं
आज की अगली पीढ़ी के काफी लोग भी Postgres में काफी देर से आए हैं
Tom भी खुद को कम करके बताएगा, लेकिन उसने कई साल image-related काम किया, और tiff, jpg, png में से हर एक के creation process में किसी न किसी रूप में शामिल रहने के बाद Postgres खोजा और उस पर काम शुरू किया
वे Postgres contribution शुरू करने के तरीके पर काफी content बनाते हैं, और दूसरे PG enthusiasts से बात करने को भी friendly हैं
collaboration या सलाह भी मिल सकती है: https://www.youtube.com/watch?v=rihfAnd_leM
email x4mmm@.ru या Twitter @x4mmmmmm पर संपर्क किया जा सकता है
participation barrier कम हो गया है, इसलिए उम्मीद है कि और लोग जल्दी retire होकर open source में हिस्सा लेंगे
कुछ publishers early-access readers को errors report करने की अनुमति देते हैं: https://nostarch.com/early-access-program
यह इतना दिलचस्प है कि early retirement संभव हो जाए और Postgres को full-time hack करना लक्ष्य बन जाए
इसमें networking, storage, data, algorithms सब शामिल हैं
सच कहूं तो C कम बड़ी समस्या है, और Postgres का code style अच्छा और काफी consistent है
मुश्किल चीज internal structure की complexity है, और community छोटी हो तो मदद मिलने की speed पर भी असर पड़ सकता है
सोच रहा हूं कि आगे चलकर C codebases को maintainers ढूंढने में दिक्कत होगी या नहीं
Postgres के पास commercial support और inertia है, लेकिन skilled C developers के आने का रास्ता कम दिखता है
C अभी भी जीवित भाषा है, उसके active users की कमी नहीं है, और दूसरी भाषाओं में systems programming करने वालों के लिए learning curve भी बहुत steep नहीं है
आज के web और application developers को C डरावना लग सकता है, क्योंकि उनके और lower-level system architecture के बीच एक opaque curtain है, लेकिन C++ या Rust इस्तेमाल करने वाले systems programmers पहले से ही उस curtain के पीछे और मोटे gloves पहनकर काम कर रहे हैं
इनमें से कई लोगों ने education या experimentation के दौरान C देखा होता है, और अगर professionally जिम्मेदारी मिले तो वे जानबूझकर पढ़कर खतरनाक pitfalls के अनुकूल हो सकते हैं
नए system projects के लिए C चुनने के खिलाफ arguments हैं, लेकिन systems programmers की कमी की समस्या को छोड़ दें तो मौजूदा code के maintainers ढूंढने को लेकर फिलहाल बड़ी चिंता नहीं दिखती
scientific तरीके से measure नहीं किया, लेकिन नए contributors की average C skill पहले से कम लगती है, हालांकि यह मेरे grey beard की बात भी हो सकती है
अभी तक लोग “काम करते हुए सीखने” के तरीके से चल रहे हैं, लेकिन यह gap कितना बड़ा है, पक्का नहीं है
कभी न कभी system के कुछ हिस्सों में, जैसे core के अंदर data type implementations में, दूसरी languages का इस्तेमाल आसान करना होगा, लेकिन realistically यह अभी कुछ दूर की बात लगती है
मुश्किल हिस्सा सही domain knowledge हासिल करना है, और पूरे system से familiar होने में समय लगता है
skilled Rust या C++ developers में ऐसे लोग बहुत कम जानता हूं जो C में भी अच्छे न हों
हालांकि यह देखना दिलचस्प होगा कि और C codebases कब modules अलग करके उन्हें Rust से replace करना शुरू करते हैं
यह पहले से Linux, curl, Chrome जैसे C++ projects, कई MS products, Amazon S3 आदि में हो रहा है
मेरे जानने में सबसे explicit holdout OpenBSD है, क्योंकि वह bootstrap और default install toolchain को छोटा रखना चाहता है
TypeScript का type system भी C से काफी जटिल है
या फिर यह C की complexity को लेकर मेरी अनभिज्ञता दिखा रहा हो सकता है
इस विषय पर मेरे काफी विचार हैं
कम्युनिटी लंबे समय से फैलती-सिमटती रही है, और PG कम्युनिटी के बारे में थोड़ा और साझा करने के इरादे से कुछ बातें कह रहा/रही हूं
कई सालों तक कोई नया committer बिल्कुल नहीं था, और हाल में टीम नए committers को ज्यादा सोच-समझकर जोड़ने और जो लोग अब भाग नहीं ले रहे उन्हें साफ करने की कोशिश कर रही है
करीब 15 साल पहले एक दौर था जब काफी युवा लोगों को commit अधिकार मिले थे; मुझे तीन लोग याद हैं जो 25 साल से कम, शायद सभी 22 साल से कम उम्र के थे
उनमें से एक थोड़े समय बाद Postgres कम्युनिटी से बाहर चला गया, एक 10 साल से ज्यादा समय तक दूसरे कामों में चुपचाप व्यस्त रहने के बाद वापस आया, और एक लगातार सक्रिय रहा
commit अधिकार मिलने के बाद गायब हो जाने वाले लोगों को लेकर असहजता थी, इसलिए लगता है कि कुछ सालों तक नए लोगों को जोड़ने की रफ्तार धीमी हो गई
संक्षेप में, इसका मतलब है कि कॉलेज से निकलते ही तुरंत Postgres commit अधिकार मिलना मुश्किल है
एक दिलचस्प, लेकिन इकट्ठा करने में कठिन डेटा यह है कि लोग किस उम्र में Postgres committer बनते हैं
अगर औसतन commit अधिकार पाने की उम्र 45 साल के करीब हो तो मुझे हैरानी नहीं होगी
कई contributors दूसरे सिस्टम्स पर काम करने के बाद Postgres में आते हैं, या mailing list पर patches भेजने का तरीका डराने वाला लगता है, इसलिए कुछ करियर अनुभव जमा होने के बाद ही योगदान के बारे में सोचते हैं
उस व्यक्ति के पहले commit की कहानी शानदार है
Materialize में SQL behavior टेस्ट करते समय वह देखना चाहते थे कि दोनों systems interval functions को एक जैसा handle करते हैं या नहीं, और उन्होंने बहुत बारीकी से
select interval '0.5 months 2147483647 days';जैसी चीजें आजमाईंइसे dbfiddle पर खुद आजमा सकते हैं: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
Postgres ने error के बजाय
{"days":-2147483634}जैसा गलत value return किया, और वजह यहां पढ़ सकते हैं: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...इसलिए स्वाभाविक रूप से इसे Postgres में fix किया गया, और उसकी वजह से version 15 और उससे ऊपर में यह सही तरह handle होता है: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
मुझे Postgres इतना पसंद है कि मैंने PG tattoo तक बनवाया है, लेकिन योगदान के दोनों रास्ते आसान नहीं हैं
अगर free time में किसी random user की तरह योगदान करना चाहें, तो “पहली बार के लिए अच्छे issues” जैसे tickets ज्यादा नहीं हैं, और PG architecture के कई हिस्सों का context और उनके ऐतिहासिक कारण थोड़ा भी न पता हो तो शुरू करना मुश्किल है
Tom या Andres जैसे लोगों से patch review करवाना भी डराने वाला हो सकता है
EDB, PG Pros, Crunchy जैसी paid PG companies में developer के तौर पर जाना भी लगभग chicken-and-egg problem जैसा है
पिछले PG hacking अनुभव के बिना junior के रूप में hire होना मुश्किल है, लेकिन वह अनुभव हासिल करने का रास्ता भी आसान नहीं है
अगर मेरी मौजूदा company नहीं होती, तो मैं PG काम करने वाली जगह पर काम करना चाहूंगा/चाहूंगी, लेकिन व्यावहारिक entry routes ज्यादा नहीं हैं
हाल में committer बने 10 लोगों के लिए, commit messages में पहली बार उनका नाम कब आया और committer के तौर पर उनका पहला commit कब हुआ, इसकी तुलना करने के लिए मैंने नीचे जैसे कुछ git commands चलाए
सिर्फ month/year की तुलना करने पर औसत भागीदारी अवधि करीब 8.9 साल थी, और सबसे छोटा मामला भी करीब 6.5 साल था
इससे बेहतर analysis भी संभव है, लेकिन लक्ष्य बस एक मोटा अंदाजा लेना था
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1उस समय शायद 22 साल के व्यक्ति के लिए इसे समझना आसान था, और वह ज्यादा हिस्सों को grasp कर सकता था
साथ ही तब C एक standard language थी, लेकिन आजकल युवा developers के C की बजाय Rust में programming करने की संभावना ज्यादा है
मुझे बिल्कुल नहीं पता था कि 22 साल से कम उम्र में commit अधिकार पाने वाले लोगों का एक झुंड था
मैं एक नया contributor हूं जिसने 5 महीने पहले Postgres में contribute करना शुरू किया था, और इस महीने के आखिर में 27 साल का हो जाऊंगा
अभी तक मैंने बहुत ज़्यादा valuable contributions नहीं किए हैं, लेकिन कुछ commits हैं, और आगे चलकर मैं Meson से Postgres extensions build करना आसान बनाना चाहता हूं और हो सके तो autotools build को जल्दी हटाने पर भी काम करना चाहता हूं
जल्द ही आप मुझे pgbouncer या pgvector repositories में भी देख सकते हैं
contribute करने की वजह यह थी कि मैं उस software consulting company से थक गया था जहां मैंने 3 साल काम किया था
मैं असल में open source system software वाला इंसान बनकर रहना चाहता था, और मुझे Micron में open source storage engine पर काम मिला
सच कहूं तो मेरी किस्मत अच्छी थी, लेकिन job posting ऐसी लगी जैसे मेरे लिए ही लिखी गई हो, इसलिए मैंने apply किया, और उस project पर 2.5 साल तक खुशी से काम किया
दुर्भाग्य से फरवरी के आखिर में Micron ने पूरी team को lay off कर दिया, और उसके बाद MongoDB से C/C++ driver पर काम का offer मिला था, फिर वापस ले लिया गया
उसके बाद मैंने अपने network पर ज़्यादा भरोसा करना शुरू किया, और Libera.Chat/Matrix के #mesonbuild में जिसे जानता था वह Postgres पर काम कर रहा था, इसलिए मैंने पूछा कि क्या मेरे background के हिसाब से कोई Postgres-related role है
उसने बताया कि Neon hiring कर रहा है, और मैंने storage engine team में apply किया, लेकिन पहले interview में ही वह व्यक्ति जो बाद में मेरा manager बनने वाला था, इस नतीजे पर पहुंचा कि मैं उनकी नई बनाई जा रही Postgres team, यानी upstream Postgres में contribute करने वाली team, के लिए ज़्यादा fit हूं
मुझे मौका देने के लिए मैं Neon का बेहद आभारी हूं
इस लेख का विषय दिलचस्प है क्योंकि PGConf NYC में दूसरे युवा Postgres contributors से बात करते हुए अभी-अभी यह मुद्दा उठा था
छोटे patch तक review करवाना मुश्किल है, और community में नाम जितना जाना-पहचाना होता है, उतने ज़्यादा reviews मिलते लगते हैं, इसलिए यह एक cyclic समस्या बन जाती है
Postgres mailing list का structure भी अच्छा नहीं है: pgsql-hackers नाम की firehose को सीधे पीना पड़ता है, जबकि LKML कई subsystems में बंटी है
modern code forges में PR/issues के specific tags subscribe करने की value होती है, लेकिन अभी pgsql-hackers में ऐसा कोई तरीका नहीं है
commitfest में item जोड़ना भी थोड़ा झंझट भरा है, और पूरे Postgres CI से गुजरने के लिए उसे commitfest में डालना पड़ता है; उसके बाद भी आपको खुद check करना पड़ता है या उम्मीद करनी पड़ती है कि कोई committer CI failure देखने को कहेगा
bug reports भी pgsql-bugs mailing list में जाती हैं, और Postgres में Linux bugzilla जैसा कोई equivalent नहीं है
patches email attachment के रूप में भेजे जाते हैं और जरूरी नहीं कि वे git-format-patch format में हों, जबकि देखने में LKML लगभग exclusively git-send-email इस्तेमाल करता है
कुल मिलाकर Postgres contributor community के tools उन लोगों के लिए सबसे अच्छे लगते हैं जो 15+ साल से इसके अंदर गहराई से जमे हुए हैं
मैं इसे “GitHub/GitLab इस्तेमाल करें” वाला लेख नहीं बनाना चाहता, और बल्कि मुझे लगता है कि patch discussion के लिए email बेहतर है, लेकिन mailing list के आसपास के tools बेहतर हो सकते हैं
सब कुछ बहुत अलग-अलग बंटा हुआ है, और मुझे लगता है कि SourceHut ने mailing list based development को रोज़मर्रा के contributors के लिए ज़्यादा accessible बनाने में अच्छा काम किया है
issues, mailing list, CI/CD और repository सब connected हैं, अभी के Postgres की तरह अलग-अलग services में नहीं बंटे
यह comment खुद किसी दिन अलग blog post बन सकता है, लेकिन यहीं खत्म करता हूं
अगर आप Postgres contribution में नए हैं, तो शायद हम अपने experiences share कर सकते हैं; tristan neon.tech या tristan partin.io पर email कर सकते हैं
एक और Postgres contributor का मानना था कि non-committer contributors के बीच हर महीने मिलने, अपने चल रहे या publish किए गए patches पर बात करने और peer review पाने की meeting useful हो सकती है
Tristan शायद online meetup lead कर सकता है
Melanie Plageman को भी ऐसे idea में interest था, और हमने अलग-अलग तरह के office hours पर थोड़ी चर्चा की थी
यह एक अच्छा लेख बन सकता है, और organization और process के लिहाज से Postgres community जिन चीज़ों को अपेक्षाकृत आसानी से improve कर सकती है, उनमें से लगता है
हालांकि “name recognition” वाले हिस्से को लेकर मैं कम निश्चित हूं, और लगता है कि दूसरी तरफ भी काफी drop-off है
pgsql-hackers के firehose जैसा महसूस होने वाली समस्या सही है, और मुझे लगता है कि पिछले कुछ वर्षों में यह बहुत बदतर हो गई है
commitfest में डाले बिना भी repository में CI चालू किया जा सकता है: https://github.com/postgres/postgres/blob/master/src/tools/c...
यह वही CI है जो commitfest items के लिए चलता है
bug reports का mailing list में जाना मुझे सच में पसंद नहीं है, और मैं भी उन्हें लगातार miss करता हूं
मुझे kernel bugzilla भी काफी बेकार लगता है, लेकिन उससे बेहतर करना मुश्किल नहीं होना चाहिए
मुझे LKML-style patch handling भी अच्छी नहीं लगती, खासकर क्योंकि patchset के हर revision पर नया thread बनता है, जिससे tracking बहुत आसान नहीं हो जाती
लगभग 15 साल development में शामिल रहने के बाद भी मैं यह नहीं कहूंगा कि मौजूदा tools खास तौर पर अच्छी तरह काम करते हैं
development process समय के साथ कुछ हद तक evolve हुई है, लेकिन जितनी जरूरत है उतनी नहीं
PG community जैसी grey-beard-heavy community को बदलना बहुत मेहनत मांगता है; असंभव नहीं है, लेकिन आसान भी नहीं
व्यक्तिगत रूप से मैं complex कामों के लिए GitHub या GitLab इस्तेमाल करने को strongly dislike करता हूं, लेकिन नए contributors के लिए आसान बनाने के लिए इनमें से किसी एक के जरिए PR/MR accept करने चाहिए, ऐसा सोचता हूं
हालांकि यह सिर्फ मेरे decision से होने वाली चीज़ नहीं है
patch discussion के लिए email बेहतर है, लेकिन आसपास के tools improve होने चाहिए—इस विचार का विरोध करने वाले शायद 2-3 लोगों से ज़्यादा नहीं होंगे
समस्या यह है कि बहुत से लोग development process tools या integration पर समय लगाने के बजाय Postgres hacking में समय लगाना चाहते हैं
pgrx की मदद से मैंने Postgres पर थोड़ा काम किया है, और इसे data solutions बनाने के platform के रूप में recommend कर सकता हूं
CMU channel भी अच्छा resource था: https://www.youtube.com/@CMUDatabaseGroup
उदाहरण के लिए अगर आप नया Table Access Method handler लिखना चाहें, तो core pg-sys SDK में TableAM-related bindings हैं, लेकिन Rust में उन्हें कैसे इस्तेमाल करें, इस पर कोई documentation या example नहीं है
आजकल IT में आने वाले ज़्यादातर लोग सिर्फ पैसे के पीछे हैं, और जुनूनी लोग अब बहुत कम बचे हैं—ऐसा देखने को मिलता है
यह बहुत दुखद है, और लगता है कि इसी वजह से कई open source projects मरते जा रहे हैं
योगदान देकर या मदद करके कुछ लौटाने के बजाय बस “Stack Overflow से copy-paste करो और salary लो” वाला रवैया है
इसका मतलब यह नहीं कि सभी ऐसे हैं, लेकिन कई कंपनियों में काम करते हुए करीब से देखने और बातचीत करने पर अनुपात लगभग 19:1 जैसा लगा
संदर्भ के लिए, मैं मानक की तुलना में काम बहुत जल्दी खत्म कर देता हूँ और meetings का इंतज़ार करते हुए काफी समय बर्बाद होता है, इसलिए मैं हर दिन दो कंपनियों के लिए काम करता हूँ
दिलचस्प काम करने के लिए मैंने कई side jobs भी किए, और नए hardware आज़माने या experiment करने के लिए कई बार मुफ्त में भी काम किया
contract में मौजूद invention assignment clauses और बाहरी गतिविधियों से जुड़े clauses योगदान की बाधा बढ़ाते हैं
मैं सहमत हूँ कि Postgres को नए users आकर्षित करने में कोई खास मुश्किल नहीं हो रही
मैं भी कई self-hosting apps में Postgres इस्तेमाल कर रहा हूँ
हालांकि PHP applications में default या इकलौता database होने के कारण MariaDB ही इस्तेमाल करना पड़ता है
संक्षेप में, बात यह लगती है कि PostgreSQL contributors की उम्र बढ़ रही है, और Neon मौजूदा committers के बजाय juniors को hire और train करके developer base को बड़ा कर रहा है
C/C++ का experience नहीं है, लेकिन रुचि रखने वाले programmer के तौर पर, अगर code को विस्तार से समझाने वाली video series हो तो contribution शुरू करने में सचमुच मदद मिलेगी