কিভাবে একটি ওপেন সোর্স প্রজেক্ট তৈরি করবেন

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

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

আমরা খোলা লাইসেন্সের সমস্যাগুলি স্পর্শ করব না। এটি অত্যন্ত বড় এবং জটিল একটি বিষয় যার জন্য গভীর তদন্ত প্রয়োজন৷ এই বিষয়ে বেশ ভাল নিবন্ধ এবং উপকরণ অনেক লেখা হয়েছে. কিন্তু যেহেতু আমি নিজে কপিরাইটের ক্ষেত্রে বিশেষজ্ঞ নই, তাই আমি শুধু বলব যে লাইসেন্সটি অবশ্যই প্রকল্পের লক্ষ্য পূরণ করতে হবে। উদাহরণস্বরূপ, এমবক্সের জন্য একটি GPL লাইসেন্সের পরিবর্তে একটি BSD পছন্দ দুর্ঘটনাজনিত ছিল না।

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

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

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

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

ওপেনসোর্স প্রকল্প তৈরির সুবিধা সেখানে শেষ হয় না। বিপণন হিসাবে ব্যবসা যেমন একটি গুরুত্বপূর্ণ উপাদান ধরা যাক. তার জন্য, এটি একটি খুব ভাল স্যান্ডবক্স যা তাকে কার্যকরভাবে বাজারের প্রয়োজনীয়তা মূল্যায়ন করতে দেয়।

এবং অবশ্যই, আমাদের অবশ্যই ভুলে যাওয়া উচিত নয় যে একটি ওপেনসোর্স প্রজেক্ট নিজেকে যেকোন বিশেষীকরণের বাহক হিসাবে ঘোষণা করার একটি কার্যকর উপায়। কিছু ক্ষেত্রে, এটি বাজারে প্রবেশের একমাত্র উপায়। উদাহরণস্বরূপ, Embox একটি RTOS তৈরির একটি প্রকল্প হিসাবে শুরু হয়েছিল। প্রতিযোগী অনেক আছে ব্যাখ্যা করার কোন প্রয়োজন সম্ভবত নেই. একটি সম্প্রদায় তৈরি না করে, আমাদের কাছে প্রকল্পটি শেষ ব্যবহারকারীর কাছে আনার জন্য পর্যাপ্ত সম্পদ থাকত না, অর্থাৎ তৃতীয় পক্ষের বিকাশকারীদের জন্য প্রকল্পটি ব্যবহার শুরু করার জন্য।

সম্প্রদায় একটি ওপেনসোর্স প্রকল্পের মূল বিষয়। এটি আপনাকে উল্লেখযোগ্যভাবে প্রকল্প পরিচালনার খরচ কমাতে, প্রকল্পের বিকাশ এবং সমর্থন করতে দেয়। আমরা বলতে পারি যে একটি সম্প্রদায় ছাড়া কোনও ওপেনসোর্স প্রকল্প নেই।

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

একটি ওপেনসোর্স প্রকল্প সম্প্রদায় তৈরি করার সময় প্রধান নিয়ম হল কোন নিয়ম নেই। আমি বলতে চাচ্ছি যে কোনও সার্বজনীন নিয়ম নেই, যেমন কোনও সিলভার বুলেট নেই, যদি শুধুমাত্র প্রকল্পগুলি খুব আলাদা হয়। এটি অসম্ভাব্য যে আপনি একটি js লগিং লাইব্রেরি এবং কিছু অত্যন্ত বিশেষ ড্রাইভারের জন্য একটি সম্প্রদায় তৈরি করার সময় একই নিয়ম ব্যবহার করতে পারেন। তদুপরি, প্রকল্পের উন্নয়নের বিভিন্ন পর্যায়ে (এবং সেইজন্য সম্প্রদায়), নিয়মগুলি পরিবর্তিত হয়।

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

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

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

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

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

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

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

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

উপসংহারে আমি উল্লেখ করতে চাই মন্তব্য, আমার মতে, একটি ওপেনসোর্স প্রকল্প থেকে ব্যবহারকারীর প্রত্যাশা প্রতিফলিত করে:

আমি এই ওএসে স্যুইচ করার বিষয়ে গুরুত্ব সহকারে চিন্তা করছি (অন্তত চেষ্টা করুন। তারা সক্রিয়ভাবে এটি অনুসরণ করছে এবং দুর্দান্ত জিনিস করছে)।

পিএস চালু টেক ট্রেন আমাদের কাছে তিনটি রিপোর্ট থাকবে। একটি ওপেন সোর্স সম্পর্কে এবং দুটি এমবেডেড সম্পর্কে (এবং একটি ব্যবহারিক)। স্ট্যান্ডে আমরা প্রোগ্রামিং মাইক্রোকন্ট্রোলার ব্যবহার করে একটি মাস্টার ক্লাস পরিচালনা করব এমবক্স. যথারীতি, আমরা হার্ডওয়্যার আনব এবং আপনাকে এটি প্রোগ্রাম করতে দেব। এছাড়াও একটি অনুসন্ধান এবং অন্যান্য কার্যক্রম হবে. উৎসবে এসে আমাদের স্ট্যান্ড, মজা হবে।

উত্স: www.habr.com