Заодно проверю свой же netutils-linux

  1. [x] Убедитесь, что это уже не сделано. Поищите альтернативы. Поищите что ищут люди на stackoverflow для решения задачи, которую решает ваш проект.
  2. [x] Убедитесь, что он реально нужен кому-то кроме вас. Вообще это становится понятно после предыдущего пункта. Кстати, если все предложения в найденных вопросах хуже, чем ваш проект - порекомендуйте его (возможно у вас появится первый пользователь). У меня его использует техподдержка на работе, плюс он вкорячен в основной продукт как модуль и используется из коробки (там обновления значительно реже).
  3. [x] Есть сырая версия, которая работает. Изначально это было набором утилит, которые валялись у меня на компе и вручную подкидывались при необходимости разобраться с сетевым стеком. Иногда писались заново с нуля, так как не мог найти.
  4. [x] У вас есть хорошее название, в гугле никем не занятое. Ладно, есть какой-то проект на sourceforge с таким же названием и отсутствием каких-либо релизов. Ещё есть netutils-selinux, но я не знаю что это.
  5. [x] У вас есть лёгкий способ доставки его людям. Кому-то подойдёт докер, кому-то что-то ещё. В моём случае это pip. Почему это важно - люди ленивые, люди не хотят тратить много времени на что-то, если они не уверены, что оно им пригодится. Если времени требуется меньше - вы увеличите вероятность того, что ваш софт попробуют.
  6. [x] Покажите его ≈10 знакомым. Если меньше 80% говорит что бесполезная херня - отлично. Если больше - стоит задуматься.
  7. [x] Покажите чуть большему кругу лиц, но не навязывая. Запостите ссылку в своём твиттере/google+. Может кому-нибудь будет скучно и вас ткнут носом в говнокод.
  8. [x] Оно покрыто тестами? Перед первым официальным релизом вы должны быть готовы начать очень быстро исправлять баги. Без тестов - это нереально. Воспользуйтесь халявным travis-ci, why not?
  9. [x] README. Если вы поставляете пакет в pypi, скорее всего README у вас в RST. На github отображаться он может неплохо, а вот на pypi вся разметка может и поехать. Проверьте это! P.S: README не на английском - плохая идея.
  10. [x] КАРТИНОЧКИ, ГИФОЧКИ. Покажите что делает ваш код и зачем он вообще нужен. Я дичайше балдею от традиции прикладывать демо-гифку в описание плагинов Atom! Это же чудесно - можно ничего не устанавливать, а уже понятно, нужно оно мне или нет.
  11. [x] БАДЖИКИ. Первым делом люди смотрят на README. Если там есть хоть какой-то намёк на то, что этот код собирается, проходит тесты, доступен для скачивания, а также не богомерзко выглядит под капотом - градус доверия повышается.
  12. [ ] Примеры использования, кейсы, документация. На мой взгляд документация - это не скопипащенный вывод --help. Документация это примеры, глядя на которые пользователь сможет понять как вообще этим пользоваться. (--help этот пункт не отменяет!)
  13. [x] Подчистите код. Рефакторинг, рефакторинг, рефакторинг. Скорее всего пока вы добивались того, чтобы оно просто заработало, вы налепили костылей, сломали архитектуру, итд.
  14. [x] Проверьте работоспособность в разных окружениях. Разные дистрибутивы Linux, MacOS, версии python, разрядность операционной системы, настройки терминала, локали, итд. А ещё проверьте, что после всех пунктов выше этим можно пользоваться (руками запустите).
  15. [ ] Добавьте разных способов установки. Один способ хорошо, но не все хотят использовать ещё один package manager, а кто-то вообще не знает где его взять. Чем больше человек попробует воспользоваться вашим софтом во время пиара и чем больше обратной связи вы соберёте - тем лучше.
  16. [ ] Пиар в рунете.
    1. [x] Статья в бложеке. README хорошо, а публицистический стиль тоже хорошо. Попробуйте приготовиться к пиару, напишите в собственный бложек (в блокнот, если нет) статью о том, что вы сделали, какой вы классный.
    2. [x] Вылизываем статью. Перечитайте её. Перечитайте её за 15 минут. Скормите её главреду. Дайте её прочитать кому-нибудь близкому, чтобы покритиковал. Не обязательно чтобы он разбирался в предмете, если не шарит - даже лучше.
    3. [x] linux.org.ru и прочие reddit. Посмотрите, есть ли уместные темы для упоминания на форуме/в сабреддитах.
    4. [x] Телеграмовые чатики. Если ваш проект хорошо ложится в тематику какого-нибудь из этих телеграмовых чатиков - вбросьте туда. Люди, возможно, покритикуют (но маловероятно, скорее всего будет что-то типа “ыы, клёво”).
    5. [x] Публикуемся в рунете. Если есть аккаунт на хабрахабре - можно немного попиариться там. Тут есть одна сложность - вы (не демка, а именно вы) должны быть способны выдержать хабраэффект. Я опубликовался во вторник и времени на то, чтобы чинить баги и отвечать в issues/комментарии было мало, так как работа же. В итоге, скорее всего, из-за багов с разными окружениями потерял кучу потенциальных пользователей (поставил-не-работает-забил). Если все пункты выше выполнены, то скорее всего звёздочек на гитхабе прибавится, вы попадёте в @pythontrending, что даст некоторый интерес от зарубежных пользователей.
    6. [ ] Я НАХОЖУСЬ ЗДЕСЬ –> Анализируем результаты. Дополните статью на хабре тем, что спрашивали в комментариях больше всего. Возможно после публикации вы допилили какие-то важные фичи.
  17. [ ] Пиар в нормальном интернете
    • [ ] Переведите статью на английский.
    • [ ] Поищите где можно попиариться в интернетах
      • [x] Упоминания в различных тематических wiki. Я подумал, что здесь упоминание моих тулз более чем уместно.
      • [ ] Дальше пока хз
  18. [x] Получаем уже хоть какой-то профит. Для Open Source разработчиков в мире довольно много халявы. Jetbrains к примеру даёт All Products Pack для некоммерческого использования. Выхватить легальный PyCharm Professional бесплатно - вполне себе неплохой бонус за старания.
  19. [ ] Формируем community вокруг проекта. У меня не получилось, наверное нужно больше золотапользователей.