Как мы переделываем открытое ПО
Рассказываю про одно из относительно новых, но невероятно сложных и интересных направлений моей работы.
Задача
Допустим у вас есть софт, построенный на куче открытых библиотек и фреймворков.
Софт становится популярным, его начинают использовать в абсолютно разных окружениях, в компаниях разного размера, с различным уровнем подготовки сотрудников и так далее.
В какой-то момент вы обнаруживаете что 90% проблем, о которых вам сообщают пользователи, происходят уже не из вашего собственного кода а из кода библиотек, которые вы когда-то использовали.
Возможно вы даже уже пробовали делать патчи и слать в апстрим, но довольно быстро поняли что с той стороны свои интересы и свои пользователи, ради которых каждая библиотека и поддерживается. И вам с вашими патчами там не очень рады.
И вот уже для того чтобы продолжать радовать пользователей, вам нужно «освоить и затянуть» к себе в проект какие-нибудь Apache Commons и тот же Eclipse Jetty.
Внезапно оказывается, что эти проекты по количеству кода и сложности превосходят ваш собственный на порядок, при этом содержат кучу всего ненужного.
Тут и использование AccessController, который удалили из последних версий JDK и использование InputStream без закрытия (а это потенциальная утечка памяти).
И мест таких в чужом проекте будет очень много.
Теперь помножьте это на объемы популярных библиотек и получите печальную перспективу обосраться.
Что мы делаем
Это прямой результат нашей работы за полгода - кастомная версия Jetty, откуда было вырезано все ненужное для конкретного проекта: JMX, JNDI, JSP, всякая телеметрия и статистика (коей там немало внутри), поддержка устаревших протоколов и запуска на разных серверах приложений.
Оставшийся код был вычищен вручную с помощью анализатора Intellj.
Получилась маленькая библиотека, собираемая в .jar-файл размером ~1Мб, которая отлично встраивается и что самое главное — ее реально поддерживать небольшими силами не очень опытной команды.
Вопрос безопасности
Когда начинаешь таким заниматься и подобное предлагать клиентам в качестве решения — обязательно вылезут «говорящие головы», сделают страшные глаза и начнут вещать про уязвимости:
Обновляйтесь! Ибо только благословленный апдейт от святого вендора защитит рабов божьих от чертей компьютерных!
Если серьезно то речь про стандартную практику постоянного обновления версий используемых библиотек с последующим глубоким тестированием.
К сожалению персонажи, предлагающие такое на серьезных щщах — почему-то никогда сами подобное не делали на сколь-нибудь крупном и популярном проекте.
А я делал и могу сказать что как только ваш проект стал успешным — последнее что ваше руководство будет терпеть это его нестабильность, поэтому малейший намек на возможную нестабильную работу и вашу инициативу по обновлению тут же задавят.
Гарантировать же что ничего не сломается при обновлении мажорной версии какого-нибудь Spring очевидно нельзя.
Поэтому под всеми популярными проектами с миллионами пользователей всегда есть гора легаси кода.
Особенности новой реальности
К сожалению сытые времена, позволяющие абсолютное доверие к вендору прошли, сейчас ситуация такова что все друг другу гадят, друг за другом следят и недоверяют.
С точки зрения продуктовой разработки это означает необходимость полного владения проектом и его регулярного аудита.
Наш опыт ковыряния популярных библиотек и фреймворков показал, что внутри очень много потенциально опасных мест, которые могут быть использованы для пенетрации вашего замечательного проекта.
В самый неожиданный момент, разумеется.
Apache Commons: IO, Lang, Text, Collections, Codec, Beanutils
Каждую из этих библиотек удалось серьезно уменьшить, вычистить устаревший и неиспользуемый в проекте код. Что дало определенный прирост производительности.
Вообщем это достаточно сложная и опасная игра для смелых и если готовы в нее сьиграть — пишите.
Злой дух опенсорса
Вам может показаться что происходит нарушение принципов опенсорса и воровство чужого кода.
Самое главное что вы должны понимать:
кастомизация под себя открытого ПО — устоявшаяся мировая практика.
Так делают во всех крупных компаниях по всему миру.
А вот отправка своих доработок в апстрим далеко не всегда разумна, поскольку часто ваши идеи и доработки просто не соотносятся с планом развития открытого проекта.
И конечно же процесс «выбрасывания всего ненужного с вашей точки зрения» уж точно до апстрима никогда не дойдет.