خطرات در حال ظهور منبع باز

اقتصاد منبع باز امروز: پروژه های سرگرم کننده، صنعتگران کد مستقل و خدمات مدیریت شده بازار نرم افزار را تغییر داده اند.

به یاد داشته باشید زمانی که منبع باز همه چیز درباره بود صلح، عشق و لینوکس؟ زمانی که جنبش کوچک اما پرشور بود و بر سر GPL در مقابل BSD/Apache، نرم افزار رایگان در مقابل منبع باز مبارزه می کرد؟ وقتی دیدن لینوکس یا سایر نرم‌افزارهای منبع باز در حال اجرا در طبیعت کار بزرگی بود، ارزش یک وبلاگ یا توییتر؟ ممکن است برخی از آن روزهای خوب گذشته خوششان بیاید، اما دنیا پیش رفته است. منبع باز برای نحوه ساخت همه نرم افزارها ضروری شده است، که با فرصت ها و ریسک های بزرگ همراه است.

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

متن باز تغییر کرده است

در اوایل ما از یک هکر تنها مانند لینوس توروالدز تجلیل کردیم که پروژه بزرگی مانند لینوکس را ایجاد کرد و سپس جامعه ای را در اطراف آن ایجاد کرد. نمونه‌های دیگر عبارتند از Dries Buytaert (دروپال)، Salvatore Sanfilippo (Redis)، و موارد دیگر. آن روزهایی بود که هکرها پروژه‌های منبع باز را برای سرگرمی یا به عنوان یک «خروجی خلاقانه» مانند Jens Axboe (Fio) یا دیگران ساختند. البته این هنوز هم اتفاق می افتد، اما در میان یک بازار متن باز بسیار متفاوت اتفاق می افتد.

همانطور که Mugrage برجسته می‌کند، منبع باز اولیه اغلب سعی می‌کرد تا یک جایگزین منبع باز برای یک بسته نرم‌افزاری اختصاصی بزرگ ایجاد کند (به جای Adobe Photoshop، OpenOffice را به عنوان جایگزینی برای Microsoft Office یا GIMP در نظر بگیرید). با این حال، “امروزه گسترش نرم افزار منبع باز وجود دارد.” این گسترش حداقل دو شکل اصلی دارد: «از یک طرف، ما غول‌های اینترنتی را داریم که انواع ابزارها، چارچوب‌ها و پلتفرم‌ها را تولید می‌کنند. از طرف دیگر، تیم‌هایی با استفاده از OneDev، یک پلتفرم توسعه نرم‌افزار منبع باز، بخش‌های کوچک اما حیاتی را ایجاد کرده‌اند که تعداد زیادی از کسب‌وکارها را پشتیبانی می‌کند.

این عالی است، درست است؟ ما هم پروژه های بزرگ و هم پروژه های کوچکی داریم که نوآوری های عظیم را تقویت می کنند. چه چیزی را دوست ندارید؟

فقدان مشارکت کنندگان متنوع، برای یک چیز، که ریسک را متمرکز می کند. درست است، همیشه همینطور بوده است< /a> که نرم افزار منبع باز (بدون توجه به پروژه) توسط تعداد کمی از مشارکت کنندگان توسعه یافته است. اگرچه ما دوست داریم منبع باز را اسطوره‌سازی کنیم که در مورد جوامع بزرگ و جهانی است، اما بسیار رایج‌تر است که کار یک یا دو نفر باشد. هنگامی که انجمن می آید، معمولاً پس از سال ها موفقیت و هزینه های شخصی بسیار زیاد است، همانطور که یک بار مت کلاین، خالق و نگهدارنده فرستاده برای من تعریف کرد. (متن باز یک «کار زیاد است.»)

بنابراین این بخشی از پازل است. Mugrage به نکته دیگری استدلال می کند که اغلب “پایه های کد برای بسته های منبع باز به سادگی بیش از حد بزرگ هستند که امکان بازرسی معنی دار را فراهم نمی کنند.” پسر عموی این مشکل پروژه های BigCo این است که “بسته های دیگر توسط غول های اینترنتی توزیع می شوند که انتظار ندارند هیچ کس دیگری در آنها مشارکت داشته باشد.” کد “تک رشته ای” برای یک موجودیت بزرگ بدون توانایی یک جامعه برای تاثیرگذاری بر توسعه است.

از سوی دیگر، «نسخه‌های دیگر، نسخه‌های هدفمند و متمایز هستند که ممکن است فقط یک کار نسبتاً جزئی را انجام دهند، اما آن را به قدری خوب انجام می‌دهند که در سراسر اینترنت پخش شده‌اند». ببینید به کجا میرسد؟ “با این حال، به جای یک جامعه فعال از نگهبانان، آنها اغلب فقط یک یا دو توسعه دهنده متعهد هستند که روی یک پروژه پرشور کار می کنند.”

پاسخ به مشکل منبع باز BigCo تمایل به “خشم علیه ماشین منبع باز شرکتی” است، که تا حد زیادی بیهوده ثابت شده است. یکی از پاسخ‌ها به چنین پروژه‌هایی، ظهور استارت‌آپ‌ها برای حمایت بیشتر (و کسب درآمد) از پروژه بوده است، که یکی از جنبه‌های بزرگ‌نمایی منبع باز را با مشکل دیگری برطرف می‌کند. پاسخ به توسعه‌دهندگان مستقل که زیرساخت‌های منبع باز ضروری اما پشتیبانی‌نشده را ایجاد می‌کنند، درخواست با صدای بلند از BigCos برای حمایت از این صنعت‌گران کد مستقل بوده است.

این پیشنهاد معمولاً توسط کسانی ارائه می‌شود که به سادگی چیز بهتری نمی‌دانند. از افرادی که برای بنیادها یا سایر سازمان‌هایی که برای تأمین مالی توسعه منبع باز طراحی شده‌اند، بپرسید، و آن‌ها همان چیزی را که Mugrage می‌گوید تکرار می‌کنند: «پرتاب پول برای مشکل راه‌حلی نیست». چرا؟ زیرا “بسیاری از علاقه مندان منبع باز که نرم افزار خود را شخصا نگهداری می کنند در حالی که زندگی حرفه ای پرمشغله ای دارند … [نمی خواهند] مسئولیت یک توافقنامه در سطح خدمات را بر عهده بگیرند زیرا شخصی برای ایجاد آنها به آنها پول پرداخت کرده است.”

چه باید کرد؟

هدینگ شرط‌های منبع باز

بسیاری از شرکت‌ها به دنبال آسان‌تر کردن زندگی منبع باز خود با خرید سرویس‌های مدیریت‌شده هستند. این یک راه حل کوتاه مدت عالی است، اما مشکل بلندمدت پایداری را حل نمی کند. نه، ابر مقیاس‌کننده‌های ابری استخراج‌کننده‌های استریپ نیستند، و به طرزی شرم‌آور کد توسعه‌دهندگان ناآگاه را شکار می‌کنند. اما اغلب برخی تیم‌ها در برنامه‌ریزی برای کمک به پروژه‌هایی که به آنها وابسته هستند، ناکام می‌مانند. من به برخی تاکید می کنم، زیرا این موضوع در کل شرکت نیست، صرف نظر از فروشنده. من این را به تفصیل شرح داده‌ام قبلاً. صرف نظر از این، شرکت‌هایی که این خدمات مدیریت شده را ارائه می‌دهند، تمایلی به کنترل نقشه راه پروژه‌ها ندارند. این برای شرکت هایی که می خواهند ریسک را کنترل کنند عالی نیست. گوگل یک استثنای قابل توجه است – تمایل زیادی به مشارکت در پروژه های کلیدی دارد.

آنها لزوماً نمی توانند مستقیماً به پروژه ها کمک کنند. همانطور که Mugrage نشان می دهد، برای شرکت هایی مانند نتفلیکس یا فیس بوک (Meta) که پروژه های بزرگ منبع باز دارند، این “نسخه های منبع باز تقریباً به برندسازی کارفرما بستگی دارد – راهی برای نشان دادن مهارت های مهندسی خود به کارمندان بالقوه” که به معنای “شما” است. احتمالاً تأثیر بسیار کمی بر تحولات آینده خواهد داشت.» آنها واقعاً به مشارکت شما نیاز ندارند.

در مورد پروژه هایی که توسط علاقه مندان نگهداری می شود چطور؟ هنگامی که شروع به بررسی بخش‌های مهم پشته نرم‌افزار خود می‌کنید که در آن به علاقه‌مندان متکی هستید، انتخاب‌های شما شروع به کاهش می‌کند.» چرا؟ از آنجایی که بعید است زمان یا منابعی برای ارائه کد داشته باشید، آنها ممکن است پول نقد شما را نخواهند، و پروژه های مهمی (مانند Log4J) وجود دارد که بدون توجه به آنها باید به پروژه های آنها تکیه کنید. در این مورد، Mugrage پیشنهاد می کند، فقط آگاهی از خطر از طریق ممیزی نرم افزاری که به آن وابسته هستید می تواند مفید باشد.

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