روزی که جنریتور “حلما” رو درست کردم، تصمیم گرفتم Open Sourceش کنم. چون اولین بار بود که میخواستم اینکارو بکنم، هیچ ایده‌ای نداشتم که از کجا باید شروع کرد یا باید به چه نکاتی توجه کنم. به همین دلیل، پیش یکی از بهترین دوستام به اسم گوگل!! رفتم تا مثل همیشه کمکم کنه، توی گوگل با کلیدواژه‌های start، open source و how جستجو کردم. بیشتر مقاله‌هایی که آورد رو خوندم، یه تعدادیشون نکته‌های خیلی خوب داشتند، این نکته‌هارو توی Evernote نوشتم تا سرفرصت تبدیلشون کنم به این مقاله‌ای که الان میخونید.

نکته‌هارو به دو گروه زیر تقسیم کردم:

گروه اول- نکاتی که قبل از Open Source کردن یه پروژه باید بهشون توجه کرد.

گروه دوم- نکاتی که وقتی یه پروژه Open Source شد باید بهشون توجه کرد.

 

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

 

گروه اول- نکات قبل از Open Source کردن

معرفی پروژه

قبل اینکه پروژه رو Open Source کنید، به صورت خلاصه توی یه پاراگراف بنویسید قراره چه مشکلی رو حل کنه و برای استفاده چه چیزهایی نیاز داره. حواستون باشه این پاراگراف رو کسایی میخونند که هیچ شناختی از پروژتون ندارند. بعد همیشه این پاراگراف رو یه جای دم دست نگه دارید، چون احتمالا توی جاهای زیادی (تو چت،شبکه‌های اجتماعی،فروم‌ها و …) باید در مورد پروژه صحبت کنید و میتونید همین پاراگراف رو سریع براشون بفرستید.

 

انتظار مشارکت زیاد از بقیه برنامه‌نویس‌ها

این فکر اشتباه رو نداشته باشید که وقتی پروژه Open Source بشه، یهو بقیه برنامه‌نویس‌ها میان کمکتون و همه‌ی کارهارو میکنند! بیشتر پروژه‌های Open Source رو اگر بررسی کنید، درصد زیادی از کد پروژه توسط گروه کوچکی از برنامه‌نویس‌ها نوشته شده که بصورت خاص رو اون پروژه کار می‌کنند (مثلا توی شرکتی هستند که پروژه برای اونجاس یا پول می‌گیرند). خیلی از پروژه‌ها هم نمی‌تونند بیشتر از بنیان‌گذارهاش برنامه‌نویس‌های دیگه‌ای جذب کنند و بعد یک سال متوقف می‌شند. بهتره همون اول پروژه سعی کنید از طریق صحبت کردن توی فروم‌ها یا نوشتن پست بلاگ تعدادی برنامه‌نویس برای مشارکت توی پروژه پیدا کنید. خوبیش اینه چون از شروع پروژه کنارتون هستند، حس میکنند این پروژه برای خودشونه و تلاش بیشتری می‌کنند.

 

مزایای Open Source کردن پروژه

از مزایای Open Source کردن پروژه میشه به موارد زیر اشاره کرد:

۱- باعث آزادی بیشتر میشه. مثلا روی پروژه‌ای کار می‌کنید که صاحبش شرکت هست، Open Source شدنش باعث میشه که در آینده حتی اگر از اون شرکت هم بیرون اومدید، بتونید روش کار کنید.

۲- حس مفید بودن می‌کنید و احساس بهتری پیدا می‌کنید.

۳- با تاثیری که پروژتون رو دنیای برنامه‌نویس‌ها میذاره، برای همیشه یه اثر و ردپا از شما می‌مونه.

۴- راحت‌تر میشه به مشکلاتی که توی پروژه دارید لینک بدید و از بقیه کمک بگیرید. کسی هم که میخواد کمک کنه چون به سورس دسترسی کامل داره، خیلی بهتر کمکتون میکنه.

 

معایب Open Source کردن پروژه

Open Source شدن پروژه در کنار مزایا بالا، معایبی هم داره. مثل:

۱- هرچی از شروع پروژه میگذره کار سخت‌تر میشه! وظیفه‌هاتون خیلی زیاد میشه مثل توسعه‌ی دادن کد، نوشتن داکیومنت، جواب دادن به سوال کسایی که از پروژه استفاده می‌کنند ،بررسی کدهایی که بقیه برای مشارکت توی توسعه پروژه فرستادن و بررسی درخواست ویژگی‌های جدید که براتون ارسال شده.

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

۲- موقع Open Source کردن در نظر داشته باشید که احتمالا این کار باعث میشه کسب درآمدتون سخت‌تر بشه. البته گاهی میشه به جای Open Source کردن کل پروژه‌ای که می‌فروشید و منبع درآمدتون هست، شبیه شرکت Dropbox، کتابخونه‌هایی که برای ساخت پروژه‌ی خودتون درست کردید رو Open Source کنید. اینجوری هنوز میتونید به فروش پروژه‌تون ادامه بدید.
البته توی بعضی موارد مجبورید پروژتون رو Open Source کنید و راه دیگه‌ای ندارید. بطور مثال اگر یه نرم افزار زیرساختی درست کردید(مثل سیستم‌عامل،دیتابیس و …)، انتخاب دیگه‌ای ندارید. هم-بنیانگذار Cloudera گفته که توی ده سال گذشته هیچ نرم افزار زیرساختی با Closed Sourceیی نبوده که بتونه خیلی معروف بشه و عده‌ی زیادی ازش استفاده کنند! توی اینجور پروژها، کاربرها معمولا از استک‌های Open Source استفاده می‌کنند.

۳- برعکس اینکه همه فکرمی‌کنند Open Source کردن باعث میشه هزینه‌ها کم بشه! نه تنها کم نمیشه، تازه زیادم میشه. چون در حالت معمول که کار می‌کنید، کسی اون کد رو نمی‌بینه و فقط کدتون کار کنه! کافیه. اما وقتی کدهارو بقیه می‌بینند مجبورید برای اینکه خجالت زده نشید، کلی وقت براشون بذارید!! همچنین غیر از کد زدن هم وظیفه‌های دیگه‌‌ای مثل داکیومنت نوشتن و … که قبلا بهشون اشاره کردم به کارهاتون اضافه میشند.

 

گروه دوم- نکات بعد از Open Source کردن

جذب مشارکت‌کننده

برای جذب مشارکت کننده میتونید در ازای اینکه کسی توی توسعه پروژه مشارکت کنه، بهش برنامه‌نویسی یاد بدید. شاید اوایل نتونند خیلی بهتون کمک کنند ولی در آینده تعدادی مشارکت کننده دارید که پیوسته روی توسعه پروژه باهاتون همکاری می‌کنند.

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

 

تبلیغ پروژه

معمولا برنامه‌نویس‌ها از اون مدل آدم‌هایی نیستند که خودشون رو تبلیغ کنند ولی توی این مورد باید بکنند! برای شروع میتونید یه پست بلاگ بنویسید یا داخل StackOverflow توی موضوعاتی که به پروژتون ربط داره سوال جواب بدید.

تو بحث‌های برنامه نویسی داخل Hakernews یا Reddit شرکت کنید (اگر بین ایرانی‌ها میخواید تبلیغ کنید، توییتر و تلگرام هست)

با پروژه‌های Open Source دیگه همکاری کنید! شاید پروژه‌تون بتونه بخشی از نیاز اون‌هارو رفع کنه و به عنوان dependency از پروژتون برای خودشون استفاده کنند! این اتفاق پروژه‌تون رو خیلی معروف‌تر میکنه.

 

انتخاب لایسنس

یکی از موضوعاتی که روی پروژه خیلی تاثیر داره اینه که چه لایسنی انتخاب میکنید، مثلا GPL سخت‌گیرانه رو انتخاب می‌کنید یا لایسنس های آسون‌تر مثل MIT

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

لیست تغییرات جدید
حتما لیست تغییرات داشته باشید و حداقل سه قسمت داشته باشه:‍

۱- نسخه‌ی جدید چه ناسازگاری‌هایی با نسخه‌ی قبلی داره

۲- چه ویژگی‌های جدید به سیستم اضافه شده

۳- چه باگ‌هایی در سیستم درست شدند.

حواستون باشه که قرار نیست توی لیست تغییرات یه سری پیام کامیت رو پشت هم بذارید! سعی کنید یه متن واضح و خوب بنویسید

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

راه ارتباطی با کاربرها و مشارکت‌کننده‌ها
توی Gitter کانال درست کنید تا بیشتر با کاربرها در ارتباط باشید، سعی کنید حتما سوال‌هایی که پرسیده میشه رو سریع جواب بدید، اینجوری کاربرا و مشارکت‌کننده‌ها میفهمن که برای اونها و پروژه‌ی خودتون اهمیت قائل هستید.
خیلی بده اگر در نظر نگیریدشون و بهشون اهمیت ندید!

ساخت وبسایت
حتما یه وبسایت برای پروژه درست کنید، یه سایت تک صفحه ای هم خیلی کمک میکنه. میتونید از Github Pages استفاده کنید.

ساخت Readme
فایل readme مناسب برای پروژه درست کنید. میتونید داخلش این موارد رو بنویسید:

۱- پاراگرافی که بصورت خلاصه در مورد پروژتون نوشتید رو داخل بذارید.
۲- توضیح بدید که چطور میشه پروژه رو اجرا کرد.
۳- آدرس وبسایت پروژه رو بذارید
۴- اسم و ایمیل کسایی که توی پروژه همکاری میکنند رو بنویسید

برای پروژه release بسازید
همه دوست ندارند از سورس کنترل استفاده کنند و پروژه رو کلون کنند! حتما موقع وقتی نسخه جدید میخواید بدید از پکیچ‌های فشرده استفاده کنید تا اگر کسی خواست بتونه راحت دانلودش کنه.

ساخت داکیومنت برای کاربران

کار خیلی سختیه ولی به همون اندازه مهمه! بدون راهنمایی کسی نمیتونه از پروژه استفاده!! لازم نیست همون اول کار یه راهنمای کامل بنویسی، یه داکیومنت ساده هم کافیه.
داکیومنت رو جزء ریپوزیتوری نذارید که بعد هر تغییر نیاز به پوش کردن باشه، داکیومنت باید جایی باشه که خیلی سریع و راحت بشه تغییرش داد.

نوشتن داکیومنت برای مشارکت کننده‌ها

‍۱- کدهای پروژه کجاس و چطوری میشه دریافت کردشون.

۲- در مورد فولدربندی پروژه یه توضیح مختصر بدید.

۳- اگر از build system استفاده میکنید، در مورد نحوه‌ی تنظیم کردنش توضیح بدید و بگید dependecyهای پروژه رو چطور باید گرفت.

۴- نحوه‌ی build کردن پروژه و اجرا کردن تست‌هارو توضیح بدید.

۵- شرایط مشارکت کردن توی پروژه رو بنویسید.

 

سخن پایانی که اعتماد به نفستون رو باید بالا نگه دارید،به مفید بودن کار خودتون اعتقاد داشته باشید. کدهاتون رو با کدهای بقیه مقایسه نکنید، پروژتون رو مقایسه نکنید، به خودتون گیر ندید که حتما باید از بقیه بهتر باشید!!!چون معیار این بهتر بودن مشخص نیست و امکانش نیست معیاری بشه براش تعریف کرد.

به اینکه بقیه دولوپرها شاید بعدا چیزهای بدید مورتون بگن رو نکنید ( مثلا بگن پروژتون بده،بی فایده‌اس و …)! توی اینترنت همیشه کسایی هستند که حتی اگر از آسمون هم پول بباره وجه منفیشو می‌بینند!!

منابع

http://blog.smartbear.com/open-source/how-to-turn-your-pile-of-code-into-an-open-source-project

http://www.wikihow.com/Have-a-Successful-Open-Source-Project

https://readwrite.com/2014/07/07/ open-source-software-pros-cons

https://opensource.com/life/15/5/4-steps-creating-thriving-open-source-project

https://www.smashingmagazine.com/2013/01/starting-an-open-source-project