نظارت درست بر روی پروژه‌ی در حال رشد

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

مثال‌هایی از نقش‌های رسمی مورد استفاده در پروژه های متن باز، چه هستند؟

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

مضمون و معنای این نقش‌ها، در واقع کاملا به شما بستگی دارد. در اینجا، چند نوع نقشی که ممکن است آن‌ها را تشخیص دهید، نام بردیم:

• نگهدارنده (Maintainer)
• مشارکت‌کننده (Contributor)
• کامیت کننده (Committer)

در برخی از پروژه‌ها، نگهدارندگان تنها افرادی در پروژه هستند که دسترسی کامیت دارند. در برخی دیگر از پروژه‌ها، فقط افرادی دسترسی دارند که در «README» به عنوان نگهدارنده ذکر شده‌اند.

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

مشارکت‌کننده می‌تواند هر کسی باشد: کسی که مسئله یا درخواست «Pull»ی را مطرح می‌کند، یا افرادی باشند که به پروژه ارزش می‌بخشند (خواه این که مسائل مربوط به اولویت‌بندی درخواست‌ها، نوشتن کد یا سازماندهی رویدادها باشد) یا هر کسی باشد که درخواست «Pull»ی را ادغام (merge) بکند (جزئی‌ترین تعریف از مشارکت‌کننده)

اصطلاح «کامیت کننده»، ممکن است برای وجه تمایز دسترسی کامیت، که نوع خاصی از مسئولیت در مقابل سایر اشکال مشارکت است، استفاده شود.

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

چگونه به این نقش‌های مدیریتی، رسمیت ببخشیم؟

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

در پروژه‌های کوچک‌تر، تعیین کردن مدیران می‌تواند به سادگی افزودن نام آن‌ها به فایل‌های «README» یا به یک فایل متنی «CONTRIBUTORS» باشد.

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

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

تیم‌های مدیریت، ممکن است بخواهند کانالی مشخص (مانند IRC) ایجاد کنند یا به طور منظم برای بحث درمورد پروژه با هم ملاقات کنند (مانند Gitter یا Google Hangout). حتی می‌توانید آن جلسات را علنی برگزار کنید تا سایر افراد بتوانند گوش دهند. به عنوان مثال، Cucumber-ruby همچین کاری می‌کند

پس از اینکه نقش‌های مدیریتی را ایجاد کردید، ثبت چگونگی نحوه‌ی دسترسی افراد به آن‌ها را فراموش نکنید! فرآیند روشن و واضحی را برای چگونگی کسی که می‌خواهد نگهدارنده شود یا به کمیته‌ای فرعی در پروژه شما بپیوندد، ایجاد کنید و آن را در «GOVERNANCE.md» خود بنویسید.

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

در آخر اینکه اگر پروژه‌ی شما در «GitHub» است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. تشکل‌های «GitHub»، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق مالکیت مشترک محافظت می‌کنند.

چه موقع باید به کسی اجازه‌ی دسترسی کامیت بدهیم؟

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

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

اگر پروژه‌ی شما در «GitHub» است، می توانید از شاخه‌های محافظت شده protected branches برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید

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

سه ساختار نظارتی متداول در ارتباط با پروژه‌های متن باز وجود دارد.

• BDFL مخفف “Benevolent Dictator for Life” یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار، یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. Python، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت BDFL هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی BDFL قرار گیرند

• Meritocracy: (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی.)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از خود «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت.

• Liberal contribution: (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام می‌دهند به عنوان تأثیرگذارترین افراد شناخته می‌شوند، اما این مدل براساس کاری که اکنون انجام می‌دهند است و نه مشارکت‌های که در گذشته داشته‌اند. تصمیمات بزرگ‌ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث‌ در مورد مسائل اساسی) به جای رأی‌گیری تنها گرفته می‌شود، و تلاش می‌شود تا آنجا که ممکن است دیدگاه‌های بیشتری از اجتماع را شامل شود. از جمله پروژه‌هایی که از مدل مشارکت آزادانه استفاده کردند، می‌توان Node.js و Rust را نام برد.

از کدام مدل بهتر است استفاده کنید؟ به خودتان بستگی دارد! هر مدل، شامل نکات منفی و مثبتی می‌شود. اگرچه ممکن است این مدل‌ها در ابتدا کاملاً متفاوت به نظر برسند؛ اما هر سه مدل، بیشتری از آنچه که به نظر می رسد اشتراکاتی دارند:

• BDFL model template
• Meritocracy model template
• Node.js’s liberal contribution policy

آیا هنگام راه‌اندازی پروژه‌ی خود به اسناد نظارتی نیاز دارم؟

زمان مناسب و دقیقی برای نوشتن اسناد نظارتی پروژه وجود ندارد، اما هنگامی که شرایط اجتماع خود را دیدید و با جو آن آشنا گشتید، به ثبت رساندن اسناد بسیار ساده‌تر می‌شود. بهترین (و سخت‌ترین) بخش در مورد نظارت پروژه‌های متن باز این است که توسط خود اجتماع شکل می‌گیرد!

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

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

اگر کارمندان شاغل در شرکت شروع به ارائه‌ی خدمات کنند، چه می‌شود؟

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

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

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

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

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

آیا برای حمایت و پشتیبانی از پروژه‌ی خود به نهاد قانونی نیاز خواهم داشت؟

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

به عنوان مثال، اگر می‌خواهید کسب و کاری ایجاد کنید، باید از طریق «C Corp» یا «LLC» (اگر در ایالات متحده مستقر هستید) اقدام کنید. اگر فقط کارهای پیمانکاری مربوط به پروژه متن باز خود را انجام می‌دهید، می‌توانید به عنوان یک مالک شخصی پول را بپذیرید یا یک «LLC» (اگر در ایالات متحده مستقر هستید) ایجاد کنید.

اگر می‌خواهید کمک‌های مالی برای پروژه‌ی متن باز خود بپذیرید، می‌توانید بستری را برای کمک‌های مالی (مثلاً با استفاده از PayPal یا Stripe) ایجاد کنید، اما این مبلغ مشمول کسر مالیات می‌شود، مگر اینکه به عنوان یک سازمان غیرانتفاعی واجد شرایط باشید (اگر در ایالات متحده مستقر هستید).

بسیاری از پروژه‌ها مایل به پذیرفتن مشکلات ناشی از ایجاد سازمانی غیرانتفاعی نیستند، بنابراین در عوض یک حامی مالی غیرانتفاعی پیدا می‌کنند. یک حامی مالی، معمولاً در ازای درصدی از کمک مالی، کمک‌های مالی را از طرف شما قبول می‌کند. Software Freedom Conservancy،Apache Foundation ،Eclipse Foundation ، Linux Foundation و Open Collective، نمونه‌هایی از سازمان‌ها هستند که به عنوان حامی‌های مالی در پروژه‌های متن باز فعالیت می‌کنند

اگر پروژه‌ی شما رابطه‌ی نزدیکی با زبان یا اکوسیستم خاصی داشته باشد، ممکن است پیش‌زمینه‌ی نرم‌افزاری مرتبط با آن وجود داشته باشد که بتوانید با آن کار کنید. به عنوان مثال، Python Software Foundation از PyPI پشتیبانی می‌کند، Python package manager و Node.js Foundation به Express.js، که مبتنی بر Node است، کمک می‌کند.

بازگشت به صفحه اصلی