Cal.com ने AI सुरक्षा खतरों के कारण open source से closed source में बदलाव किया

 (cal.com)
3 पॉइंट द्वारा GN⁺ 2026-04-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 5 साल तक open source के रूप में चलने के बाद Cal.com ने AI-आधारित सुरक्षा खतरों में बढ़ोतरी के कारण closed source में बदलने का फैसला किया
  • ऐसे दौर में जब AI codebase का अपने-आप विश्लेषण करके कमजोरियां ढूंढ सकता है, public code सीधे हमलावरों के लिए सुराग बन रहा है
  • कंपनी ने ग्राहक डेटा की सुरक्षा के लिए open source बनाए रखने और सुरक्षा जोखिम के बीच बाद वाले को प्राथमिकता दी
  • open source भावना को जारी रखने के लिए Cal.diy प्रोजेक्ट को MIT लाइसेंस के तहत जारी किया, जो community के लिए self-hosting version देता है
  • मौजूदा सुरक्षा ढांचे को पीछे छोड़ देने वाली रफ्तार से AI के आगे बढ़ने के बीच, Cal.com ने सुरक्षा स्थिर होने पर फिर से open source में लौटने की इच्छा जताई

Cal.com का open source बंद करने का फैसला और AI सुरक्षा खतरे

  • Cal.com 5 साल से open source के रूप में चल रहा था, लेकिन AI-आधारित सुरक्षा खतरों में तेज़ बढ़ोतरी के कारण अब closed source में जाने का फैसला किया है
    • ग्राहक डेटा की सुरक्षा को सर्वोच्च प्राथमिकता देते हुए कंपनी ने माना कि open source बनाए रखना अब सुरक्षित नहीं है
    • कंपनी ने कहा कि “यह आसान फैसला नहीं था”
  • पहले application vulnerabilities का दुरुपयोग करने के लिए skilled hackers का समय और मेहनत चाहिए होती थी, लेकिन अब AI अपने-आप codebase scan करके कमजोरियां ढूंढने के दौर में हम आ चुके हैं
    • open source code को हमलावरों के लिए “तिजोरी का नक्शा देने जैसा” बताया गया
    • AI security startups इस क्षमता को commercialize कर रहे हैं, और अलग-अलग कमजोरियां पहचानने के कारण एक भरोसेमंद single security standard तय करना मुश्किल हो गया है
  • Cal.com ने कहा कि उसके सामने दो विकल्प थे
    • open source बनाए रखते हुए ग्राहक डेटा के जोखिम को स्वीकार करना, या
    • closed source में बदलकर जोखिम कम करना
    • यह परफेक्ट समाधान नहीं है, लेकिन यूज़र सुरक्षा के लिए अनिवार्य फैसला माना गया
  • open source भावना को बनाए रखने के लिए Cal.diy नाम का एक अलग प्रोजेक्ट MIT लाइसेंस के तहत जारी किया गया
    • Cal.diy डेवलपर्स और hobby users के लिए खुला version है, यानी self-hosting योग्य community-केंद्रित version
    • मुख्य service codebase में authentication और data processing systems जैसी core संरचनाओं में बड़े बदलाव किए गए हैं, इसलिए यह तकनीकी रूप से Cal.diy से अलग है
  • AI सुरक्षा माहौल को बहुत तेज़ी से बदल रहा है, और AI ने BSD kernel की 27 साल पुरानी vulnerability को कुछ घंटों में ढूंढकर exploit बना दिया — इसका भी उल्लेख किया गया
    • यह रफ्तार और सटीकता मौजूदा security response systems पर भारी पड़ रही है
    • Cal.com ने कहा कि वह ग्राहकों, application और sensitive data की सुरक्षा के लिए हर संभव कदम उठा रहा है, और सुरक्षा माहौल स्थिर होने पर फिर से open source में लौटना चाहता है

आगे की दिशा और संदेश

  • फिलहाल security risk mitigation और user protection सबसे बड़ी प्राथमिकता हैं
  • open source community के साथ संबंध Cal.diy के जरिए बनाए रखे जाएंगे
  • लंबे समय में सुरक्षा माहौल के विकास के अनुसार open source में वापसी की संभावना खुली रखी गई है
  • यह फैसला दिखाता है कि AI युग की security reality software distribution models को सीधे प्रभावित कर रही है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-17
Hacker News की राय

  • Drew Breunig ने कल पोस्ट किए गए लेख में ठीक उलटा निष्कर्ष निकाला
    अब security vulnerabilities tokens का इस्तेमाल करके खोजे जा सकने वाले resources बन गए हैं, इसलिए उल्टा open source और भी ज़्यादा valuable है
    open source में कई projects audit cost share कर सकते हैं, लेकिन closed source में हर vulnerability अकेले खोजनी पड़ती है

    • उस लेख को यहाँ फिर से पोस्ट किया गया था। शीर्षक है Cybersecurity looks like proof of work now
    • असली वजह शायद यह लगती है कि AI को products का copyright-wash करने से रोका जाए। security बस बहाने की तरह लगती है
    • यह निष्कर्ष ज़्यादा convincing लगता है। Mythos आए हुए अभी कुछ ही हफ्ते हुए हैं, और इतने जल्दी principles बदलना अजीब है। शायद business reason था, और अब बस जनता को बेचने लायक justification ढूँढा गया है
    • आर्थिक रूप से भी यह तर्कसंगत निष्कर्ष है। आखिरकार या तो token cost झेलने लायक value पैदा करनी होगी, या vulnerability discovery का आर्थिक फायदा कम करना होगा
      यह distribution scope घटाकर या system privileges कम करके किया जा सकता है।
      आगे चलकर यह शायद 'open spec + model-based code generation' के रूप में विकसित होगा। security और governance model layer पर होने की संभावना है
    • “सिस्टम को मजबूत करने के लिए attackers से ज़्यादा tokens खर्च करने होंगे” यह बात अजीब लगती है। अगर software stable है, तो attack surface घटता है, और Mythos नई vulnerabilities बनाता नहीं है। defenders को token के मामले में advantage होना चाहिए

  • मैं Thunderbird project lead हूँ। हमारा scheduling tool Thunderbird Appointment हमेशा open source रहेगा
    GitHub repository पर साथ मिलकर बनाने का निमंत्रण दिया गया। Cal.com का विकल्प बन सके, इसमें मदद करने की बात है

    • README या login से पहले वाले screen में screenshots जोड़ना अच्छा होगा। tool अच्छा लग रहा है, लेकिन hosted version की pricing जानना चाहता हूँ
    • लेकिन पुराने Linux laptop पर Thunderbird बहुत भारी है। low-spec users को भी ध्यान में रखा जाए। इंटरनेट को संभालने लायक स्तर पर बनाए रखने की गुज़ारिश है
    • साइट पर जाकर email डाला तो waitlist पर भेज दिया, और आखिर में email block कर दिया। user experience अच्छा नहीं था
    • “हमारे साथ मिलकर बनाइए” पर मज़ाक में पूछा गया, “तो क्या उसके लिए appointment चाहिए?”
    • इसे एक अच्छे alternative के रूप में देखने वाली positive प्रतिक्रिया भी थी

  • अगर LLM code vulnerabilities इतनी अच्छी तरह ढूँढ सकता है, तो release से पहले internal LLM pentest चला लेना चाहिए, है न?
    ऐसा लगता है कि Linus's Law(लिंक) अब जाकर सच हुआ है

    • लेकिन release के बाद attackers के पास अनंत समय होगा और लगातार smarter होते जा रहे LLM के साथ code का analysis कर पाएँगे।
      बचाव के लिए attackers जो कुछ कर सकते हैं, वह सब हर release से पहले करना पड़ेगा
    • LLM के आगे बढ़ने के साथ FOSS maintenance की समय और manpower cost तेज़ी से बढ़ रही है।
      AI से बने low-quality issues या PR बढ़ रहे हैं, इसलिए open source maintain करने की incentives घट रही हैं।
      जब commercial products FOSS core पर आधारित होते हैं, तब ऐसे बदलाव और बढ़ सकते हैं
    • closed source में LLM को internally इस्तेमाल करके security मजबूत की जा सकती है।
      लेकिन बाहर attack opportunities खुली न रहें, इस कारण बंद करने का तर्क भी समझ में आता है
    • जहाँ commits बार-बार होते हैं, वहाँ हर बार पूरे codebase को LLM से scan करना पड़ता है, इसलिए cost बहुत बढ़ जाती है।
      GitHub जैसी जगहों पर भी static analysis की cost पहले से ही ऊँची है
    • आखिर में राय यह है कि simple code लिखना बेहतर है, और compiler level पर भी LLM security testing करनी चाहिए

  • यह फैसला security से ज़्यादा business decision लगता है।
    AI की वजह से self-hosting आसान हो गई है, इसलिए open source projects की paid hosting revenue घट रही है

    • लोग LLM का इस्तेमाल करके “pro features” खुद implement कर लेते हैं या extension points खोज लेते हैं। security सिर्फ ऊपरी दिखावा है
    • AI को दोष देना बहाना है। AI पहले ही code से सीख चुका है। genetic algorithms + fuzzing मिल जाएँ, तो यह इंसानों से कहीं तेज़ सीख सकता है
    • आजकल हर चीज़ का दोष AI पर डाल दिया जाता है। layoffs हों, product shutdown हो, या source code बंद करना हो — सब AI की वजह से बताया जाता है
    • Google Workspace के appointment tool की तरह यह product पहले ही commoditized हो चुका है
    • आखिरकार “sellout” जैसी आलोचना भी सामने आई

  • एक संभावित ग्राहक के रूप में Cal.com के इस फैसले से निराशा हुई।
    open source को transparent SSDLC की वजह से trust मिल सकता है, लेकिन closed source में vendor पर भरोसा करना ही पड़ता है
    Drew Breunig की दलील से सहमत नहीं हूँ। bugs की संख्या सीमित होती है, और अगर पर्याप्त रूप से powerful model नियमित रूप से code scan करे, तो बची हुई vulnerabilities की संभावना तेज़ी से घटती है

  • “अगर AI open source code scan कर सकता है?” → तो फिर बस bugs ठीक कर दो।
    यह तर्क बिल्कुल भी convincing नहीं है

  • “AI code तक पहुँच सकता है इसलिए हम बंद करेंगे” यह सिर्फ बहाना है

    • असली वजह AI या security नहीं, बल्कि यह है कि clone projects बहुत बढ़ गए हैं और revenue घट गया है

  • इस तरह का फैसला आखिरकार Security through obscurity जैसा लगता है।
    सवाल है कि यह कब से सही model बन गया

    • obscurity तभी काम की होती है जब वह मुख्य defense नहीं बल्कि secondary deterrent हो
    • attack surface घटाना obscurity नहीं, बल्कि attack vector minimization strategy है
    • फिर भी कुछ लोगों की राय थी कि यह “obscurity के बिना security” से बेहतर है
    • एक co-founder ने कहा कि “पड़ोस का 16 साल का बच्चा भी 15 मिनट और 100 डॉलर में hack कर सकता है”
    • लगता है लोग भूल गए हैं कि “security को obscurity पर आधारित नहीं होना चाहिए” यह विचार क्यों आया था।
      पुरानी पीढ़ियाँ बेवकूफ नहीं थीं, बल्कि इसलिए कि यह ऊपर से अच्छा दिखने वाला लेकिन असफल approach था

  • Cal.com का “हम open source पर विश्वास करते थे” कहना खोखला लगता है।
    अगर बात सच होती, तो ऐसी बेमानी सफाई नहीं दी जाती

  • यह AI से पहले भी दिया जा सकने वाला बहाना था।
    लगता है कि core product पर्याप्त रूप से अलग नहीं बन पाया, इसलिए revenue बचाने की कोशिश हो रही है।
    अंत में यह सिर्फ revenue protection move है