اپنے بڑھتے ہوئے پروجیکٹ کے لیے گورننس کو سمجھنا

آپ کا پروجیکٹ بڑھ رہا ہے، لوگ مصروف ہیں، اور آپ اس چیز کو جاری رکھنے کے لیے پرعزم ہیں۔ اس مرحلے پر، آپ سوچ رہے ہوں گے کہ اپنے ورک فلو میں باقاعدہ پروجیکٹ کے شراکت داروں کو کیسے شامل کیا جائے، چاہے یہ کسی کو کمٹٹ رسائی دے رہا ہو یا کمیونٹی کے مباحثوں کو حل کر رہا ہو۔ اگر آپ کے سوالات ہیں، تو ہمارے پاس جوابات ہیں۔

اوپن سورس پروجیکٹس میں استعمال ہونے والے رسمی کرداروں کی کیا مثالیں ہیں؟

بہت سے منصوبے شراکت داروں کے کردار اور شناخت کے لیے ایک جیسے ڈھانچے کی پیروی کرتے ہیں۔

ان کرداروں کا اصل میں کیا مطلب ہے، اگرچہ، مکمل طور پر آپ پر منحصر ہے۔ یہاں چند قسم کے کردار ہیں جنہیں آپ پہچان سکتے ہیں:

* دیکھ بھال کرنے والا مضمون کنندہ کمیٹر

کچھ پروجیکٹس کے لیے، “مینٹینرز” پروجیکٹ میں واحد لوگ ہوتے ہیں جن کے پاس کمٹٹ رسائی ہوتی ہے۔ دوسرے پروجیکٹس میں، وہ صرف وہ لوگ ہیں جو README میں دیکھ بھال کرنے والے کے طور پر درج ہیں۔

ضروری نہیں کہ مینٹینر کوئی ایسا شخص ہو جو آپ کے پروجیکٹ کے لیے کوڈ لکھتا ہو۔ یہ کوئی ایسا شخص ہو سکتا ہے جس نے آپ کے پروجیکٹ کی بشارت کے لیے بہت زیادہ کام کیا ہو، یا تحریری دستاویزات جس نے پروجیکٹ کو دوسروں کے لیے زیادہ قابل رسائی بنایا ہو۔ اس سے قطع نظر کہ وہ روزانہ کیا کرتے ہیں، ایک مینٹینر شاید وہ ہوتا ہے جو پروجیکٹ کی سمت پر ذمہ داری محسوس کرتا ہے اور اسے بہتر بنانے کے لیے پرعزم ہے۔

ایک “مطالعہ کرنے والا” کوئی بھی ہو سکتا ہے جو کسی مسئلے پر تبصرہ کرتا ہے یا پل کی درخواست کرتا ہے، وہ لوگ جو پروجیکٹ میں اہمیت کا اضافہ کرتے ہیں (چاہے یہ ٹریجنگ ایشوز ہوں، کوڈ لکھیں، یا ایونٹس کا اہتمام کریں) یا ضم شدہ پل کی درخواست والا کوئی بھی ہو (شاید شراکت دار کی سب سے تنگ تعریف)۔

** اصطلاح “کامیٹر”** کا استعمال کمٹ رسائی کو الگ کرنے کے لیے کیا جا سکتا ہے، جو کہ ایک مخصوص قسم کی ذمہ داری ہے، شراکت کی دیگر اقسام سے۔

جب کہ آپ اپنے پروجیکٹ کے کردار کو اپنی مرضی کے مطابق بیان کر سکتے ہیں، شراکت کی مزید اقسام کی حوصلہ افزائی کے لیے وسیع تر تعریفیں استعمال کرنے پر غور کریں۔ آپ قائدانہ کرداروں کا استعمال ان لوگوں کو باضابطہ طور پر پہچاننے کے لیے کر سکتے ہیں جنہوں نے آپ کے پراجیکٹ میں نمایاں شراکت کی ہے، چاہے ان کی تکنیکی مہارت کچھ بھی ہو۔

میں ان قائدانہ کرداروں کو کیسے باضابطہ بناؤں؟

آپ کے قائدانہ کرداروں کو باضابطہ بنانے سے لوگوں کو ملکیت کا احساس کرنے میں مدد ملتی ہے اور وہ کمیونٹی کے دیگر ممبران کو بتاتے ہیں کہ کس کی مدد کرنا ہے۔

ایک چھوٹے پروجیکٹ کے لیے، لیڈروں کو نامزد کرنا اتنا ہی آسان ہو سکتا ہے جتنا کہ آپ کے README یا CONTRIBUTORS ٹیکسٹ فائل میں ان کے نام شامل کرنا۔

کسی بڑے پروجیکٹ کے لیے، اگر آپ کے پاس ویب سائٹ ہے، تو ایک ٹیم کا صفحہ بنائیں یا وہاں اپنے پروجیکٹ لیڈرز کی فہرست بنائیں۔ مثال کے طور پر، Postgres کا ایک جامع ٹیم صفحہ ہے جس میں ہر تعاون کنندہ کے مختصر پروفائلز ہیں۔

اگر آپ کے پروجیکٹ میں بہت فعال شراکت دار کمیونٹی ہے، تو آپ دیکھ بھال کرنے والوں کی ایک “بنیادی ٹیم” تشکیل دے سکتے ہیں، یا یہاں تک کہ ایسے لوگوں کی ذیلی کمیٹیاں بھی تشکیل دے سکتے ہیں جو مختلف ایشو ایریاز (مثال کے طور پر، سیکیورٹی، ایشو ٹرائجنگ، یا کمیونٹی کنڈکٹ) کی ملکیت حاصل کرتے ہیں۔ لوگوں کو انہیں تفویض کرنے کے بجائے خود کو منظم کرنے اور ان کرداروں کے لیے رضاکارانہ طور پر کام کرنے دیں۔

لیڈرشپ ٹیمیں ایک نامزد چینل (جیسے IRC پر) بنانا چاہتی ہیں یا پروجیکٹ پر بات کرنے کے لیے باقاعدگی سے مل سکتی ہیں (جیسے Gitter یا Google Hangout پر)۔ آپ ان ملاقاتوں کو عوامی بھی بنا سکتے ہیں تاکہ دوسرے لوگ سن سکیں۔ ککڑی-روبی، مثال کے طور پر، ہر ہفتے دفتری اوقات کی میزبانی کرتا ہے۔

ایک بار جب آپ قائدانہ کردار قائم کر لیں، تو یہ دستاویز کرنا نہ بھولیں کہ لوگ انہیں کیسے حاصل کر سکتے ہیں! ایک واضح عمل قائم کریں کہ کس طرح کوئی آپ کے پروجیکٹ میں مینٹینر بن سکتا ہے یا ذیلی کمیٹی میں شامل ہو سکتا ہے، اور اسے اپنی GOVERNANCE.md میں لکھیں۔

ٹولز جیسے Vossibility آپ کو عوامی طور پر ٹریک کرنے میں مدد کر سکتے ہیں کہ پروجیکٹ میں کون تعاون کر رہا ہے (یا نہیں کر رہا)۔ اس معلومات کو دستاویزی بنانا کمیونٹی کے اس تاثر سے بچتا ہے کہ دیکھ بھال کرنے والے ایک گروہ ہیں جو اپنے فیصلے نجی طور پر کرتے ہیں۔

آخر میں، اگر آپ کا پروجیکٹ GitHub پر ہے، تو اپنے پروجیکٹ کو اپنے ذاتی اکاؤنٹ سے کسی تنظیم میں منتقل کرنے اور کم از کم ایک بیک اپ ایڈمن کو شامل کرنے پر غور کریں۔ گٹ ہب آرگنائزیشنز اجازتوں اور متعدد ذخیروں کا نظم کرنا اور [مشترکہ ملکیت] کے ذریعے اپنے پروجیکٹ کی میراث کی حفاظت کرنا آسان بناتی ہیں۔ /building-community/#share-ownership-of-your-project)۔

میں کب کسی کو کمٹ کی رسائی دوں؟

کچھ لوگوں کا خیال ہے کہ آپ کو ہر اس شخص تک رسائی دینا چاہئے جو تعاون کرتا ہے۔ ایسا کرنے سے زیادہ لوگوں کو آپ کے پروجیکٹ کی ملکیت محسوس کرنے کی ترغیب مل سکتی ہے۔

دوسری طرف، خاص طور پر بڑے، زیادہ پیچیدہ منصوبوں کے لیے، آپ صرف ان لوگوں تک رسائی دینا چاہیں گے جنہوں نے اپنی وابستگی کا مظاہرہ کیا ہے۔ ایسا کرنے کا کوئی صحیح طریقہ نہیں ہے - وہ کریں جو آپ کو سب سے زیادہ آرام دہ بناتا ہے!

اگر آپ کا پروجیکٹ GitHub پر ہے، تو آپ protected branches کا استعمال کر سکتے ہیں تاکہ یہ انتظام کیا جا سکے کہ کون کسی خاص برانچ کو دھکیل سکتا ہے، اور کن حالات میں۔

اوپن سورس پروجیکٹس کے لیے کچھ عام گورننس ڈھانچے کیا ہیں؟

اوپن سورس پروجیکٹس کے ساتھ تین مشترکہ گورننس ڈھانچے وابستہ ہیں۔

  • BDFL: BDFL کا مطلب ہے “زندگی کے لیے فلاحی آمر”۔ اس ڈھانچے کے تحت، ایک شخص (عام طور پر پروجیکٹ کا ابتدائی مصنف) تمام بڑے پروجیکٹ فیصلوں پر حتمی رائے رکھتا ہے۔ Python ایک بہترین مثال ہے۔ چھوٹے منصوبے شاید ڈیفالٹ کے طور پر BDFL ہوتے ہیں، کیونکہ صرف ایک یا دو مینٹینرز ہوتے ہیں۔ ایک پروجیکٹ جس کی ابتدا کسی کمپنی سے ہوئی ہو وہ بھی BDFL کے زمرے میں آ سکتی ہے۔

  • Meritocracy: ** (نوٹ: اصطلاح “میریٹوکریسی” کچھ کمیونٹیز کے لیے منفی معنی رکھتی ہے اور اس کی ایک [پیچیدہ سماجی اور سیاسی تاریخ] ہے (http://geekfeminism.wikia.com/wiki/Meritocracy)) ** میرٹ کریسی کے تحت، پراجیکٹ کے فعال شراکت داروں (جو “میرٹ” کا مظاہرہ کرتے ہیں) کو فیصلہ سازی کا باقاعدہ کردار دیا جاتا ہے۔ فیصلے عام طور پر خالص ووٹنگ اتفاق رائے کی بنیاد پر کیے جاتے ہیں۔ میرٹوکیسی کے تصور کا آغاز Apache Foundation نے کیا تھا۔ تمام اپاچی پروجیکٹس قابلیت ہیں۔ شراکتیں صرف اپنی نمائندگی کرنے والے افراد کی طرف سے کی جا سکتی ہیں، کمپنی کی طرف سے نہیں۔

  • لبرل شراکت: ایک لبرل کنٹریبیوشن ماڈل کے تحت، سب سے زیادہ کام کرنے والے لوگوں کو سب سے زیادہ بااثر تسلیم کیا جاتا ہے، لیکن یہ موجودہ کام پر مبنی ہے نہ کہ تاریخی شراکتوں پر۔ منصوبے کے بڑے فیصلے خالص ووٹ کی بجائے اتفاق رائے کے حصول کے عمل (بڑی شکایات پر بات چیت) کی بنیاد پر کیے جاتے ہیں، اور زیادہ سے زیادہ کمیونٹی کے نقطہ نظر کو شامل کرنے کی کوشش کرتے ہیں۔ لبرل کنٹری بیوشن ماڈل استعمال کرنے والے پروجیکٹس کی مشہور مثالوں میں Node.js اور Rust شامل ہیں۔

آپ کو کون سا استعمال کرنا چاہئے؟ یہ آپ پر منحصر ہے! ہر ماڈل کے فوائد اور تجارتی تعلقات ہیں۔ اور اگرچہ وہ پہلے تو بالکل مختلف لگ سکتے ہیں، تینوں ماڈلز میں ان سے کہیں زیادہ مشترک ہے۔ اگر آپ ان میں سے کسی ایک ماڈل کو اپنانے میں دلچسپی رکھتے ہیں، تو یہ ٹیمپلیٹس دیکھیں:

جب میں اپنا پروجیکٹ شروع کرتا ہوں تو کیا مجھے گورننس کے دستاویزات کی ضرورت ہے؟

اپنے پروجیکٹ کی گورننس کو لکھنے کا کوئی صحیح وقت نہیں ہے، لیکن جب آپ نے اپنی کمیونٹی کی حرکیات کو ختم ہوتے دیکھا ہے تو اس کی وضاحت کرنا بہت آسان ہے۔ اوپن سورس گورننس کے بارے میں سب سے بہترین (اور سب سے مشکل) حصہ یہ ہے کہ اس کی تشکیل کمیونٹی نے کی ہے!

کچھ ابتدائی دستاویزات لازمی طور پر آپ کے پروجیکٹ کی گورننس میں حصہ ڈالیں گی، تاہم، اس لیے لکھنا شروع کریں جو آپ کر سکتے ہیں۔ مثال کے طور پر، آپ رویے کے لیے واضح توقعات کی وضاحت کر سکتے ہیں، یا آپ کے تعاون کنندہ کا عمل کیسے کام کرتا ہے، یہاں تک کہ آپ کے پروجیکٹ کے آغاز پر بھی۔

اگر آپ اوپن سورس پروجیکٹ شروع کرنے والی کمپنی کا حصہ ہیں، تو لانچ کرنے سے پہلے اس بارے میں ایک اندرونی بات چیت کرنے کے قابل ہے کہ آپ کی کمپنی اس پروجیکٹ کو آگے بڑھنے کے بارے میں کیسے برقرار رکھنے اور فیصلے کرنے کی توقع رکھتی ہے۔ آپ عوامی طور پر کسی خاص بات کی وضاحت بھی کرنا چاہیں گے کہ آپ کی کمپنی اس منصوبے کے ساتھ کس طرح شامل ہوگی (یا نہیں کرے گی!)۔

اگر کارپوریٹ ملازمین چندہ جمع کرنا شروع کردیں تو کیا ہوگا؟

کامیاب اوپن سورس پروجیکٹس کو بہت سے لوگوں اور کمپنیوں کے ذریعہ استعمال کیا جاتا ہے، اور کچھ کمپنیاں آخر کار آمدنی کے سلسلے کو پروجیکٹ سے منسلک کرسکتی ہیں۔ مثال کے طور پر، ایک کمپنی تجارتی سروس کی پیشکش میں پروجیکٹ کے کوڈ کو ایک جزو کے طور پر استعمال کر سکتی ہے۔

جیسے جیسے اس پروجیکٹ کا وسیع پیمانے پر استعمال ہوتا جاتا ہے، اس میں مہارت رکھنے والے افراد کی مانگ میں اضافہ ہوتا جاتا ہے - ہو سکتا ہے آپ ان میں سے ایک ہو! - اور کبھی کبھی اس منصوبے میں کام کرنے کے لیے ادائیگی کی جائے گی۔

تجارتی سرگرمیوں کو معمول کے مطابق اور ترقی کی توانائی کا ایک اور ذریعہ سمجھنا ضروری ہے۔ بامعاوضہ ڈویلپرز کو بلا معاوضہ ڈیولپرز کے ساتھ خاص سلوک نہیں کرنا چاہیے، یقیناً۔ ہر شراکت کو اس کی تکنیکی خوبیوں پر جانچنا چاہیے۔ تاہم، لوگوں کو تجارتی سرگرمی میں مشغول ہونے میں آرام محسوس کرنا چاہیے، اور کسی خاص اضافہ یا خصوصیت کے حق میں بحث کرتے وقت اپنے استعمال کے معاملات بتاتے ہوئے آرام محسوس کرنا چاہیے۔

“کمرشل” مکمل طور پر “اوپن سورس” کے ساتھ مطابقت رکھتا ہے۔ “تجارتی” کا مطلب صرف یہ ہے کہ کہیں پیسہ شامل ہے - یہ کہ سافٹ ویئر کامرس میں استعمال ہوتا ہے، جس کا امکان بڑھتا جا رہا ہے جیسے جیسے کسی پروجیکٹ کو اپنایا جاتا ہے۔ (جب اوپن سورس سافٹ ویئر کو کسی غیر اوپن سورس پروڈکٹ کے حصے کے طور پر استعمال کیا جاتا ہے، تو مجموعی پروڈکٹ اب بھی “مالیداری” سافٹ ویئر ہے، حالانکہ اوپن سورس کی طرح، یہ تجارتی یا غیر تجارتی مقاصد کے لیے استعمال کیا جا سکتا ہے۔)

کسی اور کی طرح، تجارتی طور پر حوصلہ افزائی کرنے والے ڈویلپرز اپنے تعاون کے معیار اور مقدار کے ذریعے پروجیکٹ میں اثر و رسوخ حاصل کرتے ہیں۔ ظاہر ہے، ایک ڈویلپر جسے اس کے وقت کے لیے ادائیگی کی جاتی ہے وہ کسی ایسے شخص سے زیادہ کام کرنے کے قابل ہو سکتا ہے جسے ادا نہیں کیا جاتا، لیکن یہ ٹھیک ہے: ادائیگی بہت سے ممکنہ عوامل میں سے صرف ایک ہے جو متاثر کر سکتی ہے کہ کوئی شخص کتنا کرتا ہے۔ اپنے پراجیکٹ کے مباحثوں کو شراکت پر مرکوز رکھیں، نہ کہ ان بیرونی عوامل پر جو لوگوں کو یہ تعاون کرنے کے قابل بناتے ہیں۔

کیا مجھے اپنے پروجیکٹ کی حمایت کے لیے کسی قانونی ادارے کی ضرورت ہے؟

آپ کو اپنے اوپن سورس پروجیکٹ کو سپورٹ کرنے کے لیے کسی قانونی ادارے کی ضرورت نہیں ہے جب تک کہ آپ رقم ہینڈل نہ کر رہے ہوں۔

مثال کے طور پر، اگر آپ تجارتی کاروبار بنانا چاہتے ہیں، تو آپ C Corp یا LLC (اگر آپ امریکہ میں مقیم ہیں) قائم کرنا چاہیں گے۔ اگر آپ صرف اپنے اوپن سورس پروجیکٹ سے متعلق کنٹریکٹ کا کام کر رہے ہیں، تو آپ ایک واحد مالک کے طور پر رقم قبول کر سکتے ہیں، یا ایک LLC قائم کر سکتے ہیں (اگر آپ امریکہ میں مقیم ہیں)۔

اگر آپ اپنے اوپن سورس پروجیکٹ کے لیے عطیات قبول کرنا چاہتے ہیں، تو آپ عطیہ کا بٹن ترتیب دے سکتے ہیں (مثال کے طور پر پے پال یا اسٹرائپ کا استعمال کرتے ہوئے)، لیکن اس رقم پر ٹیکس کی کٹوتی نہیں ہوگی جب تک کہ آپ اہل غیر منفعتی (501c3، اگر آپ امریکہ میں ہیں)۔

بہت سے پروجیکٹس غیر منفعتی تنظیم قائم کرنے کی پریشانی سے گزرنا نہیں چاہتے ہیں، اس لیے وہ اس کے بجائے ایک غیر منفعتی مالی کفیل تلاش کرتے ہیں۔ ایک مالی کفیل آپ کی طرف سے عطیات قبول کرتا ہے، عام طور پر عطیہ کے فیصد کے بدلے میں۔ سافٹ ویئر فریڈم کنزروینسی، Apache Foundation، Eclipse Foundation، Linux Foundation اور Open Collective ان تنظیموں کی مثالیں ہیں جو اوپن سورس پروجیکٹس کے لیے مالی کفیل کے طور پر کام کرتی ہیں۔

اگر آپ کا پروجیکٹ کسی مخصوص زبان یا ماحولیاتی نظام کے ساتھ قریب سے وابستہ ہے، تو وہاں ایک متعلقہ سافٹ ویئر فاؤنڈیشن بھی ہو سکتی ہے جس کے ساتھ آپ کام کر سکتے ہیں۔ مثال کے طور پر، Python Software Foundation PyPI، Python پیکیج مینیجر، اور Node.js فاؤنڈیشن ایک نوڈ پر مبنی فریم ورک Express.js کو سپورٹ کرنے میں مدد کرتا ہے۔