من در تهران زندگی نمیکنم. یا به عبارت دیگه، من هیچ آینده‌ای در برنامه‌نویسی ندارم. این جمله اغراق آمیز، اما نزدیک به واقعیته. عمده بازار کار برنامه‌نویسی در تهرانه و کار پیدا کردن برای کسانی که در شهر‌های دیگه زندگی میکنند (به غیر از چند شهر بزرگ دیگه) به مراتب سخت تره. این نه تنها روی جیبم اثر میگذاره، بلکه روی انگیزم برای یادگیری و ادامه دادن برنامه‌نویسی، میزان مهارت و تجربم هم اثر میگذاره. خیلیا تو این شرایط یا برنامه‌نویسی رو رها میکنند و یا از روی ناچاری به تهران مهاجرت میکنند. اما من بعد از ۴ سال هیچکدوم از این کار هارو نکردم و هنوز دارم ادامه میدم. این برای من یک موفقیته و اینو مدیون اپن‌سورس هستم.

اپن‌سورس موقیت‌هایی در اختیار من گذاشته که نمیتونم جای دیگه داشته باشم. تو گیت‌هاب میتونم کد‌های بقیه رو بخونم و ازش یاد بگیرم. یا میتونم با مشارکت در اپن‌سورس، کمی تجربه کسب کنم. اپن‌سورس باعث شد جدا افتادنم از برنامه‌نویس‌های دیگه رو کمتر حس کنم و اگر این رو نداشتم احتمالا مدت‌ها پیش قید برنامه‌نویسی رو زده بودم.

اما اپن‌سورس فقط این نیست. در اپن‌سورس این فرصت رو دارید که پروژه‌ها و آدم‌هایی که بهشون علاقه دارید رو پیدا کنید و باهاشون کار کنید. آدم‌هایی که در شرایط عادی امکان کار کردن باهاشون رو ندارید. با مشارکت در اپن‌سورس، میتونید رزومه‌ای برای خودتون بسازید که بهتر از هر چیزی مهارتتون رو نشون میده. در اپن‌سورس پروژه‌هایی پیدا میکنید که خوراک کپی‌-پیست کردنه. من هروقت جایی گیر میکنم، میگردم دنبال پروژه‌های اپن‌سورس مشابه و اکثر مواقع جوابش رو تو کد یکی دیگه پیدا میکنم و ازش یه چیزی یاد میگیرم. جدا از همه اینها، اگر میخواید یک زبان برنامه‌نویسی یا کتابخونه‌ای که مربوط به یک زبان اپن‌سورس هست، یا خیلی چیز‌های دیگه بسازید، چاره‌ای جز اپن‌سورس کردنش ندارید، چون در غیر این صورت احتمالا ازش استقبال نمیشه. همه برنامه‌نویس‌ها در هر سطحی میتونن از اپن‌سورس بهره ببرن.

چه انتظاراتی از اپن‌سورس نداشته باشیم؟

انتظارات غلط میتونه شمارو برای همیشه از اپن‌سورس متنفر کنه. بنابراین، مهمه که با دیدگاه درستی وارد دنیای اپن‌سورس بشید. اینها انتظارات اشتباهی هست که خیلی‌ها دارند:

1. کسب درآمد: درصد پروژه‌هایی که به اندازه‌ای کمک مالی میگیرند که یک نفر بتونه تمام‌وقت روش کار کنه خیلی کمه. اکثر پروژه‌ها، یا اصلا درآمدی ندارند یا درآمدشون اونقدری نیست که ارزش وقت برنامه‌نویس‌هاش رو داشته باشه. پول در آوردن از اپن‌سورس غیرممکن نیست. پروژه‌های اپن‌سورس زیادی هستند که از نظر مالی موفق هستند. اما برای اینکه تو ذوقتون نخوره، انتظار نداشته باشید که اپن‌سورس شمارو پولدار کنه.
2. وقت دیگران: اکثر آدما پاره‌وقت یا تفریحی اپن‌سورس کار میکنند و از اون طرف کار اپن‌سورس هم سبک نیست و ممکنه وقت این رو نداشته باشند که سریع به پیام هاتون جواب بدن. اگر از یک زاویه دیگه بهش نگاه کنید، مسئول جواب دادن به پیام‌های شما هم نیستند چون ما در ازاش چیزی به اونها نمیدیم. البته اکثر مواقع سریع به پیام‌ها و درخواست‌هاتون جواب داده میشه اما بهتره توقعش رو نداشته باشید.
3. مربی (mentor): یه عده ممکنه در اپن‌سورس دنبال مربی بگردن. یعنی انتظار داشته باشند که یکی پیدا بشه و مشکلات کدی که نوشتند رو بهشون بگه. به نظرم مربی‌گری مسئولیت سنگینیه و انداختنش روی دوش یه آدم تو اینترنت درست نیست. اگر دنبال یه مربی تمام و کمال هستند، تو اپن‌سورس دنبالش نگردید. البته، اگر رفتارتون خوب باشه و سوال‌های خوبی بپرسید، کسانی پیدا میشن که بهتون کمک کنند.

چطور شروع کنیم؟

برای شروع، به یک حساب کاربری در گیت‌هاب نیاز دارید. این روزا عمده فعالیت‌های اپن‌سورس در گیت‌هاب انجام میشه. طبیعتا باید با git هم آشنایی داشته باشید.

چنتا اصطاح گیت‌هاب که زیاد ازش استفاده میکنم:

• ریپو (ریپازیتوری/repository): هر پروژه اپن‌سورس در یک ریپازیتوری گیت‌هاب قرار میگیره.
• issue: هر ریپو، بخشی به اسم Issues داره که معمولا برای گزارش باگ، درخواست امکانات جدید، سوال یا ارتباط با مسئولان ریپو استفاده میشه.
• pull request(PR): برای اعمال تغییرات در یک ریپو، ابتدا یک pull request ساخت. اگر مسئول ریپو اون رو تایید کرد، PR به اصطلاح merge میشه و به کد اصلی اضافه میشه.
• maintainer: مشارکت‌کننده‌های اصلی یک پروژه که به نوعی مسئول ریپو هستند.

بعد باید دنبال یه پروژه مناسب بگردید. بهترین پروژه‌ برای شروع، یکی از کتابخونه‌هایی هست که دارید ازش استفاده میکنید. تو گیت‌هاب بگردید دنبال ریپو اون کتابخونه که با یک سرچ ساده پیدا میشه. مثلا، من اخیرا از کتابخونه sonner استفاده میکنم که کارش نمایش نوتیفیکیشن تو ری‌اکت هست. این ریپازیتوری sonner در گیت‌هاب هست:

یه جای دیگه برای پیدا کردن پروژه‌‌های باحال، صفحه trending گیت‌هاب هست. اونجا لیستی از پروژه‌های محبوب رو نشون میده که میتونید بر اساس زبان برنامه‌نویسی فیلترش کنید. من همیشه یه چیز باحال اونجا پیدا میکنم.

بعد از اینکه پروژه مورد نظرتون رو پیدا کردید، باید شروع به استفاده ازش کنید. عمده مشارکت‌های معناداری که میتونید انجام بدید، از استفاده کردن از اون پروژه نشات میگیره. پس باهاش کار کنید، مستنداتش رو بخونید و دنبال فرصتی بگردید که در پروژه شرکت کنید. مشارکت هم فقط از طریق ارسال کد نیست. میتونید:

1. بهش ستاره بدید: گوشه بالا و راست گیت‌هاب یه علامت ستاره هست که به نوعی محبوبیت اون رو نشون میده. پروژه‌هایی که ستاره‌های بیشتری داشته باشند معمولا توجه بیشتری جلب میکنند.
2. به بقیه کمک کنید: همه پروژه‌ها، بخشی رو برای سوال و جواب در نظر گرفتند. بعضی ریپو‌ها بخش Discussions دارند که فعال کردنش دست مسئول (maintainer) ریپو هست. بعضی‌ها ترجیح میدن که سوال و جواب‌ها تو بخش Issues انجام بشه و بقیه هم یه چنل دیسکورد یا یه شبکه اجتماعی رو برای اینجور چیزا در نظر گرفتند. با جواب دادن به سوال‌های بقیه، میتونید یه بار عظیم از دوش مسئولات پروژه بردارید.
3. مستندات رو بهتر کنید: معمولا به مستندات توجه کافی نمیشه. یا به خاطر کمبود وقت یا چون کار سختیه. این یه فرصت عالیه که خودتون رو نشون بدید. وقتی دارید مستندات میخونید، اگر غلط املایی دیدید، یا حس کردید یک موضوع بد توضیح داده شده، یا رنگ یک دکمه اشتباهه، فورا یه PR بسازید و درستش کنید. این یکی از ساده‌ترین و مفیدترین مشارکت‌هایی هست که میتونید انجام بدید. در بخش بعد ساخت PR توضیح میدم.
4. issue خوب بسازید: اگر حین استفاده از پروژه به مشکلی برخوردید، بهتره یک issue بسازید و موضوع رو با مسئولان درمیون بگذارید. ساخت یک issue خوب، یکی از مهم‌ترین مشارکت‌هایی هست که میتونید انجام بدید. حتی مهم تر از PR.

نکاتی در مورد مشارکت

قبل از اینکه به هر طریقی در یک پروژه مشارکت کنید، باید به این نکات توجه کنید:

1. بعضی از پروژه‌ها، بیشتر public source هستند تا open source. یعنی کدشون در اختیار عموم هست، اما علاقه‌ای به مشارکت بقیه ندارند و فقط مشارکت افراد خاصی رو قبول میکنند. مثلا، کد دیتابیس SQLite در گیت‌هاب هست، اما فقط تیم SQLite میتونن کد رو تغییر بدند و به بقیه این اجازه داده نمیشه. بعضی از پروژه‌های گوگل هم همینطور هستند. بهترین کار اینه که به تصمیم مسئولان این پروژه‌ها احترام بگذارید و مشارکت نکنید تا وقت خودتون هم تلف نشه. اینجا منظور از مشارکت، ارسال PR هست و ساخت issue و بقیه اشکال مشارکت همچنان مفیده. البته اینجور پروژه‌ها خیلی کم هستند و معمولا مشارکت شما موجب دلگرمی مسئولانش هست.
2. پروژه‌هایی که مشارکت شمارو میخوان، معمولا یک فایل contributing.md دارند. یا به هر شکل دیگه‌ای، نحوه مشارکت در پروژه رو توضیح دادند. قبل از هر کاری، نکاتی که تو این بخش گفته شده رو با دقت بخونید و سعی کنید مو به مو اجراش کنید.
3. قبل از این سوال بپرسید یا یک issue بسازید، بگردید دنبال سوال‌ها و issueهای مشابه و اگر مورد مشابهی بود شما اون رو تکرار نکنید و سوالتون رو همونجا مطرح کنید.
4. سعی کنید تا جای ممکن توی PRها و issueها پیام ندید چون با هر پیامی که اضافه میکنید، یک ایمیل به همه کسانی که توی اون بحث شرکت کردن میاد و ایجاد مزاحت میکنه. به جاش از ری‌اکشن هایی که توی گیت‌هاب هست استفاده کنید. اگر یه نفر شما رو راهنمایی میکنه، لازم نیست حتما توی یه پیغام جدا ازش تشکر کنید، مخصوصا اگر آدم های زیادی توی اون بحث شرکت کرده باشن. میتونید با یه قلب ساده قال قضیه رو بکنید. اگر با پیام یک نفر موافق هستید، کافیه یک لایک براش بگذارید. تاثیر ری‌اکشن‌ها معمولا بیشتره.
5. وقتی میخواید یک issue جدید بسازید، سعی کنید تا جایی که میتونید اطلاعات بدید. اگر یه باگ پیدا کردید، با تمام جزییات توضیحش بدید. از سیستم عامل بگیر، تا نسخه‌ای از پروژه که باگ توش مشاهده شده. اگر بتونید دستورالعمل‌هایی برای شبیه‌سازی باگ (reproduction example) بدید هم خیلی کمک میکنه. هرچی اطلاعات بیشتری بدید، شانس حل شدن اون باگ رو هم بیشتر میکنید. یا اگر میخواید درخواست امکانات جدید (feature request) بدید، چنتا مثال بزنید که چرا برای شما و بقیه میتونه مفید باشه. یا پیشنهاد بدید که چطور اون امکانات پیاده‌سازی بشه. بعضی از ریپو‌ها هم قالب‌هایی برای ساخت issue در نظر گرفتند. بهتره تا جای ممکن رعایتش کنید. مثلا این قالب گزارش باگ Next.js هست.
6. قبل از اینکه یک PR بسازید، بهتره یک issue مرتبط باهاش پیدا کنید. مثلا، اگر میخواید یه باگ رو رفع کنید، بگردید دنبال یک issue که اون باگ رو گزارش داده و لینکش رو توی توضیحات PR بنویسید. یا اگر میخواید امکانات جدیدی اضافه کنید، issue‌ای درخواست اون امکانات رو داده پیدا کنید. اگر همچین issue ای وجود نداشت خودتون بسازیدش. این کار چنتا فایده داره:
   1. از انجام کار تکراری جلوگیری میکنه. PR هایی که به یک issue مربوط هستند، تو صفحه issue نوشته میشه و میتونید ببینید که آیا به اون issue قبلا رسیدگی شده یا نه.
   2. اطلاعات بیشتری در اختیار بقیه میگذاره که چرا اون PR ساخته شده.
   3. ممکنه مسئولان پروژه قصد رسیدگی به اون issue رو نداشته باشند و مطرح کردنش در یک issue ممکنه از هدر رفتن وقت شما جلوگیری کنه.
7. وقتی یک PR جدید میسازید، توضیح مختصری از کاری که انجام دادید بدید. حتی اگر خیلی ساده باشه.

به عنوان مثال، چند روز پیش میخواستم چیزی به کتابخونه sonner اضافه کنم که وجود نداشت. این مراحلی بود که انجام دادم:

1. دنبال issue و PR های مرتبط گشتم ولی چیزی پیدا نکردم. پس خودم دست به کار شدم.
2. دنبال فایل CONTRIBUTING.md گشتم اما پیداش نکردم. این نشون میده که مشارکت در پروژه قوانین خاصی نداره. اکثر پروژه‌‌های کوچیک اینطور هستند.
3. خودم یک issue ساختم و چیزی که میخواستم رو توضیح دادم.
4. معمولا اینجور مواقع صبر میکنم که اون issue به نوعی توسط مسئولانش تایید بشه و بعد میرم سراغ پیاده سازیش. البته اگر دنبال تایید هستید، بهتره تو متن issue بنویسید که منتظر تایید هستید وگرنه ممکنه جوابی نگیرید. تو این مورد چون چیزی که میخواستم خیلی ساده بود و وقت زیادی نمیگرفت فورا یک PR براش ساختم. اول PR نوشتم Closes و جلوش لینک issue مربوطه رو گذاشتم. این عبارت Closes خیلی مرسومه و نشون میده که این PR چه issue هایی رو رفع میکنه. بعد یک توضیح مختصر در مورد کارایی که انجام دادم نوشتم. میتونید ببینید که بقیه موافقت خودشون با این issue و PR رو با ری‌اکشن نشون دادن و کامنت اضافی ننوشتند. این PR هم چند روز طول کشید تا merge بشه ولی من از مسئولش درخواست اضافی نکردم که سریع تر بهش رسیدگی کنه.

به همین راحتی. تا وقتی که نکات بالا رو رعایت کنید و حداقل‌هایی از صبر و ادب رو داشته باشید، تو اپن‌سورس به مشکلی بر نمیخورید.

اگر نظر یا سوالی دارید، حتما بهم ایمیل بزنید.