‌ـ‌ من برنامه‌نويس خوبي نيستم.

‌ـ‌ نمي‌دانم روي چه پروژه‌اي كار كنم.

را در ذهن خود مطرح مي‌كنيم؛ اما بايد به نكات زير توجه كرد:

‌ـ‌ پروژه‌ها به همه افراد با هر سطح توانايي و مهارت نياز دارد.

‌ـ‌ كمك هر اندازه هم كه‌ اندك باشد، باز هم سودمند است.

‌ـ‌ بهترين پروژه براي كمك، پروژه‌اي است كه از آن استفاده مي‌كنيم.

بزرگ‌ترين دغدغه تازه واردان در كمك به دنياي برنامه‌نويسي اين است كه مي‌انديشند بايد برنامه‌نويس خبره‌اي باشند. اين مساله صحيح نيست. هر چند بزرگان اين جامعه براي خود شهرتي دست و پا كرده‌اند، اما بخش عمده‌اي از اين جامعه اين‌گونه نيستند. برخي اوقات كمك به يك پروژه در حوزه برنامه‌نويسي است و برخي اوقات هيچ ارتباطي با برنامه‌نويسي ندارد.بخش عمده‌اي از دليل موفقيت پروژه‌هاي منبع باز، كاري است كه در آنها انجام مي‌شود؛ كارهايي كه نياز به مغز متفكر ندارد. طراحي يك زبان برنامه‌نويسي يا بستر توسعه وب شايد نياز به الهامات دروني داشته باشد، اما موفقيت پروژه‌هايي چون Perl و Rails در استمرار فعاليت آنهاست؛ كارهايي كه شايد خيلي شهرتي به ارمغان نياورد، اما لازم است و بعد از مدتي، ميزان كمك‌هاي هر فرد بالاخره مورد توجه قرار مي‌گيرد.

در منبع باز، همه چيز به ديگران مربوط است. بايد به يك تيم بپيونديد و براي اين كار بايد دركي از جامعه و شيوه كاركرد آن پروژه داشته باشيد. ورود به پروژه و اعلام اين جمله: «سلام، به نظر من اين پروژه بايد چنين كاري را بكند.» معمولا گزينه خوبي نيست. برخي پروژه‌ها اين روش را مي‌پسندند اما اگر پروژه‌اي براي مدتي در حال كار باشد، چنين رفتاري معمولا با استقبال مواجه نمي‌شود. ارتباط با ديگر اعضا و شنيدن نيازهاي پروژه مي‌تواند نقطه شروع خوبي براي ورود به پروژه باشد.

بيشتر پروژه‌ها فهرست ايميلي دارند كه ارتباطات اصلي توسعه پروژه در آن محل انجام مي‌شود. در پروژه‌هاي بزرگ فهرست‌هاي ايميل زيرشاخه وجود دارد. مثلا در پروژه PostgreSQL 12 فهرست با محوريت كاربري و شش فهرست با محوريت توسعه كد وجود دارد كه مي‌توان به آنها ملحق شد.

بلاگ‌هاي اين پروژه‌ها كه معمولا توسط توسعه‌دهندگان مركزي به‌روز مي‌شود، اطلاعاتي از جمله قابليت‌هايي را كه در نسخه‌هاي بعدي نرم‌افزار پياده مي‌شود شامل مي‌شود. سايت‌هاي قمري معمولا اين كار را انجام مي‌دهند و اخبار و حواشي توسعه پروژه را تحت پوشش خبري قرار مي‌دهد. وب سايت‌هايي چون planet.gnome.org و planet.mysql.com از اين نمونه‌هاست. براي شروع مي‌توانيد در گوگل عبارت planet و سپس نام پروژه را جستجو كنيد.

بسياري از پروژه‌هاي منبع باز، كانال چت IRC مخصوص به خود را دارد كه توسعه‌دهندگان و كاربران در آنجا مشكلات و مسائل توسعه را با يكديگر در ميان مي‌گذارند. معمولا توضيحات اتصال به شبكه IRC در وب سايت اين پروژه‌ها وجود دارد.

كدنويسي قلب هر پروژه منبع باز در نظر گرفته مي‌شود اما نوشتن كد تنها روش كمك به پروژه نيست. نگهداري از كد و سيستمي كه كنار آن فعاليت مي‌كند از بخش‌هاي مهم ديگر اين پروژه به شمار مي‌رود. اين نواحي براي ورود تازه‌كاران بسيار مفيد خواهد بود. البته براي كنترل تيكت‌ها به دسترسي نياز داريد، اما مديران اغلب پروژه‌ها به دنبال فردي مي‌گردند كه بخش درخواست‌ها و باگ‌ها را مرتب و كنترل كند.

معمولا باگ‌ها بخوبي گزارش نمي‌شوند. گزارش يك باگ و پيگيري آن مي‌تواند در وقت توسعه‌دهندگان صرفه‌جويي كند. اگر اتفاقي براي نرم‌افزارتان افتاد و توانستيد با انجام اعمالي آن را دوباره تكرار كنيد، اين شرايط هرقدر هم كه خاص باشد، مي‌تواند به رفع آن باگ و در نتيجه به كل پروژه كمك كند.حتي اگر دليل رويداد باگ را هم نمي‌دانيد، تلاشي كه براي كم كردن حالت‌هاي اتفاق انجام مي‌دهيد، به تعمير سريع‌تر آن كمك مي‌كند. بهتر است نتايج خود را در قالب تيكت به وب سايت پروژه ارسال كنيد.معمولا در پروژه‌ها باگ‌هايي وجود دارد كه قبلا رفع شده ولي تيكت آن به روز نشده است. با يافتن و بستن اين تيكت‌ها (كه كار دشوار و زمان بري است) مي‌توان به پروژه‌اي تميزتر و هدفمندتر كمك كرد.براي شروع كافي است تيكت‌هايي را كه بيش از يك سال است در سيستم باز مانده‌اند، جستجو كنيد و بعد با مراجعه به release log پروژه، به دنبال آن باگ بگرديد. اگر اين مشكل رفع شده بود، شماره نسخه رفع ايراد را در انتهاي تيكت نوشته و آن را ببنديد.امتحان كنيد آيا باگ در آخرين نسخه تيكت نيز وجود دارد يا خير. اگر باگي وجود نداشت، اين موضوع را در تيكت قيد كرده و آن را ببنديد. اگر باگ هنوز وجود داشت، در انتهاي تيكت اين موضوع را يادداشت كنيد و تيكت را باز بگذاريد.

همه برنامه‌نويس‌ها، در هر سطحي كه باشند، مي‌توانند به كدنويسي پروژه كمك كنند. هر پروژه‌ يك جريان كاري دارد و بهتر است قبل از دست‌بردن و ارسال كد، متوجه آن جريان كاري شويم.مثلا در پروژه PostgreSQL، اصلاح كدها به شكل Patch به فهرست ايميل ارسال مي‌شود و بعد توسعه‌دهندگان از هر نظر كد جديد را بررسي مي‌كنند، اما مثلا در پروژه‌اي ديگر مثل Parrot، كافي است دسترسي تغيير مستقيم كد را داشته باشيد.اگر پروژه مورد نظر از GitHub استفاده مي‌كند، مي‌توان از قابليت pull آن استفاده كرد و به طور مستقل به توليد پچ پرداخت.