Feel the source
Серпень 2nd, 2008
Переклад Feel the source з Linux Haters Blog
Переважна більшість FOSS натовпу вважає, що розповсюдження вихідного коду є чимось надзвичайно добрим. Натомість, я впевнений, що не все так чудово. Концепція OSS, що закликає до розповсюдження усього програмного забезпечення лише у вихідних кодах має кілька підводних каменів, про які зазвичай не згадують.
Перше і найголовніше, модель OSS змушує розробників проектів наступних рівнів приймати рішення, які мали б прийматись на попередніх етапах. Що це за рішення? Наприклад, який компілятор використовувати? які опції вказати при компіляції? які версії бібліотек використати при лінкуванні? Під час збирання ПЗ для подальшого розповсюдження виникають сотні подібних питань. Логічно було б, якби такі рішення приймались людьми, що писали той код, тобто розробниками вищих рівнів. Але, в інноваційному лінуксовому світі такі рішення приймаються на нижчому рівні, мейнтейнерами пакунків у дистрибутивах. Тими людьми, яким не відомо достеменно, як працює код, проте вони вміють збирати rpm’и. Навіть якщо вони щось таки дізнавалися про код, все одно розробники знають більше. Проте все одно саме збирачі пакетів приймають критичні рішення, від яких залежить швидкодія та стабільність кінцевого продукту. Це не свобода вибору. Це свобода якимось людям перевернути все догори дригом.
Друге. Розповсюдження вихідних кодів зменшує ефект тестування на вищому рівні. Будя-який тестер скаже вам, що різні бінарні файли мають мати різні сценарії тестування. У кожному нижчому проекті виправляють код програми, або просто компілюють його у інший спосіб. В результаті фактично утворюється ще одна гілка вихідного коду. Такі дії потроху розчиняють результати тестування вищого рівня. Навіт дурням зрозуміло, що це призводить до проблем. У очевидних випадках це закінчується катастрофою, подібною тій, яку мав Debian з OpenSSL. А іноді ви можете просто отримати купу багрепортів від юзерів, бо при компіляції вами було використано опцію, яку розробники не тестували. Або у вашому дистрибутиві використовується інша версія бібліотеки, ніж та, що була у розробника на момент відправлення коду до svn. Вони вважають, що вільне ПЗ буде кращим за рахунок глобального тестування розданного коду. Насправді, кожен тестує свою, трохи відмінну версію бінарну версію програми. Надзвичайна кількість варіантів зводить нанівець ефект від того тестування.
Водночас, вільне розповсюдження спричинює дублювання зусиль на нижчих рівнях. Кожний дистрибутив робить все по-своєму, але напевно всі вони стикаються з одними й тими самими проблемами. Який компілятор обрати? яку версію бібліотеки використати? Які версії частин надійно запрацюють у цілому проекті? Сотні дистрибутивів не тільки не діляться досвідом з інтеграції, вони дійсно багато дублюють дії одне одного. Результати цієї надзвичайної роботи не можуть бути використані повторно, тому що різні дистри мають різні конфігурації. Надзвичайне марнування. Як ви гадаєте, чому, попри зростання числа користувачів і тестерів Лінуксу, якість дистрибутивів не зростає так само? Кожен новий дистрибутив лише докладає зусиль до вже змарнованих, повторюючи все те, що вже було зроблено. Але ж, вся та робота є безплатною, чи не так?
З погляту розробників, теж не все прекрасно. Хіба може так бути? Тобто, розробники ж люблять вихідний код, чи не так? Хм, добре, що ви запитали.
Що є типовим для всіх OSS-бібліотек, так це відсутність нормальної документації. Та біс з ним, кажуть нам розробники, ви ж завжди можете переглянути вихідні коди. Для того, хто зазвичай сам не програмує, може, це звучить і нормально. Кому треба та документація, коли по коду й так видно, що він робить?
Не вірно, на жаль.
Забудемо про те, що сама ідея читати код для того, щоб дізнатися, що він робить – відстійна. Є і інша проблема: код, на відміну від документації по API, занадто специфічний. Коли розробник може бачити реалізацію інтерфейсу, він може легко почати писати код, залежний від тієї реалізації, від її конкретних особливостей (досить часто це особливості, на які розробник інтерфейсу не звертав уваги). Вихідний код “перевизначає” API. Найгірше, коли розробники починають залежати від багів (_відмітимо, відсутність вихідного коду ще не гарантує, що розробники не будуть спиратися на баги при написанні свого коду. Маємо багато прикладів зі світу Win32. Втім, коли вихідний код перед очима, такі помилки робити набагато легше_)
Інша остогидла проблема. Як розробникам компенсувати витрачені кошти, коли все “зароблене важким трудом” віддається задаром? Питання заговорили досмерті на всіх форумах, проте все його варто згадати. Так, ви всі тут постійно мені розказуєте про Google, що заробляє трохи грошенят на вільному ПЗ. Але знаєте що? Вони не продають програмне забезпечення. Якою буде бізнес-модель, якщо ваша мета – продавати чисте ПЗ кінцевим користувачам? Зара хтось може згадати RedHat, але спершу спробуйте порівняти прибутки RadHat та Microsoft. Вони формально приносили прибуток, але це дуже, дуже мало, порівняно з тими компаніями, які продають програми.
Останнє. Той факт, що вікриті проекти розповсюджують свої вихідні коди, лише поглиблює та розтягує всі проблеми, згадані вище. Якщо б OSS проекти розповсюджували бінарні файли, стало б очевидно, в якій глибокій дупі вони знаходяться (і, може, вони б спробували б якось виправити ситуацію). І якби OSS-розробники змогли б показати, що вони можуть координувати свої зусилля і випускати бінарні файли, тоді б до них приєдналися б і комерційні компанії, і всім було б добре. Але щось я замріявся.
Ще варто сказати, що я зовсім не проти розповсюдження відкритого коду. Це корисно для виправлення багів, і для координації покращень в коді вищого рівня. Але занадто багато тупих фанів просто відкидають ідею розповсюдження програм у бінарній формі як таку. Це дурня і невігластво.
Категорії: Linux Hate | Теґи:FOSS, linux, OSS
