खतरा इस्तीफे के पत्र से शुरू नहीं होता। यह उससे हफ्तों पहले शुरू होता है, जब इंजीनियर अभी भी हर रिपॉज़िटरी में लॉग इन है, अभी भी डिज़ाइन दस्तावेज़ों तक पूरी पहुंच रखता है, और पहले से ही आगे की सोच रहा है। यह समय शांत है, कोई अलार्म नहीं बजाता, और एक साधारण मंगलवार जैसा दिखता है। यही वह पल भी है जब एक स्टार्टअप उस सबसे स्पष्ट रिकॉर्ड को खो देता है कि वास्तव में किसने क्या बनाया।
दरवाज़े से असल में क्या बाहर जाता है
शायद ही कभी यह तैयार उत्पाद होता है। प्रोडक्शन रिपॉज़िटरी आमतौर पर ठीक होती है: उसका कमिट इतिहास है, एक असली चेंजलॉग है, और एक से अधिक लोग उसकी पुष्टि कर सकते हैं। जो गायब होता है वह इसके आसपास की हर चीज़ है। एक निजी रिपॉज़िटरी जो किसी शुरुआती प्रोटोटाइप के लिए बनाई गई थी, इससे पहले कि "असली" रिपॉज़िटरी बनी भी हो। एक डिज़ाइन दस्तावेज़ जो निजी ईमेल में चिपकाया गया क्योंकि उस दिन Slack काम नहीं कर रहा था। एक ब्रांच जिसे किसी ने मर्ज नहीं किया क्योंकि फ़ीचर टाल दिया गया था, लेकिन जिसमें अब भी उस विचार का पहला काम करने वाला संस्करण मौजूद है जिसे कंपनी ने बाद में किसी और नाम से लॉन्च किया। जब तक व्यक्ति टीम में है, इनमें से कुछ भी महत्वपूर्ण नहीं लगता। जिस दिन वह टीम में नहीं रहता, यह सब विवाद का विषय बन जाता है।
कोई तकनीकी सह-संस्थापक जो मतभेद के बाद चला जाता है, इस समस्या का सबसे तीखा रूप है। दो लोग एक ही छह महीनों को पूरी तरह अलग-अलग तरीके से याद रख सकते हैं, और एक बार रिश्ता टूट जाने पर, यह साझा विवरण नहीं बचता कि किसने कौन सी लाइन पहले लिखी, किसका स्केच आर्किटेक्चर बना, या किसी विचार ने वास्तव में कब आकार लिया। जो बचता है वह याददाश्त के खिलाफ याददाश्त है, और यह सबूत नहीं है।
यह सिर्फ संस्थापकों तक सीमित नहीं है। एक कॉन्ट्रैक्टर जिसने पूर्णकालिक नियुक्त होने से पहले किसी फ़ीचर का पहला संस्करण बनाया। एक इंटर्न जिसका गर्मियों का प्रोजेक्ट चुपचाप उत्पाद का एक केंद्रीय हिस्सा बन गया। एक फ्रीलांसर जिसने मूल आर्किटेक्चर डायग्राम बनाया। ये सभी पीछे वैसा ही अंतर छोड़ जाते हैं, आमतौर पर बिना किसी के ध्यान दिए, जब तक कोई विवाद किसी को ऐसा सबूत खोजने पर मजबूर नहीं करता जो कभी सहेजा ही नहीं गया था।
"बड़े पड़ावों पर" सील करना यह अंतर खुला क्यों छोड़ता है
ज़्यादातर तकनीकी टीमें जो इस बारे में सोचती भी हैं, गलत समय पर सोचती हैं। एक रिलीज़ को टैग किया जाता है। एक अनुबंध पर हस्ताक्षर होते हैं। यही सील होता है, अगर कुछ सील होता भी है। वह खोजी ब्रांच जिसने रिलीज़ को आकार दिया, वह शुरुआती प्रोटोटाइप जिसने साबित किया कि विचार वाकई संभव था, वह आंतरिक डिज़ाइन दस्तावेज़ जिस पर रिलीज़ वास्तव में आधारित है: इन सबको शायद ही कभी वही ध्यान मिलता है, क्योंकि जब लोग साथ मिलकर कोड लिख रहे होते हैं, तब कोई किसी के जाने के बारे में नहीं सोच रहा होता। यह ठीक उल्टा है। सबसे कमज़ोर दस्तावेज़ी निशान वाली सामग्री वही होती है जिसकी सबसे स्पष्ट याद जाने वाले इंजीनियर को होती है, और अक्सर उसका श्रेय लेने की सबसे मज़बूत प्रवृत्ति भी उसी में होती है।
निरंतर सीलिंग असल में क्या स्थापित करती है
समाधान कोई बड़ी कानूनी टीम नहीं है। यह सीलिंग को तकनीकी काम को सहेजने के सामान्य हिस्से की तरह मानना है, न कि लॉन्च और हस्ताक्षरों के लिए आरक्षित किसी कदम की तरह। व्यवहार में इसका मतलब है एक आदत जो मुख्य ब्रांच में मर्ज करने जितनी ही सामान्य हो: सोर्स कोड को केवल रिलीज़ पर नहीं बल्कि नियमित अंतराल पर सील करना, डिज़ाइन दस्तावेज़ को उस दिन सील करना जिस दिन वह टीम के साथ साझा किया जाता है न कि जिस दिन वह अंतिम रूप लेता है, और शुरुआती प्रोटोटाइप को उसी हफ्ते सील करना जब वह पहली बार चलता है, महीनों बाद नहीं, अगर तब भी हो। इनमें से कुछ भी यह याद रखने पर निर्भर नहीं करता कि कोई विदाई कभी हो सकती है। इसे बस पहले से ही टीम के काम करने का तरीका होना चाहिए। eIDAS के अनुच्छेद 41 के तहत, एक योग्य इलेक्ट्रॉनिक टाइमस्टैंप उस तारीख़ और समय की सटीकता की धारणा रखता है जो वह दर्ज करता है, साथ ही उस डेटा की अखंडता की भी जिसे वह कवर करता है। स्विट्ज़रलैंड में, ZertES-मान्यता प्राप्त प्रदाता के ज़रिए जारी हस्ताक्षर वही कानूनी वज़न रखता है जो एक हस्तलिखित हस्ताक्षर का होता है। इनमें से कोई भी ढांचा इस बात की परवाह नहीं करता कि जब अंततः कोई विवाद सामने आता है तब कौन अब भी कार्यरत है। दोनों इस बात की परवाह करते हैं कि क्या दर्ज हुआ और कब, और यही वह हिस्सा है जो इस बात पर निर्भर नहीं करता कि कहानी कौन सुना रहा है।
दो संस्थापकों की कल्पना करें जो साथ मिलकर किसी उत्पाद का पहला काम करने वाला संस्करण बनाते हैं, और फिर अठारह महीने बाद बुरी तरह अलग हो जाते हैं। अगर शुरुआती प्रोटोटाइप और उससे जुड़ा डिज़ाइन दस्तावेज़ उसी हफ्ते सील किया गया था जब वे लिखे गए थे, तो एक तारीख़ी, छेड़छाड़-रहित रिकॉर्ड मौजूद है, जो दोनों में से किसी की भी याददाश्त या मौजूदा रिश्ते से स्वतंत्र है। अगर ऐसा नहीं हुआ, तो विवाद इस पर आ टिकता है कि कौन ज़्यादा विश्वसनीय लगता है, और यह ऐसी स्थिति है जिसमें किसी भी संस्थापक को नहीं रहना चाहिए।
यह क्या नहीं करता
सीलिंग किसी रोज़गार अनुबंध या बौद्धिक-संपदा-हस्तांतरण खंड का विकल्प नहीं है, और यह अपने आप कोई विवाद तय नहीं करती। किसी कंपनी को फिर भी वे बुनियादी समझौते चाहिए जो सबसे पहले यह तय करते हैं कि काम के नतीजे पर मालिकाना हक किसका है। सीलिंग जो जोड़ती है वह वह सबूती रिकॉर्ड है जिसकी किसी विवाद को उन समझौतों के मौजूद होने के बाद वास्तव में ज़रूरत होती है: यह प्रमाण कि क्या मौजूद था, किस रूप में, और कब, जिसे कोई भी पक्ष रिश्ता खत्म होने के बाद चुपचाप नहीं बदल सकता।
इसे विदाई से पहले आदत बनाएं, बाद में नहीं
जब तक कोई नोटिस देता है, तब तक सबसे महत्वपूर्ण काम को सील करना शुरू करने में पहले ही देर हो चुकी होती है। जो स्टार्टअप इस झगड़े से बचते हैं वे वही हैं जिन्होंने शुरू से ही सीलिंग को अपने तकनीकी काम को सहेजने के तरीके का हिस्सा बनाया, ठीक वैसे ही जैसे उन्होंने वर्ज़न कंट्रोल को उसे लिखने के तरीके का हिस्सा बनाया। अगली विदाई, चाहे योजनाबद्ध हो या न हो, इस सवाल को ज़रूरी बनाए इससे पहले देखें कि यह सॉफ़्टवेयर और आईपी टीमों के लिए कैसे काम करता है।
