Социально-психологические факторы эффективности совместной деятельности разработчиков открытого программного обеспечения тема диссертации и автореферата по ВАК РФ 00.00.00, кандидат наук Панов Кирилл Алексеевич

• Панов Кирилл Алексеевич
• кандидат наук
• 2025

Оглавление диссертации кандидат наук Панов Кирилл Алексеевич

Введение

Глава 1. Теоретические основы изучения эффективности совместной деятельности разработчиков открытого программного обеспечения

1.1. Принципы специальной методологии социальной психологии при исследовании совместной деятельности

1.2. Эффективность совместной деятельности как объект социально-психологического исследования

1.3. Показатели эффективности совместной деятельности разработчиков открытого программного обеспечения

1.4. Интрасубъективные состояния группы, обеспечивающие эффективное совмещение индивидуальных действий

1.5. Свойства опосредованной совместной деятельности

1.6. Социально-психологический анализ особенностей совместной деятельности разработчиков открытого программного обеспечения

1.7. Выводы по главе

Глава 2. Методическое обеспечение эмпирического исследования эффективности совместной деятельности разработчиков открытого программного обеспечения

2.1. Концептуальная модель эффективности совместно-творческой деятельности

2.2. Программа исследования

2.3. Характеристики выборки

2.4. Выбор и описание методик

2.5. Выводы по главе

Глава 3. Результаты эмпирического исследования эффективности совместной деятельности разработчиков открытого программного обеспечения

3.1. Анализ данных эмпирического исследования

3.2. Общий анализ и интерпретация результатов исследования

3.3. Выводы по главе

Общие выводы

Заключение

Список литературы

Приложение

Приложение

Приложение

Приложение

Приложение

Приложение

Введение диссертации (часть автореферата) на тему «Социально-психологические факторы эффективности совместной деятельности разработчиков открытого программного обеспечения»

Введение

Актуальность исследования. Современная социальная ситуация характеризуется неопределенностью и постоянными необратимыми изменениями (Андреева, Леонтьев, 2018; Марцинковская, 2021; Хорошилов, 2024), которые субъективно воспринимаются личностью как одновременное сосуществование множественных, разнонаправленных, непредсказуемых и неконтролируемых вариантов развития событий (Белинская, 2022). Технологические инновации выступают одной из определяющих черт ситуации социальных изменений, становясь неотъемлемой частью нашей среды и трансформируя как индивидуальные (Белинская, Гавриченко, 2018), так и групповые социально -психологические феномены (Панов, Патраков, 2023).

Вектор развития современной социальной психологии как науки, включенной в общественные отношения, по словам Г.М. Андреевой, заключен в призыве не просто предсказывать, но «катализировать» социальные изменения. В ситуации изменений, вызванных технологиями, социальная психология может помочь индивидам и группам адаптироваться к новой технологии и адаптировать ее для себя за счет исследования социально-психологического содержания, изменяющегося под воздействием технологических инноваций, что реализуется в исследованиях: взаимодействия (А.Е. Войскунский); совладания (Е.П. Белинская, Д.А. Хорошилов); социализации (Е.М. Дубовская, Г.У. Солдатова); идентичности (Т.Д. Марцинковская); психологического благополучия (О.А. Тихомандрицкая, Н.Г. Малышева); принятия экономических решений (Т.В. Фоломеева); потребительского поведения (Ф.Н. Винокуров); социальных представлений (Е.Д. Садовская) и др. Применительно к производственным группам предлагаемый вектор может быть реализован через учет в процессе управления именно социально-психологических факторов эффективности совместной деятельности (Г.М. Андреева, Р.С. Немов).

Изменение условий протекания совместной деятельности, вызванное

развитием и внедрением новых информационных технологий, не только

3

трансформировало форму и содержание совместной производственной деятельности (А.Л. Журавлев, Т.А. Нестик, А.Н. Занковский, Э.В. Патраков, В.И. Панов, Е.А. Сергиенко), но и привело к возникновению нового субъектно-информационного класса (А.В. Карпов, А.А. Карпов) и широкому распространению нового типа совместно-творческой деятельности (Г.М. Андреева, Т.Ю. Базаров; П.В. Малиновский). Совместно-творческий тип деятельности отличается преимущественной ориентацией индивидов на профессиональное развитие, возникновением необходимой для решения задачи социальной структуры, допускающей гибкое распределение ролей, а также созданием инновационного продукта, индивидуальные вклады участников в который неотделимы. К данному типу совместной деятельности, в частности, относится разработка программного обеспечения с открытым исходным кодом.

Открытое программное обеспечение (открытое ПО) — программное обеспечение, распространяемое с открытым исходным кодом, позволяющим его изменить, изучить на наличие уязвимостей и дополнить. Движение за открытое ПО, начавшееся как ответ группы разработчиков-энтузиастов на высокую стоимость и недостаточную гибкость коммерческого ПО, продолжилось в виде децентрализованной модели разработки, продукты которой лежат в основе большинства современных цифровых сервисов как в мире, так и в России. Оно повышает эффективность применения ИТ-инфраструктуры конечными пользователями, обеспечивает стабильность использования ИТ в ситуации блокировок, а также порождает инновации благодаря формированию сообщества разработчиков.

Несмотря на широкую представленность работ, посвященных различным областям эффективности деятельности разработчиков открытого ПО — концептуализацию феномена эффективности (E. Raymond, K. Crowston, C. Schweik, N. Eghbal, G. Peng и др.), ее критерии (D. G. Feitelson, A. H. Ghapanchi, Y. Zhao, G. Z. Heller, S. R. Schach и др.), предикторы и детерминанты (R. Sen, A. W. R. Emanuel, A. Joy, S. Thangavelu, A. Jyotishi и др.), большинство исследований ограничиваются

корреляционным анализом переменных, доступных для выгрузки из платформы для совместной разработки. В качестве предмета исследования авторы принимают формальные характеристики: качество кода (J. Li, I. Ahmed, C. Barbosa) или эмоциональную валентность высказывания (Т. Zhang), в то время как содержание совместной деятельности и механизмы, обеспечивающие эффективное взаимодействие в виртуальной среде, не становятся предметом анализа.

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

Продуктивному разрешению поставленных вопросов способствуют несколько предпосылок. Во-первых, наличие разработанного понятийного аппарата теории деятельности позволяет включить в систему научного знания выводы об эффективности взаимодействия виртуальных групп. Во-вторых, открытость предметной деятельности наблюдению обеспечивает высокую степень экологической валидности результатов. В-третьих, развитые технологические возможности для автоматизации сбора больших данных дают возможность

распространить найденные закономерности на генеральную совокупность групп разработчиков открытого ПО, гарантируя высокую степень внешней валидности.

Таким образом, актуальность диссертационного исследования обусловлена как широким распространением виртуальных производственных групп, так и необходимостью разрешения вопроса о преобразовании социально-психологических феноменов в виртуальных группах под влиянием новых технологий.

Цель исследования — выявить и проинтерпретировать социально -психологические факторы эффективности совместной деятельности разработчиков открытого программного обеспечения.

Объект исследования — эффективное виртуальное взаимодействие в процессе совместно-творческой деятельности.

Предмет исследования — закономерности и социально-психологические факторы эффективности совместно-творческой деятельности.

Общая гипотеза исследования: эффективная совместно-творческая деятельность в виртуальной среде имеет схожие закономерности и социально -психологические факторы эффективности, как и совместная деятельность контактных групп.

Были выдвинуты следующие частные гипотезы исследования:

1. эффективная совместно-творческая деятельность распределённых групп характеризуется достижением целевого единства между участниками;

2. для осуществления эффективной совместно-творческой деятельности в виртуальной среде без единого времени и пространства необходима временная синхронизация индивидуальных ритмов деятельности;

3. эффективная совместно-творческая деятельность организационно независимых участников возможна благодаря функционально-ролевой дифференциации.

Для достижения поставленной цели диссертационного исследования необходимо решить задачи исследования:

• выделить принципы специальной методологии социальной психологии, применяющиеся к изучению совместной деятельности;

• проанализировать особенности социально-психологического подхода к эффективности совместной деятельности;

• систематизировать и критически рассмотреть подходы к социально -психологическим факторам эффективности совместной деятельности в различных парадигмах социальной психологии. Выделить проблемную область диссертационного исследования;

• выбрать наиболее адекватный специфике деятельности разработчиков открытого ПО способ операционализации понятия «эффективность совместной деятельности»;

• выявить социально-психологические факторы, связанные с эффективным согласованием индивидуальных действий в опосредованной совместной деятельности разработчиков открытого программного обеспечения;

• выбрать адекватную производственной деятельности разработчиков открытого программного обеспечения операционализацию показателей эффективности совместной деятельности;

• разработать схему наблюдения за взаимодействием разработчиков открытого программного обеспечения;

• выделить совокупность основных переменных и определить способы анализа их взаимосвязи, разработать систему методических процедур, а также приемов статистической обработки полученных данных;

• обеспечить технические средства для сбора больших объемов данных с помощью методов машинного обучения и автоматического кодирования взаимодействий разработчиков открытого программного обеспечения в соответствии с кодировочной инструкцией;

• изучить различия во взаимодействии между эффективными и неэффективными группами разработчиков открытого программного обеспечения, выделив способствующие эффективному достижению цели факторы.

Этапы и методы исследования. Исследование состояло из четырех этапов. На первом этапе в целях операционализации показателей эффективности совместной деятельности, полученной в обзоре литературы, было проведено семь полуструктурированных интервью с руководителями проектов по разработке отечественных и зарубежных проектов открытого ПО.

На втором этапе осуществлялся выбор схемы наблюдения, соответствующей специфике объекта исследования. Для первичного ознакомления со взаимодействием разработчиков открытого ПО с помощью метода обоснованной теории было закодировано 700 действий. Выбрана схема наблюдения, содержащая категории трех типов взаимодействия: предметно-направленного, субъектно-направленного и направленного на организацию процесса взаимодействия. Далее два эксперта закодировали 2 119 действий. Была измерена надежность схемы наблюдения через оценку межэкспертной согласованности.

На третьем этапе с целью создания технических средств для автоматического кодирования взаимодействия в соответствии с кодировочной инструкцией была осуществлена оценка эффективности определения категорий несколькими большими языковыми моделями (LLM). Количественно оценено соответствие экспертной и автоматической категоризации 900 высказываний, имеющих однозначно приписанную экспертами категорию.

На последнем этапе был использован интеллектуальный анализ данных (Data mining) для сбора больших данных о взаимодействии в группах разработчиков. Ключевым внешним критерием эффективности выступила востребованность создаваемого продукта в профессиональном сообществе. Отобраны 984 функционирующие группы, которые впоследствии были разделены на эффективные и неэффективные по параметрам производственной и социально -психологической эффективности. В каждой из групп фиксировались действия

участников, относящиеся к разным типам взаимодействия: предметно-направленному, субъектно-направленному и направленному на процесс организации. Всего собрано 114 016 последовательностей действий.

В качестве статистических методов обработки данных использовались: корреляционный анализ (r-Пирсона); непараметрические статистики сравнения двух выборок (U-критерий Манна-Уитни); анализ таблиц сопряженности (метод хи-квадрата Пирсона); факторный анализ (метод главных компонент); регрессионный анализ (линейная регрессия). Статистическая обработка данных осуществлялась с помощью программ Jamovi, SPSS Statistics 21 и библиотек для анализа данных, написанных на языке программирования Python.

Методологическая основа исследования:

- принцип социальной обусловленности совместной деятельности (Г.М. Андреева, А.В. Петровский и др.), позволяющий рассмотреть содержание социально значимой совместной деятельности конкретной профессиональной группы и сложившиеся отношения между ее членами;

- принцип деятельности (А.Н. Леонтьев, Г.М. Андреева и др.), позволяющий изучить собственно групповые феномены и процессы интеграции индивидуальных действий во внутригрупповую активность;

- принцип развития (Г.М. Андреева, М.Г. Ярошевский, А.В. Петровский, Е.М. Дубовская и др.), позволяющий рассмотреть функциональную интеграцию группы как внутренне необходимый момент динамики изменения системы групповой активности;

- принцип системности (Б.Ф. Ломов, А.В. Петровский, Р.Л. Кричевский и др.), позволяющий анализировать детерминанты эффективности на нескольких соподчиненных уровнях системы группового функционирования.

Теоретическая основа исследования:

- теоретические представления об эффективности совместной деятельности в социальной психологии (Б.Ф. Ломов, Р.С. Немов, Г.М. Андреева);

- концепция интеграции малой функциональной группы (А.И. Донцов);

9

- концепция сработанности участников совместной деятельности (Н.Н. Обозов, А.И. Китов);

- представления о взаимодействии как о базовой единице анализа совместной деятельности (А.И. Донцов, А.Л. Журавлев);

- модель психологической структуры совместной деятельности (А.Л. Журавлев);

- представления о совместно-творческой форме совместной деятельности (Г.М. Андреева, Т.Ю. Базаров).

ПОЛОЖЕНИЯ, ВЫНОСИМЫЕ НА ЗАЩИТУ

1. Инвариантным и основополагающим фактором эффективности совместной деятельности как распределенных групп в виртуальной среде, так и контактных групп является необходимость разделения участниками схожего образа результата совместной деятельности, который позволяет включить индивидуальный вклад в общий продукт.

2. Специфическим фактором эффективности совместной деятельности, происходящей в виртуальной среде без временных и пространственных ограничений, выступает формирование участниками единого отношения ко времени, которое проявляется в осуществлении синхронизированных, своевременных и согласованных действий.

3. Осуществление эффективной совместно-творческой деятельности в виртуальной среде в отсутствие организационно заданного распределения функциональных обязанностей требует от участников активного принятия ответственности за предлагаемый индивидуальный вклад и взаимных призывов к осуществлению последующих действий.

4. Комбинация социально-психологических факторов, необходимых для достижения высокой эффективности совместно-творческой деятельности в виртуальной среде, включает: согласование единого образа результата деятельности, формирование единого отношения ко времени и активное принятие участниками ответственности за предлагаемый индивидуальный вклад.

Теоретическая значимость результатов исследования. Конкретизировано соотношение специфики формирования эффективной совместной деятельности в контактной и виртуальной группе. Обосновано, что инвариантным социально-психологическим фактором является целевое единство. В то время как закрепленная функционально-ролевая дифференциация заменяется распределением ответственности между участниками, а пространство-временное единство заменяется единством отношения ко времени.

Расширены представления о синхронизации распределенных участников в процессе совместно-творческой деятельности (Г.М. Андреева, Т.Ю. Базаров), протекающей в виртуальной среде. Доказано, что для достижения функционально зависимыми участниками социально-значимых целей необходимы: согласование образа результата деятельности; синхронизация времени действий; закрепленное распределение ответственности.

Уточнен список условий достижения сработанности (Н.Н. Обозов, А.И. Китов) для виртуальных распределенных рабочих групп. Такие условия включают в себя: трансляцию актуального для группы и доступного для достижения отдельным участником образа результата деятельности; реализацию временной синхронизации между участниками; распределение ответственности между участниками взаимодействия.

Основные результаты исследования вносят вклад в развитие идей о социально-психологических детерминантах эффективности совместно-творческой деятельности, протекающей в отсутствии единого времени и пространства.

Практическая значимость результатов исследования. Научные результаты диссертационного исследования, описывающие ключевые социально-психологические факторы обеспечения эффективности совместно-творческой деятельности в виртуальной среде, могут быть использованы практическими психологами, оказывающими услуги психологического сопровождения и оптимизации процесса организации совместной деятельности распределенных групп.

Конкретные методические рекомендации, направленные на формирование синхронизации взаимодействия, могут быть внедрены в практическую деятельность руководителей распределенных групп с целью обеспечения согласованного функционирования группы. В частности, сосредоточив внимание на формировании согласованного образа ожидаемого результата, временной синхронизации участников и явном распределении ответственности между ними.

Разработанная технология наблюдения за предметно-направленным, субъектно-направленным и организационно-направленным взаимодействием в виртуальной среде, позволяет изучать динамические характеристики совместно-творческой деятельности распределенных групп разработчиков ПО.

Научная новизна результатов диссертационного исследования. Продемонстрирована возможность распространения общих фундаментальных социально-психологических закономерностей на принципиально новые условия протекания эффективной совместной деятельности. В частности, установлен инвариантный для реальной и виртуальной среды фактор эффективности — достижение целевого единства участников.

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

Определена комбинация социально-психологических факторов, способствующих эффективной совместно-творческой деятельности групп в виртуальной среде. Такими факторами выступают: согласование единого образа результата совместной деятельности, единство отношения ко времени и принятие участниками ответственности за предлагаемый индивидуальный вклад.

Обнаружено латентное распределение ответственности в эффективных самоорганизующихся группах, осуществляющих совместно-творческую деятельность. Согласно ему, внешний разработчик отвечает за инициацию предметно-направленного взаимодействия, член команды — за субъектно-направленного, руководитель — за организационно-направленного взаимодействия.

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

Получены новые эмпирические данные о взаимодействии распределенных групп в процессе эффективной совместно-творческой деятельности. В частности, определены поведенческие критерии сформированной среды для совместно-творческой деятельности: неучастие руководителя в предметно-направленном взаимодействии, возложение ответственности на участника за индивидуальный вклад, призывы участников к совершению действий.

Сформулировано заключение о наборе условий, необходимых для достижения группой высокой эффективности совместно-творческой деятельности в виртуальной среде.

Достоверность и надежность результатов исследования обеспечена за счет проработки теоретико-методологической базы на соответствие целям и задачам исследования; формирования репрезентативной выборки групп разработчиков открытого ПО; применения адекватных задачам исследования процедур и статистических методов обработки и анализа результатов.

Апробация работы. Материалы диссертации представлены на конференциях: «Международная конференция студентов, аспирантов и молодых ученых «Проспект Свободный - 2024» (Сибирский федеральный университет, 2024); «Международная научная конференция "Андреевские чтения. Социальная психология в современном обществе"» (МГУ имени М.В. Ломоносова, 2024).

Диссертационная работа обсуждена и рекомендована к защите кафедрой социальной психологии факультета психологии МГУ имени М.В. Ломоносова (Москва, 2021-2025 гг.). Диссертационная работа обсуждена и рекомендована к защите на методологическом семинаре Диссертационного совета на базе ФГБОУ ВО «Ярославский государственный университет им. П.Г. Демидова». Результаты диссертационного исследования изложены в 5 публикациях, 4 из которых — в изданиях, рекомендованных ВАК.

Структура и объем диссертации. Работа состоит из введения, трех глав, выводов, заключения, библиографии и приложений. Список использованной литературы включает в себя 190 источников, 100 из которых — на иностранном языке. В тексте работы содержится 13 иллюстраций, 24 таблицы, 6 приложений. Объем работы — 150 страниц без приложений.

Глава 1. Теоретические основы изучения эффективности совместной деятельности разработчиков открытого программного обеспечения

1.1. Принципы специальной методологии социальной психологии при исследовании совместной деятельности

Перед проведением эмпирического исследования возникает вопрос об исследовательской стратегии, т. е. специальной методологии науки о существующих на данном этапе развития психологического знания методологических предпосылках, описанных в текстах исследователей совместной деятельности и направляющих исследование. При проведении конкретного эмпирического исследования явная экспликация принимаемых автором положений позволит продемонстрировать переход от методологических оснований к следствиям, предпринятый в конкретном эмпирическом исследовании, что повысит прозрачность созданного текста, облегчит его восприятие и позволит проделать (при необходимости) тот же путь, что и автор.

Первым необходимым шагом является решение вопроса об общих принципах или представлениях, которые являются консенсусом среди исследователей совместной деятельности. Анализ литературы показывает, что одним из таких принципов является социальная обусловленность совместной деятельности (далее — СД). Согласно ему, общественно значимая потребность через социальные связи между индивидами реализуется в СД, иными словами, причина возникновения СД лежит в общественных отношениях и общественном разделении труда (Андреева, 2018; Донцов, 1984; Журавлев, 2005; Кричевский, Дубовская, 2009; Петровский, 1978).

Принцип деятельности стал следствием включения Г.М. Андреевой положений оригинальной теории А.Н. Леонтьева в социальную психологию.

Следуя ему, единый процесс СД разделяется между участниками, из-за чего изменяется строение индивидуальной деятельности каждого. Индивидуальный результат деятельности больше не приводит к удовлетворению потребности индивида, на смену приходит удовлетворение всеобщим продуктом, что в сознании индивидов начинает осознаваться как отношения с другими, от которых он получает часть продукта СД (Андреева, 2018; Леонтьев, 2005).

Развитие теории систем позволило социальной психологии использовать одноименный принцип, согласно которому система СД группы состоит из системы индивидуальных деятельностей, одновременно с этим она существует в более крупной системе — социальном контексте. Помимо того, что разные уровни анализа (диада, малая группа, большая группа, социальная общность) взаимосвязаны, они еще и имеют свои феномены и интегративные процессы, которые важно рассматривать в соподчинении (Дубовская, 2013).

Последний принцип акцентирует внимание исследователей на динамической составляющей СД. Принцип развития заключает в себе убеждение в том, что система СД имеет внутренние противоречия и способна развиваться как прогрессивно, так и регрессивно (там же).

Описанные выше принципы можно резюмировать определением совместной деятельности, в котором синтезируются черты каждого из них. СД, согласно позиции социальной психологии, — это «организованная система активности взаимодействующих индивидов, направленная на целесообразное производство объектов материальной и духовной культуры» (Андреева, Яноушек, 1987, с. 24).

Второй вопрос, напрямую возникающий при подготовке исследования совместной деятельности, касается определения различий между групповой и совместной деятельностью. Какие признаки позволяют заключить, что перед нами феномены собственно-совместной деятельности, а не случайного объединения людей?

Список литературы диссертационного исследования кандидат наук Панов Кирилл Алексеевич, 2025 год

Список литературы

1. Абульханова-Славская, К. А. Категория деятельности в советской психологии // Психологический журнал. - 1980. - Т. 1. - № 4. - С. 11-28.

2. Андреева Г. М., Леонтьев А. Н. Методические проблемы исследования психологических аспектов социальных изменений //Психология. Журнал Высшей школы экономики. - 2018. - Т. 15. - №. 4. - С. 646-654.

3. Андреева, Г. М. Наследие А. Н. Леонтьева и современная психология социального познания // Мир психологии. - 2003. - № 2. - С. 124-134.

4. Андреева, Г. М. Социальная психология: Учебник для высших учебных заведений. М.: Аспект Пресс, 2018.

5. Андреева, Г. М., Яноушек, Я. Общение и оптимизация совместной деятельности. М.: Московский Государственный Университет, 1987.

6. Базаров Т. Ю. Импровизация как основа совместного творчества в управлении // Национальный психологический журнал. - 2006. - №2 1 (1). - С. 120122.

7. Базаров, Т. Ю., Дикусарова, А. Р. Влияние стилей реагирования на изменения фасилитатора и эффективность командной работы в виртуальной среде // Научный результат. Педагогика и психология образования. - 2021. - Т. 7. - № 4. - С. 74-87.

8. Базаров, Т. Ю., Сычева, М. П. Создание и апробация Опросника «Стили реагирования на изменения» // Психологические исследования. - 2012. - Т. 5. - № 25. - С. 12. URL: http://psystudy.ru (дата обращения: 12.09.2024).

9. Барабанщикова В. В., Иванова С. А. Предикторы прокрастинации в трудовой деятельности современного профессионала //Психологический журнал. -2017. - Т. 38. - №. 3. - С. 44-56.

10. Белинская Е. П. Совладание с трудностями в эпоху неопределенности и глобальных рисков: основные исследовательские тренды //СибСкрипт. - 2022. -Т. 24. - №. 6 (94). - С. 760-771.

11. Белинская Е. П., Вознесенская В. С. Проблема регуляции социального поведения в теориях информационного общества и реальность сетевого взаимодействия // Психологические исследования. - 2016. - Т. 9. - № 48. - С. 5-5.

12. Белинская, Е. П. Человек в информационном мире // Социальная психология в современном мире / под ред. Г. М. Андреевой, А. И. Донцова. - М.: Аспект Пресс, 2002. - С. 203-220.

13. Белинская, Е. П., Франтова, Д. К. Активность в виртуальном взаимодействии как фактор конструирования идентичности пользователями социальных сетей: межпоколенные различия // Вестник РГГУ. Серия «Психология. Педагогика. Образование». - 2017. - № 3 (9). - С. 28-43.

14. Белинская, Е., Гавриченко, О. Самопрезентация в виртуальном пространстве: феноменология и закономерности // Психологические исследования.

- 2018. - Т. 11, № 60.

15. Брушлинский, А. В. Проблема субъекта в психологической науке (статья первая) // Психологический журнал. - 1991. - Т. 12. - № 6. - С. 3-11.

16. Буева, Л. П. Общественные отношения и общение // Методологические проблемы социальной психологии. - 1975. - Т. 2. - С. 68-85.

17. Винокуров Ф. Н., Панов К. А., Садовская Е. Д. Наследие Г.М. Андреевой: роль технологических инноваций в социальных изменениях // Национальный психологический журнал. — 2024. — № 3. — С. 46-64. -10.n62ynpj.2024.0304 (18 п.л./4 п.л.). — ИФ РИНЦ - 1,167.

18. Власова, Е. В. Особенности коммуникации в различных видах групповой деятельности. - СПб.: Изд-во СПбГУ, 1998. - 196 с.

19. Войскунский, А. Е. Современные тенденции киберпсихологических исследований // Цифровое общество в культурно-исторической парадигме. - 2019.

- С. 6-13.

20. Гамова Е. И. Ориентировка в структуре совместной деятельности и ее влияние на результативность совместной деятельности малых молодежных групп

// Политематический сетевой электронный научный журнал Кубанского государственного аграрного университета. - 2012. - № 79. - С. 795-805.

21. Гамова Е. И. Социально-психологические аспекты ориентировочной основы совместной деятельности малых молодёжных групп : дис. - Курск, 2013.

22. Головаха, Е. И. Структура групповой деятельности: социально-психологический анализ. - Киев: Наукова думка, 1979. - 232 с.

23. Долгова, Н. Ю. Эффективность совместной деятельности и регуляторный опыт участников. - Москва, 2012. - 164 с.

24. Донцов А. И. Психологическое единство коллектива. - М.: Знание,

1982.

25. Донцов А. И., Дубовская Е. М., Жуков Ю. М. Группа-коллектив-команда. Модели группового развития // Социальная психология в современном мире. М. - 2002. - С. 96-114.

26. Донцов, А. И. К проблеме целостности субъекта коллективной деятельности // Вопросы психологии. - 1979. - № 3. - С. 25-34.

27. Донцов, А. И. Психологические основы интеграции коллектива : дис. ... д-ра психол. наук. - М.: МГУ им. М. В. Ломоносова, 1988.

28. Донцов, А. И. Психология коллектива. М.: Издательство Московского университета, 1984.

29. Донцов, А. И. Цель как фактор групповой активности // Личность в системе общественных отношений. Тезисы докладов к VI Всесоюзному съезду общества психологов СССР. - АН СССР. 1983.

30. Донцов, А. И., Дубовская, Е. М., Улановская, И. М. Разработка критериев анализа совместной деятельности // Вопросы психологии. 1998. № 98 (2). С. 61-71.

31. Дрынкина Т. И., Карпова Е. А. Виртуальная команда: вызов XXI века //Современное состояние и перспективы развития психологии труда и организационной психологии. - 2018. - С. 189-201.

32. Дубовская, Е. М. Информационное пространство транзитивного общества // Цифровое общество в культурно-исторической парадигме. - 2019. - С. 48-53.

33. Дубовская, Е. М., и др. Проблема совместной деятельности: традиция и перспектива // Социальная психология и общество. - 2013. - № 4 (3). - С. 5-12.

34. Жуков Ю. М., Журавлев А. В., Павлова Е. Н. Технологии командообразования. Учебное пособие. - 2008.

35. Журавлев А. Л., Занковский А. Н. Тенденции развития организационной психологии //Психологический журнал. - 2017. - Т. 38. - №. 2. -С. 77-88.

36. Журавлев А. Л., Нестик Т. А. Групповая рефлексивность: основные подходы и перспективы исследований // Психологический журнал. - 2012. - Т. 33. - № 4. - С. 27-37.

37. Журавлев А. Л., Нестик Т. А. Совместное творчество как ресурс деятельности организации: состояние и перспективы исследований // Психологический журнал. - 2011. - Т. 32. - №. 1. - С. 3-21.

38. Журавлев, А. Л. Проблема совместной трудовой деятельности в социально-психологическом исследовании коллектива // Личность в системе общественных отношений. - 1983. - С. 508-510.

39. Журавлев, А. Л. Психология совместной деятельности.- М.: Институт психологии РАН, 2005.

40. Журавлев, А. Л., Нестик, Т. А. Психология управления совместной деятельностью: Новые направления исследований. - М.: Институт психологии РАН, 2010.

41. Замглавы Минцифры Максим Паршин: «Не хотим изоляции, но нам нужен свой репозиторий» [Электронный ресурс] // Forbes. URL: https://www.forbes.ru/tekhnologii/486349-zamglavy-mincifry-maksim-parsin-ne-hotim-izolacii-no-nam (дата обращения: 03.05.2023).

42. Занковский, А. Н., Журавлёв, А. Л. Психология виртуальной организации: основные проблемы исследования // Психологический журнал. -2017. - Т. 38. - № 5. - С. 92-102.

43. Карпов А. В., Нестик Т. А. АВ Карпов о будущем психологии //Институт психологии Российской академии наук. Социальная и экономическая психология. - 2020. - Т. 5. - № 3. - С. 373-398.

44. Китов, А. И. Психология хозяйственного управления. - М.: Профиздат, 1984. - 246 с.

45. Климов А. А. Идентификация с организацией и рабочей группой как фактор экстраролевого поведения работника : автореф. дис. ... канд. психол. наук. - М. : Национальный исследовательский университет «Высшая школа экономики», 2015.

46. Кожевникова, Л. В., Старовойтова, И. Е. Формирование виртуальных команд: удаленный тимбилдинг и лидерство // Вестник университета. - 2022. - № 4. - С. 64-71.

47. Коммерческий open source в России: темпы внедрения и перспективы (2023-2025) [Электронный ресурс] // World Market Studies. - URL: https://worldmarketstudies.ru/article/kommerceskij-open-source-v-rossii-tempy-vnedrenia-i-perspektivy-2023-2025 (дата обращения: 12.09.2024).

48. Кричевский, Р. Л., Дубовская, Е. М. Социальная психология малой группы. - М.: Издательство «Аспект Пресс», 2009.

49. Кричевский, Р. Л., и др. Психология руководства и лидерства в спортивном коллективе. - М.: Изд-во МГУ, 1985. - 223 с.

50. Кузин Т. С., Грищенко Н. П. Социально-психологический анализ экстраролевого поведения сотрудника организации // Юридическая психология. -2019. - № 4. - С. 24-29.

51. Леонтьев, А. Н. Деятельность. Сознание. Личность. - М.: Смысл: Академия, 2005.

52. Липатов С. А. Использование различных стратегий «смешанных методов» в диагностике организационной культуры //Социальная психология и общество. - 2018. - Т. 9. - №. 3. - С. 62-70.

53. Ломов, Б. Ф. Методологические проблемы социальной психологии // Психологический журнал. - 1987. - Т. 8. - № 3. - С. 21-32.

54. Ломов, Б. Ф. Совместная (групповая) деятельность людей, формирование трудовых коллективов и психологические аспекты управления ими // Правовые и социально-психологические аспекты управления. - М., 1972. - С. 211-240.

55. Лутошкин, А. Н. Системная модель коллектива и некоторые принципы исследования групповых эмоциональных потенциалов // Социально-психологические проблемы личности и коллектива: сборник трудов. - Ярославль, 1977. - Вып. 48. - С. 20-37.

56. Лутошкин, А. Н. Эмоциональные потенциалы первичного коллектива // Эмоциональные потенциалы коллектива / Ярославский пед. институт им. К. Д. Ушинского. - Ярославль, 1977. - № 50. - С. 7-95.

57. Макарченко, М. А.., Павлова, О. Н. Особенности трансформации классического командообразования в виртуальное в условиях цифровизации // п-Бсопошу. - 2018. - Т. 11. - № 1. - С. 39-53.

58. Марцинковская Т. Д. Новая методология исследования транзитивности жизненного пространства изменяющейся личности //Новые психологические исследования. - 2021. - Т. 1. - №. 2. - С. 31-45.

59. Марцинковская, Т. Д. Новые методологические подходы современной психологии в цифровом обществе // Психологический журнал. - 2023. - Т. 44. - № 2. - С. 5-12.

60. Мельникова О. Т., Нестерова Е. М. Особенности групповой дискуссии в очных и онлайн фокус-группах //Вестник Московского университета. Серия 14. Психология. - 2024. - №. 1. - С. 184-206.

61. Мельникова О. Т., Нестерова Е. М. Сравнительный анализ типов дизайнов смешанных методов в контексте социально-психологических исследований //Теоретическая и экспериментальная психология. - 2023. - Т. 16. -№. 2. - С. 107-126.

62. Мельникова, О. Т., Хорошилов, Д. А. Методологические проблемы качественных исследований в психологии. - М.: Акрополь, 2020. - 234 с.

63. Немов Р. С., Шестаков А. Г. Сплоченность как фактор групповой эффективности // Вопросы психологии. - 1981. - № 3. - С. 113-118.

64. Немов, Р. С. Психологические условия и критерии эффективности работы коллектива. - Москва : Издательство «Знание», 1982. - 64 с.

65. Нестик, Т. А. Развивать организацию через развитие социальных сетей: роль кадровой службы // Кадровая служба и управление персоналом предприятия. - 2004. - № 7. - С. 323-325.

66. Обозов, Н. Н. Межличностные отношения. - Ленинград: Изд-во Ленингр. ун-та, 1979. - 215 с.

67. Обозов, Н. Н. Совместимость и срабатываемость людей. - СПб.: Питер, 2007. - 352 с.

68. Орлова, Т. Е. Динамика взаимодействия в виртуальных командах : дис. ... канд. психол. наук. - СПб., 2006. - 182 с.

69. Панов В. И., Патраков Э. В. Трансформация социальных взаимодействий высокоорганизованных групп в условиях цифровизации: экопсихологическая модель //История, современность и перспективы развития психологии в системе Российской академии наук. - 2022. - С. 370-372.

70. Панов К. А., Винокуров Ф. Н. Методика наблюдения за взаимодействием разработчиков открытого программного обеспечения // Вестник РГГУ. Серия: Психология. Педагогика. Образование. — 2024. — № 2. — С. 117130.

71. Панов К. А., Винокуров Ф. Н. Показатели эффективности совместной деятельности разработчиков открытого программного обеспечения // Организационная психология. — 2024. — Т. 14. - № 1. — С. 158-172.

72. Панов К. А., Сработанность как фактор эффективности совместной деятельности разработчиков открытого программного обеспечения // Научное мнение. Педагогические, психологические и философские науки. — 2024. — № 78. — С. 163-170.

73. Папкин А. И. Психологические исследования проявлений эмоциональной идентификации личности в коллективе. -М.: МГУ. - 1975.

74. Петровский, А. В. Социальная психология коллектива. - М.: Просвещение, 1978.

75. Позняков, В. П. Психологические отношения субъектов совместной жизнедеятельности // Знание. Понимание. Умение. - 2013. - № 13 - С. 167-174.

76. Ребзуев Б. Г. Разработка конструкта трудового поведения и шкалы экстраролевого трудового поведения // Психология. Журнал высшей школы экономики. - 2009. - Т. 6. - № 1. - С. 3-57.

77. Сарычев С. В., Хусаинова С. В., Лебедчук П. В. Ориентировка и саморегуляция деятельности группового субъекта в напряженных условиях // Казанский педагогический журнал. - 2021. - № 3 (146). - С. 255-261.

78. Сидоренков А. В. Разработка и апробация двухфакторного опросника организационного гражданского поведения работников // Экспериментальная психология. - 2020. - Т. 13. - № 2. - С. 182-193.

79. Смирнова Я. К. К постановке проблемы феномена ориентировочной основы совместной деятельности // Вестник психологии и педагогики Алтайского государственного университета. - 2016. - № 3. - С. 63-72.

80. Соловьева, О. В. Наблюдение // Социальная психология: Практикум. Учебное пособие для студентов вузов / Под ред. Т. В. Фоломеевой. 2006. С. 28-49.

81. Уманский, Л. И. Психология организаторской деятельности. - М.: Педагогика, 1980. - 224 с.

82. Федотова С. В., Винокуров Ф. Н. Апробация методов интеллектуального анализа данных для выявления представлений о цифровых рисках // Казанский педагогический журнал. - 2022. - № 6. - С. 85-93.

83. Хараш, А. У. Принцип деятельности в исследованиях межличностного восприятия // Вопросы психологии. - 1980. - Т. 3. - С. 20-31.

84. Хорошилов, Д. А., Мельникова, О. Т. Метод тематического анализа в изучении представлений о женском лидерстве // Организационная психология. -2020. - № 10 (3). - С. 85-99.

85. Чегурова М. М. Руководители в условиях цифровой экономики: новые вызовы и компетенции //Вестник Санкт-Петербургского университета. Социология. - 2021. - Т. 14. - №. 3. - С. 208-223.

86. Чернышев А. С. Социально-психологические основы организованности первичного коллектива (на материалах исследования молодежных групп и коллективов): автореф. дисс. д-ра психол. наук: 19.00.05. -1980. - 65 с.

87. Шихирев, П. Н. Современная социальная психология в Западной Европе: Проблемы методологии и теории. - М.: Наука, 1985.

88. Шпалинский, В. В. Экспериментально-психологическое исследование групповой сплоченности // Проблемы экспериментальной психологии и ее истории / под ред. А. В. Петровского и др. - 1973. - С. 56-74.

89. Штроо, В. А. Человек и организация в условиях модернизации экономики // Модернизация экономики и государство: мат-лы VII междунар. науч. конф. - М.: Изд-во ГУ ВШЭ, 2006.

90. Ярошевский, М. Г. Программно-ролевой подход к исследованию научного коллектива // Вопросы психологии. - 1978. - № 3. - С. 40-53.

91. 2023 State of Open Source Report [Электронный ресурс] // Openlogic. URL:https://www.openlogic.com/resources/2023-state-open-source-report?utm_source=OSI&utm_medium=content&utm_campaign=OPL-GLB-2023Q1-CON-State (дата обращения: 03.05.2023).

92. Alaiad A., Alnsour Y., Alsharo M. Virtual teams: Thematic taxonomy, constructs model, and future research directions // IEEE Transactions on Professional Communication. - 2019. - VOL. 62. - no. 3. - pp. 211-238.

93. Alami A., Cohn M. L., W^sowski A. Why does code review work for open source software communities? //2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). - IEEE, 2019. - pp. 1073-1083.

94. Albrecht, K. The power of minds at work: Organizational intelligence in action. - New York: AMACOM Div American Mgmt Assn, 2003.

95. Ale Ebrahim N., Ahmed S., Taha Z. Virtual teams: A literature review // Australian journal of basic and applied sciences. - 2009. - vol. 3. - no. 3. - pp. 26532669.

96. Alexander Hars S. O. Working for free? Motivations for participating in open-source projects // International journal of electronic commerce. - 2002. - vol. 6. -no.3. - pp. 25-39.

97. Alves M. P. et al. Can virtuality be protective of team trust? Conflict and effectiveness in hybrid teams //Behaviour & Information Technology. - 2023. - vol. 42.

- no.7. - pp. 851-868.

98. Bagozzi R. P., Dholakia U. M. Open source software user communities: A study of participation in Linux user groups // Management science. - 2006. - vol. 52. -no.7. - pp. 1099-1115.

99. Bales, R. F. A Set of Categories for the Analysis of Small Group Interaction // American Sociological Review. - 1950. - vol. 15. - no.2. - pp. 257-263.

100. Bales, R. F. Social interaction systems: Theory and measurement. - 1st ed.

- London: Routledge, 2017. - 417 p.

101. Barbosa, C., et al. Beyond the Code: Investigating the Effects of Pull Request Conversations on Design Decay // 2023 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). - IEEE, 2023. - pp. 112.

102. Barr, P. S., Glynn, M. A. Cultural variations in strategic issue interpretation: Relating cultural uncertainty avoidance to controllability in discriminating threat and opportunity // Strategic Management Journal. - 2004. - vol. 25. - no.1. - pp. 59-67.

103. Beecher, K. et al. Evolutionary success of open source software: An investigation into exogenous drivers // Electronic Communications of the EASST. -2008.

104. Bell B. S., McAlpine K. L., Hill N. S. Leading virtually //Annual Review of Organizational Psychology and Organizational Behavior. - 2023. - vol. 10. - no. 1. - pp. 339-362.

105. Bitzer J., Schrettl W., Schröder P. J. H. Intrinsic motivation in open source software development // Journal of comparative economics. - 2007. - vol. 35. - no.1. -pp. 160-169.

106. Bolton R., Logan C., Gittell J. H. Revisiting relational coordination: a systematic review //The Journal of applied behavioral science. - 2021. - vol. 57. - no. 3. - pp. 290-322.

107. Bregenzer A., Jimenez P. Risk factors and leadership in a digitalized working world and their effects on employees' stress and resources: Web-based questionnaire study //Journal of medical Internet research. - 2021. - vol. 23. - no. 3. -24906 p.

108. Carillo K. D. A. Understanding contributor behaviour within Free/Libre/Open Source Software communities: A socialization perspective : gnc. - Open Access Te Herenga Waka-Victoria University of Wellington, 2014.

109. Chang, L. Motivations, Team Dynamics, Development Practices and How They Impact the Success of Open Source Software: A Study of Projects of Code for America Brigades // 2018.

110. Chen G., Kanfer R. The future of motivation in and of teams //Annual Review of Organizational Psychology and Organizational Behavior. - 2024. - vol. 11. -no. 1. - pp. 93-112.

111. Chew R. et al. LLM-assisted content analysis: Using large language models to support deductive coding //arXiv preprint arXiv:2306.14924. - 2023.

112. Choi N., Chengalur-Smith I., Nevo S. Loyalty, ideology, and identification: An empirical study of the attitudes and behaviors of passive users of open source software // Journal of the Association for Information Systems. - 2015. - vol. 16. - no.8. - pp. 2.

113. Colazo, J. A., Fang, Y., Neufeld, D. Development success in open source software projects: exploring the impact of copylefted licenses // 2005.

114. Cosentino V., Izquierdo J. L. C., Cabot J. A systematic mapping study of software development with GitHub // Ieee access. - 2017. - vol. 5. - pp. 7173-7192.

115. Crowston, K. et al. Towards a portfolio of FLOSS project success measures // Workshop on Open Source Software Engineering, 26th International Conference on Software Engineering, Edinburgh. - 2004.

116. Crowston, K., Annabi, H., Howison, J. Defining open source software project success // 2003.

117. Crowston, K., Shamshurin, I. Core-periphery communication and the success of free/libre open source software projects // Journal of Internet Services and Applications. - 2017. - vol. 8. - no. 1. - pp. 1-11.

118. Daly, A., Scott, D. The Dynamics of Group-Level Interaction in Organizational Culture: Insights from Activity Theory // Group Processes & Intergroup Relations. - 2019. - vol. 22, no.4. - pp. 545-563. DOI: 10.1177/1368430218798602

119. Dias E. et al. What makes a great maintainer of open source projects? // 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). - IEEE, 2021. - pp. 982-994.

120. Dominic J. et al. Conversational bot for newcomers onboarding to open source projects //Proceedings of the ieee/acm 42nd international conference on software engineering workshops. - 2020. - pp. 46-50.

121. Eghbal, N. Working in public: the making and maintenance of open source software. Stripe Press, 2020.

122. El Idrissi A., Fourka M. Performance in Virtual Teams: Towards an Integrative Model //Proceedings. MDPI. - 2022. - vol. 82. - no. 1. - pp. 73.

123. Emanuel, A. W. R. et al. Success factors of OSS projects from sourceforge using Datamining Association Rule // 2010 International Conference on Distributed Frameworks for Multimedia Applica.

124. EvanLi/Github-Ranking [Электронный ресурс] // Github. URL: https://github.com/EvanLi/Github-Ranking (дата обращения: 28.05.2024).

125. Fang Y., Neufeld D. Understanding sustained participation in open source software projects //Journal of Management Information Systems. - 2009. - vol. 25. - no. 4. - pp. 9-50.

126. Fang Y., Neufeld D. Understanding sustained participation in open source software projects // Journal of Management Information Systems. - 2009. - vol. 25. -no.4. - pp. 9-50.

127. Feitelson, D. G., Heller, G. Z., Schach, S. R. An empirically-based criterion for determining the success of an open-source project // Australian Software Engineering Conference (ASWEC'06). - 2006.

128. Futoran, G. C., Kelly, J. R., McGrath, J. E. TEMPO: A Time-based System for Analysis of Group Interaction Process // Basic and Applied Social Psychology. -1989. - vol. 10. - no.3. - pp. 211-232.

129. George J. M., Brief A. P. Feeling good-doing good: A conceptual analysis of the mood at work-organizational spontaneity relationship //Psychological bulletin. -1992. - vol. 112. - no. 2. - pp. 310.

130. Gerosa M. et al. The shifting sands of motivation: Revisiting what drives contributors in open source // 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). - IEEE, 2021. - pp. 1046-1058.

131. Ghapanchi, A. H. Investigating the interrelationships among success measures of open source software projects // Journal of Organizational Computing and Electronic Commerce. - 2015. - vol. 25. - no. 1. - pp. 28-46.

132. Gilson L. L. et al. Putting the "TEAM" back into virtual teams // Organizational Dynamics. - 2021. - vol. 50. - no.1. - 100847 p.

133. Grewal, R., Lilien, G. L., Mallapragada, G. Location, location, location: How network embeddedness affects project success in open source systems // Management science. - 2006. - vol. 52. - no. 7. - C. 1043-1056.

134. Grishin, V. I., Boichenko, A. V., Lukinova, O. V. Information Society: Causes, Features and Risks // International Session on Factors of Regional Extensive Development (FRED 2019). - Atlantis Press, 2020. - pp. 545-549.

135. Grossman, R., Nolan, K., Rosch, Z., Mazer, D., & Salas, E. The team cohesion-performance relationship: A meta-analysis exploring measurement approaches and the changing team landscape // Organizational Psychology Review. - 2022. - vol. 12. - no.2. - pp. 181-238. - DOI: 10.1177/20413866211041157.

136. Han, S., & Kang, M. Combinations of Conditions for Network Effectiveness: A Fuzzy-Set Qualitative Comparative Analysis of 37 International Development Intervention Cases // VOLUNTAS: International Journal of Voluntary and Nonprofit Organizations. - 2021. - vol. 32. - no.4. - P. 731-749. DOI: 10.1007/s11266-021-00358-2.

137. Hartnell, C. A., Ou, A. Y., & Kinicki, A. Organizational culture and organizational effectiveness: A meta-analytic investigation of the competing values framework's theoretical suppositions // Journal of Applied Psychology. - 2011. - vol. 96. - no.4. - pp. 677-694. - DOI: 10.1037/a0021987.

138. Hata H. et al. GitHub Discussions: An exploratory study of early adoption // Empirical Software Engineering. - 2022. - vol. 27. - pp. 1-32.

139. Hayton, J. C., Allen, D. G., Scarpello, V. Factor retention decisions in exploratory factor analysis: A tutorial on parallel analysis // Organizational research methods. - 2004. - vol. 7, no.2. - pp. 191-205.

140. Heimburger L. et al. Gamifying onboarding: How to increase both engagement and integration of new employees //International conference on applied

human factors and ergonomics. - Cham : Springer International Publishing, 2019. - pp. 3-14.

141. Horiguchi H., Omori I., Ohira M. Onboarding to open source projects with good first issues: A preliminary analysis // 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). - IEEE, 2021. - pp. 501505.

142. Jiang H. et al. Bringing Open Source Communication and Development Together: A Cross-Platform Study on Gitter and GitHub // IEEE Transactions on Software Engineering. - 2024.

143. Johnson D. W., Johnson R. T. New developments in social interdependence theory //Genetic, social, and general psychology monographs. - 2005. - vol. 131. - no. 4. - pp. 285-358.

144. Joy, A., Thangavelu, S., Jyotishi, A. Performance of GitHub open-source software project: an empirical analysis // 2018 Second International Conference on Advances in Electronics, Computers.

145. Kauffeld, S., Grote, S., Frieling, E. Die Diagnose beruflicher Handlungskompetenz: Das Kasseler-Kompetenz-Raster // Zeitschrift für Arbeits- und Organisationspsychologie. - 2000. - vol. 44. - no.3. - pp. 129-140.

146. Kauffeld, S., Lehmann-Willenbrock, N. Meetings Matter: Effects of Team Meetings on Team and Organizational Success // Small Group Research. - 2012. - vol. 43. - no.2. - pp. 130-158.

147. Kaur R., Chahal K. K., Saini M. Understanding community participation and engagement in open source software Projects: A systematic mapping study // Journal of king saud university-computer and information sciences. - 2022. - vol. 34. - no.7. - pp. 4607-4625.

148. Khatoonabadi S. H. et al. On wasted contributions: Understanding the dynamics of contributor-abandoned pull requests-a mixed-methods study of 10 large open-source projects // ACM Transactions on Software Engineering and Methodology. -2023. - vol. 32. - no. 1. - pp. 1-39.

149. Li R. et al. Code of conduct conversations in open source software projects on github // Proceedings of the ACM on Human-computer Interaction. - 2021. - vol. 5.

- no.CSCWl. - pp. 1-31.

150. Li Y., Tan C. H., Teo H. H. Leadership characteristics and developers' motivation in open source software development // Information & Management. - 2012.

- vol. 49. - no.5. - pp. 257-267.

151. Li, J., Ahmed, I. Commit message matters: Investigating impact and evolution of commit message quality // 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). - IEEE, 2023. - pp. 806-817.

152. Lin C., Standing C., Liu Y. C. A model to develop effective virtual teams //Decision support systems. 2008. vol. 45. no. 4. pp. 1031-1045.

153. Long J. Understanding the Role of Core Developers in Open Source Software Development // Journal of Information, Information Technology & Organizations. - 2006. - vol. 1.

154. Martins L. L., Schilpzand M. C. Global virtual teams: Key developments, research gaps, and future directions //Research in personnel and human resources management. Emerald Group Publishing Limited, 2011. - pp. 1-72.

155. McLeod L., MacDonell S. G. Factors that affect software systems development project outcomes: A survey of research //ACM Computing Surveys (CSUR). - 2011. - vol. 43. - no. 4. - pp. 1-56.

156. Medappa P. K., Srivastava S. C. Does superposition influence the success of FLOSS projects? An examination of open-source software development by organizations and individuals //Information Systems Research. - 2019. - vol. 30. - no. 3. - pp. 764786.

157. Morrison-Smith S., Ruiz J. Challenges and barriers in virtual teams: a literature review //SN Applied Sciences. - 2020. - vol. 2. - no. 6. - pp. 1-33.

158. Multi-Label Classification Model From Scratch: Step-by-Step Tutorial [Электронный ресурс] // Huggingface. URL: https://huggingface.co/blog/Valerii-Knowledgator/multi-label-classification (дата обращения: 03.05.2024).

159. O'Connor, C., Miller, K. Organizational Culture and Internal Tensions: A Dialectical Perspective // Management Communication Quarterly. - 2020. - vol. 34. -no.3. - pp. 331- 354. - DOI: 10.1177/0893318920908654

160. Oreg S., Nov O. Exploring motivations for contributing to open source initiatives: The roles of contribution context and personal values // Computers in human behavior. - 2008. - vol. 24. - no.5. - pp. 2055-2073.

161. Peng, G. Co-membership, networks ties, and knowledge flow: An empirical investigation controlling for alternative mechanisms // Decision Support Systems. - 2019.

- vol. 118. - pp. 83-90.

162. Powell A., Piccoli G., Ives B. Virtual teams: a review of current literature and directions for future research //ACM SIGMIS Database: the DATABASE for Advances in Information Systems. - 2004. - vol. 35. - no. 1. - pp. 6-36.

163. Raymond, E. The cathedral and the bazaar // Knowledge, Technology & Policy. - 1999. - vol. 12. - no. 3. - pp. 23-49.

164. Reyes D. L., Luna M., Salas E. Challenges for team leaders transitioning from face-to-face to virtual teams //Organizational Dynamics. - 2021. - vol. 50. - no. 2.

- pp. 100785.

165. Rezgui Y. Exploring virtual team-working effectiveness in the construction sector //Interacting with computers. - 2007. - vol. 19. - no. 1. - pp. 96-112.

166. Santos I. et al. Software solutions for newcomers' onboarding in software projects: A systematic literature review //Information and Software Technology. - 2025.

- vol. 177. - pp. 107568.

167. Schermuly, C. C., Scholl, W. The Discussion Coding System (DCS) - A New Instrument for Analyzing Communication Processes // Communication Methods and Measures. - 2012. - vol. 6. - no.1. - pp. 12-40.

168. Schweik C. M., English R. C. Internet success: a study of open-source software commons. - MIT Press, 2012.

169. Schweik, C. The Dependent Variable: Defining Open Source" Success" and "Abandonment" Using Sourceforge. Net Data. NCDG, 35. - 2009.

170. Sen, R. Open source software development projects: determinants of project popularity // EERI Research Paper Series, 2/2006. - 2006.

171. Senyard, A., Michlmayr, M. How to have a successful free software project // 11th Asia-Pacific Software Engineering Conference. IEEE, 84-91. - 2004.

172. Steinmacher I. et al. Almost there: A study on quasi-contributors in open source software projects //Proceedings of the 40th international conference on software engineering. - 2018. - pp. 256-266.

173. Stewart K. J., Gosain S. The impact of ideology on effectiveness in open source software development teams // MIS quarterly. - 2006. - pp. 291-314.

174. Subramaniam, C., Sen, R., Nelson, M. L. Determinants of open source software project success: A longitudinal study // Decision Support Systems. - 2009. -vol. 46. - no. 2. - pp. 576-585.

175. Tamburri D. A., Lago P., Vliet H. Organizational social structures for software engineering //ACM Computing Surveys (CSUR). - 2013. - vol. 46. - no. 1. -pp. 1-35.

176. Than N. et al. Updating "The Future of Coding": Qualitative Coding with Generative Large Language Models //Sociological Methods & Research. - 2025. - vol. 54. - no. 3. - pp. 849-888.

177. The state of open source software [Электронный ресурс] // Github. URL: https://octoverse.github.com (дата обращения: 03.05.2023).

178. Trinh, H. N. Communication in GitHub projects: a systematic mapping study. - 2022.

179. Tsay, J. T., Dabbish, L., Herbsleb, J. Social media and success in open source projects // Proceedings of the ACM 2012 conference on computer supported cooperative work companion, 2012. - pp. 223-226. .

180. Von Krogh G. et al. Carrots and rainbows: Motivation and social practice in open source software development // MIS quarterly. - 2012. - pp. 649-676.

181. Vuchkovski D. et al. A look at the future of work: The digital transformation of teams from conventional to virtual // Journal of Business Research. - 2023. - vol. 163. - 113912 p.

182. Wei J. et al. Chain-of-thought prompting elicits reasoning in large language models //Advances in neural information processing systems. - 2022. - vol. 35. - pp. 24824-24837.

183. Weick, K.E., Roberts, K.H. Collective mind in organizations: Heedful interrelating on flight decks // Administrative science quarterly. - 1993. - pp. 357-381.

184. Weinstein, M. Active Agency and Organizational Culture: A Process-Oriented Perspective // Human Relations Journal. - 2021. - vol. 74. - no.8. - pp. 12031225. DOI: 10.1177/0018726719876210

185. Xiao W. et al. Recommending good first issues in github oss projects // Proceedings of the 44th International Conference on Software Engineering. - 2022. - pp. 1830-1842.

186. Ye Y., Kishida K. Toward an understanding of the motivation of open source software developers // 25th International Conference on Software Engineering, 2003. Proceedings. - IEEE, 2003. - pp. 419-429.

187. Zhang H. et al. When qualitative research meets large language model: Exploring the potential of QualiGPT as a tool for qualitative coding //arXiv preprint arXiv:2407.14925. - 2024.

188. Zhang, T., et al. Revisiting sentiment analysis for software engineering in the era of large language models // arXiv preprint arXiv:2310.11113. - 2023.

189. Zhao, Y. et al. Evaluation indicators for open-source software: a review // Cybersecurity. - 2021. - vol. 4. - no. 1. - pp. 1-24.

190. Zheng, Y., Yu, S., Harris, A. Investigating Sequence Patterns of Collaborative Problem-Solving Behavior in Online Collaborative Discussion Activity // Sustainability. - 2020. - vol. 12. - no.20. - 8522 p.

Матрица связности социально-психологических феноменов, которые обозначаются в литературных обзорах как факторы/предикторы эффективности совместной деятельности.

г«ои|гк<;МсК1|ННс(1сС(С||е

relationship building 0....1.1....1 ........... 1 .... 4

work practice predictability . » ...... 11..1.1..1...1.1 ..... 7

onboarding support . . 0.........................11

understanding . . . 0......1...............1..2

group identity ....0..1.1.1...1...1..1....1.7

reciprocity 1 . . . . 0 ....................... 1

knowledge integration......0.....1 ... 1 ... 1 1.......4

tea« cohesion 1...1..0.1..11 ............... S

shared responsibility .1 ...... «1..1.1..1.,.1.1 ..... 7

knowledge sharing .1..1..119..1.1..11....1.....9

Alignment of goals t expectations ...1......0...............1..2

contribution culture ....1 ...... 0,..1...1..1.,.,1.S

trust (cognitive I affective) 11... .1111. .0.1.111.11.1.1. ..14

coordination.......1.....0...............1

leadership .1......11..1.0..11..1.1.1...9

group coaaltment ....1 ...... 1...0...1..1....1.S

leadership and engineering......1.....1 , . . e . . . 1 1.......4

quality of goal setting .1 ...... 11..1.1..0...1.1 ..... 7

shared mental nodel ...... ...1. .1.1... 0......1. ..4

low coordination costs ....1 ...... 1...1...0..1....1.5

coaaunlcatlon capacity......1.....1 ... 1 ... 0 1.......4

goal coaaltnent .1....1.1...1.1.11..19 ....... 8

Intrinsic activation ....1 ...... 1...1...1..0....1.S

conflict-handling style .1 ...... 11..1.1..1 ..... 0 ..... 6

Coaaunlcatlon 1.......................e , . . . ij

tea* awareness............1.1. ..1......0...)

Conflict t politics ...1......1...............0.2

nodular task ....1 ...... I...I...I..I....0.S

effective coaaunlcatlon of testing culture ..1 ......................... 01

Рисунок 14 - Матрица связности терминов

Рисунок 15 - Визуальное отображение связи терминов с пометкой наиболее

встречаемых в научной литературе

Расшифровки интервью с разработчиками открытого ПО.

И: Да, вроде, всё включил. Здравствуйте, меня зовут Кирилл. Я провожу исследование для своей диссертации и очень благодарен за то, что вы согласились побеседовать про ваш опыт. Руководство проектной командой для реализации... Беседа пройдёт следующим образом: я хотел бы немного побеседовать с вами, познакомиться, ознакомиться с контекстом вашего проекта, после чего подробно расспросить о том, как вы отслеживаете командное взаимодействие в своём проекте и по каким ориентирам понимаете, что «всё у нас идёт хорошо» или «не очень». Беседа займёт где-то 30 минут, возможно меньше. Я хотел бы вести запись и сделать транскрипцию. Она никуда не уйдёт. Вы не против? Р1: Нет. Я за. Я согласен.

И: Хорошо, спасибо большое. Я хотел бы начать. Если у вас есть вопросы ко мне перед тем, как мы начнём? Р1: Думаю, нет.

И: Супер, спасибо. Вы не могли бы рассказать, для чего нужен ваш продукт? Сейчас это open source-проект. Что он делает, что позволяет разработчикам? Какое у продукта назначение? Р1: Мы с командой разрабатываем библиотеку, которая помогает тестировать программное обеспечение. Когда ты разрабатываешь, хочешь быть уверен, что, внося изменения в уже существующий код, ты не сломал предыдущий код и внёс правильные правки. Обычно в разработке мы пишем тесты. Существует огромное количество разных библиотек для этого, которые решают проблему тестирования. Но они не решают проблему хранения тестовых данных. Например, у вас есть какой-нибудь пользователь. У этого пользователя должны быть разрешения что-то сделать. Если у вас какой-то большой тест покрывает большой участок кода, правильная подготовка состояния приложения может занять много времени: нужно сделать много действий, чтобы подготовить код к нужному состоянию, в котором провести нужный тест. Если всё это делать стандартными средствами библиотек, то это занимает очень много строк кода, что ухудшает читаемость и вообще работу с тестами. В итоге проект начинает деградировать: появляются «code smells» — «запахи кода», сигнализирующие, что качество проекта ухудшается, вместо того чтобы улучшаться.

Изначально мной была придумана история: вынести тестовые данные из тестов и просто их использовать. С моей библиотекой эти данные можно легко получать из файлов. Так как это тесты, мы помогаем сделать их более лаконичными, чтобы разработчик, читающий тест, мог сконцентрироваться на сути и использовать тесты как документацию, вместо того чтобы пробираться через код. Это помогает писать тесты в более декларативном стиле — скорее про подготовку тестового сценария. Наша библиотека встраивается в процесс: она не заменяет уже существующие библиотеки, она только меняет способ получения тестовых данных. А дальше разработчик может использовать привычные ему библиотеки. То есть ему не нужно переучиваться на новый стиль разработки: нужно просто изменить способ подготовки тестовых данных. Это может быть очень удобно.

И: И вы над этим один работаете или у вас есть люди в команде?

Р1: Изначально начинал один, потому что это была моя идея, но сейчас нас трое.

И: Вы не могли бы рассказать, как со временем менялись обязанности внутри вашей тройки? Кто чем занимался и как обстоят дела сейчас?

Р1: Сначала все обязанности были на мне. Постепенно появился второй человек, который поначалу брал баг-фиксы и подобные задачи, чтобы погрузиться. На самом деле библиотека небольшая, поэтому нам не нужно много разработчиков. Сейчас, из-за того что основной функционал более-менее реализован, мы в основном обновляем библиотеку, потому что выходят новые версии языков, новые фичи, и библиотеку нужно адаптировать. Нужно уметь работать с новыми типами данных и т. п. В основном развитие идёт под новые версии. Этим обычно занимается тот, у кого больше свободы по времени: если, например, я загружен на основном месте работы, а выходит новая версия, то я могу делегировать. Плюс, если на нашу библиотеку заводят issues — находят ошибки и т. п. — мы тоже распределяем задачи по времени. Мы заранее оговорили, что у разных людей разное количество свободного времени в течение недели для работы над библиотекой, поэтому стараемся уместиться в эти рамки. Так как это инициатива «для себя», без коммерческой подоплёки, мы стараемся идти друг другу навстречу. Проект интересен всем, и в первую очередь наши пользователи — это мы сами. Как только сталкиваешься с проблемой, которая мешает в реальном проекте, быстро подключаешься и улучшаешь библиотеку. В этом и смысл: библиотека свободная. Как только выходит что-то новое и ты хочешь это использовать — реализуешь это в библиотеке, чтобы не писать костыли в своём проекте.

И: Круто. Я правильно услышал, что обязанности у вас не разделены жёстко: кто может — тот подключается и делает?

Р1: В общем, у нас есть обязанности. Я пытаюсь делегировать задачи, потому что всё-таки менеджерю этот проект. Но задач не так уж много, поэтому в основном берём по мере возможности. При необходимости я помогаю выбрать задачу коллегам. Мы подумываем о реализации нашей библиотеки для других языков программирования. Тогда, возможно, понадобится разработчик, более экспертный в таком языке. Появится экспертиза: например, в библиотеке под Python будет больше отвечать за разработку тот, у кого больше опыта с этим языком, чем сейчас, когда все мы привыкли использовать один конкретный язык. И: Получается, вы распределяете задачи по мере появления? Эти задачи вы придумываете сами или они приходят извне — кто-то комментирует, триггерит, создаёт новую issue? Как формируется поток задач?

Р1: Каждый из нас троих может придумать задачу и внести её в бэклог. Также, так как мы разрабатываем на GitHub, любой пользователь может создать issue, если столкнулся с проблемой. Мы разбираемся: либо помогаем пользователю понять, что это не ошибка, либо, если это ошибка, стараемся встроить её в наш бэклог. Не всегда получается взять задачу здесь и сейчас, но в течение нескольких недель (больше месяца у нас не было) мы возвращаемся и реализуем её. Если накапливается блок багов, то тот, у кого есть желание и время, может взять самую приоритетную ошибку и начать разбираться — или взять не самую приоритетную, но ту, в которой лучше понимает. Даже в маленькой библиотеке есть экспертиза: какой-то модуль писал больше я, какой-то — коллеги. Соответственно, понять проблему у автора получается быстрее, и есть ответственность за написанный код.

И: Я услышал, что вам в основном сыплются issues. Бывают ли люди, которые контрибьютят в ваш проект, кроме этих трёх членов команды?

Р1: Это интересный момент. Я начинал писать библиотеку для себя, чтобы использовать в реальном проекте. Мои коллеги тоже её используют, но они не контрибьютят. Примерно так же происходит с коллегами по основному проекту и с коллегами коллег: они тоже используют библиотеку. У нас есть определённое количество людей, подписанных на нашу библиотеку. Периодически, например, в Java появляется возможность использовать новый тип данных, а наша библиотека не адаптирована под него: она могла читать, но если в тестовых данных были ошибки, вместо того чтобы лаконично объяснить пользователю, библиотека просто падала. Нам предложили добавить поддержку нового типа, и мы её реализовали, хотя это было неочевидно: ожидалось, что всё будет работать так же, как и с предыдущими типами данных, но оказалось, что нужны доработки.

И: Понял: изредка появляются такие моменты, когда очевидно, что нужно доработать, и приходится «трогать» код. Р1: Да-да-да.

И: Как руководителю команды вам приходится держать руку на пульсе состояния проекта. В общем виде: как вы понимаете, что у вас всё идёт хорошо? На что ориентируетесь и за чем смотрите на постоянной основе?

Р1: Самый очевидный с одной стороны и неочевидный с другой аспект — это «звёздочки» на GitHub. По сути, это люди, подписанные на проект: они получают уведомления об обновлениях, отслеживают. Но здесь есть проблема: человек может поставить звёздочку и перестать отслеживать проект, игнорировать уведомления и перестать использовать библиотеку. Как понять, что аудитория активная? Тут помогает Maven Repository: мы публикуем библиотеку и там, и можно видеть количество скачиваний. По количеству скачиваний, по количеству форков (если кто-то пытается решать свою проблему самостоятельно) можно понять, насколько люди заинтересованы продуктом. Наша главная проблема — библиотека нишевая. Есть другие способы получать те же тестовые данные: одна из крупных библиотек их просто рандомизирует, что мне не нравится. Когда читаешь тестовые данные, хочется понимать, что в них есть взаимосвязь, а не случайность. Например, в компаниях номер счёта генерируется из трёх символов фамилии, набора цифр и т. п. Это важно демонстрировать читателю. Мы пытаемся популяризировать наш подход — насколько получается. Р1: Я потерял вопрос, если честно.

И: Обобщу: поскольку проект нишевый и аудитория конкретная, для вас главным показателем, что всё идёт хорошо, являются форки, звёздочки на GitHub (или аналог в другой системе) и скачивания.

Р1: Да.

И: Скачивания и форки показывают, что ваша работа нужна и используется другими командами? Р1: Скачивания показывают, что если мы выпускаем новую версию, люди переходят на неё — это актуально. Базовый минимум, который я создал в самом начале, закрывал 60-70% потребностей, а остальные версии улучшали понятность и удобство использования библиотеки. Нам важно, чтобы люди переходили на новые версии, а не сидели 10 лет на первой. Если каждое новое обновление получает хотя бы столько же скачиваний, как предыдущие, значит, подписчики ждут новую версию и сразу переходят — это признак заинтересованности в продукте.

И: То есть продукт обновляется, и его продолжают скачивать; не обходятся самой первой версией, которая «закрывала»?

Р1: Да-да-да. Можно было бы скачать и перестать пользоваться, а мы видим, что скачивания продолжаются — это помогает отслеживать, что всё хорошо.

И: Можно попросить привести примеры конкретных ситуаций во взаимодействии с коллегами, когда вы понимали, что всё идёт хорошо — не только на уровне «продукт-пользователь», но и внутри команды?

Р1: Было несколько таких моментов, и они были приурочены к выходу новых версий языка программирования и фреймворков, которые мы используем. В команде появляется исследовательский ажиотаж: кроме того, что делаем полезный продукт, мы пробуем то, что обычно не делаем в течение рабочей недели. В больших компаниях есть гэп между выходом новых версий и переходом на них — полгода для языков, а иногда 2-3 года. Чувствуешь, что «мир впереди», а ты отстал. Когда выходят новые версии, увеличивается количество коммитов от двух других разработчиков и моих. Есть подъём коммитов в эти недели. Java выходит весной и осенью (если не ошибаюсь — в апреле/мае и сентябре). За 3-4 недели до и 3-4 недели после — у нас подъём статистики. Плюс, например, библиотека X в Java-мире выходит примерно каждый месяц 23-24 числа, и у нас тоже увеличивается активность: если две недели может не быть ничего, то в эти дни у нас всегда есть коммиты. То есть мы привязаны к циклам других опенсорс-проектов.

И: Угу. К глобальным изменениям языка.

Р1: Да.

И: А «исследовательский ажиотаж» — поясните, что это и как вы его понимаете? Р1: Когда работаешь в обычном проекте, есть промежуток между появлением новых технологий и возможностью их использовать. Вокруг новых технологий нарастает инфоповестка: завезли новые фичи, новые способы писать код — хочется попробовать. Можно переписать устаревающий код под новую версию языка. Например, в одной из версий Java добавили новый тип классов и изменили процесс их создания — нам пришлось вносить изменения, чтобы наш код понимал: это старый вид классов или новый, и корректно их создавать. «Исследовательский» — это когда ты изучаешь технологии через написание реального проекта. Чтение и маленькие «программки в стол» — не тот эффект, что работа над настоящим проектом с реальными пользователями: другой уровень ответственности и более значимый опыт. Опыт, получаемый в нашем опенсорсе, важнее, чем просто почитать про новые штуки в библиотеке или языке. И: Спасибо. Обратная ситуация: когда вы понимали, что всё идёт не очень. Были такие моменты? Р1 : Было два случая. Один раз показалось, что всё идёт не очень, но всё было ок; второй раз — действительно было не очень. Первый случай: количество звёзд не то чтобы уменьшилось, но количество скачиваний снизилось. Оказалось, это были периоды «чёрной пятницы», Нового года и т. п., когда обычно вводят запрет на изменения кода, чтобы не вносить рисков. В эти периоды количество скачиваний новых версий уменьшается — мы попали в это окно. Никому библиотека в этот момент не была нужна, потому что написание кода в больших проектах (банки и т. п.) приостанавливается. Это было тяжело отследить, но мы посмотрели на свои проекты, обсудили с коллегами, разослали опросник — нам ответили около 100 человек, и мы увидели тенденцию. Для нашей библиотеки — это значимая выборка.

Во втором случае один из участников начинал брать задачи и писать код, но выглядело так, будто он берёт задачи ради самого факта. Количество закреплённых за ним задач всё увеличивалось, а если другой разработчик берёт задачу, ты туда не лезешь — мы стараемся разрабатывать параллельно и не пересекаться, иначе будут проблемы с объединением изменений. В какой-то

момент получилось так, что ни у меня, ни у второго коллеги задач нет, а у него 12-13 задач, некоторые из которых он взял полтора-два месяца назад — и не двигает. Мы поговорили: человек переживал, что, в отличие от нас, он меньше работает в опенсорсе, и пытался создать эффект деятельности. Мы прошли кризис: взяли эти 12 задач, я помог с тайм-менеджментом и расставлением приоритетов, часть задач снял и делегировал второму разработчику, часть взял на себя. Это в основном был баг-фиксинг, без новых фич. Ситуация была такой, что человек публиковал коммиты, «процесс шёл», но конца не было видно — процесс ради процесса. Сейчас этой проблемы нет; мы стараемся с пониманием относиться — жизнь может быть напряжённой, времени не хватает.

И: Любопытно. В завершение: как вы оцениваете проект — успешен он сейчас или нет? Р1: Если сравнивать с «мастодонтами», у которых в первые часы после публикации — сотни тысяч скачиваний, то, конечно, нет. Но для нас, учитывая, что мы начинали с 2-3 скачиваний, а сейчас их несколько тысяч, — прогресс ощутимый. Нам пользуются, мы постоянно получаем фидбек: «здесь неудобно», «зачем вы это изменили» и т. п. Есть костяк заинтересованных людей в рамках GitHub — это значимо. Я знаю библиотеку в другом опенсорс-проекте, где всего два разработчика, но ей много кто пользуется. Мы чувствуем, что можем держать не худший уровень качества, и наличие пользователей толкает нас развивать библиотеку. В какой-то момент начали появляться внешние контрибьюторы, которые приходят, создают issue и сами её решают — делают коммиты. Им пишут комментарии — попросить что-то поправить, потому что человек новый и может не знать нашу культуру. Он правит — и мы мержим. Ты тратишь 20-30 минут, а человек — дни или недели, решая свою проблему, — библиотека становится более универсальной. Но тут есть сложность продуктового управления: надо понять, нужна ли нам вообще эта функция, или она нужна только конкретному человеку.

Р1: Это интересный челлендж менеджмента. Мы пытаемся подсматривать, как развиваются крупные проекты в Agile. У нас библиотека для Java, поэтому мы в основном на эту инфраструктуру смотрим.

И: Как выстраиваете вижн — направленность, куда будете развиваться?

Р1: У нас понятное видение: мы хотим сделать библиотеку, которая помогает получать тестовые данные. Сейчас концепция такая: мы храним тестовые данные в файлах; библиотека поглощает их и превращает в объекты — живём в объектно-ориентированных языках. Одна из основных проблем — данные могут устаревать, поэтому мы защищаем данные от устаревания. Есть перечень принципов: когда разрабатываешь новую фичу, нужно думать — помогает ли она удобно получать данные; понятно ли это пользователю; защищает ли новый функционал от устаревания или неправильности данных. Например, в Java есть аннотации: поле — это всегда e-mail, значит в нём должен быть набор символов, потом «@», потом доменная часть. Когда читаем тестовые данные, хотим убедиться, что это действительно e-mail, а не белиберда. Нам нужно быть уверенными, что пользователь случайно не ошибся, чтобы сохранить целостность данных.

Плюс зона производительности. В больших проектах тестов много — тысячи, десятки тысяч. Повезло, что сейчас живём в мире микросервисов, и кусочки меньше, чем 10 лет назад, когда проект мог быть на 200 000 строк кода — и тестов, например, 50-60 тысяч. Если каждый тест увеличивается при запуске на секунду, то 50 000 секунд — это очень долго. Мы работаем над производительностью — это фактор, из-за которого от библиотеки могут отказаться. Если она непонятная, если данные устаревают — это один кейс. Мы абстрагировались от решения других

проблем: не хотим писать очередное решение для моков объектов и т. п. Мы лишь помогаем получать данные, чтобы моки были релевантны, а читающий код понимал бизнес-правила: например, курьер может перейти из статуса «активный» в статус «взял заказ», из «взял заказ» — в «сдал заказ»; он не может «закончить смену» напрямую. Эти правила должны транслироваться в тестовых данных. Мы концентрируемся на этих трёх задачах: удобство получения, понятность и защита от устаревания/ошибок. Если новая фича не удовлетворяет этим трём показателям, её нужно доработать или не вносить.

Есть ещё расширение «вширь»: поддержка разных типов данных. Если кто-то говорит: «я использую библиотеку X, там есть такая штука, и мне нужно её получить», а мы понимаем, что, чтобы поддержать, придётся тянуть эту библиотеку к нам — это увеличивает связанность и ухудшает ситуацию. Мы стараемся ограничивать зависимости: чем больше внешнего, тем больше причин пользователям не использовать нас. Больше зависимостей — больше потенциальных уязвимостей и больше работы по их устранению. Поэтому не вносим новые зависимости без крайней необходимости. Это техническая часть. Первая — больше про использование библиотеки; третья — про техническую составляющую.

И: Спасибо большое. Я понял, что ключевая цель и вижн — библиотека, которой удобно пользоваться. Исходя из этого, вы держите три направления и технические особенности: минимизация зависимостей и уязвимостей, адаптация под пользователя и под новые версии. Моё время вышло, кажется, я задал все вопросы. Спасибо за интервью и до свидания.

И: Да, К., здравствуйте. Спасибо большое, что согласились принять участие в интервью. Оно пройдёт следующим образом: я хотел бы немного побеседовать с вами, познакомиться, больше узнать контекст и ваш продукт, который вы разрабатываете, после чего — чуть подробнее про взаимодействие в команде: как вы, как мейнтейнер, отслеживаете, что всё с проектом хорошо или что-то с ним не очень. Скажите, пожалуйста, перед тем как мы начнём, есть ли у вас ко мне вопросы? Р2: Пока нет.

И: Тогда я хотел бы у вас спросить: вы не могли бы рассказать немного про ваш продукт — что это, каково его назначение, зачем он? Спасибо.

Р2: Open source — это чисто про выкатывание новых фичей. Наш продукт — это библиотека для загрузки картинок под Android. Мы предоставляем API, которое позволяет разработчикам с нуля импортировать нашу библиотеку и загружать изображения. Мы предлагаем ряд оптимизаций. Р2: Да. Мы предлагаем ряд оптимизаций, например: мы кэшируем изображения, чтобы не тратить трафик. Если приложение работает по мобильной сети, мы предлагаем разные способы изменения изображений. Например, если разработчик хочет кэшировать не оригинальную картинку, а уменьшенную — допустим, 10*10 пикселей, — под конкретное место в интерфейсе, где картинка очень маленькая, то можно кэшировать только финальную, уменьшенную версию. А можно кэшировать оригинал. Мы предоставляем различные способы это сделать — для разных проектов оптимальные стратегии кэширования могут отличаться. Если картинка используется во многих местах, проще хранить оригинал и затем делать ресайз. Если используется только в одном месте — разумнее хранить финальную небольшую версию.

Р2: Также мы предоставляем различные способы изменения изображения — так называемые трансформеры. Разработчик может имплементировать API «трансформера», который позволяет

накладывать разные эффекты и маски на оригинальную картинку. Например, сделать аватар круглым вместо квадратного или наложить блюр и т. п. И: Угу. А вы всё это один делаете?

Р2: Нет. У нас команда из четырёх человек. В целом мы стараемся избегать «бутылочных горлышек», когда один разработчик занимается только одной вещью, а другой — другой. Такой способ разработки может поставить команду в тупик, если кто-то уйдёт, а остальные никогда этой частью не занимались. Поэтому мы распределяем разные задачи между разными разработчиками, чтобы каждый в целом понимал, как работает весь проект. И мог подхватить в случае чего.

Р2: Да-да. Если нужно срочно что-то сделать и один разработчик не успевает, мы можем распараллелить работу между несколькими разработчиками и успеть вовремя. И чтобы не было ситуации, когда кто-то «сидит полгода и въезжает», у нас в большинстве своём каждый разработчик может взять любую задачу и выполнить её. И: То есть у вас универсальные ребята, получается? Р2: Да.

И: С этим я разобрался. А у вас проект коммерческий или вы занимаетесь им помимо основной работы? Как устроено финансирование: пожертвования от аудитории или это сайд-проект, который вы делаете в дополнительное время?

Р2: Вообще наш проект изначально развивался как сайд-проект: было интересно применить профессиональные знания и сделать что-то стоящее. Потом нашлись сторонники, которым тоже интересно этим заниматься. Да, тут может казаться противоречием: я говорю, что нужно срочно выполнять задачи, а потом — что это сайд-проект.

Р2: Итак, изначально проект начинался как сайд-трек, и мейнтейнеров постепенно стало больше. Обычный процесс: чем больше опыт в проекте, тем больше людей хотят участвовать; таким образом разрастается кодовая база, и одному уже сложно за всем следить — поэтому и разработчиков становится больше.

И: Вы членов команды искали среди знакомых или среди контрибьюторов? Были активные контрибьюторы, которые вкладывали больше, или приходилось искать среди знакомых и приглашать?

Р2: В большей степени это изначально незнакомые люди. Обычно сложно найти среди знакомых тех, кто интересуется опенсорсом и готов тратить своё время. Подбор правильных прогеров, это основное, что может быть. Поэтому чаще это контрибьюторы, неизвестные нам заранее. Р2: Как это происходит? Обычный контрибьютор сначала становится пользователем библиотеки. В какой-то момент его начинает интересовать технология и сама библиотека; он начинает разбираться глубже. Потребитель — это «пассажир», а контрибьютор уже вникает. Так разрастается сообщество контрибьюторов.

И: Как мейнтейнер, на что вы в первую очередь обращаете внимание, чтобы понять, что с проектом всё идёт хорошо?

Р2: Во-первых, нужно смотреть, что проект развивается: вещи, которые нужны пользователям, реализуются. Если какая-то фича или релиз по какой-то причине идут от идеи до завершения год — это, наверное, не очень хорошо: либо не хватает времени (это сайд-проект, свободного времени не всегда хватает), либо есть другие проблемы, и проект тормозится, а фичи «пилятся» слишком долго. И: Угу.

Р2: Так... Каким был вопрос?

И: Я спрашивал про длительность создания фичи — я понял, записал. А на что ещё вы обращаете внимание? Когда понимаете, что всё идёт как надо? Может быть, пример, когда проект развивается так, как вы планировали?

Р2: Как ни странно, один из признаков развития — когда количество issues в проекте растёт. Это говорит о том, что людям интересен проект: они пользуются, приходят и говорят, что где-то что-то не так, что-то нужно добавить или починить. Так можно понять, что проект набирает популярность. И это главный критерий: в опенсорсе, если нет пользователей, нет и смысла в проекте. Соответственно, рост пользовательской базы — главный признак; он говорит и о качестве продукта.

И: Угу. То есть, когда люди создают issue, это значит, что продукт им нравится, они заинтересованы, но им чего-то не хватает; при этом сами они не всегда готовы разрабатывать. Р2: Да. Гораздо проще сообщить разработчикам, что нужно что-то поправить или добавить. В большинстве случаев, если это не большая компания, пользователи не готовы сами разрабатывать продукт. И: Угу.

Р2: Да, гораздо проще написать разработчикам, что нужно поправить.

И: Как у вас в команде распределяются действия? Вы сказали про ответственность, а как распределяются доработки по задачам: issue попадает к вам — что дальше происходит, и кто её берёт? Как это организовано? Вы делегируете, назначают сами — как устроен процесс? Р2: Угу. У нас нет запрета вроде «какие-то разработчики могут брать только какие-то issues». Во-первых, мы смотрим на сложность: есть простые задачи, которые могут сделать новые мейнтейнеры, ещё не погружённые в проект. А есть запросы на сложные фичи или баги, которые «с первого раза не ложатся» — ими занимаются более опытные мейнтейнеры: либо просто сильные разработчики, либо те, кто давно поддерживает проект. И: Угу-угу. То есть вы перекидываете это условно на более опытных участников. Р2: Да-да-да. Но при этом, если у новичка есть желание и он проявляет активность — переписывается с пользователями и т. п., — он может взять сложную фичу. Главное — предупредить других мейнтейнеров. Он берёт фичу и делает, а потом мы, естественно, проводим ревью кода: смотрим, насколько хорошо реализована фича.

И: То есть если включается разработчик с меньшим опытом, вы усиливаете контроль за его

кодом.

Р2: Да.

И: Теперь об обратной стороне: когда с проектом что-то идёт не так. Были ли конкретные ситуации, когда вы понимали, что проект идёт не по плану?

Р2: Бывает. Есть циклы, когда по тем или иным причинам проект перестаёт активно поддерживаться как раньше. Это связано с личной заинтересованностью мейнтейнеров: не все готовы тратить время на поддержку. Проект может «затухать» ровными периодами: активная разработка — выпуск мажорной версии — затем скорость падает на довольно долгий период, а потом снова набирает оборот.

И: Угу. То есть периодичность и цикличность связаны с процессами разработки или с личными обстоятельствами?

Р2: Причин много. Одна из основных — как я сказал — колебания заинтересованности разработчиков.

И: Угу. Р2: В проекте.

И: Из-за переключения на основную работу? Или потому, что после большой версии остаются не самые важные истории — issues, которые нужно пофиксить?

Р2: Бывает и так, и так. Часто разработчик приходит, проявляет активность несколько месяцев, иногда год, а потом ему надоедает — и он уходит в другой проект или занимается только основной работой. Вторая причина — не всегда хватает квалифицированных программистов. Часто проект держится на одном-двух людях, которые хорошо его знают. Остальные либо не очень сильные разработчики, либо участвуют нерегулярно. Так возникает «бутылочное горлышко» в виде тех самых сильных разработчиков.

И: Правильно ли я услышал, что для устойчивости проекта важно отсутствие «бутылочных горлышек» и разделённое между участниками представление о том, что мы делаем, — чтобы не было одного человека, который всё знает, а остальные не включены?

Р2: Цель именно такая. Но этих разработчиков нельзя просто «взять с улицы» на зарплату: проект преимущественно некоммерческий. В большинстве случаев всё держится на энтузиазме. Сильных разработчиков «переманить» из других open source-проектов обычно невозможно. По сути, небольшие опенсорс-проекты — это площадка, где разработчики учатся и повышают профессиональные навыки. Поэтому сильные разработчики чаще сидят на старых и популярных проектах.

И: Угу. Благодаря которым они уже приобрели этот опыт. Р2: Да

И: Хорошо, спасибо. В завершение: что вам приходилось предпринимать, когда в команде что-то шло не так? Что вы делали как администратор, когда видели негативную динамику? Р2: Были случаи, когда мы вводили серьёзные баги в новых версиях. Нам приходилось откатываться и сообщать пользователям, что новую версию использовать нельзя. Такие случаи, конечно, влияют на репутацию проекта. После них стараешься более осознанно тестировать финальные версии релиза.

И: А почему такие релизы происходили: кто-то не досмотрел? По какой причине это случалось? Р2: Одна из причин — на ревью. Процесс ревью был нестрогим, и ревьюер пропустил ошибку в коде нового разработчика. После этого мы ввели практику более тщательного ревью и желательно — чтобы approve давали два и более человека: как минимум двое должны посмотреть финальный код.

И: У разработчика не было опыта в вашей специфике или это проблема интеграции его кода? Р2: Скорее второе. Разработчик очень опытный, но конкретно с нашим типом разработки он не был знаком, из-за некоторых тонкостей допустил неочевидные ошибки. И: Угу. То есть это проблема интеграции.

Р2: Я бы сказал — проблема онбординга новых разработчиков. Решение — подготовить README, где описаны архитектура и базовые подходы, чтобы новичок мог быстро понять, как работает проект.

И: Понял. И вы усилили контроль за кодом нового человека — чтобы несколько людей могли

посмотреть.

Р2: Да.

И: Хорошо, К., спасибо большое за интервью. Я заканчиваю запись.

И: Здравствуйте, меня зовут Кирилл Панов. Я социальный психолог, исследователь. Спасибо большое, что согласились принять участие в интервью. Оно пройдёт следующим образом: мы немного побеседуем и познакомимся; я хотел бы узнать подробности про контекст создания и развития вашего продукта, после чего — разобрать конкретные ситуации: как вы, как администратор проекта, руководитель, следите за состоянием проекта — когда всё идёт хорошо, а когда не очень. На конкретных примерах обсудим, за чем именно вы следите, чтобы поддерживать рабочее состояние как в команде, так и в самом проекте. Скажите, пожалуйста, есть ли у вас вопросы перед тем, как мы начнём?

Р3: Привет! Меня зовут А. Пока сходу вопросов не приходит, поэтому, думаю, можно начинать интервью — по ходу дела разберёмся.

И: Скажите, пожалуйста, можете ли вы рассказать немного о вашем проекте и о его назначении? Для чего он используется людьми, чем полезен сообществу?

Р3: У нас небольшая команда из десяти человек; мы занимаемся проектом по разработке интеллектуального видеонаблюдения.

И: Правильно ли я понимаю: у вас есть собственный продукт/опыт, который вы предлагаете разным компаниям как проприетарное решение, и дальше поддерживаете его использование? Или вы отдаёте проект внутрь их команды?

Р3: Скорее второй вариант: мы предоставляем доступ к продукту и дальше занимаемся его поддержкой на конкретных площадках. Если у заказчика появляются идеи по доработке, то мы реализуем их сами. В основном разработку ведём силами своей команды.

И: Скажите, пожалуйста, команда, которая работает над продуктом, — это сотрудники на зарплате или добровольцы? Как устроено?

Р3: В основном команда работает на зарплату, но есть и добровольцы, вносящие вклады. Бывает, что нам не хватает разработчика или аналитика и сейчас нет бюджета, чтобы нанять. Тогда мы ищем помощи: приходят молодые специалисты с небольшим опытом или без него и соглашаются помогать нам за опыт в течение примерно полугода. По окончании этого «испытательного срока» мы можем принять человека в команду и платить зарплату. Иногда набираем нескольких стажёров, которые работают «за опыт».

И: Понял. А остальные члены команды? Они приходили как контрибьюторы и потом переросли в команду или изначально набирались по вакансиям/по знакомым? Расскажите подробнее, как собиралась команда.

Р3: Изначально, когда возникла идея продукта, пробовали через друзей, сообщества, даже через HeadHunter: менеджер проекта, который придумал концепцию, публиковал вакансии на разработчика, инженера и аналитика. Нашли технических специалистов, заложили основу проекта. Дальше подключали людей через знакомых и друзей — находили нужных разработчиков и аналитиков. По мере роста продукта всё чаще находили сотрудников по рекомендациям, всё реже пользовались площадками вроде HeadHunter. В небольшой команде важны доверительные отношения, поэтому, когда кто-то приводит своего друга, почти уверены, что это хороший специалист и нам подойдёт и по «вайбу», и как профессионал. И: Как в вашей команде из десяти человек распределяются обязанности?

Р3: Вначале, когда нас было три-четыре человека, каждый делал всё, чтобы любой мог подменить другого, если кто-то отсутствует, и проект не простаивал. Со временем команда выросла, роли стали чётче. У нас несколько человек занимаются разработкой бекенда, есть один фронтендер, есть два специалиста, которые занимаются обучением нейронных сетей — мы их

называем аналитиками. Ещё двое инженеров отвечают за развёртывание решений и инфраструктуру (сетевое взаимодействие, виртуальные машины и т. п.). И есть менеджер проекта, который всем управляет. При этом, так как команда маленькая, мы видим, кто чем занимается, и любой может подменить другого при необходимости: все разбираются понемногу во всём, помимо своей специализации. Здесь лишь важно, чтобы команда создалась сплоченная и слаженная.

И: Чтобы была возможность подмены в случае чего. Р3: Да, всё верно.

И: Как вы, находясь внутри команды, понимаете, что работа идёт как надо? На что смотрите в первую очередь?

Р3: Как и многие ИТ-проекты, мы работаем по Agile. Используем Jira и делим разработку на спринты по две недели. На каждый спринт закладываем задачи на каждого члена команды и оцениваем их в стори-пойнтах (условно, один стори-пойнт — это один полноценный рабочий день без отвлечений). Автор задачи оценивает её вместе с исполнителем. В двухнедельный спринт (10 рабочих дней) закладываем 8 стори-пойнтов, оставляя несколько дней на форс-мажоры: созвоны, блокеры и т. п. В конце спринта смотрим, кто сколько задач закрыл; ведём статистику по каждому члену и по команде в целом: сколько задач создано, сколько закрыто, добавлялись ли новые в ходе спринта, что убиралось. Если закрыли меньше ожидаемого, разбираем причины по каждому случаю. Раз в месяц проводим ретроспективу: каждый рассказывает, что понравилось, что нет, что хотел бы улучшить. По итогам формируем улучшения в виде задач в Jira и распределяем ответственность. Таким образом, проблемы любого характера превращаем в задачи и решаем. Оценка эффективности — это, по сути, сколько стори-пойнтов команда закрывает за спринт и насколько стабильно это получается. И: То есть опираясь на этот количественный показатель, вы судите об эффективности разработки. Р3: Да, в части закрытия задач — так. Нужно вывести фичи.

Р3: Но кроме этого есть бизнес-цели: нужно зарабатывать деньги. На площадках у заказчика есть люди, которые взаимодействуют с нами.

Р3: Перед выкатыванием решения на площадке сначала оценивается его экономическая эффективность. Есть специалисты, которые считают, сколько денег мы сэкономим заказчику, если реализуем решение. Это называется экономический эффект.

Р3: Экономический эффект предварительно рассчитывается и защищается перед заказчиком. Затем мы реализуем проект и по итогам контрольного периода проверяем, сошлись ли расчёты с фактом. Если есть расхождения, обсуждаем, что с этим делать дальше.

И: Хотел бы услышать обратные примеры: когда вы видели негативное развитие проекта. Какие это были ситуации и какие индикаторы показывали, что всё идёт не так?

Р3: Был проект: нужно было детектировать, что во время ремонтных работ человек находится в страховочной системе, чтобы в случае падения всё было хорошо. Оказалось, что проект экономически неэффективен: явной экономии нет. Мы не хотели его делать. Но заказчик настаивал, объясняя, что важна не экономическая эффективность, а престиж и моральная значимость — контроль безопасности людей. Были реальные случаи падений со смертельным исходом. Часть команды хотела заняться этим из идейных соображений, часть — нет, так как на этом ничего не заработаем. Возникли разногласия. Решили так: тех, кому это не нравилось, перевели на другие проекты; несколько человек, согласившихся делать это «для кармы»,

остались и довели решение до конца. В портфолио этот проект есть как пример, что мы можем сделать и что сохраняет жизни, но экономического эффекта для нас он не принёс. И: То есть негативным индикатором стало расхождение ценностей внутри команды относительно бесплатного, но социально значимого проекта; в итоге вы перераспределили людей.

Р3: Да, всё верно.

И: А теперь пример, когда всё шло особенно хорошо — ситуация, выделяющаяся из обычного процесса. На что вы там обращали внимание?

Р3: Был проект: по видеокамерам нужно было отследить полный цикл работы с цистерной, приезжающей в ангар: подготовка, выкачивание содержимого, перемещение. Пришлось связать много технологий, в том числе интегрироваться с ^^системами: забирать показания датчиков и связывать их с видеоаналитикой, прошивать большую логику. Было много непредвиденных ситуаций: нейросеть учится на определённых паттернах, а данные меняются; заказчики не всегда понимают, как это устроено, и дают неверные исходные данные — приходится переобучать. Камеру могут перевесить — всё ломается. Было много итераций. В итоге мы реализовали систему, и заказчику она настолько понравилась, что нас начали рекомендовать повсюду — пошёл поток новых запросов. Система ещё и вскрыла серьёзные недоработки подрядчиков: то, что можно было сделать за несколько часов, у них занимало сутки. Когда начали фиксировать процесс, они стали работать быстрее — настолько, что предприятие физически не успевало обрабатывать объём. Пришлось «притормозить». Это пример, когда решение оказалось слишком эффективным.

И: Получается, всё шло хорошо не только потому, что вы получили опыт интеграции разных систем и подразделений, но и потому, что достигли сверхрезультатов и получили новые запросы. Р3: Верно. После этого мы начали придумывать другие штуки — делать «микростартапы» внутри команды. Обычно мы работаем со стационарными камерами на предприятиях; но бывают работы «в полях», где нет проводной связи. Мы интегрировались с ребятами, которые собирают портативные камеры: покупают обычные камеры, силовые банки, диски — делают переносную микростанцию. Мы научились ставить свои нейронные сети прямо на их камеры. Получается штатив с камерой в защитном кожухе: можно поставить где угодно, она снимает и пишет в архив, а дальше видеоматериалы обрабатываются и ищутся нарушения. Такие решения тоже стали делать.

И: То есть внутри команды формируются временные группы под запрос, своего рода команды небольших стартапов.

Р3: Да, у нас такое часто. Приходит идея — выделяем небольшой бюджет и несколько людей. Если идёт хорошо, выделяем полноценные ресурсы и взаимодействуем с другими командами, создавая новый продукт.

И: Это пришло органически или стало результатом управленческого решения? Р3: Скорее результат управленческого подхода. Когда человек долго делает одно и то же, ему становится неинтересно. Руководителю важно искать новые кейсы, чтобы люди развивались. Даже когда в продукте всё хорошо — есть деньги и интересные задачи — важно разнообразие. Один из разработчиков, стоявших у истоков, хотел уйти: достиг потолка, новых кейсов не было. Тогда мы три года назад начали сознательно развивать новые направления — и это сработало: текучка очень маленькая; если и уходят, то по личным причинам (переезд и т. п.), а не из-за скуки.

И: Спасибо. И в завершение: сейчас ваш проект в какой фазе — всё идёт своим чередом, поддержка, развитие?

Р3: Сейчас мы реализовали все взятые кейсы и временно не берём новые: сосредоточились на поддержке и модернизации. В условиях общего экономического кризиса решили не закупать дорогое железо, а заниматься оптимизацией. По сути, есть два пути увеличения производительности: купить мощнее железо или оптимизировать код. Мы выбрали оптимизацию: профилируем сервисы, переписываем узкие места, используем многопоточность и асинхронность, убираем неиспользуемое. Уже получили трёхкратный прирост в ряде сервисов: то, что раньше жгло три ядра, теперь работает на одном.

Р3: Когда это всё писалось, опыта было меньше. Ещё мы активно участвуем в конференциях по разработке и нейросетям: не просто посещаем, но и выступаем с докладами, получаем рекомендации от коллег, находим партнёров и кейсы. Это тоже помогает оптимизировать экосистему.

И: То есть вы сейчас нацелены на оптимизацию, чтобы не тратиться на оборудование, и параллельно наращиваете экспертизу через конференции и выступления.

Р3: Да. Мы занимаемся оптимизацией и повышением компетенций, чтобы, когда придёт сезон новых заказов, быть готовы. Поглядываем на новые кейсы на площадках, но пока не вкладываемся: сначала оптимизация, затем — новые заказы и обновления на существующих площадках.

И: Записал. А., спасибо большое за разговор, останавливаю запись.

И: Спасибо вам большое, что нашли время участвовать в интервью Оно пройдёт следующим образом: мы немного побеседуем и познакомимся; я хотел бы узнать подробности про контекст создания и развития вашего продукта, после чего — разобрать конкретные ситуации: как вы, как администратор проекта, руководитель, следите за состоянием проекта — когда всё идёт хорошо, а когда не очень. Если вы готовы, расскажите коротко про ваш проект?

Р4: Я работаю в A. и наша команда сейчас сфокусирована на наборе серверов по протоколу MCP, которые подключают ассистентов к данным и инструментам AWS. У нас десятки серверов, от общих для API до специализированных, например, сервер с актуальной документацией AWS. Пользователи ставят их одной кнопкой в Cursor или в VS Code. Мы публикуем контейнеры в публичный ECR, так что удобно запускать в докере. Над проектом работает команда из нескольких человек, она кросс-функциональная, есть люди, кто ведет конкретные серверы, есть те, кто отвечает за разные клиенты. Сервис сводится к двум сценариям, даем ассистенту доступ к свежим AWS знаниям - актуальные статьи, референсы и посты «что нового». И: Спасибо большое за подробное введение в продукт. Если раскрывать тему, можете, пожалуйста, рассказать, на что вы ориентируетесь, когда понимаете, что проект развивается как надо?

Р4: Как и все, наверное, на количество багов после релиза и откаты изменений. Если что-то в продукте идет не так, получаем сигналы от пользователей. Должна быть установка в клиентах без трения, меньше вопросов в поддержке, стабильные релизы. Если чего-то из этого нет, нам об этом пишут. Иногда получается привлекать внешних контрибьюторов, идут осмысленные PR, значит, мы попали в потребность, команда усилилась. Например, недавно выкатили улучшения и увидели резкий рост установок, плюс PR от внешних команд с расширениями под их пайплайны. Чистые багфиксы, без регрессий. Я не свожу эффективность к количеству фичей. Для

меня она про устойчивость системы, качество кода и то, как быстро мы закрываем issues в обратной связи. Багов не должно быть много, это хороший знак на любом проекте. И: А обратный пример, когда вы понимали, что что-то идёт не так?

Р4: Да, это, правда, давно было. В одном из серверов добавили поддержку новой команды, не добили тесты, пришлось откатывать минорную версию и закрывать баг. В такие моменты я напоминаю команде простую вещь, что best practice, когда четко вовремя говорят, что всё идёт не так. Так работа идёт быстрее, если сигнализировать сразу о проблеме, экономим дни. И: Вы что-то делали в таких ситуациях, как-то реагировали?

Р4: Да, пришлось закрывать дыру в процессе, усилять ревью. Если изменение затрагивает чувствительный код, ревьюят минимум двое, а в самом начале решаем, куда это изменение поставить, в какой из релизов.

И: Вы много рассказываете про техническую составляющую, хотел бы уточнить про взаимодействие в группе, есть ли что-то в нем, что позволяет увеличивать эффективность проекта?

Р4: Тут важны общие вещи, важно чтобы команда была именно командой, сплочённой и слаженной. Тогда нет ненужных конфликтов на профессиональной почве. Слежу за процессом и понимаю, что надо вовремя и быстро убирать мешающих ребят. Хорошие специалисты, крутые, но иногда токсичные, очень сложно коммуницировать. В открытом ПО токсичность дорожает вдвойне, прост теряешь желающих работать над проектом. Если не умеют говорить, это сразу технический долг и slow down.

И: Вернёмся к задачам. Как вы приоритезируете и распределяете работу?

Р4: Мы раскладываем по направлениям. Есть ядро, которое влияет на большинство пользователей, и есть специализированные направления, например отдельные серверы. В ядре соблюдаем короткий цикл релизов и отбираем функции по значимости для проекта. И: А вы как-то действуете, чтобы удерживать добровольцев и внутренних контрибьюторов? Р4: Они сами остаются. Скорее всего из-за возможности влиять на продукт. Появляется видимый результат и ощущение, что вклад нужен. Плюс отношения. Нет опасности задавить чужую инициативу. Она держит проект на плаву и порождает другие активности [неразборчиво]. И: Спасибо, мне стала более понятна специфика разработки открытого ПО, спасибо, что уделили время.

И: Здравствуйте, меня зовут Кирилл. Спасибо, что согласились поучаствовать в этой встрече. Предлагаю кратко познакомиться, а затем подробно обсудить, как вы взаимодействуете с разработчиками, администрируете продукт и на что обращаете внимание в процессе. Вы могли бы рассказать, как вы пришли к администрированию проектов с открытым исходным кодом и чем занимаетесь сейчас?

Р5: Да, могу. Можем постараться уложиться в 10-15 минут? Давайте я сразу к делу перейду. Несколько лет я вёл open source-проект, небольшую библиотеку, параллельно работая инженером в компании. В какой-то момент понял, что хочу расти дальше и становиться ментором, поэтому на следующих этапах взял на себя функции евангелиста: общение с сообществами, перевод между «языком бизнеса» и «языком инженеров», выстраивание мостиков между разными мирами. Меня захватило это, стал рассказывать, как работать с сообществом: проводить тренинги для разработчиков. Если коротко, я «швейцарский нож». Так я бы охарактеризовал свой путь и опыт.

И: Расскажите, пожалуйста, чуть подробнее про вашу работу именно как администратора open source-проекта: как вы к этому пришли и как выстраивалось взаимодействие в команде, формировалась рабочая группа?

Р5: История довольно классическая: мы собрались с друзьями и начали делать свою библиотеку. В какой-то момент поняли, что код полезен не только нам, но и сообществу, и решили открыть его. Дальше прошли проверку лицензий, безопасности, совместимости, подготовили документацию и сформулировали видение проекта. Когда выкладываешь код на всеобщее обозрение, уже не отвертишься: это представлено сообществу, значит должно быть сделано. Важно не просто «залить архив на GitHub», а объяснить, что это за инструмент и для чего он. Если выложить и забыть, люди из сообщества остаются без доработок и обратной связи. Всегда отдельно подчёркиваю важность описания процесса: файл CONTRIBUTING, кодекс поведения, явная цель проекта и траектория развития. Тогда сразу понятно, поддерживается ли проект и есть ли смысл вкладывать усилия, когда ты сторонний контрибьютор.

И: По мере развития вашего проекта как вы понимали, что «всё идёт хорошо», а где не совсем? Р5: Первый критерий - это отсутствие снежного кома багов. Все идет хорошо, если баги планомерно закрываются. Очень плохо, когда их куча и надо расхлебывать. Массовое накопление багфиксов это не только про недочёты, это про риски для качества. Когда копятся баги, замедляется выпуск новых фич, поэтому лучше не допускать их накопления. Второй критерий, это предсказуемость релизов. Эффективный проект — это частота фичей, частота закрытия багов, время небольшое. Все быстро, получил детали, 2 дня, отладка и поехали. Где-то разработку постоянно пушит бизнес, где-то, совсем нет; но предсказуемость важна везде. Р5: Третий критерий, наверное, устойчивость: тестирование, инфраструктурная надёжность и поддержка пользователей. Это фундамент, без которого любые короткие победы превращаются в технический долг и замедление.

И: Вы несколько раз упоминали «видение». Что это для вас и как оно транслируется команде? Р5: Для меня видением является ближайший контур фич: что мы должны сделать как библиотека, чтобы решать реальную задачу разработчика. У нас стабильные релизные циклы, и в каждом релизе мы выпускаем функции, которые не добавляют лишних зависимостей, не утяжеляют установку, но увеличивают полезность инструмента. Мы условно фиксируем Vision 1.0 как набор полезных фич, а раз в несколько релизов синхронизируем приоритеты: например, прилетели issues от пользователей, решаем, берём ли их сейчас или позже, или есть более приоритетные задачи, которые сильнее улучшат положение проекта (чаще добавления в избранное, скачивания). Тренды индустрии тоже влияют: они частично диктуют, что появится в функционале.

Р5: Иногда синхронизация проходит трудно: кто-то из разработчиков уверен, что его фичи нужно делать прямо сейчас, иначе будет сложнее встраивать их потом. Мы в соге-команде, поэтому в начале необходимо договориться о процессе, чтобы вместе пилить продукт и до конца его доводить. Если у тебя самого «размыт» vision, ты не сможешь его транслировать — начинается дёргание туда-сюда. Когда утвердились в общем взгляде, работать становится значительно легче. В прошлом мы даже рассматривали три альтернативные траектории развития и долго обсуждали развилку всей командой.

И: Если открыть ваш проект на GitHub, по каким признакам можно понять, что он развивается как надо?

Р5: Стереотипно судить по «звёздам» и красивому README. Это часть картины, но не вся. Обычно смотрят на частоту релизов, время реакции и работу с новыми контрибьюторами, как мейнтейнеры взаимодействуют с внешними разработчиками. Пример про внутреннюю жизнь: если в команде есть сильный инженер, который токсично коммуницирует, у него большое эго, он не эскалирует проблемы и предпочитает «всё решить в одиночку», это разрушает совместную работу. Из-за эго командная работа может посыпаться: «читай документацию и разбирайся сам», это не дружелюбно и отпугивает. Возникают какие-то склоки, недомолвки, я не очень понимаю, да, из-за чего это происходит сейчас. Обсудил, не договорились, выкатил это в прод. Снимаем, дорабатываем. Фича превращается в костыль.

Р5: Снаружи «здоровый» проект выглядит как непрерывная разработка без откатов назад, прозрачная работа с пул-реквестами, предсказуемые релизы и дружелюбные ревью. Плюс правильный найм и лидерство: важно подбирать людей, способных брать сложные задачи и не «рассыпаться», и при этом постоянно транслировать взгляд вперёд.

Р5: У коллег бывают альтернативные подходы. Кто-то делает акцент на уверенности в «завтрашнем дне» и финансировании: «мы выйдем на окупаемость, вот бюджет». Это важно, но я больше опираюсь на профессионализм и командную работу как механизм, где каждый выдаёт свой best.

И: Как вы мотивируете участников продолжать участие в проекте?

Р5: Развитием: людям интересно дорабатывать инструмент, которым они сами пользуются. По моделям финансирования: у нас сейчас донаты; где-то помогают гранты (часто их недостаточно), где-то компанию интересует функция, она финансирует разработчиков. У нас пока упор на энтузиазм и прокачку навыков.

И: Что происходит, если видение не выработано заранее?

Р5: Простой, но показательный кейс: одна команда изменила лицензию, чтобы ограничить использование продукта облачными провайдерами. Крупный провайдер сделал форк и начал развивать его независимо; большая часть сообщества ушла туда. Вывод: вопросы коммерциализации и правил использования нужно решать заранее и встраивать в Vision. Плюс понятные правила: любое изменение должно приносить пользу сообществу. На митапах я подчёркиваю важность постоянной обратной связи и контакта с сообществом: это люди, которые помогают дорабатывать продукт.

И: Вы упоминали, что главное - это люди и процессы. Что вы вкладываете в «процессы»? Р5: Это набор прозрачных правил, как мы делаем продукт. Регулярные синки, чтобы обсудить не только прогресс по фичам, но и как был выстроен сам процесс работы, и отметить достижения. Правила взаимодействия с сообществом: я прошу ребят делать дружелюбные ревью, иначе мы отпугнём «новую кровь». Предсказуемые релизы тоже часть прозрачности: пользователи ориентируются по ним, формируют ожидания.

Р5: В соседних проектах видно, как погоня за «хайповыми» генеративными функциями без внимания к стабильности приводит к огромному техническому долгу. Если уделять внимание только интерфейсу и стабильности, можно проиграть гонку; если гнаться лишь за новыми возможностями, получишь баги и долг. Баланс достигается за счёт людей и процессов, которые удерживают фокус и темп.

И: Если коротко, как бы вы сформулировали главный маркер «здорового» open source-проекта? Р5: Прозрачные процессы и предсказуемые релизы. Внешние и внутренние разработчики видят результат своей работы и получают поддержку, а проект живёт дальше. Дальше — вопрос

масштаба и времени: получится ли привлечь финансирование или проект останется на изначальной схеме. Главное — прозрачный процесс.

И: Спасибо за беседу. Рад, что это не заняло у вас много времени. Останавливаю запись.

И: Так, запись пошла. Да, П., здравствуйте. Спасибо большое, что согласились принять участие в интервью. Оно пройдёт следующим образом: сначала я хотел бы немного с вами познакомиться, после чего подробно расспросить о контексте разработки вашего продукта и о том, как вы, как мейнтейнер, управляете своей командой в опенсорсе. Хорошо, да. Запись никуда не уйдёт, нужна только мне. Исследование направлено на понимание факторов эффективности совместной деятельности разработчиков открытого программного обеспечения и необходимо для защиты моей диссертации. Если вы готовы, я тоже готов. Р6: Хорошо, да, я готов.

И: Вы не могли бы рассказать немного про свой проект — чему он посвящён, для чего используется другими людьми, каково его значение и краткое описание?

Р6: Наша команда занимается поддержкой нескольких довольно крупных библиотек, которые достаточно массово используются в веб-разработке, в частности в мире РНР-разработки. Библиотеки используются, в том числе, для выстраивания взаимодействия между разными сервисами в банковских системах — и не только в банковских, во многих. Соответственно, нам время от времени поступают запросы в поддержку — на устранение каких-то проблем с этими библиотеками, поскольку они достаточно обширные, а финансирование на них выделяется не то чтобы большое из-за того, что это опенсорс. Они поддерживаются либо силами энтузиастов, либо нами — как ключевыми разработчиками. Не столько авторами, сколько именно разработчиками, которые держат все эти библиотеки «на плаву». К нам либо приходят пользователи этих библиотек с предложениями в виде pull-request'ов, которые мы рассматриваем и даём комментарии по улучшению, либо берём их в работу и мержим в наш код.Соответственно, чтобы убедиться в том, что всё идёт хорошо, мы прогоняем тесты. У нас есть определённый набор автоматизированных и ручных, но в большей степени — автоматизированных тестов, которые позволяют убедиться, что изменения в коде не ломают существующий функционал и обратную совместимость между версиями. Иногда бывает так, что обратная совместимость нарушается, и приходится увеличивать мажорную версию библиотеки — это не очень удобно ни для нас, ни для пользователей, потому что им, как правило, приходится адаптировать больше своего кода, чем хотелось бы. Соответственно, мы стараемся по возможности сохранять обратную совместимость, увеличивая только минорную или патч-версию. И, соответственно, о чём это я? Да. Одна сторона нашей работы — обработка pull-request'ов от сообщества, которое помогает нам поддерживать и развивать продукты. Другая часть — это отработка запросов в баг-трекере: люди пишут, что с чем-то возникли проблемы, приходят с предложениями — «давайте добавим новую фичу».То есть люди приходят не с готовым pull-request'ом, потому что они либо не хотят, либо не знают, как это сделать, но очень хотят, чтобы появилась такая возможность. Соответственно, мы рассматриваем эти предложения и, если по-нашему, скажем так, коллегиальному решению понимаем, что это действительно полезная фича, либо если запрос собирает много голосов от других пользователей библиотеки, мы берём её в работу, проектируем, прорабатываем и покрываем тестами — чтобы убедиться, что это ничего не ломает. Вот таким образом всё развивается. Иногда кто-то из нашей команды лично знаком с пользователями библиотеки из каких-то компаний — например, сотрудники ИТ-отделов банков

несколько раз обращались либо напрямую, если есть знакомство, либо через знакомых, и просили что-то улучшить в проекте. Тогда мы принимали это в работу мимо task-tracker^: просто обсуждали, чего людям не хватает. Примерно так наша работа и построена в общих чертах. И: Скажите, пожалуйста, вы говорите «наша работа». Сколько человек работает над проектом помимо вас, мейнтейнера? И как вы распределяете обязанности по команде? Р6: В общей сложности сейчас четыре человека работают над этими библиотеками: я и ещё трое разработчиков, которые специализируются на разработке вообще и на опенсорс-разработке в частности. Распределяется работа следующим образом. Если нам сообщают о каком-то критическом баге в проекте, который нужно как можно скорее починить, то чаще всего этим занимается тот разработчик, который лучше всего знаком именно с этой библиотекой или ее частью: он быстрее сориентируется, где и что нужно исправить, чтобы не сломать пользователей. А если это что-то не очень срочное, то задачи разбираются произвольно — по желанию: кто свободен, тот и берёт. Таким образом достигаем того, что разработчики примерно равномерно погружены в проекты: при перекрёстной работе они разбираются в задачах, и, если кто-то по какой-то причине выбывает, остальные без особых проблем могут подхватить ту часть проекта, над которой он работал. И: То есть они взаимозаменяемые, условно?

Р6: Мы к этому стремимся, да. Часто бывает так, что один разработчик долго работает над каким-то куском проекта, и другие туда не заглядывают. И этот кусок успевает значительно вырасти. В таких случаях взаимозаменяемость страдает. Но со временем люди так или иначе начинают разбираться во всём проекте — неизбежно, потому что они над ним работают. То есть да, мы стремимся к взаимозаменяемости, но иногда она хромает.

И: Вы не могли бы рассказать больше про особенности вашей работы как мейнтейнера? Как вы понимаете в процессе разработки, что всё идёт хорошо? На что ориентируетесь в первую очередь, либо бьёте тревогу, либо понимаете, что у нас всё нормально?

Р6: Всё нормально банально определяется признаками вроде отсутствия большого количества запросов в поддержку — о том, что что-то идёт не так. Это может быть, как мой личный e-mail (указан в контактах), так и баг-трекер: если там тихо, если нет pull-request'ов с пометкой «исправление критического бага», значит, всё более-менее нормально. Наоборот, мы бьём тревогу, когда вдруг приходит много отрицательной обратной связи и запросов в поддержку. Чаще всего это случается после релиза какой-то версии, которую по какой-то причине мы не до конца хорошо протестировали. Не очень много таких случаев, но если они бывают, то это как раз после релиза, где в каком-то месте код оказался более «сырым», чем нам хотелось бы. В таком случае идём и «латаем дырки».

И: Какие действия вам нужно предпринимать именно как мейнтейнеру, когда всё идёт не особенно нормально — прилетает много сообщений о багах, «ничего не работает»? Р6: Как минимум, нужно оперативно выйти на связь хотя бы с одним разработчиком и вместе разобрать жалобы: понять, что между ними общего — относятся ли они к одной и той же проблеме или это несколько разных проблем. Предпочтительнее, конечно, одна. В таком случае работа устраивается так. Два основных сценария. Если я достучался до разработчика, мы разбираемся, в чём дело, я объясняю, что нужно сделать; как правило, если это баг-репорт в баг-трекере, мы просто берём его в работу, он проходит типичный пайплайн, и выпускается релиз очередной патч-версии — 1.2.1, например. Если по какой-то причине все разработчики вне зоны

доступа (на основной работе заняты своими проектами), то в зависимости от срочности я могу что-то сделать своими руками — навык ещё остался.

И: Как вы распределяете задачи? Когда созвонились с разработчиком — он сам принимает эту задачу, или вы назначаете её? Если я дозвонился до разработчика, определяем, что у него есть время ей заниматься, и он понимает, что нужно сделать. Да, спасибо.

Р6: Он назначается ответственным за эту задачу и ведёт её до конца по нашему процессу. В конце я смотрю pull request; в идеале другие разработчики тоже его смотрят, чтобы понимать, что происходит в проекте. Когда один разработчик долго работает над кодом, глаз может «замылиться», он может не видеть проблем «на поверхности» — для этого и существует code review.

И: То есть другие разработчики смотрят по возможности, а вы — обязательно. Запускаются все тесты, всё это держится, и делается релиз. Мне было любопытно узнать про распределение ответственности. Вы сказали, что в открытом ПО, в отличие от проприетарной разработки, задачи и ответственность распределяются как-то иначе. Видите ли вы разницу в вашем проекте по сравнению с обычной разработкой?

Р6: Возможно, это зависит от проекта. В контексте наших открытых проектов разница не такая большая. Она скорее в том, что у нас нет явных стейкхолдеров, явных заказчиков, поскольку ими фактически является сообщество разработчиков. То есть это своего рода B2B: мы делаем продукт для других разработчиков. Поэтому у нас нет, как правило, явных требований «что хотим получить» — точнее, что сообщество хочет от продукта. В проприетарной разработке есть инвестор/заказчик и достаточно чётко очерченные бизнес-метрики. В случае с открытым ПО в большинстве случаев нет чётких векторов развития: они нащупываются по взаимодействию с сообществом — «у кого что болит». Отличие еще в том, что появляется необходимость удерживать разработчиков. Нужно дать уверенность, что я тоже буду его продолжать, все будет хорошо, условно говоря, кнут прикладывать не получится, нет инструментов. Нужен пряник, и важно держать основных разрабов, иначе будет туго.

И: А сообщество хочет разного. Как вы вырабатываете вижн проекта — то, что будет определять развитие, например, на ближайшие полгода?

Р6: Я бы выделил два основных принципа. Первый: продукт уже имеет какой-то вектор, по которому развивается, и по умолчанию мы идём по нему. Второй: мы смотрим на обратную связь сообщества — какие инициативы собирают наибольшее количество голосов. Если инициатива действительно полезна, мы добавляем её минимум в бэклог и начинаем развивать. Здесь опасность — задавить чужую инициативу. Она держит проект на плаву и порождает другие активности от модов и моделек до трехмерного рендеринга. И: А что, если инициативы сообщества ортогональны изначальному вектору? Р6: Такое случается редко. Я не припомню, чтобы в наших продуктах было прямо так, но если продукт должен развиваться в неожиданном направлении, напрашивается форк: делаем форк библиотеки. Он подтягивает исправления багов и новые фичи из родительской, но при этом обрастает своим функционалом. Пример: есть изначально консольная утилита, с которой работают в терминале. Появляется запрос на пользовательский интерфейс, а основной команде этим заниматься неинтересно. Делается форк: в него подтягиваются все изменения и закрытия уязвимостей из родительской утилиты, а сверху добавляется UI — им занимаются другие разработчики. Это распараллеливается и, пожалуй, это ещё одно отличие от проприетарного ПО, где такое почти не встречается.

И: А у ваших проектов кто-то делал форк?

Р6: Форки случаются постоянно; у наших библиотек их тоже немало. Другое дело, что не каждый форк получает существенное развитие — это видно, например, по числу «звёзд» на GitHub. Иногда у форка звёзд больше, чем у основного проекта, но чаще наоборот. Бывает, идут «ноздря в ноздрю». Если взять WireGuard — протокол для построения VPN-туннелей, — есть российский форк AmneziaWG с дополнительной обфускацией, и у него звёзд сравнимо с оригиналом. Но чаще у форков значимого развития не происходит.

И: Да, с этим я разобрался, спасибо. А были ли ситуации, когда во взаимодействии команды всё шло не по плану — критические моменты, мешавшие разработке? Проблемы коммуникации, выпадение участников?

Р6: Я бы сказал, сталкивались пару раз: разработчики либо теряли интерес к продукту, либо по каким-то причинам не могли им заниматься. Семья появляется, слишком много задач на основной работе и т. п. Если это происходит незадолго до значительных запланированных изменений, это тяжело: релиз следующей версии откладывается, приходится меньшими силами разруливать или искать замену. Бывали проблемы в общении, разговаривать невозможно— большое эго. Разработчик считал, что он круче всех и вместо ответа говорит "читай документацию". Но ни у меня, ни у членов команды иногда времени на это нет. Других проблем не припомню: как правило, всё идёт достаточно гладко. Важно понимать, что разработка открытого ПО чаще всего менее оперативна, чем проприетарного: нет внятных сроков, KPI, инвестиций. Этим люди занимаются на энтузиазме, а энтузиазм — вещь непостоянная. Личный интерес, опыт. Часто человек использует библиотеку в своём проекте, ему не хватает функциональности — он сам дорабатывает и присылает pull-request. Даже если это не постоянный член команды поддержки, он может быть активным контрибьютором. Личный интерес тоже играет роль — помимо прокачки опыта.

И: Спасибо. Ну и в завершение: вы не могли бы сравнить ваш проект с конкурентами в вашей области — тоже библиотеками? Как сейчас у вас дела по сравнению с ними? Р6: Я бы сказал, у нас довольно мало прямых конкурентов: есть схожие библиотеки, которые делают то же, но для других платформ, языков и фреймворков — мы с ними не пересекаемся, аудитория разная. С инструментами внутри фреймворков конкуренция шире, сообщество больше, но благодаря техническим нюансам наше решение пользуется серьёзным спросом и не планирует идти на спад. Конкуренция, скорее, помогает: происходит взаимное «опыление» новыми тенденциями и фичами — мы не давим друг друга, а помогаем расти. И: Получается, основной критерий сравнения — не только число вовлечённых, но и постоянство вовлечения. У вас люди постоянно вовлечены, хоть их и меньше, чем у некоторых библиотек, но им это действительно нужно. Да, да. Как минимум — использование библиотеки конечными разработчиками. Да. Хорошо, я с этим разобрался. Спасибо большое за интервью. Я останавливаю запись.

И: Спасибо, что согласился поучаствовать в интервью между встречами. Оно анонимное, делаю запись, но она никуда не уйдет, нужна только мне, чтобы вспомнить содержание. Хотел поговорить про твое понимание эффективности команды, твой взгляд на этот вопрос. Можешь описать, чем отличается эффективная команда?