Как да стартирам проект с отворен код

Казвам се Дима и съм разработчик на Ruby. Днес искам да споделя моя опит в създаването на решение с отворен код. Ще говоря за това какви стъпки трябва да предприеме проектът, как да избера правилната функционалност за първото издание и какви грешки съм срещал лично при създаването на моя проект с отворен код.

Преди половин година имах идеята, че би било добре да създам проект с отворен код. Вместо тестови задачи за интервюто, ще ми е достатъчно да изпратя линк към хранилището. Перспективата да помогна на колегите за решаване на ежедневните им проблеми ме вдъхнови.

Винаги не съм харесвал скъпоценни камъни за създаване на административни панели. Всяко допълнително движение трябва да предефинира класа, а за полета за промяна трябва да направите промени във файловете. След като помислих и разговарях с колеги, реших да създам нова библиотека, която да бъде гъвкава и да не изисква табла за управление или конфигурационни файлове.

Определете целите

Всеки проект с отворен код решава определен проблем. Говорете с колеги, чатове, форуми и споделете идеята си. Всичко ви помага на първите стъпки да разберете важни неща, като например кои решения вече съществуват, и да чуете критика. Говорете с хора, които вече имат проекти с отворен код. Те могат да ви дадат много ценен съвет, така че не се страхувайте да попитате и да поемете инициативата.

Един важен съвет, който получих на този етап, е да обърна внимание на първо място на документацията на проекта. Можете да имате много добър проект, но никой няма да отдели време, за да разбере как работи.

Най-важният аспект, без който не са възможни по-нататъшни стъпки, е мотивацията. Идеята на проекта трябва да ви вдъхнови преди всичко. Най-често хората свикват с инструментите, с които работят и попадат в зона на комфорт, така че външните мнения може да са двусмислени.

Планиране

Изборът на определен ръководител на задачи е въпрос на вкус. Той трябва да има ясна представа за задачите и етапите на вашия проект.

Разделете задачите на подзадачи. В идеалния случай, ако една задача не отнема повече от 3-4 часа, е важно да се насладите на изпълнението на малки задачи. Това ще помогне да се избегне изгаряне и загуба на мотивация.

Използвам основен тракер. Основното предимство е безплатната версия за проекти с отворен код, където можете да сортирате задачите по вид (функция, грешка, работа, освобождаване) и да ги групирате в издания и определени срокове.

Документация

Всеки проект с отворен код трябва да съдържа следните неща:

  • ПРОЧЕТИ МЕ
  • Лиценз с отворен код
  • Допринасящи насоки
  • Дневник на промените

Файлът README не само обяснява как да използвате проекта си, но и целта на проекта. Ако не знаете как правилно да напишете README файл, можете да разгледате други известни проекти с отворен код или да използвате шаблон.

Лицензът гарантира, че други могат да използват, копират и модифицират изходния код на проекта. Трябва да добавите този файл към всяко хранилище с вашия проект с отворен код. MIT и Apache 2.0 GPLv3 са най-популярните лицензи за проекти с отворен код. Ако не сте сигурни какво да изберете, можете да използвате тази удобна услуга.

Файлът CONPRIBUTING ще помогне на други разработчици да допринесат за проекта. При първите стъпки на проекта не е необходимо да обръщате голямо внимание на този файл. Можете да използвате вече подготвения шаблон от друг проект.

Дневникът на промените съдържа поддържан, хронологично подреден списък със значителни промени за всяка версия. Както при досието С ПРИНОС, не съветвам да обръщате специално внимание на това на ранен етап.

Версиониране

За проследяване на важни промени за потребители и сътрудници има семантична версия. Номерът на версията съдържа номера и се придържа към следния модел XYZ

  • X основно издание
  • Y второстепенно освобождаване
  • Z освобождаване на пластира

Непрекъсната интеграция / Непрекъсната доставка

За да стартирам автоматично тестове и изграждане, използвам Travis CI. Също така е добра идея да добавите значки, за да покажете успешното сглобяване на компилацията в съветника, тестовото покритие (Codecov) и документацията (Inch CI).

След всеки нов фиксиране или обединяване в главното, аз автоматично имам разполагане на Heroku (много удобна интеграция с GitHub). Всички инструменти са абсолютно безплатни за проект с отворен код.

Мои грешки

За да анализирам началния етап, имах идея, но нямаше ясен план. Реших, че искам да направя това, без да имам ясна представа колко време ще отнеме или конкретно представяне на функциите, които ще бъдат в първата версия на библиотеката. Имах много голямо желание и липса на ясен план.

Освен това, след като прочетох историята на други проекти (не само с отворен код), забелязах, че на ранен етап някои планове са твърде оптимистични. Те се нуждаят от преоценка на своите сили и възможности. Но не е лесно да намирате време всеки ден, за да напишете нова функция в проекта. Повечето задачи в крайна сметка трябваше да бъдат премахнати, оставяйки необходимия минимум за MVP.

В момента моят прост администраторски проект е в алфа версията. По-нататъшните планове включват създаване на отделна версия на библиотеката за Hanami.