Уявіть, що ви супроводжуєте широко використовуваний проект із відкритим кодом, на який покладаються розробники з усього світу. Бути супроводжувачем означає, що ви можете вирішувати, які внески зовнішніх учасників приймати. Тепер є два внески. Один від окремого учасника та один від людини, яку ви знаєте, що працює в певній компанії. Ви знаєте, що окремий учасник працював над кодом, який вони вносять у свій вільний час, і вам дуже подобається якість його роботи. Інший внесок також має високу якість. Чи ставилися б ви до цих внесків інакше? Ви повинні?
Технічно обидва вони є лише особами, які додають код. Але чи можете ви справді ігнорувати той факт, що один учасник належить компанії, чи ви навіть приписуєте їхній внесок переважно цій компанії? Нещодавнє опитування Linux Foundation показало, що організації щорічно вносять 7,7 мільярда доларів США в проекти з відкритим кодом, і що 86% цього внеску здійснюється у вигляді праці окремих людей. Мене цікавить роль, яку відіграють особисті особи та компанії у внеску з відкритим кодом.
Щоб дослідити тему, я спершу надам довідкову інформацію про програмне забезпечення з відкритим кодом і огляд теорії ідентичності як на індивідуальному, так і на спільному рівнях. Потім я розглядаю природу індивідуальних внесків в OSS, їх мотивацію та роль спільноти та меритократії. На противагу цьому я досліджу, як і чому компанії роблять внесок у OSS, і порівню це з окремими внесками та внесками громади. Порівнюючи їх, я потім виявляю ключові проблеми та напруження між окремими учасниками та компаніями. Використовуючи представлену раніше теорію організаційної ідентичності, можна отримати деякі цікаві ідеї. Потім я хочу навести кілька практичних прикладів, які я бачив, працюючи в ROS.
Контекст: програмне забезпечення з відкритим кодом, теорія ідентичності
Відкритий вихідний код у своїй базовій формі означає, що вихідний код частини програмного забезпечення є вільно доступним для будь-кого, щоб аналізувати, змінювати або ділитися. На практиці існують різні ліцензії, які публікуються разом із вихідним кодом, кожна з яких має певні пов’язані з ними права та обов’язки. Але це не те, про що я сьогодні буду говорити. Що робить відкритий код таким потужним, так це те, що цей вільний доступ до вихідного коду дозволяє справді відкрито співпрацювати. Ерік С. Реймонд описав це у двох контрастних моделях розробки програмного забезпечення «Базар» і «Собор». Тут Bazaar означає спосіб розробки програмного забезпечення в проектах з відкритим кодом: відкрито та спільно, з багатьма учасниками. З іншого боку, модель Cathedral символізує класичну розробку програмного забезпечення: закриту в рамках комерційних проектів розробки кількома експертами. Реймонд стверджує, що модель Bazaar більш ефективна для створення надійного та інноваційного програмного забезпечення.
З міркувань прозорості я хочу заявити, що на мій аналіз цих тем вплинув головним чином мій особистий досвід роботи в одному проекті з відкритим кодом, а саме ROS, операційній системі роботів. Це дивовижний фреймворк для створення роботів, але його технічні деталі не будуть актуальними для цієї статті.
Перш ніж далі досліджувати проекти OSS, я хочу представити інструмент для цього дослідження: identity . Загалом кажучи, ідентичність – це відношення суб’єкта до самого себе 4 . Локк чітко дав зрозуміти, що саме свідомість забезпечує особисту ідентичність . Цю свідомість можна розширити до минулих дій або думок. Хоча це фундаментальний будівельний блок для ідентичності, сам по собі він не допоможе пояснити, що мене цікавить.
Більш сучасний погляд - соціальна ідентичність . Це «уявлення людини про те, ким вона є, на основі її членства в групі» 7 . Знання цього може дати людям відчуття приналежності, мети, власної гідності та, що важливо, ідентичності. На практиці ці групи можна визначити за будь-яким принципом: від етнічної приналежності чи релігії до професійної приналежності чи музичних уподобань. Це також може пояснити аспекти того, як особистості людей базуються на тому, що вони працюють у компанії. Однак у мене є останній розділ, присвячений корпораціям.
Коли компанії називають себе, це називається організаційною ідентичністю . По-перше, організації — це більше, ніж набір індивідуальних ідентичностей. Френч стверджує, що організації в цілому мають мораль. В основному тому, що вони мають цілеспрямованість і відповідальність 9 . Якщо говорити про компанію, то її здатність приймати рішення призводить до такої навмисності. Для прийняття таких рішень організації потрібна особистість. І подібно до того, як ми бачили з Локком вище, це ґрунтується на власній історії, а також на посиланні на тип організації, який самостійно призначається. Я думаю, що це дуже цікаво, і його можна використовувати для пояснення багатьох явищ, які виникають під час роботи в компаніях. Але наразі цього достатньо, і далі я хочу розглянути природу внесків з відкритим кодом більш детально.
Індивідуальні внески в OSS
Чому люди роблять свій внесок у відкритий код? Я думаю, що основна мотивація є внутрішньою. Внутрішню пристрасть до програмування та розробки не можна недооцінювати. Однак ці проекти OSS також є спільнотами, і участь у них може бути дуже мотиваційною. Як ми дізналися з соціальної ідентичності, приналежність до групи є складовою власної ідентичності.
Крім того, свою роль відіграють зовнішні мотиви. Це включає власне кар’єрне зростання, тому що внесок у відкритий код робить людину помітною та може створити репутацію, яка може бути корисною під час пошуку роботи. Зовнішнє визнання також може служити більш загальним мотивуючим фактором. Відчуття того, що людину сприймають як цінного учасника, підвищує її самооцінку.
Я думаю, що ця цитата добре це підсумовує
[Мотиви включають] як зовнішні, так і підвищення репутації та розвиток людського капіталу та соціальних мереж; і внутрішні, задоволення психологічних потреб, задоволення та почуття соціальної приналежності.
Хоча я говорив про визнання як одне з джерел мотивації, визнання також служить іншій меті в проектах з відкритим кодом: силі. Проекти з відкритим кодом часто називають меритократіями. Цікаво, що цей термін популяризувала антиутопічна книга Майкла Янга під назвою «Підйом меритократії» . У ньому передбачене майбутнє суспільство, засноване на меритократії, має багато проблем, можливо, найбільшою є відсутність соціальної мобільності. Ретельний аналіз може спростувати негативні наслідки меритократії, які передбачав Янг у 1958 році. Тож сьогодні меритократія загалом вважається бажаною політичною системою.
Політичні системи дивляться на те, як розподіляється влада, а в меритократії ідея полягає в тому, що влада присуджується на основі заслуг. Саме цю заслугу накопичують окремі розробники, беручи участь у проектах з відкритим кодом. Таким чином, вони отримають вплив в ієрархії проекту. Це, як правило, дозволяє приймати більш технічно обґрунтовані рішення, припускаючи, що ті, хто зробив великий внесок у проект, також мають чітке уявлення про його внутрішню роботу. Існує очевидний контраст із тим, як організована влада в компаніях, де рішення, як правило, приймаються тими, хто в ієрархії має право їх приймати, але не обов’язково має відповідні технічні знання. Це не означає, що в компаніях не приймаються технічно обґрунтовані рішення, але роль і потенційний вплив окремих інженерів відрізняються від ролі та потенційного впливу в проектах з відкритим кодом. На мою думку та досвід, це також причина, чому люди роблять внесок у проекти з відкритим кодом.
Зауважте, що можна стверджувати, що ієрархічні структури в управлінні багатьма проектами OSS також можуть наблизити їх до жорстких структур компаній. Однак це не збігається з моїми особистими анекдотичними свідченнями роботи в ROS. Хоча це може відрізнятися від проекту до проекту, тема, звичайно, не є точною двійковою різницею. Але, незважаючи на відмінності в способах прийняття рішень, у компаній також є багато причин використовувати відкритий код, і це те, на що я хочу поглянути далі.
Внесок компанії в OSS
Чому компанії зацікавлені у відкритому коді? При першому аналізі може здатися нерозумним, що компанія, яка загалом зацікавлена у фінансовому успіху, зацікавлена у вдосконаленні програмного забезпечення, яке, зрештою, має бути та залишатися безкоштовним для використання та яким надалі користуються всі їхні прямі конкуренти. Але багато хто помічав, що хоча історично люди в основному сприяли відкритому коду, тепер компанії. чому так
Першою мотивацією є якість . Ерік С. Реймонд ввів закон Лінуса: «за наявності достатньої кількості очних яблук усі жуки стають дрібними», який названо на честь Лінуса Торвальдса 3 . І це, безперечно, має сенс: якщо більше людей дивляться на даний код, то кращою буде його якість. Я б стверджував, що це також можна пояснити тим, як працюють спільноти з відкритим кодом. Кожен, хто працював у великих проектах розробки, знає, що надто велика кількість інженерів не дозволить автоматично створювати якісне програмне забезпечення. Однак я стверджую, що саме організація різноманітної групи внутрішньо мотивованих інженерів у меритократичних структурах призводить до постійного покращення якості програмного забезпечення. Але обіцянка якості не може бути єдиною мотивацією для компаній, які щорічно інвестують 7,7 млрд доларів США в проекти з відкритим кодом.
Дивитися на інновації стає справді цікаво. Історично вважалося невід’ємним завданням компанії самостійно створювати інновації. Однак постійно зростаючий прогрес технічного прогресу може ускладнити його досягнення, не кажучи вже про розширення за допомогою інновацій. OSS допомагає тут, вирівнюючи умови гри. Коли сучасні технології доступні для використання всім, не потрібно винаходити колесо. Окремі компанії можуть зосередити свої команди розробників, щоб інвестувати в те, що вони вважають інноваційним. Це також робить ці проекти надзвичайно цікавими для невеликих компаній, оскільки описані ефекти для них ще більш виражені.
Якщо компанії будують свою інноваційність, а отже, іноді і всю свою бізнес-модель, на програмному забезпеченні з відкритим кодом, природно, що вони зацікавлені в добробуті відповідного проекту OSS. Тому багато компаній підтримують такі проекти грошово. Однак ця залежність також мотивує бажання впливу. Довгостроковий стратегічний вплив часто надається проектом OSS в обмін на фінансову підтримку. Для короткотермінового технічного впливу часто також в інтересах компаній платити своїм розробникам за активний внесок у програмне забезпечення. Цей вплив також може бути більш цілеспрямованим, але часто вимагає заохочення учасників з необхідним впливом у довгостроковій перспективі 16 . Дуже цікавим моментом в опитуванні Linux Foundation було те, що багато респондентів були відносно краще обізнані про розмір своїх фінансових внесків, ніж про внески через працю.
Виклики та напруга
На перший погляд це виглядає як взаємовигідні стосунки: інженери хочуть зробити свій внесок, компанії дозволяють їм це робити та отримують вплив. Однак це також несе труднощі. Наприклад, компаніям непросто зрозуміти, який вплив вони хочуть або потребують у довгостроковій перспективі. Для інженера, який бачить потребу в такому впливі, також може бути складно переконати свого роботодавця зробити необхідні інвестиції. Тут цікаво подумати, з якою ідентичністю ця заслуга тоді буде пов’язана: із заслугами компанії чи окремого інженера? З мого досвіду, часто це стосується окремої людини, до певної міри, коли ці люди беруть із собою свої заслуги, коли змінюють роботу. Це, очевидно, не в інтересах компаній, які спеціально інвестували в цю людину та проект. Однак завдяки ретельній довгостроковій роботі над стратегією OSS компаніям також цілком можливо накопичувати заслуги, а не втрачати їх через кадрові зміни.
Інша дуже реальна проблема для окремих учасників і супроводжувачів, яку підкреслили Надя Егбал та інші, це вигорання. Це явище цілком може бути притаманним недостатньому управлінню в управлінні проектами OSS. Особливо схильні до ризику вигорання супроводжувачі, які займають посади, які дуже адаптовані до їх особи та/або навичок. Ефективне управління визначило б процеси розподілу робочого навантаження між більшою кількістю людей або пошуку людей, які могли б втрутитися у випадку, якщо їм потрібно зробити перерву чи виконати особисті обов’язки. Часто також просто малоймовірно, що хтось інший займе посаду цієї людини. Якщо вони добре виконують свою роботу, ніхто не буде оскаржувати їх посаду, і якщо їх робоче навантаження сприймається як загалом більше, ніж повний робочий день, це стає ще менш ймовірним. Зв’язок із ідентичністю компанії тут слабший: описане явище зазвичай стосується осіб, чия ідентичність має набагато більше значення для їх успіху, ніж ідентичність їхньої компанії, якщо це взагалі має відношення. Однак трагічна реальність полягає в тому, що багато інших компаній залежать від роботи цієї людини, не маючи можливості забезпечити їм належні умови праці. Тепер, я думаю, ми можемо ближче розглянути ці проблеми за допомогою додаткової теорії ідентичності.
Теорія організаційної ідентичності, застосована до OSS
Цікавим аспектом у статті Уеттена є те, що організаційна ідентичність більш мінлива, ніж особиста. Принаймні це те, що я беру з цього, і це має сенс, тому що як людина я покладаюся на цю ідентичність набагато більше, і це може спричинити серйозну кризу, якщо їй поставити під сумнів або змінитися занадто сильно. Однак ідентичність компаній піддаватиметься сумніву частіше, і вони часто правильно визначаються лише у випадках змін чи кризи. Це пояснює, чому заслуги в OSS сильніше приписуються індивідуальним ідентичністям, якщо вони більш постійні. Однак також очевидно, що необхідною умовою для розподілу заслуг між корпораціями є сильна організаційна ідентичність. Звичайно, на це також впливає індивідуальність інженерів, пов’язаних із цими корпораціями в публічних контекстах, таких як проекти OSS.
Ще один цікавий зв’язок можна витягнути з аргументів Френча на користь моральності корпорацій 9 . Якщо хтось стверджує, що компанії, які використовують програмне забезпечення з відкритим кодом, повинні повертати внески взамін, це моральне твердження. Це може набути або втратити чинність на основі приписування компаніям моральності. До того, як прочитати статтю Френча, я б особисто не припускав, що компанії є моральними. Крім того, я також не вважав мораль дуже актуальною в контексті компаній, які роблять свій внесок (чи ні) у відкритий код. Проте я вважаю, що ми можемо чогось навчитися, застосувавши аргумент Френча до відкритого коду: цей аргумент базується на навмисності та відповідальності. Для мене це інтуїтивно зрозуміло, що я можу нести моральну відповідальність лише за дії, які я вчинив навмисно та за які несу відповідальність. Коли ми застосовуємо це до компанії, яка має намір використовувати програмне забезпечення з відкритим вихідним кодом і несе відповідальність за таке використання, лише тоді вони будуть морально зобов’язані зробити свій внесок. Цікаво те, що відбувається без навмисності: якщо організація не мала наміру використовувати цей відкритий вихідний код, наприклад, тому що один співробітник вирішив використати його, не отримавши належного схвалення, це не обов’язково тягне за собою моральну потребу в прийнятті рішення на рівні компанії зробити свій внесок. А щодо відповідальності ми можемо розглянути приклад, коли компанія не несе відповідальності за використання певного програмного забезпечення з відкритим кодом, можливо, через те, що її змушує використовувати інший діловий партнер, тоді я також можу дотримуватися аргументу, що вона не буде морально зобов’язана робити внески. Мене дуже вражає те, як чітко такі атрибути, як мораль, добре зрозумілі для окремих агентів, можуть бути застосовані до організацій. Тут відкритий код працює як чудовий приклад, який допомагає прояснити ці ідеї.
Тематичні дослідження та приклади
Щоб зробити ці моменти ще більш зрозумілими, я хотів би додати кілька практичних прикладів, які я спостерігав у ROS. Одним з аспектів, який я не знаю, наскільки він унікальний порівняно з іншими проектами, є поширеність невеликих компаній або учасників, які мають власний фрілансерський бізнес. З одного боку, це слугує цікавим поглядом на мораль компаній, у яку тим легше повірити, чим ближче компанія до окремої людини. З іншого боку, це також підкреслює важливість окремих учасників в OSS. Багато з цих компаній не тільки малі, але й постійно змінюються, що робить людей більш постійним аспектом спільноти, ніж їхні компанії. Тут я маю зауваження, яке не погоджується з тим, що Шрапе пише, що «компанії та інші організації можуть залучати свої ресурси більш безперервно та послідовно, ніж окремі учасники». У ROS, і особливо в Nav2, ми стали свідками того, що досить багато компаній припинили свої внески, тоді як участь відповідних осіб виглядає набагато стабільнішою та послідовнішою.
Стосовно доречності та важливості ідентифікацій для роботи з відкритим кодом я натрапив на дискусію Stack Overflow, де людина запитує, чи можливо було б зробити внесок у все, що робить їхня компанія, з одного облікового запису GitHub. Консенсус між відповідями полягає в тому, що це погана ідея з кількох причин, одна з них — невід’ємна актуальність особистого спілкування в спільнотах OSS. У блозі Джоно Бейкона також є гарна публікація про те, чи є анонімні внески OSS гарною ідеєю, прийшовши до висновку, що особи в OSS важливі з міркувань меритократії, підзвітності та відкритості. Це достовірні моменти для релевантності індивідуальних ідентичностей у відкритому коді з дуже практичної точки зору.
Однак є також цікавий приклад організаційної ідентичності на рівні, який ми досі не розглядали. Цей приклад досить цікавий для самої спільноти ROS. Ми можемо застосувати те, що ми дізналися про необхідність обговорення організаційної ідентичності та потенціал для стимулювання цієї дискусії через великі зміни та загрозу втрати ідентичності. Прикладом є, звичайно, придбання великої частини Open Robotics компанією Intrinsic у 2022 році. Це призвело до багатьох дискусій у спільноті ROS і, зрештою, до заснування нової керівної організації Open Source Robotics Alliance OSRA. Тож я читаю це як приклад для ROS як організації, яка втрачає свою ідентичність через Внутрішнє придбання та подальше перевизначення власної ідентичності, що закінчується більш чіткою та краще зрозумілою ідентичністю, ніж вона мала раніше. І лише ця нова ідентичність могла привести до міцної позиції OSRA сьогодні.
Висновок
Ключові висновки, які можуть бути корисними з цієї статті:
- Напруга між особистими та організаційними заслугами : внески в проекти з відкритим кодом часто пов’язані з особистими особами, а не з компаніями, які вони представляють. Щоб використовувати це як компанія, потрібна сильна стратегія відкритого коду.
- Меритократія проти ієрархії : проекти з відкритим кодом часто працюють як меритократії, де вплив заробляється через внески. Однак управління проектом також містить елементи класичної ієрархії. Цей баланс є вирішальним.
- Подвійна мотивація для внеску : люди керуються як внутрішніми факторами, такими як пристрасть до розвитку та приналежність до громади, так і зовнішніми факторами, такими як просування по службі та репутація. Однак компанії мотивовані такими цілями, як покращення якості, інновації та довгостроковий вплив на проекти з відкритим кодом.
- Роль організаційної ідентичності : Компанії можуть утверджувати свою ідентичність у спільноті з відкритим кодом шляхом постійного й навмисного внеску, що з часом допомагає зміцнити довіру та вплив.
- Проблеми управління у відкритому коді : вигоряння серед супроводжуючих підкреслює потребу в кращих структурах управління проектами з відкритим кодом, таких як процеси для розподілу робочого навантаження та забезпечення безперервності, які можуть суттєво відрізнятися від практики корпоративного управління проектами.
Велика подяка Максиміліану Росманну та Себастьяну Кастро за покращення змісту та мови – без вас ми б не змогли!
Бойзел, Сем, Френк Негл, Гіларі Картер, Анна Германсен, Кевін Кросбі, Джефф Лущ, Стефані Лінкольн, Деніел Юе, Мануель Хоффманн і Олександр Стауб. 2024. «Звіт про фінансування програмного забезпечення з відкритим кодом за 2024 рік». https://opensourcefundingsurvey2024.com/ .
Реймонд, Ерік С. 2001. Собор і базар: роздуми про Linux і відкритий вихідний код випадкового революціонера . 1-е видання. Оксфорд, Велика Британія: O'Reilly Media.
Нунан, Гарольд і Бен Кертіс. 2022. «Ідентичність». У «Стенфордській енциклопедії філософії» під редакцією Едварда Н. Залти та Урі Нодельмана, осінь 2022 р. Дослідницька лабораторія метафізики Стенфордського університету.
Локк, Джон. 1694. «Есе про людське розуміння».
Гордон-Рот, Джессіка. 2020. «Локк про особисту ідентичність». У Стенфордській енциклопедії філософії , весна 2020 р.
Тернер, Дж. К., Р. Дж. Браун і Х. Таджфел. 1979. «Соціальне порівняння та груповий інтерес до внутрішньогрупового фаворитизму». Європейський журнал соціальної психології 9 (2): 187–204. https://doi.org/10.1002/ejsp.2420090207 .
«Теорія соціальної ідентичності в психології» (Tajfel & Turner, 1979). 2023. https://www.simplypsychology.org/social-identity-theory.html .
Френч, Пітер А. 1979. «Корпорація як моральна особа». АМЕРИКАНСЬКИЙ ФІЛОСОФСЬКИЙ КВАРТАЛЬНИК 16 (3): 5–13. https://www.jstor.org/stable/20009760 .
Whetten, David A. 2006. «Альберт і Whetten Revisited: посилення концепції організаційної ідентичності». Journal of Management Inquiry 15 (3): 219–34. https://doi.org/10.1177/1056492606291200 .
Бенклер, Йохай. 2004. «Стратегії, засновані на спільному використанні, і проблеми патентів». Наука 305 (5687): 1110–11. https://doi.org/10.1126/science.1100526 .
Молодий, Майкл. 1958. Розквіт меритократії .
Аллен, Ансгар. 2011. « Підйом меритократії Майкла Янга: філософська критика». Британський журнал освітніх досліджень 59 (4): 367–82. https://doi.org/10.1080/00071005.2011.582852 .
Шрапе, Ян-Фелікс. 2018. «Спільноти з відкритим вихідним кодом: соціотехнічна інституціоналізація колективних винаходів». В Колективність і влада в Інтернеті , 57–83. Cham: Springer International Publishing. https://doi.org/10.1007/978-3-319-78414-4\4 .
«Еволюція учасників програм з відкритим кодом: від любителів до професіоналів». nd Перевірено 1 січня 2025 р.https://www.redhat.com/en/blog/evolution-open-source-contributors-hobbyists-professionals .
«Участь у спільнотах з відкритим кодом». nd Перевірено 1 січня 2025 р. https://www.linuxfoundation.org/resources/open-source-guides/participating-in-open-source-communities .
Надія Егбал. 2020. Публічна робота: створення та підтримка програмного забезпечення з відкритим кодом . Сан-Франциско: Stripe Press.
«Чому робити внесок у відкрите програмне забезпечення страшно і як все одно зробити внесок Authentik». nd Перевірено 1 січня 2025 р. https://goauthentik.io/blog/2024-03-07-why-contributing-to-open-source-is-scary/ .
«Зміни робочої групи Navigation2 і ПОТРЕБУЄТЬСЯ ДОПОМОГИ - ROS наступного покоління». 2021. Дискурс РОС . https://discourse.ros.org/t/navigation2-wg-changes-and-help-wanted/12348 .
«[Nav2] Час змін – Загальне». 2021. Дискурс РОС . https://discourse.ros.org/t/nav2-a-time-for-change/30525 .
«Учасник – Внесок як компанія – Обмін стеками з відкритим кодом». nd Перевірено 1 січня 2025 р. https://opensource.stackexchange.com/questions/9763/contributing-as-a-company .
«Анонімні проекти з відкритим кодом - Джоно Бекон». 2017. https://www.jonobacon.com/2017/04/28/anonymous-open-source-projects/ .
«Intrinsic Alphabet отримує більшість відкритої робототехніки – IEEE Spectrum». nd Перевірено 24 січня 2025 р. https://spectrum.ieee.org/alphabet-intrinsic-open-robotics-acquisition .
«Питання щодо внутрішнього придбання OSRC». nd ROS Discourse . Перевірено 24 січня 2025 р. https://discourse.ros.org/t/questions-about-the-intrinsic-acquisition-of-osrc/28763 .
«Оголошуємо Альянс робототехніки з відкритим кодом». nd Open Robotics . Перевірено 24 січня 2025 р. https://www.openrobotics.org/blog/2024/3/18/announcing-the-open-source-robotics-alliance-osra .
