Як економічно підтримується розробка програмного забезпечення GNU?

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

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

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

Проблема полягає в тому, що це масштабується вкрай погано для великих програм з наступних причин:

1. Настільки ж цікавим, як і програмування, коли проект, який потрібно реалізувати, стає більшим, час, необхідний для реалізації потрібної функціональності, зростає надзвичайно швидко. Програма більш масштабного масштабу займає неймовірну кількість часу, наприклад, для запрограмування операційної системи людині може знадобитися 15 років вільного часу та відпустки, а до моменту випуску його програмне забезпечення буде повністю застарілим. .
2. Оскільки інші люди пишуть програми іншим способом, як так, як ви це зробили, читання та розуміння чужого коду займає багато часу, в більшості випадків стільки ж, скільки і написання власного коду з нуля. Змінення коду інших людей та спробу його вдосконалити, оскільки це заохочує філософія GNU - це майже стільки ж часу, як і розробка власного клону вказаної програми з функціоналом, який ви хочете додати.
3. Як тільки двом і більше людям доведеться співпрацювати, щоб розробити більшу програму, це створить безліч питань щодо прийняття рішень, які ніколи не виникли б у проекті одного розробника. Результат полягає в тому, що, наприклад, якщо група з 2-х програмістів співпрацює над проектом, який потребує 10 років, щоб створити одного чоловіка, вони не зроблять це через 5 років, але, ймовірно, через 8.
4. Якщо люди, які співпрацюють над тим самим проектом, зустрічаються в Інтернеті виключно в Інтернеті, для одного учасника проекту легко зникнути раптово (або через те, що він втратив інтерес, або через те, що фізично більше не може бути в Інтернеті), завдяки чому співпраця навіть важче

Отже, хоча я прекрасно розумію, як прості програми можуть бути розроблені за допомогою мислення GNU, я абсолютно не бачу, як такі величезні програми, як GNU / Linux або gcc, можливі на цій моделі. gcc становить близько 7 мільйонів рядків коду. Я знаю, що рядки коду не значать багато, оскільки на більш пізньому етапі проекту більш продуктивним програмістом буде той, який фактично видалить рядки коду (спрощення та / або оптимізація проекту), але це дає перегляд того, наскільки масивний проект gcc є.

Тож теоретично кожен може вільно змінювати gcc у вільний час, але на практиці? Його розробляли дуже професійні люди як робота, а не як хобі. Кожен, хто робить компілятор як хобі, врешті-решт відмовиться, оскільки вартість / вигода не вартує цього:

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

Для того, щоб зацікавити людей у ​​розробці такої програми, як GNU / Linux, gcc або Open Office, в довгостроковій перспективі це повинно бути корисним. Отже, моє питання: Чому люди вносять внесок у великий проект GNU, якщо вони не отримують за це зарплату?

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

Для початку хочу сказати, що відкритий код не означає, що ви не можете заробляти гроші на програмному забезпеченні. Це просто означає, що код повинен бути загальнодоступним. Такі компанії, як Red Hat та Canonical, заробляють гроші не продаючи програмне забезпечення, а продаючи свої знання. Якщо я не хочу, щоб моя компанія запускала сервер Linux, я можу отримати програмне забезпечення безкоштовно. Але мені потрібен хтось, щоб його встановити, налаштувати і надати підтримку. Ось тут спеціаліст із Red Red Hat заходить і заробляє гроші. Для компанії це має сенс, адже наймати власного спеціаліста, можливо, буде набагато дорожче. Це також надає цим компаніям стимул внести кодекс. Вони хочуть, щоб їхній продукт був хорошим, щоб люди користувались ним та послугами.

Але давайте поговоримо про ваші моменти щодо масштабованості.

1. Класна річ із відкритим кодом - це те, що не потрібно все розробляти з нуля. Таку операційну систему, як Ubuntu, не створила жодна людина. Натомість багато людей внесли свій внесок у різні частини системи (насправді я думаю, що важко було б знайти одну людину з усіма навичками створення та ефективної операційної системи). Наприклад, люди Ubuntu не розробляють ядро ​​Linux. Вони просто використовують одне, розроблене іншими. Тож те, що було без відкритого коду, мабуть, неможливо, тепер можливо, тому що ви можете будувати роботу інших народів.

2. Читання та розуміння інших кодують це не більше часу, ніж писати своє. Принаймні, не у багатьох випадках. Крім того, ви не повинні розуміти весь код, який ви використовуєте. Якщо я хочу написати програму для Linux, я не повинен розуміти, як детально працюють всі частини цієї програми. Я просто повинен знати, що вони роблять. Потім я можу взяти ці частини і скласти їх разом з іншими частинами, щоб створити свою програму. Або я можу взяти існуючу програму та змінити її для моїх потреб.

3. такі інструменти, як git та github, дозволяють співпрацювати неймовірно просто. Ви просто отримуєте код і вносите зміни. Потім ви надсилаєте їх особі, яка відповідає за проект. Якщо це добре, це буде прийнято.

4. люди весь час заходять у проекти та виходять із них. Але якщо проект буде популярним, над ним буде достатньо працювати.

Ось кілька причин, чому працює відкритий код.

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

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

Якщо вас все ще цікавить, пропоную прочитати Собор та базар

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

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

1. Вони розробляють цю частину самі і вона стає власністю компанії. Або купують рішення із закритим кодом у іншої компанії.
2. Вони знаходять проект з відкритим кодом, який вирішує цю проблему, і це ідеально підходить і ліцензія підходить. Вони просто включають його у свій проект, який може бути або не потребувати відкритих джерел залежно від ліцензії та способу її використання. Вони не сприяють поверненню проекту.
3. Вони знаходять проект з відкритим кодом, який майже вирішує цю проблему, але має або дефекти, або недоліки. Вони вдосконалюються на цьому, і вони можуть внести ці покращення назад в базовий проект.
4. Вони не знаходять нічого, що їм подобається, тому вони починають власний проект і вирішують відкрити його.

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

У своєму поточному проектному проекті я один із 12 розробників і працював над системою близько двох років. Ми включили близько 5000 проектів з відкритим кодом! Ми створили лише декілька нових проектів FOSS та внесли вклад у, можливо, півдесятка. У цьому випадку ми не особливо хороші громадяни (інші компанії набагато кращі), але це показує вам повну шкалу того, як це все працює. Навіть на невеликих проектах внески з відкритим кодом можуть легко налічувати десятки чи сотні. Якби ми не використовували будь-яке програмне забезпечення з відкритим кодом, витрати на розробку збільшилися б у 100–10000.

Масштабованість трапляється через модульність дизайну, а також завдяки цьому виду найвигіднішого процесу виживання, де код може бути відремонтований, роздвоєний тощо. Виживаність, як правило, краща за власні альтернативи, оскільки навіть якщо код більше не підтримується, він існує там, і інші люди, які знаходять в ньому цінність, можуть зберігати свою власну вилку. Компанії приходять і йдуть, а співробітників наймають і ще швидше звільняються. Якщо ви додасте програмну залежність, для якої у вас немає вихідного коду, або у вас є лише невелика внутрішня команда для обслуговування, ви спричинили значні ризики. Такі великі проекти, як ядро ​​Linux, gcc, Android та інші, часто беруть участь у великій кількості компаній.

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

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