Антихрупкий софт

Работая над своим frameworkом, задумался над вопросом, что лучше — подключить через composer какую-нибудь известную стороннюю библиотеку для генерации RSS-потоков или скопировать свой собственный код для RSS из движка Intellect Board с необходимой адаптацией. С одной стороны, первый вариант лучше тем, что более тщательно протестирован, тогда мой тестировался только на типичных сценариях использования, а на каких-то экзотических данных могут вылезти ошибки.
Но с другой — это путь к тому, что в книге Нассима Талеба «Антихрупкость» называется хрупкодельством. Подключая стороннюю библиотеку, я получаю код—«чёрный ящик», в который никогда не буду заглядывать. Который в свою очередь, может иметь ещё несколько зависимостей, в которые, скорее всего, точно так же не заглядывает разработчик библиотеки.
Само по себе в этом ничего плохого бы не было, если бы соблюдался принцип «хороший код — это тот, который пишется раз и навсегда и впоследствии не меняется, потому что решает поставленные задачи». Но увы, об этом остаётся только мечтать: все эти сторонние библиотеки постоянно обновляются. Каждое обновление — это риск, что что-то сломается. Соответственно, чем больше зависимостей, тем больше риск, что что-то сломается. И разрабатываемый софт становится всё более и более хрупким.
Поэтому, на мой взгляд, правильный подход должен быть таким (оговорюсь, что речь идёт о некоммерческой разработке):
1) использовать зависимости только для того, на что не хватает либо квалификации, либо желания реализовывать самому;
2) если зависимость всё же использовали, то фиксировать версию, и обновляться только в том случае, если в этом есть обоснованная необходимость;
3) предусматривать возможность ставить свой софт не только через composer, а и скачать единым архивом, в который сразу будут включены все необходимые библиотеки, как это делалось в старые добрые времена. (К сожалению, уже не раз сталкивался с софтом, установка которого без composerа превращается в весьма непростой процесс. Хотя бы тот же Twig 2 и 3 версий.)

Наткнулся на Хабре на интересную дискуссию на тему устаревания софта, в частности, библиотек, которая непосредственно связана с вопросом антихрупкости. Очередная битва БЛ против ЧЛ, выражаясь языком соционики. Одна сторона (пользователь DabjeilQutwyngo) считает, что качественно написанный софт не устаревает, если методы решения соответствующих задач не меняются в принципе, а необходимость его переписывать — искусственна. Другая (пользователи nronnie, selivanov_pavel, luckman) — придерживается позиции, что устаревание — это естественный процесс, которому нет смысла (да и невозможно) противодействовать.
Лично мне позиция DabjeilQutwyngo гораздо ближе, сам неоднократно озвучивал такую же позицию. Но в то же время, когда заходит речь о том, чтобы взять какой-то совсем старый класс, зачастую испытываю настороженость и опасение, что делаю что-то не так. Хотя, как показывает практика, зачастую более старый код оказывается лучше в плане производительности/потребления памяти. А вам что ближе?

Мне ближе позиция DabjeilQutwyngo. Потому, что это минимизация человеческого труда (здравый смысл с точки зрения ЧЛ, как ни странно). Если код качественный и поддаётся доработке, то для его полного переписывания должны быть какие-то ну очень веские причины. Иначе так можно постоянно переписывать и переписывать, сизифов труд получается. У меня был только один раз, когда я одну свою программу переписывал полностью. Это был парсер, который был очень большим и сложным. Дорабатывать его было настолько тяжело, что нецелесообразно, плюс мне не нравилась его архитектура. Когда же под устарелостью понимается несоответствие модным тенденциям, у меня это вызывает лютое охреневание и непонимание, так как несоответствие моде само по себе веской причиной не является. Следование моде есть ни что иное, как выполнение чужой воли, тех, кто её задаёт (если не сказать диктует). Многое из советской техники до сих пор работает и выполняет свою задачу ничем не хуже, а то и лучше современной, особенно что касается надёжности. Поводом для её замены может послужить разве что внешний вид или доступность запчастей. Вот и с софтом примерно так же. На эту тему есть известная фраза из анекдота: «вам шашечки или ехать?».