جشنواره فناوری اطلاعات این هفته در سن پترزبورگ برگزار می شود . یکی از سخنرانان ریچارد استالمن خواهد بود. در جشنواره نیز شرکت می کند و البته نمی توانستیم موضوع نرم افزار آزاد را نادیده بگیریم. به همین دلیل یکی از گزارش های ما نامیده می شود . این به تاریخچه توسعه Embox به عنوان یک پروژه منبع باز اختصاص داده خواهد شد. در این مقاله می خواهم در مورد ایده های اصلی صحبت کنم که به نظر من بر توسعه پروژه های منبع باز تأثیر می گذارد. مقاله، مانند گزارش، بر اساس تجربه شخصی است.
بیایید با چیزی ساده شروع کنیم، با تعریف واژه منبع باز. بدیهی است که پروژه منبع باز پروژه ای است که دارای یکی از مجوزهایی است که امکان دسترسی به کد منبع پروژه را فراهم می کند. علاوه بر این، یک پروژه باز به این معنی است که توسعه دهندگان شخص ثالث می توانند تغییراتی ایجاد کنند. یعنی اگر یک شرکت یا توسعه دهنده کد محصول خود را به طور جزئی یا کامل منتشر کند، این هنوز این محصول را به یک پروژه متن باز تبدیل نمی کند. و در نهایت، هر گونه فعالیت پروژه باید به نوعی نتیجه منجر شود و باز بودن پروژه حاکی از آن است که این نتیجه نه تنها توسط خود توسعه دهندگان استفاده می شود.
ما به مشکلات مجوزهای باز دست نخواهیم داد. این موضوع بسیار بزرگ و پیچیده است که نیاز به بررسی عمیق دارد. مقالات و مطالب بسیار خوبی در این زمینه نوشته شده است. اما از آنجایی که من خودم در زمینه کپی رایت متخصص نیستم، فقط می گویم که مجوز باید اهداف پروژه را برآورده کند. برای مثال، برای Embox انتخاب یک BSD به جای مجوز GPL تصادفی نبود.
این واقعیت که یک پروژه منبع باز باید توانایی ایجاد تغییرات و تأثیرگذاری بر توسعه پروژه منبع باز را فراهم کند، به این معنی است که پروژه توزیع شده است. مدیریت آن، حفظ یکپارچگی و عملکرد در مقایسه با یک پروژه با مدیریت متمرکز بسیار دشوارتر است. یک سوال منطقی مطرح می شود: اصلا چرا پروژه ها باز می شوند؟ پاسخ در زمینه امکان سنجی تجاری نهفته است؛ برای دسته خاصی از پروژه ها، مزایای این رویکرد بیشتر از هزینه ها است. یعنی برای همه پروژه ها مناسب نیست و رویکرد باز عموما قابل قبول است. به عنوان مثال، تصور توسعه یک سیستم کنترل برای یک نیروگاه یا یک هواپیما بر اساس یک اصل باز دشوار است. خیر، البته، چنین سیستم‌هایی باید شامل ماژول‌هایی بر اساس پروژه‌های باز باشند، زیرا این مزیت‌ها را به همراه خواهد داشت. اما یک نفر باید مسئول محصول نهایی باشد. حتی اگر سیستم کاملاً مبتنی بر کد پروژه‌های باز باشد، توسعه‌دهنده با بسته‌بندی همه چیز در یک سیستم و انجام ساخت‌ها و تنظیمات خاص، اساساً آن را می‌بندد. این کد ممکن است برای عموم در دسترس باشد.
همچنین مزایای زیادی برای این سیستم ها از ایجاد یا مشارکت در پروژه های منبع باز وجود دارد. همانطور که قبلاً گفتم، کد سیستم نهایی ممکن است در دسترس عموم باقی بماند. چرا، زیرا بدیهی است که بعید است کسی همان هواپیما را برای آزمایش سیستم داشته باشد. این درست است، اما ممکن است کسی باشد که بخواهد بخش‌های خاصی از کد را بررسی کند، یا برای مثال، ممکن است کسی متوجه شود که کتابخانه مورد استفاده به درستی پیکربندی نشده است.
اگر شرکت قسمتی از سیستم را به یک پروژه جداگانه اختصاص دهد، مزیت بزرگتری به نظر می رسد. به عنوان مثال، یک کتابخانه برای پشتیبانی از نوعی پروتکل تبادل داده. در این حالت، حتی اگر پروتکل مختص یک حوزه موضوعی خاص باشد، می‌توانید هزینه‌های نگهداری این قطعه از سیستم را با سایر شرکت‌های این حوزه به اشتراک بگذارید. علاوه بر این، متخصصانی که می توانند این قطعه از سیستم را در حوزه عمومی مطالعه کنند، به زمان بسیار کمتری برای استفاده موثر از آن نیاز دارند. و در نهایت، جدا کردن یک قطعه به یک موجودیت مستقل که توسعه‌دهندگان شخص ثالث از آن استفاده می‌کنند به ما این امکان را می‌دهد که این بخش را بهتر کنیم، زیرا ما نیاز به ارائه APIهای مؤثر، ایجاد مستندات داریم، و من حتی در مورد بهبود پوشش آزمایشی صحبت نمی‌کنم.
یک شرکت می تواند بدون ایجاد پروژه های منبع باز از مزایای تجاری برخوردار شود؛ کافی است متخصصان آن در پروژه های شخص ثالث مورد استفاده در شرکت شرکت کنند. از این گذشته ، همه مزایا باقی می مانند: کارمندان پروژه را بهتر می شناسند ، بنابراین از آن به طور مؤثرتری استفاده می کنند ، شرکت می تواند در جهت توسعه پروژه تأثیر بگذارد و استفاده از کدهای آماده و اشکال زدایی بدیهی است که هزینه های شرکت را کاهش می دهد.
مزایای ایجاد پروژه های منبع باز به همین جا ختم نمی شود. بیایید یکی از مؤلفه های مهم تجارت را مانند بازاریابی در نظر بگیریم. برای او، این ماسه‌بازی بسیار خوبی است که به او اجازه می‌دهد تا نیازهای بازار را به طور مؤثر ارزیابی کند.
و البته، ما نباید فراموش کنیم که یک پروژه منبع باز روشی موثر برای معرفی خود به عنوان حامل هر تخصص است. در برخی موارد این تنها راه ورود به بازار است. به عنوان مثال، Embox به عنوان پروژه ای برای ایجاد یک RTOS آغاز شد. احتمالاً نیازی به توضیح نیست که رقبای زیادی وجود دارد. بدون ایجاد یک انجمن، ما به سادگی منابع کافی برای ارائه پروژه به کاربر نهایی نداشتیم، یعنی توسعه دهندگان شخص ثالث شروع به استفاده از پروژه کنند.
جامعه در یک پروژه منبع باز کلیدی است. این به شما امکان می دهد تا به طور قابل توجهی هزینه های مدیریت پروژه را کاهش دهید، پروژه را توسعه و پشتیبانی کنید. می توان گفت که بدون جامعه هیچ پروژه منبع باز وجود ندارد.
مطالب زیادی در مورد نحوه ایجاد و مدیریت یک جامعه پروژه منبع باز نوشته شده است. برای اینکه حقایق شناخته شده را بازگو نکنم، سعی می کنم روی تجربه Embox تمرکز کنم. به عنوان مثال، روند ایجاد یک جامعه موضوع بسیار جالبی است. یعنی خیلی ها می گویند چگونه یک جامعه موجود را مدیریت کنیم، اما لحظات ایجاد آن گاهی نادیده گرفته می شود، با توجه به اینکه این یک امر مسلم است.
قانون اصلی هنگام ایجاد یک جامعه پروژه منبع باز این است که هیچ قانونی وجود ندارد. منظورم این است که قوانین جهانی وجود ندارد، درست مانند هیچ گلوله نقره ای، اگر فقط به این دلیل که پروژه ها بسیار متفاوت هستند. بعید است که بتوانید هنگام ایجاد یک انجمن برای کتابخانه js logging و برخی درایورهای بسیار تخصصی از قوانین مشابه استفاده کنید. علاوه بر این، در مراحل مختلف توسعه پروژه (و بنابراین جامعه)، قوانین تغییر می کنند.
Embox به عنوان یک پروژه دانشجویی شروع شد زیرا به دانشجویان بخش برنامه نویسی سیستم دسترسی داشت. در واقع، ما وارد جامعه دیگری می شدیم. ما می‌توانیم شرکت‌کنندگان این انجمن، دانش‌آموزان را به فعالیت‌های صنعتی خوب در تخصص خود، کار علمی در زمینه برنامه‌نویسی سیستم، دوره‌های آموزشی و دیپلم علاقه مند کنیم. یعنی ما یکی از قوانین اساسی سازماندهی یک جامعه را دنبال کردیم: اعضای جامعه باید چیزی دریافت کنند و این قیمت باید با سهم مشارکت کننده مطابقت داشته باشد.
مرحله بعدی برای Embox جستجو برای کاربران شخص ثالث بود. درک این نکته بسیار مهم است که کاربران در جامعه منبع باز مشارکت کامل دارند. معمولا تعداد کاربران بیشتر از توسعه دهندگان است. و برای اینکه بخواهند در یک پروژه مشارکت کنند، ابتدا شروع به استفاده از آن به روشی می کنند.
اولین کاربران Embox، دپارتمان سایبرنتیک نظری بودند. آنها پیشنهاد ایجاد یک سیستم عامل جایگزین برای Lego Mindstorm را دادند. و اگرچه اینها هنوز کاربران محلی بودند (ما می توانستیم شخصاً با آنها ملاقات کنیم و در مورد آنچه آنها می خواستند صحبت کنیم). اما باز هم تجربه بسیار خوبی بود. به عنوان مثال، ما دموهایی را توسعه دادیم که می‌توان آن را به دیگران نشان داد، زیرا روبات‌ها سرگرم‌کننده هستند و توجه را به خود جلب می‌کنند. در نتیجه، ما کاربران واقعاً شخص ثالثی را دریافت کردیم که شروع به پرسیدن این سوال کردند که Embox چیست و چگونه از آن استفاده کنیم.
در این مرحله باید به مستندسازی فکر می‌کردیم، در مورد وسایل ارتباطی با کاربران. نه، البته قبلاً به این موارد مهم فکر کرده بودیم، اما زودهنگام بود و تأثیر مثبتی نداشت. تأثیر نسبتاً منفی بود. اجازه بدهید چند مثال بزنم. ما از googlecode استفاده کردیم که ویکی آن از چند زبانه بودن پشتیبانی می کرد. ما صفحاتی را به چندین زبان، نه تنها انگلیسی و روسی، که به سختی می‌توانستیم ارتباط برقرار کنیم، بلکه آلمانی و اسپانیایی ایجاد کردیم. در نتیجه وقتی به این زبان ها از او پرسیده می شود بسیار مضحک به نظر می رسد، اما ما اصلاً نمی توانیم پاسخ دهیم. یا قوانینی را در مورد نوشتن مستندات و اظهار نظر معرفی کردند، اما از آنجایی که API اغلب و به طور قابل توجهی تغییر می کرد، معلوم شد که اسناد ما قدیمی بوده و بیش از آنکه کمک کند، گمراه کننده است.
در نتیجه تمام تلاش‌های ما، حتی تلاش‌های اشتباه، منجر به ظهور کاربران خارجی شد. و حتی یک مشتری تجاری ظاهر شد که می خواست RTOS خودش را برای او توسعه دهد. و ما آن را توسعه دادیم زیرا تجربه و زمینه‌ای داریم. در اینجا باید در مورد لحظات خوب و بد صحبت کنید. از بدها شروع می کنم. از آنجایی که بسیاری از توسعه دهندگان به صورت تجاری درگیر این پروژه بودند، جامعه از قبل کاملاً ناپایدار و تقسیم شده بود، که البته نمی توانست بر توسعه پروژه تأثیر بگذارد. یک عامل اضافی این بود که جهت پروژه توسط یک مشتری تجاری تعیین شده بود و هدف او توسعه بیشتر پروژه نبود. حداقل این هدف اصلی نبود.
از سوی دیگر، یکسری جنبه های مثبت وجود داشت. ما کاربران واقعاً شخص ثالث داریم. این نه تنها مشتری، بلکه کسانی بودند که این سیستم برای آنها در نظر گرفته شده بود. انگیزه شرکت در پروژه افزایش یافته است. به هر حال، اگر بتوانید از یک تجارت جالب نیز درآمد کسب کنید، همیشه خوب است. و مهمتر از همه، ما یک خواسته از مشتریان شنیدیم، که در آن زمان برای ما دیوانه به نظر می رسید، اما اکنون ایده اصلی Embox است، یعنی استفاده از کدهای توسعه یافته در سیستم. اکنون ایده اصلی Embox استفاده از نرم افزار لینوکس بدون لینوکس است. یعنی جنبه مثبت اصلی که به توسعه بیشتر پروژه کمک کرد این بود که این پروژه توسط کاربران شخص ثالث استفاده می شود و باید برخی از مشکلات آنها را حل کند.
در آن زمان، Embox قبلاً از محدوده یک پروژه دانشجویی فراتر رفته بود. عامل محدود کننده اصلی در توسعه پروژه با توجه به مدل دانشجویی، انگیزه شرکت کنندگان است. دانش آموزان در حین تحصیل شرکت می کنند و زمانی که فارغ التحصیل می شوند باید انگیزه دیگری وجود داشته باشد. اگر انگیزه ظاهر نشود، دانش آموز به سادگی شرکت در پروژه را متوقف می کند. اگر در نظر بگیریم که دانش آموزان ابتدا باید آموزش ببینند، معلوم می شود که تا فارغ التحصیلی متخصصان خوبی می شوند، اما سهم آنها در پروژه، به دلیل بی تجربگی، چندان زیاد نیست.
به طور کلی، ما به آرامی به نقطه اصلی می رویم که به ما امکان می دهد در مورد ایجاد یک پروژه منبع باز صحبت کنیم - ایجاد محصولی که مشکلات کاربران خود را حل کند. همانطور که در بالا توضیح دادم، ویژگی اصلی یک پروژه منبع باز جامعه آن است. علاوه بر این، اعضای جامعه در درجه اول کاربران هستند. اما وقتی چیزی برای استفاده وجود ندارد از کجا می آیند؟ بنابراین معلوم می‌شود که، درست مانند پروژه‌های غیر متن‌باز، باید روی ایجاد یک MVP (حداقل محصول قابل دوام) تمرکز کنید، و اگر کاربران را علاقه‌مند کند، جامعه‌ای در اطراف پروژه ظاهر می‌شود. اگر فقط از طریق روابط عمومی جامعه، نوشتن یک ویکی به تمام زبان‌های جهان، یا گردش کار git صحیح در github مشغول ایجاد یک انجمن هستید، در مراحل اولیه پروژه بعید است که این موضوع مهم باشد. البته در مراحل مناسب اینها نه تنها مهم هستند، بلکه موارد ضروری نیز هستند.
در پایان می خواهم به آن اشاره کنم به نظر من، منعکس کننده انتظارات کاربر از یک پروژه منبع باز است:
من به طور جدی به تغییر به این سیستم عامل فکر می کنم (حداقل سعی کنید. آنها به طور فعال آن را دنبال می کنند و کارهای جالبی انجام می دهند).
PS روشن ما به اندازه سه گزارش خواهیم داشت. یکی در مورد منبع باز و دو مورد در مورد تعبیه شده (و یکی عملی است). در غرفه ما یک کلاس کارشناسی ارشد در مورد برنامه نویسی میکروکنترلرهای استفاده می کنیم . طبق معمول، سخت افزار را می آوریم و به شما اجازه برنامه ریزی می کنیم. همچنین یک کوئست و فعالیت های دیگر وجود خواهد داشت. به جشنواره و غرفه ما بیایید، سرگرم کننده خواهد بود.
منبع: www.habr.com