एबी केर्न्स, एक्टिवस्टेट के सीईओ – साक्षात्कार श्रृंखला

एबी केर्न्स एक्टिवस्टेट के सीईओ हैं और एक प्रौद्योगिकी कार्यकारी हैं जिनके पास 25 से अधिक वर्षों का अनुभव है जो उद्यम सॉफ्टवेयर संगठनों का निर्माण और विस्तार करते हैं। उन्होंने पहले पपेट के सीटीओ के रूप में कार्य किया, जहां उन्होंने एक रणनीतिक परिवर्तन का नेतृत्व किया जो कंपनी के परफोर्स सॉफ्टवेयर द्वारा अधिग्रहण में समाप्त हुआ। अपने करियर की शुरुआत में, वह क्लाउड फाउंड्री फाउंडेशन के सीईओ थे, जो उद्योग के सबसे बड़े ओपन सोर्स क्लाउड प्लेटफ़ॉर्म पारिस्थितिकी तंत्र के विकास का मार्गदर्शन करते थे। एबी वर्तमान में अक्का (पूर्व में लाइटबेंड) के बोर्ड में कार्य करती हैं। उन्हें यह जानने के लिए जाना जाता है कि कैसे कंपनियां बादल, ओपन सोर्स और एआई में प्रमुख बदलावों को स्पष्ट उत्पाद रणनीति और उद्यम विकास में अनुवाद करती हैं।

एक्टिवस्टेट एक कनाडाई सॉफ्टवेयर कंपनी है जो 1997 में स्थापित की गई थी जो उद्यम उपकरण और मंच प्रदान करती है जो ओपन सोर्स सॉफ्टवेयर का निर्माण, प्रबंधन और सुरक्षा करते हैं। इसका मुख्य उत्पाद, एक्टिवस्टेट प्लेटफ़ॉर्म, विकास, डेवओप्स और सुरक्षा टीमों को निर्भरता प्रबंधन, कमजोरियों का पता लगाने और उन्हें दूर करने और विभिन्न प्रोग्रामिंग भाषाओं जैसे पायथन, पर्ल और टीसीएल में सुरक्षित, पुनरुत्पादक विकास वातावरण बनाने में मदद करता है।

आपने अपने करियर को ओपन सोर्स, क्लाउड-नेटिव प्लेटफ़ॉर्म और उद्यम परिवर्तन के बीच बिताया है, क्लाउड फाउंड्री फाउंडेशन का नेतृत्व करने से लेकर पपेट में सीटीओ के रूप में कार्य करने तक। एक्टिवस्टेट में सीईओ की भूमिका संभालने के लिए आपको क्या आकर्षित किया, और इस अगले विकास चरण में कंपनी के लिए आपकी दृष्टि क्या है?

मेरे करियर का एक सामान्य धागा रहा है जो समुदाय और बुनियादी ढांचे के बीच के बिंदु पर काम करना है, जब उद्योग ऐसे निर्णय ले रहा होता है जो वर्षों तक जुड़े रहते हैं। क्लाउड फाउंड्री क्लाउड-नेटिव के लिए वह क्षण था। पपेट कॉन्फ़िगरेशन प्रबंधन और डेवसेकओप्स के शुरुआती चरणों के लिए वह क्षण था। एक्टिवस्टेट ओपन सोर्स शासन के लिए वह क्षण है।

मुझे यहाँ एक समस्या आकर्षित करती है जिसे मैंने लंबे समय से देखा है। प्रत्येक उद्यम जिसे मैंने मुलाकात की है, वह ओपन सोर्स पर चलता है। अधिकांश उन्हें विश्वास के साथ नहीं बता सकते कि वे कौन सा ओपन सोर्स चला रहे हैं, क्या यह पैच किया गया है, या इसका उपयोग करने के निर्णय के लिए कौन जिम्मेदार है। ओपन सोर्स कितना मूलभूत हो गया है और अधिकांश संगठनों द्वारा इसके शासन के लिए कितनी कम सख्ती लागू की जाती है, इसके बीच का अंतर जहां उद्योग का जोखिम जमा हो रहा है। एक्टिवस्टेट ने बीस वर्षों से अधिक समय से इस अंतर को बंद करने के लिए बुनियादी ढांचे का निर्माण किया है। मेरा काम यह सुनिश्चित करना है कि बाजार समझे कि इसे बंद करना क्यों जरूरी है।

इस अगले चरण के लिए दृष्टि स्पष्ट है: एक्टिवस्टेट उद्यम ओपन सोर्स से कहाँ आता है, इस प्रश्न का डिफ़ॉल्ट उत्तर बन जाता है। एक स्कैनर नहीं। एक रिपोर्ट नहीं। एक विश्वसनीय, सत्यापित, निरंतर उपचारित स्रोत जिसे संगठन नियामकों, बोर्डों या घटना प्रतिक्रियाकर्ताओं से पूछताछ के समय इंगित कर सकते हैं कि उन्होंने अपने सॉफ्टवेयर आपूर्ति श्रृंखला का शासन कैसे किया।

एक्टिवस्टेट सॉफ्टवेयर आपूर्ति श्रृंखला को सुरक्षित करने में एक महत्वपूर्ण परत के रूप में खुद को स्थापित कर रहा है, जब एआई कोड जेनरेशन को तेज कर रहा है। ओपन सोर्स सॉफ्टवेयर के जोखिम प्रोफाइल को एआई कैसे मौलिक रूप से बदलता है?

एआई-सहायता प्राप्त विकास पूरे ओपन सोर्स शासन टूलचेन पर बनाए गए एक मूलभूत धारणा को तोड़ता है: एक डेवलपर ने जानबूझकर एक निर्भरता शामिल करने का निर्णय लिया।

प्रत्येक एसबीओएम आदेश, प्रत्येक एससीए टूल, प्रत्येक कमजोरियों प्रबंधन कार्य प्रवाह मानता है कि एक मानव लूप में था जिसने पुस्तकालय को खींचने का निर्णय लिया। जब एआई कोड बनाता है, तो निर्भरताएं उत्पादन में आती हैं जिन्हें कोई नहीं चुनता, समीक्षा नहीं करता है, और अक्सर यह भी नहीं जानता कि वे वहां हैं। शासन टूलिंग निर्णयों की तलाश में है। एआई उत्पादन परिवर्तन कर रहा है जो पूरी तरह से निर्णय को दरकिनार करता है।

एक दूसरा परत है। कोडिंग टूल जो एआई अपनाने को बढ़ावा देते हैं, उत्पादकता बेंचमार्क, डेवलपर सर्वेक्षण, गिटहब सितारे, उनमें से कोई भी मूल्यांकन ढांचे में सुरक्षा को पहले क्रम के उपाय के रूप में शामिल नहीं करते हैं। उद्योग ने गति और सहीपन के लिए अनुकूलित किया और बिना यह पूछे कि आउटपुट सुरक्षित था या नहीं, बुनियादी ढांचे को शिप किया। यह एक टूलिंग विफलता नहीं है। यह एक नेतृत्व विफलता है कि अपनाने के निर्णय कैसे किए गए। हम अब पैमाने पर एक आधार पर काम कर रहे हैं जिसे जोखिम के लिए कभी मूल्यांकन नहीं किया गया था।

आपने कहा है कि अनियंत्रित ओपन सोर्स एक प्रमुख उद्यम कमजोरियों में से एक बन रहा है। ओपन सोर्स शासन अब बोर्ड स्तर पर क्यों बढ़ रहा है, और क्या कार्यकारी अभी भी कम अनुमान लगा रहे हैं?

यह बोर्ड तक पहुंच रहा है क्योंकि नियामक वातावरण में बदलाव हुआ है जो जवाबदेही संरचना को बदल देता है। यूरोपीय संघ के साइबर रेजिलिएंस एक्ट, एसईसी प्रकटीकरण आवश्यकताएं, सीआईएसए के सुरक्षित डिज़ाइन मार्गदर्शन: ये ढांचे प्रश्न को “क्या आपके पास एक स्कैनर था?” से “क्या आप साबित कर सकते हैं कि आपका सॉफ्टवेयर मूल रूप से सुरक्षित था?” में बदल रहे हैं। वे बहुत अलग प्रश्न हैं, और अधिकांश संगठन दूसरा उत्तर नहीं दे सकते हैं।

कार्यकारी जो अभी भी कम अनुमान लगा रहे हैं वह यह है कि यह एक संरचनात्मक समस्या है, एक संसाधन समस्या नहीं है। मैं जिन संगठनों को ओपन सोर्स जोखिम का जवाब देने के लिए अधिक स्कैनिंग टूल जोड़ रहे हैं, वे मूलभूत मुद्दे का समाधान नहीं कर रहे हैं। स्कैनिंग समस्याओं का पता लगाती है जब वे पहले से ही आपके वातावरण में प्रवेश कर चुके होते हैं।

जब सब कुछ झंडे दिखा रहा होता है, तो कुछ भी प्राथमिकता नहीं लेता है, और अलर्ट की मात्रा स्वयं एक संचालन असामंजस्य बन जाती है। जो संगठन इसे सफलतापूर्वक नेविगेट करेंगे वे वे नहीं होंगे जो अधिक टूल खरीद रहे हैं। वे वे हैं जो अपने वातावरण में प्रवेश करने वाले ओपन सोर्स के बारे में निर्णय लेने के तरीके को बदल रहे हैं, और जो उन निर्णयों के लिए जिम्मेदार हैं।

ओपन सोर्स को अब अधिकांश उद्यम सॉफ्टवेयर स्टैक में एम्बेड किया गया है, संगठनों को ओपन सोर्स को बुनियादी ढांचे के रूप में पुनः सोचें के रूप में कैसे देखना चाहिए, न कि केवल एक विकास सुविधा के रूप में?

अधिकांश संगठन जिस मानसिक मॉडल से काम कर रहे हैं वह एक दशक पुराना है। ओपन सोर्स ने एक विकास सुविधा के रूप में शुरुआत की। डेवलपर लाइब्रेरी खींच सकते थे, तेजी से आगे बढ़ सकते थे, और मूलभूत घटकों को पुनः बनाने से बच सकते थे। यह फ्रेमिंग तब समझ में आया जब ओपन सोर्स वैकल्पिक और पूरक था।

यह वर्तमान वास्तविकता नहीं है। ओपन सोर्स आधुनिक सॉफ्टवेयर का आधार है। 96% अनुप्रयोग ओपन सोर्स घटकों को शामिल करते हैं। यह प्रोप्राइटरी इन्फ्रास्ट्रक्चर के ऊपर एक सुविधा परत नहीं है। यह बुनियादी ढांचा है। और बुनियादी ढांचे को बुनियादी ढांचे की तरह शासित किया जाना चाहिए, जिसमें वातावरण में प्रवेश करने वाले के बारे में स्पष्ट नीतियां हों, रखरखाव और उपचार के लिए परिभाषित स्वामित्व हों, और संगठन के सही स्तर पर जवाबदेही हो।

जो संगठन आगे हैं उन्होंने एक जानबूझकर बदलाव किया है: ओपन सोर्स की खपत एक रणनीतिक निर्णय है जिसमें सुरक्षा और वित्तीय परिणाम हैं, न कि डेवलपर्स द्वारा व्यक्तिगत रूप से प्रबंधित एक डिफ़ॉल्ट सेटिंग। यह बदलाव नीति, संचालन प्रक्रिया और स्पष्ट कार्यकारी जवाबदेही की आवश्यकता है। अधिकांश संगठन अभी तक इस बदलाव को नहीं बना पाए हैं।

आपने कई प्रौद्योगिकी तरंगों का नेतृत्व किया है। एआई-चालित परिवर्तन की तुलना क्लाउड और डेवओप्स जैसे पिछले संक्रमणों से कैसे की जा सकती है, जो गति और विघटन के संदर्भ में हैं?

वर्तमान एआई-चालित आंदोलन पिछले प्रौद्योगिकी परिवर्तनों के समान है। जब क्लाउड एक वितरण मॉडल के रूप में उभरा, तो जिन संगठनों ने इसे एक शुद्ध प्रौद्योगिकी चुनाव के रूप में माना, उन्होंने जिन संगठनों से अलग गलतियां कीं जिन्होंने इसे एक वास्तुकला और संचालन परिवर्तन के रूप में माना। जो विफल रहे उन्होंने शैडो आईटी, लागत अधिकचार्ज, सुरक्षा और तकनीकी ऋण में वर्षों तक इसका भुगतान किया।

जो अलग है वह यह है कि वर्तमान एआई-चालित परिवर्तन की गति और अदृश्यता है। क्लाउड अपनाया जाना दिखाई दे रहा था। आपको पता था जब आपका संगठन क्लाउड में काम को स्थानांतरित कर रहा था। डेवओप्स दिखाई दे रहा था: संगठन टीमों को पुनर्गठित कर रहे थे, तैनाती पाइपलाइनों को बदल रहे थे, और प्रक्रियाओं को पुनः लिख रहे थे। एआई कोडिंग टूल्स को विकासकर्ता द्वारा विकासकर्ता और टूल कॉल द्वारा अपनाया जा रहा है, और जोखिम कोडबेस में जमा हो रहा है जब अधिकांश संगठनों ने महसूस किया है कि एक शासन निर्णय लिया गया था।

विघटन भी एक तरह से असममित है जो क्लाउड और डेवओप्स में नहीं था। उन संक्रमणों ने नए जोखिम श्रेणियां बनाईं लेकिन यह धारणा बनाए रखी कि एक मानव कोड के लिए जिम्मेदार था जो जहाजों पर चढ़ा था। एआई उस बिंदु पर इस धारणा को कमजोर कर रहा है जहां यह सबसे कठिन है इसका पता लगाने के लिए। यही इस संक्रमण को अलग बनाता है। एक्सपोजर तब तक अदृश्य है जब तक यह नहीं है।

कई कंपनियां ओपन सोर्स को एक टिकाऊ व्यवसाय मॉडल में बदलने के लिए संघर्ष करती हैं। कंपनियों को क्या अलग करता है जो सफल होती हैं और जो विफल होती हैं?

जिन संगठनों ने ओपन सोर्स पर टिकाऊ व्यवसाय बनाया है, उनमें एक विशेषता है: वे यह जानते हैं कि वे वास्तव में कौन सा उत्पाद बेच रहे हैं। वे ओपन सोर्स सॉफ्टवेयर नहीं बेच रहे हैं, जो मुफ्त है। वे विशेषज्ञता, संचालन समर्थन, शासन बुनियादी ढांचे, या प्रबंधित सेवा बेच रहे हैं जो उद्यम स्तर पर मुफ्त सॉफ्टवेयर को व्यवहार्य बनाता है।

इसके विपरीत, जो संगठन विफल होते हैं वे समुदाय को अपनाने को व्यावसायिक ट्रैक्शन के साथ भ्रमित करते हैं। वे एक ही चीज नहीं हैं। एक उच्च गिटहब स्टार गिनती या एक बड़ा समुदाय यह संकेत देता है कि डेवलपर परियोजना को उपयोगी पाते हैं। यह यह नहीं कहता है कि खरीदार इसके लिए भुगतान करेंगे, या जो डेवलपर उपयोगी पाते हैं वह वही है जिसकी संगठनों को वास्तव में आवश्यकता है। डेवलपर अपनाने से उद्यम मूल्य तक का अनुवाद करने के लिए ओपन सोर्स स्वयं से परे कुछ बनाने की आवश्यकता है, और जो संगठन इस प्रतिष्ठा को स्पष्ट रूप से नहीं बनाते हैं, अपनी स्थिति, उत्पाद में, और बिक्री गति में, अक्सर पैमाने पर संक्रमण को जीवित नहीं रख पाते हैं।

डेवलपर-फर्स्ट संगठनों को स्केल करने के अपने अनुभव से, उत्पाद-नेतृत्व वाली वृद्धि से उद्यम-स्तरीय संचालन में परिवर्तन के दौरान नेतृत्व की सबसे बड़ी चुनौतियां क्या हैं?

सबसे बड़ी चुनौती यह है कि उत्पाद-नेतृत्व वाली वृद्धि में आपको जो कौशल और प्रवृत्ति मिली है, वह उद्यम स्तर पर आपके खिलाफ काम करती है। उत्पाद-नेतृत्व वाली वृद्धि तेजी से आगे बढ़ने, सार्वजनिक रूप से पुनरावृत्ति करने, डेवलपर अनुभव के लिए अनुकूलन करने और व्यावसायिक गति को अपनाने की अनुमति देती है। उद्यम बिक्री जानबूझकर प्रक्रिया, कार्यकारी संबंधों, लंबे चक्रों और आपके उत्पाद को परिणामों से मैप करने की क्षमता को पुरस्कृत करती है जो गैर-डेवलपर खरीदारों के लिए मायने रखते हैं।

नेतृत्व में सबसे बड़ी गलती जो मैं देखता हूं वह यह है कि यह मानता है कि परिवर्तन मुख्य रूप से एक बिक्री गति समस्या है। यह नहीं है। यह एक संगठनात्मक डिज़ाइन समस्या है। जिस टीम ने उत्पाद, स्थिति, और शुरुआती ग्राहक संबंधों का निर्माण किया, अक्सर वह टीम नहीं है जो उद्यम गति को निष्पादित कर सकती है। यह स्वीकार करना कि बिना जो बनाया गया था उसे नुकसान पहुंचाए, वास्तव में मुश्किल है। जो नेता इसे अच्छी तरह से करते हैं वे उन हिस्सों के बारे में ईमानदार हैं जिन्हें संगठन को विकसित करने की आवश्यकता है और जो नई क्षमताएं बनाते हैं जो संस्कृति को नुकसान पहुंचाए बिना जो उत्पाद को खरीदने लायक बनाती है।

आपने सुरक्षा और डेवलपर उत्पादकता के बीच के बिंदु पर काम किया है। कंपनियां गति और नवाचार की बढ़ती आवश्यकता के साथ सुरक्षित और विश्वसनीय सॉफ्टवेयर घटकों को कैसे संतुलित कर सकती हैं?

गति के खिलाफ सुरक्षा का फ्रेमिंग एक झूठा विकल्प है जो बना हुआ है क्योंकि टूलिंग ने इसे मजबूत किया है। जब सुरक्षा को विकास प्रक्रिया के अंत में एक समीक्षा गेट के रूप में लागू किया जाता है, तो यह एक बोतलनेक है। जब यह एक शासित स्रोत के रूप में लागू किया जाता है जिसे डेवलपर्स प्रक्रिया की शुरुआत में खींचते हैं, तो यह कुछ भी धीमा नहीं करता है।

जिन लोगों ने इस तनाव को हल किया है, उन्होंने ऐसा करके किया है कि वे सुरक्षा कहां होती है। निर्मित कोड की समीक्षा करने के लिए नहीं। निर्मित कलाकृतियों को स्कैन करने के लिए नहीं। जो कैटलॉग से डेवलपर और एआई टूल खींचते हैं उसे शासित करना। यदि स्रोत विश्वसनीय है, तो सुरक्षा समीक्षा द्वारा वेलोसिटी पर अंकुश नहीं लगाया जाता है क्योंकि सुरक्षा कार्य अपस्ट्रीम हुआ। यह एक वास्तुकला निर्णय है, एक सांस्कृतिक नहीं। इसके लिए शासन बुनियादी ढांचे में निवेश की आवश्यकता है, लेकिन इसके लिए गति और सुरक्षित रूप से जहाज चलाने के बीच चुनने की आवश्यकता नहीं है।

एआई टूल्स कोड और निर्भरता का उत्पादन बढ़ाने के साथ, अगले कुछ वर्षों में क्यूरेटेड या विश्वसनीय ओपन सोर्स पारिस्थितिकी तंत्र की भूमिका कैसे विकसित होगी?

क्यूरेटेड, विश्वसनीय ओपन सोर्स स्रोतों की भूमिका एक सर्वोत्तम अभ्यास से एक बेसलाइन आवश्यकता में बदल जाएगी। यह परिवर्तन दो चीजों से चलाया जा रहा है जो उलट नहीं जाएंगे।

पहला नियामक वातावरण है। 2026 के परिदृश्य में, सॉफ्टवेयर प्रोवेनेंस का प्रदर्शन करने में सक्षम होना एक कानूनी आवश्यकता है, एक स्वैच्छिक मानक नहीं। बोर्ड और नियामक यह पूछने वाले प्रश्नों को बदल रहे हैं जिनका उत्तर अधिकांश संगठन देने में सक्षम नहीं हैं।

दूसरा एआई विकास वेलोसिटी है। जैसे-जैसे एआई टूल अधिक कोड और अधिक निर्भरता उत्पन्न करते हैं, अनवेटेड घटकों की मात्रा जो उत्पादन में प्रवेश कर रही है, किसी भी संगठन की मैनुअल रूप से समीक्षा करने की क्षमता से अधिक हो जाएगी। जिन संगठनों ने एक क्यूरेटेड, नीति-नियंत्रित कैटलॉग को अपने डेवलपर्स और एआई टूल्स के लिए डिफ़ॉल्ट स्रोत के रूप में स्थापित किया है, वे एआई की वेलोसिटी के साथ सुरक्षा शासन का मिलान करने में सक्षम होंगे। जो संगठन अभी भी सार्वजनिक रजिस्ट्रियों और मैनुअल समीक्षा पर निर्भर हैं, वे एक बढ़ती खाई का सामना करेंगे जो कोड कितनी तेजी से उत्पन्न हो रहा है और यह कितनी अच्छी तरह से मूल्यांकन किया जा रहा है।

क्यूरेटेड पारिस्थितिकी तंत्र एआई विकास द्वारा बनाई गई एक समस्या का बुनियादी ढांचा उत्तर हैं।

ओपन सोर्स और बुनियादी ढांचे के क्षेत्र में महिला सीईओ में से एक के रूप में, आपने नेतृत्व विविधता में क्या परिवर्तन देखा है, और क्या अभी भी सुधार की आवश्यकता है?

वास्तविक परिवर्तन हुआ है। जब मैंने अपना करियर शुरू किया, तो ओपन सोर्स और बुनियादी ढांचे में कार्यकारी भूमिकाओं में महिलाओं का प्रतिनिधित्व इतना कम था कि अपवाद उल्लेखनीय थे। यह अब कम सच है। अधिक महिलाएं वरिष्ठ तकनीकी और कार्यकारी पदों पर हैं, अधिक संगठन हैं जिन्होंने प्रदर्शन विविधता बयान चरण से आगे बढ़कर संरचनात्मक परिवर्तन किए हैं, और अधिक मॉडल हैं जो इस स्थान में नेतृत्व के लिए क्या दिख सकता है।

शेष अंतर को बंद करने के लिए व्यवसाय मामला स abstract नहीं है। इस उद्योग में जिन समस्याओं पर काम किया जा रहा है, सॉफ्टवेयर आपूर्ति श्रृंखला जोखिम, एआई शासन, सुरक्षा को एक प्राथमिक अभ्यास बनाने के लिए संगठनात्मक परिवर्तन, वे मुश्किल समस्याएं हैं। विविध टीमें कठिन समस्याओं पर बेहतर परिणाम उत्पन्न करती हैं। यह एक आकांक्षा के रूप में नहीं है, बल्कि इसलिए है कि विभिन्न दृष्टिकोण धारणाओं को उजागर करते हैं जो समान टीमें याद करती हैं। मैंने इसे सीधे देखा है। जिन संगठनों ने वास्तव में प्रगति की है उनमें से जो संगठन वास्तव में संबंध बनाने में प्रगति कर चुके हैं, वे हैं जिनमें यह संचालन लाभ दिखाई देता है।

संबंध अभी भी उद्योग में असमान है। कमरे में होना वास्तव में आपके दृष्टिकोण को वजनदार मानने जैसा नहीं है। यहाँ अगले चरण की प्रगति की आवश्यकता है।

धन्यवाद महान साक्षात्कार के लिए, पाठक जो अधिक जानना चाहते हैं उन्हें एक्टिवस्टेट पर जाना चाहिए।