به گزارش از وبسایت cncf، در بررسی‌های حاکمیتی انجام‌شده روی 72 پروژه CNCF، الگوهای مشخصی دیده شده است؛ الگوهایی که تفاوت میان الزامات CNCF در هر سطح بلوغ را با داده‌هایی که برای سلامت بلندمدت پروژه‌ها پیشنهاد می‌شود، روشن می‌کند. این مطلب این الگوها را به‌عنوان راهنما برای پروژه‌هایی جمع‌بندی می‌کند که می‌خواهند ساختار governance خود را انتخاب کنند یا آن را ارتقا دهند 😊
آنچه داده‌ها نشان می‌دهند
بررسی‌های governance در میان 72 پروژه graduated، incubating و archived نشان می‌دهد:
پروژه‌هایی که در زمان ورود به sandbox چند maintainer از سازمان‌های مختلف دارند، 2.07 برابر بیشتر از پروژه‌های تک‌سازمانی graduate می‌شوند؛ یعنی 59.1 درصد در برابر 28.6 درصد.
پروژه‌هایی که کمیته steering دارند یا از org-balanced voting استفاده می‌کنند، تنوع maintainer را مدت بیشتری حفظ می‌کنند؛ در حالی که پروژه‌های بدون این سازوکارهای ساختاری، زودتر دچار تمرکز می‌شوند.
مستندات خوب به‌تنهایی کافی نیستند. در چند پروژه، با وجود governance docs بسیار دقیق، تمرکز maintainer رخ داده است؛ چون ساختار آن‌ها شامل org-balance voting یا محدودیت‌های steering committee نبوده است.
20 درصد از پروژه‌های graduated اکنون نشانه‌هایی از تمرکز governance پس از graduation نشان می‌دهند و همه آن‌ها در مرحله incubation فاقد سازوکار org-balance بوده‌اند.
در یکی از پروژه‌های incubating که بعداً archived شد، قوانین تنوع سازمانی فقط برای کمیته governance وجود داشت و نه برای بدنه maintainerها.
این داده‌ها تأیید می‌کند که سازوکارهای org-balance باید جایی را پوشش دهند که کار واقعی انجام می‌شود، نه فقط لایه حاکمیتی را.
تعداد contributorها به‌تنهایی شاخص مناسبی برای سلامت پروژه نیست؛ بلکه ساختار governance، تنوع سازمانی و مسیرهای رشد contributorها اهمیت بیشتری دارند.
سه مدل governance
مخزن الگوی پروژه در CNCF سه template برای governance ارائه می‌دهد که هرکدام برای یک الگوی مشخص از پروژه مناسب هستند:
1. Maintainer Council
بهترین گزینه برای: پروژه‌های متمرکز، تکrepo یا با دامنه محدود، که گروهی کوچک و منسجم از contributorها دارند.
در این مدل، یک شورای maintainer که اعضای آن را خودشان انتخاب می‌کنند، همه تصمیم‌های پروژه را می‌گیرد. در اینجا بین افرادی که code می‌نویسند و افرادی که پروژه را اداره می‌کنند، تفکیک جدی وجود ندارد. تصمیم‌ها با lazy consensus گرفته می‌شود؛ یعنی اگر در بازه زمانی مشخص مخالفتی مطرح نشود، تصمیم تأیید شده تلقی می‌شود. رأی‌گیری رسمی فقط برای اختلاف‌ها یا تغییرات governance به کار می‌رود.
زمانی که این مدل خوب کار می‌کند:
– پروژه دامنه‌ای روشن و محدود دارد
– 3 تا 10 maintainer فعال دارد که به‌طور منظم با هم همکاری می‌کنند
– بیشتر contributorها یکدیگر را می‌شناسند و مستقیم ارتباط دارند
– اغلب تصمیم‌ها بدون اختلاف و با consensus گرفته می‌شوند
اجزای کلیدی:
– فایل MAINTAINERS با نام‌ها، affiliationها و حوزه‌های مسئولیت
– فرایند مستند برای اضافه‌کردن و حذف maintainerها، از جمله در صورت inactivity
– تعریف emeritus status برای maintainerهایی که کناره‌گیری می‌کنند
– lazy consensus به‌عنوان روش پیش‌فرض، همراه با thresholdهای مشخص رأی‌گیری برای تغییرات governance
– تیم پاسخ به security که در پروژه‌های کوچک می‌تواند همان گروه maintainerها باشد
چه زمانی باید این مدل را تغییر داد:
اگر یک سازمان به‌دلیل استخدام، acquisition یا خروج contributorهای بیرونی بر فهرست maintainerها مسلط شود، بهتر است org-balanced voting اضافه شود یا پروژه به سمت یک steering committee انتخابی برود. به بخش transition points در ادامه توجه کنید.
2. Elected Steering Committee
بهترین گزینه برای: پروژه‌های بزرگ با جامعه contributor تثبیت‌شده، جایی که پاسخ‌گویی رهبری به جامعه گسترده‌تر اهمیت دارد.
در این مدل، یک steering committee از سوی contributorهای واجد شرایط انتخاب می‌شود و جهت‌گیری راهبردی پروژه را تعیین می‌کند، در حالی که کار فنی را به working groupها یا Special Interest Groupها یا SIGها واگذار می‌کند. انتخابات، accountability ایجاد می‌کند و محدودیت دوره مسئولیت و محدودیت نمایندگی شرکت‌ها نیز تنوع دیدگاه را حفظ می‌کند.
در برخی پروژه‌ها، این نهاد با نام Technical Steering Committee یا TSC یا Governance Committee یا GC شناخته می‌شود و دامنه‌ای صراحتاً technical دارد. بعضی پروژه‌ها هم هم‌زمان یک steering committee برای امور اداری و یک TSC برای امور فنی دارند.
زمانی که این مدل خوب کار می‌کند:
پروژه پایگاه contributor کافی برای برگزاری انتخابات معنادار دارد
سازمان‌های مختلف به‌طور فعال در آن مشارکت می‌کنند
تعداد تصمیم‌ها و گستره کار به‌اندازه‌ای است که یک نهاد governance اختصاصی ارزش افزوده ایجاد می‌کند
پروژه از جدا کردن direction راهبردی از تصمیم‌های فنی روزمره سود می‌برد
اجزای کلیدی:
– فرایند انتخابات با eligibility، nomination و روش رأی‌گیری مستند
– محدودیت دوره مسئولیت، معمولاً 1 تا 2 سال
– محدودیت در نمایندگی شرکت‌ها، مثلاً حداکثر 1 تا 2 عضو از هر سازمان
– واگذاری روشن اختیار به working groupها و SIGها
– فرایند مستند برای حذف اعضای steering، از جمله در صورت عدم عملکرد در دوره مسئولیت
– یادداشت‌های عمومی جلسات و ثبت تصمیم‌ها
چرا این مدل با تنوع پایدار ارتباط دارد:
پروژه‌هایی که governance را از execution جدا می‌کنند، تنوع سازمانی را برای مدت بیشتری حفظ می‌کنند؛ زیرا عضویت در committee محدودیت سازمانی دارد، حتی اگر ترکیب maintainerها تغییر کند. این محدودیت‌های سازمانی مانند یک حفاظ ساختاری عمل می‌کنند و مستقل از این هستند که چه کسی بیشترین code را می‌نویسد.
چه زمانی باید این مدل را تغییر داد:
ساختار governance باید با اندازه فعلی پروژه هماهنگ باشد؛ یعنی اگر پروژه بالغ‌تر یا کوچک‌تر شده، باید ساختار را ساده‌تر کرد. اگر committeeها حوزه‌های هم‌پوشان دارند، working groupها leader فعال ندارند یا پیچیدگی هماهنگی به‌جای بهبود تصمیم‌گیری آن را کند کرده است، زمان تجمیع فرارسیده است. ادغام نهادهای تکراری، کاهش کرسی‌ها یا ادغام working groupهایی با دامنه نزدیک، همگی انتقال‌های معتبر governance هستند.
3. Federated Subproject Governance
بهترین گزینه برای: پروژه‌های umbrella که از چند subproject نیمه‌مستقل تشکیل شده‌اند و هرکدام maintainerها و چرخه release مخصوص خود را دارند.
در این مدل، یک نهاد steering هماهنگی میان subprojectها را انجام می‌دهد و هر subproject خودش governance مستقل دارد. نهاد steering مسائل مشترک را مدیریت می‌کند؛ از جمله زیرساخت مشترک، brand، پاسخ به security و حل اختلاف بین subprojectها.
زمانی که این مدل خوب کار می‌کند:
– پروژه واقعاً از subprojectهای مجزا با گروه‌های contributor متفاوت تشکیل شده است
– subprojectها چرخه release، دامنه یا جامعه کاربری متفاوت دارند
– یکپارچه‌کردن همه subprojectها در یک ساختار governance واحد، اصطکاک ایجاد می‌کند
– زیرساخت یا brand مشترک به اندازه‌ای هست که هماهنگی را ارزشمند کند
اجزای کلیدی:
– مستندات governance جداگانه برای هر subproject
– نهاد steering با اختیار مستند در تصمیم‌های cross-cutting
– فرایند اضافه‌کردن و حذف subprojectها
– معیارهای سلامت و چرخه عمر subproject، شامل active، maintenance و archived
– مسیر روشن برای escalation از subproject به نهاد steering
چه زمانی باید این مدل را تغییر داد:
ساختارهای federated هم باید کوچک شوند و هم بزرگ. subprojectها و SIGهایی که contributor فعال خود را از دست داده‌اند، scope خود را کامل کرده‌اند یا با گروه دیگری همگرا شده‌اند، بهتر است archived یا consolidated شوند، نه اینکه به‌صورت پوسته‌های خالی ادامه پیدا کنند. بخش مهمی از governance این است که واقعاً از آن استفاده شود. برای مثال، اجرای چرخه عمر subproject اهمیت دارد؛ چون SIGهای غیرفعال می‌توانند ظاهری از governance گسترده ایجاد کنند، در حالی که کار واقعی در گروه‌های کمتری متمرکز شده است.
org balanced voting: سازوکاری ساختاری که با هر سه مدل کار می‌کند
org-balanced voting رأی‌های governance را به‌جای افراد، بر اساس سازمان‌ها تخصیص می‌دهد تا نفوذ رأی یک شرکت فقط با افزایش تعداد maintainerهایش بیشتر نشود. محدود کردن رأی هر سازمان، معمولاً به یک یا دو رأی، مانع از آن می‌شود که یک شرکت تنها با تعداد بالای نیروهایش بر governance مسلط شود.
این الگو در جلوگیری از تمرکز governance مؤثر بوده است. org-balanced voting از تصمیم‌های governance محافظت می‌کند، اما به‌تنهایی تضمین نمی‌کند که ترکیب maintainerها متوازن باشد. یک پروژه می‌تواند org-balanced voting داشته باشد، اما همچنان بیشتر maintainerهایش از یک شرکت باشند؛ این سازوکار فقط اجازه نمی‌دهد این اکثریت به کنترل متناسب governance تبدیل شود.
پروژه‌ها باید درباره دامنه این سازوکار هم تصمیم بگیرند. در عمل، نسخه‌های مؤثر این روش، سقف رأی هر سازمان را برای تصمیم‌های governance مانند انتخابات steering، تغییرات governance و direction راهبردی، روی یک یا دو رأی قرار می‌دهند؛ در حالی که تصمیم‌های فنی مانند code review، merge authority و release را به maintainerهای فردی و بر پایه lazy consensus می‌سپارند.
سقفی بالاتر از دو رأی تاکنون کارآمدی قابل‌توجهی نشان نداده است؛ پروژه‌هایی با سقف شش رأی هم همچنان دچار تمرکز شده‌اند. در اینجا دامنه اهمیت زیادی دارد؛ اینکه org-balance برای همه تصمیم‌ها اعمال شود یا فقط برای governance.
این سازوکار زمانی بیشترین اثر را دارد که با یک contributor ladder همراه شود که maintainerهای خارج از سازمان غالب را فعالانه رشد می‌دهد. این مکانیزم را می‌توان روی هر سه مدل بالا نیز اعمال کرد: یک Maintainer Council می‌تواند آن را برای تصمیم‌های governance بپذیرد و در عین حال lazy consensus را برای کار فنی روزمره حفظ کند؛ یک Steering Committee می‌تواند از org-balanced elections استفاده کند؛ و یک پروژه Federated می‌تواند رأی‌های org-balanced را در سطح steering الزامی کند.
در میان 72 پروژه CNCF، این سازوکار قوی‌ترین پیش‌بینی‌کننده مشاهده‌شده برای تنوع پایدار است. پروژه‌هایی که هیچ سازوکار org-balance ندارند، بیشترین احتمال را برای تجربه تمرکز governance پس از graduation دارند.
هماهنگ‌کردن مدل governance با اندازه پروژه
آستانه‌های اندازه در جدول زیر نشان می‌دهد که با رشد گروه‌ها، هماهنگی چگونه تغییر می‌کند. پژوهش‌ها درباره پویایی گروه‌های همکاری، از جمله مدل لایه‌ای Dunbar، نشان می‌دهد که اعتماد مستقیم در گروه‌هایی با حدود 5 تا 15 نفر به‌خوبی عمل می‌کند؛ اما گروه‌های بزرگ‌تر برای حفظ پاسخ‌گویی به delegation و ساختار رسمی نیاز دارند.
در داده‌های CNCF، پروژه‌هایی که کمتر از 8 maintainer دارند، تقریباً همیشه بر پایه consensus اداره می‌شوند؛ اما بالاتر از این تعداد، بیشتر آن‌ها سراغ رأی‌گیری تعریف‌شده یا ساختار نقش‌ها می‌روند. گذار به steering committee و مدل‌های federated کمتر از تعداد افراد و بیشتر از پیچیدگی سازمانی تأثیر می‌گیرد؛ مثل چند repo، چند شرکت مشارکت‌کننده یا ریسک تمرکز.
ویژگی پروژه
مدل پیشنهادی
دلیل
تکrepo، 3 تا 10 maintainer، 1 تا 3 سازمان
Maintainer Council
هزینه کم، اعتماد بالا. governance نباید از خود پروژه پیچیده‌تر باشد.
تکrepo، 10 تا 20 maintainer، 3 تا 5 سازمان
Maintainer Council با نقش‌های تعریف‌شده
می‌توان حوزه‌های مسئولیت مشابه SIG اضافه کرد و فرایند تصمیم‌گیری را مستند ساخت، اما هنوز برای یک steering committee کامل زود است.
چند repo، بیش از 20 maintainer، بیش از 5 سازمان
Elected Steering Committee یا Federated Subproject
ساختار project… 😊
