مدل منبع باز چین بیشتر احتمال دارد که کند شود تا مسدود شود.

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

چیزی که واقعاً گیر می کند معمولاً ورودی ها و به روز رسانی ها است.

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

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

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

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

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

رویکرد پایدارتر این است که تصور نکنید محاصره ای وجود نخواهد داشت، بلکه شکستن محاصره به چندین مشکل کوچک مقرون به صرفه از قبل است: وزن و زمان اجرا به طور جداگانه ذخیره می شوند، آدرس دانلود و مقدار تأیید با هم ذخیره می شوند، محیط استنتاج برای بازسازی آفلاین ساخته می شود، نتایج ارزیابی بر اساس نسخه بایگانی می شوند، و مسیر انتشار به همان اندازه روشن است. به این ترتیب حتی اگر بالادست به طور ناگهانی خاموش شود، محصول تنها یک ورودی را از دست می دهد و کل قابلیت به طور همزمان آفلاین نخواهد بود.

خندق واقعی مدل منبع باز هرگز این نبوده است که “هیچ کس جرات مدیریت آن را ندارد”، اما “وقتی مدیریت می شود، مدیریت آن تا حدی دشوار است.” ورودی های زیادی وجود دارد که می توان آنها را سفت کرد و بازیابی نسخه هایی که پخش شده اند دشوار است.