Почему некоторые библиотеки с открытым исходным кодом не предоставляют двоичные файлы?

Почему некоторые библиотеки с открытым исходным кодом не предоставляют двоичные файлы? Я заметил, что некоторые проекты принадлежат сторонним организациям, которые поддерживают текущие сборки программного обеспечения, особенно для сборок Windows.

Я спрашиваю, потому что это похоже на барьер для принятия библиотеки. Для разработчика это больше работа, так как он должен настроить свою среду для ее создания. Разработчик также должен беспокоиться о том, что он вводил ошибки, неправильно создавая библиотеку.

РЕДАКТИРОВАТЬ : Некоторые обновления для адреса комментариев и ответов. Я удалил примеры, так как они не являются центральными для обсуждения. Также перефразировал мой вопрос, поскольку «некоторые библиотеки с открытым исходным кодом предоставляют», а не «библиотеки с открытым исходным кодом, как правило, предоставляют» ... не понимал, что люди обидятся на это.

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

• Вы использовали Windows для того, что кажется вечным.
• У вас дома установлена ​​только Windows.
• Вы использовали Linux здесь и там на работе, но только как пользователь, а не для администрирования или разработки для Linux.
• Вы знаете, что gcc - наиболее часто используемый компилятор для Linux, но никогда не устанавливали его на свой компьютер.
• Вы в основном работаете над программным обеспечением для себя в Windows, но не возражаете против исправления ошибок для Linux, если кто-то другой сделает работу по обеспечению его совместимости и распространению двоичных файлов.
• Вы не хотите платить за другую ОС и набор инструментов, когда кто-то, кто уже имеет, совершенно готов сделать сборки.

Каир - это библиотека, а не приложение. У Postgres, похоже, есть бинарные файлы для Windows . Небольшие проекты часто не предоставляют сборки, потому что у них нет инфраструктуры / ресурсов.

Это часть философии открытого исходного текста «если хочешь что-то сделать, возьми лопату». Естественно, это снижает нагрузку на разработчиков, если пользователи просто сами компилируют программу. Не нужно беспокоиться обо всех этих архитектурах, ОС и т. Д.

Но если вы создаете продукт потребительского уровня (Firefox, Paint.NET, Audacity, Keepass и т. Д.), И вы заботитесь о привлечении пользователей, вы должны всегда, всегда, всегда! включать двоичные файлы Вероятно, только 2% людей, которые сталкиваются с вашим сайтом и интересуются вашим продуктом, собираются:

• Загрузите соответствующий клиент SCM
• Проверьте всю копию исходного дерева
• Загрузите необходимые инструменты IDE или компилятора (несколько сотен МБ для некоторых проектов)
• Загрузите и установите все необходимые зависимости (и установите переменные среды)
• Запустите новую компиляцию (легко 10-минутный процесс в некоторых проектах)
• Разбираться с любыми ошибками, проблемами или возникающими проблемами (которые в небольших проектах, вероятно, не документированы - «о, да, последние на самом деле переписывают ветвь, а не транк!»)
• Удалите все или оставьте все на своем компьютере и заново скомпилируйте обновления.

(Очевидно, что в Linux все гораздо разумнее, но большинство потребителей все еще используют Windows.)

Новичкам гораздо проще сказать: «О, версия для Windows! Скачайте. Запустите».

Тем не менее, многие проекты с открытым исходным кодом не на потребительском уровне; они нацелены на программистов, которые имеют гораздо более высокую терпимость к такого рода испытаниям, поэтому двоичные файлы являются самостоятельными. По моему опыту, программисты могут быть такими же ленивыми, как и пользователи, поэтому будьте осторожны. :)

Создатели приложений, написанных в среде Write Once Compile Anywhere (C, C ++ и т. Д.), Выигрывают от передачи шага компиляции дистрибьюторам (apt, rpm, yum и т. Д.), Которые создают и упаковывают двоичные файлы для популярных архитектур. Это обеспечивает максимально переносимое приложение с меньшими усилиями со стороны создателей и позволяет им тратить больше времени на то, чтобы сосредоточиться на своей основной компетенции (разработка приложения, а не его компиляция и размещение для нескольких архитектур). Некоторые создатели приложений WOCA готовы платить дополнительные расходы в особых случаях, таких как Windows, потому что, ну, в общем-то, никто этого не сделает, пользователи ожидают этого, и они не хотят отказываться от рынка.

С другой стороны, приложения, написанные в среде Write Once Run Anywhere (Java) или для конкретной целевой архитектуры (например, приложения OS X), могут предоставить один двоичный файл и часто делают это, поскольку им нужно только оплатить компиляцию стоить один раз.

Наконец, их пользователям, как правило, удобно либо строить из исходного кода, либо использовать диспетчер пакетов ОС, поэтому эта модель также обеспечивает удобство использования. Пользователи знают, где взять двоичные файлы (их менеджер пакетов), имеют согласованный опыт установки и управления жизненным циклом пакетов, а также знают, где можно получить исходный код, если он им понадобится.

Почему я хочу использовать пропускную способность, предоставляя вам сборку (которая, очевидно, может быть очень большой), а не сборку источника, который я вам предоставляю в любом случае? Не говоря уже о том, что создание проекта на собственной машине всегда даст лучшие результаты, поскольку оно скомпилировано специально для вашей платформы.

Я могу думать о двух причинах.

Во-первых, у вас есть несколько операционных систем, работающих на разных типах оборудования; количество бинарных целей, которые вы должны построить, становится неуправляемым. Есть три версии Windows, все еще широко используемые (XP, Vista, 7), работающие на 32-битном или 64-битном оборудовании; это 6 двоичных целей прямо там. Ситуация хуже на стороне Linux, с большим количеством разнообразных дистрибутивов, работающих на бог знает, какое оборудование (x86, PPC, MIPS, SPARC, PA-RISC и т. Д.). Собираетесь ли вы строить для каждой возможной комбинации? У вас даже есть оборудование и / или программное обеспечение для этого? Если там еще кто-то работает (да поможет нам Бог) NT на PII, вы собираетесь создать двоичный файл для них?

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

Как правило, ценность проекта с открытым исходным кодом, будь то приложение, система, модуль или библиотека, заключается в том, что он может быть изучен и / или изменен по мере необходимости. Распространение источника является неотъемлемой частью модели публикации.

Распространение бинарного файла сопряжено с риском того, что он каким-то образом был изменен для гнусных целей. Компиляция проекта из источника пытается уменьшить этот риск.

Это может иметь несколько причин. Многие (если не большинство) проектов с открытым исходным кодом начинаются в Linux. Таким образом, первоначальный проект выполнен для этой системы, а упаковка выполняется членами команды.

Создание установщика Windows - это дополнительная работа, требующая знаний, которых нет у разработчиков Linux. Поэтому, если кто-то из основной команды берет на себя эту работу, его часто упоминают специально.

То же самое может быть верно для других систем, таких как OS X или даже определенных дистрибутивов Linux. Все зависит от того, у кого есть знания и время для выполнения дополнительной работы.