Что нужно сделать перед тем, как выложить код открытого программного обеспечения

Выложить проект с открытым программным кодом – это больше, чем выложить код в Интернете.

Интерес к программным продуктам с открытым исходным кодом растёт последние 10 лет. Linux стоит и в стиральных машинах, и в боевых дронах. Большинство программистов не могут представить свою жизнь без широкого ассортимента бесплатных и открытых инструментов в своем распоряжении.

Обратная сторона этого замечательного тренда состоит в том, что когда вы выпускаете новый проект c открытым исходным кодом, вы попадаете в зону жесткой конкуренции.

Чем вы можете помочь своему проекту, чтобы его заметили?

Перед тем, как открыть какой-либо код, я отвечаю на вопросы, которые изложил в этой статье. Но не обязательно в таком же порядке.

Вы можете следовать каждому пункту чеклиста, а можете только его части. Помните о цели – помочь другим узнать о вашем проекте, быстро разобраться, как его использовать, и принять в нём участие.

Лицензия

• У вашего проекта есть лицензия?

Без лицензии ваш проект не является программным обеспечением с открытым исходных кодом. Больше об этом читайте здесь ^[1].

• Эта лицензия одобрена OSI/FSF?

Некоторые лицензии могут выглядеть так, как будто они подходят для лицензирования программного обеспечения с открытым исходным кодом. Но они не имеют такого права. Проверьте список лицензий, одобренных OSI ^[2] и FSF ^[3].

• Ваша лицензия совместима с другими в экосистеме?

Проверьте, какое лицензирование у проектов похожей тематики. Больше о совместимости лицензий читайте здесь ^[4].

Сайт

• Есть ли у вашего проекта страница в интернете?

Readme ^[5] на Gihub, profile ^[6] на SourgeForce или специализированные сайты ^[7]. Вашему проекту нужно иметь свое место в интернете.

• Посетителю страницы сразу будет понятно, что это?

• И как это работает?

• Вы использовали визуальные элементы?

Скриншоты и диаграмы – легкий способ захватить внимание читателя.

• Вы оставили свои контакты?

Наверняка вы захотите услышать мысли людей, которые заинтересованы в вашем проекте.

Доступность

• Вы предоставляете способ распространения «родной» для языка программирования?

Это может быть npm ^[8], gem ^[9] или crate ^[10]. Если у вашего языка есть система управления пакетами, ваш проект должен быть зарегистрирован в ней.

• Вы можете предложить способ распространения для дистрибутива *nix?

Возможность устанавливать программное обеспечение из знакомых источников – это вершина комфорта вашего пользователя. Если у вас есть время, позаботьтесь о том, чтобы разместить ваш проект для Fedora ^[11], Debian/Ubuntu ^[12] или Homebrew ^[13].

• Имеет ли смысл писать автоматический установщик?

С помощью автоматического установщика ваш проект можно будет запустить и установить так же просто, как установить package штатными средствами. Если создание package не имеет смыла для вашего проекта, пишите легкий инсталлятор/установщик (как этот ^[14] или этот ^[13])

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

• Ваша документация начинается с краткого руководства по установке?

Чем легче установить и запустить ваш проект, тем вероятнее, что кто-то его попробует.

• Включен ли интерфейс/ссылки на API?

Кроме того, чтобы дать возможность «попробовать» ваш проект, интерфейс/ссылки на API – крайне важны, если кто-то действительно захочет использовать ваш продукт.

• Вашу документацию, вообще, можно найти?

Поисковая функциональность сделает вашу документацию более полезной. Даже если это только одна страница с ctrl-f в браузере.

• Должна ли она объяснять, как создать окружение для разработчика?

Возможно, вы хотите упомянуть, как собрать и отлаживать ваш проект для тех, кто захочет принять участие в его разработке.

Багтрекер

• Он не пустой?

Даже если сейчас вы не нашли багов, сделайте несколько тикетов для вещей, которые вы хотите улучшить или сделать в следующий раз. Вы никогда не угадаете, кто может их обнаружить.

• Он включает несколько задач для начинающих?

Сделайте несколько действительно простых задач, чтобы вовлечь тех, кто только начинает программировать для опен-сорс проектов. Разделение функции на две или выведение дополнительного аргумента командной строки – это замечательные задачи для тех, кто незнаком с кодом проекта.

• Все ли задачи хорошо объяснены?

Убедитесь, что все задачи хорошо описаны, и другие программисты легко могут работать с ними, если им будет интересно.

Инструменты

• У вашего проекта есть автотесты?

Набор тестов облегчит проверку изменений на совместимость с оставшимся кодом проекта программистам, которые принимают участие в вашем проекте.

На старт, внимание, релиз!

Если на все вопросы вы ответите утвердительно, ваш проект станет очень успешным среди других проектов с открытым программным кодом. Не переживайте, если не получится сделать всё – даже маленькие шаги работают на вас.

И когда первый разработчик придет и напишет что-то в коде, не забудьте это отметить, как чувак из «Большого Лебовски»:

Только что из Иллинойса

Если вы знаете, что ещё можно добавить в этот список, напишите в комментариях ^[15] к статье или в твиттер автору статьи: @radekpazdera.

Автор: Voximplant

Источник ^[16]