منبع باز از چند پروژه شفاف پیشگام به ستون فقرات توسعه مدرن در سراسر صنعت تبدیل شده است. در نتیجه، اکنون بسیاری از پروژه‌ها از اصطلاح «منبع باز» برای انتقال یک برداشت مثبت استفاده می‌کنند. با این حال، با طیف گسترده ای از شیوه های توسعه و مجوزهای منبع باز، معنای “منبع باز” می تواند به طور قابل توجهی متفاوت باشد. در این مقاله، هدف من این است که ارزش واقعی باز بودن را بررسی کنم و تشخیص دهم که چه چیزی واقعاً باز است و چه چیزی نیست. علاوه بر این، سطوح مختلف باز بودن پروژه‌ها را مورد بحث قرار می‌دهم و به شما کمک می‌کند تا در چشم‌انداز متنوع پروژه‌های منبع باز به طور موثرتر حرکت کنید.
ارزش منبع باز
ارزش منبع باز به روش های مختلفی آشکار می شود. یکی از مزیت‌های مهم شفافیت است که به شما امکان می‌دهد کدی را که اجرا می‌کنید درک کنید، مخصوصاً هنگام پردازش داده‌ها و اطلاعات حساس. کد منبع باز همچنین شما را قادر می سازد تا نرم افزاری را که در کسب و کار یا پروژه خود استفاده می کنید، تعمیر یا ارتقا دهید.
با این حال، برای پروژه‌هایی که می‌خواهند به استانداردهای پایه‌ای برای دیگران تبدیل شوند، کاربران به دنبال چیزی بیش از شفافیت هستند – آنها به دنبال اطمینان هستند. این شامل اطمینان از این است که پروژه دچار تغییرات ناگهانی نمی شود که می تواند همه چیز ساخته شده در بالای آن را مختل کند و اینکه برای آینده قابل پیش بینی به طور فعال توسعه و نگهداری خواهد شد. در این زمینه، رویکرد به منبع باز بسیار مهم می شود.
در آپاچی ما اعتماد داریم
این نوع اطمینان است که بر نقش حیاتی بنیاد نرم افزار آپاچی (ASF) تأکید می کند. بسیاری برای اولین بار با آپاچی از طریق پروژه پیشگام آن، چارچوب وب سرور منبع باز که امروزه در عملیات وب در همه جا وجود دارد، مواجه می شوند. ASF در ابتدا برای نگهداری مالکیت معنوی و دارایی های پروژه آپاچی ایجاد شد و از آن زمان به سنگ بنای پروژه های منبع باز در سراسر جهان تبدیل شده است. ASF استانداردهای سختگیرانه‌ای را برای مشارکت‌ها، استقلال و فعالیت‌های متنوع در پروژه‌های خود اعمال می‌کند و تضمین می‌کند که آنها می‌توانند در آزمون زمان به عنوان استانداردهایی در توسعه نرم‌افزار مقاومت کنند. بسیاری از پروژه‌های منبع باز تلاش می‌کنند تا به پروژه‌های Apache تبدیل شوند تا اعتبار جامعه لازم برای پذیرش به عنوان بلوک‌های سازنده نرم‌افزار استاندارد را به دست آورند، مانند Apache Tomcat برای برنامه‌های کاربردی وب جاوا، Apache Arrow برای نمایش داده‌های درون حافظه و Apache Parket برای قالب‌بندی فایل‌های داده. بین دیگران.
سازمان‌های دیگر، مانند بنیاد لینوکس، پروژه‌های منبع باز را میزبانی و هدایت می‌کنند و به طور مستقل دارایی‌ها را مدیریت می‌کنند و نظارت را بر عهده دارند. با این حال، آنها اغلب به استانداردهای دقیق استقلال مانند ASF پایبند نیستند. این دلیل مهمی است که چرا نام تجاری آپاچی به استاندارد طلایی برای استقلال پروژه های منبع باز تبدیل شده است. در اصل، می توان گفت: “ما به آپاچی اعتماد داریم.”
چرا استقلال مهم است؟
در واقعیت، استقلال همیشه مهم نیست. بسیاری از استانداردهای منبع باز در توسعه وب، مانند React، پروژه های آپاچی نیستند و به شدت توسط سازندگان آنها مانند متا هدایت می شوند. با این حال، چارچوب وب مانند React مسئول قابلیت همکاری برنامه های کاربردی وب نیست. در عوض، استانداردهای قدیمی مانند REST و HTTP به عنوان چسبی عمل می کنند که برنامه های کاربردی وب را در زبان های مختلف باطن، فریم ورک های فرانت اند و غیره به هم متصل می کند.
در حوزه داده، استانداردها هنوز در حال ظهور هستند. برخی از استانداردهای قابل توجه عبارتند از Apache Arrow و Apache Arrow Flight برای نمایش داده ها در حافظه و انتقال داده، و Apache Parquet برای اینکه چگونه مجموعه داده ها در سیستم فایل برای تجزیه و تحلیل باقی می مانند. همانطور که مجموعه داده ها بزرگتر می شوند، نیاز به استانداردهایی در مورد نحوه نمایش مجموعه داده های چند فایل (فرمت های جدول) و نحوه ردیابی، کنترل و کشف این مجموعه داده ها توسط ابزارهای مختلف (کاتالوگ های فراداده) وجود دارد.
در دنیای فرمت‌های جدول، سه استاندارد رقیب وجود دارد: Apache Iceberg، Apache Hudi، و Delta Lake، که دو مورد از این سه پروژه Apache هستند (و همچنین Apache XTable برای قابلیت همکاری بین این فرمت‌ها و فرمت‌های آینده وجود دارد). برای کاتالوگ ها، گزینه هایی شامل Nessie، Gravitino، Polaris و Unity Catalog هستند که همگی منبع باز هستند اما هنوز پروژه های آپاچی نیستند.
هنگامی که یک استاندارد خاص به طور قابل توجهی بر نحوه ایجاد شرکت های تجاری خود برای تعامل با اکوسیستم گسترده تر تأثیر می گذارد، فشار بیشتری برای استقلال وجود دارد. این به این دلیل است که عدم استقلال تضمین شده می تواند خطرات بالقوه ای برای شرکای اکوسیستم ایجاد کند.
مزایا و معایب وابستگی فروشنده
بسیاری از پروژه های منبع باز محبوب محبوب هستند و با فروشندگان خاصی مرتبط هستند. به عنوان مثال، چارچوب های وب مانند React و Angular به ترتیب با متا و گوگل مرتبط هستند. نرم افزارهای پایگاه داده مانند MongoDB، Elasticsearch و Redis نیز به نهادهای تجاری خاص مرتبط هستند، اما به طور گسترده مورد استفاده قرار می گیرند و به دلیل عملکردشان مورد تحسین قرار می گیرند. هنگامی که یک محرک واضح برای یک پروژه وجود دارد، می تواند مزایایی را ارائه دهد:
-
چابکی در توسعه: با جهت گیری بیشتر از بالا به پایین، ویژگی های جدید می توانند سریعتر ارائه شوند.
-
پشتیبانی مالی: پروژه هایی که برای کسب و کار یک واحد تجاری مرکزی هستند، اغلب از پشتوانه مالی قابل توجهی برای توسعه خود برخوردار می شوند.
با این حال، زمانی که پروژه زیربنایی استانداردی باشد که بسیاری از شرکت‌های تجاری باید کسب‌وکار خود را بر اساس آن ایجاد کنند و در آن سرمایه‌گذاری کنند، خطرات واضحی وجود دارد:
-
تغییرات سریع: پروژه ای که توسط یک نهاد هدایت می شود می تواند تغییرات بزرگی را به سرعت ایجاد کند، اما این تغییرات می تواند مخل باشد و چالش های مهاجرتی شدیدی را برای کاربران و مشاغل وابسته به آن ایجاد کند. به عنوان مثال، انتشار Angular 2 بازنویسی کامل چارچوب بود و کسب‌وکارهایی را که از Angular استفاده می‌کردند مجبور کرد اساساً برنامه‌های خود را بازنویسی کنند.
-
بازخورد محدود: پروژه ای که توسط یک نهاد هدایت می شود ممکن است بازخورد زیادی از مشتریان خود دریافت کند، اما ممکن است ورودی کمتری از اکوسیستم گسترده تر داشته باشد. این می‌تواند به ویژگی‌های جدیدی منجر شود که به نفع محرک اصلی است، که اگر قرار باشد پروژه پایه‌ای برای کل اکوسیستم قابلیت همکاری ابزار باشد، می‌تواند مشکل‌ساز باشد.
-
تغییرات غیرقابل پیش بینی: تغییرات ناگهانی مجوز، تصاحب شرکت‌ها، تغییرات رهبری، یا تغییرات دیگر می‌توانند به طور ناگهانی پروژه را تغییر دهند یا حتی تعطیل کنند و بسیاری را برای بازسازی بر روی یک جایگزین به تکاپو بیاندازند.
استقلال برای پروژه‌های منبع باز همه چیز نیست، اما هر چه یک پروژه فرمت استانداردی را نشان دهد که ارزش آن در اکوسیستم آن نهفته است، استقلال بیشتری باید اهمیت داشته باشد.
خطوط تار کمتر تار شدند
فراتر از تغییرات غیرمنتظره، تغییر مجوزها، و یک زمین بازی ناهموار برای اکوسیستم، روش‌های دیگری نیز وجود دارد که تحت عنوان باز بودن باید محتاط بود. یک استراتژی که برای جلوگیری از برخی تضادهای سنتی مجوز استفاده می شود، ارائه دو نسخه از یک پروژه است: یک نسخه منبع باز و یک نسخه اختصاصی که توسط یک نهاد تجاری کنترل می شود. نسخه اختصاصی اغلب ابتدا ویژگی های جدید یا انحصاری را دریافت می کند.
این عمل، به خودی خود، ذاتا بد نیست. بسیاری از کسب‌وکارها فورک‌های اختصاصی تجاری پروژه‌های منبع باز را حفظ می‌کنند، اما معمولاً نسخه تجاری نامی متفاوت از پروژه منبع باز دارد. به عنوان مثال، در دنیای کاتالوگ های داده، Dremio توسعه دهنده اصلی Nessie است و Snowflake Polaris را هدایت می کند. هدف هر دو تبدیل شدن به پروژه های جامعه محور در طول زمان است، اما همچنین ویژگی های یکپارچه را در محصولات تجاری مربوطه خود تحت نام های مختلف ایجاد می کنند. به عنوان مثال، اگر کاتالوگ Nessie خود را تنظیم کنید، در مقایسه با کاتالوگ سازمانی Dremio (قبلاً قطب شمال) که در Dremio Cloud ادغام شده است، نامی متمایز دارد. کاتالوگ Dremio Enterprise توسط Nessie ارائه می‌شود، اما دارای ویژگی‌های اضافی است، بنابراین نام‌های مختلف از سردرگمی در مورد ویژگی‌های موجود یا اینکه کدام مستندات باید ارجاع داده شود، جلوگیری می‌کند.
در مقابل، Databricks از چنگال‌های داخلی Spark، Delta Lake و Unity Catalog استفاده می‌کند و از نام‌های یکسانی برای نسخه‌های منبع باز و ویژگی‌های خاص پلتفرم Databricks استفاده می‌کند. در حالی که آنها اسناد جداگانه ای را ارائه می دهند، بحث های آنلاین اغلب منعکس کننده سردرگمی در مورد نحوه استفاده از ویژگی ها در نسخه های منبع باز است که فقط در پلت فرم Databricks وجود دارد. این باعث ایجاد “گل آلود شدن آب” بین آنچه که باز است و آنچه که اختصاصی است ایجاد می کند. اگر کاربر Databricks هستید، این مشکلی نیست، اما برای کسانی که می خواهند از این ابزارها خارج از اکوسیستم Databricks استفاده کنند، می تواند کاملاً گیج کننده باشد.
بسته به معنای بد نیست
برای روشن‌تر شدن، این واقعیت که یک پروژه از بالاترین استانداردهای باز بودن پیروی نمی‌کند یا حتی اختصاصی است، از کیفیت کد پروژه، مهارت‌های توسعه‌دهندگان یا ارزشی که می‌تواند به کاربران خود ارائه کند، نمی‌کاهد. با این حال، باز بودن می‌تواند به عنوان سیگنالی از اطمینان عمل کند و اکوسیستم‌هایی را برای استانداردهایی تقویت کند که از اثر شبکه رو به رشد سود می‌برند. بازیگران مستقل در این اکوسیستم‌ها احساس راحتی بیشتری می‌کنند که بر اساس چنین پروژه‌هایی ساخته می‌شوند، که به ویژه برای استانداردهایی که بر نحوه ارتباط سیستم‌ها با یکدیگر تأثیر می‌گذارند، مهم است.
