InnerSource একটি মিথ্যা - সাধারণ ভুল ধারণার প্রতিক্রিয়া
যখন আপনি YouTube-এ “InnerSource” অনুসন্ধান করেন, আপনি সম্ভবত প্রথম যে ফলাফলগুলির মুখোমুখি হবেন তার মধ্যে একটি হল এমন একটি ভিডিও যা দাবি করে যে “InnerSource একটি মিথ্যা।”
(লিংক: https://youtube.com/shorts/53jEP3mPP3E)
এই দৃষ্টিভঙ্গি একটি সাধারণ ফাঁদের প্রতিনিধিত্ব করে যেখানে অনেক মানুষ পড়ে যায় যখন তারা প্রথম InnerSource সম্পর্কে জানে।
আমি এই ভিডিওটিকে একটি কেস স্টাডি হিসেবে ব্যবহার করতে চাই যাতে ব্যাখ্যা করা যায় এটি কী ধরনের বিভ্রান্তিকর সিদ্ধান্তের প্রচার করে। এটি একটি ভুল যা আমি অতীতেও করেছি, এবং এটি একটি ফাঁদ যেখানে অনেক মানুষ সহজেই পড়তে পারে যারা এই ক্ষেত্রটি গভীরভাবে অন্বেষণ করেনি। এই কারণেই আমি আত্ম-প্রতিফলনের সাথে এটি পরীক্ষা করতে চাই এবং এই ফাঁদগুলি উন্মোচন করে অন্যদের সঠিক পথ খুঁজে পেতে সাহায্য করতে চাই।
প্রথম ভুল ধারণা: “React ব্যবহার করুন যাতে অন্যরা অবদান রাখতে পারে” #
আমি প্রথমে এই ক্ষেত্রে যুক্তিটি বিশ্লেষণ করি। ভিডিওটি অভ্যন্তরীণ অ্যাপ্লিকেশনের জন্য React ব্যবহার করার পরামর্শ দেয় “React ব্যবহার করুন কারণ অন্য মানুষ এতে অবদান রাখতে পারে।” এই ধরনের যুক্তি প্রকৃত InnerSource আলোচনায় খুব কমই শোনা যায়।
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
এই যুক্তিটি তিনটি মূল সমস্যায় বিভক্ত করা যেতে পারে:
- InnerSource আসলে কী বোঝায় তার মৌলিক ভুল বোঝাবুঝি
- InnerSource প্রয়োগের জন্য ভুল ডোমেইন নির্বাচন
- ব্যক্তিগত বনাম দলীয় দৃষ্টিভঙ্গির বিভ্রান্তি
InnerSource আসলে কী বোঝায় #
InnerSource হল একটি কোম্পানির মধ্যে ওপেন সোর্স নীতিগুলি অনুশীলন করা। এটি শুধুমাত্র “অবদান রাখা” বা “অবদান গ্রহণ করা” সম্পর্কে নয়।
বেশিরভাগ মানুষ যারা ওপেন সোর্সের সাথে ইন্টারঅ্যাক্ট করে তারা কেবল “ব্যবহারকারী।” কেউ কেউ শুধু ভোক্তা, অন্যরা বাগ রিপোর্ট ফাইল করে, এবং শুধুমাত্র একটি ছোট অংশ আসলে পুল রিকোয়েস্ট জমা দেয়। InnerSource ওপেন সোর্স শিক্ষাগুলি অভ্যন্তরীণভাবে প্রয়োগ করে এমন সংস্থা তৈরি করে যা খোলা, ব্যাপকভাবে অ্যাক্সেসযোগ্য, স্বচ্ছ সিদ্ধান্ত গ্রহণের সাথে, এবং মালিকানা ও পরামর্শদানের মাধ্যমে বিশ্বাসের উপর ভিত্তি করে দলীয় সম্পর্ক। এটি স্বচ্ছতা এবং সহযোগিতার সংস্কৃতি তৈরি করে।
এটিই “অভ্যন্তরীণভাবে ওপেন সোর্স অনুশীলন করা” বোঝায় - এটি শুধু “পুল রিকোয়েস্ট গ্রহণ করা” সম্পর্কে নয়। পুল রিকোয়েস্ট এই সংস্কৃতির একটি ফলাফল মাত্র, প্রাথমিক লক্ষ্য নয়।
InnerSource প্রয়োগের জন্য কম অনুকূল ডোমেইন #
দ্বিতীয় সমস্যা হল এই যুক্তিটি এমন একটি ডোমেইনে উন্মোচিত হয় যেখানে InnerSource এবং ওপেন সোর্স বিশেষ চ্যালেঞ্জের মুখোমুখি হয়।
যদি আপনি “পুল রিকোয়েস্ট গ্রহণ করতে” বা “অনেক মানুষকে গুণমান উন্নত করতে আপনার কোড ব্যবহার করতে” চান, তা আপনার পণ্যের প্রকৃতি দ্বারা সীমিত হতে পারে। এটি স্পষ্ট যে “উচ্চ-নির্ভরতা উপাদান” বা প্ল্যাটফর্ম-স্তরের সরঞ্জাম ভাগাভাগি করা শেষ-ব্যবহারকারী অ্যাপ্লিকেশনের চেয়ে বেশি মূল্য তৈরি করবে। যদিও স্ট্রিম-সংযুক্ত দলগুলি এখনও উপকারী হলে ওপেন সোর্স অনুশীলন গ্রহণ করা উচিত, সহযোগিতার গতিশীলতা উল্লেখযোগ্যভাবে ভিন্ন।
এন্টারপ্রাইজ কোম্পানিগুলির সাথে কাজ করার আমার অভিজ্ঞতায়, প্রকল্প-স্তরের উদ্যোগের জন্য InnerSource ব্যবহার করা যেখানে শেষ ব্যবহারকারীরা “অ-প্রকৌশলী” তা অনন্য চ্যালেঞ্জ উপস্থাপন করে। কেন? কারণ শেষ পর্যন্ত, এই পণ্যগুলি “শেষ ব্যবহারকারী” বা “ব্যবসায়িক ব্যবহারকারী"দের চাহিদা পূরণ করতে হয় যাদের উন্নয়ন দক্ষতা এবং উন্নয়ন দলের সাথে সরাসরি যোগাযোগের চ্যানেল নাও থাকতে পারে। এটি জটিল, ব্যক্তিগতকৃত প্রয়োজনীয়তা এবং দীর্ঘ যোগাযোগের লিড টাইম তৈরি করে।
InnerSource বাস্তবায়ন তুলনামূলকভাবে ভাল কাজ করে যখন ভাগ করা লাইব্রেরি, প্ল্যাটফর্ম উপাদান, উন্নয়ন সরঞ্জাম, এবং অবকাঠামো কোডে প্রয়োগ করা হয়—এমন ক্ষেত্র যেখানে “ব্যবহারকারীরা” প্রাথমিকভাবে অন্যান্য ডেভেলপার যারা সহযোগিতামূলক উন্নয়ন অনুশীলনে অর্থপূর্ণভাবে অবদান রাখতে এবং উপকৃত হতে পারে।
যদিও ব্যবহারকারী-মুখী অ্যাপ্লিকেশনে InnerSource অনুশীলন প্রয়োগ করা স্বচ্ছতা এবং উন্নত ইস্যু ট্র্যাকিংয়ের মতো মূল্যবান সুবিধা আনতে পারে (যা একাই এটিকে সার্থক করে তোলে)।
ব্যক্তিগত বনাম দলীয় দৃষ্টিভঙ্গি #
তৃতীয় সমস্যাটি “আপনি” একজন ব্যক্তি নাকি একটি দলকে বোঝায় তা নিয়ে।
এটি লক্ষ করা গুরুত্বপূর্ণ যে InnerSource অগত্যা একটি কোম্পানির মধ্যে “আপনার ব্যক্তিগত প্রকল্পে” কারও অবদান রাখার জন্য অপেক্ষা করা সম্পর্কে নয়। যখন InnerSource প্রয়োগ করা হয়, তখন এমন ক্ষেত্রে হতে পারে যেখানে মানুষ বড় প্রযুক্তি সংস্থাগুলির মতো 20% সময়ে উন্নত প্রকল্পে অবদান রাখে, কিন্তু এটি অগত্যা মূলধারার পদ্ধতি নয়।
InnerSource প্রাথমিকভাবে প্রবর্তিত এবং বজায় রাখা হয় কারণ এটি খরচ হ্রাস, চাকা পুনর্আবিষ্কার এড়ানো, সিনার্জি তৈরি, গুণমান নিশ্চিতকরণ, এবং শ্রেণিবদ্ধ সিদ্ধান্ত গ্রহণ থেকে যোগাযোগের ওভারহেড অপসারণের মাধ্যমে ROI উৎপন্ন করে। এটি সাধারণত ভাগ করা অভ্যন্তরীণ লাইব্রেরি, মালিকানাধীন প্রতিযোগিতামূলক সুবিধা উপাদান, বা এন্টারপ্রাইজের মধ্যে কুলুঙ্গি যা উচ্চ নির্ভরতা সহ জিনিসগুলি জড়িত। এবং এই “ব্যবসায়িক সুবিধাগুলি” সাধারণত বেশিরভাগ ক্ষেত্রে “দলীয় অপারেশনে” ফিরে আসে। শেষ পর্যন্ত, এটি দল এবং সংস্থার জন্য ROI সম্পর্কে। যদি আমরা দল সম্পর্কে চিন্তা না করি, কেউ আপনাকে প্রকল্পে অবদান রাখা থেকে বিরত রাখবে। আপনাকে আপনার ROI ন্যায্যতা প্রমাণ করতে হবে তা স্বল্পমেয়াদী বা দীর্ঘমেয়াদী যাই হোক।
InnerSource সম্পর্কে যা অনন্য তা হল এটি মৌলিকভাবে দল-থেকে-দল সহযোগিতা সম্পর্কে। এখানেই বেশিরভাগ বাস্তবায়ন শেষ পর্যন্ত পৌঁছায়। এটি অগত্যা ব্যক্তিরা এলোমেলোভাবে সুবিধাজনক ব্যক্তিগত প্রকল্পে অবদান রাখা নয়। এটি সাধারণত হোস্ট টিম এবং গেস্ট টিম সম্পর্কের মাধ্যমে বাস্তবায়িত হয়, যেখানে গেস্ট টিমগুলি হোস্ট টিম দ্বারা রক্ষণাবেক্ষণ করা অংশগুলির সাথে যুক্ত হয়। বেশিরভাগ এন্টারপ্রাইজে নির্ধারিত ভূমিকা এবং দায়িত্ব সহ কর্মচারী রয়েছে, এবং সহযোগিতা এই কাঠামোর মধ্যে ঘটে থাকে।
অতএব, InnerSource বিশেষভাবে কার্যকর যখন প্ল্যাটফর্ম টিম এবং স্ট্রিম-সংযুক্ত টিমগুলির (গেস্ট টিম এবং হোস্ট টিম) মধ্যে সম্পর্ক স্থাপিত হয়। স্ট্রিম-সংযুক্ত টিম বা ব্যক্তিদের মধ্যে সক্রিয় সহ-সৃষ্টি প্রাকৃতিকভাবে সফল হওয়ার জন্য আরও অনিশ্চিত।
এমন পরিস্থিতির উপর ভিত্তি করে সমস্ত InnerSource-এর সমালোচনা করা যা কাজ করার সম্ভাবনা কম তা কোনো যৌক্তিক অর্থ রাখে না।
দ্বিতীয় ভুল ধারণা: “এটি প্রকৃত কোম্পানিতে কখনো ঘটে না” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
আসলে, এটি ঘটছে। কেস স্টাডি এটি প্রমাণ করে। পিরিয়ড।
তৃতীয় ভুল ধারণা: “99.69% InnerSource প্রকল্প ব্যর্থ হবে” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
আপনি “InnerSource” কীভাবে সংজ্ঞায়িত করেন তার উপর নির্ভর করে এটি সঠিক হতে পারে। যেমন আগে উল্লেখ করা হয়েছে, InnerSource “PR অবদান গ্রহণ করা” সম্পর্কে নয়।
তবে, বিবেচনা করার তিনটি গুরুত্বপূর্ণ বিষয় রয়েছে:
- InnerSource বিশেষভাবে কৌশলগত উপাদানে প্রযোজ্য - এটি সব উপাদানের জন্য প্রয়োজনীয় নয়
- সুবিধাগুলি সক্রিয় অবদানের বাইরে বিস্তৃত
- ওপেন সোর্সেরও একই “ব্যর্থতার হার” সমস্যা রয়েছে
InnerSource একটি কর্পোরেট কৌশল #
যখন মানুষ InnerSource সম্পর্কে চিন্তা করে, তারা কখনও কখনও “এন্টারপ্রাইজের মধ্যে সমস্ত কোড ভাগাভাগি করা” বা “সবাই সবকিছুতে অবদান রাখা” এর মতো র্যাডিক্যাল ধারণা কল্পনা করে। তারা একটি কোম্পানির মধ্যে শত শত ভাগ করা রিপোজিটরি কল্পনা করতে পারে যেখানে সবাই সক্রিয়ভাবে অবদান বিনিময় করে। ওপেন সোর্স কোম্পানিগুলির জন্য একটি কৌশল হওয়ার মতো, InnerSource-ও অগ্রাধিকার সহ একটি কর্পোরেট কৌশল। কোম্পানিগুলি প্রথমে “যা ভাগাভাগি করার মূল্য রাখে” তা ভাগ করে।
অতএব, কোডবেসের প্রকৃত সংখ্যা যেখানে কোড সক্রিয়ভাবে দলগুলির মধ্যে প্রবাহিত হয় এবং প্রাণবন্ত ক্রস-টিম সহযোগিতা ঘটে তা তুলনামূলকভাবে ছোট। এটি প্রকৃতপক্ষে একক-সংখ্যার শতাংশ হতে পারে। তবে, সক্রিয় ক্রস-টিম সহযোগিতা ছাড়াও, অনেক প্রকল্প খোলা এবং স্বচ্ছ হওয়ার সুবিধা পেতে পারে। InnerSource-এর এই অর্থে, এন্টারপ্রাইজগুলি প্রায়শই আরও অনেক ক্ষেত্রে মূল্য ভাগ করতে পারে।
যদিও InnerSource ব্যক্তিগত অবদান অন্তর্ভুক্ত করে, এটি প্রাথমিকভাবে দল-থেকে-দল সহযোগিতার উপর দৃষ্টি নিবদ্ধ করে। অতএব, InnerSource-এর মাধ্যমে যা ভাগ করা হয় তা এন্টারপ্রাইজের মধ্যে তুলনামূলকভাবে কুলুঙ্গি হতে থাকে, বা বিশেষ প্রয়োজনের জন্য ফর্ক করা লিনাক্স ডিস্ট্রিবিউশনের মতো উদ্দেশ্য-নির্দিষ্ট আইটেম। অথবা এটি কেবল ওপেন সোর্স-সদৃশ উন্নয়ন সংস্কৃতি হতে পারে, যেমন GitHub যখন সমস্ত কর্মচারীর মধ্যে Ruby on Rails কোড ভাগ করে।
যখন আমরা এই শতাংশ আলোচনাকে InnerSource-এ শর্তযুক্ত করি যা সক্রিয়ভাবে সহযোগিতা করে এবং সাধারণ প্রয়োজনীয়তা হিসাবে রক্ষণাবেক্ষণ করা হয়, শতাংশ প্রকৃতপক্ষে তুলনামূলকভাবে কম হতে পারে। তবে, গেস্ট টিম এবং প্ল্যাটফর্ম/হোস্ট টিমগুলির মধ্যে ডকুমেন্টেশন পুল রিকোয়েস্ট বা ছোট কনফিগারেশন পরিবর্তনের মতো ছোট সহযোগিতা (ছোট প্যাচ পাঠানো) তুলনামূলকভাবে ঘন ঘন ঘটে। যখন আপনি এই মাইক্রো-সহযোগিতা এবং স্বচ্ছতার সুবিধাগুলি অন্তর্ভুক্ত করেন যা ডুপ্লিকেট প্রচেষ্টা প্রতিরোধ করে, এই সংখ্যাগুলি উল্লেখযোগ্যভাবে বৃদ্ধি পায়।
ওপেন সোর্সেরও একই “সমস্যা” রয়েছে #
অন্যদিকে, যদি আমরা এভাবে সংজ্ঞায়িত করি, ওপেন সোর্সও একটি “মিথ্যা” হবে। কারণ “99.69% ওপেন সোর্স প্রকল্প ব্যর্থ হবে।” ওপেন সোর্স হিসাবে প্রকাশিত বেশিরভাগ কোড অবদান পায় না। কিন্তু কেউ বলে না “ওপেন সোর্স একটি মিথ্যা” এই কারণে। মানুষ ওপেন সোর্স অনুসরণ করে কারণ অবদান গ্রহণের বাইরেও সুবিধা রয়েছে।
আবার, “অবদান পাওয়া” InnerSource-এর একমাত্র মূল্য নয়। এবং একই কথা ওপেন সোর্স মূল্যের জন্যও সত্য
স্বচ্ছতার প্রকৃত সুবিধা #
অভ্যন্তরীণ কোড লুকানোর পরিবর্তে খোলা রাখা - GitHub-এ, রাজস্ব দলের আর্কিটেক্ট বা সমাধান প্রকৌশলীরা প্রাসঙ্গিক তথ্য খুঁজে পেতে সোর্স কোড পরীক্ষা করতে সক্ষম হতে পারে, সম্ভাব্যভাবে গ্রাহকের অনুরোধের খুব কাছাকাছি বিবরণ খুঁজে পেতে, মসৃণ সহায়তা কথোপকথন সহজতর করতে, এবং ইস্যু থেকে আরও নির্ভুল তথ্য নিষ্কাশন করতে পারে। আমি টোকিওতে বাস করি, এবং কখনও কখনও পরিবর্তন এবং তাদের পটভূমি সম্পর্কে বাস্তবায়ন প্রশ্ন জিজ্ঞাসা করার জন্য SF-ভিত্তিক পণ্য দলের জেগে ওঠার জন্য অপেক্ষা করার চেয়ে বাস্তবায়ন পরীক্ষা করতে Ruby কোড দেখা বা পরিবর্তনের পটভূমি পরীক্ষা করতে ইস্যুতে যাওয়া দ্রুততর।
git blame কমান্ড ব্যবহার করে, আপনি কোডের “প্রকৃত” স্টেকহোল্ডারদের চিহ্নিত করতে এবং সিদ্ধান্তের পটভূমি সম্পর্কে প্রশ্ন জিজ্ঞাসা করতে পারেন।
বলার অপেক্ষা রাখে না, একই কথা অন্যান্য উন্নয়ন দলের জন্যও প্রযোজ্য। নির্ভরতা তৈরি করতে পারে এমন উপাদানগুলি সম্পর্কে তথ্য সহজলভ্য থাকা স্পষ্টভাবে যোগাযোগের ওভারহেড হ্রাস করে।
InnerSource অভ্যন্তরীণভাবে ওপেন সোর্স নীতি অনুশীলন করার বিষয়ে। InnerSource শুধু পুল রিকোয়েস্ট আদান-প্রদান সম্পর্কে নয় - এটি স্বচ্ছতা নিশ্চিত করা এবং ওপেন সোর্স-স্টাইল সহযোগিতার মাধ্যমে সুবিধা অর্জনের বিষয়ে। এই সুবিধাগুলি সক্রিয়ভাবে রক্ষণাবেক্ষণ করা রিপোজিটরির কয়েক শতাংশের বাইরে ব্যাপক সাংস্কৃতিক বাস্তবায়ন সুবিধায় বিস্তৃত।
চতুর্থ ভুল ধারণা: “আপনি চলে গেলে আপনাকে ফিরে ডাকা হবে” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
সম্পদ কখনও কখনও রক্ষণাবেক্ষণহীন হয়ে যায়, কিন্তু এটি InnerSource নিজেই একটি উপযুক্ত সমালোচনা নয় - এটি InnerSource সঠিকভাবে বাস্তবায়ন করতে ব্যর্থ হওয়ার সমালোচনা। এটি InnerSource-এর সমালোচনা নয়, বরং রক্ষণাবেক্ষণ সংস্কৃতির অভাবের সমালোচনা যেখানে কেউ কোড রক্ষণাবেক্ষণ করে না। এটি InnerSource সঠিকভাবে বাস্তবায়ন করতে ব্যর্থ হওয়া বা এটি বিবেচনা না করার ফলাফল - মালিকানার অভাবের ফলাফল।
DevOps উপমা #
এটি InnerSource করতে ব্যর্থ হওয়ার সমালোচনা, InnerSource নিজেই সমালোচনা নয়। কখনও কখনও এটি যুক্তিকে বিভ্রান্ত করে। এটিকে DevOps পরিভাষায় বলতে গেলে: এটি বলার মতো “কোম্পানিগুলি কয়েক মাসের ধীর পর্যালোচনা চক্র বা অডিট গ্রহণ করে, বা রিলিজ সিদ্ধান্তের জন্য প্রক্রিয়া যোগ করে, তাই রিলিজ ত্রৈমাসিক বা বছরে মাত্র দুইবার হয়। অতএব DevOps, যা দ্রুত রিলিজ সক্ষম করার দাবি করে, ভাল নয়।” এটি DevOps পদ্ধতি খারাপ বলে নয়, বরং কেবল “এমন ক্ষেত্রে ছিল যেখানে DevOps বাস্তবায়ন করা যায়নি।”
ব্যবসায়িক প্রক্রিয়া ভাঙা অত্যন্ত কঠিন, এবং অনেক কোম্পানি বলেছিল DevOps অসম্ভব। কিন্তু যখন মানুষ ভেবেছিল এটি অসম্ভব, তখনও সাহসী অগ্রদূত ছিল যারা সংস্কৃতি পরিবর্তন করতে কঠোর পরিশ্রম করেছিল এবং DevOps অর্জন করেছিল। InnerSource-এর সাথেও একই ঘটতে পারে।
পঞ্চম ভুল ধারণা: “আপনাকে 100% সবকিছুর মালিক হতে হবে” #
you own it 100% (যার অর্থ: InnerSource যেখানে আপনি 100% মালিক নন তা অসম্ভব)
“InnerSource মানে কোড মালিকানা পরিত্যাগ করা” ভুল। InnerSource আসলে দলগুলিকে কোডের মালিক হতে হয়। এটি একটি সাধারণ ভুল। এটি এমন মানুষদের মতো যারা রক্ষণাবেক্ষণ দায়িত্ব পরিত্যাগ করতে চায় এবং বলে “চলুন এটি ওপেন সোর্স করি।” এটি কাজ করে না।
ব্যক্তিগত বনাম দলীয় মালিকানা - InnerSource কি শক্তিশালী কোড মালিকানা? #
প্রথমত, এই “আপনি” কি একবচন নাকি বহুবচন? যদিও সংস্থাগুলিতে ব্যক্তিরা CODEOWNERS ফাইলে তালিকাভুক্ত হতে পারে, দলগুলি শেষ পর্যন্ত কোডের জন্য দায়িত্ব ধারণ করে। প্রসঙ্গক্রমে, এটি সম্ভবত শক্তিশালী কোড মালিকানা সম্পর্কে কথা বলছে। কিন্তু সাংগঠানিক রক্ষণাবেক্ষণ বিবেচনা করার সময় এটি ভাল নয়। কারণ কর্মচারীরা চাকরি ছাড়তে পারে।
InnerSource শক্তিশালী কোড মালিকানা নয়। ন্যূনতম, একাধিক মানুষকে দায়িত্ব ভাগ করতে হবে। এটি বলে যে, আমি স্বীকার করি যে শক্তিশালী কোড মালিকানা স্বল্পমেয়াদে উদ্ভূত হতে পারে, এবং একটি প্রকল্পের প্রাথমিক পর্যায়ে, শক্তিশালী ব্যক্তিগত ইচ্ছা প্রাকৃতিকভাবে এই ধরনের ব্যবস্থার দিকে নিয়ে যেতে পারে, কিন্তু যদি আপনি দীর্ঘমেয়াদী সাফল্য অর্জন করতে চান, তাহলে কর্তৃত্ব অর্পণ করা প্রয়োজন যাতে সংস্থা সম্মিলিতভাবে রক্ষণাবেক্ষণ পরিচালনা করতে পারে।
দলীয় মালিকানার ধরন - InnerSource কি সম্মিলিত কোড মালিকানা? #
এই ধরনের যুক্তি কখনও কখনও সম্মিলিত মালিকানা উল্লেখ করতে পারে। এই ক্ষেত্রে, যুক্তিটি এও পরামর্শ দেয় যে InnerSource মানে সম্মিলিত মালিকানা, কিন্তু এটি আসলে ভিন্ন। InnerSource সম্মিলিত কোড মালিকানা নয় InnerSource হোস্ট টিমগুলি শেষ পর্যন্ত রক্ষণাবেক্ষণ পরিচালনা জড়িত। InnerSource দুর্বল কোড মালিকানা। তাই রক্ষণাবেক্ষণ দায়িত্ব 100% সঠিক হলেও, “আপনাকে 100% মালিক হতে হবে এবং InnerSource ভিন্ন” বলা সম্পূর্ণ অযৌক্তিক। এটি আসলে একটি ভুল মতামত।
মার্টিন ফাউলার কোড মালিকানা সম্পর্কে বিখ্যাতভাবে যুক্তি দিয়েছিলেন, সবাইকে 100% কোডের মালিক করা (সম্মিলিত মালিকানা) কখনও কখনও এমন পরিস্থিতি তৈরি করে যেখানে কেউ দায়িত্ব নেয় না। এটি খুবই সমস্যাজনক - দায়িত্ব অস্পষ্ট হয়ে যায় এবং প্রকল্পগুলি শেষ পর্যন্ত ব্যর্থ হয়।
দুর্বল কোড মালিকানা মডেল #
দুর্বল কোড মালিকানায়, রক্ষণাবেক্ষণকারী বিদ্যমান, হোস্ট টিম প্রকল্প রক্ষণাবেক্ষণ করে, এবং নির্দিষ্ট অংশ অন্যান্য দল থেকে বিশ্বস্ত কমিটার/রক্ষণাবেক্ষণকারী আনতে পারে। কেউ অবদান রাখতে পারে, কেউ রক্ষণাবেক্ষণ করতে পারে, কিন্তু “আপনার” বা “আপনার দলের” দ্বারা 100% নয় - এটি বেশ ভিন্ন হতে পারে। উদাহরণস্বরূপ, 98% কোড আপনার দলের মালিকানাধীন হতে পারে, যখন 2% অন্যান্য দলের মালিকানাধীন হতে পারে।
এই ক্ষেত্রে, মনে রাখবেন যে সংস্থাগুলিতে ব্যক্তিরা কোড মালিক হিসাবে নিয়োগ পেলেও, দলগুলি শেষ পর্যন্ত কোডের জন্য দায়িত্ব ধারণ করে। দলগুলির এর মালিক হওয়া উচিত, এবং এই গুরুত্বপূর্ণ বিষয়টি ভুলে যাবেন না।
ষষ্ঠ ভুল ধারণা: “কেউ আপনার উপর 7000 লাইন ফেলে দেবে” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
হঠাৎ 7000-লাইন পুল রিকোয়েস্ট উপস্থিত হওয়া নিজেই InnerSource সংস্কৃতি প্রবর্তনে ব্যর্থতা - এটি InnerSource করার ফলে ঘটে এমন কিছু নয়। এই ক্ষেত্রে চিন্তা হতে পারে যে InnerSource প্রবর্তন এই ধরনের সহযোগিতা ঘটায়, কিন্তু এটি সম্পূর্ণ ভুল।
প্রকৃত সমস্যা #
এই যুক্তি InnerSource সংস্কৃতি এবং সহযোগিতামূলক অনুশীলন বাস্তবায়নে ব্যর্থতার প্রতিনিধিত্ব করে, InnerSource নিজেই নয়। 7000-লাইন বাস্তবায়ন খুবই সীমিত ক্ষেত্রে। এটি সহযোগিতা সংস্কৃতির ব্যর্থতার প্রতিনিধিত্ব করে যেখানে কোনো বিজ্ঞপ্তি ছাড়াই হঠাৎ পুল রিকোয়েস্ট হিসাবে 7000 লাইন জমা দেওয়া হয় - সংস্থার এই মৌলিক সংস্কৃতি সমস্যা ঠিক করা উচিত, যা প্রি-InnerSource।
যদি আপনি এটি প্রতিরোধ করতে চান, একটি সমাধান আছে। আপনার সংস্থার মধ্যে InnerSource সংস্কৃতি লালন করুন:)
বাস্তবতা: InnerSource আসলে কী #
InnerSource হল সাংস্কৃতিক বাস্তবায়ন - সহযোগিতার মাধ্যমে ওপেন সোর্স যে বিভিন্ন সুবিধা পায় তা উপভোগ করতে ওপেন সোর্স সহযোগিতা অনুশীলন ব্যবহার করা। InnerSource-এর চূড়ান্ত উদ্দেশ্য শুধু অবদান (পুল রিকোয়েস্ট) গ্রহণ করা নয়, বরং ইস্যুর মাধ্যমে বৈশিষ্ট্য অনুরোধ, সহায়তা সমন্বয়, এবং বিভিন্ন অন্যান্য সুবিধা, এছাড়াও সিদ্ধান্ত গ্রহণে স্বচ্ছতা এবং ব্যবহারিক সাংস্কৃতিক প্রচার অন্তর্ভুক্ত।
অতএব, আমি দৃঢ়ভাবে “পুল রিকোয়েস্ট পেতে InnerSource সর্বোত্তম অনুশীলন বাস্তবায়ন একটি মিথ্যা” দাবি প্রত্যাখ্যান করি।
অবদানের বাস্তবতা বোঝা #
“কেউ কখনো অবদান রাখবে না”
ওপেন সোর্স সহযোগিতায়, অবদানকারীরা প্রকৃতপক্ষে একটি ক্ষুদ্র অংশ। 1000 ব্যবহারকারীর মধ্যে, হয়তো বিশাল সংখ্যাগরিষ্ঠ শুধু ব্যবহারকারী, 20 জন ইস্যু বা বৈশিষ্ট্য অনুরোধ জমা দিতে পারে, 5 জন পুল রিকোয়েস্ট পাঠাতে পারে, এবং হয়তো শুধুমাত্র একজন রক্ষণাবেক্ষণকারী হয়।
আবার, InnerSource সর্বোত্তম অনুশীলন সব 1000 জনকে অবদান রাখতে বাধ্য করবে না। InnerSource এই ধরনের সহযোগিতা প্ররোচিত করতে সাহায্য করে, কিন্তু শেষ পর্যন্ত এন্টারপ্রাইজ সাইলো ভাঙতে, ঐতিহ্যগত সাংগঠানিক সীমাবদ্ধতা দ্বারা বাধাগ্রস্ত সহযোগিতা উন্নত করতে, তথ্য সাইলো থেকে লিড টাইম হ্রাস করতে, এবং ওপেন সোর্স অনুশীলন ব্যবহার করে সাংগঠানিক সম্পদ বরাদ্দ অপ্টিমাইজ করতে লক্ষ্য রাখে।
উপসংহার #
যদিও এই ক্ষেত্রে যুক্তিগুলি কিছু প্রকৃত চ্যালেঞ্জ স্পর্শ করে, তারা সাধারণ ভুল বোঝাবুঝির উপর ভিত্তি করে যা অনেক মানুষ InnerSource সম্পর্কে প্রথম শেখার সময় সম্মুখীন হয়। এগুলি সম্প্রদায়ে সুপরিচিত ফাঁদ, এবং এটি বোধগম্য যে কেউ ক্ষেত্রটির গভীর অন্বেষণ ছাড়াই এই সিদ্ধান্তে পৌঁছাতে পারে।
মূল অন্তর্দৃষ্টি হল InnerSource একটি কঠোর কাঠামোতে ওপেন সোর্স অনুশীলন জোর করার বিষয়ে নয়। পরিবর্তে, এটি মৌলিক প্রশ্নে ফিরে যাওয়ার বিষয়ে: আমরা ওপেন সোর্স থেকে কী শিখতে পারি? ওপেন সোর্সকে একটি ব্যাপক লেন্সের মাধ্যমে পরীক্ষা করে, আমরা এই নীতিগুলি অভ্যন্তরীণভাবে আরও ভালভাবে মানিয়ে নিতে পারি।
আপনি এই কথোপকথনে যোগ দিতে এবং নতুন দৃষ্টিভঙ্গি আনতে পারেন। আপনি এই আলোচনার উপর ভিত্তি করে গড়তে চান, আরও নির্দিষ্ট বাস্তবায়ন বিবরণ অন্বেষণ করতে চান, বা এমনকি এই যুক্তিগুলিকে সম্পূর্ণভাবে চ্যালেঞ্জ করতে চান - সব পদ্ধতি স্বাগত। যা সবচেয়ে গুরুত্বপূর্ণ তা হল ওপেন সোর্স শিক্ষার উপর সেই ব্যাপক দৃষ্টিভঙ্গি বজায় রাখা এবং কীভাবে তারা অভ্যন্তরীণ সাংগঠানিক প্রসঙ্গে অনুবাদ করে।
InnerSource সম্পর্কে বিস্তৃত তথ্যের জন্য, আমি InnerSource Commons Foundation পরীক্ষা করার সুপারিশ করি। তারা বিভিন্ন দৃষ্টিভঙ্গি এবং কীভাবে ওপেন সোর্স নীতিগুলি সংস্থাগুলির মধ্যে মূল্য তৈরি করতে পারে সে সম্পর্কে চলমান সংলাপ স্বাগত জানায়।
