Никогда не забывай об этом, когда делаешь open-source проект

Честно говоря, я и не опен-сорс проекты с приличной документацией не видел. Вот, например, искал недавно возможность работать с вебсокетами, так ничего приличнее буста не нашел, а на мелкомягком сайте не документация, а даже не знаю и что - полный бардак. Но это в части разработки ПО, конечно. А в части его использования, предположу, что-то может быть иначе.

Ну, мелкие проекты на гитхабе чаще всё же идут с бинарниками. Кто поглупее - хранит их прямо в гите, кто поумнее - выкладывает релизы.

А вот проекты GNU это да, анекдот. Особенно под винду.

Последняя моя попытка скачать банальный gcc привела меня к pacman, у которого я так и не нашёл команды "установить пакет". В итоге выручил какой-то ноунейм (для меня), выложивший свою свежую сборку на своём сайте, что родом из того первого веба....

Полностью согласен с тем, что с документацией у многих опенсорс проектов большая проблема. Тут сразу вспоминается частое заблуждение про "чистый код == понятный проект", но, к сожалению, это далеко не так, и без хорошего описания любая разработка будет мало полезна. При этом я могу понять разработчиков, которые не любят писать документацию - очень уж это трудоёмкий процесс, который отнимает много времени. Но я надеюсь, что после прочтения статьи, кто-нибудь из создателей плохо задокументированного open-source проекта лишний раз задумается о её необходимости...

GNU подобные лицензии требуют выкладывать код, а не писать документацию. Возможно, отсутствие документации - задел на дальнейшую манетизацию через техподдержку и консультации

Собрать все зависимости бывает тот еще квест. А еще зависимости к зависимостям))))

Опишу свой опыт с другой стороны. Я вот поддерживаю свой компилятор Java/Kotlin/Scala в JavaScript. Какая-то документация есть. Но документация в стиле "вот так вы можете сгенерировать JS". При этом документация не раскрывает, например, следующие моменты:

1. Как подключить JS к HTML-файлу (потому что это элементарная культура, про это вообще в интернете куча всего)

2. Как завести gradle или Maven проект

3. Как обеспечить копирование какого-то файлика в директории сборки в WAR-файл

4. Как поднять HTTP-сервер и задеплоить в нём, например, WAR-файл

5. Как работают те или иные JS API (например, тот же DOM) - есть только документация о том, как их вызывать из Java кода

6. Как отлаживать JS в браузере

7. Как настроить webpack и чем ES2015 modules отличаются от CommonJS

И вот не поверите, всё это у меня постоянно спрашивают пользователи, недовольные тем, что "у проекта нет документации". Когда я кому-то из них по какой-то причине всё-таки помогаю (т.е. по сути помогаю с ИХ проблемой, а не с пониманием, как пользоваться МОИМ компилятором), то угадайте, сколько таких несчастных в ответ написали хоть один туториал в репозиторий с документацией по проекту?

Ещё часто пользователи просто не могут глазами спарсить сообщение об ошибке, где им чёрным по белому расписано, почему что-то не работает. При этом есть ещё небольшая прослойка адекватных пользователей, которым, как оказывается, документация вообще не нужна, потому что они давно склонировали репозиторий и нашли в нём папку samples, где уже есть готовые примеры - изучай нехочу, да папку tests, где, не поверите, лежат тесты, которые являются по совместительству ещё и примерами использования проекта.

Что касается бинарников - обычно для всяких кросплатформенных сред с этим всё сильно лучше. И тут я вам открою страшную тайну: собрать дистрибутив на Rust или C++ под все платформы - это то ещё приключение (хотя бы в силу отсутствия того или иного железа в наличии у мейнтейнера). В случае той же Java это не проблема - собирай себе на любой машине и это запуститсяу кого угодно.

Дарёному коню в зубы не смотрят. Опенсурс-разрабы даже "спасибо" за свой труд не получают. Ну и в лицензиях тоже прописано, мол, никаких гарантий и ответственности

Добавлю, что в релизах вообще большинство любят выкладывать zip-архив исходника и все. Зачем мне исходники, очевидно, что я иду в релизы, чтобы скачать нужный бинарь под свою платформу, а не собирать его?

Инстинктивно хотел порекомендовать gtk toolkit, но потом вспомнил что он в основном только для линуха...

Но напомнить лишний раз про документацию не повредит.

Спасибо за ваше замечание. Советы действительно могут показаться простыми, но в реальности у многих опенсорс разработок существует ряд проблем, связанных с ними. Вот например результаты исследования по используемым лицензиям в открытых проектах: https://blog.opensource.org/the-most-popular-licenses-for-each-language-2023/ - как видно из результатов, огромная часть разработок её и вовсе не имеет. Это очень большая проблема, а ведь разработчики данных решений может и не задумывались ни разу о том, почему она важна. Про повально плохое качество документации в комментариях уже многие отметили. По остальным пунктам то же самое, и я уверен что стоит об этом рассказывать больше и чаще, тогда и многие проекты, которые нас окружают, будут становиться лучше.

С одной стороны - да, с другой - а что небанального и обобщенного можно вообще посоветовать?

- готовы ли вы к конфликтам, форкам, драме, оскорблениям, необоснованным требованиям по немедленной доставке фич, немедленному исправлению багов, немедленной реакции на инциденты, потенциальным проблемам с патентами, адвокатами, письмами cease and desist, DMCA-тейкдаунами, GDPR-совместимостью, бану вашей юрисдикции гитхабом, неадекватами всех сортов и мастей, и прочим прелестям взаимодействия с большой группой бездельников в интернете?

Кстати, да, в статью нужно добавить предупреждение, что среди пользователей статистически предопределённо обязательно найдутся неадекваты, которые будут предъявлять совершенно необоснованные претензии и портить атмосферу в сообществе.

Это нужно иметь в виду и быть морально готовым к этому (а ещё лучше выработать соответствующую политику и административные меры). И это одна из причин по которой закрываются многие ОС проекты.

Очень верное замечание. Очень часто бывает,что ищешь пакет или библиотеку под определенную задачу, а находишь сразу несколько, но все сырые, устаревшие и брошенные. Если бы авторы этих библиотек не делали свои библиотеки, а потратили это время на то, чтобы добавить пару коммитов в уже существующие, всем было бы только лучше.

По сути вы перечислили проблемы любого начинающего бизнеса )

Спасибо за ваши дополнения, полностью согласен что заданные вами вопросы очень важны!
Конечно, существует много факторов, которые следует осознавать при начале своей деятельности в роли лидера опенсорс проекта, но я хотел бы отметить, что правильная работа с сообществом поможет закрыть многие из этих пунктов. Находя помощников и заинтересованных в развитии вашей разработки, вы уже гораздо легче сможете справиться с ростом пользовательской базы проекта. Повышая ответственность коллег, вы снимете нагрузку с себя.
Про цели проекта я также отметил в статье, но тут важно подчеркнуть, что следует обладать гибкостью, и быть готовым к тому, что цели могут измениться в любой момент, иначе будет тяжело выживать при сильной конкуренции. А вот что касается альтернатив и повторения существующего функционала... не могу сказать, что это плохо, всегда полезно, когда есть большой выбор разработок, решающих одну задачу, но по-разному. Элемент конкуренции является драйвером развития любых проектов, а монополии — это всегда плохо, даже в open-source разработке.

Да, это хорошие и полезные предостережения. Нужно еще быть готовым к переговорам, компромиссам, прокачке soft скиллов, чтобы проект развивался эффективно.

Можно узнать, были ли прецеденты заявления прав работодателем на код написанный в свободное время на личном компьютере?

Помню претензии Рамблера на nginx, но это оказалось смешно всем

Вы сейчас говорите - зачем быть бескорыстными, будьте жадными
Зачем быть добрыми, будьте злыми

И да, к коммунизму и альтруизму добавьте христианство. Тоже не победило.

Если лицензировать под AGPL, то корпорациям будет нелегко его использовать. А если это, к тому же, не продукт уровня ядра линукса а маленькая библиотека, то они его не будут использовать почти наверняка. При этом ты по-прежнему можешь наслаждаться своим альтруизмом и тем как приносишь пользу людям своим проектом (более того, каждый успешный проект под gpl приближает победу некой вариации коммунизма).

Однако у условных "корпораций" есть эффективное оружие и против закрытых проектов и против gpl - гитхаб (в меньшей степени и другие сети). Выложив туда проект под лицензией типа mit программисты получают звездочки, подписчиков, обратную связь, которые мотивируют их продолжать работу. Выложив под gpl получают меньше обратной связи (исключаются почти все кто хотел бы зарабатывать на твоем проекте), а не выложив не получают ничего. В таких условиях у закрытых продуктов очень мало шансов.

Just for fun, конечно.

Я когда свой проект стартовал в 2013 году, был на последнем курсе магистратуры, и деньги мне тогда были не нужны, нужны были прикладные знания и навыки в области Software Engineering и Software Development, которые я и пошел получать и тренировать наилучшим, на мой тогдашний взгляд, способом. При этом и процесс, и результат этого труда были нужны именно мне (я тогда занимался модификацией UEFI-совместимых прошивок в качестве хобби), а альтернатив хороших, кросс-платформенных, с открытым кодом и графическим интерфейсом тогда не было.

В итоге получилось и свой C и C++/Qt улучшить заметно, и проблему достаточно эффективно решить, и научиться не только программированию, но и сопровождению, и заиметь определенную репутацию в своих узких кругах, благодаря которой получилось устроиться и на первую серьезную работу (разработчиком прошивок), а затем и в мегакорпорацию (специалистом по безопасности эти самых).

Если бы я заранее рассчитывал на монетизацию этого проекта, то не стал бы за него садиться, потому что у среднего пользователя нет денег на такую ерунду, а имеющиеся альтернативы (PhoenixTool, например) уже тогда были и бесплатными, и работоспособными, а из недостатков имели только закрытый код и привязанность к .Net 3 (т.е. к Windows).

Более того, товарно-денежные отношения для подавляющего большинства людей подразумевают (хотя бы частичную) передачу контроля на проектными решениями и приоритетами, т.е. задачей разработчика становится "делать пользователю зашибись". У меня такой задачи нет, и я делаю зашибись в первую очередь себе самому, а пользователям хотя и очень рад (они, например, тестируют твой софт на конфигурациях, которые ты сам у себя в подвале гарантированно собирать не станешь), но ничего не должен. И донаты не беру по этой же примерно причине.

Корпорации, кстати, это тоже хорошие пользователи, и то, что они каким-то образом делают на моем коде деньги - да на здоровье, я бы эти деньги все равно не сделал, потому что не желаю смешивать работу за деньги с работой для души. Уважение коллег заработал - отлично, пользователи сказали "спасибо" - замечательно, попал в десятку лучших в мире специалистов по разбору UEFI-совместимых прошивок на составные части, потому что за 10 лет работы над их разбором насмотрелся на любые и всякие - тоже хорошо, теперь эту специализацию можно продать тем, кому она для чего-то нужна.

Абсолютно уверен, что если бы я вместо опенсорса и работы с сообществом написал бы какой-нибудь UEFITool PRO и попытался его продать, заработал бы сейчас значительно меньше, если что-либо вообще. А так и с деньгами проблем больше нет, и проект стал стандартом де-факто в своей микроскопической нише. Понятно, что это все результат скорее случайных процессов и удачных таймингов, и потому может быть проигнорировано как "ошибка выжившего", но получилось как получилось, и мне нравится этот результат.

Для начала покажите платёжную систему, которая бы работала во всём мире. Или биткоинами оплачивать?

Были статьи на хабре, например 769892. Если вкратце - всё плохо с GPL. Точнее, всё хорошо, пока все ведут себя по-джентльменски. Как только появляются ушлые люди, убирающие упоминания о лицензиях в заимствованном коде или отказывающиеся выполнять другие положения лицензии, как в упомянутом примере, то выясняется, что никаких правовых механизмов восстановить статус-кво нет.