Community member churn: आखिर सब चले जाते हैं

अभी इस वक़्त दस लोग आपकी community को थामे हुए हैं. आप ठीक-ठीक जानते हो वो कौन हैं. आपसे पहले वो सवालों के जवाब देते हैं, project हिलने लगे तो उसका बचाव करते हैं, और एक सुस्त मंगलवार को भी कमरे को गरम बनाए रखते हैं.

एक साल बाद उनमें से कोई नहीं होगा.

ये आपकी किसी ख़ास community के बारे में भविष्यवाणी नहीं है. ये हर community की default हालत है, उन community की भी जो मैं खुद चलाता हूँ. गलती उन दस लोगों को खोना नहीं है. गलती ये मानकर build करना है कि आप उन्हें कभी खोओगे ही नहीं.

Community member churn असल में है क्या

Community member churn वो दर है जिस रफ़्तार से members हिस्सा लेना बंद कर देते हैं. ज़्यादातर सलाह इसे एक leak मानती है जिसे बंद करना है, कोई ऐसी चीज़ जिसे आप exit surveys और win-back campaigns से ठीक कर लोगे. ये framing एक paid membership के लिए काम करती है, जहाँ churn का मतलब है एक cancel हुआ subscription.

पर जो लोग असल में आपका कमरा चलाते हैं, उनके लिए ये frame गलत है.

चले जाना ही normal है, और इस पर एक number भी है. 2025 में MIS Quarterly में छपे एक field experiment ने नापा कि एक online community में newcomers के साथ क्या होता है, और पाया कि एक newcomer के 12 महीनों के अंदर लौटने की probability 38% है. यानी पाँच में से करीब तीन लोग, जो एक बार पोस्ट करते हैं, दोबारा कभी पोस्ट नहीं करते. फिर researchers ने warmth वाले एक intervention से इसे ठीक करने की कोशिश की और वो number 3.7 percentage points हिला, ज़्यादा अच्छा बनने से इतना ही मिलता है.

आपके core members subscribers नहीं हैं. वो आज़ाद लोग हैं जो बिना पैसे के काम कर रहे हैं क्योंकि उन्हें आप पसंद हो, project पसंद हो, या बस vibes पसंद हों. ये उस भीड़ से बिल्कुल अलग चीज़ है जिसे कोई incentive खींच लाता है, और जो rewards रुकने वाले हफ़्ते ही खाली हो जाती है. हर एक का आपकी community में एक runtime है: ठहरने की एक लंबाई, जिसे आपके बनाए events, roles और लौटने की वजहें बढ़ा तो सकती हैं, पर कभी infinite नहीं कर सकतीं. Churn leak नहीं है. Churn घड़ी है.

Dependency एक ही तरफ़ चलती है

जब कुछ members active हो जाते हैं और active बने रहते हैं, तो उन्हें operation में शामिल कर लेना natural लगता है. वो उन सवालों के जवाब देने लगते हैं जो आप देते. Message आपकी नज़र में आने से पहले ही वो chat को शांत कर देते हैं. चुपचाप, वो आपकी team का हिस्सा बन जाते हैं.

और जिस पल वो बनते हैं, आप उन पर depend करने लगते हो.

अब वो हिस्सा जो भुला दिया जाता है. ये dependency एक ही तरफ़ चलती है. आप उन पर टिके हो, activity के लिए, जवाबों के लिए, social proof के लिए, इस एहसास के लिए कि कमरा ज़िंदा है. वो आप पर किसी चीज़ के लिए नहीं टिके. आप उन्हें pay नहीं कर रहे. वो कल निकल सकते हैं और उनका कुछ नहीं जाएगा.

इस बिना-पैसे वाली dependency का पैमाना नापा जा चुका है. 2022 में Northwestern के researchers और उनके साथियों ने अंदाज़ा लगाया कि Reddit के करीब 21,500 volunteer moderators रोज़ 466 घंटे काम कर रहे थे, जिसकी कीमत साल में कम से कम 3.4 मिलियन डॉलर बैठती है, यानी Reddit के 2019 revenue का लगभग 2.8%. उसी team को moderation logs में इससे भी असहज करने वाली एक बात मिली: जो काम दिखता है वो कुल का median सिर्फ़ 23% है. आपके volunteers आपके लिए जो करते हैं उसका तीन-चौथाई आप कभी देखते ही नहीं, यानी आपको ये भी अंदाज़ा नहीं कि आप replace क्या कर रहे होगे.

ज़्यादातर community managers मन ही मन सोचते हैं कि audience को project से बस कुछ चाहिए. Rewards, पैसा, वक़्त. ये सच है, और ये आधा सच है. आपको भी वो उतनी ही बुरी तरह चाहिए, उन messages के लिए जो server को busy दिखाते हैं और उन जवाबों के लिए जो आपको अठारह घंटे वाले उन दिनों से बचाते हैं जो ये नौकरी वरना वसूलती है. ये दो आज़ाद पक्षों के बीच का आपसी इंतज़ाम है, और कोई भी पक्ष दूसरे को हमेशा टिके रहने का वादा नहीं देता.

अगर ये बात आप कभी अंदर तक नहीं उतारते, तो हर विदाई धोखे जैसी लगती है. वो धोखा नहीं है. किसी ने कुछ sign नहीं किया था. आपने उन लोगों पर dependency बना ली जो कभी इस बात पर राज़ी ही नहीं हुए थे.

मेरी अपनी एक community में churn कैसा दिखा

मैं Inner Circle नाम का एक creator program चलाता हूँ, Syndicate brand के नीचे चार हफ़्ते का एक cohort. दो seasons पूरे हो चुके हैं, और उसके पीछे की platform हर submission log करती है, तो मैं आपको feeling के बजाय असली numbers के साथ बता सकता हूँ कि churn दिखता कैसा है.

Season one में 657 applications आईं और 79 लोग accept हुए. उन 79 में से 57 ने कभी कुछ submit किया. 27 लोगों ने आठ या उससे ज़्यादा core tasks पूरे किए. यानी जो कमरा 79 members का दिखता था, चलाने के हिसाब से वो 27 लोग था.

अब देखो कि उन 27 लोगों ने हफ़्तेवार numbers के साथ क्या किया. हर हफ़्ते active members रहे 56, फिर 47, फिर 40, फिर 34. चार हफ़्तों में लोगों में 39% की गिरावट, जो किसी dashboard पर एक बिखरती हुई community जैसी दिखती है.

Output उल्टी दिशा में गया. हर हफ़्ते submissions रहे 893, 799, 856, और फिर आख़िरी हफ़्ते 1,033, पूरे season में सबसे ज़्यादा, 95.1% approval rate के साथ. कमरे ने अपने 22 active लोग खोए और अपना सबसे अच्छा हफ़्ता दिया.

जो लोग गए वो ज़्यादातर वही थे जिन्होंने कभी सच में शुरू ही नहीं किया था. Season के आख़िर में मैंने 13 members से role हटाया जिनकी zero submissions थीं और जो दो हफ़्ते या उससे ज़्यादा से चुप थे. Season के बीच में भार उठाने वाला कोई नहीं गया. पूँछ झड़ गई और बीच टिका रहा, और इसका सेहतमंद version ऐसा ही दिखता है.

आपका core उससे छोटा है जितना leaderboard दिखाता है

Community के काम में सबसे ज़्यादा quote होने वाला number है Jakob Nielsen का 90-9-1 rule, जो Nielsen Norman Group ने 2006 में छापा: ज़्यादातर online communities में 90% लोग सिर्फ़ देखते हैं, 9% कभी-कभार contribute करते हैं, और 1% लगभग सब कुछ बनाते हैं. Blogs के लिए उन्होंने इसे 95-5-0.1 के करीब रखा.

जो मानकर चलता है कि उसका अपना कमरा अपवाद है, उसके लिए ये rule बुरी तरह टूटता है. Reddit moderation logs वाली उसी 2022 की study ने नापा कि काम कितना असमान बँटा है. 36 subreddits में moderator actions पर Gini coefficient 0.47 से 0.90 तक रहा, median 0.74, और एक community में अकेले सबसे active moderator ने पूरे moderation का 72% काम किया. वो subreddit बिना किसी moderation के रह जाने से बस एक इंसान दूर था.

मैंने अपनी distribution इसके सामने रखकर देखी, और हमारी काफ़ी ज़्यादा flat है. Season two के final leaderboard में 75 ranked members थे और उनके बीच 11,039 points. सबसे ऊपर वाले member के हिस्से में कुल points का 2.1% आया. Top 10 के हिस्से में 20.9%. ऊपर वाले आधे लोगों के हिस्से में 74.2%. Median score 182 रहा, जबकि top score 236 था.

ये flatness design की गई है, किस्मत नहीं है. Program में contribution हर task पर capped है, तो कोई अकेला इंसान पूरा कमरा लेकर भाग नहीं सकता, और structured काम का एक floor है जिसे कोई भी पूरा कर सकता है. Structure participation की असमानता को दबा देता है.

इसका मतलब ये भी है कि leaderboard असली risk छुपा लेता है. एक flat leaderboard आपको ये नहीं बताता कि कौन से चार लोग जाते वक़्त कमरे का माहौल अपने साथ ले जाएँगे, क्योंकि माहौल tasks submit नहीं करता. Season two में जिन members की कमी मुझे सबसे ज़्यादा खलती, वो top scorers नहीं थे. वो वो लोग थे जो आधी रात को chat में newcomers को जवाब दे रहे थे, और मेरा कोई dashboard इसे गिनता नहीं.

Members क्यों जाते हैं, और वजह शायद ही कभी आप होते हो

कभी-कभी ऐसी कोई वजह होती ही नहीं जो आपको कभी मिले. वो busy हो गए. वो किसी दूसरी chain पर चले गए. उन्हें कोई कमरा मिल गया जो उन्हें ज़्यादा पसंद है.

Offline volunteering की दुनिया हमसे कहीं पहले से इसे track कर रही है. Corporation for National and Community Service के 2007 के एक research brief में पाया गया कि साल दर साल volunteer retention 69% है, यानी करीब 31% लौटकर नहीं आए, और organizations ने अपने खोए हुए लोगों में से सिर्फ़ 83.2% की भरपाई की. उसने ख़ास तौर पर Baby Boomers को देखा, हालाँकि बाकी उम्र वालों का turnover भी लगभग वैसा ही, 29% निकला.

काम की बात उसी report में मौजूद dose response है. जो लोग साल में 12 या उससे ज़्यादा हफ़्ते volunteer करते थे उनमें retention 79% था, जबकि दो हफ़्ते या उससे कम देने वालों में 53%. Churn हल्की भागीदारी में ही रहता है. वो पूँछ है, core नहीं, और यही मेरे अपने हफ़्तेवार numbers भी कहते हैं.

कभी-कभी ये एक chain reaction होता है जो न आपने शुरू किया और न आप रोक सकते हो. दो members आपस में भिड़ जाते हैं. एक chat से break ले लेता है. तीसरा, जिसे वो इंसान पसंद था, ठंडा पड़ जाता है और खिसक जाता है. एक ऐसे झगड़े में तीन लोग चले गए जिससे आपका कोई लेना-देना ही नहीं था.

और कभी-कभी वो तेज़ जलते हैं और गायब हो जाते हैं. Season two में सबसे तेज़ चार नए members दो हफ़्तों के अंदर चुप हो गए. एक ने गायब होने से पहले 21 submissions दर्ज की थीं, दूसरे ने 12. जहाँ तक मैं देख सका, वो नाराज़ नहीं थे. उन्होंने पहले हफ़्ते में अपना सब कुछ लगा दिया और दूसरे हफ़्ते के लिए कुछ बचा ही नहीं.

मेरे अपने data में इसका सबसे साफ़ version वो है जो दो seasons के बीच हुआ. Season one के 19 veterans ने एक महीने बाद season two में सचमुच कुछ भी नहीं बनाया. वही Discord, वही लोग, वही program, zero activity. Track किए गए 123 accounts में से 25 ने मेरे किसी की review तक पहुँचने से पहले ही खुद role छोड़ दिया था.

Community member churn की ईमानदार शक्ल यही है. कोई dramatic exit नहीं. लोग चुपचाप रुक जाते हैं.

कोई कैसे जाता है, यही तय करता है कि वो आगे क्या करेगा

असली skill यही है, और ये tactical से ज़्यादा emotional है.

जो community manager ये भूल गया कि ये आज़ाद लोग हैं, वो किसी regular के चुप हो जाने पर कड़वा हो जाता है. उसे personally ले लेता है. उन्हें guilt-trip करता है, उनसे ठंडा हो जाता है, exit को भद्दा बना देता है. यही सबसे बुरा कदम है, क्योंकि कोई कैसे जाता है यही तय करता है कि वो आगे क्या करेगा.

किसी के जाने को शराफ़त से संभालो, और आगे बढ़ चुका एक core member project का दोस्त बना रहता है. बड़े मौकों पर वो लौटकर आता है. वो लोगों को refer करता है. वो बाहर से आपका बचाव करता है, और जिसका अब कोई stake ही नहीं बचा उसका बिन माँगा बचाव उस सब से ज़्यादा कीमती है जो वो अंदर रहते हुए पोस्ट करता.

मैंने ऐसी research ढूँढी जो साबित करे कि शराफ़त भरा exit आगे चलकर advocacy बनाता है, और communities के लिए ऐसी research है ही नहीं. जो मौजूद है वो नौकरी वाला version है. Journal of Management में 2021 की एक study ने 30,714 लोगों को track किया और पाया कि जो employees अपने पुराने employer के पास लौटे, उनमें जो पहली बार किसी negative वजह से गए थे उनमें से 64% दूसरी बार भी negative वजह से ही गए. Rehires का turnover भी 36.6% रहा, जबकि अंदरूनी moves का 20.9%. कोई पहली बार क्यों गया था, ये सालों बाद तक उसका behavior बताता रहता है, और community managers जिस बात को पहले से दिल से जानते हैं, उसके लिए यही सबसे करीबी ठोस सबूत है जो मैं दिखा सकता हूँ.

इसीलिए, जब मैंने season two के चुप members का audit किया, तो अपने लिए जो recommendation लिखी वो थी एक DM पूछने के लिए कि हुआ क्या, role हटाना नहीं. और जो season one के veterans inactive बैठे थे, उनके लिए फ़ैसला था current-cohort role हटा देना और veteran role वहीं रहने देना. उन्होंने जो status कमाया वो उनके पास रहता है, roles ईमानदार रहते हैं, और किसी को ये नहीं कहा जाता कि ज़िंदगी होने की वजह से उसे demote कर दिया गया.

Exit में ज़हर घोल दो तो ये सब चला जाता है, और ऊपर से आप छोटे भी दिखते हो.

नए रिश्ते बनाते रहो, हमेशा

चूँकि सब चले जाते हैं, ये काम कभी बंद नहीं होता. आप नए members के साथ नए रिश्ते बनाते रहते हो जबकि आपका मौजूदा core अभी active है, तब भी जब कोई नया रिश्ता किसी पुराने member के साथ आपके रिश्ते को थोड़ा ठंडा कर दे. ये सौदा बेवफ़ाई जैसा लगता है. वो है नहीं. कमरे के center of gravity को घुमाते रहना ही तो काम है.

मकसद है एक ऐसी community जहाँ कोई दस लोग भार उठाने वाले न हों. अगर तीन ख़ास members के जाने से पूरी चीज़ ढह जाती है, तो आपके पास community नहीं है. आपके पास एक group chat है जिसमें single point of failure है.

इस पर सबसे साफ़ data open source के पास है, क्योंकि वहाँ हर commit public है. दिसंबर 2024 की एक study ने 36,000 से ज़्यादा open source projects देखे और पाया कि 89% ने कम से कम एक बार अपनी पूरी core team खोई, और उनमें से 70% नुकसान पहले तीन सालों में हुए. लेखकों का कहना है कि ये जानलेवा नहीं बल्कि normal है, और मेरी बात भी यही है. जो number आपको डराना चाहिए वो है recovery rate: छोड़ दिए गए projects में से सिर्फ़ 27% को कभी कोई नया core developer मिला. Core खोकर बचा जा सकता है, उसकी भरपाई न कर पाने से आमतौर पर नहीं.

Truck factor पर पुराने काम में, यानी किसी project को डुबोने के लिए कितने लोगों का गायब होना ज़रूरी है, ये मिला कि 133 popular GitHub applications में से 34% का truck factor एक था, और बाकी 30% का दो. मशहूर open source software का दो-तिहाई हिस्सा दो लोगों के जाने से ठप हो सकता है.

आपका Discord कोई software repository नहीं है, पर failure mode बिल्कुल वही है. एक छोटा group उसे ढो रहा है, उस group को पैसा नहीं मिलता, और इस पूरे इंतज़ाम में कहीं भी replacement की कोई guarantee नहीं है.

Practically इसका मतलब है कुछ बे-चमक आदतें. Recruit तब करो जब कमरा सेहतमंद लग रहा हो, क्योंकि सेहतमंद तब है जब आप अभी भी नए रिश्ते जोड़ रहे हो, तब नहीं जब आप रुक जाओ. ऐसा कोई flow कभी मत बनाओ जिसे सिर्फ़ एक इंसान चला सके, और जहाँ flow दोहराव वाला है, वहाँ उसे किसी volunteer के बजाय किसी tool को सौंप दो. आपके power users जो जानते हैं उसे लिखकर रखो, ताकि उनका knowledge उनकी दिलचस्पी से ज़्यादा जिए. और alumni के लिए कम मेहनत में जुड़े रहने का एक रास्ता रखो, जो हमारे यहाँ एक veteran role है जिसे रखने में उनका कुछ नहीं लगता.

जो कमरा अपने core के बिना बच जाता है, सिर्फ़ वही कमरा आपके बिना भी बचेगा.

जो चुपचाप risk पैदा करता है	जो उसे घटाता है
Power users को permanent staff मानना	उन्हें एक runtime वाले volunteers मानना
ऐसे flows जिन्हें चलाना सिर्फ़ एक इंसान जानता है	लिखी हुई procedure, या दोहराव वाला आधा हिस्सा करता एक bot
Recruit सिर्फ़ तब करना जब कमरा सुनसान लगे	सबसे ज़्यादा recruit तब करना जब वो सेहतमंद लगे
किसी चुप member को personally ले लेना	एक message, ये पूछता हुआ कि हुआ क्या
कोई खिसक जाए तो उसका status हटा देना	एक alumni role जिसे रखने में कुछ नहीं लगता
पूरे कमरे को अपने सबसे शोर वाले members के हिसाब से मोड़ना	ये मान लेना कि कोई न कोई हमेशा असंतुष्ट रहेगा

आप सबको खुश नहीं कर सकते

कोई न कोई हमेशा असंतुष्ट रहेगा. ज़्यादातर बार उसका असंतुष्ट होना जायज़ भी होता है, और फिर भी ये कोई ऐसी problem नहीं जिसे आप हल कर सको, क्योंकि सबको खुश करना कभी option था ही नहीं.

100% के पीछे भागकर ही आप burn out होते हो. उससे भी बुरा, इसी तरह आप अपने सबसे शोर वाले, सबसे ज़्यादा माँगने वाले members के बंधक बन जाते हो, और पूरे कमरे को उन चंद लोगों के हिसाब से मोड़ देते हो जिन्हें खोने से आप सबसे ज़्यादा डरते हो. जिन्हें खोने से आप सबसे ज़्यादा डरते हो, ठीक उन्हीं पर आपको सबसे कम depend होना चाहिए.

ये वही discipline है जो ऊपर की हर बात में है. जानो कि वो आज़ाद हैं, ऐसा build करो कि उनके जाने से कुछ टूटे नहीं, और जब वो जाएँ तो उन्हें अच्छे से जाने दो.

मैं यही काम करके कमाता हूँ, पंद्रह से ज़्यादा crypto projects और अपने दो cohorts में. अगर आप ऐसे कमरे को देख रहे हो जो चार लोगों पर चलता है और एक second opinion चाहते हो कि आप कितने exposed हो, तो एक call book करो.

स्रोत

• Inner Circle season one and season two operating data, Syndicate cohort platform (production database), May to July 2026. Figures cited: applications, accepted members, weekly actives, weekly submissions, approval rates, and the final leaderboard distribution, which I computed for this article.
• Jakob Nielsen, "The 90-9-1 Rule for Participation Inequality in Social Media and Online Communities," Nielsen Norman Group, 8 October 2006, retrieved 2026-08-09. https://www.nngroup.com/articles/participation-inequality/
• Li, H., Hecht, B., et al., "All That's Happening behind the Scenes: Putting the Spotlight on Volunteer Moderator Labor in Reddit," ICWSM 2022 (moderator-log Gini distribution and invisible labor), retrieved 2026-08-09. https://arxiv.org/abs/2205.14529
• Li, H. et al., "Measuring the Monetary Value of Online Volunteer Work," ICWSM 2022, retrieved 2026-08-09. https://arxiv.org/abs/2205.14528
• Northwestern University, "Unpaid social media moderators perform labor worth at least $3.4 million a year on Reddit alone," May 2022, retrieved 2026-08-09. https://news.northwestern.edu/stories/2022/05/unpaid-social-media-moderators
• Pethig, F. et al., field experiment on newcomer retention in an online community, MIS Quarterly 49(2), 2025, retrieved 2026-08-09. https://www.florianpethig.com/preprints/nudge.pdf
• Foster-Bey, J., Grimm, R., Dietz, N., "Keeping Baby Boomers Volunteering: A Research Brief on Volunteer Retention and Turnover," Corporation for National and Community Service, March 2007, retrieved 2026-08-09. https://www.govinfo.gov/content/pkg/GOVPUB-Y3_N21_29-PURL-LPS113705/pdf/GOVPUB-Y3_N21_29-PURL-LPS113705.pdf
• "Myth: The loss of core developers is a critical issue for OSS communities," arXiv preprint, December 2024 (36,000+ projects), retrieved 2026-08-09. https://arxiv.org/abs/2412.00313
• Avelino, G., Passos, L., Hora, A., Valente, M.T., "What is the Truck Factor of popular GitHub applications? A first assessment," PeerJ Preprints, 2015, retrieved 2026-08-09. https://peerj.com/preprints/1233.pdf
• Arnold, J.D., Van Iddekinge, C.H., Campion, M.C., Bauer, T.N., Campion, M.A., "Welcome Back? Job Performance and Turnover of Boomerang Employees Compared to Internal and External Hires," Journal of Management 47(8), November 2021, pp. 2198-2225 (n = 30,714), retrieved 2026-08-09. DOI https://doi.org/10.1177/0149206320936335 (open copy: https://apps.it.purdue.edu/sites/Home/DirectoryApi/Files/baea7601-cbe7-4b10-b3ad-cd93e060e489/Download)