7 पॉइंट द्वारा baeba 3 시간 전 | 4 टिप्पणियां | WhatsApp पर शेयर करें

SQLite के निर्माता के अनुसार, 26 वर्षों की सफलता का राज अपने ज़रूरी tools खुद बनाना, बाहरी योगदान को न्यूनतम रखना, और कठोर testing के ज़रिए code quality बनाए रखना है।
यह जटिल open source ecosystem में अक्सर नज़रअंदाज़ किए जाने वाले ‘स्वतंत्रता’ के असली अर्थ को दिखाता है।


विषय सूची

  1. SQLite के निर्माता, Richard Hipp की 26 वर्षीय code यात्रा


1. SQLite के निर्माता, Richard Hipp की 26 वर्षीय code यात्रा

SQLite के निर्माता Richard Hipp ने 26 वर्षों की code development यात्रा में निम्नलिखित दर्शन को अपनाया है।

  • अपने लिए ज़रूरी tools खुद विकसित करना।
  • बाहरी code contribution को न्यूनतम रखना।
  • कठोर testing के ज़रिए code quality बनाए रखना।
  • बाहरी dependencies कम करके development की स्वतंत्रता सुनिश्चित करना।

1.1. SQLite की शुरुआत: युद्धपोत से शुरू हुआ समस्या-समाधान

युद्धपोत project से शुरू हुआ SQLite

  • SQLite की शुरुआत युद्धपोत USS Oscar Austin से जुड़े contract work से हुई।
  • उस समय Richard Hipp, General Dynamics के contractor के रूप में Bath Iron Works के DDG-79 जहाज़ निर्माण project में शामिल थे।
  • जहाज़ के damage control information system के development में समस्या आ गई थी।
  • दूसरी कंपनी ने लाखों डॉलर निवेश किए थे, लेकिन वह ठीक-ठाक परिणाम नहीं दे पाई थी।

मौजूदा database systems की सीमाएँ

  • Richard Hipp ने damage control system की समस्या हल करने के लिए तेज़ heuristic-आधारित software विकसित किया।
  • लेकिन data storage के लिए इस्तेमाल हो रहा Informix database engine बंद हो जाए तो software भी साथ में काम करना बंद कर देता था।
  • system administrator के database engine रोक देने पर भी software को चलते रहना चाहिए था।
  • इसी वजह से उन्होंने अलग database process के बिना application द्वारा disk के data को सीधे पढ़ने के तरीके पर विचार किया।
  • उस समय ऐसी ज़रूरत पूरी करने वाला SQL database engine ढूँढना कठिन था, इसलिए उसे खुद बनाना पड़ा।

self-study से शुरू हुआ relational database शोध

  • उस समय internet search आज की तरह आम नहीं था।
  • Richard Hipp ने स्थानीय university library में संबंधित सामग्री खोजकर relational database तकनीक का अध्ययन किया।
  • उस समय MIT, Harvard, Berkeley आदि में relational database पर सक्रिय शोध चल रहा था।
  • लेकिन भौगोलिक सीमाओं के कारण नवीनतम research जानकारी आसानी से मिल नहीं पाती थी।
  • आखिरकार उन्हें ज़रूरी database technology खुद ही पढ़कर लागू करनी पड़ी।

1.2. SQLite की वृद्धि और व्यावसायिक सफलता

बिना revenue उद्देश्य के शुरू हुआ project

  • SQLite शुरू से monetization के उद्देश्य से विकसित किया गया software नहीं था।
  • शुरुआती version को free software के रूप में जारी किया गया।
  • development के समय इसके ज़रिए business करने या revenue कमाने की कोई योजना नहीं थी।

Motorola के साथ पहला commercial contract

  • SQLite के public होने के कुछ वर्षों बाद mobile phone निर्माता Motorola ने संपर्क किया।
  • Motorola SQLite को अपने mobile phones में शामिल करना चाहती थी।
  • इसी से SQLite का पहला commercial contract हुआ।
  • यह contract usage-based licensing की बजाय fixed-price model पर हुआ।

AOL के साथ सहयोग

  • इसके बाद America Online(AOL) ने भी CD-ROM package में SQLite शामिल करने के लिए contract किया।
  • यह contract भी fixed-price model पर हुआ।
  • Richard Hipp के अनुसार, उस समय contract amount SQLite की value की तुलना में अपेक्षाकृत कम था।

Symbian OS द्वारा SQLite का चयन

  • Nokia आदि के phones में इस्तेमाल होने वाले Symbian OS ने database engine चुनने के लिए blind test किया।
  • कुल 10 database engines का मूल्यांकन किया गया।
  • test के परिणामस्वरूप SQLite को अंतिम रूप से चुना गया।
  • इस प्रक्रिया में यह चिंता उठी कि SQLite एक ही मुख्य developer पर बहुत अधिक निर्भर है।
  • तथाकथित bus factor बढ़ाने के लिए consortium बनाने का सुझाव दिया गया।

bus factor
यह एक metric है जो बताता है कि यदि project के कुछ मुख्य लोग अचानक काम करने में सक्षम न रहें, तो क्या project जारी रह सकता है।
bus factor 1 होने का मतलब है कि एक मुख्य developer के हटने पर project को बनाए रखना कठिन हो सकता है।

consortium की स्थापना और full-time development

  • Mozilla की Mitchell Baker ने consortium स्थापना पर सलाह दी।
  • इसके आधार पर SQLite consortium बनाया गया।
  • consortium बनने के बाद Richard Hipp ने SQLite development को full-time काम के रूप में करना शुरू किया।
  • कई कर्मचारियों को नियुक्त करके उन्होंने छोटा लेकिन sustainable development organization चलाना शुरू किया।

2050 तक long-term support की योजना

  • 2010 में Airbus, A350 aircraft project के avionics में SQLite का उपयोग करना चाहता था।
  • Airbus ने पूछा कि क्या SQLite को लंबे समय तक maintain और support किया जा सकेगा।
  • aircraft fuselage की लगभग 40 वर्ष की lifespan को देखते हुए long-term support का वादा किया गया।
  • यह वादा कानूनी बाध्यता से अधिक SQLite project के long-term goal के करीब था।
  • वर्तमान में Richard Hipp ने SQLite के लिए अपना व्यक्तिगत support end goal 2050 तय किया है।
  • यह लक्ष्य इस विचार पर आधारित है कि code को data की अपेक्षित उम्र से भी अधिक समय तक बनाए रखा जाए, यानी तथाकथित ‘data-first code’ में 50 वर्ष जोड़ने का तरीका

1.3. लाइसेंस, open source दर्शन, और अपने tools का विकास

‘प्रार्थना’ license की शुरुआत

  • SQLite version 1, GDBM library पर निर्भर था।
  • चूँकि GDBM GPL license का उपयोग करती थी, इसलिए SQLite भी GPL के प्रभाव से मुक्त नहीं रह सकता था।
  • बाद में range query support के लिए B-tree आधारित अपना storage backend विकसित किया गया।
  • बाहरी library dependency हटने के बाद license को स्वतंत्र रूप से चुनना संभव हो गया।

Public Domain का चयन

  • उस समय MIT और Berkeley license जैसे कुछ ही licenses व्यापक रूप से जाने जाते थे।
  • Richard Hipp ने जटिल कानूनी clauses वाले license की बजाय SQLite को Public Domain के रूप में जारी किया।
  • बाद में उन्हें पता चला कि Public Domain की अवधारणा हर देश में समान रूप से मान्य नहीं मानी जाती।
  • फिर भी SQLite की public release policy व्यवहार में open source license जैसी ही स्वीकार की जाती है।

‘प्रार्थना-पंक्ति’

SQLite source code के header में सामान्य कानूनी language के बजाय आशीर्वाद या प्रार्थना जैसी पंक्तियाँ शामिल की गईं।

May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.

SQLite दुनिया की सबसे व्यापक रूप से उपयोग होने वाली software libraries में से एक बन गई, और यह पंक्ति भी उसके विशिष्ट license दर्शन का प्रतीक बन गई।

बाहरी योगदान को न्यूनतम रखने की development शैली

  • SQLite सामान्य open source projects की तरह pull requests सक्रिय रूप से स्वीकार नहीं करता।
  • बाहरी contributions को न्यूनतम रखते हुए core development team खुद code लिखती और manage करती है।
  • Richard Hipp pull requests की तुलना ‘free puppy’ से करते हैं।
  • जैसे free में puppy लेने पर भी बाद में उसकी देखभाल और ज़िम्मेदारी उठानी पड़ती है, वैसे ही बाहरी code लेने पर ये long-term responsibilities आती हैं।
    • code maintenance
    • testing
    • documentation
    • bug fixes
    • दूसरे platforms के साथ compatibility management
    • long-term technical responsibility
  • बाहरी contribution को सीमित रखने का यह तरीका SQLite को 26 वर्षों से अधिक समय तक एकसमान quality और दिशा बनाए रखने में मदद करने वाले कारणों में से एक है।

अपने tools के development के उदाहरण

Fossil
  • Fossil SQLite project को manage करने के लिए बनाया गया अपना version control system है।
  • इसे Git के लगभग उसी समय विकसित किया गया था।
  • source code management के अलावा यह निम्न सुविधाएँ integrated रूप में देता है।
    • version control
    • issue tracking
    • wiki
    • forum
    • web interface
  • Fossil खुद SQLite पर आधारित है।
  • इसलिए Fossil, SQLite के लिए एक वास्तविक beta test platform की भूमिका भी निभाता है।
  • Fossil के development और operation के दौरान application developer के नज़रिए से SQLite की कमियों की पहचान और सुधार संभव हुआ।
  • Richard Hipp का मानना है कि Git, Linux kernel जैसे बड़े distributed projects के लिए उपयुक्त है, जबकि SQLite जैसे छोटे projects के लिए Fossil अधिक उपयुक्त है।
Lemon
  • Lemon SQLite का SQL parser generate करने के लिए विकसित किया गया tool है।
  • Yacc या Bison का उपयोग करने के बजाय इसे खुद बनाया गया।
  • अपना tool होने के कारण SQLite की ज़रूरतों के अनुसार parser generation तरीके को स्वतंत्र रूप से बेहतर बनाया जा सका।

अपने tools और स्वतंत्रता का दर्शन

  • Richard Hipp के लिए अपने tools बनाना सिर्फ तकनीकी पसंद नहीं है।
  • उनके अनुसार, अपने लिए ज़रूरी tool खुद बनाना स्वयं की देखभाल करने जैसा है।
  • बाहरी dependencies कम करने से दूसरे projects या कंपनियों के फ़ैसलों का असर कम पड़ता है।
  • उनका मानना है कि यही स्वतंत्रता developer की freedom को बढ़ाती है।
  • हालांकि SQLite के दुनिया भर के अनगिनत systems में एक core dependency के रूप में इस्तेमाल होने की स्थिति को लेकर वे दबाव और चिंता भी महसूस करते हैं।

1.4. कठोर testing और AI युग में software development

SQLite की सफलता का मुख्य आधार: testing

  • SQLite लंबे समय तक stable रह सका, इसका एक मुख्य कारण बेहद कठोर testing है।
  • SQLite development team सिर्फ features के काम करने की पुष्टि तक सीमित नहीं रहती, बल्कि कई exceptional situations और platforms को भी verify करती है।
  • testing को इतना महत्व दिया जाता है कि test code की मात्रा वास्तविक product code से कहीं अधिक है।

DO-178B standard का उपयोग

  • SQLite development team ने aircraft software development standard DO-178B की पद्धति को testing में लागू किया।
  • इसके माध्यम से test coverage को व्यवस्थित रूप से बढ़ाया गया।
  • Android development के शुरुआती चरण में DO-178B स्तर की test coverage हासिल करने के बाद bug reports लगभग गायब हो गईं।
  • इस अनुभव से यह स्पष्ट हुआ कि कठोर testing वास्तव में software stability को सीधे बेहतर बनाती है।

fuzzing से नए bugs की खोज

  • बाद में profile-guided fuzzing तकनीक सामने आई।
  • fuzzing वह तरीका है जिसमें random या mutated data को program में input देकर अप्रत्याशित errors खोजे जाते हैं।
  • DO-178C स्तर की testing से भी पकड़ में न आने वाले नए प्रकार के bugs fuzzing से मिले।
  • इससे पता चलता है कि सिर्फ उच्च test coverage से सभी errors नहीं मिलते।

AI द्वारा खोजे गए bugs

  • हाल के समय में AI का उपयोग bug खोजने या bug reports लिखने के लिए भी होने लगा है।
  • SQLite project को भी ऐसे bug reports मिले हैं जिनके AI-जनित होने का संदेह था।
  • AI, मौजूदा testing और fuzzing को पूरक करने वाला नया software verification tool बन सकता है।

AI पर Richard Hipp का मूल्यांकन

  • Richard Hipp कहते हैं कि AI के बारे में उनकी राय रोज़ बदल सकती है।
  • फिलहाल वे AI को बहुत उपयोगी tool की तरह इस्तेमाल कर रहे हैं।
  • उन्होंने अनुभव साझा किया कि जब उन्होंने ChatGPT से SQLite code के बारे में सवाल किया, तो AI ने उन्हें इस तरह जवाब दिया।

“बेशक, आपको भी पता होगा…”

  • उन्होंने बताया कि अपने ही लिखे code के बारे में AI का ऐसे बात करना, मानो वह उनसे अधिक जानता हो, थोड़ा डरावना लगा।
  • AI जानकारी खोजने और ideas पाने में उपयोगी है।
  • लेकिन यह हमेशा सही नहीं होता और बहुत विश्वास पैदा करने वाली भाषा में ग़लत जानकारी भी दे सकता है।
  • AI-जनित code में compatibility issues भी आए, जैसे किसी एक operating system पर चलना लेकिन दूसरे पर न चलना।
  • इसलिए AI द्वारा बनाए गए output की भी इंसानों को सीधे review और सुधार करना चाहिए।

युवा developers के लिए सलाह

  • Richard Hipp SQLite को fork करके बेहतर database बनाने की कोशिशों का स्वागत करते हैं।
  • लेकिन वे ज़ोर देकर कहते हैं कि SQLite जैसे स्तर तक पहुँचने के लिए निम्न तत्व आवश्यक हैं।
    • 25 वर्षों से अधिक का सतत development
    • एक विषय के प्रति अडिग समर्पण
    • लंबे समय तक testing और improvement
    • user needs का सतत अवलोकन
    • बार-बार असफल होकर अर्जित अनुभव
  • बेहतरीन software कम समय में नहीं बनता।
  • उनका मानना है कि AI के कारण software development का तरीका बहुत बदल सकता है, लेकिन भविष्य कैसा होगा यह आसानी से अनुमान लगाना मुश्किल है।

1.5. SQLite की sustainability और मानवीय पक्ष

26 वर्षों तक टिके रहने का कारण

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

छोटी team के फायदे

  • Richard Hipp कहते हैं कि वे बहुत से लोगों के साथ घुलने-मिलने या संगठन के भीतर political relationships manage करने में कुशल नहीं हैं।
  • इसी स्वभाव के कारण उन्होंने SQLite development team को छोटा रखा।
  • परिणामस्वरूप, उनका मानना है कि छोटी team structure ने SQLite की consistent direction और तेज़ decision-making में मदद की।
  • वे स्वीकार करते हैं कि Linux के Linus Torvalds की तरह अनगिनत developers के साथ संबंधों का समन्वय करने की क्षमता उनमें नहीं है।

पत्नी Ginger के साथ company चलाना

  • Richard Hipp अपनी पत्नी Ginger के साथ company चलाते हैं।
  • दोनों परिस्थिति के अनुसार एक-दूसरे की roles बदलते हुए लचीला teamwork बनाए रखते हैं।
  • Ginger एक musician हैं और computer समस्याओं से जूझ रहे दूसरे musicians की मदद करने में निपुण हैं।
  • Richard Hipp मज़ाक में कहते हैं कि स्थानीय community में Ginger उनसे अधिक प्रसिद्ध हैं।

software development का मानवीय पक्ष

  • Richard Hipp software को सिर्फ code या technology का संग्रह नहीं मानते।
  • वे ज़ोर देते हैं कि developer की भावनाएँ, सहयोगी संबंध, जुनून, असफलताएँ और उपलब्धि की भावना जैसे मानवीय तत्व software development में महत्वपूर्ण हैं।
  • software भले ही जटिल और abstract outcome हो, लेकिन उसके पीछे उसे बनाने वाले लोगों की कहानियाँ होती हैं।

अनुशंसित पुस्तक: 《The Soul of a New Machine》

  • Richard Hipp software और computer development के मानवीय पक्ष को समझने के लिए 《The Soul of a New Machine》 की सिफारिश करते हैं।
  • यह पुस्तक केवल computer technology की व्याख्या नहीं करती।
  • यह एक नए computer के development की प्रक्रिया में सामने आने वाले निम्न पहलुओं को भी संबोधित करती है।
    • developers का जुनून
    • organization के भीतर conflicts
    • technical challenges
    • असफलता और निराशा
    • collaboration और competition
    • creation process में भावनाएँ
  • वे ज़ोर देते हैं कि जटिल technology को गहराई से समझते हुए उसे मानवीय कहानी के रूप में प्रस्तुत करने की क्षमता महत्वपूर्ण है।

निष्कर्ष

SQLite 26 वर्षों से अधिक समय तक सफलतापूर्वक बना रहा, इसका कारण सिर्फ उत्कृष्ट तकनीकी क्षमता नहीं है।

मुख्य सफलता-कारकों को इस प्रकार संक्षेपित किया जा सकता है।

  1. वास्तविक समस्याओं को हल करने के लिए ज़रूरी technology खुद विकसित की गई।
  2. बाहरी dependencies कम करके project पर नियंत्रण बनाए रखा गया।
  3. बाहरी contribution से अधिक long-term maintenance responsibility को महत्व दिया गया।
  4. Fossil और Lemon जैसे ज़रूरी tools खुद बनाए गए।
  5. aircraft software स्तर की कठोर testing लागू की गई।
  6. AI और नई development technologies का उपयोग किया गया, लेकिन output पर अंधविश्वास नहीं किया गया।
  7. छोटी team और मानवीय संबंधों के आधार पर project चलाया गया।
  8. एक ही विषय में लंबे समय तक दृढ़ता से डूबे रहे।

SQLite का उदाहरण यह दिखाता है कि स्वतंत्रता का अर्थ बिना किसी बंधन की स्थिति नहीं, बल्कि अपने इस्तेमाल के tools और code के लिए स्वयं ज़िम्मेदारी लेने और उन पर नियंत्रण रखने की स्थिति है।

बाहरी dependencies कम करना, ज़रूरी tools खुद बनाना, और कठोर validation करना—SQLite की development शैली तेज़ी से बदलते AI युग में भी sustainable software development क्या होता है, इसका एक महत्वपूर्ण उदाहरण है।

4 टिप्पणियां

 
regentag 1 시간 전

RTCA का Do-178 इतना छोटा दिशानिर्देश है कि इसे सच में पढ़कर लागू करना संभव है। यह विमानन उद्योग में व्यापक रूप से लागू होता है.

https://studylib.net/doc/27132454/rtca-do-178b

 
hmmhmmhm 2 시간 전

"25 साल से ज़्यादा का लगातार development" वाकई बहुत शानदार है...

 
cnaa97 2 시간 전

कमाल है.. थोड़ा फ़िल्म जैसा भी लगता है

 
toida 3 시간 전

इनका माइंडसेट बहुत शानदार है