सभी नाय-कहने वालों के विपरीत, चलो मान लेते हैं कि वास्तविक व्यापार की आवश्यकता है।
(उदाहरण के लिए, वितरण योग्य स्रोत कोड है, ग्राहक व्यवसाय की एक ही पंक्ति से हैं और इसलिए एक-दूसरे के प्रतिस्पर्धी हैं, और आप व्यवसाय मॉडल अपने रहस्यों को गुप्त रखने का वादा करते हैं)
इसके अलावा, मान लें कि आपकी कंपनी के पास सभी शाखाओं को बनाए रखने के लिए उपकरण हैं, जो या तो मैनपावर है ( मान लीजिए कि 100 डेवलपर्स विलय के लिए समर्पित हैं, 5-दिवसीय रिलीज में देरी के लिए समर्पित है, या 10 -दिवसीय रिलीज के लिए 10 दिन मानने वाले लैग ठीक है), या; इस तरह के भयानक स्वचालित परीक्षण जो स्वचालित रूप से प्रत्येक शाखा में कोर कल्पना और विस्तार कल्पना दोनों के लिए सही मायने में परीक्षण किए जाते हैं , और इस प्रकार केवल ऐसे परिवर्तन जो "स्वच्छ" विलय नहीं करते हैं उन्हें मानव हस्तक्षेप की आवश्यकता होती है। यदि आपके ग्राहक न केवल कस्टमाइज़ेशन के लिए, बल्कि उसके रखरखाव के लिए भुगतान करते हैं, तो यह एक मान्य व्यवसाय मॉडल हो सकता है।
मेरा (और ने-कहने वालों का) सवाल है, क्या आपके पास प्रत्येक ग्राहक को वितरण के लिए एक समर्पित व्यक्ति है ? यदि आप कहते हैं, 10,000-व्यक्ति कंपनी है, तो यह मामला हो सकता है।
इसे कुछ मामलों में प्लगइन आर्किटेक्चर द्वारा नियंत्रित किया जा सकता है, मान लीजिए कि आपका कोर ट्रंक है, प्लगइन्स को ट्रंक या शाखाओं में रखा जा सकता है, और प्रत्येक ग्राहक के लिए कॉन्फ़िगरेशन या तो विशिष्ट नाम वाली फ़ाइल है या ग्राहक शाखा में आयोजित की जाती है।
प्लगइन्स को रन टाइम पर लोड किया जा सकता है, या कंपाइल टाइम में बनाया जा सकता है।
सचमुच कई परियोजनाएं इस तरह से की जाती हैं, मौलिक रूप से एक ही समस्या अभी भी लागू होती है - सरल कोर परिवर्तन एकीकृत करने के लिए तुच्छ होते हैं, संघर्ष परिवर्तनों को या तो वापस रोल किया जाना चाहिए, या कई प्लगइन्स में परिवर्तन की आवश्यकता है।
ऐसे मामले होते हैं जब प्लगइन्स पर्याप्त अच्छे नहीं होते हैं, यही कारण है कि कोर के इतने सारे इंटर्नल को ट्वीक किया जाना चाहिए कि प्लगइन इंटरफ़ेस गिनती को संभालने के लिए बहुत बड़ी हो जाती है।
आदर्श रूप से इसे पहलू-उन्मुख प्रोग्रामिंग द्वारा नियंत्रित किया जाएगा , जहां ट्रंक कोर कोड है, और शाखाएं पहलू हैं (अतिरिक्त कोड और निर्देश हैं कि एक्सट्रा को कोर से कैसे जोड़ा जाए)
एक सरल उदाहरण, आप निर्दिष्ट कर सकते हैं कि कस्टम fooकोर से पहले या बाद में चलाया गया है klass.fooया यह इसे बदल देता है, या जो इसे लपेटता है और इनपुट या आउटपुट को बदल सकता है।
इसके लिए पुस्तकालयों का एक टन है, हालांकि मर्ज संघर्षों की समस्या दूर नहीं होती है - स्वच्छ मर्जों को एओपी द्वारा नियंत्रित किया जाता है और संघर्षों को अभी भी मानवीय हस्तक्षेप की आवश्यकता है।
अंत में इस तरह के व्यवसाय को वास्तव में शाखा रखरखाव के साथ खुद को चिंतित करना पड़ता है , अर्थात्, ग्राहक-विशिष्ट सुविधा एक्स इतना सामान्य है कि इसे कोर में स्थानांतरित करना सस्ता है, भले ही सभी ग्राहक इसके लिए भुगतान न कर रहे हों?