Transcript
00:00:00GitHub एक बहुत ही गंभीर, बहुत ही खराब स्थिति में है।
00:00:04वहाँ कई, कई समस्याएँ हैं, उनमें से कई AI से संबंधित हैं,
00:00:08लेकिन शायद उन कारणों से नहीं जो आप सोचते हैं,
00:00:10लेकिन मैं उस पर वापस आऊँगा।
00:00:11और ज़ाहिर है कि यह मायने रखता है।
00:00:13यह मायने रखता है क्योंकि GitHub आधुनिक विकास कार्य
00:00:16की रीढ़ है।
00:00:17कोई फर्क नहीं पड़ता कि आप ओपन सोर्स डेवलपमेंट कर रहे हैं,
00:00:20या आप कुछ ओपन सोर्स प्रोजेक्ट्स को मैनेज कर रहे हैं,
00:00:22या आप सिर्फ अपने प्रोजेक्ट्स पर काम कर रहे हैं,
00:00:24अपने व्यक्तिगत प्रोजेक्ट्स, अपने साइड प्रोजेक्ट्स,
00:00:26या यदि आप एक छोटा व्यवसाय, एक छोटी कंपनी चला रहे हैं,
00:00:29या शायद आप किसी बड़ी कंपनी में हैं,
00:00:32इसका उपयोग कोड आर्काइव के रूप में हर तरह की चीजों के लिए किया जाता है,
00:00:35CI/CD वर्कफ़्लो के लिए, सहयोग के लिए,
00:00:38इश्यूज के माध्यम से प्रोजेक्ट्स पर साथ मिलकर काम करने के लिए,
00:00:42पुल रिक्वेस्ट्स और कई अन्य चीजों और उपयोग के मामलों के लिए।
00:00:47तो यह मायने रखता है, लेकिन जैसा कि बताया गया है,
00:00:49वहाँ कई, कई समस्याएँ हैं।
00:00:51और चलिए पहले यह देखते हैं कि क्या गलत है,
00:00:53इससे पहले कि हम इसके कारणों को देखें
00:00:54और भविष्य के लिए इसके क्या मायने हैं।
00:00:57और चलिए एक बड़ी बात से शुरुआत करते हैं।
00:00:59वहाँ एक बड़ी, एक विशाल,
00:01:02एक अविश्वसनीय सुरक्षा संवेदनशीलता कल रिपोर्ट की गई थी,
00:01:07जब मैं इसे रिकॉर्ड कर रहा हूँ।
00:01:09github.com पर एक रिमोट कोड एक्ज़ीक्यूशन।
00:01:12मेरा मतलब है, इसे पढ़ना ही पागलपन भरा है।
00:01:16इसे Viz, एक सुरक्षा कंपनी द्वारा खोजा गया था,
00:01:19और इसका फायदा नहीं उठाया गया था।
00:01:21तो इसे खोजा गया, रिपोर्ट किया गया और इसे ठीक कर दिया गया।
00:01:25कोई नुकसान नहीं हुआ था।
00:01:28GitHub के अनुसार,
00:01:31उन्होंने इस रिपोर्ट पर एक जवाब भी प्रकाशित किया है।
00:01:33अब, मैं इसकी बारीकियों में नहीं जाऊँगा
00:01:36कि वह संवेदनशीलता कैसे काम करती थी।
00:01:39हालाँकि मैं नीचे लेख का लिंक दे दूँगा।
00:01:42लेकिन अंत में, यह सब git push के ज़रिए हुआ।
00:01:44तो इसमें कोई फ़िशिंग शामिल नहीं थी,
00:01:46किसी कर्मचारी के अकाउंट का टेकओवर नहीं हुआ,
00:01:49कोई सप्लाई चेन हमला नहीं था।
00:01:51हमने पिछले हफ़्तों में ऐसी बहुत सी चीज़ें देखी हैं,
00:01:54लेकिन नहीं, इसमें ऐसा कुछ भी शामिल नहीं था।
00:01:56इसके बजाय, यह सिर्फ git push था,
00:01:58और फिर विशेष रूप से मानक पुश विकल्प फीचर
00:02:03जिसे आप git push कमांड में जोड़ सकते हैं
00:02:05उस पुश कमांड के साथ अतिरिक्त विकल्प जोड़ने के लिए।
00:02:10और उस ऑप्शन्स फीचर और उस संवेदनशीलता के माध्यम से
00:02:13और जिस तरह से GitHub पुश को हैंडल करता था,
00:02:17सुरक्षा शोधकर्ता यहाँ कोड जोड़ने में सक्षम थे
00:02:22जो GitHub सर्वर पर बस यूँ ही एक्ज़ीक्यूट हो जाता।
00:02:27अब, फिर से, सटीक विवरण इस रिपोर्ट में हैं,
00:02:31लेकिन अंत में, उन्होंने इस तथ्य का दुरुपयोग किया
00:02:34कि आप xstat हेडर में अतिरिक्त मेटाडेटा जोड़ सकते थे
00:02:39जो उस पुश ऑप्शन्स फ़्लैग की मदद से भर जाता।
00:02:44और वह मेटाडेटा, वह जानकारी जो आप साथ भेज सकते थे
00:02:49पुश रिक्वेस्ट के साथ उस हेडर के ज़रिए,
00:02:52वह अंत में GitHub द्वारा सैनिटाइज़ नहीं किया गया था।
00:02:54उन्होंने बस अंत में पुश रिक्वेस्ट को प्रमाणित किया,
00:02:58पुश कमांड को।
00:02:59उन्होंने जाँच की कि क्या आपको पुश करने की अनुमति है
00:03:01उस रिपॉजिटरी में जिसे आप पुश करने की कोशिश कर रहे हैं,
00:03:03लेकिन फिर उन्होंने वह ऑप्शन्स डेटा लिया
00:03:07और उस डेटा को सैनिटाइज़ किए बिना xstat हेडर बनाया।
00:03:12और इसने सुरक्षा शोधकर्ताओं को
00:03:15उस कमांड को एक्ज़ीक्यूट करने की अनुमति दी जो तब प्रतिबंधित नहीं था
00:03:18उस रिपॉजिटरी तक जिसमें उन्होंने पुश किया था,
00:03:21बल्कि इसके बजाय वह स्वतंत्र रूप से GitHub सर्वर पर चला
00:03:24और अन्य रिपॉजिटरीज़ को भी एक्सेस करने में सक्षम था,
00:03:27जिसमें प्राइवेट रिपॉजिटरीज़ भी शामिल थीं।
00:03:29अब, फिर से, इस संवेदनशीलता को रिपोर्ट किया गया और ठीक किया गया
00:03:33और यह अब अस्तित्व में नहीं है,
00:03:35लेकिन यह ज़ाहिर तौर पर एक बहुत बड़ी बात है।
00:03:39मेरा मतलब है, यह इतनी बड़ी बात है कि एक ऐसी संवेदनशीलता हो
00:03:43जो github.com पर रिमोट कोड एक्ज़ीक्यूशन की अनुमति दे।
00:03:45यह सच में बहुत बड़ा है।
00:03:47तो हाँ, यह एक बड़ी बात है,
00:03:48लेकिन ज़ाहिर है कि यह एकमात्र समस्या नहीं है।
00:03:5123 अप्रैल को, यानी कुछ ही दिन पहले,
00:03:56GitHub मर्ज क्यूज़ से संबंधित एक बहुत बड़ी घटना हुई थी।
00:04:01अब, GitHub मर्ज क्यूज़, यदि आप नहीं जानते हैं,
00:04:04एक GitHub फीचर है जिसका उपयोग उन रिपॉजिटरीज़ के लिए किया जाता है
00:04:07जहाँ बहुत अधिक गतिविधि, बहुत अधिक सक्रिय कार्य होता है,
00:04:11और बहुत सारी पुल रिक्वेस्ट्स आती रहती हैं।
00:04:13और यह सुनिश्चित करने के लिए कि आपको मर्ज न करना पड़े
00:04:16हर पुल रिक्वेस्ट इससे पहले कि कोई नई भेजी जा सके,
00:04:19क्योंकि ज़ाहिर है आप एक पुल रिक्वेस्ट चाहते हैं
00:04:21रिपॉजिटरी की नवीनतम स्थिति के खिलाफ,
00:04:24उदाहरण के लिए, मेन ब्रांच के खिलाफ,
00:04:26यह सुनिश्चित करने के लिए कि आपको मर्ज न करना पड़े
00:04:28हर पुल रिक्वेस्ट इससे पहले कि कोई नई ओपन की जा सके।
00:04:30अंत में, यह मर्ज क्यू फीचर मौजूद है,
00:04:34जिसका सरल लक्ष्य प्रभावी ढंग से बनाना है
00:04:38जैसे कि पहले से ही एक इंटरमीडिएट मर्ज
00:04:42रिपॉजिटरी की ब्रांच की एक नई स्थिति बनाना
00:04:46जिसके खिलाफ आप हर पुल रिक्वेस्ट के लिए मर्ज करने की कोशिश कर रहे थे।
00:04:49और यदि पुल रिक्वेस्ट्स की श्रृंखला में
00:04:51एक नई पुल रिक्वेस्ट जोड़ी जाती है,
00:04:53तो वह भी पहले से ही सामने की पुल रिक्वेस्ट्स के साथ
00:04:57मेन ब्रांच में मर्ज कर दी जाती है
00:04:58ताकि नई पुल रिक्वेस्ट्स इस तरह से ओपन हों
00:05:01जैसे कि पिछली पुल रिक्वेस्ट्स पहले ही मर्ज हो चुकी हों।
00:05:05और यह टीमों को तेज़ी से काम करने की अनुमति देता है
00:05:08क्योंकि आप और अधिक पुल रिक्वेस्ट्स ओपन कर सकते हैं
00:05:10बिना सामने वाली रिक्वेस्ट्स के पहले मर्ज हुए।
00:05:13किसी बिंदु पर, ज़ाहिर है, उन्हें मर्ज किया जाएगा,
00:05:15लेकिन यह आपको काम जारी रखने की अनुमति देता है,
00:05:17जो ज़ाहिर है बड़ी टीमों के लिए महत्वपूर्ण है, उदाहरण के लिए।
00:05:19अब उस फीचर से जुड़ी एक और महत्वपूर्ण बात
00:05:22ज़ाहिर है यह है कि यह सही ढंग से काम करे।
00:05:24और 23 अप्रैल को जो हुआ वह यह था
00:05:28कि वहाँ एक त्रुटि थी, एक आंतरिक लॉजिक त्रुटि
00:05:32कि कैसे GitHub इन अलग-अलग पुल रिक्वेस्ट्स को रिज़ॉल्व करता है
00:05:37ताकि अंततः यह एक ऐसा मर्ज बना दे
00:05:41जो कुछ जानकारी छोड़ दे जिससे
00:05:45एक अमान्य कमिट बन जाए और कुछ हिस्सों को
00:05:49Git हिस्ट्री से हटा दे।
00:05:50अब डेटा वास्तव में खोया नहीं था,
00:05:53लेकिन इस फीचर ने गलत तरीके से काम किया
00:05:55और वह गलत कमिट पैदा किया।
00:05:57यह इसका संक्षिप्त विवरण है, इसका सार है।
00:06:00और ज़ाहिर है, यह पूरी तरह से अस्वीकार्य भी है
00:06:03यदि आप एक बड़ी कंपनी हैं या कोई भी कंपनी जो भरोसा करती है
00:06:06उस फीचर पर और अचानक आपका प्रोजेक्ट
00:06:09एक टूटी हुई स्थिति में पहुँच जाता है बिना किसी स्पष्ट स्पष्टीकरण के,
00:06:13तो यह ज़ाहिर तौर पर अस्वीकार्य है।
00:06:16और आपका पहला विचार ज़ाहिर है शायद यह नहीं होगा
00:06:19कि उस मर्ज क्यू फीचर में कोई आंतरिक बग है।
00:06:23यह शायद यह होगा कि आपने कुछ गलत किया है।
00:06:26तो आप गलती खोजने में बहुत समय बिताते हैं
00:06:28जब तक आपको पता नहीं चलता, ओह नहीं, यह GitHub है।
00:06:30और यह सब ज़ाहिर है उस अतिरिक्त समस्या के रूप में आता है
00:06:33जो GitHub की चल रही अपटाइम डाउनटाइम समस्याओं के साथ है।
00:06:38अब आधिकारिक स्टेटस पेज खराब दिखता है,
00:06:42लेकिन शायद ठीक है, पर हमारे पास यहाँ भी
00:06:46अपटाइम के 'थ्री नाइन्स' (99.9%) नहीं हैं, कम से कम अधिकांश सिस्टम्स के लिए।
00:06:49वे अलग-अलग सिस्टम्स के लिए अपटाइम की रिपोर्ट अलग से करते हैं।
00:06:53लेकिन चीज़ें थोड़ी अलग दिखती हैं अगर हम
00:06:55मिसिंग GitHub स्टेटस पेज को देखें,
00:06:57जो अपटाइम को एक अलग तरीके से ट्रैक करता है
00:07:00और हर छोटी घटना को एक समस्या के रूप में गिनता है,
00:07:04अंत में एक डाउनटाइम के रूप में।
00:07:05यहाँ हमारे पास GitHub जैसे महत्वपूर्ण सिस्टम के लिए
00:07:10एक भयानक अपटाइम है, जो ज़ाहिर तौर पर पूरी तरह से अस्वीकार्य है।
00:07:14तो हमारे पास पिछले महीनों से अपटाइम की समस्याएँ थीं
00:07:18और यहाँ तक कि पिछले साल भी।
00:07:20और यहाँ-वहाँ छोटे-मोटे बग्स भी रहे हैं,
00:07:23बस इसके जितने बड़े नहीं या उतने महत्वपूर्ण नहीं
00:07:26जितनी कि यह सुरक्षा संवेदनशीलता थी।
00:07:28लेकिन हाँ, बहुत सारी समस्याएँ हैं
00:07:31और GitHub निश्चित रूप से एक अविश्वसनीय प्लेटफ़ॉर्म बन गया है
00:07:36इस समय, दुर्भाग्य से,
00:07:38जो इसकी भूमिका और इसके महत्व को देखते हुए एक आपदा है
00:07:43जैसा कि मैंने शुरू में कहा था, आधुनिक विकास में,
00:07:47चाहे आप किसी भी प्रकार का विकास कार्य कर रहे हों।
00:07:50एक और समस्या यह है कि GitHub की ओर से संचार
00:07:54काफी कम रहा है, चलिए ऐसा कहते हैं।
00:07:59बहुत अधिक संचार नहीं हुआ है,
00:08:01लेकिन 28 अप्रैल को एक ब्लॉग पोस्ट साझा की गई थी
00:08:06उस सुरक्षा संवेदनशीलता से पहले,
00:08:10जहाँ वे एक तरह से समझाते हैं कि क्या हो रहा है,
00:08:14समस्याएँ कहाँ से आ रही हैं,
00:08:16कि वे समझते हैं कि उनकी संचार रणनीति
00:08:19आदर्श नहीं रही है और चीज़ें बेहतर होंगी।
00:08:23अब यह अगला हिस्सा है।
00:08:25समस्याएँ कहाँ से आ रही हैं?
00:08:28यहाँ आधिकारिक बयान में AI को एक कारण बताया गया है,
00:08:32लेकिन इस अर्थ में नहीं कि Microsoft के
00:08:36GitHub इंजीनियर AI का उपयोग कर रहे हैं और खराब सॉफ़्टवेयर,
00:08:40GitHub के लिए खराब अपडेट भेज रहे हैं।
00:08:43ऐसा हो रहा हो सकता है, लेकिन हमारे पास इसका कोई प्रमाण नहीं है।
00:08:47लेकिन इसके बजाय, यहाँ बताया गया मुख्य कारण ज़ाहिर है यह है
00:08:51कि AI की वजह से, अब बहुत अधिक प्रोजेक्ट्स
00:08:57बनाए जा रहे हैं, बहुत अधिक कोड जेनरेट किया जा रहा है,
00:09:00और अंततः वे सभी प्रोजेक्ट्स और वह सारा कोड
00:09:03GitHub पर पुश किया जा रहा है।
00:09:04और वे कुछ, खैर, हाँ, बहुत मददगार नहीं,
00:09:09लेकिन वे यहाँ कुछ चार्ट्स साझा करते हैं।
00:09:12वे बहुत मददगार नहीं हैं क्योंकि हमारे पास कोई y-अक्ष (y-axis) नहीं है।
00:09:14हमें पूर्ण संख्याएँ नहीं दिखतीं,
00:09:17लेकिन ज़ाहिर है कि हम यहाँ संबंधों को देख सकते हैं।
00:09:20और हम, ज़ाहिर है, देख सकते हैं कि 2025 के दौरान,
00:09:23मर्ज की गई पुल रिक्वेस्ट्स में भारी वृद्धि हुई थी,
00:09:28पुश किए गए कमिट्स, और ज़ाहिर है नई रिपॉजिटरीज़ के ओपन होने में भी।
00:09:32ये वे सभी साइड प्रोजेक्ट्स हैं जो हम अब बना रहे हैं
00:09:34और AI के साथ पूरे नहीं कर रहे हैं।
00:09:36और फिर 2026 में, ज़ाहिर तौर पर इन सभी मेट्रिक्स के लिए,
00:09:41चार्ट बस आसमान छू रहा है, मुझे लगता है।
00:09:46तो हाँ, यह ज़ाहिर तौर पर काफी स्पष्ट रुझान है।
00:09:49और यह ट्रैफ़िक, ट्रैफ़िक में इस तरह की वृद्धि
00:09:54ज़ाहिर तौर पर किसी भी सिस्टम को तनाव में डाल देगी।
00:09:58यह विशेष रूप से GitHub के लिए समस्याग्रस्त है
00:10:01क्योंकि वे माइग्रेशन के बीच में हैं
00:10:05एक मोनोलिथिक संरचना से दूर और अपने स्वयं के समर्पित
00:10:09डेटा सेंटर्स या सिस्टम्स से Azure क्लाउड में
00:10:13और एक अधिक विभाजित सिस्टम, एक माइक्रोसर्विसेस सिस्टम में,
00:10:17आप कह सकते हैं, उस मोनोलिथिक संरचना के बजाय।
00:10:21यह 2026 में प्रवेश करने से पहले ही एक चल रही प्रक्रिया थी।
00:10:26लेकिन ज़ाहिर है इसका मतलब है कि अब यह माइग्रेशन प्रक्रिया
00:10:31मांग में उस उछाल से प्रभावित हुई है,
00:10:34इसका मतलब है कि भले ही आप माइग्रेट कर रहे हों,
00:10:36आपको वर्तमान सिस्टम को एक तरह से स्थिर करना होगा
00:10:39और साथ ही माइग्रेशन को जारी रखना होगा,
00:10:40जो उम्मीद है कि भविष्य में ट्रैफ़िक की
00:10:44उस वृद्धि में मदद करेगा।
00:10:46बेशक, यह सिर्फ एक उम्मीद है, कोई गारंटी नहीं।
00:10:50लेकिन निश्चित रूप से यह कुछ ऐसा है जिससे GitHub को निपटना होगा।
00:10:52अब वे यहाँ बता रहे हैं कि उन्होंने अक्टूबर, 2025 में
00:10:56GitHub की क्षमता को 10 गुना बढ़ाने की योजना पर काम शुरू कर दिया था।
00:11:01तो आप कह सकते हैं कि यहाँ के आसपास उन्होंने देखा,
00:11:04कि खैर, यह सब ऊपर जा रहा है।
00:11:06मेरा मतलब है, वे इसे पहले से ही देख सकते थे,
00:11:09लेकिन यहीं उन्होंने फैसला किया कि हमें अपनी क्षमता 10 गुना करने की जरूरत है।
00:11:13और फिर फरवरी, 2026 में उन्होंने देखा,
00:11:16ठीक है, हमें 10 गुना नहीं बल्कि 30 गुना की जरूरत है क्योंकि, खैर,
00:11:20यहाँ हुए उस विकास की वजह से, है ना?
00:11:22ज़ाहिर है कि उस माइग्रेशन के अलावा यह काम भी किया जाना चाहिए।
00:11:28और यह स्पष्ट रूप से एक बहुत बड़ा काम है।
00:11:33अब यह Microsoft का हिस्सा है, तो यह कोई छोटा स्टार्टअप नहीं है,
00:11:37लेकिन फिर भी, यह एक कठिन काम है।
00:11:39और इस पूरी GitHub समस्या का यह एक ऐसा पहलू है
00:11:44जहाँ मुझे कुछ सहानुभूति है क्योंकि मुझे लगता है कि
00:11:47GitHub से नफरत करना या उसका मजाक उड़ाना आसान है।
00:11:51और आप निश्चित रूप से ऐसा कर सकते हैं।
00:11:52और मैं आगे और समस्याओं पर आऊँगा, जो वाकई बहुत खराब हैं।
00:11:56लेकिन इस तरह की ट्रैफ़िक वृद्धि किसी भी सिस्टम के लिए,
00:11:59दुनिया की किसी भी कंपनी के लिए एक बहुत बड़ी समस्या होगी।
00:12:03और यह मानना मुश्किल है कि GitHub का कोई भी प्रतिस्पर्धी
00:12:07इस स्थिति में बेहतर प्रदर्शन कर पाएगा।
00:12:09फिर भी, निश्चित रूप से, यह कोई बहाना नहीं है।
00:12:10यह Microsoft का हिस्सा है।
00:12:12और इसलिए, उनके पास निश्चित रूप से वे संसाधन हैं
00:12:16कि वे इस बदलाव से गुज़र सकें और अपने सिस्टम को
00:12:20इस नई दुनिया और ट्रैफ़िक की इस नई मात्रा के अनुसार ढाल सकें।
00:12:24लेकिन यहाँ GitHub के साथ एक और महत्वपूर्ण समस्या है।
00:12:28और वो यह है कि अब इसका कोई CEO नहीं है।
00:12:32पिछले CEO, थॉमस, थॉमस डमके,
00:12:37रिटायर हो गए या पद छोड़ दिया या घोषणा की कि वह पद छोड़ देंगे
00:12:41अगस्त, 2025 में।
00:12:43और Microsoft ने कोई नया CEO नियुक्त नहीं किया।
00:12:48इसके बजाय, GitHub 'कोर AI' का हिस्सा बन गया,
00:12:51जो Microsoft का एक आंतरिक विभाग है, जो जैसा कि नाम से पता चलता है,
00:12:56पूरी तरह से AI और AI टूल्स और प्लेटफॉर्म बनाने के बारे में है।
00:13:01और GitHub उसका हिस्सा है।
00:13:03तो स्पष्ट रूप से Microsoft के नजरिए से GitHub का मिशन
00:13:07उस AI टूल चेन का हिस्सा बनना है,
00:13:11उस AI क्रांति का हिस्सा बनना है।
00:13:13और ज़ाहिर है कि Microsoft अपने सभी उत्पादों में
00:13:15Co-Pilot को बढ़ावा दे रहा है।
00:13:16और वास्तव में GitHub Universe 2023 में,
00:13:20उन्होंने पहले ही कह दिया था कि वे GitHub को
00:13:24एक AI-संचालित डेवलपर प्लेटफ़ॉर्म में बदल देंगे
00:13:28जहाँ GitHub हर जगह होगा।
00:13:30इसमें नई सुविधाओं जैसी चीज़ें शामिल हैं
00:13:32जो GitHub Co-Pilot के साथ 'इश्यूज' बनाने में मदद करती हैं,
00:13:36जो ओपन सोर्स मेंटेनर्स के लिए एक बड़ी समस्या है,
00:13:39लेकिन साथ ही GitHub पर हर जगह
00:13:43GitHub Co-Pilot की शुद्ध मौजूदगी भी है।
00:13:44GitHub पर यह 'Agent HQ' नाम की चीज़ है,
00:13:48[github.com/copilot](https://github.com/copilot),
00:13:49जहाँ आप GitHub Co-Pilot के साथ इंटरैक्ट कर सकते हैं
00:13:52और सीधे GitHub Co-Pilot के अंदर से ही अपने कोड पर काम कर सकते हैं
00:13:55बिना किसी लोकल IDE या कोडिंग एजेंट टूल को खोले
00:14:00और भी बहुत कुछ।
00:14:02GitHub Co-Pilot अब GitHub में हर जगह है,
00:14:05ठीक वैसे ही जैसे Co-Pilot हर जगह है
00:14:07Microsoft के सभी उत्पादों में, मुझे लगता है।
00:14:10और यह निश्चित रूप से एक स्पष्ट रणनीतिक निर्णय है
00:14:14जो एक तरह से GitHub के वास्तविक मिशन के खिलाफ जाता है,
00:14:19कम से कम उस मिशन के जो GitHub का अतीत में था।
00:14:23क्योंकि जैसा कि मैंने शुरुआत में ही उल्लेख किया था,
00:14:25GitHub अलग-अलग तरह के डेवलपर्स के लिए
00:14:29तमाम तरह के उपयोग के मामलों के लिए महत्वपूर्ण है।
00:14:31ओपन सोर्स मेंटेनर्स इसका उपयोग अपना सोर्स कोड
00:14:36वहाँ रखने और अन्य मेंटेनर्स
00:14:39और समुदाय के अन्य योगदानकर्ताओं के साथ सहयोग करने के लिए करते हैं।
00:14:41'इश्यूज' (Issues) कमियों का पता लगाने
00:14:45और उन पर काम करने के लिए महत्वपूर्ण हैं।
00:14:46'पुल रिक्वेस्ट' (Pull requests) इसलिए महत्वपूर्ण हैं ताकि अन्य लोग
00:14:50कोड बेस में अपना योगदान दे सकें।
00:14:52'डिस्कशन्स' (Discussions) नई सुविधाओं या किसी रिपॉजिटरी
00:14:55या लाइब्रेरी की दिशा पर चर्चा करने के लिए बेहतरीन हो सकते हैं।
00:15:01यहाँ इससे जुड़ी कई सुविधाएँ हैं
00:15:03जो ओपन सोर्स मेंटेनर्स की मदद करती हैं
00:15:04या कम से कम अतीत में करती थीं।
00:15:07अन्य लोग GitHub का उपयोग केवल लिंक या दस्तावेज़ों की
00:15:11मेजबानी के लिए एक संसाधन के रूप में कर रहे हैं
00:15:13जैसे कि ये सभी शानदार रिपॉजिटरी - awesome Go, awesome Rust
00:15:17इत्यादि, जिनका उपयोग आप आसानी से संसाधन खोजने के लिए कर सकते हैं
00:15:20यदि आप Go या Rust के साथ काम करना चाहते हैं।
00:15:22मैं अपने कोर्स के संसाधनों को होस्ट करने के लिए भी GitHub का उपयोग कर रहा हूँ
00:15:26जैसे यहाँ मेरे Codex कोर्स के लिए, उदाहरण के तौर पर,
00:15:29और कई अन्य कोर्सेज के लिए भी।
00:15:31तो आप GitHub का उपयोग एक तरह के
00:15:33डॉक्यूमेंट स्टोरेज के रूप में भी कर सकते हैं।
00:15:36और फिर निश्चित रूप से आप CI/CD काम के लिए भी GitHub का उपयोग कर सकते हैं।
00:15:40एक कंपनी में, आप अपना सोर्स कोड वहाँ रखने के लिए
00:15:43GitHub का उपयोग कर रहे होंगे,
00:15:46ताकि आपकी टीम के सदस्य उस सोर्स कोड पर
00:15:50पुल रिक्वेस्ट आदि के साथ सहयोग कर सकें।
00:15:52और फिर निश्चित रूप से, GitHub बहुत बार
00:15:54CI/CD पाइपलाइन का हिस्सा भी होता है
00:15:57जहाँ मेन ब्रांच पर एक नया 'पुश', उदाहरण के लिए,
00:15:59एक CI/CD पाइपलाइन को ट्रिगर करता है।
00:16:02यह GitHub Actions की मदद से हो सकता है,
00:16:05हालांकि उस उत्पाद की अपनी समस्याएं हैं।
00:16:08लेकिन ज़ाहिर है कि इसका उपयोग किसी अन्य CI/CD प्रदाता पर
00:16:12CI/CD पाइपलाइन को ट्रिगर करने के लिए भी किया जा सकता है, न कि केवल GitHub Actions पर।
00:16:16तो GitHub की निश्चित रूप से क्लासिक पारंपरिक
00:16:20डेवलपमेंट कार्य के लिए एक बहुत महत्वपूर्ण भूमिका है।
00:16:24लेकिन निश्चित रूप से, Microsoft ने तय किया कि नहीं,
00:16:27इसे एक AI संचालित डेवलपर प्लेटफॉर्म बनना चाहिए,
00:16:31सिर्फ एक डेवलपर प्लेटफॉर्म नहीं।
00:16:33और यह निश्चित रूप से यहाँ एक तरह का मेल नहीं है।
00:16:37डेवलपर्स ज़रूरी नहीं कि GitHub के हर पहलू में
00:16:41Co-Pilot को चाहते हों।
00:16:43मुझे लगता है कि सामान्य तौर पर Microsoft उत्पादों के उपयोगकर्ता
00:16:46अपने सभी उत्पादों में GitHub नहीं चाहते,
00:16:48लेकिन वह एक अलग कहानी है।
00:16:49और GitHub उन मुख्य विशेषताओं की उपेक्षा कर रहा है
00:16:53जो डेवलपर्स के लिए महत्वपूर्ण हैं।
00:16:56और मेरा मतलब है, ओपन सोर्स डेवलपमेंट के काम को ही ले लीजिए।
00:17:00ओपन सोर्स प्रोजेक्ट मेंटेनर्स AI द्वारा उत्पन्न
00:17:03इश्यूज और पुल रिक्वेस्ट के नीचे दबे जा रहे हैं।
00:17:07अब यहाँ समस्या निश्चित रूप से असंतुलन की है।
00:17:10कोड या इश्यूज उत्पन्न करने के लिए AI का उपयोग करना आसान है।
00:17:14उस सब की समीक्षा करना कहीं अधिक कठिन है।
00:17:19यानी उस उत्पन्न कोड और इश्यूज की समीक्षा करना।
00:17:24और मेरा मतलब है, यह कुछ ऐसा है जिसे हर डेवलपर जानता है
00:17:26जिसने कभी AI के साथ काम किया है।
00:17:27आप आसानी से तीन या अधिक AI एजेंट चला सकते हैं
00:17:30और उन्हें अपने प्रोजेक्ट्स पर काम पर लगा सकते हैं,
00:17:32पूरी तरह से GitHub के बाहर।
00:17:33आप इसे अपनी मशीन पर CodeX,
00:17:35Claude Code और इसी तरह के अन्य टूल्स के साथ कर सकते हैं।
00:17:36लेकिन फिर यदि आप 'वाइप कोडिंग' (wipe coding) के रास्ते पर नहीं जा रहे हैं,
00:17:39जो कि मेरे विचार में आपको नहीं जाना चाहिए,
00:17:41तो आपको किसी न किसी मोड़ पर उस कोड की समीक्षा करनी ही होगी।
00:17:44और इसमें समय लगता है।
00:17:45और इसमें बहुत मज़ा नहीं आता, कम से कम मुझे तो नहीं।
00:17:48अब, यदि आप तीन एजेंट चलाते हैं,
00:17:51तो आपको तीन एजेंटों के आउटपुट की समीक्षा करनी होगी।
00:17:54यदि यह आपके लिए बहुत अधिक है तो आप एजेंटों की संख्या कम कर सकते हैं
00:17:57और आपको लगता है कि आप वास्तव में उस तरह से
00:17:59उत्पादक नहीं हो पा रहे हैं।
00:18:00अब, जब आप GitHub पर एक ओपन सोर्स मेंटेनर होते हैं,
00:18:03तो आप AI द्वारा उत्पन्न इश्यूज और पुल रिक्वेस्ट के बोझ तले दब जाते हैं
00:18:07और आपके पास मुख्य रूप से दो विकल्प होते हैं।
00:18:09आप उन्हें अनदेखा कर सकते हैं और ज़ाहिर है कि यह उनके उद्देश्य को ही खत्म कर देता है,
00:18:13लेकिन स्पष्ट रूप से यह एक वैध रणनीति है।
00:18:16या आप उनके बीच से रास्ता बनाने की कोशिश करते हैं
00:18:18और आप थक कर चूर हो जाते हैं क्योंकि यह बहुत ज़्यादा है
00:18:21क्योंकि आपके अपने निजी डेवलपमेंट कार्य के विपरीत,
00:18:25आप आने वाले इश्यूज और पुल रिक्वेस्ट की संख्या को
00:18:29कम नहीं कर सकते।
00:18:30आप अपने स्वयं के कम एजेंटों का उपयोग कर सकते हैं
00:18:33यदि आपको लगता है कि आप उन सभी एजेंटों के साथ
00:18:36प्रभावी या उत्पादक नहीं हैं जिन्हें आप चलाने की कोशिश कर रहे हैं।
00:18:38आप सार्वजनिक रिपॉजिटरी के साथ ऐसा नहीं कर सकते।
00:18:41आप इसे नियंत्रित नहीं कर सकते कि कितने लोग AI जनित
00:18:45इश्यूज पोस्ट करेंगे या आपके साथ पुल रिक्वेस्ट साझा करेंगे।
00:18:49तो यह ओपन सोर्स मेंटेनर्स के लिए एक बहुत बड़ी समस्या है
00:18:53और यही कारण है कि पूरा ओपन सोर्स परिदृश्य
00:18:56और ओपन सोर्स के पीछे का दर्शन
00:18:59AI की वजह से अभी बहुत बड़ी समस्याओं में है।
00:19:04और GitHub इसमें कोई मदद नहीं कर रहा है।
00:19:06इसके बजाय, वे इसका उल्टा कर रहे हैं।
00:19:08वे सक्रिय रूप से AI द्वारा तैयार किए गए बेकार 'इश्यूज'
00:19:13को साझा करना और भी आसान बना रहे हैं।
00:19:15मेंटेनर्स और डेवलपर्स को जिस चीज़ की आवश्यकता होगी,
00:19:18वह इन सभी AI जनित इश्यूज और पुल रिक्वेस्ट से
00:19:22निपटने के लिए अधिक प्रभावी उपकरण होंगे।
00:19:25लेकिन GitHub उस पर काम नहीं कर रहा है।
00:19:27मुझे लगता है कि यह उनकी रणनीति का हिस्सा नहीं है।
00:19:29अब, शायद यह बदल जाए।
00:19:30GitHub की वह आधिकारिक पोस्ट जिसका मैंने पहले उल्लेख किया था
00:19:35मुख्य रूप से विश्वसनीयता और अपटाइम (uptime) समस्याओं के बारे में बात करती है
00:19:39और यह कि वे अधिक पारदर्शी होना चाहते हैं और इसी तरह।
00:19:41लेकिन उन्होंने यह भी उल्लेख किया कि उनकी एक प्रतिबद्धता
00:19:44डेवलपर्स का समर्थन करने की है।
00:19:46हम देखेंगे, मैं बहुत ज़्यादा सकारात्मक नहीं हूँ
00:19:49क्योंकि आखिरकार यह Microsoft का हिस्सा है
00:19:52और यहाँ उनकी अपनी बहुत ही अलग रणनीति है।
00:19:55लेकिन फिर GitHub के लिए इसका क्या मतलब है?
00:19:59क्या यहाँ से माइग्रेट करने का समय आ गया है?
00:20:02मैंने X (पूर्व में ट्विटर) पर यहाँ-वहाँ कुछ आवाजें सुनी हैं
00:20:05कि अब GitHub के विकल्प का समय आ गया है।
00:20:08मुझे पता है कि कुछ प्रोजेक्ट्स यहाँ से माइग्रेट कर चुके हैं।
00:20:12SIG शायद सबसे प्रमुख नामों में से एक है।
00:20:15वे नवंबर, 2025 में GitHub से Codeberg में माइग्रेट कर गए।
00:20:20लेकिन चलिए यहाँ व्यावहारिक बनते हैं।
00:20:22एक तो, जैसा कि मैंने पहले उल्लेख किया है,
00:20:24GitHub पर आने वाले ट्रैफ़िक की भारी मात्रा
00:20:28किसी भी प्रतिस्पर्धी को भी पस्त कर देगी।
00:20:31संभवतः GitHub से भी ज़्यादा
00:20:32क्योंकि वे Microsoft का हिस्सा नहीं हैं।
00:20:35इसलिए हम निश्चित रूप से GitHub को रिप्लेस होते हुए नहीं देखेंगे।
00:20:40और जबकि कुछ व्यक्तिगत प्रोजेक्ट्स,
00:20:42विशेष रूप से ओपन सोर्स प्रोजेक्ट्स GitHub छोड़ सकते हैं
00:20:45उन कारणों से जिन्हें मैं पूरी तरह से समझ सकता हूँ,
00:20:48वे सभी कंपनियां, वे सभी व्यक्तिगत डेवलपर्स
00:20:52संभवतः माइग्रेट नहीं करेंगे।
00:20:54GitHub के पास अपनी सभी समस्याओं के बावजूद,
00:20:57एक सुविधाओं से भरपूर प्लेटफ़ॉर्म है जिसमें ऐसी सुविधाएँ हैं जो
00:21:02कई डेवलपर्स के वर्कफ़्लो और दिन-प्रतिदिन के काम का अभिन्न अंग हैं।
00:21:06विशेष रूप से कंपनियों के लिए, निश्चित रूप से,
00:21:08GitHub को किसी अन्य प्रदाता के साथ
00:21:11बदलना आसान नहीं है।
00:21:13भले ही विश्वसनीयता की ये सभी समस्याएँ
00:21:15स्पष्ट रूप से कंपनियों के लिए भी बहुत बड़ी समस्याएँ हैं,
00:21:18वे माइग्रेट करने के बारे में सोचने से पहले
00:21:23कहीं ज़्यादा दर्द सहने में सक्षम और तैयार होंगे।
00:21:25मुझे इसका पूरा यकीन है।
00:21:26GitHub बस एक बहुत ही महत्वपूर्ण प्लेटफ़ॉर्म है।
00:21:30यह आपके Git प्रबंधित कोड को क्लाउड में रखने,
00:21:35उस पर काम करने और उस पर सहयोग करने का प्लेटफ़ॉर्म है।
00:21:39इसलिए मुझे यकीन है कि यह कहीं नहीं जा रहा है,
00:21:43भले ही स्थिति और भी खराब हो जाए।
00:21:45बेशक, अंततः लोग इसे छोड़ देंगे
00:21:47यदि GitHub कुछ भी नहीं कर रहा होता,
00:21:49लेकिन स्पष्ट रूप से वे कर रहे हैं,
00:21:50कम से कम अपटाइम और विश्वसनीयता की समस्याओं के संबंध में।
00:21:55जब ओपन सोर्स काम और वहाँ की समस्याओं
00:21:58और AI बेकार इश्यूज की बात आती है, तो हम देखेंगे।
00:22:01वहाँ भी, मेरा मानना है कि GitHub बहुत महत्वपूर्ण है
00:22:07और ओपन सोर्स मेंटेनर्स के लिए इसके इतने फायदे हैं
00:22:10कि वे बस इसे छोड़ नहीं सकते, कम से कम वे सभी तो नहीं।
00:22:14लेकिन मैं निश्चित रूप से समझता हूँ कि यदि व्यक्तिगत प्रोजेक्ट्स
00:22:17GitHub से दूर चले जाते हैं, तो ऐसा हो सकता है।
00:22:20लेकिन हाँ, कंपनियों और सामान्य रूप से GitHub के लिए,
00:22:23यह बना रहेगा।
00:22:24फिर भी, कोई केवल यही आशा कर सकता है कि यह स्थिति
00:22:28शायद Microsoft के लिए एक चेतावनी (wake up call) हो।
00:22:33शायद वे GitHub के लिए फिर से किसी CEO को कार्यभार सौंपें।
00:22:38वे शायद इसके महत्व को समझते हैं।
00:22:41वे शायद यह समझते हैं कि यह एक डेवलपर
00:22:45और डेवलपमेंट प्लेटफ़ॉर्म है, न कि मुख्य रूप से एक AI प्लेटफ़ॉर्म।
00:22:49लेकिन हाँ, उम्मीद की जा सकती है।
00:22:52मुझे नहीं पता कि ऐसा कब और होगा भी या नहीं।
00:22:55लेकिन हाँ, यह GitHub की वर्तमान स्थिति है।
00:23:00यह खराब है, यह वास्तव में खराब है।
00:23:03और यह निकट भविष्य के लिए खराब ही रहेगी,
00:23:06लेकिन कम से कम विश्वसनीयता उम्मीद है कि बेहतर हो जाएगी
00:23:11इस साल के अंत तक।
00:23:13मुझे लगता है कि हम देखेंगे।