Здравствуйте, Nuzhny, Вы писали:

N>Ну так это в две стороны работает: начал писать своё, а потом оказывается, что надо поддерживать ещё другие ОС/платформы, страдает перформанс и т.д. А открытая библиотека силами сообщества или крупного вендора уже всё это умеет.

Да, бывает и так.

P>>Одни лицухи могут доставить вагон геморроя.
N>Так можно смотреть на них ДО того, как тащить проект к себе.

Интересуют вопросы не "до", а именно что после — смена лицензии у пакета, или изменение статуса с "можно" на "нельзя".


N>Стратегия пляски через готовые библиотеки и в короткой, и в длительной перспективе выгоднее всегда.

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

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

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

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

Здравствуйте, Nuzhny, Вы писали:

N>Ну так это в две стороны работает: начал писать своё, а потом оказывается, что надо поддерживать ещё другие ОС/платформы, страдает перформанс и т.д. А открытая библиотека силами сообщества или крупного вендора уже всё это умеет.

Да, бывает и так.

P>>Одни лицухи могут доставить вагон геморроя.
N>Так можно смотреть на них ДО того, как тащить проект к себе.

Интересуют вопросы не "до", а именно что после — смена лицензии у пакета, или изменение статуса с "можно" на "нельзя".


N>Стратегия пляски через готовые библиотеки и в короткой, и в длительной перспективе выгоднее всегда.

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

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

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

У библиотеки есть стоимость владения, и нынче один только выбор со сравнением аналогов, может обойтись в сумму, которая превосходит лицуху в разы.

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