TGViewer
Teamlead Good Reads – ежедневные советы про менеджмент людей и команд Teamlead Good Reads – ежедневные советы про менеджмент людей и команд @leadgr · 28.1K subscribers
Post #2385 7.45K
Как умирают опенсорсные проекты

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

В статье – полезная классификация ситуаций, которые могут привести к смерти опенсорса, на который вы положились. Вот некоторые из них:

👉Корпоративный сирота. Компания решила заопенсорсить какие-то внутренние наработки, а затем ответственный за них человек уволился или был переключен на другие задачи. README никто не обновил, проект остался существовать, но в компании про него никто никогда не вспомнит.
👉Ментейнера наняли. Проект был создан человеком в свое свободное время. Потом его наняли в компанию, условия контракта с которой не позволяют ему продолжить поддерживать проект.
👉Дедлок наследования. Основной ментейнер проекта куда-то исчез вместе со всеми правами на публикацию новых версий. Остальные ментейнеры были быи рады подхватить флаг, но экосистема либо не позволяет передать права на пакет без ведома его создателя, либо это слишком сложный процесс, в который никто не готов вписаться.
👉Ментейнер выгорел. Он все еще принимает простые правки, не требующие когнитивного ресурса, но любые серьезные изменения зависают навсегда. При этом, чем больше его пушат, тем меньше вероятность того, что что-то случится.
👉Знание о проекте ушло. Создатель проекта передал права, а новые ментейнеры не очень хорошо понимают, как он устроен под капотом. В результате он неявно переходит в ридонли режим, с только косметическими правками.
👉Протест. Владелец проекта в знак протеста с политической или социальной проблемой ломает свой проект так, что он перестает работать либо для всех, либо для какой-то части людей.
👉Теневая разработка. В опенсорсе находится только зеркало, а настоящая разработка идет в приватном корпоративном репозитории, который когда-то просто забудут продолжить подливать.
👉Не подлежащий релизу мастер. Разработка проекта ушла слишком далеко с момента последнего релиза, он гарантированно сломает обратную совместимость всем и везде, и никто за такое не хочет брать ответственность.
👉Транзитивная смерть. Умерла какая-то важная зависимость проекта, и аналога нет или переезд слишком сложный.
Andrew Nesbitt Dumb Ways for an Open Source Project to Die How your dependencies became Bernies
  • 👍 27
  • ❤ 7
More from @leadgr
  1. Sep 22, 2026Как Bending Spoons переделывает компании Bending Spoons – это итальянская компания с очень…
  2. Sep 21, 2026🦺 Обучение по охране труда под ключ Организуем обучение по охране труда с учётом специфик…
  3. Sep 21, 2026Как писать с помощью LLM Давайте сразу согласимся – AI пока еще пишет отвратительно, и даж…
  4. Sep 18, 2026Кроссплатформа теряет смысл Shopify, которые безумно топили за React Native последние годы…
  5. Sep 17, 2026Стать резидентом Дубая теперь легче, чем когда-либо Как вы знаете, иметь внж надежной стра…
  6. Sep 17, 2026Как агенты следуют разным техникам верификации Несмотря на то, что модели становятся умнее…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →