Чому деякі бібліотеки з відкритим кодом не надають бінарних файлів?

Чому деякі бібліотеки з відкритим кодом не надають бінарних файлів? Я помітив, що деякі проекти відкладаються стороннім особам, які підтримують поточні версії програмного забезпечення, особливо для версій 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) або для конкретної цільової архітектури (наприклад, програми X X), можуть забезпечити єдиний бінарний файл і часто це роблять, оскільки їм потрібно платити лише за компіляцію вартість одного разу.

Нарешті, їхнім користувачам зазвичай зручно або будувати з джерела, або використовувати їх менеджер пакетів ОС, тому ця модель також забезпечує кращу зручність використання. Користувачі знають, де отримати бінарні файли (їх менеджер пакунків), мають послідовний досвід встановлення та управління пакетами, і знають, де придбати джерело, якщо вони знадобляться.

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

Я можу придумати дві причини.

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

По-друге, джерело доставки означає, що користувачі можуть оптимізувати збірку для свого конкретного середовища; вони можуть увімкнути будь-які оптимізації, які вам потрібні, або налаштувати джерело, якщо це необхідно.

Зазвичай цінність проекту з відкритим кодом, будь то додаток, система, модуль або бібліотека, полягає в тому, що його можна вивчити та / або змінити за потреби. Розповсюдження джерела є суттєвим для видавничої моделі.

Розповсюдження бінарного файлу ризикує його змінити певним чином для недобрих цілей. Складання проекту з джерела намагається зменшити цей ризик.

Це може бути кілька причин. Багато (якщо не більшість) проектів з відкритим кодом починаються в Linux. Отже, початковий проект робиться для цієї системи, а упаковка виконується членами команди.

Створення інсталятора Windows - це додаткова робота, яка потребує знань, яких розробники Linux можуть не мати. Тож якщо хтось із зовнішньої команди бере на себе цю роботу, його часто згадують спеціально.

Це може бути справедливо і для інших систем, таких як OS X або навіть певних дистрибутивів Linux. Все залежить від того, хто має знання та час, щоб виконати додаткову роботу.