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

Dragokas

Angry & Scary Developer
Команда форума
Супер-Модератор
Разработчик
Клуб переводчиков
Сообщения
7,814
Реакции
6,593
1.jpg


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

Интерес к программным продуктам с открытым исходным кодом растёт последние 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 в браузере.
  • Должна ли она объяснять, как создать окружение для разработчика?
Возможно, вы хотите упомянуть, как собрать и отлаживать ваш проект для тех, кто захочет принять участие в его разработке.

Багтрекер

  • Он не пустой?
Даже если сейчас вы не нашли багов, сделайте несколько тикетов для вещей, которые вы хотите улучшить или сделать в следующий раз. Вы никогда не угадаете, кто может их обнаружить.
  • Он включает несколько задач для начинающих?
Сделайте несколько действительно простых задач, чтобы вовлечь тех, кто только начинает программировать для опен-сорс проектов. Разделение функции на две или выведение дополнительного аргумента командной строки – это замечательные задачи для тех, кто незнаком с кодом проекта.
  • Все ли задачи хорошо объяснены?
Убедитесь, что все задачи хорошо описаны, и другие программисты легко могут работать с ними, если им будет интересно.

Инструменты

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

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

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

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

2.gif

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

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

Источник.
 
Назад
Сверху Снизу