Історія розвитку ВПЗ

                                                                                          Зміст

1 Вільні ліцензії

2 Розробка ПЗ як наукове  дослідження

3 Введення обмежень для  ПО

4 Визначення вільного  ПЗ

4.1 Open source software

5 Основна громадська ліцензія GNU

6 Спільнота розробників  і користувачів

6.1 Взаємодопомога

6.2 Виправлення помилок

7 Філософія

8 Міграція на вільне  ПЗ

9 Поширеність вільного  і відкритого ПЗ

12 Посилання

Історія розвитку ВПЗ

У 50-70-х роках ВПЗ було звичним явищем для користувачів. Воно запросто поширювалось користувачами, котрі мали доступ до комп'ютерів та фірмами-виробниками, котрі раділи, що люди пишуть програми, котрі роблять роботу з їхніми пристроями зручнішою. В 70-х - на початку 80-х років компанії почали обмежувати ці свободи, захищати розроблені програми копірайтами та поширювати лише бінарні коди програм, щоб ускладнити або унеможливити вивчення та модифікацію програм.

У 1983 році Річард Столмен заснував проект GNU після того, як безпосередньо зіткнувся зі змінами у культурі користувачів та комп'ютерної індустрії в цілому. Розробка ПЗ для операційної системи GNU розпочалась у січні 1984 року, а Фонд Вільного Програмного Забезпечення (англ. Free Software Foundation, FSF) був заснований у жовтні 2005 року. Він ввів визначення ВПЗ та термін «copyleft» (буквально «авторське ліво») на противагу «copyright» («авторське право»)для позначення ВПЗ.

ВПЗ — це потужна міжнародна співпраця по написанню програм, котрі використовуються окремими людьми, великими організаціями та урядовими  структурами. ВПЗ має величезну  вагу на ринку серверів та інтернет-служб, як, наприклад, веб-сервер Apache, СКБД MySQL та мова сценаріїв PHP. Повністю вільні комп'ютерні середовища доступні у вигляді величезних пакунків базових програм у складі дистрибутивів GNU/Лінукс та ОС FreeBSD. Розробники ВПЗ також створили вільні версії практично всіх поширених стільничних програм, як от веб-оглядачі, офісні пакети та мультимедійні програвачі. Важливо також зауважити, що в багатьох випадках ВПЗ для окремих робочих станцій чи домашніх користувачів — лише частина більших власницьких пакетів. Більшість ВПЗ поширюється безкоштовно через інтернет або звичайними способами за символічну плату; проте це не є обов'язковою вимогою і будь-хто може продавати його за будь-яку ціну.

Економічні вигоди моделі ВПЗ були розпізнані такими великими корпораціями як ІВМ, Red Hat та Sun Microsystems. Багато компаній, чий ключовий бізнес лежить за межами ІТ-сектору, вибирають ВПЗ для представництва в інтернет, для офіційних сайтів завдяки низькій собівартості та можливості вільно змінювати пакунки програм.

 
Вільне програмне забезпечення (ВПЗ , англ. Free software , також software libre або libre software ) , вільний софт - програмне забезпечення , щодо якої права користувача ( «свободи» ) на необмежену установку , запуск , а також вільне використання , вивчення , поширення і зміна (вдосконалення ) захищені юридично авторськими правами за допомогою вільних ліцензій або на це програмне забезпечення немає виняткових прав .

Як і безкоштовне ( freeware ) і безкоштовно розповсюджується програмне забезпечення , ВПЗ можна отримувати і використовувати безкоштовно (але конкретний розповсюджувач може стягувати плату за отримання у нього копій , за канали доставки , носії - компакт -диски або додаткові сервісні послуги). Однак freeware зазвичай поширюється в Исполнимости вигляді без вихідних кодів і є пропрієтарним ПО , а щоб ПЗ було вільним , одержувачам повинні бути доступні його вихідні коди , з яких можна створювати виконані файли , з відповідними ліцензіями . Також слід розрізняти вільне і відкрите ПЗ ( open source ) - хоча доступність вихідного коду для ВПЗ є обов'язковим, а багато відкриті програми є одночасно вільними , але відкритим іноді називають [ хто?] І деякий невільне пропрієтарне ПЗ ( наприклад , комерційне ПЗ з відкритим вихідним кодом , Shared source ) .

Бізнес-моделі ВПЗ , як правило, засновані на принципі розширення можливостей - наприклад , нові об'єкти застосування , навчання , інтеграція , настройка або сертифікація . У той же час , деякі бізнес - моделі , які працюють з пропрієтарним програмним забезпеченням , не сумісні з вільним програмним забезпеченням , особливо ті , які змушують користувачів платити за ліцензію , щоб законно використовувати програмний продукт.

Вільні ліцензії

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

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

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

Розробка ПЗ як наукове дослідження 

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

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

Однак технологія виробництва комп'ютерів розвивалася не менш активно , ніж  програмне забезпечення для них. У 1970 -ті роки існувало величезна різноманітність  різних архітектур обчислювальних машин , розрізнялися також продуктивністю і ціною . Природно , для кожної архітектури  доводилося розробляти окремий набір  програмного забезпечення. З середини 1970-х у більшості американських  університетів для академічних  розробок використовувалися комп'ютери  архітектури PDP - 10 , що дозволяло співробітникам різних університетів використовувати  розробки один одного на своїх машинах. Співробітники лабораторії штучного інтелекту Массачусетського технологічного інституту ( MIT) в кінці 1970 - х розробили  для PDP - 10 власну операційну систему ITS ( Incompatible Timesharing System - несумісна система  з поділом часу) і дуже великий  набір програм для неї. Вихідні  тексти написаних в MIT програм були загальнодоступні , співробітники інших  університетів користувалися їх вихідними текстами і надсилали їм виправлення , все програмне забезпечення в цих лабораторіях було повністю академічним .

Введення обмежень для ПО

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

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

Щоб захистити свої інтереси , виробники  комп'ютерів та програмного забезпечення використовують ліцензії - вид договору між володарем авторських прав і  користувачем (покупцем ) програмного  забезпечення . Подібні договори укладалися і з університетами : наприклад , університету передавалися вихідні  тексти програм і право їх змінювати , але заборонялося поширювати їх за межами університету. Подібні обмеження  означали , що тексти відповідних програм  не могли відкрито обговорюватися в  співтоваристві , тобто не існували для наукової розробки. Були у комп'ютерів та програмного забезпечення покупці  і поза академічного середовища - наприклад , банки. Таким користувачам не настільки  важливо отримати вихідні тексти програм , вони зацікавлені в програмному забезпеченні як в закінченому продукті і готові платити гроші за надійні та зручні програми .

Однак комп'ютери розвивалися дуже швидко , і колишні цілком сучасними  в 1970-і PDP - 10 до початку 1980 - х вже застаріли  і значно відставали по продуктивності від більш сучасних машин. Проте  ні для однієї з нових архітектур вже не було операційної системи  та іншого програмного забезпечення , розробленого виключно в академічному середовищі і за її правилами . Тепер  університети повинні були купувати нові комп'ютери з новим програмним забезпеченням і виконувати умови  ліцензії , що обмежує їх права на розробку та розповсюдження ПЗ - інакше кажучи , обмежує можливість наукової моделі розробки та розповсюдження програмного  забезпечення.

У цей час у лабораторії штучного інтелекту MIT розроблялися звані LISP -машини , що вміли на апаратному рівні інтерпретувати мову програмування , схожий на LISP - розвинений і перспективний мова програмування . На LISP ж була написана операційна система  для таких машин і все програмне  забезпечення для них. На початку 1980- х деякі співробітники лабораторії  штучного інтелекту викупили у MIT права  на LISP -машини і математичну систему Macsyma і заснували власні комерційні компанії для подальшої розробки в цій області. Дуже багато співробітників лабораторії перейшли працювати  в ці компанії , після чого всі  їхні подальші розробки вже ставали  закритими для наукової спільноти . Нові LISP -машини поширювалися з ліцензіями , що забороняють користувачам модифікувати і поширювати вихідні тексти програм. Програми , які раніше для співробітників MIT були аналогом наукових публікацій , стали належить комусь патентованим продуктом.

Річард Столлман , засновник руху вільного ПЗ. 

Одному зі співробітників , що залишилися в лабораторії штучного інтелекту MIT , Річарду Столлманом , такий стан справ здавалося неприпустимим  порушенням відкритого наукового процесу  розробки програмного забезпечення. Він наодинці намагався в рамках колишньої академічної моделі розвивати LISP -машини і відкрито реалізовувати  зміни , аналогічні зробленим у рамках закритої комерційної розробки , щоб LISP -машини MIT могли конкурувати з  патентованими аналогами . Звичайно , ця спроба наздогнати активною розробкою  цілої компанії була приречена на невдачу.

Тоді в пошуках однодумців Річард Столлман створює некомерційну організацію  « Фонд вільного програмного забезпечення ». Своєю основною метою Фонд ставить  збереження програмного забезпечення , процес розробки якого завжди буде гарантовано відкритим , а вихідні  тексти завжди доступні. Більш масштабна  мета Фонду - розробка операційної системи , цілком складається з відкрито розроблюваного програмного забезпечення. Декларуючи таку мету , Столлман , фактично , хотів повернути представлявшееся йому ідеальним стан , коли в MIT працювали  у власній операційній системі  для PDP -10.

Операційна система , що розробляється  в рамках Фонду , повинна була стати  сумісної з операційною системою UNIX. До початку 1980 - х UNIX дуже широко використовувався , в тому числі і в академічному середовищі . Для цієї операційної  системи існувало багато програм , вільно поширювалися в науковому співтоваристві , тому хотілося , щоб ці програми працювали  і в новій - вільної - операційній  системі . Ця майбутня операційна система  отримала назву GNU.

Фонд вільного ПЗ раніше ділив невільне на напіввільне ( таке , яке відрізняється  від вільного лише забороною на комерційне використання ) і пропрієтарне ( власницьке , англ. Proprietary ) (яке не має всіх чотирьох свобод , навіть якщо комерційне використання дозволено) .

На відміну від власницького , напіввільне ПО згадується рідко. Іноді до невільного ПЗ відносять  і всі « комерційне ПЗ », вважаючи вільне ПЗ видом безкоштовного , однак  це невірно: отримувати вигоду від програми можна не тільки продажем невільних  ліцензій . 

Визначення вільного ПЗ

Для того щоб зберегти модель наукового  співробітництва між розробниками , необхідно було забезпечити , щоб  вихідні тексти програм , написаних  розробниками , залишалися доступними для читання і критики всьому науковому співтовариству зі збереженням  авторства творів. Для цього Річард Столлман сформулював поняття вільне програмне забезпечення , в якому  відбилися принципи відкритої розробки програм в науковому співтоваристві , що склалося в американських університетах  в 1970- і роки. Столлман явно сформулював  ці принципи , вони ж - критерії вільного програмного забезпечення. Ці критерії обумовлюють ті права , які автори вільних програм передають будь-якому користувачеві :

Програму можна вільно використовувати  з будь-якою метою ( « нульова свобода  »).

Можна вивчати , як програма працює, і  адаптувати її для своїх цілей ( «  перша свобода »). Умовою цього  є доступність вихідного тексту програми .

Можна вільно поширювати копії програми - на допомогу товаришу ( «друга свобода  »).

Програму можна вільно покращувати  і публікувати свою поліпшену  версію - з тим , щоб принести користь  всьому співтовариству ( «третя свобода  »). Умовою цієї третьої свободи є  доступність вихідного тексту програми і можливість внесення до нього модифікацій  і виправлень.

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

Тільки задовольняє всім чотирьом перерахованим принципам програма може вважатися вільної програмою , тобто гарантовано відкритою  і доступною для модернізації та виправлення помилок і дефектів , і не має обмежень на використання та поширення. Потрібно підкреслити , що ці принципи обумовлюють тільки доступність  вихідних текстів програм для  загального використання , критики  і поліпшення , і права користувача , що отримав здійсненний або вихідний код програми , але ніяк не обумовлюють  пов'язані з поширенням програм  грошові відносини , в тому числі  не припускають і безоплатності . В англомовних текстах тут  часто виникає плутанина , оскільки слово « free » по-англійськи означає  не тільки «вільне » , а й « безкоштовне» , і нерідко вживається стосовно безкоштовному програмному забезпеченню , яке поширюється без справляння плати за використання , але недоступне для зміни користувачами і співтовариством , тому що його вихідні тексти не опубліковані. Таке безкоштовне ПЗ зовсім не є вільним. Навпаки , вільне ПЗ цілком можна поширювати (і поширюють ) , стягуючи при цьому плату , однак дотримуючись при цьому критерії свободи: кожному користувачеві надається право отримати вихідні тексти програм без додаткової плати ( за винятком ціни носія) , змінювати їх і поширювати далі. Всяке програмне забезпечення , користувачам якого не надається такого права , є невільним - незалежно від будь-яких інших умов. 
Open source software

Відкритий доступ до вихідних текстів  програм є ключовою ознакою вільного ПЗ , тому запропонований дещо пізніше  Еріком Реймондом термін open source software ( ПО з відкритим вихідним текстом) деяким представляється навіть більш  вдалим для позначення даного феномена , ніж спочатку запропонований Столлманом « free software ». Столлман наполягає на відмінності  цих двох понять , оскільки слова open source вказують лише на наявність одного , чи не найважливішого (хоча і необхідного  для реалізації двох з чотирьох свобод ) , на його думку , з властивостей , притаманних  вільному ПЗ - можливості побачити вихідний код.

Хоча різні формальні визначення вільних і відкритих творів зазвичай багато в чому збігаються для ПО , вираження open source і « відкрите програмне  забезпечення » в окремих випадках використовується [ ким?] Для пропрієтарного ПЗ , які не підходящого ні під  одне з них (наприклад , комерційне ПЗ з відкритим вихідним кодом) .  
Основна громадська ліцензія GNU

Логотип GNU GPLv3

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

Річард Столлман займався розробкою  текстового редактора Emacs на основі вихідних текстів Джеймса Гослінга . Тоді Гослінг вільно роздавав свої вихідні  тексти всім зацікавленим . Проте в  якийсь момент Гослінг продав права  на розповсюдження Emacs компанії UniPress [ 5] , і ця компанія попросила Столлман припинити поширення його версії Emacs , так як права належать їм. [ Стиль! ] Цей інцидент змусив Столлман переписати заново ті частини початкового тексту Emacs , які тепер належали UniPress , після  чого він розробив власну ліцензію на своє програмне забезпечення .

Ліцензія , сформульована Столлманом , повинна була працювати так само , як і ліцензії на невільне програмне  забезпечення : це типовий договір  автора програми ( власника авторських прав) з користувачем , у якому  автор , серед іншого , обумовлює  права користувача по відношенню до програми . На відміну від типової  власницькою ліцензії , ліцензія Столлман надає користувачеві права , які  є критеріями вільної програми : отримувати вихідні тексти програм , змінювати їх , поширювати змінені, і незмінені версії. Згодом ліцензія Столлман отримала назву GNU General Public License ( «Основна громадська ліцензія GNU "), скорочено GNU GPL або просто GPL.

У цій ліцензії обмовляється також  принципове для Столлман захисне  умова поширення вільного ПЗ: жоден  користувач , який зробив модифіковану версію вільної програми , не має  права поширювати її , не дотримуючись всіх принципів вільного ПЗ , тобто  робити модифікацію вільної програми невільною . Щоб підкреслити відмінність  такої ліцензії , яка використовує ЗоАП ( copyright ) для спонукання до збереження свободи , від типових власницьких  ліцензій , які використовують ЗоАП для обмеження свободи , був придуманий термін copyleft ( копілефт ) - гра слів , побудована на значеннях англійських  слів right і left . Дія копілефту засноване  на тому , що похідні роботи в більшості  випадків успадковують ліцензії своїх  складових; якщо в програмі використовується невелика частина стороннього коду під GPL , то вся програма і її похідні  повинні поширюватися під GPL , поки вони є похідними цього коду . При  цьому в GPL є розділ, що дозволяє вимагати збереження в коді імен авторів , забороняти використання цих імен в рекламі , попереджати про зареєстровані  товарні знаки і т. п. , що дозволяє комбінувати роботи під GPL з роботами під багатьма вільними некопілефтнимі ліцензіями (наприклад , деякими з  ліцензій BSD ) , не створюючи значних  обмежень і не порушуючи ліцензії , - але похідні від результату , будучи похідними від роботи під GPL , вже не можуть (без окремого дозволу  правовласників ) поширюватися на умовах даної некопілефт - ліцензії без  дотримання умов GPL - у тому числі  і як невід'ємна частина невільного ПЗ. З цієї причини ліцензії , подібні GNU GPL , іноді називають також «  вірусними ліцензіями » : вони ніби « заражають » програму , стаючи її невід'ємною частиною. 
Спільнота розробників і користувачів

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

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

Користувач вільно поширюваної програми не отримує  разом з нею ніяких гарантій : автор зробив її вихідний текст відкритим  для суспільства , але при цьому  не взяв на себе зобов'язань пояснювати всім , як працює програма. Хоча справедливості заради варто помітити , що будь-яка  невільна програма в 99 % випадках теж  поставляється «як є» і без  гарантій. Оскільки спільнота користувачів більшості програм розподілено  по всьому світу , для організації  взаємодії в ньому найбільш активні  користувачі ( а часто і самі автори ) організують (рідше - використовують існуючі ) списки розсилки , форуми та інші засоби спілкування в Інтернеті. Для накопичення і рубрикації інформації по програмі ( зокрема , списків  часто ставляться ( ЧаВо ; англ. FAQ - frequently asked questions ) , а також організації  більш складних форм взаємодії ( спільної розробки , систем відслідковування помилок ) створюються веб - сайти , присвячені програмам. 
Виправлення помилок

У будь-який досить складною програмою неодмінно  є помилки і дефекти , кількість  яких звичайно невідомо. Багато великих  виробники ПЗ створюють і оплачують  роботу відділу контролю якості ( QA - Quality assurance ) , який контролює відповідність  процесу розробки ПЗ певним вимогам , виконання яких дозволяє знизити  ймовірність появи помилок в  ПЗ (наприклад , вимогам стандарту DO - 178B , який застосовується при розробці ПЗ для авіаційних систем). Тим не менш, у даний час відсутні методи, що дозволяють повністю гарантувати  відсутність помилок в досить складному ПЗ ( існують формалізовані  критерії складності ПЗ).

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

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

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

Діагностика помилки , що сталася на комп'ютері  користувача , - завдання не з легких , оскільки у співробітників служби підтримки ( і тим більше програмістів фірми) немає доступу до цього  комп'ютера. Тому відділами підтримки  широко практикуються програми , що видають різноманітну інформацію про  комп'ютер користувача , а в складних випадках і горезвісна налагоджувальна  інформація (співробітник просить користувача  прогнати програму в « діагностичному режимі» (як правило , за допомогою недокументованою налаштування , або користувачеві  надсилається отладочная версія потрібного модуля ) і відправити йому отриманий  файл звіту) .

У типовою  вільної програми ( тобто , некомерційною  і / або розроблюваної невеликою  компанією або приватною особою ) зазвичай немає оплачуваної відділу  контролю якості. Значить , користувач може зіткнутися з ще більшою кількістю  помилок , ніж в типовій комерційної  проприетарной програмі . Тим актуальніше  для нього можливість повідомити про помилку розробникам програми . Раніше в супроводжує програму документації було прийнято вказувати  електронну адресу, за якою розробники брали повідомлення про помилки ( bug report ) . Деякі вводили стереотипну  форму для таких повідомлень , щоб полегшити і автоматизувати їх обробку . Вже це вимагає істотно  більш високою зв'язності сообщества в усьому світі , істотно більшою , ніж достатньо для закритої розробки.

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

Простому  та впорядкованому прийому та перенаправлення  повідомлень про помилки служать  системи відслідковування помилок ( bug tracking system ) , найвідоміші з яких розроблені учасниками великих проектів для себе , а завдяки вільними ліцензіями використовуються повсюдно . Такі GNUTS ( розроблена в GNU ) , Bugzilla ( Mozilla Foundation ) , JitterBug (проект Samba ) або Debian BTS . Більш  ранні версії орієнтуються на електронну пошту , пізніші включають в себе web -інтерфейс. Наприклад , за допомогою Bugzilla організується сайт в Інтернеті , на якому користувач може заповнити  форму повідомлення про помилку . Кожне повідомлення має свій номер , за яким можна потрапити на «  персональну » сторінку даної  помилки , де відображаються всі відбуваються з її приводу події , від первісного повідомлення ( відкриття ) до виправлення ( закриття). При кожній зміні в  стані помилки Bugzilla розсилає всім зацікавленим особам (включаючи , природно , що повідомив  про помилку і займаються даною  програмою розробників ) листи електронною  поштою . Оскільки Bugzilla дозволяє залишати коментарі і прикладати файли , вона є повноцінним засобом для  спілкування користувача з розробником  з приводу помилки в програмі.

Принципова  перевага користувача вільної програми полягає в тому , що у нього , на відміну від користувачів невільних  програм , завжди є можливість заглянути  в вихідні тексти . Звичайно , для  багатьох користувачів вихідні тексти не більше зрозумілі , ніж машинний код . Однак при достатньому рівні  пізнань в програмуванні користувач може сам встановити причину помилки  в програмі , а то й усунути  її , виправивши відповідним чином  вихідний текст . А якщо користувач зацікавлений у розвитку програми , то з його боку буде розумно не лише повідомити автору про помилку , а  й надіслати йому свої виправлення  до вихідного тексту програми : автором  залишиться тільки застосувати ці виправлення  до тексту програми , якщо він знайде їх коректними і доречними. Пересилати автору виправлений текст програми цілком непрактично : він може бути дуже великим (десятки тисяч рядків ) , і автору буде нелегко розібратися , що ж змінено (а раптом зміни  зроблені неграмотно ?) .

Щоб полегшити  і автоматизувати процес внесення виправлень , Ларрі Уолл в 1984 році розробив утиліту patch ( « латочка » ) , яка у формалізованому (але добре зрозумілому людині ) вигляді описує операції редагування , які потрібно провести , щоб отримати нову версію тексту. З появою цієї утиліти  користувач , виявити і виправити  помилку в програмі , міг надіслати  автору невелику латочку , за якою автор  міг зрозуміти , які зміни пропонуються , і автоматично « докласти »  їх до свого вихідного тексту. З  появою утиліти patch набагато більше користувачів стало включатися в розробку програм  з доступним початковим текстом , чималу роль і тут зіграла мережу Usenet . Зрештою , даний спосіб виправлення став загальновживаним і применяющимся не тільки до вихідного коду програми , але і безпосередньо до скомпілювати исполнимости кодом у разі закритого ПЗ , а слово « патч » стало прозивним. Патчі ( файли - заплатки з виправленнями ) - обов'язковий атрибут сьогоднішньої розробки будь-яких програм будь-якої складності .