Microsoft چندین پروژه مهم را با کد و مجوز عمومی منتشر و نگهداری می‌کند، اما این واقعیت به معنی Open Source بودن تمام محصولات و خدماتش نیست. مخزن TypeScript، کد VS Code و بخش‌های مختلف .NET را می‌توان جدا بررسی کرد. خود سرویس GitHub را نباید صرفاً چون میزبان مخزن‌های عمومی است، به‌عنوان یک محصول کاملاً متن‌باز معرفی کرد. تفاوت پروژه، محصول توزیع‌شده و سرویس میزبانی‌شده، نقطه شروع خواندن این موضوع است.
نسخه قبلی مطلب درباره بزرگ‌ترین مشارکت‌کننده جهان و سرمایه‌گذاری سالانه عدد مشخصی می‌داد که منبع قابل بررسی نداشت. این ادعاها کنار گذاشته شده‌اند. صفحه رسمی Microsoft Open Source برنامه و حوزه‌های مشارکت شرکت را معرفی می‌کند، ولی برای تصمیم فنی بهتر است به مجوز، فرایند نگهداری و وابستگی همان پروژه‌ای برسید که واقعاً استفاده می‌کنید.
کد عمومی، مجوز و محصول را از هم جدا کنید
دیدن فایل‌ها در یک مخزن عمومی به تنهایی توضیح کامل حقوق استفاده نیست. مجوز تعیین می‌کند چه استفاده‌ای مجاز است و چه شرط‌هایی باید رعایت شود. توزیع یک محصول ساخته‌شده از همان کد نیز ممکن است نام تجاری، افزونه یا شرایط دیگری داشته باشد. در بررسی، فایل LICENSE و توضیح توزیع را کنار README بخوانید. عبارت کلی «رایگان» این تفاوت‌ها را پوشش نمی‌دهد.
در VS Code، مخزن microsoft/vscode کد منبع را ارائه می‌کند و FAQ رسمی VS Code تفاوت کد و توزیع محصول را شرح می‌دهد. اگر سازمان می‌خواهد build اختصاصی تهیه کند یا توزیع خاصی را نصب کند، باید شرایط همان مورد را بررسی کند. استفاده روزمره از editor و بازتوزیع آن دو فعالیت یکسان نیستند.
این تفاوت برای افزونه‌ها نیز وجود دارد. editor می‌تواند متن‌باز باشد ولی یک extension مجوز و سرویس خارجی جدا داشته باشد. توسعه‌دهنده نباید اعتبار یک جزء را به همه extensionهای نصب‌شده تعمیم دهد. فهرست افزونه‌های لازم تیم، منشأ آن‌ها و داده‌ای که به خارج می‌فرستند را ثبت کنید. انتخاب محیط کار با نصب مجموعه‌ای ناشناخته از ابزارها کامل نمی‌شود.
TypeScript یک پروژه زبان و ابزار است
مخزن TypeScript محل کد، issueها و مسیر مشارکت آن است. TypeScript به ابزارهای بررسی type و تبدیل کد مربوط است؛ اجرای برنامه همچنان به محیط مناسب JavaScript نیاز دارد. آن را با یک Runtime یا سرویس ابری یکی نگیرید. پروژه‌ای که TypeScript استفاده می‌کند مجبور نیست برای همین دلیل در Azure مستقر شود.
برای یک تیم، ارزش عملی می‌تواند خواندن issue مرتبط با خطای compiler یا بررسی تفاوت نسخه‌ها باشد. وجود مخزن عمومی کمک می‌کند علت تغییر رفتار را پیگیری کنید، ولی مسئول نگهداری پروژه شما همچنان باید نسخه را انتخاب و تغییر را مرور کند. upgrade بی‌بررسی می‌تواند خطای تازه در build یا اختلاف type ایجاد کند. داشتن منبع عمومی، نیاز به قرارداد نسخه را از بین نمی‌برد.
اگر bug report می‌فرستید، نمونه کوچک و بدون داده خصوصی تهیه کنید. نسخه ابزار، انتظار شما و خروجی واقعی را بنویسید. گزارش کلی «کار نمی‌کند» برای نگهدارنده قابل اقدام نیست. نمونه‌ای که فقط مسئله مورد نظر را بازتولید می‌کند هم به تیم شما کمک می‌کند و هم هزینه بررسی بیرونی را کمتر می‌کند. انتشار مخزن واقعی مشتری برای توضیح خطا لازم نیست.
.NET مجموعه‌ای از پروژه‌هاست
نام .NET به یک اکوسیستم اشاره دارد. برای مثال dotnet/runtime بخشی از آن را پوشش می‌دهد. SDK، کتابخانه‌ها و ابزارهای دیگر مخزن‌ها و چرخه‌های خود را دارند. وقتی درباره مجوز یا پشتیبانی تصمیم می‌گیرید، نام بسته و نسخه دقیق را مشخص کنید. عبارت «همه .NET متن‌باز است» بدون محدوده، سؤال عملی مصرف‌کننده را پاسخ نمی‌دهد.
چرخه پشتیبانی با عمومی بودن کد فرق دارد. ممکن است کد نسخه‌ای همچنان در دسترس باشد ولی آن نسخه دیگر به‌روزرسانی عادی دریافت نکند. تیمی که سرویس Production نگه می‌دارد باید تاریخ و سیاست پشتیبانی را از مرجع همان محصول بخواند. توانایی ساختن نسخه قدیمی از کد، هزینه نگهداری امنیتی آن را به‌طور خودکار حل نمی‌کند.
پروژه‌های عمومی فرصت مطالعه تصمیم‌های طراحی را فراهم می‌کنند. issue، discussion و تغییر کد ممکن است زمینه یک محدودیت را روشن کنند. با این حال پاسخ یک مشارکت‌کننده در گفت‌وگو را تعهد قراردادی محصول ندانید. برای قابلیت حیاتی، مستند رسمی و قرارداد پشتیبانی باید مرجع تصمیم باشند. این تفاوت از انتظار نامتناسب از نگهدارنده داوطلب یا تیم پروژه جلوگیری می‌کند.
Azure SDK با خود سرویس Azure فرق دارد
پروژه Azure SDK مسیر دسترسی به SDKهای زبان‌های مختلف را نشان می‌دهد. SDK، کتابخانه‌ای برای ارتباط با سرویس است؛ متن‌باز بودن آن به معنی متن‌باز بودن کل سرویس میزبانی‌شده نیست. اگر برنامه از API مدیریت‌شده استفاده می‌کند، همچنان به حساب، قرارداد، شبکه و قابلیت‌های همان سرویس وابسته است.
کد SDK می‌تواند عیب‌یابی درخواست و فهم رفتار retry را آسان‌تر کند. اما برای جابه‌جایی به ارائه‌دهنده دیگر باید API، مدل داده و semantics عملیات را هم بررسی کنید. دو سرویس با نام مشابه ممکن است تضمین‌های متفاوتی داشته باشند. قابلیت حمل را از روی مسیرهای استفاده واقعی برنامه بسنجید؛ فقط عوض کردن import در یک فایل همه وابستگی‌ها را حذف نمی‌کند.
برای محدود کردن وابستگی، تماس با سرویس را در لایه مشخص نگه دارید و قرارداد داخلی آن را بنویسید. مثلا تابع ذخیره فایل می‌تواند نیازهای کسب‌وکار را بیان کند و جزئیات SDK در implementation بماند. این جداسازی تضمین انتقال بدون هزینه نیست، ولی محل تغییر را آشکارتر می‌کند. خواندن کد عمومی SDK زمانی مفید است که نیاز مشخصی را دنبال کنید.
GitHub میزبان مشارکت است
GitHub امکاناتی برای issue، Pull Request و توزیع کد دارد. مخزن عمومی می‌تواند روی این سرویس قرار بگیرد، اما شرایط سرویس با مجوز هر مخزن فرق دارد. Terms of Service در GitHub به استفاده از پلتفرم مربوط است. مجوز یک پروژه را از همان مخزن بخوانید؛ عمومی بودن repository به معنی نبودن شرط استفاده نیست.
برای تیم، نگهداری دسترسی سازمانی و استمرار کار مهم است. مالکیت مخزن، دسترسی انتشار package و تنظیمات pipeline نباید فقط به حساب یک فرد وابسته باشد. عمومی بودن کد به تنهایی بازیابی دسترسی را حل نمی‌کند. ثبت مسئولیت انتشار و بازبینی مجوزها کمک می‌کند با خروج یک عضو، نگهداری پروژه متوقف نشود.
مشارکت را از PR کوچک شروع کنید
در یک پروژه بزرگ، قبل از تغییر کد CONTRIBUTING را بخوانید. ممکن است توافق مشارکت، قواعد style یا فرایند بررسی خاصی لازم باشد. پیشنهاد ویژگی باید با هدف پروژه هماهنگ شود؛ باز کردن یک PR بزرگ بدون گفت‌وگو درباره مسئله می‌تواند وقت دو طرف را هدر دهد. اصلاح مستند یا نمونه کوچک هم مشارکت است، اگر مشکلی واقعی را حل کند.
برای نمونه، اگر متن مستند درباره optionی مبهم است، ابتدا نسخه مربوط را بررسی و جمله دقیق مشکل را مشخص کنید. تغییر پیشنهادی باید برای خواننده‌ای که گفت‌وگوی شما را ندیده روشن باشد. ادعای تازه یا رفتار آزمایش‌نشده را وارد مستند نکنید. اگر ابهام به محدودیت محصول مربوط است، فقط بازنویسی جمله کافی نیست و باید با نگهدارنده درباره معنای درست هماهنگ شود.
زمان نگهدارنده محدود است. issue مناسب زمینه لازم را دارد و از او نمی‌خواهد کل پروژه شما را بررسی کند. پاسخ دیرهنگام نیز لزوماً بی‌اهمیت بودن مسئله را نشان نمی‌دهد. برای نیاز فوری کسب‌وکار، برنامه جایگزین یا پشتیبانی مناسب لازم است؛ پروژه عمومی تعهد زمانی خودکار ایجاد نمی‌کند. این نگاه به مشارکت، انتظار دو طرف را عملی‌تر نگه می‌دارد.
برداشت درباره انگیزه را با واقعیت مخزن مخلوط نکنید
پروژه عمومی می‌تواند هم به مصرف‌کننده کمک کند و هم با خدمات تجاری شرکت ارتباط داشته باشد. توضیح انگیزه اقتصادی بدون سند باید به‌عنوان تحلیل مطرح شود، نه واقعیت قطعی درباره نیت سازمان. برای تصمیم استفاده، شواهد قابل بررسی مانند مجوز، activity نگهداری، پاسخ به issue و سیاست نسخه از جمله‌های کلی درباره آینده صنعت مفیدترند.
یک سازمان می‌تواند از ابزار متن‌باز استفاده کند و هم‌زمان بعضی خدمات اختصاصی داشته باشد. این ترکیب را با یک برچسب کلی قضاوت نکنید. بپرسید برای همین پروژه چه چیزی در دسترس شماست، چه چیزی وابسته به سرویس است و چه قراردادی برای تداوم دارید. جواب ممکن است برای editor، compiler و دیتابیس متفاوت باشد.
گام بعدی، تهیه فهرست وابستگی‌های واقعی تیم و ثبت مجوز، نسخه و مسئول نگهداری آن‌هاست. برای انتشار قابل تکرار، مقاله CI/CD برای فرانت‌اند و برای بررسی تصمیم زیرساختی، مقایسه خدمات ابری ادامه مرتبط‌اند. این فهرست باید مبنای انتخاب باشد، نه عددهای بی‌منبع درباره رتبه جهانی شرکت‌ها.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!