ساخت یک پروژه متن باز: پشت صحنه

نقطه شروع

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

اگر تصمیم دارید پروژه خود را منبع باز کنید، اولین مراحل آماده سازی را می توانید در https://opensource.guide/starting-a-project/ guideline بیابید. اگر آن را نخوانده اید، به شدت توصیه می کنم این کار را انجام دهید. هنوز کافی نیست، اما نقطه شروع خوبی است.

چند وقت پیش پروژه ای به نام “xq” را شروع کردم که یک زیباساز خط فرمان XML و HTML و استخراج کننده محتوا است که در Go نوشته شده است. با استفاده از این پروژه به عنوان مثال، می خواهم نشان دهم که چه کاری انجام دادم تا آن را کمی بیشتر قابل کشف و استفاده برای افراد دیگر کنم.

انگیزه

خوب، شما قبلاً کد منبع پروژه خود را به GitHub منتقل کرده اید. چرا نیاز به خواندن بعدی دارید؟ خیلی زود، ممکن است متوجه شوید که هیچ کس از وسایل جالب شما استفاده نمی کند که سال گذشته در شب می ساختید. می تواند ناامید کننده باشد.

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

یکی دیگر از چیزهایی که به من انگیزه زیادی می دهد، توانایی آزمایش با فناوری ها و آزمایش چیزهای جدید است. من یک کار معمولی دارم و روی محصول تجاری کار می کنم. آوردن چیزی جدید و غیرقابل اعتماد همیشه سخت است زیرا محصولات تجاری زمین بازی نیستند. بنابراین ابتکارات منبع باز من همیشه به من کمک کرد تا دانشی در مورد فناوری هایی که نمی توانم در کار اصلی از آنها استفاده کنم یا آنها را آزمایش کنم به دست بیاورم.

مخاطب هدف

تجزیه و تحلیل دقیق مخاطبان هدف پروژه خود برای موفقیت پروژه بسیار مهم است. من اغلب می بینم که چگونه سازندگان و نگهبانان از کاربران پروژه خود همان سطح از مهارت ها را انتظار دارند. در بیشتر موارد، این یک سوء تفاهم است که برای هر دو طرف مشکل ایجاد می کند.

به عنوان مثال، برای ابزار “xq” من که با XML در CLI سروکار دارد و در Go نوشته شده است، انتظار دارم که کاربران بدانند XML برای چیست و چگونه از ابزارهای خط فرمان استفاده کنند. اما من اصلاً انتظار دانش Go، زنجیره ابزار مربوطه یا حتی مهارت های کدنویسی را ندارم.

قابلیت استفاده

نکته مهم بعدی این است که در مورد پروژه خود به عنوان محصولی فکر کنید که حداقل نصب آن آسان باشد و شروع به استفاده کنید. در حالت ایده آل، ارزش محصول برای کاربر نهایی از اولین ثانیه های استفاده از محصول شما کاملاً مشخص است.

ما دوست داریم پروژه منبع باز خود را به GitHub فشار دهیم، اما این کد محور است. ما باید با دستورالعمل های نصب آسان و واضح به کاربران خود کمک کنیم. و اینجا یک تله است. من از مک استفاده می کنم و می خواهم ابزار “xq” من با استفاده از Homebrew قابل نصب باشد:

brew install xq

من دستورالعمل‌های نحوه مشارکت در Homebrew را بررسی کردم و متوجه شدم که اگر مخزن شما صفر “ستاره” داشته باشد، شانس اضافه شدن شما صفر است. برای شروع باید جایگزین هایی پیدا کرد. خوب، Go یک تسهیلات برای آن فراهم می کند:

go install github.com/sibprogrammer/xq@latest

در نگاه اول، خوب به نظر می رسد، اما مخاطب را محدود به افرادی می کند که قبلاً زنجیره ابزار Go را نصب کرده اند. این یک محدودیت کاملا سخت است. بنابراین در مورد من، یک نقطه شروع خوب، نصب کننده bash برای ابزار CLI بود:

curl -sSL https://bit.ly/install-xq | sudo bash

پس از به دست آوردن 50-70 “ستاره” اول، ما برای تلاش های جدید مانند brew یا apt install.

اما حتی قبل از اینکه به این فکر کنیم که چگونه فرآیند نصب را آسان کنیم، باید یک کاربر بالقوه را جذب کنیم و ارزش محصول خود را نشان دهیم. من واقعاً پروژه هایی را دوست دارم که دارای یک اسکرین شات یا ویدیوی متحرک هستند که ویژگی های اصلی را درست در ابتدای فایل README.md نشان می دهد. اگر در مورد ابزارهای CLI صحبت می کنیم، مجموعه جامع مثال های استفاده نیز یک بخش اساسی است. اگر نوعی محصول وب است، پیوند به سرور آزمایشی از پیش نصب شده ضروری است. زندگی کوتاه است و همه ما بسیار مشغول هستیم. احتمالاً هیچ تیم فروش برای راحتی کاربران بالقوه ندارید و مردم ممکن است محصول شما را بیش از 1 تا 2 دقیقه ارزیابی کنند.

بازار یابی

خوب، برای اکثریت ما، کلمه “بازاریابی” هیچ ارتباطی با چیز خوب، جالب و کاری که می خواهیم انجام دهیم ندارد. اما داشتن یک محصول خوب کافی نیست، باید به نحوی آن را به دیگران بگوییم.

شروع با دوستان و جوامع محلی چندان سخت نیست. توییتر، ردیت، فیسبوک، لینکدین و سایر شبکه های اجتماعی ممکن است به شما کمک کنند تا اولین بازخوردها را به دست آورید و اولین کاربران را جذب کنید. من می خواهم داستان تلاش های بازاریابی “xq” را برای شما بگویم تا نشان دهم که چگونه در زندگی واقعی کار می کند.

شرکتی که من در آن کار می کنم ابتکاری به نام “روزهای تحقیق” دارد و یک رویداد ویژه به نام “دموهای روزهای پژوهش” وجود دارد. بنابراین، اولین ارائه ای که انجام دادم در این رویداد برای همکارانم بود. افراد زیادی نبودند، اما برخی از آنها این ابزار را دوست داشتند. من همچنین یک پست کوتاه در کانال داخلی Slack مربوط به ابتکارات مشابه گذاشتم.

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

بعدها دوره ای از رشد ارگانیک آهسته، رفع اشکالات و اجرای ویژگی های جدید وجود داشت. من روش‌های ساده‌تر کردن نصب در لینوکس را بررسی کردم و کمک نگهدارنده‌های توزیع کمک زیادی به پذیرش آن کرد.

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

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

در وقت خود صرفه جویی کنید

کار بر روی یک پروژه به دلیل کارهای مختلف می تواند به راحتی خسته کننده شود. مرتب‌سازی گزارش‌های اشکال بد نوشته شده، آزمایش دستی هر تغییر و غیره ممکن است دلیل اصلی نارضایتی باشد. از آنجایی که روی یک پروژه متن باز کار می کنید، وقت خود را صرف کنید و آن را به صورت رایگان انجام دهید. یکی از راه‌هایی که می‌توانید انگیزه خود را حفظ کنید، تمرکز روی پاسخ دادن به این سؤال است که چگونه از کارهای روزمره خودداری کنید و در زمان خود صرفه‌جویی کنید.

GitHub اجازه می دهد تا قالب های سفارشی برای ایجاد شماره جدید ارائه دهد. دست کم نگیر. به طور قابل توجهی به ساده کردن گزارش ها کمک می کند و مردم را مجبور می کند به سؤالات لازم برای نگهدار پاسخ دهند.

آخرین چیزی که من می خواهم در محدوده پروژه های منبع باز خود با آن برخورد کنم، اشکالات رگرسیون است. به همین دلیل است که مجموعه ای جامع از تست ها باعث صرفه جویی قابل توجهی در زمان می شود و لذت کار بر روی بهبود پروژه را به ارمغان می آورد. بدون آزمایش، نگهداری پروژه های کم و بیش پیچیده پس از 5-6 چرخه انتشار به راحتی به یک کابوس تبدیل می شود. جالب است که ببینید چقدر این حقیقت نادیده گرفته می شود.

نوشتن مجموعه ای از تست ها کافی نیست. GitHub Actions یک تسهیلات عالی برای سازماندهی فرآیند CI است نه تنها برای فشار به شاخه اصلی، بلکه برای درخواست‌های کشش نیز. در غیر این صورت، کاملاً ناامید کننده است که پس از ادغام درخواست کشش کسی متوجه شویم که سبک کد یا حتی تست ها شکسته شده است. تنظیم اکشن ها چندان سخت نیست. اگر پروژه منبع باز مورد علاقه خود را بررسی کنید، حدس می‌زنم همه آنها CI را ایجاد کرده باشند.

با “xq”، من حتی فراتر رفتم و فرآیند انتشار را با استفاده از GoReleaser خودکار کردم. برای انتشار نسخه جدید، تنها چیزی که نیاز دارم ایجاد و فشار دادن تگ Git است. GitHub Action مربوطه یک فرآیند انتشار را راه اندازی می کند و GoReleaser باینری ها و تغییرات را بر اساس قراردادهای اعلام شده آماده می کند. نتیجه از سطح بالایی از پیش بینی برخوردار است و نیازی به کار دستی نیست.

امتیازات

پروژه های متن باز معمولاً برای کسب درآمد نیستند. حداقل به صورت مستقیم. اگر می‌خواهید محصولی بسازید و مطمئن نیستید که چگونه از آن درآمد کسب کنید، راه‌اندازی این محصول با منبع باز آن از نظر من اصلاً ایده خوبی نیست.

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

اگر در مورد یک حرفه صحبت می کنیم، من معتقدم تقریباً هر توسعه دهنده ای با بیش از 10 سال تجربه باید بتواند کدهایی را که نوشته است نشان دهد. NDA بهانه ای نیست. تقریباً هر نرم افزار مدرن به شدت به اجزای منبع باز وابسته است. بنابراین، کمک به اصلاح یا بهبود در برخی از پروژه ها فقط یک مسئله زمان و تجربه است. من ممکن است کاملاً در اشتباه باشم، اما به عنوان مردی که در طول دو دهه گذشته صدها مصاحبه فنی انجام داده است، اگر بتوانم کدی که او نوشته است را بررسی کنم، ساختن نمایه نامزد بسیار آسان تر بود. بنابراین در حین کار بر روی پروژه های متن باز، مطمئناً در ساخت نمایه عمومی خود به عنوان یک توسعه دهنده سرمایه گذاری می کنید.

معمولاً بدون استفاده از ابزارهای مختلف نمی توان محصولی ساخت. برخی از آنها می توانند رایگان باشند و برخی از آنها می توانند تجاری باشند. مزیت بزرگ کار بر روی پروژه های متن باز این است که بسیاری از شرکت ها با محصولات تجاری پیشنهادات ویژه ای برای توسعه غیرتجاری دارند. در مورد ابزار “xq” که در Go نوشته شده است، من از GoLand IDE توسط JetBrains استفاده می کنم. من برای چندین ماه هزینه آن را پرداخت کردم اما بعداً سعی کردم برای برنامه منبع باز آنها اعمال کنم. آنها نه تنها برای GoLand بلکه برای کل بسته محصول به من مجوز دادند! مثال دیگر سرویس CodeCov است. من می خواهم پوشش کد را به روشی آسان دنبال کنم تا کیفیت را کنترل کنم و اطمینان حاصل کنم که تمام سناریوهای اصلی توسط آزمایش ها پوشش داده می شوند. CodeCov برای محصولات تجاری بسیار گران است (مخصوصاً نسخه میزبانی شده که حدود 50 هزار دلار هزینه دارد)، اما برای پروژه های منبع باز کاملاً رایگان است و این عالی است! اگر به میزبانی پروژه نیاز دارید (مثلاً برای اهداف نمایشی)، ممکن است سعی کنید برای ابتکار منبع باز DigitalOcean درخواست دهید، و جایگزین های دیگری نیز در دسترس هستند. این فقط چند نمونه است.

اتصال نقطه ها

برای خلاصه کردن مقاله، در اینجا چند نکته وجود دارد که امیدوارم برای شما مفید باشد.

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

بدون بازاریابی، افراد تقریباً هیچ شانسی برای دانستن پروژه جالب شما ندارند. با کمال تعجب شروع آن چندان سخت نیست. و با انگیزه بلندمدت شما از راه های بیشتری نسبت به آنچه در ابتدا فکر می کنید مرتبط است.

پروژه متن باز شما نباید به یک کار خسته کننده تبدیل شود. یکی از راه‌های دستیابی به آن، خودکار کردن تمام کارهای روزمره و اجرای سیاست‌ها است. در پایان، انتشار باید باعث خوشحالی باشد و خواندن درخواست‌های ویژگی‌های کاربر و گزارش‌های باگ نباید شما را به دلیل نداشتن جزئیات ضروری گریه کند.

آخرین اما نه کم اهمیت، کار بر روی پروژه های منبع باز مفید است. گاهی اوقات چندان واضح نیست، اما اگر در مورد چشم انداز بلندمدت صحبت کنیم، قطعاً اینطور است.