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

Тема в разделе "Другие языки программирования", создана пользователем Dragokas, 21 июн 2016.

  1. Dragokas
    Оффлайн

    Dragokas Very kind Developer Команда форума Супер-Модератор Разработчик Клуб переводчиков

    Сообщения:
    4.497
    Симпатии:
    4.312
    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.

    Источник.
     
    orderman нравится это.
  2. Dragokas
    Оффлайн

    Dragokas Very kind Developer Команда форума Супер-Модератор Разработчик Клуб переводчиков

    Сообщения:
    4.497
    Симпатии:
    4.312

Поделиться этой страницей