گیتهاب بهتر برای نگهدارندگان اوپنسورس
خلاصهٔ کاملتر
وقتی Mat Duggan لیست آرزوهاشو از یه جایگزین گیتهاب نوشت، بیشتر خواستههاش حول Stacked PRs، بازخورد قبل از push، و review آفلاین بود. نویسندهی این مقاله نظر دیگهای داره: تقریباً همهی اون موارد، مشکلات سمت کلاینت هستن و کلاینتها دارن خودشون حلشون میکنن. Jujutsu stacked changes رو بهتر از هر web UIای مدیریت میکنه، review داره به editor میره، و بازخورد pre-commit باید روی ماشین خودت اجرا بشه.
اما چیزی که نمیشه به کلاینت سپردش اینه: روابط بین پروژهها. چه کسی به تو وابستهست، تو به چی وابستهای، و اون پروژهای که سه سال پیش fork کردی الان کجاست. اینها توی یه ریپوی تنها اتفاق نمیافتن؛ بین ریپوها هستن. و این بخشیه که گیتهاب سالهاست بهش دست نزده.
تنها رابطهای که گیتهاب واقعاً مدل کرده fork هست، چون در ۲۰۰۸ روش استفاده از کد دیگران همین بود. اما در ۲۰۲۶ تو یه خط به manifest اضافه میکنی و forge هیچ معادل آبجکتی برای این رابطه نداره. وابستگیها رو فقط به چشم «چیزی که Dependabot PR تولید میکنه» میبینه.
یکی از مهمترین ویژگیهای پیشنهادی، تست downstreamهاست. وقتی داری یه نسخه از کتابخونهات آماده میکنی، forge باید test suite خودت رو اجرا کنه، بعد سراغ پروژههایی که بهت وابستهن بره و test suiteهاشون رو با تغییر جدیدت اجرا کنه. زبان Rust این کار رو با «crater run» برای کامپایلر انجام میده، اما باید یه دکمه روی هر release PR باشه. الان نگهدارنده از طریق هزار تیکت خشمگین میفهمه که هزار downstream رو خراب کرده — و forge تنها جاییه که هم dependency graph داره هم compute لازم برای اینکه قبل از push بهت بگه.
ویژگی دیگه یه فید برای وابستگانه. اگه میخوای یه تابع deprecated رو در نسخه بعدی حذف کنی، الان یا توی changelog مینویسیش که کسی نمیخونه، یا runtime warning میدی که اکثراً به هیچ انسانی نمیرسه. ایده اینه که یه فید داشته باشی که هر پروژهای لاکفایلش شامل پکیج توئه، بهصورت پیشفرض subscribe باشه. همون کانال میتونه بگه «دنبال نگهدارنده میگردیم»، «ریپو رو منتقل میکنیم»، یا «یه CVE پیدا شده، نسخه patch شده اینجاست.»
در مورد fork networkها هم، وقتی یه پروژه خاموش میشه، معمولاً همه جداگانه fork میکنن، یکی از اون forkها جون میگیره، و کاربران بهمرور از طریق دهانبهدهان پیداش میکنن. forge همهی اینا رو میبینه؛ میدونه upstream هجده ماهه merge نکرده و سه fork دارن release tag فعال و star میگیرن. نمایش این اطلاعات روی صفحهی ریپوی اصلی و اجازه دادن به forkها که خودشون رو «ادامهدهنده» معرفی کنن، خیلی بهتر از network graph ناخواناییه که از ۲۰۱۰ تغییر نکرده.
نویسنده چند پیشنهاد دیگه هم داره: پیشفرضهای امنتر برای CI مثل pinned actions و cache ایزوله، یه cache پروکسی برای پکیجها در CI که لود روی npm و PyPI و بقیه رو کم کنه، و تغییر نام «issues» به «tickets» — چون feature request مشکل نیست، سوال هم مشکل نیست، و این اسمگذاری دمای مکالمه رو از همون اول بالا میبره.
در آخر نویسنده نتیجه میگیره که این ویژگیها معادل enterprise ندارن، چون یه کدبیس داخلی هزار downstream ناشناس نداره. احتمالاً به همین دلیله که گیتهاب هیچوقت اینا رو نساخته. هر کسی که داره یه forge جدید میسازه، میتونه از همینجا شروع کنه.
نکات کلیدی:
- گیتهاب روابط بین ریپوها رو بهدرستی مدل نکرده؛ fork رو میشناسه ولی dependency رو نه
- تست downstream (مثل crater run در Rust) باید یه دکمهی استاندارد روی release PR باشه
- یه فید اطلاعرسانی subscribeشده از طریق lockfile میتونه deprecation و CVE و انتقال ریپو رو به نگهدارندگان وابسته برسونه
- fork network باید وضعیت فعالیت forkها رو روی صفحه ریپوی اصلی نشون بده
- پیشفرضهای CI برای open source ناامنان؛ forge جدید باید pinned actions و cache ایزوله داشته باشه
- cache مرکزی پروکسی در CI میتونه فشار روی registries غیرانتفاعی رو به شدت کاهش بده
- تغییر نام «issues» به «tickets» به کاهش خصومت محیط مشارکت کمک میکنه
