Линукс Док

Технологии и экономика в цифрах

Экономика

Автор: Туманов Александр, Редактор: Летописец, Дата: 2026-10-18

Технологии и экономика: связка в цифрах

Формат каждого блока: тезис → механизм → цифры → возражение → что это значит для Linux.

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

Стержень: вся цепочка в семи строках

  1. Технология — средство. Её ценность определяется задачей, а не возможностями.
  2. Интерфейсы задают цену повторения. Формат, протокол, API определяют, сколько сил уходит на то, чтобы сделать то же самое ещё раз.
  3. Повторение интерфейсов — потерянные ресурсы: человеко-часы, энергия, железо.
  4. Кто владеет интерфейсом, тот и получает выгоду от унификации. Унификация без общего управления — это не кооперация, а рента.
  5. Открытый стандарт под общим управлением позволяет унифицировать, не отдавая интерфейс одному владельцу.
  6. Это измеримо: сколько реализаций у одного и того же, сколько стоит поддержка, сколько тонн уходит в отходы.
  7. Для Linux это не теория: дублирование интерфейсов — то, с чем сталкивается каждый, кто собирает пакеты, настраивает сеть или пишет службу.

Блок 1. Цена дублирования интерфейсов

Тезис. Один и тот же код упаковывается заново в каждой системе, и это повторяющаяся работа, которую можно посчитать.

Механизм. Пакетный менеджер, система инициализации, настройка сети — у каждой системы свои. Верхний проект один, а «обёрток» вокруг него столько, сколько дистрибутивов.

Цифры. Сервис Repology считает, в скольких репозиториях упакован проект. Данные на 18.10.2026:

Проект Сборок Репозиториев
nginx 1181 150
openssl 1019 183
curl 898 189

Это не «популярность», а именно дублирование: один upstream-архив, сотни сборок, у каждой свой мейнтейнер, свои зависимости, свой патч безопасности.

Главный пробел — и что с ним стало. Прямой цифры «сколько человеко-часов съедает дублирование» никто не публиковал. Методика такая:

человеко-часы = (число репозиториев) × (часы на поддержку пакета в год) × (годы)

Число репозиториев известно (150–189). Второй множитель удалось оценить по двум исследованиям — сколько компонентов приходится на одного мейнтейнера и сколько времени он на них тратит. Это оценка, а не измерение: все допущения названы в разделе «Оценка в человеко-часах» ниже.

Возражение, которое надо снять сразу. «Разнообразие — это хорошо». Да — но разнообразие реализаций и дублирование интерфейсов разные вещи. Реализаций может быть много, и это страховка: ошибается одна — есть другая. А интерфейсов должно быть мало, иначе вся экономия уходит на пересборку и переписывание.

Для Linux. Материал под рукой, всё в нашем же корпусе: DEB / RPM / Pacman / Portage / APK; systemd / SysV init / OpenRC / runit; NetworkManager / ifupdown / netplan / systemd-networkd. Три слоя — три набора несовместимых интерфейсов.

Блок 2. Замок: когда унификация превращается в ренту

Тезис. Унификация выгодна — но выгоду получает тот, кто владеет интерфейсом. Поэтому «одна система для всех» без общего управления — не решение, а смена владельца.

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

Возражение. «Пусть владеет один — зато эффективно». Это и есть ловушка: посылка об эффективности сама по себе ведёт к монополии, а не к кооперации. Чтобы вывод стал «кооперация», нужна вторая посылка — открытое управление стандартом.

Честно про цифры. Цифры цены замка (сколько стоит переключение, сколько стоят лицензии в масштабе страны) я пока не нашёл и не привожу. Это следующий шаг; вместо них здесь работает механизм и обратная сторона — цифры открытости в блоках 3 и 4.

Блок 3. Что даёт открытый стандарт

  • Единый зарядный разъём в ЕС (USB-C). По данным Европарламента: экономия потребителей — до €250 млн в год на ненужных зарядках, а выброшенные и неиспользованные зарядные устройства — около 11 000 тонн электронных отходов в год в ЕС.
  • JEDEC (память). Наш собственный пример, первичный источник: модули DDR4 от Kingston и Patriot встали в один ноутбук и заработали вместе — потому что стандарт общий. В статье про SODIMM подбор второго модуля сводится к трём параметрам, а не к «только модуль того же производителя».
  • POSIX, HTTP/HTML, Unicode. Переносимость кода, единый веб, единые тексты. Отдельных цифр здесь не привожу — их надо искать так же, как остальные.

Блок 4. Что даёт открытый код

  • Стоимость воссоздания. Исследование Linux Foundation (2008): собрать дистрибутив Fedora 9 «с нуля» стоило бы около $10,8 млрд, а одно только ядро Linux — около $1,4 млрд. То есть готовый дистрибутив — это актив на миллиарды долларов, полученный кооперацией, а не покупкой.
  • Вклад в экономику. Исследование Еврокомиссии (2021, Fraunhofer ISI и OpenForum Europe): компании в ЕС вложили в открытое ПО около €1 млрд в 2018 году, а эффект для экономики ЕС — €65–95 млрд. Соотношение затрат и выгоды выше 1:4; рост вклада в открытое ПО на 10 % давал бы дополнительно 0,4–0,6 % ВВП в год.

Блок 5. Куда уходят ресурсы, если не договариваться

По данным Global E-waste Monitor 2024 (ITU и UNITAR):

  • 62 млн тонн электронных отходов за 2022 год — на 82 % больше, чем в 2010;
  • к 2030 году прогноз — 82 млн тонн;
  • документально собрано и переработано — 22,3 %, к 2030 прогноз падения до 20 %;
  • вместе с отходами потеряно ресурсов на $62 млрд;
  • если довести сбор и переработку до 60 %, выгода превысит затраты более чем на $38 млрд;
  • только 1 % спроса на редкоземельные элементы закрывается переработкой.

Это и есть ответ на «куда деваются ресурсы»: не в абстрактное «человечество», а в конкретные тонны, которые можно было бы вернуть в оборот.

Стимулы при дефиците (вместо «природы человека»)

«Человеческая природа» как объяснение неопровержима: на неё всегда можно ответить «это твоё мнение». Рабочая формулировка — стимулы при дефиците: когда ресурса мало, а правила такие-то, человеку выгодно взять своё; когда правила другие — выгодно договариваться. Проверяется это тем, что меняется вместе с правилами:

  • где правило есть (JEDEC, USB-C, HTTP) — совместимость растёт без единого владельца;
  • где правила нет (форматы документов, зарядки до USB-C) — растут дублирование и замки.

Так «Человек» и «Капитал» перестают быть двумя отдельными разделами: это один механизм — выгода при заданных правилах.

Что делать

Из цифр выше следуют не призывы, а действия. У каждого — проверяемый результат.

1. Не заводить новый интерфейс, если есть старый

Почему: каждый новый формат или протокол умножает дублирование — в блоке 1 это 189 сборок одного и того же кода. Что делать: прежде чем придумывать свой формат — искать существующий стандарт; если свой всё же нужен, публиковать его открыто и объяснять, чем он лучше. Как проверить: число форматов и протоколов в вашей системе не растёт.

2. Чинить в upstream, а не у себя

Почему: патч, живущий только в дистрибутиве, надо заново носить в каждой сборке; патч в upstream расходится по всем сразу. Что делать: правило «upstream first» — сначала правка в проект-источник, потом в упаковку; в описании патча — ссылка на обсуждение в upstream. Как проверить: доля патчей, ушедших в upstream, растёт; число «своих» патчей падает.

3. Публиковать интерфейс, а не только реализацию

Почему: открытый код без открытого интерфейса снова создаёт замок, как только появляется вторая реализация. Что делать: спецификация + тесты совместимости + открытая лицензия на них. Реализаций при этом может быть много — это страховка, а не расточительство. Как проверить: можно ли заменить реализацию, не переписывая потребителей.

4. Стандарт — под общим управлением, а не под одним владельцем

Почему: выгода от унификации достаётся владельцу интерфейса (блок 2). Посылка об эффективности сама ведёт к монополии — нужна вторая: открытое управление. Что делать: участвовать в открытых организациях (JEDEC, IETF, W3C, ISO); в закупках требовать открытые стандарты и форматы. Как проверить: можно ли реализовать стандарт без разрешения владельца.

5. Считать и публиковать цену дублирования

Почему: то, что не измерено, не оптимизируется. По электронным отходам цифры публикуются каждый год (блок 5), а по дублированию интерфейсов — нет. Что делать: вести публичный индекс дублирования (Repology показывает, что это считаемо), измерить человеко-часы на поддержку пакетов, публиковать отчёт раз в год. Как проверить: индекс и отчёт существуют и обновляются.

6. На своём уровне: выбирать открытое и объяснять почему

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

  • читателю — выбирать открытые форматы и понимать, чем они отличаются от закрытых;
  • разработчику — upstream first и открытый интерфейс;
  • организации — требования к закупкам: открытые форматы, отсутствие замка;
  • государству — «общественные деньги — общественные интерфейсы»: если платит бюджет, интерфейс должен быть открыт. Как проверить: доля открытых стандартов и форматов в конкретной организации растёт, цена переключения падает.

Чего в этом блоке нет — и почему

Здесь нет «надо договориться» и «люди должны понять». Это не действия. Действие — то, что можно сделать в понедельник и проверить в пятницу.

Что ещё не проверено

  1. Число человеко-часов — оценка, а не измерение. Оба множителя взяты из исследований, но из разных: время мейнтейнеров upstream-проектов (Tidelift) и число компонентов на дистрибутивного мейнтейнера (EMSE). Оценка и границы её точности названы в разделе «Оценка в человеко-часах».
  2. Нет цифр по цене замка (лицензии, миграции) — блок 2 держится на механизме, а не на числах.
  3. Нет данных по России и СНГ — если раздел нужен не только про ЕС, это отдельный набор источников.
  4. Проверка источников — не разовая работа. Цифры стареют: у Repology данные меняются каждую неделю, у отчётов по отходам — раз в год. Нужно решить, как часто перепроверять и кто это делает.

Где искать цифру человеко-часов

Вопрос «сколько человеко-часов съедает дублирование» не пустой — им занимались, и часть работы уже сделана:

  • «Toward Efficient Package Maintenance: An Empirical Study of Patch Sharing across Four Linux Distributions» (ICSE 2026, стр. 1635–1647) — самое близкое к нашей задаче. Открытый PDF у авторов: https://zhangyw.work/file/papers/Peng2026ICSE.pdf, данные: https://zenodo.org/records/18150449.

    Авторы сравнили Debian, Ubuntu, Fedora и openEuler и посчитали, сколько работы делается повторно:

    • 33 293 «гомологичных» пакета между Debian и Ubuntu — это 96,6 % всех пакетов Debian и 89,1 % всех пакетов Ubuntu;
    • между Fedora и Debian совпадает 40,3 % пакетов Debian и 56,1 % пакетов Fedora;
    • но наборы патчей совпадают лишь частично: 19,45 % между Fedora и Debian и 46,73 % между Fedora и openEuler;
    • 85,34 % пакетов Fedora–Debian с патчами содержат патчи, которых нет у соседа; у Fedora–openEuler таких 50,29 %.

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

  • «An Empirical Study of Integration Activities in Distributions of Open Source Software» (Empirical Software Engineering, 2015; Adams, Kavanagh, Hassan, German). Открытый PDF: https://mcislab.github.io/publications/2016/integration_oss_distribution.pdf.

    Работа описывает семь видов работ по интеграции — готовый словарь того, из чего состоит дублирование, — и даёт доли пакетов, которые этих работ требуют:

    • локальный патч носят 22,1 % пакетов Debian, 28,4 % — Ubuntu, 12,2 % — FreeBSD (от всех версий пакетов);
    • из них 24,7 % (Debian), 11,9 % (Ubuntu) и 6,3 % (FreeBSD) могли бы вообще не держать свой патч — он уже ушёл в upstream.

    То есть примерно каждый четвёртый-пятый пакет несёт собственную правку, а четверть этих правок — лишняя работа. Часов здесь тоже нет: измерены доли пакетов.

  • Опросы мейнтейнеров — здесь как раз часы. Tidelift, «State of the Open Source Maintainer» (2023 и 2024): https://www.sonarsource.com/open-source-maintainer-survey-2023.pdf.

    • 78 % мейнтейнеров-любителей, работающих бесплатно, тратят 10 часов в неделю или меньше (в 2023 году — 81 %);
    • 81 % профессиональных мейнтейнеров (живущих с этого) тратят больше 20 часов в неделю, 93 % — больше 10;
    • 60 % мейнтейнеров по-прежнему не получают за это денег.

Как из этого собирается оценка

Складываем то, что измерено, и отдельно называем то, что додумали:

часы на дублирование =
    (доля пакетов с локальными патчами)    ← 22–28 %  (EMSE 2015)
  × (доля патчей, уже ушедших в upstream)  ← 6–25 %   (EMSE 2015)
  × (число дистрибутивов с этим пакетом)   ← до 189   (Repology)
  × (часы на патч в год)                   ← ДОПУЩЕНИЕ, его надо показать

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

  • Методика пересчёта кода в человеко-часы уже решена — SLOCCount и модели COCOMO. Пример: исследование Debian 2.2 (55 млн строк) дало 14 005 человеко-лет (см. https://en.wikipedia.org/wiki/Source_lines_of_code); Linux Foundation в 2008 считала тем же методом дистрибутив Fedora 9. Один человеко-год ≈ 1 800 часов — дальше арифметика.
  • «Open Source Software Maintenance Effort Estimation: A Systematic Mapping Study» (2022) — обзор всего поля оценки трудозатрат на сопровождение открытого ПО: удобная точка входа, если понадобится больше источников.

Важно не смешивать. Человеко-годы из SLOCCount — это стоимость разработки дистрибутива, а не стоимость дублирования сопровождения. Для нашей цифры нужны именно работы первого типа (patch sharing, integration effort), и конкретное число надо брать из статьи, а не выводить самому.

Обе статьи платные (ACM и Springer), публично доступны аннотации; для цифр нужен полный текст или препринт.

Оценка в человеко-часах

Два множителя, которых не хватало, нашлись в двух работах — обе лежат у нас в хранилище.

Сколько компонентов приходится на одного мейнтейнера (EMSE 2015, по данным дистрибутивов):

Дистрибутив Мейнтейнеров Компонентов На одного
Debian ~2 400 24 000 10
FreeBSD ~400 23 000 57,5
Ubuntu ~150 24 000 160

Сколько времени уходит у мейнтейнера (Tidelift, 2023):

  • 78 % бесплатных мейнтейнеров-любителей тратят 10 часов в неделю или меньше;
  • 81 % профессиональных (живущих с этого) — больше 20 часов в неделю, 93 % — больше 10.

Отсюда часы на компонент в год — на примере Debian, где на человека приходится 10 компонентов:

10 часов в неделю ÷ 10 компонентов = 1 час в неделю на компонент = 52 часа в год
20 часов в неделю ÷ 10 компонентов = 2 часа в неделю на компонент = 104 часа в год

Теперь пример на настоящем проекте. Возьмём curl: по Repology он упакован в 189 репозиториях.

Шаг Что считаем Результат
1 Вся работа по копиям: 189 × 52–104 ч 9 828 – 19 656 ч в год
2 Из них пакеты с локальными патчами (22–28 %, EMSE) 2 162 – 5 504 ч в год
3 Из них правки, которые уже ушли в upstream (6–25 %, EMSE) 130 – 1 376 ч в год

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

Как эта оценка может ошибаться и в какую сторону. Tidelift считает время мейнтейнеров upstream-проектов, EMSE — дистрибутивных пакетов. Умножая одно на другое, мы соединяем две разные группы людей, и в оценку попадает время на разработку самого кода — то, что дублированием не является. Поэтому первый ряд — верхняя граница. Ещё два допущения: время распределяется по компонентам ровно, и доля патчей одинакова во всех 189 репозиториях. Ни то, ни другое не проверено.

Что превратило бы оценку в измерение: замер на нескольких мейнтейнерах — сколько часов в неделю уходит на конкретный пакет. Такую проверку провести можно, данных пока нет, и выдавать оценку за измерение мы не будем.

Источники

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

Оценка статьи 0

Смотрите также

Комментарии

Пока комментариев нет.