InnerSource কে সংজ্ঞায়িত করার অর্থ কী

প্রশ্ন #

মানুষ প্রায়ই আমাকে জিজ্ঞেস করে InnerSource এর সংজ্ঞা কী। এখন, InnerSource কী? আমি InnerSource সম্পর্কে এবং এটি আমার কাছে কী অর্থ বহন করে সে বিষয়ে কিছু চিন্তাভাবনা শেয়ার করতে চাই।

শুরু থেকেই আমি স্পষ্ট করে বলি: এগুলো আমার ব্যক্তিগত মতামত, কোনো অফিসিয়াল অবস্থান নয়। যদিও আমি বর্তমানে InnerSource Commons Foundation এর প্রেসিডেন্ট হিসেবে দায়িত্ব পালন করছি, InnerSource অনেক অগ্রদূতের দ্বারা গঠিত হয়েছে যাদের আমি গভীরভাবে সম্মান করি। তাদের অবদান আজকের InnerSource কে তৈরি করেছে।

InnerSource এর ভিত্তি এসেছে কর্পোরেট অনুশীলন, একাডেমিক গবেষণা এবং অবশ্যই, ওপেন সোর্সের বিবর্তনের পারস্পরিক সংযোগ থেকে। এই সমৃদ্ধ বুননের পরিপ্রেক্ষিতে, আমার পক্ষে ব্যক্তিগতভাবে InnerSource কে সংজ্ঞায়িত করার দাবি করা অহংকারপূর্ণ হবে। শুধুমাত্র আমি বর্তমানে প্রেসিডেন্ট হিসেবে দায়িত্ব পালন করছি বলেই আমার একা সেই সংজ্ঞা তৈরি করার কর্তৃত্ব বা প্রজ্ঞা আছে তা নয়।

একটি একক নির্দিষ্ট উত্তর প্রদান করার পরিবর্তে, আমি এই প্রশ্নের বিভিন্ন দৃষ্টিভঙ্গি শেয়ার করতে চাই, এমন দৃষ্টিভঙ্গি প্রদান করতে চাই যা আপনাকে আপনার নিজস্ব সংজ্ঞা এবং InnerSource আপনার প্রসঙ্গে কী অর্থ বহন করে তা আবিষ্কার করতে সাহায্য করতে পারে।


InnerSource এর দুটি পথ #

আমরা একটি আকর্ষণীয় মোড়ের মুখে আছি। আমি কী বোঝাতে চাইছি তা আরো স্পষ্ট করে বলি। আজকে মূলত দুই ধরনের মানুষ InnerSource এর কাছে আসছে:

প্রথম গ্রুপ তাদের নিয়ে গঠিত যারা ওপেন সোর্স অনুশীলন করে এসেছে, এর সহযোগিতামূলক পদ্ধতিগুলো শক্তিশালী মনে করেছে এবং স্বাভাবিকভাবেই এই নীতিগুলো অভ্যন্তরীণভাবে প্রয়োগ করেছে। তাদের কাছে, InnerSource ছিল কেবল এমন কিছুর নাম যা তারা ইতিমধ্যে করছিল—ওপেন সোর্স সহযোগিতার উৎকর্ষতা তাদের সংস্থায় নিয়ে আসা।

দ্বিতীয় গ্রুপ InnerSource কে একটি নামকরণ করা পদ্ধতি হিসেবে আবিষ্কার করেছে। তাদের ব্যাপক ওপেন সোর্স পটভূমি নাও থাকতে পারে, কিন্তু তারা স্বীকার করে যে একটি সাংগঠনিক পদ্ধতি হিসেবে InnerSource রূপান্তরের জন্য অসাধারণ মূল্য প্রদান করে। তারা InnerSource গ্রহণ করছে কারণ তারা ওপেন সোর্স অনুশীলনকারী ছিল বলে নয়, বরং কারণ InnerSource নিজেই সাংগঠনিক সুবিধার প্রতিশ্রুতি দেয়।

এই দ্বৈততা আমাদের কমিউনিটিতে আকর্ষণীয় সুযোগ তৈরি করে। প্রথম গ্রুপ স্বজ্ঞাতভাবে বুঝতে পারে একটি সংস্থার মধ্যে InnerSource বাস্তবায়ন করার অর্থ কী, সেইসাথে InnerSource এবং ওপেন সোর্সের মূল্য ও সংস্কৃতি। তাই, তারা InnerSource কীভাবে সংজ্ঞায়িত হওয়া উচিত তা নিয়ে চিন্তা করতে পারে এবং ওপেন সোর্সের কাঠামোর মধ্যে এটি নিয়ে ভাবতে পারে। অন্যদিকে, দ্বিতীয় গ্রুপের অগত্যা ওপেন সোর্সের সাথে সম্পৃক্ততা নেই, তাই তারা এটি আসলে কী তা সম্পর্কে স্পষ্ট ধারণা খোঁজার প্রবণতা রাখে।

90%


DevOps থেকে শেখা: নামকরণের শক্তি #

InnerSource এর সংজ্ঞাগত চ্যালেঞ্জ বুঝতে, আসুন DevOps এর দিকে তাকাই। এর বিবর্তন আমি যেভাবে বুঝি: Flickr এর মতো কোম্পানির অনুশীলনকারীরা কিছু উদ্ভাবনী কাজ করছিল—ডেভেলপমেন্ট এবং অপারেশনের মধ্যে সাইলো ভেঙে ফেলা। যখন তারা তাদের অভিজ্ঞতা শেয়ার করল এবং কেউ এটির একটি নাম দিল—“DevOps”—কিছু জাদুকরী ঘটনা ঘটল। হঠাৎ করে, সর্বত্র কোম্পানিগুলো বুঝতে পারল তারা একই রকম কাজ করছে, এবং তারা সবাই তাদের গল্প শেয়ার করতে শুরু করল।

মূল অন্তর্দৃষ্টি হলো এই: অনুশীলন নামের আগে থেকেই বিদ্যমান ছিল, কিন্তু নামকরণ কমিউনিটি তৈরি করেছে। সেই কমিউনিটির সাথে এসেছে টুলস, শেয়ার করা ধারণা, কনফারেন্স এবং বিস্ফোরক বৃদ্ধি। DevOps আবিষ্কৃত হয়নি; এটি আবিষ্কৃত এবং নামকরণ করা হয়েছে। নামকরণ অন্য সবকিছুকে অনুঘটক করেছে।

InnerSource একটি অসাধারণভাবে অনুরূপ প্যাটার্ন অনুসরণ করে। Tim O’Reilly ২০০০ সালে একটি ব্লগ পোস্টে এটি উল্লেখ করেছিলেন। ২০১৫ সালে, Danese Cooper এবং সহকর্মীরা, তখন PayPal এ, InnerSource Commons কে আনুষ্ঠানিক রূপ দেন, পরে এটিকে একটি ফাউন্ডেশন হিসেবে স্পিন আউট করেন। কিন্তু তারা অনুশীলন আবিষ্কার করেননি—তারা এমন কিছুর নাম দিয়েছেন যা মানুষ ইতিমধ্যে করছিল।

এই নামকরণ জাদুকরী ছিল। হঠাৎ করে, বিচ্ছিন্ন অনুশীলনকারীরা বুঝতে পারল তারা একা নয়। “ওহ, আমাদের অভ্যন্তরীণ লাইব্রেরিগুলোর সাথে আমরা যা করছি? সেটা InnerSource!” কমিউনিটি প্যাটার্ন শেয়ারিংয়ের সাথে বিস্ফোরিত হয়েছে, যার ফলে InnerSource Patterns এর মতো রিসোর্স তৈরি হয়েছে যা সামষ্টিক প্রজ্ঞা ধারণ করে।

আজকে DevOps কী? অনেকের মধ্যে একটি দৃষ্টিভঙ্গি #

মানুষ DevOps কে অসংখ্য উপায়ে সংজ্ঞায়িত করে, এবং আমি সেগুলো সব কভার করতে পারব না। এটি কীভাবে বোঝা যেতে পারে তার একটি উদাহরণ এখানে:

  • ঐতিহ্যগতভাবে পৃথক দলগুলোর মধ্যে সহযোগিতার সংস্কৃতি
  • অনুশীলন এবং অটোমেশন টুলসের একটি সেট
  • ঐতিহ্যগত ওয়াটারফল ডেভেলপমেন্টের বিরোধিতা করে এমন একটি দর্শন
  • পদ্ধতি এবং ফ্রেমওয়ার্কের একটি সংগ্রহ
  • বিশেষায়িত ক্ষেত্রে সম্প্রসারণ: BizDevOps, DevSecOps, এবং আরও

এটি শুধুমাত্র একটি ব্যাখ্যা। দশজন অনুশীলনকারীকে জিজ্ঞেস করুন, এবং আপনি দশটি ভিন্ন জোর পাবেন। এই বৈচিত্র্য দুর্বলতা নয়—এটি বিবর্তনীয় শক্তি।

90%


“অভ্যন্তরীণ ওপেন সোর্স” এর একাধিক অর্থ #

“অভ্যন্তরীণ ওপেন সোর্স” বাক্যাংশটি বিরোধাভাসী মনে হয়, এবং এই বিরোধাভাস প্রকাশ করে কেন InnerSource বিভিন্ন সংস্থার কাছে বিভিন্ন অর্থ বহন করে। আমাদের কমিউনিটি আলোচনা থেকে উদ্ভূত কিছু প্রতিনিধিত্বমূলক উদাহরণ আমি শেয়ার করি:

ওপেন সোর্স পরিপক্বতার পথ হিসেবে InnerSource #

কারো কারো কাছে, InnerSource ওপেন সোর্স অংশগ্রহণ এবং ডিজিটাল রূপান্তরের দিকে একটি জৈব পথ খুলে দেয়। এটি শুধুমাত্র শেষ পর্যন্ত ওপেন সোর্স অবদানের জন্য প্রস্তুতি নিয়ে নয়—এটি এমন একটি পরিবেশ তৈরি করার বিষয়ে যেখানে সংস্থা একটি সত্যিকারের সফটওয়্যার কোম্পানিতে বেড়ে উঠতে পারে। Microsoft এবং Google এর মতো কোম্পানিগুলো এই যাত্রার উদাহরণ, যেখানে অভ্যন্তরীণ অনুশীলনগুলো স্বাভাবিকভাবে বাহ্যিকগুলোর প্রতিফলন ঘটাতে বিবর্তিত হয়, কোম্পানির ভিতরে এবং বাইরে উভয় জায়গায় নিরবচ্ছিন্ন সহযোগিতা তৈরি করে।

কিন্তু উৎপাদনকারী কোম্পানি, খুচরা বিক্রেতা বা আর্থিক প্রতিষ্ঠানগুলোর কী হবে? যদিও তারা বিপুল পরিমাণ ওপেন সোর্স ব্যবহার করতে পারে, তাদের যাত্রা ভিন্ন। তাদের জন্য, InnerSource একটি দীর্ঘ রূপান্তরের প্রথম ধাপ হতে পারে—সফটওয়্যার ক্ষমতা তৈরি করা, উদ্ভাবনী সংস্কৃতি লালন করা এবং সম্ভবত শেষ পর্যন্ত তাদের ব্যবসায়িক মডেলের সাথে সামঞ্জস্যপূর্ণ ওপেন সোর্সের সাথে জড়িত হওয়ার তাদের নিজস্ব অনন্য উপায় খুঁজে পাওয়া।

সাংগঠনিক স্বচ্ছতা হিসেবে InnerSource #

অনেকে সাংস্কৃতিক রূপান্তরের জন্য InnerSource এর প্রতি আকৃষ্ট হয়। এটি শুধুমাত্র পুল রিকোয়েস্ট পাঠানোর বিষয়ে নয়—যদিও এটি এর একটি অংশ। এটি জৈব স্বচ্ছতা তৈরি করার বিষয়ে যেখানে আপনি পারেন:

  • অন্যান্য দলের কাছে ফিচার রিকোয়েস্ট জমা দিতে
  • প্রতিবেশী দলগুলো কী তৈরি করছে তা দেখতে
  • বৃহত্তর সাংগঠনিক প্রযুক্তি ল্যান্ডস্কেপ বুঝতে
  • সহযোগিতা প্রতিরোধকারী সাইলো ভেঙে ফেলতে
  • আরো খোলা, শ্বাসযোগ্য সাংগঠনিক সংস্কৃতি তৈরি করতে যেখানে তথ্য স্বাভাবিকভাবে প্রবাহিত হয়

এই স্বচ্ছতা সংস্থাগুলোকে কঠোর শ্রেণিবিন্যাস থেকে সহযোগিতার জীবন্ত নেটওয়ার্কে রূপান্তরিত করে।

শেষ পর্যন্ত, এগুলো ইঞ্জিনিয়ার, প্রোডাক্ট টিম এবং সংস্থার মধ্যে জড়িত সবার সুখ ও কল্যাণে অবদান রাখে। একটি সহায়ক কর্মপরিবেশে বিশ্বস্ত বোধ করা—ডিফল্টভাবে বিশ্বস্ত বোধ করা—অবিশ্বাস্যভাবে গুরুত্বপূর্ণ। এটি ডেভেলপার এক্সপেরিয়েন্সের সাথে সম্পর্কিত, এবং ফলস্বরূপ উন্নত প্রতিভা ধরে রাখার দিকে নিয়ে যায় এবং নিয়োগের জন্যও ইতিবাচক ফলাফল প্রদান করে।

রিসোর্স অপটিমাইজেশন হিসেবে InnerSource #

ঐতিহ্যগত শ্রেণিবদ্ধ প্রকল্প ব্যবস্থাপনা প্রতিটি স্তরে মার্জিন যোগ করে। প্রয়োজনীয়তা নিচের দিকে প্রবাহিত হয়, প্রতিটি স্তর অনিশ্চয়তার জন্য বাফার সময় যোগ করে। কাজ বাস্তবায়নে পৌঁছানোর সময়, সময়সীমা ফুলে যায় এবং ইঞ্জিনিয়াররা চাপে পড়ে।

InnerSource এটিকে উল্টে দেয়। সমস্যার সবচেয়ে কাছের মানুষরা সেগুলো সবচেয়ে ভালো বোঝে। তারা ক্যাসকেডিং মিটিং এবং অনুমোদন ছাড়াই অগ্রাধিকার দিতে, আলোচনা করতে এবং সমস্যা সমাধান করতে পারে। এটি সবসময় সঠিক নয়—ফিল্ড টিমরা শুধুমাত্র তাদের ক্ষেত্র জানে—কিন্তু কৌশলগত তত্ত্বাবধানের সাথে ভারসাম্য রক্ষা করলে, এটি শক্তিশালী।

কিন্তু রিসোর্স অপটিমাইজেশন মানব এবং দলীয় রিসোর্সের বাইরেও যায়। এটি সংস্থার কোড সম্পদ, বুদ্ধিবৃত্তিক সম্পত্তি এবং প্রতিযোগিতামূলক সুবিধা কাজে লাগানোর বিষয়েও। যখন দলগুলো একে অপরের টুলস, লাইব্রেরি এবং জ্ঞান শেয়ার করতে এবং তার উপর ভিত্তি করে তৈরি করতে পারে, তারা এমন সিনার্জি তৈরি করে যা সাইলো করা কাঠামোতে থাকত না। আপনার দল যে অভ্যন্তরীণ মেশিন লার্নিং লাইব্রেরি তৈরি করেছে? অন্য একটি দল এটিকে এমনভাবে প্রসারিত করতে পারে যা আপনি কখনো কল্পনা করেননি। যে টেস্টিং ফ্রেমওয়ার্ক আপনাকে প্রতিযোগিতামূলক সুবিধা দিয়েছে? এটি অভ্যন্তরীণভাবে শেয়ার করা সংস্থা জুড়ে এর মূল্য বহুগুণ করে। InnerSource সংস্থাগুলোকে বুঝতে সাহায্য করে যে তাদের কোড এবং জ্ঞান সম্পদ এমন রিসোর্স যা শেয়ার করলে আরো মূল্যবান হয়ে ওঠে, জমা করে রাখলে নয়।


সংজ্ঞার দ্বিধা: প্রসঙ্গই সব #

একাধিক অর্থের এই চ্যালেঞ্জ InnerSource এর জন্য অনন্য নয়। বিবেচনা করুন কীভাবে Open Source Program Office (OSPO) অ্যাডভোকেটরা অভ্যন্তরীণভাবে ওপেন সোর্স প্রচার করে। তারা অবশ্যই বিভিন্ন দর্শকের জন্য বিভিন্ন বার্তা ব্যবহার করে কারণ প্রতিটি কার্যকলাপের বিভিন্ন স্টেকহোল্ডারদের কাছ থেকে সমর্থন প্রয়োজন, এবং সংস্থার প্রতিটি স্তরের বিভিন্ন আগ্রহ ও উদ্বেগ রয়েছে।

InnerSource অ্যাডভোকেসির জন্য, বার্তা এরকম দেখতে পারে:

ইঞ্জিনিয়ারদের কাছে: “উজ্জ্বল সহকর্মীদের সাথে সহযোগিতা করুন, সেরা কোড থেকে শিখুন, আপনার তাৎক্ষণিক দলের বাইরে উত্তেজনাপূর্ণ প্রকল্পে অবদান রাখুন”

মধ্যম ব্যবস্থাপনার কাছে: “ডুপ্লিকেশন কমান, দক্ষতা বৃদ্ধি করুন, পুনঃব্যবহার এবং সহযোগিতার মাধ্যমে ডেলিভারি ত্বরান্বিত করুন”

এক্সিকিউটিভদের কাছে: “খরচ কমান, উদ্ভাবনের গতি বৃদ্ধি করুন এবং শীর্ষ প্রতিভা ধরে রাখুন”

একই InnerSource উদ্যোগ একসাথে এই সব লক্ষ্য পূরণ করে, কিন্তু আপনি বিভিন্ন দর্শকের কাছে বিভিন্ন দিক জোর দেন। এটি প্রতারণা নয়—এটি স্বীকৃতি যে InnerSource, যেকোনো রূপান্তরকারী পদ্ধতির মতো, একাধিক স্তরে মূল্য প্রদান করে।

আপনার InnerSource সংজ্ঞা শুধুমাত্র দর্শক-নির্ভর নয়—এটি পর্যায়-নির্ভর। এবং এটি সম্পূর্ণ ঠিক আছে।


আপনার InnerSource যাত্রা: একটি বিবর্তনশীল সংজ্ঞা #

তাহলে InnerSource কী? এটি আপনি যা সংজ্ঞায়িত করেন তাই।

সম্ভবত ভবিষ্যতে, InnerSource Commons Foundation একটি স্পষ্ট, আরো যোগাযোগযোগ্য সংজ্ঞা তৈরি করবে যা InnerSource কী তা তাৎক্ষণিকভাবে স্পষ্ট করে তুলবে। ব্যক্তিগতভাবে, আমি সেই দিনের অপেক্ষায় আছি, যদিও আমি স্বীকার করি যে এত বৈচিত্র্যের মধ্যে এমন একটি সংজ্ঞা তৈরি করা অবিশ্বাস্যভাবে কঠিন কাজ।

তাছাড়া, আপনার সংজ্ঞা পরিবর্তিত হতে পারে এবং হওয়া উচিত। যে InnerSource আপনাকে আপনার যাত্রা শুরু করতে সাহায্য করে তা তিন বছর পরে আপনি যে InnerSource অনুশীলন করেন তার থেকে ভিন্ন হতে পারে। আপনার সংস্থা পরিপক্ব হওয়ার সাথে সাথে, আপনার চ্যালেঞ্জ পরিবর্তিত হওয়ার সাথে সাথে, আপনার বোঝাপড়া গভীর হওয়ার সাথে সাথে আপনার সংজ্ঞা পরিবর্তিত হতে পারে।

আপনি আপনার সংজ্ঞা কমিউনিটিতে নিয়ে আসতে পারেন, আপনার দৃষ্টিভঙ্গি শেয়ার করতে পারেন এবং আমাদের সবাইকে একসাথে এই প্রশ্নগুলো নিয়ে চিন্তা করতে সাহায্য করতে পারেন। এই সামষ্টিক অনুসন্ধানই আমাদের শেষ পর্যন্ত ভাগ করা বোঝাপড়ায় পৌঁছাতে সাহায্য করবে—উপর থেকে নিচে ডিক্রির মাধ্যমে নয়, বরং সহযোগিতামূলক আবিষ্কারের মাধ্যমে।

90%


কর্মের আহ্বান #

নিখুঁত সংজ্ঞা খোঁজার পরিবর্তে, আমি আপনাকে InnerSource অনুভব করতে উৎসাহিত করি:

  • আপনি যে সমস্যা দেখেন তা বর্ণনা করে একটি ইস্যু জমা দিন
  • ডকুমেন্টেশন ঠিক করে একটি পুল রিকোয়েস্ট পাঠান
  • অন্য দলের কাছে একটি ফিচার অনুরোধ করুন
  • সহকর্মীদের সাথে আপনার কোড শেয়ার করুন
  • অন্যান্য দল কী তৈরি করছে তা অন্বেষণ করুন
  • সাংগঠনিক সীমানা জুড়ে সহযোগিতা করুন

অনুশীলনের মাধ্যমে, আপনি আবিষ্কার করবেন InnerSource আপনার সংস্থার জন্য কী অর্থ বহন করে। আপনি এমনকি নতুন প্যাটার্ন আবিষ্কার করতে পারেন যা আমাদের বাকিরা শিখতে পারি।

কথোপকথনে যোগ দিন #

২০২৫ সালে, যখন AI আমাদের কোড লেখা এবং সহযোগিতার পদ্ধতি রূপান্তরিত করছে, InnerSource নীতিগুলো আরও প্রাসঙ্গিক হয়ে উঠেছে। AI যখন তাৎক্ষণিকভাবে হাজার হাজার লাইন তৈরি করতে পারে তখন আমরা কীভাবে গুণমান বজায় রাখি? কোড তৈরি অটোমেটেড হলে আমরা কীভাবে জ্ঞান ভাগাভাগি সংরক্ষণ করি? আমরা কীভাবে নিশ্চিত করি যে মানুষের বিচার সফটওয়্যার ডেভেলপমেন্টের কেন্দ্রে থাকে?

এই বিষয়ের জন্য, অনুগ্রহ করে AI যুগে সহযোগিতার পদ্ধতি কভার করে এমন নিবন্ধটি দেখুন।

ভাল, এই প্রশ্নগুলোর এখনো উত্তর নেই, কিন্তু আমি বিশ্বাস করি InnerSource —এর খোলামেলাতা, স্বচ্ছতা, অগ্রাধিকারপ্রাপ্ত মেন্টরশিপ এবং স্বেচ্ছাসেবী কোড অবদানের উপর জোর দিয়ে—এগুলো অন্বেষণ করার জন্য অনন্যভাবে অবস্থানে রয়েছে।

InnerSource এর অনেক স্বাদ আছে। আপনি আপনার নিজস্ব যোগ করতে পারেন। আপনি এমন প্যাটার্নের নাম দিতে পারেন যা বিদ্যমান কিন্তু স্পষ্ট করা হয়নি। এই কারণেই InnerSource উত্তেজনাপূর্ণ: এটি এমন একটি ব্যানার যার অধীনে একটি কমিউনিটি বেড়ে ওঠে, বিবর্তিত হয় এবং উদ্ভাবন ছড়িয়ে দেয়।

InnerSource Commons Foundation এই আলোচনাগুলোকে স্বাগত জানায়। আমাদের কমিউনিটির সদস্যরা প্রতিদিন এই প্রশ্নগুলো অন্বেষণ করছে, অভিজ্ঞতা শেয়ার করছে এবং অভ্যন্তরীণ সহযোগিতার ভবিষ্যত তৈরি করছে।

তাই আমি আপনাকে জিজ্ঞেস করি: আপনার InnerSource কী? আপনি আপনার সংস্থার জন্য এটি কীভাবে সংজ্ঞায়িত করবেন? আপনি কী প্যাটার্ন আবিষ্কার করবেন এবং শেয়ার করবেন?

আসুন একসাথে এই প্রশ্নগুলো অন্বেষণ করি। যাত্রা এইমাত্র শুরু হয়েছে। আমি innersourcecommons.org এ কথোপকথনে আপনাকে স্বাগত জানানোর অপেক্ষায় আছি।

Yuki Hattori

Yuki Hattori

President of the InnerSource Commons Foundation
Sr. Architect at GitHub
Open Source Technical Advisor at IPA (Japanese government administration)
Author of two books on AI and GitHub
O’Reilly books translator for Prompt Enginnering for LLMs and two InnerSource books[1][2]
 
Opinions expressed here are my own and do not represent any organization I am affiliated with.