Прочитал статью коллеги Andrey2008 о добавлении, а точнее сопротивлении добавлению в проект библиотек и решил описать «чек-лист» который я использую в работе со сторонними компонентами. Пока соотношение решений в пользу готовых/написанных с нуля за последние лет 10 примерно укладывается в пресловутые 80/20, может это мне просто везет.

Лицензия

К сожалению, крупные компании обычно имеют явный запрет на GPL/LGPL и некоторые другие лицензии. Данный запрет обычно идет со стороны департамента по интеллектуальной собственности и патентам и преодолеть его практически невозможно. Иногда выходом может стать двойное лицензирование (GPL/LGPL и коммерческая платная лицензия) — но часто бывает проще поискать другой вариант.

Деньги

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

Альтернативы

Требуйте от разработчиков как минимум две альтернативы предлагаемому компоненту и анализ их преимуществ/недостатков. Поскольку мало кто знает три разных библиотеки для каждой функциональности — это заставит людей общаться между собой. В процессе этого общения часто находятся какие-то вещи из предыдущих проектов или предлагаются более предпочтительные альтернативы.

Сообщество

Обязательно надо проверить насколько активно сообщество разработчиков данного компонента. Если это большая компания или популярный Open-Source проект — поищите блоги и другие публикации посвященные ему и посмотрите на даты. Это поможет вам понять, насколько библиотека или компонент интересны как пользователям так и самим разработчикам и как они развиваются.

Поддержка

Продолжая предыдущий пункт — существует ли официальная поддержка (как бесплатная так и платная). Даже при интеграции компонента часто проще заплатить 100-200 долларов кому-нибудь из авторов за пару часов поддержки вместо того чтобы ломать голову какая версия Питона нужна для запуска каких-нибудь хитрых скриптов без которых оно не компилируется.

Код

Для Open-Source — посмотрите код, проверьте его хотя бы простеньким статическим анализатором. Если код нечитабельный, имеет плохую структуру, отсутствуют комментарии или анализатор ругается на множественные проблемы — лучше от такого отказаться сразу.

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

Ответственный

Кто и как отвечает за добавленный код? Это может быть конкретный человек который его добавил, вся его скрам-команда, дежурная команда «скорой помощи» или кто-то еще — но если «что-то пойдет не так» в интеграции, тестах или последующем обновлении кода на машинах других разработчиков должно быть известно к кому обращаться.

Дизайн и документация

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

Техдокументация и дедлайны

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

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

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