Почему критически важное программное обеспечение с открытым исходным кодом по-прежнему зависит от одного измотанного мейнтейнера?
Возможность
В ноябре 2025 года Kubernetes вывел из эксплуатации Ingress NGINX, один из своих наиболее широко используемых компонентов, не потому, что он был заменён, а потому, что команда добровольных мейнтейнеров больше не могла его поддерживать. Отдельно External Secrets Operator, применяемый в критически важных корпоративных пайплайнах по всему миру, заморозил все обновления, когда четверо из пяти его мейнтейнеров одновременно выгорели. Отраслевые опросы показывают, что 60 процентов мейнтейнеров открытого ПО работают без оплаты, а 44 процента называют выгорание причиной ухода или намерения уйти. Программы финансирования вроде Open Source Pledge и GitHub Sponsors существуют, но решают проблему денег, а не реального узкого места, которым является очередь на ревью. Не существует лёгкого автоматизированного инструмента, который надёжно передавал бы рабочий контекст, ожидания по покрытию тестами и знания о модели угроз от уходящего мейнтейнера к преемнику, поэтому каждый уход откатывает проект почти к нулю.
Почему это важно
Программная инфраструктура мира работает на компонентах, чья непрерывность зависит от доброй воли отдельных людей, а инструментов, которые сделали бы передачу обязанностей мейнтейнера безопасной и быстрой, не существует.
Как я оцениваю возможность
Оценка возможности отражает моё личное суждение, а не точное измерение: насколько проблема болезненна, как часто она встречается и насколько мало существует решений сегодня. Чем выше оценка, тем более достойной реализации я считаю эту задачу.
Насколько серьёзные проблемы это создаёт.
Как часто люди с этим сталкиваются.
Насколько мало хороших инструментов для этого существует сегодня.
Ещё задачи, достойные решения
Почему программное обеспечение, от которого мы зависим больше всего, так неудобно использовать?
TechПочему я по-прежнему не владею ни одними из данных, которые генерирую?
TechThis is a fundamental limitation of how most data deletion works today, and it comes down to a few core problems: **Deletion is an absence, not a presence** A receipt is a positive artifact -- proof that something *happened*. Proving a negative ("this data no longer exists anywhere") is cryptographically and architecturally much harder than proving a positive ("this file was signed at time T"). **No standard audit trail** Most systems are not built to emit a verifiable, tamper-proof log of what was deleted, when, and from which storage layer. Even if a company tells you "your data was deleted," that statement lives in their system, which they control. **Backups and replication** Data often lives in dozens of places: primary DBs, read replicas, backups, logs, caches, CDN edge nodes, analytics pipelines. A deletion receipt would need to account for all of them -- and companies rarely track this end-to-end. **No legal requirement to provide one** GDPR Article 17 gives you the right to erasure, and Article 19 requires notification to recipients -- but neither mandates a cryptographically verifiable receipt. Companies only have to confirm deletion, not *prove* it in a way you can independently verify. **Technical proof would require architectural changes** A trustworthy receipt would need something like: a Merkle-tree deletion proof, a signed timestamp from an independent witness, and a commitment scheme proving the original data existed before deletion. Almost no consumer product is built this way. The gap here is a policy and incentive problem as much as a technical one -- companies have little motivation to build verifiable deletion infrastructure when regulators don't require it.
TechПочему я не могу знать, соответствует ли то, что запущено, тому, что задекларировано в моём SBOM?
TechПочему каждая цепочка происхождения C2PA разрывается в тот момент, когда контент попадает в социальные сети?
TechПочему тесты, сгенерированные с помощью ИИ, пропускают ошибки, которые они должны были обнаружить?