Выложить проект с открытым программным кодом – это больше, чем выложить код в Интернете. Интерес к программным продуктам с открытым исходным кодом растёт последние 10 лет. Linux стоит и в стиральных машинах, и в боевых дронах. Большинство программистов не могут представить свою жизнь без широкого ассортимента бесплатных и открытых инструментов в своем распоряжении.
Обратная сторона этого замечательного тренда состоит в том, что когда вы выпускаете новый проект c открытым исходным кодом, вы попадаете в зону жесткой конкуренции.
Чем вы можете помочь своему проекту, чтобы его заметили?
Перед тем, как открыть какой-либо код, я отвечаю на вопросы, которые изложил в этой статье. Но не обязательно в таком же порядке.
Вы можете следовать каждому пункту чеклиста, а можете только его части. Помните о цели – помочь другим узнать о вашем проекте, быстро разобраться, как его использовать, и принять в нём участие.
Лицензия
- У вашего проекта есть лицензия?
- Эта лицензия одобрена OSI/FSF?
- Ваша лицензия совместима с другими в экосистеме?
Сайт
- Есть ли у вашего проекта страница в интернете?
- Посетителю страницы сразу будет понятно, что это?
- И как это работает?
- Вы использовали визуальные элементы?
- Вы оставили свои контакты?
Доступность
- Вы предоставляете способ распространения «родной» для языка программирования?
- Вы можете предложить способ распространения для дистрибутива *nix?
- Имеет ли смысл писать автоматический установщик?
Документация
- Ваша документация начинается с краткого руководства по установке?
- Включен ли интерфейс/ссылки на API?
- Вашу документацию, вообще, можно найти?
- Должна ли она объяснять, как создать окружение для разработчика?
Багтрекер
- Он не пустой?
- Он включает несколько задач для начинающих?
- Все ли задачи хорошо объяснены?
Инструменты
- У вашего проекта есть автотесты?
На старт, внимание, релиз!
Если на все вопросы вы ответите утвердительно, ваш проект станет очень успешным среди других проектов с открытым программным кодом. Не переживайте, если не получится сделать всё – даже маленькие шаги работают на вас.
И когда первый разработчик придет и напишет что-то в коде, не забудьте это отметить, как чувак из «Большого Лебовски»:
Только что из Иллинойса
Если вы знаете, что ещё можно добавить в этот список, напишите в комментариях к статье или в твиттер автору статьи: @radekpazdera.
Комментарии (31)
Noiwex
14.06.2016 13:34-20Всё равно, выкладывать свой труд в опенсорс — сомнительное удовольствие.
А тем более, заботиться о том, чтобы его использовали — это вообще что-то странное.
vedenin1980
14.06.2016 13:54+11Почему? Есть 4 материальных мотива выкладывать код в опенсорс (не будет упоминать хобби и самовыражение):
- Популярный опенсорс высоко ценится работодателями на Западе -> выше зар.плата -> профит,
- Опенсорс даёт возможность сэкономить на разработке, скажем всю экосистему Нadoop и ему подобных в одиночку даже гугл нормально развивать не сможет, см. Нadoop, Spark и т.п.,
- Вы делаете бизнес на поддержки опенсорс см RedHat и ему подобные компании,
- Вы выкладывайте урезанную версию в опенсорс, а полную версию продаёте за деньги, см Idea
claygod
14.06.2016 15:22Популярный опенсорс высоко ценится работодателями на Западе -> выше зар.плата -> профит,
По сути, это обычная самореклама (думаю, эффективная).
Если у написанного автором кода на гитхабе тысяча звёзд,
это весьма существенная рекомендация.
Осталось только заработать эту самую тысячу звёзд…
Meklon
14.06.2016 15:27+7Есть еще наука. Я, например, пилю проект для лабораторий. Простой, но полезный. Для меня это контакты с коллегами и просто помощб другим. Радует.
Antelle
14.06.2016 16:061000 просто набирается, если проект полезный, нужный автору, ридмишка красивая и лендинг привлекательный.
https://changelog.com/top-ten-reasons-why-i-wont-use-your-open-source-project/
RevenantX
14.06.2016 15:19+1Ну если ты делаешь действительно важную вещь — то бывает такое, что люди сами находят твой проект на том-же GitHub. По описанию простому.
mwambanatanga
14.06.2016 15:19+4Человек вообще странное существо. И все его удовольствия — сомнительные.
woodhead
14.06.2016 15:19+1Если проект достаточно объёмный, то это реальный шанс привлечь помощников.
blackstrip
16.06.2016 06:39-1реальный шанс привлечь помощников — это нанять команду, а забесплатно — это только шанс привлечь школьников, у которых есть свободное время чтобы заниматься всякой фигней) а потом они еще и растащат ваш проект на куски себе и будет он как труп всплывать: то там рука от него показалась, то тут нога, вроде бы все ваше, но уже без всяких там лицензий, тупо украдено.
AlexZaharow
14.06.2016 14:34+5По поводу пункта «Документация».
Я бы предложил первым пунктом в документации указать какая у программы самая главная функция, ради чего она писалась и почему пользователь должен выбрать вашу программу именно за «это», этакий вау-эффект, а инструкция по установке уже вторым пунктом. Это надо писать не только на сайте самой программы (если таковой вообще есть), а по возможности в нескольких местах. Я так не один проект открыл и закрыл (не зацепило или сходу не разобрался, в то время как соседи по выборке предлагали более внятное объяснение).
Для примера, на сайте microsoft ооочень много плохой документации. Дофига описания как установить, но нет никакой возможности понять, а что я получу в результате настройки или установки? Не стоит надеяться на «опыт» пользователя, что он всё правильно себе представит.
Если программа зацепила, то какая бы «странная» не была установка — есть мотивация её осилить.Antelle
15.06.2016 00:42Очень поддерживаю о пользе tagline-а. Одна строка с описанием решаемой задачи важна не только open-source, а вообще любому проекту и даже продукту. Такой своеобразный TL;DR, видя который сразу понимаешь, стоит читать дальше или нет. Пример: A free Git & Mercurial client for Windows or Mac.
Fen1kz
14.06.2016 17:56-2Из-за раздела "разработка" ожидал увидеть что-то вроде:
Что нужно сделать перед тем, как выложить код открытого программного обеспечения?
A вот что:
git commit -am "new feature"
git push
git pull-request [-f] [TITLE|-i ISSUE|ISSUE-URL] [-b BASE] [-h HEAD]
soniq
15.06.2016 02:26+1А что там, кстати, с правом собственности. Вот, допустим, у меня есть одна библиотека, которую я мало-мало продаю заказчикам. Если ее выложить в опенсорс, то я смогу после этого легально продавать "свой" софт с коммитами посторонних людей, или он уже "не мой" после этого будет?
DrReiz
15.06.2016 02:59+3Зависит от лицензии под которой исходный код был выложен. Код «посторонних» коммитов, присоединится к данной лицензии.
BSD(или аналог) не мешает продавать. GPL(или аналог) потребует выложить исходники продаваемого продукта.
semenyakinVS
15.06.2016 03:24+1Спасибо за перевод, полезная информация! Ну, и раз тут такая тема — рискну задать наболевшие вопросы…
Не было у кого-нибудь опыта старта фан-проекта сразу с небольшой командой?.. Подскажите: как вы решали конфликты при проектировании базового каркаса приложения? Не было ли проблем с пониманием друг друга в условиях не установившейся терминологии? Ну и ещё вопрос (скорее, психологического характера)… Как сломать внутренний барьер и начать доверять людям написание части своего, кровного проекта?
Откуда возникли вопросыМы начали небольшой командой делать библиотечку, и уже в первую неделю случилось так, что вроде обсудили всё по три раза, поняли друг друга в деталях… А люди коммитили — и оказывалось, что у нас на самом деле были разные взгляды на вещи, я начинал нехорошие споры (типа, как надо и как не надо писать код), как инициатор проекта тянул одеяло на себя и в результате вообще взялся всё переписывать сам…
В общем, обнаружил, что это не так-то просто доверять людям писать код, пока не устаканился стабильный каркас приложения. Хочется, с одной стороны, заложить максимально правильное (как я его вижу) направление развития, а с другой — сделать так, чтобы люди вносили что-то своё в проект, обсуждать с ними как-нибудь, чтобы не выходило так, что я один у руля стою, а остальные так, на позиции подающих.
Понять бы как забороть этих внутренних демонов и организовать разумное и продуктивное взаимодействие в команде.Cryvage
15.06.2016 22:38+1А это смотря какая ваша конечная цель.
Если целью является написание кода, отвечающего вашему чувству прекрасного, и дальнейшее самоудовлетворение, через его созерцание, то проще всего начинать писать все самому, а затем, когда уже фундамент будет заложен, искать тех, кто разделяет ваши идеи. Но не факт, что найдете. Зависит от строгости ваших требований. Написание такого кода — цель благородная, но труднодостижимая.
Если же цель — написание библиотеки для практического использования, то надо просто составить «на бумаге» четкое ТЗ. Без фанатизма конечно, но достаточно подробное. И договориться о Code Style. Тоже описать его «на бумаге». В принципе, для библиотеки самое главное — сохранить единообразие API. Вообще, на этапе становления, самые жесткие требования надо предъявлять к публичному программному интерфейсу, а как сам код внутри написан — дело десятое. Это же первая версия, нужно сначала сделать ее и оценить. нужно ли оно вообще, и должно ли быть сделано именно так. А уж потом, код можно рефакторить и оптимизировать хоть до посинения. Рефакторинг, его ведь вообще невозможно закончить, его можно только прекратить.
З.Ы. опенсорс пока не писал, все вышесказанное, взято из опыта программирования вообще. Не раз приходилось писать системообразующее ПО и библиотеки, которые потом использовались другими программистами.semenyakinVS
16.06.2016 03:03Спасибо за ответ! Не сказать что он полностью дал решение проблемы, но он в чём-то дополнил мои мысли и натолкнул на некоторые дополнительные размышления.
Вот о чём подумал… Вопрос состоял в том, как добиться формированию единообразия API и того, как добиться общих взглядов на организацию API внутри команды. После первого провала менеджмента проекта с моей стороны (не проверил насколько люди поняли основные идеи проекта после обсуждений), я выбрал авторитарный стиль: взял и сформировал API по-своему, после чего рассказал написанное по по-своему API, выслушал их замечания.
Плюсы авторитарного стиля: В более или менее сжатые сроки получилось создать базовое API, от которого можно развивать библиотеку.
Минусы авторитарного стиля: Отсутствие параллелизма в решении задач и демотивация участников команды, которые чувствуют себя отстранёнными от развития библиотеки.
Теперь по поводу мыслей после вашего комментария… Осознал, что, пожалуй, в принципе не возможно распараллелить такую задачу, как построение базовой архитектуры программы. И действительно, лучший вариант — предложить коллегам по проекту поучаствовать в активном обсуждении того, что будет писаться, но акцентировать внимание на том, что код в будешь писать ты сам. При этом, конечно, не стоит закрывать возможность критики и формировать базовое API микрокоммитами, чтобы по мере реализации проговоренного на словах можно обсуждать те или иные решения. При этом также желательно как можно скорее реализовать API. Пусть самым примитивным образом — главное чтобы коллеги по проекту не заскучали и не почувствовали свои права в проекте ущемлёнными.
И вот когда базовое API будет готово и будут сформулированы общие принципы работы — стоит сразу начать параллелить задачи и разделять области ответственности между участниками проекта… Ну, и тут уже легче будет терпеть чужие изменения в проекте — они будут жить за интерфейсом, задаваемым API. Изменения эти легко осмысляются численными метриками (расход памяти, быстродействие, и т.д.), а не такими абстрактными штуками как «красота кода» или «разумность дизайна»
Piocan-Alex
15.06.2016 22:38Качественный Open Souce несущий пользу для бизнеса или клиентов является нематериальным активом по всем признакам.
В России физическое лицо не может иметь нематериальные активы, но могут иметь авторское право на ПО. По закону об авторском праве лицензии прилагаемые к Open Souce не имеют силы, имеет силу факт доказывания авторства через суд.
ИП и ООО имеют нематериальные активы вместо авторского права, которые являются более значимым ресурсом в силу нашего менталитета. Опять же, лицензия не является доказательством чего либо. Есть тот же закон об авторском праве, который первостепенен. Есть патентное бюро, где можно официально зарегистрировать программу.
Интересно, что если физ лицо работает на компанию по трудовому договору, то иногда там есть пункт об авторском праве, который подразумевает переход всех авторских прав на которые может претендовать компания в собственность компании. Тогда Open Source выложенный физ лицом, который хоть как то пересекается с основной деятельностью физ лица является собственностью компании.
phprus
16.06.2016 08:30> По закону об авторском праве лицензии прилагаемые к Open Souce не имеют силы
На столько не имеют, что о них даже отдельная статья в ГК РФ имеется: «Статья 1286.1. Открытая лицензия на использование произведения науки, литературы или искусства». И да, к программам для ЭВМ она тоже относится, так как они у нас охраняются как литературные произведения, да и в самой статье есть отдельная сноска про программы и базы данных.
> имеет силу факт доказывания авторства через суд
Имущественные и не имущественные авторские права в России возникают в момент создания произведения и не требуют отдельной процедуры регистрации или утверждения.
> то иногда там есть пункт об авторском праве, который подразумевает переход всех авторских прав на которые может претендовать компания в собственность компании
В России трудовой договор НЕ распространяется на нерабочее время. По этому у себя дома сотрудник может писать любой опенсурс в любой области деятельности. Проблемы возникнут только если сотрудник использует интеллектуальную или другую собственность работодателя.
А вот в США, например, это законная и часто используемая практика.
dempfi
15.06.2016 22:39Выходить с oss проектом очень тяжело. Ладно ещё когда проект не осень популярный — можно и одному справляться в свободное время, а вот когда проект становиться интересным сообществу, тогда и начинаются настоящие проблемы.
Юзеры очень часто недовольны и плохо читают документацию или вообще не читают, issues в несколько раз больше чем pull request'ов, а простой минорный роадмап может нехило так вздуться из-за багрепортов причём частенько весьма и весьма посредственных, которые, опять же, некому исправлять.
История с neovim'ом довольно показательна в этом плане. Так что oss это такая странная штука — делаешь добро, а по большей части получаешь негативный фидбек в ответ и чем популярнее проект, тем больше негатива читать и разбираться.
buratino
21.06.2016 11:56Эта лицензия одобрена OSI/FSF?
Некоторые лицензии могут выглядеть так, как будто они подходят для лицензирования программного обеспечения с открытым исходным кодом. Но они не имеют такого права. Проверьте список лицензий, одобренных OSI и FSF.
Вообще говоря с точки зрения (истинного гика/настоящего линуксоида/программиста-пофигиста/сторонника открытого ПО/патлатого чувака с фотки/гражданского кодекса) совершенно монопенисуально, одобрена или не одобрена кем-то там твоя лицензия. Можно использовать готовую, можно написать «мне всё пофиг, пользуйтесь как хотите».
ozkriff
21.06.2016 12:11> «мне всё пофиг, пользуйтесь как хотите»
Такой подход может сильно помешать использованию кода людьми, которые не хотят нарушать закон.buratino
21.06.2016 13:46Почему?
ozkriff
21.06.2016 14:26Потому что очень размытое заявление (в таком виде выглядит очень похоже на много кем критикуемую WTFPL), действительность которого для законодательств разных стран сомнительна. И, как я понимаю, в качестве бонуса на тебя могут подать в суд за ущерб, нанесенный твоим ПО (потому что не проговаривается отказ от ответственности блаблабла), или насчет патентов.
MonkAlex
А есть простая блок-схема, как выбрать лицензию? Описания обычно слишком сложные, чтобы понять разницу.
demitsuri
Вот тут есть более доступные для понимания описания.
blackstrip
«Вздумали выложить кусок текста программы? А у вас есть лицензия?» без слез не взглянешь. Примотай текст «я разрешаю, не разрешаю, запрещаю» и сразу не смогут раздербанить прогу на строчки? или взять куском, наплевав на все «лицензии»? Лицензиями и открытыми кодами балуются, в основном, те, кому терять нечего. Вместо написания своего кода они набирают из готовых проектов кусками код, лепят из него Франкенштейна, потом выкладывают его в открытую, и уже другие из него чего то свое лепят. Получается круговорот бесплатного открытого кода в среде ленивых псевдокодеров.
Zibx
Прекрасный ресурс.