Мотиви розкриття вихідного коду

Більшість користувачів вважають за краще завантажувати готові бінарні збірки, ігноруючи наявність вихідних текстів.

Ринок вже давно все розставив по місцях, довівши, що у масового користувача немає ніякої потреби у вихідних текстах - принаймні, у світі Windows, але ні зараз працює проект ReactOS. Мета якого зробити клон Windows та відкрити вихідний код даної ОС. Але цікаво що вони цим досягнуть?... Строкатість UNIX-подібних систем вимагає створення безлічі бінарних збірок, а розробникам займатися збірками лінь. Набагато простіше викласти вихідні тексти і нехай кожен користувач самостійно компілює їх під свою платформу.

Коротше кажучи, на споживчі властивості масового продукту розкриття вихідних текстів ніяк не впливає. Проте, прихильники руху Open Source стверджують, що:

· Маючи вихідні тексти на руках, користувач може переконатися, що в програмі немає закладок, дір та інших помилок. Іншими словами, користувач може провести аудит безпеки або замовити його сторонній фірмі.

Так, дійсно, навколо великих проектів - таких, наприклад, як Ubuntu, утворилося ціле співтовариство шанувальників, серед яких є як експерти, так і новачки, що займаються пошуком помилок з чисто спортивного інтересу або в якості демонстрації сили свого інтелекту. Однак відкритість проекту ніяк не пов'язана з кількістю наявних у ньому дірок. Взяти хоча б відкритого Firefox'а і порівняти його із закритою Оперою. Алгебраїчне зростання критичних помилок, виявлених у FireFox'і за останній час, доводить, що якість коду визначається виключно професіоналізмом його творців.

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

Ха -ха- ха! Який відсоток користувачів здатний грамотно описати умови, при яких виникає помилка? А отже щоб її усунути, однієї лише кваліфікації недостатньо. Тут ще потрібно розібратися в структурі вихідних текстів, а це вимагає часу, причому дуже значного. Чи не краще доручити виправлення помилок самим розробникам? Що ж до нових можливостей... Ну, добре припустимо, розібравшись, який рядок за що відповідає, ми додали необхідну нам функціональну можливість в програму, змінивши при цьому десяток файлів в сотні місць. Ми відправляємо виправлені вихідні тексти координатору проекту, але нас відправляють назад, оскільки вже давно вийшла нова версія і нікому нецікаво переносити всі зміни зі старої, до того ж така функціональна можливість на його думку не потрібна, та й реалізована вона занадто криво, нестабільно і взагалі ідеологічно неправильна. Якщо наші зміни не будуть прийняті і включені в основний проект, це означає, що ми намертво прив'язуємо себе до своєї власної версії.

Насправді, для розширення функціоналу програми досить реалізувати механізм плагінів або вбудовану скриптову мову. Відладчик OllyDbg поширюється без вихідних текстів, але для нього написано величезну кількість плагінів, які не прив'язані до якоїсь однієї конкретної версії і можуть поширюватися як за офіційними, так і по незалежними каналами.

· Вихідні тексти служать гарантом, що автор програми несподівано не виїде до США і проект, позбавлений підтримки, не помре, вдаривши по всіх його користувачах.

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

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

Дата добавления: 2015-11-14