اوپن سورس کا “کیا” اور “کیوں”
تو آپ اوپن سورس کے ساتھ شروع کرنے کے بارے میں سوچ رہے ہیں؟ مبارک ہو! دنیا آپ کے تعاون کی تعریف کرتی ہے۔ آئیے اس بارے میں بات کرتے ہیں کہ اوپن سورس کیا ہے اور لوگ ایسا کیوں کرتے ہیں۔
“اوپن سورس” کا کیا مطلب ہے؟
جب کوئی پروجیکٹ اوپن سورس ہوتا ہے، تو اس کا مطلب ہے کہ کوئی بھی شخص کسی بھی مقصد کے لیے آپ کے پروجیکٹ کو استعمال کرنے، مطالعہ کرنے، اس میں ترمیم کرنے اور تقسیم کرنے کے لیے آزاد ہے۔ یہ اجازتیں [اوپن سورس لائسنس] (https://opensource.org) کے ذریعے نافذ کی جاتی ہیں۔ /لائسنس)۔
اوپن سورس طاقتور ہے کیونکہ یہ اپنانے اور تعاون کی راہ میں حائل رکاوٹوں کو کم کرتا ہے، جس سے لوگوں کو پراجیکٹس کو تیزی سے پھیلانے اور بہتر بنانے کا موقع ملتا ہے۔ اس کے علاوہ اس لیے کہ یہ صارفین کو اپنے کمپیوٹنگ کو کنٹرول کرنے کی صلاحیت فراہم کرتا ہے، جو بند سورس کے مقابلے میں ہے۔ مثال کے طور پر، اوپن سورس سافٹ ویئر استعمال کرنے والے کاروبار کے پاس کسی بند سورس وینڈر کے پروڈکٹ کے فیصلوں پر مکمل انحصار کرنے کے بجائے، سافٹ ویئر میں اپنی مرضی کے مطابق بہتری لانے کے لیے کسی کی خدمات حاصل کرنے کا اختیار ہوتا ہے۔
Free software سے مراد پروجیکٹس کے وہی سیٹ ہیں جیسے open source۔ بعض اوقات آپ یہ شرائط کو “فری اور اوپن سورس سافٹ ویئر” (FOSS) یا “مفت، آزاد اور اوپن سورس سافٹ ویئر” کے طور پر بھی دیکھیں گے۔ (فلوس)۔ Free_اور_libre آزادی کا حوالہ دیتے ہیں، قیمت نہیں۔
لوگ اپنے کام کو اوپن سورس کیوں کرتے ہیں؟
اس کی بہت سی وجوہات ہیں کیوں کوئی شخص یا ادارہ کسی پروجیکٹ کو اوپن سورس کرنا چاہے گا۔ کچھ مثالوں میں شامل ہیں:
-
تعاون: اوپن سورس پروجیکٹس دنیا میں کسی سے بھی تبدیلیاں قبول کر سکتے ہیں۔ Exercism، مثال کے طور پر، 350 سے زیادہ شراکت داروں کے ساتھ ایک پروگرامنگ ورزش پلیٹ فارم ہے۔
-
گود لینا اور دوبارہ مکس کرنا: اوپن سورس پروجیکٹس کو کوئی بھی تقریباً کسی بھی مقصد کے لیے استعمال کرسکتا ہے۔ لوگ اسے دوسری چیزیں بنانے کے لیے بھی استعمال کر سکتے ہیں۔ WordPress، مثال کے طور پر، b2۔
-
شفافیت: کوئی بھی غلطیوں یا عدم مطابقتوں کے لیے اوپن سورس پروجیکٹ کا معائنہ کر سکتا ہے۔ بلغاریہ یا ریاستہائے متحدہ جیسی حکومتوں کے لیے شفافیت کے معاملات .gov/)، ریگولیٹڈ انڈسٹریز جیسے بینکنگ یا ہیلتھ کیئر، اور سیکیورٹی سافٹ ویئر جیسے Let’s Encrypt۔
اوپن سورس صرف سافٹ ویئر کے لیے نہیں ہے۔ آپ ڈیٹا سیٹ سے لے کر کتابوں تک سب کچھ کھول سکتے ہیں۔ آپ اور کیا اوپن سورس کر سکتے ہیں اس بارے میں خیالات کے لیے GitHub Explore کو دیکھیں۔
کیا اوپن سورس کا مطلب “مفت” ہے؟
اوپن سورس کی سب سے بڑی قرعہ اندازی یہ ہے کہ اس پر پیسہ خرچ نہیں ہوتا ہے۔ “مفت”، تاہم، اوپن سورس کی مجموعی قدر کا ایک ضمنی پروڈکٹ ہے۔
چونکہ اوپن سورس لائسنس کی ضرورت ہوتی ہے جسے کوئی بھی آپ کے پروجیکٹ کو تقریباً کسی بھی مقصد کے لیے استعمال، اس میں ترمیم اور اشتراک کر سکتا ہے، اس لیے پروجیکٹ خود ہی مفت ہوتے ہیں۔ اگر اس منصوبے کے استعمال میں پیسے خرچ ہوتے ہیں، تو کوئی بھی قانونی طور پر ایک کاپی بنا سکتا ہے اور اس کے بجائے مفت ورژن استعمال کر سکتا ہے۔
نتیجے کے طور پر، زیادہ تر اوپن سورس پروجیکٹ مفت ہیں، لیکن “مفت” اوپن سورس کی تعریف کا حصہ نہیں ہے۔ اوپن سورس پروجیکٹس کے لیے بالواسطہ طور پر دوہری لائسنسنگ یا محدود خصوصیات کے ذریعے چارج کرنے کے طریقے موجود ہیں، جبکہ اوپن سورس کی آفیشل تعریف کی تعمیل کرتے ہوئے بھی۔
کیا مجھے اپنا اوپن سورس پروجیکٹ شروع کرنا چاہیے؟
مختصر جواب ہاں میں ہے، کیونکہ نتیجہ کچھ بھی ہو، اپنا پروجیکٹ شروع کرنا یہ جاننے کا بہترین طریقہ ہے کہ اوپن سورس کیسے کام کرتا ہے۔
اگر آپ نے پہلے کبھی بھی اوپن سورس شدہ پروجیکٹ کو نہیں کھولا ہے، تو آپ اس بات سے گھبرا سکتے ہیں کہ لوگ کیا کہیں گے، یا کسی کو بالکل بھی نظر آئے گا۔ اگر یہ آپ کی طرح لگتا ہے، تو آپ اکیلے نہیں ہیں!
اوپن سورس کام کسی بھی دوسری تخلیقی سرگرمی کی طرح ہے، چاہے وہ تحریر ہو یا پینٹنگ۔ دنیا کے ساتھ اپنے کام کا اشتراک کرنا خوفناک محسوس ہوسکتا ہے، لیکن بہتر ہونے کا واحد طریقہ مشق کرنا ہے - چاہے آپ کے سامعین نہ ہوں۔
اگر آپ ابھی تک قائل نہیں ہیں، تو سوچیں کہ آپ کے مقاصد کیا ہو سکتے ہیں۔
اپنے اہداف کا تعین کرنا
اہداف آپ کو یہ جاننے میں مدد کر سکتے ہیں کہ کس چیز پر کام کرنا ہے، کس چیز کو نہیں کہنا ہے، اور آپ کو دوسروں سے کہاں مدد کی ضرورت ہے۔ اپنے آپ سے پوچھ کر شروع کریں، میں اس پروجیکٹ کو اوپن سورس کیوں کر رہا ہوں؟
اس سوال کا کوئی صحیح جواب نہیں ہے۔ آپ کے ایک پروجیکٹ کے لیے ایک سے زیادہ اہداف ہوسکتے ہیں، یا مختلف اہداف کے ساتھ مختلف پروجیکٹس۔
اگر آپ کا واحد مقصد اپنے کام کو ظاہر کرنا ہے، تو ہو سکتا ہے آپ کو تعاون بھی نہ چاہیں، اور یہاں تک کہ اپنے README میں بھی کہہ دیں۔ دوسری طرف، اگر آپ شراکت دار چاہتے ہیں، تو آپ واضح دستاویزات میں وقت لگائیں گے اور نئے آنے والوں کو خوش آئند محسوس کریں گے۔
جیسے جیسے آپ کا پروجیکٹ بڑھتا ہے، آپ کی کمیونٹی کو آپ کے کوڈ سے زیادہ کی ضرورت ہو سکتی ہے۔ مسائل کا جواب دینا، کوڈ کا جائزہ لینا، اور اپنے پروجیکٹ کی بشارت دینا اوپن سورس پروجیکٹ میں تمام اہم کام ہیں۔
اگرچہ آپ نان کوڈنگ کے کاموں پر جتنا وقت صرف کرتے ہیں اس کا انحصار آپ کے پروجیکٹ کے سائز اور دائرہ کار پر ہوگا، آپ کو ایک مینٹینر کے طور پر تیار رہنا چاہیے کہ وہ خود ان سے نمٹنے کے لیے یا آپ کی مدد کے لیے کسی کو تلاش کریں۔
اگر آپ کسی پروجیکٹ کو اوپن سورس کرنے والی کمپنی کا حصہ ہیں، تو یقینی بنائیں کہ آپ کے پروجیکٹ میں داخلی وسائل ہیں جو اسے پھلنے پھولنے کے لیے درکار ہیں۔ آپ اس بات کی نشاندہی کرنا چاہیں گے کہ لانچ کے بعد پراجیکٹ کو برقرار رکھنے کا ذمہ دار کون ہے، اور آپ ان کاموں کو اپنی کمیونٹی کے ساتھ کیسے بانٹیں گے۔
اگر آپ کو پروموشن، آپریشنز اور پراجیکٹ کو برقرار رکھنے کے لیے وقف بجٹ یا عملہ کی ضرورت ہے، تو وہ بات چیت جلد شروع کریں۔
دوسرے منصوبوں میں تعاون کرنا
اگر آپ کا مقصد دوسروں کے ساتھ تعاون کرنے کا طریقہ سیکھنا ہے یا یہ سمجھنا ہے کہ اوپن سورس کیسے کام کرتا ہے، تو موجودہ پروجیکٹ میں تعاون کرنے پر غور کریں۔ ایک پروجیکٹ کے ساتھ شروع کریں جسے آپ پہلے سے استعمال کرتے ہیں اور پسند کرتے ہیں۔ کسی پروجیکٹ میں تعاون اتنا ہی آسان ہوسکتا ہے جتنا کہ ٹائپ کی غلطیوں کو ٹھیک کرنا یا دستاویزات کو اپ ڈیٹ کرنا۔
اگر آپ اس بات کا یقین نہیں کر رہے ہیں کہ شراکت کنندہ کے طور پر کیسے شروع کیا جائے، تو ہماری [اوپن سورس میں تعاون کرنے کا طریقہ] (../how-to-contribute/) دیکھیں۔
آپ کا اپنا اوپن سورس پروجیکٹ شروع کرنا
آپ کے کام کو اوپن سورس کرنے کا کوئی بہترین وقت نہیں ہے۔ آپ کسی آئیڈیا کو اوپن سورس کر سکتے ہیں، کوئی کام جاری ہے، یا سالوں کے بند سورس ہونے کے بعد۔
عام طور پر، آپ کو اپنے پروجیکٹ کو اوپن سورس کرنا چاہیے جب آپ دوسروں کو اپنے کام کو دیکھنے اور اس پر رائے دینے میں راحت محسوس کریں۔
اس سے کوئی فرق نہیں پڑتا ہے کہ آپ اپنے پروجیکٹ کو اوپن سورس کرنے کا فیصلہ کرتے ہیں، ہر پروجیکٹ میں درج ذیل دستاویزات شامل ہونی چاہئیں:
ایک دیکھ بھال کرنے والے کے طور پر، یہ اجزاء آپ کو توقعات سے بات چیت کرنے، شراکت کا نظم کرنے، اور ہر ایک کے قانونی حقوق (بشمول آپ کے اپنے) کے تحفظ میں مدد کریں گے۔ وہ آپ کے مثبت تجربہ کرنے کے امکانات کو نمایاں طور پر بڑھا دیتے ہیں۔
اگر آپ کا پروجیکٹ GitHub پر ہے، تو ان فائلوں کو اپنی روٹ ڈائرکٹری میں تجویز کردہ فائل ناموں کے ساتھ ڈالنے سے GitHub کو پہچاننے اور خود بخود آپ کے قارئین کے سامنے لانے میں مدد ملے گی۔
لائسنس کا انتخاب
اوپن سورس لائسنس اس بات کی ضمانت دیتا ہے کہ دوسرے آپ کے پراجیکٹ کو استعمال کر سکتے ہیں، کاپی کر سکتے ہیں، اس میں ترمیم کر سکتے ہیں اور بغیر کسی نقصان کے آپ کے پروجیکٹ میں حصہ ڈال سکتے ہیں۔ یہ آپ کو چپچپا قانونی حالات سے بھی بچاتا ہے۔ آپ کو اوپن سورس پروجیکٹ شروع کرتے وقت لائسنس شامل کرنا ہوگا۔
قانونی کام کوئی مزہ نہیں ہے۔ اچھی خبر یہ ہے کہ آپ موجودہ لائسنس کو اپنے ذخیرے میں کاپی اور پیسٹ کر سکتے ہیں۔ آپ کی محنت کی حفاظت میں صرف ایک منٹ لگے گا۔
MIT، Apache 2.0، اور GPLv3 سب سے زیادہ مقبول اوپن سورس لائسنس ہیں، لیکن دوسرے اختیارات ہیں میں سے انتخاب کریں۔
جب آپ GitHub پر ایک نیا پروجیکٹ بناتے ہیں، تو آپ کو لائسنس منتخب کرنے کا اختیار دیا جاتا ہے۔ اوپن سورس لائسنس کو شامل کرنا آپ کے GitHub پروجیکٹ کو اوپن سورس بنا دے گا۔
اگر آپ کے پاس اوپن سورس پروجیکٹ کے انتظام کے قانونی پہلوؤں کے بارے میں دیگر سوالات یا خدشات ہیں تو، ہم نے آپ کو کور کر لیا ہے۔
ایک README لکھنا
READMEs آپ کے پروجیکٹ کو استعمال کرنے کے طریقے کی وضاحت سے زیادہ کام کرتے ہیں۔ وہ یہ بھی بتاتے ہیں کہ آپ کا پروجیکٹ کیوں اہمیت رکھتا ہے، اور آپ کے صارفین اس کے ساتھ کیا کر سکتے ہیں۔
اپنے README میں، درج ذیل سوالات کے جواب دینے کی کوشش کریں:
- یہ پروجیکٹ کیا کرتا ہے؟
- یہ منصوبہ مفید کیوں ہے؟
- میں کیسے شروع کروں؟
- اگر مجھے ضرورت ہو تو مجھے مزید مدد کہاں سے مل سکتی ہے؟
آپ اپنے README کو دوسرے سوالات کے جوابات دینے کے لیے استعمال کر سکتے ہیں، جیسے کہ آپ شراکت کو کیسے ہینڈل کرتے ہیں، پروجیکٹ کے مقاصد کیا ہیں، اور لائسنس اور انتساب کے بارے میں معلومات۔ اگر آپ شراکتیں قبول نہیں کرنا چاہتے، یا آپ کا پروجیکٹ ابھی پروڈکشن کے لیے تیار نہیں ہے، تو یہ معلومات لکھ دیں۔
بعض اوقات، لوگ README لکھنے سے گریز کرتے ہیں کیونکہ انہیں لگتا ہے کہ پروجیکٹ نامکمل ہے، یا وہ شراکت نہیں چاہتے ہیں۔ یہ سب ایک لکھنے کی بہت اچھی وجوہات ہیں۔
مزید حوصلہ افزائی کے لیے، @dguo کی “ReADME بنائیں” گائیڈ یا @PurpleBooth کی README ٹیمپلیٹ استعمال کرنے کی کوشش کریں۔ مکمل README لکھنے کے لیے۔
جب آپ روٹ ڈائرکٹری میں README فائل شامل کرتے ہیں، تو GitHub اسے خودکار طور پر ریپوزٹری ہوم پیج پر ظاہر کرے گا۔
اپنے تعاون کے رہنما خطوط لکھنا
ایک CONTRIBUTING فائل آپ کے سامعین کو بتاتی ہے کہ آپ کے پروجیکٹ میں کیسے حصہ لیا جائے۔ مثال کے طور پر، آپ اس پر معلومات شامل کر سکتے ہیں:
- بگ رپورٹ کیسے درج کی جائے (استعمال کرنے کی کوشش کریں issue and pull request templates)
- ایک نئی خصوصیت کی تجویز کیسے کریں۔
- اپنے ماحول کو ترتیب دینے اور ٹیسٹ چلانے کا طریقہ
تکنیکی تفصیلات کے علاوہ، ایک CONTRIBUTING فائل شراکت کے لیے آپ کی توقعات کو بتانے کا ایک موقع ہے، جیسے:
- شراکت کی وہ اقسام جن کی آپ تلاش کر رہے ہیں۔
- منصوبے کے لیے آپ کا روڈ میپ یا وژن
- تعاون کرنے والوں کو آپ سے کس طرح رابطہ کرنا چاہیے (یا نہیں ہونا چاہیے)
گرمجوشی، دوستانہ لہجے کا استعمال کرنا اور شراکت کے لیے مخصوص تجاویز پیش کرنا (جیسے دستاویزات لکھنا، یا ویب سائٹ بنانا) نئے آنے والوں کو شرکت کرنے کے لیے خوش آئند اور پرجوش محسوس کرنے میں ایک طویل سفر طے کر سکتا ہے۔
مثال کے طور پر، ایکٹو ایڈمن شروع کرتا ہے اس کا تعاون کرنے والی گائیڈ کے ساتھ:
سب سے پہلے، ایکٹو ایڈمن میں تعاون کرنے پر غور کرنے کے لیے آپ کا شکریہ۔ یہ آپ جیسے لوگ ہیں جو ایکٹو ایڈمن کو ایک بہترین ٹول بناتے ہیں۔
آپ کے پروجیکٹ کے ابتدائی مراحل میں، آپ کی CONTRIBUTING فائل آسان ہو سکتی ہے۔ آپ کو ہمیشہ یہ بتانا چاہیے کہ کیڑے یا فائل کے مسائل کی اطلاع کیسے دی جائے، اور شراکت کرنے کے لیے کوئی تکنیکی تقاضے (جیسے ٹیسٹ)۔
وقت گزرنے کے ساتھ، آپ اپنی CONTRIBUTING فائل میں دوسرے اکثر پوچھے گئے سوالات شامل کر سکتے ہیں۔ اس معلومات کو لکھنے کا مطلب ہے کہ بہت کم لوگ آپ سے وہی سوالات بار بار پوچھیں گے۔
اپنی CONTRIBUTING فائل لکھنے میں مزید مدد کے لیے، @nayafia کا contributing guide template یا @mozilla کا “کیسے کرنا ایک CONTRIBUTING.md” بنائیں۔
اپنے README سے اپنی CONTRIBUTING فائل سے لنک کریں، تاکہ زیادہ لوگ اسے دیکھ سکیں۔ اگر آپ [کونٹریبیوٹنگ فائل کو اپنے پروجیکٹ کے ریپوزٹری میں رکھتے ہیں] یا پل کی درخواست کھولتا ہے۔
!
ضابطہ اخلاق کا قیام
آخر میں، ضابطہ اخلاق آپ کے پروجیکٹ کے شرکاء کے لیے رویے کے لیے بنیادی اصول طے کرنے میں مدد کرتا ہے۔ یہ خاص طور پر قابل قدر ہے اگر آپ کسی کمیونٹی یا کمپنی کے لیے اوپن سورس پروجیکٹ شروع کر رہے ہیں۔ ایک ضابطہ اخلاق آپ کو صحت مند، تعمیری کمیونٹی کے رویے میں سہولت فراہم کرنے کا اختیار دیتا ہے، جس سے ایک مینٹینر کے طور پر آپ کے تناؤ کو کم کیا جائے گا۔
مزید معلومات کے لیے، ہماری کوڈ آف کنڈکٹ گائیڈ دیکھیں۔
بات چیت کرنے کے علاوہ کہ آپ شرکاء سے برتاؤ کی توقع کرتے ہیں، ایک ضابطہ اخلاق یہ بھی بیان کرتا ہے کہ یہ توقعات کس پر لاگو ہوتی ہیں، کب وہ لاگو ہوتی ہیں، اور اگر خلاف ورزی ہوتی ہے تو کیا کرنا چاہیے۔
اوپن سورس لائسنس کی طرح، ضابطہ اخلاق کے لیے بھی ابھرتے ہوئے معیارات ہیں، لہذا آپ کو خود لکھنے کی ضرورت نہیں ہے۔ Contributor Covenant ایک ڈراپ ان ضابطہ اخلاق ہے جسے [40,000 سے زیادہ اوپن سورس پروجیکٹس] (https://www.contributor-covenant.org/adopters) کے ذریعے استعمال کیا جاتا ہے )، بشمول Kubernetes، Rails، اور Swift۔ اس سے کوئی فرق نہیں پڑتا ہے کہ آپ جو بھی متن استعمال کرتے ہیں، آپ کو ضرورت پڑنے پر اپنے ضابطہ اخلاق کو نافذ کرنے کے لیے تیار رہنا چاہیے۔
متن کو براہ راست اپنے ذخیرہ میں CODE_OF_CONDUCT فائل میں چسپاں کریں۔ فائل کو اپنے پروجیکٹ کی روٹ ڈائرکٹری میں رکھیں تاکہ اسے تلاش کرنا آسان ہو، اور اسے اپنے README سے لنک کریں۔
اپنے پروجیکٹ کا نام اور برانڈنگ
برانڈنگ ایک چمکدار لوگو یا پرکشش پروجیکٹ کے نام سے زیادہ ہے۔ یہ اس بارے میں ہے کہ آپ اپنے پروجیکٹ کے بارے میں کیسے بات کرتے ہیں، اور آپ اپنے پیغام کے ساتھ کس تک پہنچتے ہیں۔
صحیح نام کا انتخاب
ایک ایسا نام منتخب کریں جو یاد رکھنے میں آسان ہو اور مثالی طور پر، پروجیکٹ کے کام کے بارے میں کچھ اندازہ ہو۔ مثال کے طور پر:
اگر آپ کسی موجودہ پروجیکٹ پر تعمیر کر رہے ہیں، تو ان کے نام کو بطور سابقہ استعمال کرنے سے یہ واضح کرنے میں مدد مل سکتی ہے کہ آپ کا پروجیکٹ کیا کرتا ہے (مثال کے طور پر، node-fetch ونڈو لاتا ہے Node.js پر .fetch)۔
سب سے بڑھ کر وضاحت پر غور کریں۔ پینس تفریحی ہیں، لیکن یاد رکھیں کہ کچھ لطیفے دوسری ثقافتوں یا آپ کے مختلف تجربات والے لوگوں کے لیے ترجمہ نہیں کر سکتے۔ آپ کے ممکنہ صارفین میں سے کچھ کمپنی کے ملازمین ہو سکتے ہیں: جب انہیں کام پر آپ کے پروجیکٹ کی وضاحت کرنی ہو تو آپ انہیں بے چین نہیں کرنا چاہتے!
نام کے تنازعات سے بچنا
اسی طرح کے نام کے ساتھ اوپن سورس پروجیکٹس کو چیک کریں، خاص طور پر اگر آپ ایک ہی زبان یا ماحولیاتی نظام کا اشتراک کرتے ہیں۔ اگر آپ کا نام کسی مشہور موجودہ پروجیکٹ کے ساتھ اوورلیپ ہوتا ہے، تو آپ اپنے سامعین کو الجھ سکتے ہیں۔
اگر آپ چاہتے ہیں کہ کوئی ویب سائٹ، ٹویٹر ہینڈل، یا دیگر پراپرٹیز آپ کے پروجیکٹ کی نمائندگی کریں، تو یقینی بنائیں کہ آپ اپنے مطلوبہ نام حاصل کر سکتے ہیں۔ مثالی طور پر، ذہنی سکون کے لیے ان ناموں کو ابھی محفوظ کریں، چاہے آپ ابھی ان کو استعمال کرنے کا ارادہ نہیں رکھتے۔
یقینی بنائیں کہ آپ کے پروجیکٹ کا نام کسی ٹریڈ مارک کی خلاف ورزی نہیں کرتا ہے۔ کوئی کمپنی آپ کو بعد میں اپنا پروجیکٹ ختم کرنے کے لیے کہہ سکتی ہے، یا آپ کے خلاف قانونی کارروائی بھی کر سکتی ہے۔ یہ صرف خطرے کے قابل نہیں ہے۔
آپ ٹریڈ مارک کے تنازعات کے لیے WIPO Global Brand Database کو چیک کر سکتے ہیں۔ اگر آپ کسی کمپنی میں ہیں، تو یہ ان چیزوں میں سے ایک ہے جس میں آپ کی قانونی ٹیم آپ کی مدد کر سکتی ہے۔
آخر میں، اپنے پروجیکٹ کے نام کے لیے فوری گوگل سرچ کریں۔ کیا لوگ آپ کے پروجیکٹ کو آسانی سے تلاش کر سکیں گے؟ کیا تلاش کے نتائج میں کچھ اور ظاہر ہوتا ہے جسے آپ نہیں چاہیں گے کہ وہ دیکھیں؟
آپ کیسے لکھتے ہیں (اور کوڈ) آپ کے برانڈ کو بھی متاثر کرتا ہے!
اپنے پروجیکٹ کی پوری زندگی میں، آپ بہت ساری تحریریں کریں گے: READMEs، سبق، کمیونٹی دستاویزات، مسائل کا جواب دینا، شاید نیوز لیٹر اور میلنگ لسٹ بھی۔
چاہے یہ آفیشل دستاویزات ہوں یا کوئی معمولی ای میل، آپ کا تحریری انداز آپ کے پروجیکٹ کے برانڈ کا حصہ ہے۔ اس بات پر غور کریں کہ آپ اپنے سامعین تک کیسے پہنچ سکتے ہیں اور کیا یہ وہی لہجہ ہے جسے آپ بیان کرنا چاہتے ہیں۔
گرم، جامع زبان کا استعمال (جیسے “وہ”، یہاں تک کہ جب ایک فرد کا حوالہ دے رہے ہوں) آپ کے پروجیکٹ کو نئے شراکت داروں کا خیرمقدم کرنے کا احساس دلانے میں بہت آگے جا سکتا ہے۔ سادہ زبان پر قائم رہیں، کیونکہ ہو سکتا ہے آپ کے بہت سے قارئین مقامی انگریزی بولنے والے نہ ہوں۔
آپ الفاظ کیسے لکھتے ہیں اس کے علاوہ، آپ کا کوڈنگ کا انداز بھی آپ کے پروجیکٹ کے برانڈ کا حصہ بن سکتا ہے۔ Angular اور jQuery کوڈنگ کے سخت انداز اور رہنما خطوط کے ساتھ پروجیکٹس کی دو مثالیں ہیں۔
یہ ضروری نہیں ہے کہ آپ اپنے پروجیکٹ کے لیے اسٹائل گائیڈ لکھیں جب آپ ابھی شروعات کر رہے ہوں، اور آپ کو معلوم ہو سکتا ہے کہ آپ اپنے پروجیکٹ میں مختلف کوڈنگ اسٹائلز کو شامل کرنے سے لطف اندوز ہوتے ہیں۔ لیکن آپ کو اندازہ لگانا چاہیے کہ آپ کی تحریر اور کوڈنگ کا انداز مختلف قسم کے لوگوں کو کس طرح اپنی طرف متوجہ یا حوصلہ شکنی کر سکتا ہے۔ آپ کے پروجیکٹ کے ابتدائی مراحل آپ کے لیے وہ نظیر قائم کرنے کا موقع ہیں جسے آپ دیکھنا چاہتے ہیں۔
آپ کی پری لانچ چیک لسٹ
اپنے پروجیکٹ کو اوپن سورس کرنے کے لیے تیار ہیں؟ مدد کے لیے یہاں ایک چیک لسٹ ہے۔ تمام خانوں کو چیک کریں؟ آپ جانے کے لیے تیار ہیں! “شائع کریں” پر کلک کریں اور اپنے آپ کو پیٹھ پر تھپتھپائیں۔
دستاویزات
کوڈ
لوگ
اگر آپ ایک فرد ہیں:
اگر آپ ایک کمپنی یا تنظیم ہیں:
تم نے یہ کیا!
آپ کے پہلے پروجیکٹ کو اوپن سورس کرنے پر مبارکباد۔ نتائج سے کوئی فرق نہیں پڑتا، عوام میں کام کرنا کمیونٹی کے لیے ایک تحفہ ہے۔ ہر عزم، تبصرہ، اور پل کی درخواست کے ساتھ، آپ اپنے لیے اور دوسروں کے لیے سیکھنے اور بڑھنے کے مواقع پیدا کر رہے ہیں۔
