تصور کنید تمام کدهای خود را به یک فضای جدید منتقل کرده‌اید، اما هیچ‌کدام از همکاران و دوستانتان آنجا نیستند. برای یک برنامه‌نویس، گیت‌هاب دیگر تنها مکان میزبانی کد نیست، بلکه تنها جایی است که «جامعه» در آن زنده است. این پارادوکس توسعه‌دهنده مدرن است: گیت‌هاب دیگر تنها مکان برای میزبانی کد نیست، اما همچنان تنها مکان برای میزبانی یک جامعه است.
این وضعیت باعث شده تا کل صنعت نرم‌افزار در یک اکوسیستم متمرکز حبس شود؛ حتی زمانی که نارضایتی از پایداری این پلتفرم افزایش یافته است. نبود یک جایگزین اجتماعی قابل‌اتکا، صنعت را مجبور به پذیرش این تمرکزگرایی کرده است. این تنش زمانی به نقطه جوش رسید که بحث‌های گسترده‌ای پیرامون تصمیم Codeberg شکل گرفت؛ این پلتفرم تصمیم گرفت پروژه‌هایی را که عمدتاً توسط هوش مصنوعی زاینده (Generative AI) — شبیه نویسنده‌ای که فقط جملات قبلی را پیش‌بینی می‌کند و نه لزوماً می‌فهمد — نوشته شده‌اند، ممنوع کند.
این اقدام نشان داد که Codeberg خود را یک جایگزین ماموریت‌محور و ایدئولوژیک می‌بیند، نه یک زیرساخت خنثی. بسیاری از کاربران از این تصمیم ناامید شدند، گویی یکی از معدود جایگزین‌های محتمل گیت‌هاب، آن‌ها یا پروژه‌هایشان را رد کرده است. آن‌ها می‌خواستند Codeberg یک جایگزین جهانی باشد؛ گیت‌هابی بهتر و مقصدی بدیهی برای کسانی که تصمیم به ترک گیت‌هاب می‌گیرند.
برای اکثر توسعه‌دهندگان، مشکل پروتکل Git نیست، چون این پروتکل ذاتاً غیرمتمرکز است. مشکل اصلی، زیرساخت‌های پیرامونی است. انتقال به یک پلتفرم جدید شبیه این است که خانه‌های یک محله را به شهر دیگری ببرید؛ شما ساختمان‌ها (کدها) را منتقل می‌کنید، اما نمی‌توانید دوستی‌ها، مغازه‌های محلی و عادت‌های مشترک (لایه اجتماعی) را به راحتی جابه‌جا کنید. هر چیزی که جایگزین گیت‌هاب شود، همچنان به یک لایه اجتماعی مشترک نیاز دارد: هویت‌هایی که مشارکت‌کنندگان از پیش دارند، قراردادهایی که می‌شناسند و روش‌هایی برای کشف پروژه‌ها در سراسر شبکه.
شکاف زیرساختی
به نقل از تحلیل‌های lalitm.com، مانع اصلی ترک گیت‌هاب، مشکل «راه‌اندازی سرد» (Cold Start) در هویت اجتماعی است. گیت‌هاب یک استخر مشترک از هویت‌ها و قراردادها فراهم می‌کند که مشارکت را بی‌دردسر می‌کند. اما وقتی توسعه‌دهنده‌ای به یک میزبان شخصی (Self-hosted forge) مانند Gitea می‌رود، اصطکاک شدیداً افزایش می‌یابد:
- خستگی از حساب‌های کاربری: مشارکت‌کنندگان باید برای هر میزبان (Forge) مجزایی که با آن تعامل دارند، حسابی بسازند. حتی گزارش یک باگ کوچک، نیازمند ثبت‌نام در یک سیستم جدید و یادگیری محیطی ناشناخته است.
- منحنی یادگیری: کاربران باید قراردادهای خاص هر میزبان را برای گزارش باگ‌ها یا ارسال Pull Requestها یاد بگیرند. مگر اینکه کسی واقعاً به آن پروژه اهمیت زیادی بدهد، در غیر این صورت احتمالاً برای این کار وقت نمی‌گذارد.
- مرگ اکتشاف: کشف ارگانیک پروژه‌ها از طریق فیدهای «ستاره‌دار شده» (Starred feeds) تا حد زیادی از بین رفته است. گیت‌هاب فید خود را بازطراحی کرد و زمانی که کشف پروژه دیگر بخشی از تجربه کاربری نبود، عملاً از گردش‌کار توسعه‌دهندگان حذف شد.
زوال تجربه هسته
ناامیدی از گیت‌هاب به این دلیل است که در حالی که ویژگی‌های AI اولویت می‌گیرند، تجربه پایه در حال تخریب است. نویسنده اشاره می‌کند که ابزار Copilot در همه جا دیده می‌شود، اما رابط کاربری برای بررسی Pull Requestهای حجیم همچنان به طرز دردناکی کند و دارای باگ است. این تضاد میان بهره‌وری ابزارهای ابری و حفظ استانداردهای شخصی، یادآور چالش توسعه‌دهندگان Emacs در انتخاب میان مدل‌های محلی و ابری برای کدنویسی است که در آن حریم خصوصی در برابر سرعت قرار می‌گیرد. قابلیت Stacked PRs که بیش از یک دهه در شرکت‌های بزرگ نرم‌افزاری رایج بود، تازه به گیت‌هاب اضافه شده و هنوز ناپایدار به نظر می‌رسد.
تجربه پایه گیت‌هاب کند شده است؛ موارد متعددی وجود دارد که صفحات به طور منظم لود نمی‌شوند و اعلان‌ها (Notifications) غیرقابل اعتماد هستند. خود شرکت گیت‌هاب اخیراً دو حادثه بزرگ را «غیرقابل قبول» توصیف کرد.
این ناپایداری پیامدهای واقعی برای پروژه‌های سطح بالا دارد. در اواخر آوریل ۲۰۲۴، میچل هاشیموتو اعلام کرد که پروژه Ghostty گیت‌هاب را ترک می‌کند. او دلیل این تصمیم را قطعی‌های مکرر دانست؛ از جمله موردی خاص که در آن قطعی GitHub Actions برای دو ساعت بررسی PRها را مسدود کرد. او استدلال کرد که این پلتفرم دیگر مکانی برای «کارهای جدی» نیست.
هاشیموتو تأکید کرد که مشکل از خود Git نیست، بلکه زیرساخت‌های وابسته مانند Issues، PRs و Actions هستند. این نگاه به لایه‌های زیرساختی، با دیدگاه خالق Redis همسو است که معتقد است مهندسان باید به جای تمرکز بر بررسی‌های جزئی کد، کنترل ایده‌ها و معماری کلی را در دست بگیرند. پروژه Ghostty مجبور شد برای یک مهاجرت تدریجی، میان چندین ارائه‌دهنده تجاری و متن‌باز (FOSS) جستجو کند، به جای اینکه به یک جایگزین بدیهی و پیش‌فرض منتقل شود.
ارزیابی جایگزین‌ها
پلتفرم‌های مختلف سعی دارند این خلاء را پر کنند، اما هر کدام هزینه و معامله (Trade-off) خاصی دارند:
- GitLab: بسیار قدرتمند و توانا است اما حس شرکتی (Corporate) شدیدی دارد، حتی بیشتر از گیت‌هاب. این پلتفرم در کمک به کاربران برای برخورد اتفاقی با پروژه‌ها و توسعه‌دهندگان جدید، به اندازه گیت‌هاب مؤثر نیست.
- SourceHut: شفاف و ارزش‌محور است. با این حال، گردش‌کار مبتنی بر ایمیل آن، اگرچه توسط هسته لینوکس آزمایش شده و تایید شده است، برای اکثر کاربران گیت‌هاب غریب و ناشناخته است.
- Forgejo: روی یک پروژه فدراسیون برای اتصال نمونه‌های میزبان شخصی به یک شبکه مشترک کار می‌کند. اگرچه امیدوارکننده است، اما مدتی است در دست توسعه است و همچنان آزمایشی باقی مانده است.
- Radicle: از تکثیر همتا-به-همتا (P2P) برای مخازن استفاده می‌کند و مسائل (Issues) و وصله‌ها (Patches) را در کنار آن‌ها ذخیره می‌کند. با این حال، برای پروژه‌های عمومی بیش از حد خام است؛ کاربران باید صرفاً برای گزارش یک باگ، یک CLI یا اپلیکیشن دسکتاپ نصب کنند.
- Tangled: پروژه‌ای در مرحله آلفا که روی تجربه اجتماعی و کشف متمرکز است. صفحه اصلی آن بلافاصله پروژه‌های جذاب را نشان می‌دهد و حس «گیت‌هاب قدیمی» را تداعی می‌کند.
برخی معتقدند بازار برای یک شرکت «خسته‌کننده» و سودآور — شبیه مدل bunny.net — که فقط روی پایداری و همکاری خوشایند متمرکز باشد، خالی است. شرکتی که هیچ جاه‌طلبی برای تبدیل شدن به «سیستم‌عامل توسعه نرم‌افزار» نداشته باشد یا سعی نکند برنامه‌نویسی را حول محور تکنولوژی‌هایی که سرمایه‌گذاران فعلاً به آن‌ها علاقه دارند بازسازماندهی کند. چنین شرکتی صرفاً از توسعه‌دهندگان و سازمان‌های کوچک‌تر هزینه دریافت می‌کند و با سرعتی رشد می‌کند که توسط همان درآمد پشتیبانی شود.
با این حال، توجیه اقتصادی این مدل جای سؤال دارد. هویت مشترک و کشف پروژه تنها در مقیاس بزرگ ارزشمند می‌شوند. یک شرکت نمی‌تواند صرفاً یک میزبان مخزن بهتر بسازد؛ بلکه باید با لایه اجتماعی به عنوان محصول اصلی برخورد کند تا بتواند بر اثر شبکه‌ای (Network Effect) رقیب فعلی غلبه کند.
اینکه آیا بازیگر جدیدی می‌تواند این مشکل را حل کند یا خیر، همچنان یک سؤال باز است. تا زمانی که پلتفرمی بتواند «چسب اجتماعی» جامعه توسعه‌دهندگان را بازسازی کند، صنعت احتمالاً به دلیل ضرورت، به تحمل قطعی‌های گیت‌هاب و فشار برای پذیرش AI ادامه خواهد داد.
گام بعدی شما
- اگر مدیریت پروژه‌های حساس را بر عهده دارید، استراتژی «پشتیبان‌گیری از متادیتای اجتماعی» (مانند آرشیو کردن Issues) را پیاده کنید.
- پلتفرم‌های فدراسیون مانند Forgejo را برای پروژه‌های کوچک‌تر تست کنید تا با مدل‌های غیرمتمرکز آشنا شوید.
- در صورت تجربه کندی در PRهای حجیم، ابزارهای مدیریت محلی کد را جایگزین رابط وب گیت‌هاب کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو