[Перевод] Что нужно сделать перед тем, как выложить код открытого программного обеспечения
Выложить проект с открытым программным кодом — это больше, чем выложить код в Интернете.
Интерес к программным продуктам с открытым исходным кодом растёт последние 10 лет. Linux стоит и в стиральных машинах, и в боевых дронах. Большинство программистов не могут представить свою жизнь без широкого ассортимента бесплатных и открытых инструментов в своем распоряжении.
Обратная сторона этого замечательного тренда состоит в том, что когда вы выпускаете новый проект c открытым исходным кодом, вы попадаете в зону жесткой конкуренции.
Чем вы можете помочь своему проекту, чтобы его заметили?
Перед тем, как открыть какой-либо код, я отвечаю на вопросы, которые изложил в этой статье. Но не обязательно в таком же порядке.
Вы можете следовать каждому пункту чеклиста, а можете только его части. Помните о цели — помочь другим узнать о вашем проекте, быстро разобраться, как его использовать, и принять в нём участие.
Лицензия
- У вашего проекта есть лицензия?
Без лицензии ваш проект не является программным обеспечением с открытым исходных кодом. Больше об этом читайте здесь.
- Эта лицензия одобрена OSI/FSF?
Некоторые лицензии могут выглядеть так, как будто они подходят для лицензирования программного обеспечения с открытым исходным кодом. Но они не имеют такого права. Проверьте список лицензий, одобренных OSI и FSF.
- Ваша лицензия совместима с другими в экосистеме?
Проверьте, какое лицензирование у проектов похожей тематики. Больше о совместимости лицензий читайте здесь.
Сайт
- Есть ли у вашего проекта страница в интернете?
Readme на Gihub, profile на SourgeForce или специализированные сайты. Вашему проекту нужно иметь свое место в интернете.
- Посетителю страницы сразу будет понятно, что это?
- И как это работает?
- Вы использовали визуальные элементы?
Скриншоты и диаграмы — легкий способ захватить внимание читателя.
- Вы оставили свои контакты?
Наверняка вы захотите услышать мысли людей, которые заинтересованы в вашем проекте.
Доступность
- Вы предоставляете способ распространения «родной» для языка программирования?
Это может быть npm, gem или crate. Если у вашего языка есть система управления пакетами, ваш проект должен быть зарегистрирован в ней.
- Вы можете предложить способ распространения для дистрибутива *nix?
Возможность устанавливать программное обеспечение из знакомых источников — это вершина комфорта вашего пользователя. Если у вас есть время, позаботьтесь о том, чтобы разместить ваш проект для Fedora, Debian/Ubuntu или Homebrew.
- Имеет ли смысл писать автоматический установщик?
С помощью автоматического установщика ваш проект можно будет запустить и установить так же просто, как установить package штатными средствами. Если создание package не имеет смыла для вашего проекта, пишите легкий инсталлятор/установщик (как этот или этот)
Документация
- Ваша документация начинается с краткого руководства по установке?
Чем легче установить и запустить ваш проект, тем вероятнее, что кто-то его попробует.
- Включен ли интерфейс/ссылки на API?
Кроме того, чтобы дать возможность «попробовать» ваш проект, интерфейс/ссылки на API — крайне важны, если кто-то действительно захочет использовать ваш продукт.
- Вашу документацию, вообще, можно найти?
Поисковая функциональность сделает вашу документацию более полезной. Даже если это только одна страница с ctrl-f в браузере.
- Должна ли она объяснять, как создать окружение для разработчика?
Возможно, вы хотите упомянуть, как собрать и отлаживать ваш проект для тех, кто захочет принять участие в его разработке.
Багтрекер
- Он не пустой?
Даже если сейчас вы не нашли багов, сделайте несколько тикетов для вещей, которые вы хотите улучшить или сделать в следующий раз. Вы никогда не угадаете, кто может их обнаружить.
- Он включает несколько задач для начинающих?
Сделайте несколько действительно простых задач, чтобы вовлечь тех, кто только начинает программировать для опен-сорс проектов. Разделение функции на две или выведение дополнительного аргумента командной строки — это замечательные задачи для тех, кто незнаком с кодом проекта.
- Все ли задачи хорошо объяснены?
Убедитесь, что все задачи хорошо описаны, и другие программисты легко могут работать с ними, если им будет интересно.
Инструменты
- У вашего проекта есть автотесты?
Набор тестов облегчит проверку изменений на совместимость с оставшимся кодом проекта программистам, которые принимают участие в вашем проекте.
На старт, внимание, релиз!
Если на все вопросы вы ответите утвердительно, ваш проект станет очень успешным среди других проектов с открытым программным кодом. Не переживайте, если не получится сделать всё — даже маленькие шаги работают на вас.
И когда первый разработчик придет и напишет что-то в коде, не забудьте это отметить, как чувак из «Большого Лебовски»:
Только что из Иллинойса
Если вы знаете, что ещё можно добавить в этот список, напишите в комментариях к статье или в твиттер автору статьи: @radekpazdera.
