или “Страшная сказка: продолжение-2”

В предыдущем разборе («О бедном луддите замолвите слово…») я разобрал по единой схеме одно из ключевых возражений против катастрофического прогноза кадрового разрыва — паттерн ткацкого станка. То возражение отбрасывается структурно: условия, при которых паттерн срабатывал, в текущей ситуации не выполнены.

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

Схема та же:

  1. Формулировка возражения

  2. Историческая основа

  3. Почему паттерн работал

  4. Почему не работает в полной мере сейчас

  5. Что в паттерне есть верного

  6. Вывод

«Не корпорациями едиными жива индустрия. Есть структуры, которые выживут, сохранят и компенсируют»

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

Формулировка возражения

Хорошо, допустим, корпорации рушат свой цикл воспроизводства экспертизы AI-мандатами. Но программирование — это не только корпы. Существует огромный пласт других крупных проектов: Linux kernel, Postgres, GCC, LLVM, Kubernetes, движки браузеров, BSD, ядро Python. Будучи опен-сорс, эти проекты не участвуют в «гонке к обрыву». Они живут вне корп-мандатов, у них есть своя структура наставничества (новичок → коммитер → мейнтейнер), они производят настоящих экспертов, и они структурно резистентны к решениям советов директоров. Когда у крупных корп в 2030+ начнётся острый дефицит сеньоров, эти кадры подтянутся из open-source-прослойки. Плюс мелкие лавки. После коррекции рынка на самоокупаемость нейросетевых технологий, AI станет отсечён от них ценой входа и обслуживания. А значит, они продолжат вручную растить кадры. В сумме получается «кузница кадров», которая компенсирует разрыв.

Иногда добавляется: «Linux был построен горсткой энтузиастов и до сих пор работает на миллиардах устройств. Если эта горстка справилась с этим — справится и с воспроизводством экспертизы. Всегда есть мотивированные люди, которым интересно понимать, как всё устроено по-настоящему».

Историческая основа

Open-source движение как структурный феномен оформилось в 1980-х–90-х. Конкретные точки опоры:

  • GNU project Ричарда Столлмена (с 1984): GCC, glibc, Emacs, утилиты — фундамент свободного программного обеспечения.

  • Линус Торвальдс публикует Linux (1991). К 2026 году — самая распространённая операционная система на планете: серверы, мобильные устройства Android, встраиваемые системы, суперкомпьютеры. Поддерживается небольшим ядром мейнтейнеров (несколько сотен на ключевые сабсистемы) и широкой периферией контрибьюторов.

  • Postgres (с 1996, наследник Ingres / POSTGRES академической линии 1980-х). База данных, на которой работает значимая часть мировой инфраструктуры. Core team — несколько десятков человек.

  • Apache HTTP Server, OpenSSL, BSD, Python, Perl, Ruby, Node.js — десятки фундаментальных проектов, каждый со своей структурой управления и наставничества.

  • Современная волна: Kubernetes, Docker, Rust, Go, движок Chromium, движок Firefox, экосистема Linux kernel.

Что реально произошло за 30–35 лет open-source:

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

  • Каждый крупный проект выработал собственную структуру наставничества: новичок шлёт patches → мейнтейнеры рецензируют → после периода стажировки контрибьютор получает коммит-права в одной сабсистеме → после длительной работы становится senior maintainer / архитектором.

  • Сложились международные сообщества с собственной культурой ревью, документации, преемственности. Линус-стиль ревью (жёсткий, прямой, иногда грубый) стал нормой для kernel; своя школа у Postgres, своя у Mozilla, своя у Apache Foundation.

  • Многие фундаментальные сдвиги были рождены или формализованы в open-source: модель ветвления Git, контейнеры через cgroups в Linux, языковые сообщества Python/Ruby/Rust с их PEP/RFC процессами.

Это реальный структурный феномен. На нём строится оптимистическое возражение: «open-source держит фундамент, корпорации могут гнить, но фундамент устоит».

Почему паттерн работал

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

1. Реальная сложность задач. Ядро Linux — это распределённая система, работающая на миллиардах устройств с разнообразным железом, в режиме hard-real-time на части устройств, под нагрузкой, с требованиями безопасности. Это frontier-grade задачи, эквивалентные тому, чем занимались бы в корп-исследовательской лаборатории. Аналогично Postgres — это распределённая транзакционная база с многоверсионным concurrency control, журналированием, репликацией, query optimizer уровня IBM/Oracle. Новичок, приходящий в kernel community, сталкивается с проблемами, которых не существует в типовом line-of-business SaaS. Уровень специалиста формируется уровнем задач, на которых он работает.

2. Жёсткое ревью и культура. В kernel-сообществе плохой патч публично критикуется, и автор должен либо доказать свою правоту, либо переделать. В Postgres core team — тот же режим. Это болезненный, но работающий цикл обратной связи — тот самый, который AI-мандат у корпов разрушает. Ревью делает не «AI-аудитор», а человек, который сам прошёл этот путь и понимает, что в патче должно быть, чего быть не должно, какие side effects ловить.

3. Полноценная цепочка ученичества. Большие OSS-проекты имеют полную цепочку: contributor → committer (с правами в одной сабсистеме) → maintainer (отвечает за сабсистему) → senior maintainer / архитектор. Каждое звено формируется через предыдущее, как в средневековой гильдии. Это та самая полная цепочка экспертизы, наличие которой в разборе луддита описано как условие, обязательное для воспроизводства профессии.

4. Самоотбор по мотивации. В open-source приходят не за зарплатой — она там, если есть, опосредованная (корп-работодатель, гранты, фонды). Приходят люди, для которых интересна сама задача. Это естественный фильтр против профанации: человек, который не хочет разбираться, в kernel mailing list просто не задерживается — его патчи отклоняют, ему скучно, он уходит.

5. Структурная независимость от корп-решений. Линуса Торвальдса не может уволить совет директоров. Postgres core team не подчиняется CTO. Это другой контур управления, не пересекающийся с корп-вертикалью. AI-мандат, изданный советом Apple, не действует на Linux kernel. Это и есть «прокладка», о которой говорится в возражении.

6. Перекрёстная подпитка кадрами от корпов. И вот тут важный нюанс, который обычно опускается. Большая часть mainline kernel contributors работает в Red Hat, Intel, Google, Linaro, IBM, Suse. То есть OSS-frontier исторически подпитывается корпами — корпы платят зарплату, а человек тратит часть рабочего или личного времени на upstream. Postgres core team — то же самое: люди работают в EnterpriseDB, Crunchy Data, Microsoft. OSS не самозарождается из ничего — он работает в симбиозе с корп-средой, которая поставляет ему квалифицированных людей с экономической опорой.

7. Государственное и фондовое финансирование фундамента. Многие критические OSS-проекты получали и получают институциональную поддержку: ARPA финансировала ранний интернет, BSD финансировался DARPA, Mozilla живёт на корп-донатах и грантах, Linux Foundation на корп-членстве, OpenSSL до Heartbleed держался на одном человеке, после — на грантах через CII. То есть OSS не существует в безвоздушном пространстве — у него есть внешние доноры, обеспечивающие минимальную экономическую устойчивость критических узлов.

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

Почему паттерн не работает в полной мере для компенсации каскада

Сразу различим два разных вопроса, потому что они путаются в дискуссии:

  • Хватит ли open-source-прослойки, чтобы компенсировать кадровый разрыв в корпах и сохранить темп развития фронта?

  • Хватит ли её, чтобы поддерживать существующий уровень технологии на ближайшие десятилетия?

Это два разных ответа. Сначала по первому — здесь паттерн недостаточен.

1. Двухфильтровая труба — open-source закрывает только один фильтр. В физике, на которую любят ссылаться, поток к frontier-учёному проходит через два последовательных фильтра. Первый — селекция: из массового потока отбираются способные. Второй — среда формирования: отобранный талант проходит огранку в элитных средах с frontier-задачами (CERN, Курчатник, MIT, Стеклов). Без второго фильтра алмаз остаётся алмазом-кандидатом.

Open-source закрывает первый фильтр для софта — селекция мотивированных и способных через входной барьер ревью работает. И частично закрывает второй — задачи в kernel/Postgres/Chromium действительно frontier-grade. Но только в тех нишах, которые покрыты крупными OSS-проектами. Распределённое транзакционное хранилище на сто датацентров? Это где-то в кишках Spanner и FoundationDB, и наружу выходит крошечная часть. Compiler-фронтиры? Часть в LLVM, часть закрыта в Apple, Google, Intel. Системы real-time inference на сотни тысяч QPS? Преимущественно внутри корп-лабораторий. То есть топология frontier-задач в индустрии: часть лежит в OSS, часть — нет, и недоступная часть растёт с каждым годом по мере того, как корпы превращают свои наработки в продуктовые рвы.

2. Объёмная диспропорция. Linux kernel — это несколько сотен активных maintainer’ов на ключевые сабсистемы и несколько тысяч регулярных контрибьюторов. Postgres core — десятки. LLVM core — десятки. Browser engines суммарно — на три движка, может быть, тысяча человек. Это прослойка, а не отрасль. В мире сейчас примерно 25–30 миллионов профессиональных разработчиков; в крупных технологических корпах — миллионы; в каскаде кадрового разрыва должно выпасть, по оценкам тех, кто отслеживает рынок, сотни тысяч сеньоров через 5–7 лет. OSS-прослойка не имеет физического объёма, чтобы покрыть эту дыру даже на проценты. Корпы смогут купить лучших mainline-комитеров поштучно — но это десятки людей, не десятки тысяч.

3. Циркулярная зависимость с корпами. Я выше отметил: OSS-frontier подпитывается людьми, работающими в корпах. Когда корпы перестают готовить middle-уровень — в OSS приходит меньше готовых стажироваться кандидатов. Чтобы прислать первый осмысленный патч в kernel, человек уже должен уметь читать C, понимать ОС-абстракции, проектировать — то есть пройти как минимум middle-уровень самостоятельной разработки. Если корп-цикл этого не даёт, OSS остаётся без притока. Это обратная связь второго порядка: разрушение корп-цикла подъедает топливо OSS-цикла. Не мгновенно — OSS-сообщество дольше держится за счёт оставшихся ветеранов, — но через 10–15 лет проявится.

4. Кризис преемственности. Линусу Торвальдсу 56. Грег Кроа-Хартман — старшая возрастная категория. Брюс Момджиан, Том Лейн, Стивен Фрост в Postgres — поколения 60+. Большинство фундаментальных OSS-проектов сейчас держится на людях, начавших карьеру в 80-х–90-х — в эпоху, когда профессию учили без AI-помощи. Они уйдут в ближайшие 10–20 лет, и преемников нужно вырастить из людей, которые сами прошли цикл качественной экспертизы. А этот цикл — именно то, что под ударом каскада. Без преемников OSS-проекты деградируют, пусть и не сразу, а через дрейф. Но с каждым годом будет всё больше формальных ревью, всё больше пропущенных тонкостей, всё больше регрессий — пока проект не теряет свойство «надёжная основа мировой инфраструктуры».

5. Frontier-развитие никогда не сидело преимущественно в OSS. Это структурное историческое наблюдение, которое часто игнорируется. Перечислю ключевые сдвиги в индустрии за 25 лет и их источник:

  • MapReduce и распределённое хранилище — Google Research.

  • Глубокое обучение и трансформеры — академия (Hinton, Bengio) + Google Brain / OpenAI / Anthropic; релизы в OSS постфактум.

  • Контейнеры и оркестрация — Google внутри (Borg), затем OSS (Kubernetes) как переупаковка готового.

  • React, GraphQL, PyTorch — Meta внутри, OSS как продукт.

  • TLS 1.3, формальные методы верификации — академия + корп-команды.

  • Современные SQL-движки (Spanner, CockroachDB, FoundationDB) — корпы.

OSS дал миру: Linux, Git, Postgres, Apache, BSD, несколько важных языков (Python, Ruby, частично Rust и Go в гибридной модели). Это рекомбинация и улучшение существующих парадигм, не открытие принципиально новых. Фундаментально новые парадигмы дороги: они требуют долгого финансируемого исследования, экспериментальных кластеров на миллионы долларов, ко-разработки с железом, многолетней толерантности к нулевому результату. OSS на пожертвованиях и в свободное время этого не вытягивает.

6. AI-слоп проникает и в OSS. Уже сейчас kernel mailing list обсуждает, как обращаться с AI-генерированными патчами. Преобладающая позиция: «не принимаем, если автор не понимает того, что прислал». Это фильтр работает, но он работает за счёт усиленного труда maintainer’ов, которые тратят больше времени на отбраковку. И это гонка: AI-генератор патчей становится всё неотличимее, ресурс maintainer’ов конечен, новичков с подменённой подготовкой всё больше. Через 10 лет фильтр будет работать хуже, не лучше.

7. Потолок задач у мелкой лавки занижен. Часть возражения опирается на «мелкие лавки, куда AI отсечён ценой, продолжают растить кадры». Это правда — selection-фильтр там работает, ручной труд сохраняется. Но мелкая лавка по построению не имеет frontier-задач: она делает CRUD, line-of-business SaaS, интеграции, внутренние инструменты. На этих задачах можно вырастить компетентного сеньора — но не frontier-уровня архитектора, потому что задачи соответствующей сложности в этой среде структурно не возникают. Когда корп в 2031-м придёт купить такого сеньора, она получит кандидата без огранки — а среда огранки в самой корпе уже сломана.

А вот другой вопрос: хватит ли прослойки для поддержания технологии?

Здесь ответ скорее да, с оговорками.

OSS-frontier исторически показывает поразительно низкие требования к численности при высокой стойкости. Linux kernel поддерживается с 1991-го, Postgres — с 1996-го, BSD — с 1977-го (с форками), и эти проекты до сих пор работают на крошечных по корп-меркам командах. Это значит — численный обвал поддержки можно не ждать в ближайшее десятилетие. Уже накопленный когорт ветеранов плюс молодая активная часть физически тянут 10–15 лет вперёд:

  • Безопасность критических компонентов патчится.

  • Новое оборудование поддерживается.

  • Регрессии вылавливаются.

  • Существующие технологии остаются работоспособными.

Но «технология поддерживается» ≠ «технология развивается». OSS-прослойка способна сохранять обслуживающую функцию на десятилетие+, и при этом не способна ни заменить корп-цикл воспроизводства сеньоров для крупных компаний, ни самостоятельно поднять frontier там, где он сейчас находится в корп-исследовательских лабораториях. При этом “сохранение” будет идти за счет наличия надежных релизов, а не сохранения кадров. То есть это не компенсирует кадровый разрыв - это смягчает просадку индустрии по направлению.

Что в паттерне есть верного

Несколько пунктов работают по-настоящему и должны быть зафиксированы как реальные смягчающие факторы:

  • Self-selection по мотивации работает. В OSS приходят люди, искренне интересующиеся темой. Этот фильтр AI-эпохой не сломан. Профанированный программист в kernel mailing list не задержится — его патчи отклонят, ему станет скучно.

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

  • Обслуживание текущей технологической базы сохраняется на десятилетия. Linux, Postgres, основные языки, базовые библиотеки — они никуда не денутся в ближайшие 10–15 лет. Это значит, что цивилизационный откат, если он произойдёт, будет более мягким в этой части. Не «новый Тёмный век», а остановившееся развитие при сохранении работающей базы.

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

  • Преимущество мелких лавок как поставщика кандидатов реально. Там, где AI будет отсечён ценой, разработчики продолжат расти через ручной труд. Selection-фильтр работает. Это даёт кандидатов в OSS и в малые корпы — пусть с заниженным потолком.

Эти факторы — частичные. Они работают для замедления траектории, но не отменяют её. Это критическое различение.

И даже эти факторы в таком виде могут учитываться лишь при условии, что открытые наследники базовых ИИ-инструментов не достаточны. Сейчас Llama, DeepSeek, Qwen, Mistral — open-weight модели догоняют коммерческие. И если коммерческий AI станет недоступным по цене, базовая часть инструмента останется доступной через локальные модели. Это значит, что мелкие лавки тоже получат доступ к AI, и ценовой барьер, который должен был их защищать, перестанет работать. Это отсекает один из списка положительных факторов: мелкий бизнес как поставщика кадров.

Вывод

Возражение «opensource-прослойка компенсирует каскад» частично применимо, и в этом оно сильнее возражения «луддиты и ткацкий станок». Луддитов отбрасывает структурно — там паттерн в принципе не работает. OSS-прослойка работает, но работает ограниченно:

  • Не покрывает кадровый разрыв корпов по объёму (десятки/сотни ключевых maintainer’ов против сотен тысяч выпадающих сеньоров).

  • Не подменяет frontier-развитие, которое исторически живёт в funded research labs, не в OSS.

  • Подъедается циркулярной зависимостью с корп-средой через 10–15 лет.

  • Имеет кризис преемственности к концу 2030-х по возрастным причинам.

  • Но реально удерживает обслуживание существующих технологий на ближайшие 10–15 лет уверенно.

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

Что это даёт катастрофическому прогнозу:

  • Не разворот сценария, а смягчение траектории.

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

  • Числовая оценка вероятности катастрофического сценария сдвигается с диапазона 75–85% к 65–78%. Это значимый сдвиг, но это не разворот.

  • Утешения «всё обойдётся» этот фактор не даёт. Он даёт «будет мягче, чем без него».

Правильное использование паттерна:

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

И последнее, что нужно зафиксировать. OSS как компенсаторный механизм работает только в той мере, в какой мы его сохраняем сейчас. Если коммерческие силы или AI-слоп прорвут фильтры OSS-сообществ в ближайшие годы (а они под нагрузкой) — этот компенсатор тоже выпадет. Это значит, что относиться к нему как к данности нельзя. Поддержка OSS — гранты, корп-членство в фондах, найм mainline-комитеров на полную ставку, государственные программы вроде CII — становится не «приятным дополнением», а частью стратегии сохранения цивилизационной устойчивости в условиях каскада. Не убежище для энтузиастов, а основание, на котором стоит часть мирового технологического стека.

Если о нём не позаботиться — мы потеряем и эту прокладку.

И никакой третий вариант — «авось как-нибудь обойдётся, как всегда обходилось» — здесь тоже не работает. Это не альтернативный паттерн, это отказ от анализа.