همه ما هر روز از نرمافزار متنباز (OSS) استفاده میکنیم، از سیستمعامل اندروید گوشیهایمان گرفته تا وبسایتهایی که بازدید میکنیم و ابزارهایی که توسعهدهندگان برای ساختن دنیای دیجیتال به کار میگیرند. این یک فرض رایج و درست است. اما چقدر از واقعیتهای پنهان و پیچیدگیهای دنیای متنباز آگاه هستیم؟
این مقاله بر اساس دادهها و تحلیلهای اخیر، شش حقیقت غافلگیرکننده، تأثیرگذار و گاهی خلاف تصور رایج را آشکار میکند که نگاه شما را به کدی که هر روز استفاده میکنید، برای همیشه تغییر خواهد داد.
——————————————————————————–
۱. شما بسیار بیشتر از آنچه فکر میکنید از نرمافزار متنباز استفاده میکنید—و بخش عمده آن نامرئی است.
آمارها شگفتانگیزند. بر اساس گزارش تحلیل امنیت و ریسک نرمافزار متنباز (OSSRA)، ۹۷٪ از پایگاههای کد (codebases) حاوی نرمافزار متنباز هستند و هر اپلیکیشن بهطور متوسط از ۹۱۱ مؤلفه (component) متنباز مجزا تشکیل شده است. برای درک بهتر این رشد انفجاری، کافی است بدانید که تعداد فایلهای متنباز در یک اپلیکیشن متوسط، تنها در چهار سال گذشته سه برابر شده است.
اما نکته غافلگیرکنندهتر، مفهوم «وابستگیهای انتقالی» (transitive dependencies) است. اینها کتابخانههایی هستند که کتابخانههایی که شما مستقیماً استفاده میکنید، به آنها نیاز دارند. طبق گزارش، ۶۴٪ از کل مؤلفههای متنباز در یک پروژه، همین وابستگیهای انتقالی و پنهان هستند. این یعنی بخش عمدهای از کد شما، کدی است که شما مستقیماً انتخاب نکردهاید و ردیابی آن بدون ابزارهای خودکار تقریباً غیرممکن است.
این «عمق پنهان» یک ریسک جدی است. هر وابستگی نامرئی میتواند حامل آسیبپذیریهای امنیتی یا مجوزهای حقوقی متناقضی باشد که مدیریت امنیت و انطباق قانونی را به یک کابوس تبدیل میکند. همانطور که در گزارش OSSRA به نقل از سرمایهگذاران افسانهای آمده است:
“ریسک ناشی از ندانستن کاری است که انجام میدهید.” —وارن بافت و چارلز مانگر
——————————————————————————–
۲. بخش بزرگی از کدی که استفاده میکنید، به طرز خطرناکی قدیمی است.
اگر فکر میکنید نرمافزار متنبازی که استفاده میکنید بهروز و مدرن است، گزارش OSSRA شما را شگفتزده خواهد کرد. طبق دادههای این گزارش، ۹۰٪ از پایگاههای کد حاوی مؤلفههای متنبازی هستند که بیش از چهار سال از تاریخ انتشارشان گذشته است.
این آمار حتی نگرانکنندهتر هم میشود: ۹۱٪ از مؤلفهها در آخرین نسخه خود نیستند. علاوه بر این، ۹۰٪ از پایگاههای کد حاوی مؤلفههایی هستند که بیش از ۱۰ نسخه از جدیدترین نسخه خود عقب ماندهاند. این موضوع یک مشکل جدی است، زیرا مؤلفههای قدیمی نه تنها از بهبودهای عملکردی و ویژگیهای جدید بیبهرهاند، بلکه مهمتر از آن، وصلههای امنیتی حیاتی را دریافت نمیکنند و اغلب دیگر توسط جامعه توسعهدهندگان پشتیبانی نمیشوند. برخلاف نرمافزارهای تجاری که بهروزرسانیها به کاربر اطلاعرسانی میشود، در دنیای متنباز، مسئولیت پیگیری و نصب بهروزرسانیها کاملاً بر عهده شماست.
——————————————————————————–
۳. «نرمافزار آزاد» به معنای رایگان بودن نیست؛ بلکه نمایانگر دو فلسفه متفاوت (و گاهی متضاد) درباره «آزادی» است.
یکی از بزرگترین تصورات غلط این است که نرمافزار متنباز همیشه رایگان (بدون هزینه) است. در حالی که بسیاری از پروژهها رایگان هستند، شرکتهای بزرگی مانند Red Hat با فروش خدمات حرفهای و پشتیبانی به سودآوری رسیدهاند. مدلهای دیگری مانند «اوپنکور» (open-core) نیز وجود دارند که در آن، هسته اصلی نرمافزار متنباز است، اما ویژگیهای پیشرفتهتر به صورت تجاری فروخته میشود.
اما تفاوت عمیقتر، فلسفی است. دو مجوز محبوب MIT و GPL، دو دیدگاه متفاوت درباره معنای «آزادی» را نمایندگی میکنند:
- مجوز MIT (آزادی برای توسعهدهنده بعدی): این مجوز بسیار سهلگیرانه است و به توسعهدهندهای که از کد شما استفاده میکند، آزادی کامل میدهد. او میتواند کد شما را بگیرد، آن را تغییر دهد و در یک محصول تجاری و کاملاً اختصاصی (closed-source) استفاده کند، بدون اینکه مجبور باشد کد خود را منتشر کند.
- مجوز GPL (آزادی برای کاربر نهایی): این مجوز که به آن «کپیلفت» (copyleft) میگویند، آزادی را برای کاربر نهایی تضمین میکند. طبق این مجوز، هر کسی که از کد شما استفاده کرده و آن را تغییر دهد، موظف است نسخه تغییریافته را نیز تحت مجوز GPL منتشر کند. این کار اطمینان میدهد که نرمافزار برای همیشه آزاد و متنباز باقی میماند.
بنابراین، انتخاب بین این دو یک تصمیم فنی نیست، بلکه یک تصمیم فلسفی است: «آزادی برای چه کسی» اولویت دارد؟ آزادی بیقید و شرط برای توسعهدهندگان بعدی یا تضمین آزادی ابدی برای کاربران نهایی؟
——————————————————————————–
۴. بزرگترین تهدید امنیتی شما ممکن است یک کتابخانه قدیمی و فراموششده باشد.
گزارش OSSRA نشان میدهد که ۸ مورد از ۱۰ آسیبپذیری پرخطر برتر در کتابخانه محبوب jQuery یافت شدهاند. آیا این یعنی jQuery ناامن است؟ خیر. مشکل، استفاده گسترده از نسخههای قدیمی و وصلهنشده آن است. این کتابخانه به نمادی از یک ریسک بزرگتر تبدیل شده است: «کد قدیمی» (legacy code) که در گوشهای از پروژه شما پنهان شده و فراموش شده است.
داستان عبرتآموز نشت اطلاعات Equifax در سال ۲۰۱۷، این خطر را به بهترین شکل نشان میدهد. هکرها با سوءاستفاده از یک آسیبپذیری شناختهشده در مؤلفه متنباز Apache Struts، به اطلاعات شخصی ۱۴۷ میلیون نفر دسترسی پیدا کردند. مشکل اصلی این نبود که وصله امنیتی برای این آسیبپذیری وجود نداشت؛ مشکل این بود که Equifax حتی نمیدانست که یکی از اپلیکیشنهای قدیمیاش از این مؤلفه استفاده میکند. عدم آگاهی، در را برای یکی از بزرگترین نشتهای اطلاعاتی تاریخ باز گذاشت.
گزارش کنگره آمریکا درباره این حادثه، اهمیت این موضوع را به وضوح بیان میکند:
“برای یک سازمان حیاتی است که بداند چه داراییهایی در محیطهای فناوری اطلاعات خود وجود دارد تا بتواند تصمیمات دقیق و آگاهانهای در مورد ریسک بگیرد—مانند اینکه چه زمانی و چگونه یک سیستم آسیبپذیر را وصله کند.”
——————————————————————————–
۵. تضاد مجوزها یک بمب ساعتی حقوقی پنهان است.
ممکن است فکر کنید مدیریت مجوزهای متنباز ساده است، اما آمارها چیز دیگری میگویند. گزارش OSSRA نشان داد که ۵۶٪ از پایگاههای کد مورد بررسی، دارای تضاد مجوز (license conflicts) بودند.
این تضادها زمانی رخ میدهند که دو یا چند مؤلفه با مجوزهای ناسازگار در یک پروژه استفاده شوند. مقصر اصلی؟ دوباره همان «وابستگیهای انتقالی». نزدیک به ۳۰٪ از این تضادها ناشی از وابستگیهای پنهانی است که شما از وجودشان بیخبرید.
برای مثال، فرض کنید پروژه شما تحت یک مجوز سهلگیرانه مانند MIT است. اما یکی از کتابخانههایی که استفاده میکنید، به یک کتابخانه دیگر با مجوز سختگیرانه GPL وابسته است. ورود ناخواسته این مؤلفه GPL به پروژه شما میتواند از نظر قانونی شما را ملزم کند که کل محصول خود را به صورت متنباز منتشر کنید. این یک بمب ساعتی حقوقی است که میتواند مالکیت معنوی شما را به خطر بیندازد.
همانطور که اریک آلمن، یکی از پیشگامان نرمافزار، به درستی گفته است:
“برنامهنویس بودن مستلزم آن است که به همان اندازه که از فناوری سر در میآورید، از قانون نیز سر در بیاورید.”
——————————————————————————–
۶. مشارکت در پروژههای متنباز فقط برای اصلاح باگ نیست؛ یک استراتژی قدرتمند شغلی است.
چرا یک توسعهدهنده باید وقت خود را صرف مشارکت داوطلبانه در یک پروژه متنباز کند؟ انگیزهها بسیار فراتر از نوعدوستی و رفع باگهاست. در واقع، این یک سرمایهگذاری هوشمندانه بر روی آینده شغلی است. دلایل اصلی عبارتند از:
- بهبود مهارتهای کدنویسی: هیچ چیز مانند کار روی پروژههای واقعی و دریافت بازخورد از برنامهنویسان باتجربه، مهارتهای شما را تقویت نمیکند.
- کسب تجربه اولیه: برای توسعهدهندگان تازهکار، ساختن یک رزومه عملی بسیار دشوار است. مشارکت در پروژههای متنباز به آنها اجازه میدهد یک نمونه کار واقعی بسازند. امروزه بسیاری از کارفرمایان، حساب GitHub یک متقاضی را با دقت بیشتری نسبت به CV او بررسی میکنند.
- افزایش شهرت در جامعه: شناخته شدن در جامعه متنباز میتواند درهای جدیدی را باز کند. این شهرت میتواند منجر به پیشنهادات شغلی، پروژههای مشاورهای یا حتی دعوت برای سخنرانی در کنفرانسهای بینالمللی شود.
- بهبود نرمافزاری که خودشان استفاده میکنند: بسیاری از مشارکتها از یک نیاز شخصی یا تجاری شروع میشود. اگر نرمافزاری که استفاده میکنید یک ویژگی کم دارد، میتوانید خودتان آن را اضافه کنید—یک موقعیت برد-برد هم برای شما و هم برای جامعه.
مشارکت در دنیای متنباز، یک عمل صرفاً خیرخواهانه نیست، بلکه یک استراتژی حسابشده برای رشد حرفهای، شبکهسازی و ایجاد فرصتهای جدید است.
——————————————————————————–
نتیجهگیری: یک پرسش برای آینده
دنیای نرمافزار متنباز بسیار پیچیدهتر از آن چیزی است که در نگاه اول به نظر میرسد. از وابستگیهای پنهانی که ریسکهای امنیتی و حقوقی ایجاد میکنند گرفته تا فلسفههای متفاوتی که پشت مجوزها پنهان شده و انگیزههای قدرتمند شغلی که توسعهدهندگان را به مشارکت وا میدارد. آگاهی از این حقایق دیگر یک انتخاب نیست، بلکه یک ضرورت برای هر کسی است که با نرمافزار سر و کار دارد.
با آگاهی از این واقعیتهای پنهان، قدم بعدی شما برای مدیریت هوشمندانهتر نرمافزارهای متنباز در پروژههایتان چه خواهد بود؟
