| Note : این ترجمه ی مقاله ای هست که صدرا نوشته
ما از ابزار ها و نرم افزار های متن باز(Open-Source) بسیار زیادی در زندگی و مسیر فنیمون استفاده کردیم، اما اینها چطوری توسعه پیدا میکنن ؟ چطور مردم وقت میزارن که برنامه ی متن باز بنویسن و ازشون استفاده کنن ؟ ما چطور میتونیم جزئی از جامعه ی متن باز باشیم ؟
در این مقاله ما در مورد مباحث پشت پرده ی دنیای متن باز صحبت میکنیم و طریقه ای که شما میتونین سفرتون رو در دنیای متن باز به عنوان یه برنامه نویس شروع کنین و اخلاق و اصول حرفه ای دنیای متن باز چطوری هستن. اگر به مشارکت در دنیای متن باز علاقه مندید و میخواید که Maintainer(نگه دارنده) باشید، این نقطه ی خوبی برای شروعه. | شاید این مقاله اونقدر ها فنی نباشه ، اما من تمام سعیمو کردم که تجربیات خودم رو از زمانی که شروع به کار کردن روی پروژه های متن باز در پلتفورم Github کردم رو به اشتراک بزارم. من فرض میکنم که شما با ابزار های ساده توسعه دادن و برنامه نویسی آشنایی دارین و میخواین روی مخازن(Repositories) مورد علاقتون کار کنید.
در این بخش، میخوایم درمورد موارد قبل از شروع مشارکت به دنیای متن باز صحبت کنیم.
یک جامعه متن باز جایی است که اعضایی آن از سراسر جهان در کنار هم جمع شده اند تا به یکدیگر کمک کرده و راه حل های متنوعی برای مشکلات موجود در دنیای واقعی ایجاد کنند. همه با عشق مشارکت می کنند. بسیاری از مشارکت کنندگان در ازای راهنمایی ها و فعالیت هایی که انجام میدهند، هزینه ای دریافت نمی‌کنند. خوش برخورد بودن و احترام متقابل در جوامع متن باز، شایسته ترین اخلاق حرفه ایست. از آنجا که ممکن است با فرهنگ و رسوم دیگر مناطق جغرافیایی آشنا نباشید، بهتر هست همیشه خوش‌رو و محترم باشید.
سعی کنید اولین مشارکت های خود را روی پروژه ها و مخازن ساده تر و کوچک تر انجام دهید چرا که در اواین مرحله، درگیر پیچیدگی های پروژه نشده و مسیر توسعه و حل مشکل را به خوبی درک میکنید.
به‌عنوان مشارکت‌کننده، از مشارکت روی پروژه ای بیشتر احساس رضایت خواهید کرد که مدیران و انجمن‌های فعالی داشته باشد، بنابراین درخواست های شما به سرعت بررسی می‌شود و سؤالات شما سریعتر پاسخ داده می‌شوند. شما می توانید هر پروژه ای را که به نظرتان جالب است برای مشارکت انتخاب کنید. اطمینان حاصل کنید که آنها منسوخ نشده اند و مشارکت پذیر باشند. فایل README و/یا CONTRIBUTING را در مخزن بررسی و مطالعه کنید. ممکن است به دنبال پروژه هایی باشید که محصول شما به آنها متکی است یا حتی ممکن است در پروژه های محبوب تر مشارکت کنید تا رزومه کاری و تجربه کاری بهتری برای خود ایجاد کنید.
بسیاری از ابزارها اسناد (داکیومنت) خود را به زبان های مختلفی نگهداری و عرضه می‌کنند. بخش مستندات جایی است که اکثر مشارکت کنندگان جدید مشارکت خود را از آنجا شروع می کنند. می توانید مشکلات تایپی را پیدا کنید یا حتی شروع به ترجمه کل سند به زبان های دیگر کنید. از آنجا که برخی از پروژه‌ها گاهی اوقات به توسعه تست ها اهمیت آنچنانی نمی‌دهند، نوشتن تست‌های اینگونه پروژه ها نیز یک راه خوب شروع مشارکت است.
ممکن است گاها با یک ابزار/چارچوب منبع باز کار کنید. می بینید که ابزاری که استفاده می کنید از خود خطاهای غیرعادی متعددی بروز می دهد و مشکلی (باگ) در ابزار وجود دارد. شما مخزن آن را بررسی می کنید و مشکل را پیدا می کنید. شما تصمیم می گیرید روی آن کار کنید و آن اشکال را برطرف کنید. این نوع فعالیت نیز به عنوان یک کمک (مشارکت در توسعه) تلقی می شود.
شما به سادگی می توانید مشکلاتی که چندی پیش دیگر کاربران با آن مواجه شده اند را برطرف کنید. نیازی نیست حتما خودتان آن ها را تجربه کرده باشید. اکثر مخازن از تب مسائل (issue) GitHub استفاده می کنند. در بخش ایشو، مطمئن شوید که مکالمات خود را عمومی نگه دارید. تصمیمات و گفتگو های شما در Forum های بخش Issue ممکن است روزی به دیگر توسعه دهندگان/کاربران کمک کند.
یکی از جالب‌ترین بخش‌های متن باز زمانی است که می‌توانید با دیگر افراد از کشورهای مختلف ارتباط بگیرید. پیدا کردن دوستان جدید در دنیای متن باز برای شما یک بستر برای پیشرفت سریعتر ایجاد میکند. به انجمن ها، کنفرانس ها و گفتگو ها بپیوندید و سعی کنید با دیگران ارتباط برقرار کنید و از پروژه های متن باز آنها باخبر شوید.
اگر درخواست فیچری که از نظر شما کاملاً معقول است توسط یک مدیر رد شد، یا ماه ها از زمان ایجاد یک PR شما می گذرد و هنوز کسی آن را بررسی نکرده، ناامید نشوید. اگر PR شما بسته شود، دلیلی برای آن وجود داشته. با کمال احترام، دلیل را جویا شوید و در مشارکت های بعدی خود روی آن پروژه، این نکات را به یاد داشته باشید. آنها می‌خواهند پروژه را مانند شما رشد دهند، به همین دلیل است که من به شما پیشنهاد میکنم ابتدا ایده خود را در Issue ها مورد بحث قرار دهید و در مورد پیشرفت‌هایی که فکر میکنید بی‌نقص هستند صحبت کنید سپس زمانی که مدیران پروژه موافقت کردند، می‌توانید توسعه را شروع کنید. مطمئناً زمان بیشتری را خواهید خرید!
شاید دلتون بخواد که در پروژه های عظیم تر مشارکت کنید. همون طور که فهمیدیم، بهتره همیشه از کوچیک شروع کنید. اینطوری راحت تر مراحل مختلف مشارکت رو متوجه میشید چون پیچیدگی کمتری در این پروژه ها وجود داره. این فایل و دایرکتوری ها رو در مخزن (Repository) مورد نظرتون میتونید پیدا کنید. بیاید ببینیم چطوری از هرکدومشون میتونیم استفاده کنیم.
.gitفولدری که خود گیت استفاده شده در پروژه داخلش هست.-
.gitignoreفایل ها و الگوهایی که گیت بهشون اهمیت نمیده. - برای دادن صفت(Attribute) به فایل ها.
.gitattributes
- دایرکتوری که گیت داخلش به دنبال روند های عملیاتی(Action Workflows)، قالب ها(Templates) و... میگرده :
.github - ممکنه یه فایل
mdیاrstیاtxtباشه که توضیحاتی درمورد مخزن(Repository) یا یه اپلیکیشن میده :README - یک داکیومنت که پروژه تحت اون مجوز[License] هست :
LICENSE - مراحل مشارکت کردن که باید درمورد پروژه بدونید :
CONTRIBUTING
اولین قدم همیشه باید خوندن فایل README باشه. مطمئن بشید که مخزن(Repository) فعاله، و بعد به سراغ فایل CONTRIBUTING برید. یه فایل CONTRIBUTING برای مثال:
برای مشارکت کردن به پروژه های بزرگتر، باید اول پروژه رو کامل بشناسید. داکیومنتش و داک استرینگ هاش رو بخونید تا متوجه ی هر بخش بشید. داخل فایل ها و دایرکتوری ها بچرخید. ساختار و معماری کد رو، یکپارچه(Monolithic) یا مایکروسرویس(Microservice)، رو درک کنید. اینکه رویه ای(Procedural) هستن یا شیء گرا.
پروژه های بزرگتر به برنامه ها و ماژول های مختلف تقسیم شدن تا روند توسعه برای مشارکت کننده ها آسون تر بشه. اگر میخواید که یه تابع(Function) رو بهتر کنید، ماژول ها و تست هاش رو راحت تر پیدا میکنید. یه کار خوب اینه که تست های پروژه رو بخونید تا نقش هر بخش پروژه رو بفهمین.
در پروژه های بسیار عظیم تر، مثل زبان های برنامه نویسی، یک راهنمای توسعه دهنده(Developer Guideline) وجود داره برای کسایی که میخوان در پروژه مشارکت داشته باشن. برای مثال، پایتون راهنمای توسعه دهنده خودش رو داره و همه چیز اونجا توضیح داده شده.
نکاتی که بالاتر بررسی کردیم بهتون کمک میکنن مشارکت کننده متن باز(Open-Source) بهتری باشید. اما در بیشتر اوقات، شاید شما نگه دارنده(Maintainer) یک پروژه باشید. از لحاظ نگه داری یه پروژه، این مسیر شاید کمی سخت و چالش برانگیز باشه، اما در مباحث بعدی، نکاتی درمورد نگه داری پروژه ها بهتون میگیم که مدیر متن باز(Open-Source) بهتری باشین.
به عنوان نگه دارنده(Maintainer) یه پروژه ی متن باز(Open-Source)، بعضی وقت ها در شرایطی گیر میکنید که باید همه چیز رو خودتون شروع کنید. لوگو، بنر، داکیومنت بی نقص و یه مخزن(Repository) به خوبی ساختار یافته و شما هم تنها کسی هستین که ازش مراقبت میکنین. تجربه داشتن در مهارت های متفرقه شاید بهتون توی این شرایط کمک کنه. من به شخصه فکر میکنم که یه نگه دارنده ی(Maintainer) متن باز(Open Source) باید با تمامی زمینه های فنی آشنایی داشته باشه. اما، نگه دارنده(Maintainer) باید در یک زمینه ی به خصوص متخصص باشه. این طریقه ای هست که میشه یه ایده رو متولد و آماده برای پرواز کرد. یک مقدار مهارت بازاریابی همیشه خوبه. نه تنها نیازه که در زمینه ی فنیتون بسیار ماهر باشید، بلکه بهتره مهارت های متفرقه هم به خوبی بدونید. حداقل بتونید نیازمندی های پروژتون رو برآورده کنید. | رهبری پروژه ی متن باز به مهارت های بسیار زیادی در متن باز و جسارت کافی برای استفاده ازش نیاز داره - اما فقط بعد از اینکه قلق کار دستتون اومده باشه، رفتار و کردار بقیه رو به درستی فهمیده باشین و دستاتونو با چندتا پروژه کثیف کرده باشین. (The Linux Foundation)
ما در دنیایی پر از مشکل و سختی زندگی میکنیم. به عنوان توسعه دهنده ی نرم افزار، شما قراره مشکلات رو با توانایی هاتون حل کنید. مهم نیست که متن بازه(Open-Source) یا متن بسته(Closed-Source). هر پروژه ای که دارین روش کار میکنین چیزی نیست جز یه ایده. بزارید با یه مثال توضیح بدم. تصور کنید که یه سیستم عامل روی کامپیوترتون نصب کردید. یه برنامه دارین که میخواین حین بوت شدن کامپیوتر، اجرا بشه. یه اسکریپت پایتون مینویسید و الان مشکل حل شده. میتونید اسکریپت رو نگه دارید و هرجا که میخواید دوباره ازش استفاده کنید. دیگه نیاز نیست دوباره این مشکل رو حل کنید چون الان راه حل خوبی براش دارید. اون اسکریپت چیزی جز یه متن ساده نیست. ایده ی پشتش مهم ترین بخشه. وقتی که اسکریپتتون رو متن باز میکنید، دارید این ایده رو برای همه در دسترس میزارید. هزاران فایده در توسعه دادن پروژه های متن باز هست. شاید مهم ترینش این باشه بفهمید آیا ایده یا راه حلتون پتانسیل بهتر شدن رو داره یا نه. بسیاری از مخازن(Repositories) مشهور، روزی که منتشر شدن فقط یه ایده بودن و الان کلی مشارکت کننده(Contributor) داره. شرکت هایی که از اون پروژه های متن باز(Open-Source) استفاده میکنن بهترین حامی هاشونن.
یه محصول متن باز(Open-Source) تحت یک مجوز یا پروانه(License) هست. وقتی پروژتون هیچ پروانه ای(License) نداشته باشه به این معنی نیست که پروژتون متن بازه. از اونجایی که انتخاب پروانه(License) خیلی قدم مهمی هست، بهتون پیشنهاد میکنم با دقت انتخابش کنید. اگر با پروانه های(License) متن باز فعلی فعلی راحت نیستید، میتونید خودتون یک پروانه(License) بنویسید که پیشنهاد نمیکنم.
خیلی از توسعه دهنده ها(Developers) براشون سخته که پروژه هاشون رو روی پلتفورم های مثل Github بزارن و به توسعش بپردازن. و نه از نظر فنی. شاید این سوالات رو پرسیده باشید، من هم جواب های خودمو براتون دارم.
نیاز نیست که کدتون ** بی نقص** باشه تا بتونه روی گیتهاب بره. شما ایده رو پوش(Push) میکنید تا پیاده سازیش بی نقص بشه. ایده ای که الان دارید روش کار میکنید ممکنه راه حلی برای یک مخزن(Repository) معروف دیگه بشه.
نباید ایده ی تازه متولد شدتون رو با اونهایی که هزاران مشارکت کننده(Contributor) و ستاره دارن مقایسه کنید. مدام بهترش کنید. کمک بخواید. روی پروژه های خودتون ایشیو درست کنید. به اجتماع ها(Communities) بپیوندید و درمورد ایدتون ازشون بپرسید. بزارید اونها دیدگاه هاشون رو بگن. اینطوری متوجه میشید که آیا ایدتون پتانسیل رشد کردن رو داره یا نه. این مهم ترین نگرانی هایی بوده که من در سفرم بار ها و بار ها، هر وقت خواستم پروژه ی جدیدی رو شروع کنم، باهاشون برخورد کردم. اگر سوالی درمورد این سفر دارید، لطفا با کامنت هاتون من رو در جریان بزارید
در این مقاله، درمورد نکات بسیار مهمی صحبت کردیم که میتونید در پروژه های متن بازتون استفاده کنید تا تجربه ی بهتری داشته باشین و از کردن روی پروژه های مختلف لذت ببرید، حتی اون خیلی معروفا !. همچنین توضیح دادیم که چرا لایسنس ها بسیار مهم هستند و در نهایت، به نگه داری پروژه های متن باز(Open-Source) نگاهی انداختیم.