برای سال‌ها، یکی از جذاب‌ترین ویژگی‌های اکوسیستم دات‌نت این بود که حل بعضی از سخت‌ترین مسائل مهندسی فقط یک دستور با ما فاصله داشت:
dotnet add package Polly
dotnet add package AutoMapper
dotnet add package MediatR
dotnet add package MassTransit
dotnet add package FluentAssertions
چند ثانیه بعد، چیزی وارد پروژه میشد که شاید حاصل ده سال توسعه، هزاران مشکل، صدها رفع اشکال و تجربه هزاران سیستم محیط عملیاتی بود؛ بدون آن‌که لازم باشد خودمان آن‌ها را از صفر بسازیم و مهم‌تر از همه:رایگان. یا شاید بهتر باشد بگوییم: چیزی که سال‌ها عادت کرده بودیم آن را رایگان ببینیم. اما بین سال‌های ۲۰۲۵ و ۲۰۲۶، اتفاقی در اکوسیستم دات‌نت افتاد که این فرض را به چالش کشید. کتابخانه AutoMapper مدل مجوزدهی خود را تغییر داد. MediatR همین مسیر را طی کرد. Fluent Assertions از نسخه 8 برای استفاده تجاری به لایسنس پولی نیاز پیدا کرد. MassTransit 9 به یک محصول تجاری تبدیل شد. و در ژوئیه ۲۰۲۶، نوبت به یکی از مشهورترین کتابخانه های دات‌نت رسید: Polly
اما Polly یک تفاوت اساسی داشت. مدل مجوزدهی سورس تغییر نکرد. مخزن کد بسته نشد. کد منبع پشت دسترسی پولی نرفت. Polly تصمیم گرفت چیزی را پولی کند که سال‌ها تقریباً نامرئی بود: نگهداری و شاید تمام داستان جدید متن باز از همین‌جا شروع شود.
زمانی که بسته نرم‌افزاری فقط بسته نرم‌افزاری بود در بسیاری از تیم‌های نرم‌افزاری، انتخاب بسته نرم‌افزاری برای سال‌ها تقریباً یک تصمیم صرفاً فنی بود.
- آیا API خوبی دارد؟
- کارایی آن مناسب است؟
- جامعه کاربری فعال دارد؟
- مستندسازی خوبی دارد؟
- آخرین انتشار نسخه آن چه زمانی بوده؟
- چند GitHub Star دارد؟
- چند بار دانلود شده؟
- و در نهایت، آیا لایسنس آن MIT، Apache یا BSD است؟
اگر پاسخ‌ها مناسب بودند، وابستگی وارد پروژه میشد. اما چیزی در این مدل وجود داشت که کمتر درباره آن صحبت می‌کردیم: چه کسی هزینه ادامه حیات این وابستگی را پرداخت می‌کند؟
فرض کنید کتابخانه ای توسط دو توسعه دهنده نوشته شده است. پروژه موفق میشود. صد پروژه از آن استفاده می‌کنند. بعد هزار پروژه. بعد صد هزار پروژه. شرکت‌های کوچک از آن استفاده می‌کنندبانکها از آن استفاده می‌کنند فینتک ها از آن استفاده می‌کنند سرویس های ابری از آن استفاده می‌کنند. شرکت‌هایی که میلیون‌ها دلار درآمد دارند، بخش‌هایی از محیط عملیاتی خود را روی آن بنا می‌کنند. اما از دید نگهدارنده پروژه چه اتفاقی افتاده است؟ مشکل های بیشتری ایجاد شده‌اند و گزارش اشکال های بیشتری آمده‌اند. سازگاری بیشتری باید حفظ شود. گزارش امنیتی های بیشتری باید بررسی شوند PRهای بیشتری باید بررسی شوند. وابستگی های بیشتری باید بروز شوند CI Pipelineهای بیشتری باید نگهداری شوند Releaseهای بیشتری باید منتشر شوند. اما درآمد پروژه؟ ممکن است تقریباً همان صفر باقی مانده باشد. این پارادوکس مهم متن باز است: موفقیت یک پروژه می‌تواند هزینه نگهداری آن را بالا ببرد، بدون آن‌که منابع نگهداری آن را افزایش دهد.
موج جدید مدل مجوزدهی در دات‌نت
آنچه در دات‌نت اتفاق افتاده را نباید به‌عنوان یک تغییر واحد در نظر گرفت؛ هر پروژه مدل متفاوتی انتخاب کرده است. کتابخانه AutoMapper از نسخه 15 و بعد از آن وارد مدل مجوزدهی جدید Lucky Penny شد. نسخه‌های قبلی تحت لایسنس قبلی باقی ماندند و برای نسخه‌های جدید مسیر Commercial و RPL وجود دارد. کتابخانه MediatR از نسخه 13 و بعد از آن وارد همان مدل جدید شد. نسخه‌های قبل همچنان تحت شرایط قبلی قابل استفاده‌اند. کتابخانه Fluent Assertions از نسخه 8 و بعد، برای استفاده تجاری به لایسنس پولی نیاز دارد. نسخه 7 همچنان متن باز باقی مانده وفیکس های مهم دریافت می‌کند. کتابخانه MassTransit صراحتاً یک محصول تجاری است و نسخه‌های قدیمی‌تر تحت لایسنس های متن باز قبلی باقی مانده‌اند. در Polly، سورس لایسنس تغییر نکرده است؛ اما از ۱۶ نوامبر ۲۰۲۶ مدل متن باز Maintenance Fee برای Maintainer-provided releases اعمال خواهد شد. این تفاوت مهم است. جمله‌ای مثل: همه این کتابخانه ها پولی شدند. از نظر خبری جذاب است، اما از نظر مهندسی دقیق نیست. Commercial Licensing، Dual Licensing، Reciprocal Licensing و Maintenance Fee ساختارهای یکسانی نیستند و مورد Polly شاید از همه جالب‌تر باشد.
Polly واقعاً چه چیزی را پولی کرده است؟
در ۱۴ ژوئیه ۲۰۲۶، تیم Polly اعلام کرد که پروژه از مدلی به نام OSMF استفاده خواهد کرد. تیم پروژه در توضیح تصمیم خود به بخشی از متن باز اشاره کرد که مصرف‌کنندگان معمولاً آن را نمی‌بینند:
- دسته‌بندی و اولویت‌بندی گزارش‌های مسئله
- Reviewing Pull Requests
- به‌روزرسانی وابستگی‌ها
- Security Reports
- تمدید گواهی
- Build Infrastructure
- CI
- Release Management
- مدیریت جامعه کاربری
- Publishing
تمام این فعالیت‌ها یک ویژگی مشترک دارند: کد جدید تولید نمی‌کنند، اما بدون آن‌ها کتابخانه قابل اعتماد باقی نمی‌ماند. اینجاست که فلسفه OSMF شکل می‌گیرد. سورس کد همچنان متن باز است. اما اگر یک سازمان از نسخه باینری رسمی نگهدارنده پروژه برای فعالیت درآمدزا استفاده کند، بخشی از هزینه نگهداری پروژه را پرداخت می‌کند. این هزینه نگهداری، هزینه مجوز نیست. قرارداد پشتیبانی هم نیست. توافق‌نامه سطح خدمت ایجاد نمی‌کند. رفع اشکال تضمین‌شده نمی‌خرد و پشتیبانی اولویت‌دار ایجاد نمی‌کند. در واقع، سازمان بابت یک قابلیت مشخص پول نمی‌دهد؛ برای ادامه سلامت عمومی پروژه پول می‌دهد.
برای Polly مبلغ اعلام‌شده:
۲۰ دلار در ماه برای کل سازمان است. نه برای هر توسعه دهنده. نه برای هر برنامه. نه برای هر سرور. نه برای هرکانتینر. و نه حتی برای هر پروژه. اگر سازمان شما ده محصول داشته باشد که از Polly استفاده می‌کنند، هزینه نگهداری همچنان یک هزینه نگهداری در سطح سازمان است. اما آستانه آن هم مهم است. هزینه نگهداری زمانی اعمال میشود که شرکت حداقل از یک محصول یا پروژه استفاده‌کننده از Polly، سالانه حداقل ۲۰۰۰۰ دلار درآمد ایجاد کند. معیار سود نیست؛ معیاردرآمد است. و لازم نیست خود برنامه مستقیماً فروخته شود. اگر برنامه رایگان باشد، اما از تبلیغات، خدمات پولی یا روش دیگری برای سازمان درآمد ایجاد کند، می‌تواند مشمول Fee باشد. افراد مستقل، کاربر شخصی / غیرتجاری ها، دانشجوها، سازمان های زیر آستانه و سازمان غیرانتفاعی که درآمد مرتبط با استفاده از Polly ندارند، طبق اعلام پروژه Fee پرداخت نمی‌کنند. اینجا ظریف‌ترین بخش ماجرا قرار دارد. OSMF میان دو چیز تمایز ایجاد می‌کند: Source Code و Maintainer-provided Binary Release
قالب رسمی EULA مربوط به OSMF تصریح می‌کند که سورس تحت مجوز متن باز اصلی باقی می‌ماند، در حالی که EULA می‌تواند برای نسخه باینری رسمی هزینه نگهداری تعریف کند.
همچنین کاربر می‌تواند Source را خودش Compile کند و تحت مجوز اصلی از باینری خود استفاده کند. یعنی اگر سازمان نمی‌خواهد هزینه نگهداری را پرداخت کند، از نظر نظری راه دارد: Source را بگیرد، خودش Build کند، بسته نرم افزاری خودش را تولید کند، آن را در Private Feed قرار دهد و Lifecycle آن را خودش مدیریت کند. از نظر حقوقی، OSMF با تغییر مجوز تفاوت دارد. در تغییر مجوز ممکن است لایسنس خود نرم افزار عوض شود. اما در OSMF، Source License دست‌نخورده می‌ماند و هزینه نگهداری به مصرف Maintainer-provided Binary متصل میشود. یکی از سؤال‌هایی که خیلی سریع درباره Polly مطرح شد، به Microsoft مربوط بود. Microsoft Packageهایی مانند:
Microsoft.Extensions.Resilience و Microsoft.Extensions.Http.Resilience را بر پایه Polly ارائه می‌کند. پس اگر برنامه ما Polly را مستقیماً Reference نکند، اما بسته مایکروسافت Polly را وارد گراف وابستگی‌ها کند، چه؟ هزینه نگهداری برای Dependencyهایی است که پروژه شما مستقیماً انتخاب کرده و نام برده است.
اگر کتابخانه صرفاً به دلیل Dependency یک بسته نرم افزاری دیگر وارد گراف شود، Transitive Dependency محسوب میشود و هزینه نگهداری مستقیم آن بر عهده مصرف‌کننده نهایی نیست. پس اگر Microsoft.Extensions.Http.Resilience وابستگی مستقیم شما باشد و Polly فقط از طریق آن وارد گراف شود، رابطه هزینه نگهداری طبق قوانین عمومی OSMF متفاوت است.
مشکل واقعی شاید پول نباشد؛ انگیزه است
این اتفاق می‌تواند نتیجه قابل پیش‌بینی ناهماهنگی انگیزه‌ها بین نگهدارنده پروژه ومصرف‌کننده تجاری باشد. فرض کنید یک کتابخانه موفق است. هرچه موفق‌تر شود، شرکت های بیشتری آن را مصرف می‌کنند. هرچه شرکت های بیشتری از آن استفاده کنند، درخواست Maintenance بیشتر میشود. اما اگرمدل کسب‌وکار پروژه وجود نداشته باشد، موفقیت پروژه لزوماً چیزی به Maintainer نمی‌دهد جز:
- Issue بیشتر
- Expectation بیشتر
- Support Load بیشتر
- Responsibility بیشتر
- و احتمالاً Burnout بیشتر
از این زاویه، یک پروژه متن باز می‌تواند قربانی موفقیت خودش شود. یک شرکت معمولاً از وابستگی مهم خود انتظار دارد پایدار باشد، Security Fix بگیرد، با نسخه‌های آینده Runtime سازگار شود، Breaking Changeهایش قابل پیش‌بینی باشد، مستندات داشته باشد، باگ های جدی‌اش Fix شوند و Release منظم داشته باشد. اما اگر هیچ قرارداد یا رابطه اقتصادی وجود نداشته باشد، Maintainer ممکن است بپرسد: چرا من باید همه این تعهدات ضمنی را نسبت به بیزینس شما داشته باشم؟
مصرف‌کننده ممکن است ارزش اقتصادی واقعی از پروژه دریافت کند، اما در پایداری اقتصادی آن تقریباً هیچ سهمی نداشته باشد. این تحلیل الزاماً به این معنا نیست که همه مصرف‌کننده ها باید هزینه نگهداری بدهند یا همه Maintainerها باید Commercial شوند.
هوش مصنوعی وارد میشود
تا اینجا مشکل را میشد با Economics Open Source توضیح داد. اما هوش مصنوعی معادله را پیچیده‌تر کرده است؛ چون هوش مصنوعی هم‌زمان دو نیروی متناقض ایجاد کرده است:
از یک طرف، ساخت کد را ارزان کرده؛ از طرف دیگر، نگهداری و Review آن Code را حذف نکرده است. فرض کنیم هوش مصنوعی بتواند Source Code یک Retry Library را تولید کند. آیا واقعاً Polly را بازتولید کرده است؟ کد فقط بخشی از محصول است. قسمت دیگری وجود دارد که در مخزن کد به‌سادگی قابل اندازه‌گیری نیست:
حافظه نهادی
- چرا این شرط در کد وجود دارد؟
- چرا این API این‌طور طراحی شده است؟
- چرا این Lock اینجا قرار گرفته؟
- چرا این Retry در این حالت متفاوت رفتار می‌کند؟
- چرا تستی با Scenario بسیار عجیب وجود دارد؟ احتمالاً چون سال‌ها پیش، درمحیط عملیاتی اتفاقی افتاده است.
هوش مصنوعی شاید بتواند هزار خط کد تولید کند، اما نمی‌تواند به‌سادگی: ده سال سابقه شکست‌های عملیاتی تولید کند.
هر Bug Fix در Framework بالغ، در بسیاری از مواقع بقایای یک رخداد عملیاتی است. هر حالت مرزی چیزی را نشان می‌دهد که یک‌بار شکسته است. هر گزینه پیکربندی شاید نتیجه سال‌ها تجربه باشد. هر آزمون بازگشت ممکن است یادگار یک شکست واقعی باشد. پس وقتی بسته نرم‌افزاری نصب می‌کنیم، فقط کد نمی‌گیریم. در بهترین پروژه‌ها: تجربه انباشته می‌گیریم.
تا اینجا درباره مصرف کننده ها صحبت کردیم، اما سمت Maintainer هم تغییر بزرگی در حال رخ دادن است.
هوش مصنوعی هزینه تولید مشارکت را بسیار پایین آورده است. یک مشارکت‌کننده می‌تواند ظرف یک دقیقه Agent را وادار کند ده‌ها فایل را تغییر دهد. اما Maintainer هنوز باید تغییرات را بفهمد، Review کند، تست کند، سازگاری آن را ارزیابی کند، Edge Caseها را ببیند و Responsibility مربوط به مرج را بپذیرد. هزینه تولید پایین آمده است؛ هزینه بازبینی نه.
این یعنی متن باز ممکن است وارد دوره‌ای شود که Supply Code فراوان است، اما Attention Maintainer کمیاب. قبلاً برای ارسال یک PR نسبتاً بزرگ، مشارکت‌کننده مجبور بود مخزن کد را بفهمد، Build کند، مسئله را Reproduce کند، کد را تغییر دهد، تست بنویسد و احتمالاً زمان قابل توجهی سرمایه‌گذاری کند. این Friction خودش نوعی Filter بود. اما Agent این Filter را حذف کرده است. متن باز شاید از دوره مشارکت گسترده به سمت گزینش‌گری سخت‌گیرانه حرکت کند.
یعنی مسئله آینده این نباشد که: چه کسی می‌تواند Contribution بدهد؟ بلکه: چه کسی اجازه دارد Attention Maintainer را مصرف کند؟
اگر کد تولیدشدنی شود، ارزش از نرم افزارهایی که فقط کد آماده ارائه می‌کنند، به سمت چیزهایی می‌رود که سخت‌تر قابل کپی هستند.
چه چیزهایی سخت‌تر قابل کپی‌اند؟
- Production History
- Trust
- Distribution
- Ecosystem
- Network Effects
- Data
- Operational Expertise
- Customer Relationships
- Compliance
- Support
- Security Track Record
- Brand
- Institutional Knowledge
اگر مزیت اصلی یک کتابخانه این باشد که Developer را از نوشتن ۲۰۰ خط کد تکراری و تشریفاتی نجات می‌دهد، هوش مصنوعی احتمالاً تهدید بزرگی برای آن است. اما اگر مزیت اصلی آن این باشد که ده سال است در هزاران Production Deployment، شکست های واقعی را پشت سر گذاشته، داستان متفاوت است.
دیگر فقط Build vs Buy نیست
مدل قدیمی تصمیم گیری اغلب این بود: Build or Buy. اما در متن باز عصر هوش مصنوعی، تصمیم دقیق‌تر می‌تواند چیزی شبیه این باشد:
- Build
- Buy
- Borrow
- Fork
- Self-host
- Self-build
- Sponsor
- Contract
- Transitive consume
هزینه ایجاد اولیه و هزینه مالکیت و نگهداری را با هم اشتباه نگیریم
این خطا احتمالاً در سال‌های آینده بسیار رایج خواهد شد. رهبرفنی می‌گوید MediatR را لازم نداریم؛ Agent در دو ساعت برایمان Dispatcher می‌سازد. ممکن است درست باشد.
اما سؤال بعدی چیست؟
- پنج سال دیگر چه کسی آن Dispatcher را نگه می‌دارد؟
- Cancellation چگونه مدیریت میشود؟
- Open Genericها چه می‌شوند؟
- Pipeline Ordering چه میشود؟
- Exception Semantics چه میشود؟
- Telemetry؟
- Source Generation؟
- AOT؟
- Thread Safety؟
- Performance؟
- Backward Compatibility؟
- Documentation؟
- Onboarding Developer جدید؟
هر کدی که داخل مخزن کد شما باشد، الزاماً دارایی نیست. بعضی کدها بار و مسئولیت نگهداری هستند. کد باید فهمیده شود. تست شود. بررسی شود. امن شود. ارتقا داده شود. از رده خارج شود و روزی حذف شود. در نتیجه، وقتی وابستگی خارجی را با کد داخلی تولیدشده توسط هوش مصنوعی جایگزین می‌کنیم، لزوماً هزینه را حذف نکرده‌ایم. فقط محل ثبت آن هزینه را عوض کرده‌ایم. به جای Vendor / OSS Risk داریم Internal Ownership Risk
خطر دیگر هوش مصنوعی برای نگهدارنده پروژه ها
هوش مصنوعی فقط هزینه کد زدن را کاهش نمی‌دهد؛ ممکن است تعداد موارد زیر را نیز افزایش دهد:
- Issue
- PR
- Feature Request
- Security Finding
- و حتی Noise
یعنی نگهدارنده پروژه همان زمان محدود قبلی را دارد، اما ورودی بسیار بیشتری دریافت می‌کند. از این منظر، تجاری‌سازی فقط درباره درآمد نیست. ممکن است ابزاری برای Filtering Demand هم باشد. وقتی همه‌چیز رایگان است، درخواست نیز رایگان است. وقتی رابطه اقتصادی شکل می‌گیرد، اولویت‌بندی ممکن است واقعی‌تر شود. در متن باز کلاسیک، مشارکت‌کننده کسی بود که زمان صرف کرده بود. هوش مصنوعی این هزینه ورودی را کاهش می‌دهد. اما پایین آمدن Cost Contribution لزوماً Contribution Quality را افزایش نمی‌دهد.
- ممکن است نگهدارنده پروژه مجبور شود برای محافظت از زمان خود:
- External PR را محدود کند
- سطح اعتماد مشارکت‌کننده ایجاد کند
- کنترل‌های خودکارسخت‌گیرانه‌تری بسازد
- AI-generated PR را Label یا رد کند
- مشارکت‌کننده تأییدشده بیشتری بخواهد، یا Contribution را از مدل مشارکت کاملاً باز به مدلهسته گزینش‌شده نزدیک کند.
آیا باید از پولی‌شدن متن باز ناراحت باشیم؟
این سؤال پاسخ ساده‌ای ندارد. از یک طرف، نگهدارنده پروژه حق دارد درباره پایداری بلندمدت پروژه تصمیم بگیرد. از طرف دیگر، مصرف کننده نیز حق دارد نگران تغییر شرایط استفاده چیزی باشد که معماری خود را روی آن بنا کرده است.
از طرف نگهدارنده پروژه
- زمان نگهداری واقعی است.
- Security Responsibility واقعی است.
- فرسودگی واقعی است.
از طرف سازمان بزرگ
- خرید سازمانی واقعی است.
- انطباق واقعی است.
- بودجه واقعی است.
- تأیید تأمین‌کننده واقعی است.
- بررسی مجوز واقعی است.
- هزینه مهاجرت واقعی است.
در نتیجه، تقلیل بحث به ۲۰ دلار که چیزی نیست منصفانه نیست. همان‌طور که تقلیل آن به نگهدارنده پروژه حریص شده هم منصفانه نیست. در سازمان بزرگ ، هزینه فرایندی / هزینه انجام معامله یکی نیستند. ممکن است لایسنس سالانه Polly فقط ۲۴۰ دلار باشد، اما سازمان برای پرداخت آن نیاز داشته باشد:
- ثبت و پذیرش تأمین‌کننده انجام دهد
- بررسی حقوقی بگیرد
- مدارک مالیاتی بررسی کند
- Security Review انجام دهد
- سفارش خرید بسازد
- فرایند صورتحساب ایجاد کند
- ثبت قرارداد نگه دارد و فرایند تمدید داشته باشد.
در نتیجه اقتصادی ممکن است:
$240 License Cost به $5,000 Internal Process Cost منجر شود. این مشکل Polly نیست. مشکل فرایند خرید در سازمان‌های بزرگ است. اما در تصمیم واقعی باید لحاظ شود. به همین دلیل .NET Foundation هم صراحتاً خرید سازمانی و انطباق را بخشی از ارزیابی مصرف کننده ها می‌داند.
در طرف مقابل، ممکن است سازمان بگوید: ما ۲۰ دلار نمی‌دهیم؛ خودمان Build می‌کنیم، اما اگر یک Senior Engineer فقط دو ساعت در سال صرف Pipeline داخلی، Security Update یا Upstream Sync کند، شاید کدآن از هزینه نگهداری بیشتر شود. اگر Fork واقعی داشته باشید، هزینه می‌تواند بسیار بزرگ‌تر شود. بنابراین تصمیم باید بر اساس: هزینه کل مالکیت باشد، نه مبلغ فاکتور
فورک کردن یک Event نیست؛ یک تعهد بلندمدت است
ساخت Fork در GitHub چند ثانیه طول می‌کشد. Maintaining Fork ممکن است ده سال زمان ببرد. این دو را نباید یکی دانست.
Fork یعنی:
- Upstream Monitoring
- Security Monitoring
- Merge Strategy
- Release Engineering
- Build Pipeline
- Package Distribution
- Compatibility
- Ownership
- Bus Factor
- Exit Strategy
هر بار کسی می‌گوید: «Fork می‌کنیم.»
سؤال بعدی باید این باشد:
چه کسی Owner آن Fork است و بودجه پنج‌ساله آن چیست؟
مدیریت وابستگی‌ها حالا مدیریت ریسک معماری است
شاید بزرگ‌ترین تغییر ذهنی همین باشد. تا دیروز بازبینی وابستگی‌ها یعنی:
- Version چیست؟
- License چیست؟
- آسیب‌پذیری دارد؟
اما امروز این‌ها دیگر کافی نیستند.
یک وابستگی مهم مجموعه‌ای از چیزها را وارد سیستم می‌کند:
- Code
- Maintainer
- Governance
- Funding Model
- License Model
- Binary Distribution Model
- Transitive Dependencies
- زنجیره تأمین نرم‌افزار
- سطح مواجهه امنیتی
- Commercial Risk
- Procurement Risk
- Migration Cost
- Institutional Dependency
- و حالا AI Agent Behavior
به همین دلیل، دیگر فقط یک جزئیات پیاده‌سازی نیست. برای بسته حیاتی ، یک تصمیم معماری است.
یک سیاست مدیریت وابستگی‌ها برای سال ۲۰۲۶ باید چه سؤالاتی بپرسد؟
برای بسته های مهم، یک بازبینی معماری بالغ حداقل باید این موارد را بررسی کند:
- آیا قابلیت موردنظر داخل خود دات نت وجود دارد؟
- اگر نه، چرا این بسته انتخاب شده است؟
- لایسنس و شرایط توزیع باینری چیست؟
- مدل تأمین مالی و Maintenance پروژه چیست؟
- وابستگی مستقیم و وابستگی های غیرمستقیم مهم آن کدام‌اند؟
- سابقه امنیتی و Release Cadence چگونه است؟
- اگر نگهدارنده پروژه فردا پروژه را Archive، Commercialize یا Relicense کند، راهبرد خروج چیست؟
- اگر Agent این بسته را پیشنهاد کرده، آیا Version، License و Source آن با داده زنده بررسی شده است؟
و مهم‌تر از همه:
اگر بسته را حذف کنیم و خودمان کد را بسازیم، آیا واقعاً هزینه را کم کرده‌ایم یا فقط نگهداری را داخل سازمان منتقل کرده‌ایم؟ این سؤال‌ها شاید برای یک ابزار کوچک کمکی سه‌خطی سخت‌گیری بیش از نیاز باشند. اما برای بسته ای که مسیر حیاتی کسب‌وکار شما از آن عبور می‌کند، دیگربیش از نیاز نیستند.
آینده احتمالاً نه «همه OSS» است و نه «همه AI-generated»
در بحث هوش مصنوعی معمولاً دیدگاه‌های افراطی جذاب‌اند: «دیگر هیچ‌کس بسته استفاده نمی‌کند.» یا «هوش مصنوعی فقط بسته های موجود را استفاده می‌کند.»
اما واقعیت احتمالاً بسیار نامرتب‌تر است. هوش مصنوعی ابزار کوچک کمکی کوچک را جایگزین می‌کند. هم‌زمان کتابخانه های معروف را بیشتر پیشنهاد می‌دهد. تعداد وابستگی‌ها در بعضی پروژه ها پایین می‌آید. در بعضی پروژه ها Agent آن را بالا می‌برد. Commercial Libraryهای ساده تحت فشار قرار می‌گیرند. زیرساخت های حیاتی ممکن است با افزایش میزان استفاده / پذیرش روبه‌رو شوند. پروژه های متن باز کوچک ممکن است کمتر شوند. پروژه های بزرگ‌تر ممکن است قوی‌تر شوند. نگهدارنده پروژه مشارکت کننده بیشتری دریافت می‌کنند، اما مجبور می‌شوند بیشتر رد کنند. Code ارزان‌تر میشود، امااعتماد گران‌تر. این تناقض نیست؛ تغییر محل ارزش است
در دنیایی که کد گران بود، کتابخانه ارزش زیادی داشت چون:
«لازم نیست خودت بنویسی.»
در دنیایی که هوش مصنوعی کد را ارزان می‌کند، این ارزش پیشنهادی ضعیف‌تر میشود. اما کتابخانه بالغ هنوز می‌تواند بگوید:
«لازم نیست خودت Ownership ده سال تجربه کار در محیط پروداکشن/عملیاتی را قبول کنی.»
این ارزش پیشنهادی بسیار متفاوت است. یعنی بازار از: بازکاربرد کد به سمت بازاستفاده از ریسک حرکت می‌کند. ما فقط کد کتابخانه نمی‌گیریم. ریسکی را به اکوسیستم می‌سپاریم که قبلاً آن مشکل را هزار بار دیده است.
شاید نرم افزار آینده ارزان‌تر ساخته شود، اما گران‌تر نگهداری شود
این احتمال متناقض است. هوش مصنوعی بهره‌وری برنامه‌نویس را بالا می‌برد. قابلیت بیشتری تولید میشود. کد بیشتری وارد محیط عملیاتی میشود. پروژه بیشتری ساخته میشود. اما هر کد جدید، سطح نگهداری و تعمیرات جدیدی ایجاد می‌کند. اگر تولید نرم افزار ده برابر شود، ولی ظرفیت نگهداری فقط دو برابر شود، گلوگاه از توسعه به نگهداری منتقل میشود. پس شاید آینده مهندسی نرم افزار کمتر درباره این باشد که: «چقدر سریع کد می‌نویسیم؟» و بیشتر درباره این باشد که «چقدر هوشمندانه کدی را که مالک می‌شویم محدود می‌کنیم؟»
شاید پولی‌شدن OSS نشانه شکست متن باز نباشد
این تفسیردیگری است که ارزش بررسی دارد. شاید تجاری‌سازی پروژه‌های OSS به این معنی نباشد که متن باز شکست خورده است. شاید نشان دهد متن باز آن‌قدر موفق شده که به زیرساخت واقعی اقتصاد تبدیل شده است. وقتی یک پروژه شخصی کوچک است، تأمین مالی سؤال مهمی نیست. اما وقتی Bank، Fintech، Cloud Platform و Enterprise روی آن بیزینس اجرا می‌کنند، تأمین مالی دیگر مسئله شخصی نگهدارنده پروژه نیست. به مسئله زنجیره تأمین نرم‌افزار تبدیل میشود. OSMF دقیقاً تلاش می‌کند برای این وضعیت مکانیسم جدیدی تعریف کند. آیا موفق میشود؟
پولی‌شدن Polly شاید کوچک‌ترین بخش داستان باشد
اگر تمام این مقاله را دوباره از بالا نگاه کنیم، عدد ۲۰ دلار تقریباً حاشیه‌ای به نظر می‌رسد. اتفاق مهم‌تر این است که چند فرض قدیمی توسعه نرم‌افزار هم‌زمان در حال شکستن‌اند.
فرض اول: اگر متن باز است، Maintenance آن همیشه رایگان خواهد بود.
شکست.
فرض دوم: اگر کد را لازم داریم، حتماً باید پکیج بگیریم. هوش مصنوعی این را به چالش کشیده است.
فرض سوم: اگر هوش مصنوعی آمده، وابستگی ها بی‌ارزش می‌شوند. Petabridge و Download Data این را به چالش می‌کشند.
فرض چهارم: هر Contribution برای OSS ارزشمند است. AI-generated PR Flood این را زیر سؤال برده است.
فرض پنجم: Package Selection فقط یک Technical Decision است. Licensing جدید دات نت این فرض را عملاً باطل کرده است.
پس آینده چه شکلی است؟
احتمالاً کتابخانه های خیلی ساده بیشتر با Internal AI-generated Code رقابت خواهند کرد. کتابخانه های Critical و Battle-tested همچنان ارزش زیادی خواهند داشت و حتی ممکن است AI Adoption آن‌ها را بیشتر کند. نگهدارنده پروژه های مهم بیشتر به دنبال مدل‌های پایدار خواهند رفت. Commercial Licensing، Sponsorship، Paid Support، OSMF و مدل‌های ترکیبی بیشتر خواهند شد. Open Source Contribution احتمالاً Curatedتر میشود. AI Agentها بسته نرم‌افزاری بیشتری انتخاب خواهند کرد. در پاسخ، سازمان ها Dependency Governance سخت‌گیرانه‌تری خواهند ساخت. و Architecture Teamها مجبور می‌شوند Economic Model یک وابستگی را تقریباً به‌اندازه API آن جدی بگیرند.
وقتی «رایگان» دیگر کافی نیست
شاید بزرگ‌ترین اشتباه ما این بود که متن باز را با «کار رایگان» اشتباه گرفتیم. متن باز درباره حقوق است.
- حق دیدن Source.
- حق تغییر.
- حق Fork.
- حق Build.
- حق Distribution تحت شرایط License.
اما از هیچ‌کدام از این حقوق نتیجه نمی‌شود که فرد دیگری موظف است تا ابد Issueهای ما را بررسی کند، Security Patch بدهد، Release تولید کند، با دات نت بعدی Compatibility ایجاد کند، CI را نگه دارد، Certificate تمدید کند و Binary آماده برای Business ما Publish کند. این کارها هزینه دارند. تا مدت‌ها این Cost پشت Passion Maintainerها پنهان بود. حالا دارد Visible میشود. اما هم‌زمان، هوش مصنوعی اتفاق دیگری رقم زده است. هزینه Creation را پایین آورده. در نتیجه، چیزهای دیگری ارزشمندتر شده‌اند:
- Maintenance
- Curation
- Trust
- Experience
- Distribution
- Security
- Judgment
- Institutional Memory
در چنین دنیایی، شاید سؤال درست درباره Polly این نباشد: «چرا باید ماهی ۲۰ دلار برای یک بسته نرم‌افزاری پول بدهیم؟» و سؤال درست درباره هوش مصنوعی هم این نباشد:
«چرا بسته نرم‌افزاری بخریم وقتی هوش مصنوعی می‌تواند آن را بنویسد؟»
سؤال بهتر این است:
«کدام مسئولیت را می‌خواهیم خودمان Owner شویم و کدام مسئولیت را بهتر است به یک Ecosystem بالغ بسپاریم؟»
- اگر کد را خودمان تولید کنیم، مالکیت آن با ماست.
- اگر بسته نرم‌افزاری را مصرف کنیم، Dependency Risk داریم.
- اگر Fork کنیم، Maintenance Risk داریم.
- اگر Commercial License بخریم، Vendor Risk داریم.
- اگر روی نسخه قدیمی بمانیم، Security و Upgrade Risk داریم.
هیچ انتخابی Free نیست.
فقط نوع هزینه عوض میشود.
و شاید این مهم‌ترین تغییر مهندسی نرم افزار در عصر هوش مصنوعی باشد:
کد دیگر کمیاب‌ترین بخش نرم افزار نیست.
- کد را می‌توان Generate کرد.
- Fork کرد.
- Copy کرد.
- Rewrite کرد.
اما آنچه سخت‌تر Generate میشود:
- اعتماد است.
- تجربه است.
- قضاوت است.
- مسئولیت است.
و سال‌هایی است که طول کشیده تا یک قطعه نرم افزار آن‌قدر شکست بخورد که امروز بتوانیم با خیال راحت آن را در محیط عملیاتی اجرا کنیم. به همین دلیل، ممکن است هوش مصنوعی نه متن باز را بکشد و نه Commercial Software را؛ بلکه بازار را مجبور کند ارزش واقعی هرکدام را دوباره تعریف کند. کتابخانه ای که تنها ارزشش «Code آماده» است، احتمالاً تحت فشار خواهد بود. کتابخانه ای که ارزشش «ده سال Production Knowledge» است، احتمالاً همچنان ارزشمند خواهد ماند. نگهدارنده پروژه که صرفاً Code تولید می‌کند، با AI رقابت خواهد کرد. نگهدارنده پروژه که Trust، Judgment و Reliability تولید می‌کند، شاید از همیشه باارزش‌تر شود و برای ما به‌عنوان Developer، Tech Lead و Architect نیز یک تغییر اساسی رخ داده است.
از این به بعد، وقتی در Pull Request می‌بینیم:
- نباید فقط یک خط XML ببینیم.
- پشت آن ممکن است یک نگهدارنده پروژه باشد.
- یک Business Model.
- یک License.
- یک EULA.
- یک Community.
- یک زنجیره تأمین نرم‌افزار.
- یک سطح مواجهه امنیتی.
- یک Vendor Relationship.
- یک Migration Cost.
- یک Future Risk.
- و شاید ده سال دانش که هیچ Agentی نمی‌تواند ظرف یک Prompt دوباره تولید کند.
مدیریت وابستگی دیگر فقط مدیریت بسته نیست.
و داستان Polly شاید نه پایان متن باز ، بلکه آغاز دورانی باشد که بالاخره مجبور می‌شویم هزینه واقعی نرم‌افزاری را ببینیم که سال‌ها تصور می‌کردیم رایگان است.