Open source обычно не приходит в проект как большое стратегическое решение. Чаще все проще. Есть задача, есть срок, есть готовая библиотека. Разработчик смотрит документацию, проверяет пример, подключает решение и идет дальше.
И чаще всего он прав.
Странно писать с нуля то, что давно существует и нормально работает. В любом серьезном продукте уже есть чужой код: фреймворк, база данных, сборка фронтенда, кеш, логирование, очередь задач, админка, модули для форм, авторизации или интеграций. Без этого разработка стала бы медленнее и дороже.
Для бизнеса open source тоже выглядит понятно. Быстрее стартуем. Меньше платим на первом этапе. Не покупаем лишние лицензии. Не тратим команду на базовую механику. Сразу идем к тому, ради чего проект вообще начался: личному кабинету, порталу, заявкам, обмену с 1С или CRM, отчетам, админке, работе с данными.
На этом месте обычно и появляется ошибка. Open source начинают воспринимать как «взяли готовое и забыли». Но в продукте так не бывает.
Если библиотека участвует в работе сервиса, ее придется поддерживать. Следить за версиями. Проверять обновления. Понимать, где она используется. Держать в голове, что она может повлиять на соседние функции. И желательно не только в голове, а в документации.
Иначе через несколько месяцев быстрый старт начинает стоить дороже, чем казалось.
Сам по себе open source — не проблема. Наоборот, во многих проектах он сильно помогает.
Когда мы делаем корпоративный сайт, портал или личный кабинет, заказчик не ждет от команды собственного фреймворка. Ему нужен рабочий инструмент. Чтобы заявки не терялись. Чтобы контент можно было править без разработчика. Чтобы данные уходили в нужные системы. Чтобы сотрудники видели свои роли и права. Чтобы после запуска сервис можно было поддерживать, а не разбирать заново перед каждой доработкой.
Готовые решения помогают быстрее собрать основу. Команда не пишет с нуля то, что уже много раз написано и проверено. Она быстрее переходит к бизнес-логике, интеграциям, интерфейсам и данным.
В этом смысле open source действительно снижает стоимость старта. Особенно если нужно быстро проверить идею, сделать первую версию продукта или собрать внутренний сервис для компании.
Но экономия работает только тогда, когда решение выбрали под задачу, а не просто потому, что оно первым нашлось в поиске.
Одна библиотека может быть нормальным рабочим инструментом. Другая может потянуть за собой тяжелую платформу, сложные настройки и ограничения, которые потом будут мешать. На старте разница может быть не видна. На поддержке она становится очевидной.
С open source редко бывает так, что все ломается в первый день. Обычно наоборот. Все нормально подключилось, функция заработала, релиз прошел.
Потом продукт начинает расти.
Например, в личном кабинете сначала нужны простые роли. Администратор, менеджер, пользователь. Берем готовый модуль прав доступа. Он быстро закрывает задачу.
Через какое-то время появляются филиалы. Потом внешние подрядчики. Потом доступ по регионам. Потом ограничения по договорам. Потом разные права для поддержки, руководителей, бухгалтерии или партнеров.
И модуль, который сначала решал одну небольшую задачу, начинает влиять на работу половины сервиса. От него зависят данные, админка, интерфейс, API и новые доработки.
Это не значит, что модуль плохой. Возможно, он отлично подходил для первой версии. Просто первая версия уже закончилась, а продукт пошел дальше.
Вот здесь и появляется разница между «подключили библиотеку» и «нормально внедрили решение». В первом случае команда просто закрыла задачу. Во втором — заранее подумала, что будет, когда продукт начнет меняться.
Если этого не сделать, начинаются мелкие обходы. Где-то добавили исключение. Где-то проверили права вручную. Где-то временно продублировали логику. Потом временное остается в рабочей системе, потому что на него уже успели опереться другие функции.
Так появляются проблемы, которые никто специально не планировал. Они просто накапливаются.
У многих open source-решений нет платы за лицензию. Это удобно. Но это не значит, что решение ничего не стоит.
Стоимость просто появляется в другом месте.
Нужно настроить библиотеку. Проверить, что она подходит к стеку. Обновлять версии. Следить за уязвимостями. Понимать, какие зависимости она добавила в проект. Описать настройки. Объяснить новой команде, почему выбрали именно это решение.
Если библиотека отвечает за мелочь, все это почти не чувствуется. Если она стоит в авторизации, обмене данными, обработке персональных данных, платежах, загрузке файлов или деплое, цена ошибки становится другой.
На поддержке это выглядит очень приземленно. Заказчик просит небольшую доработку. Например, добавить поле, изменить форму или поправить правило доступа. Команда открывает проект и видит старую библиотеку.
Новая версия не подходит к текущему стеку. Старая давно не обновлялась. Внутри есть ручная правка. Документации нет. Разработчик, который это делал, уже не работает с проектом.
И задача перестает быть маленькой. Перед доработкой сначала нужно понять, как устроено старое решение и что может сломаться рядом.
Для бизнеса это выглядит странно. Просили поправить одну вещь, а получили длинную оценку. Но причина часто не в самой доработке. Причина появилась раньше, когда готовое решение быстро подключили и не оставили после себя понятных следов.
Такое бывает чаще, чем хотелось бы.
Библиотека почти подходит. Не хватает одной детали. Сроки сжаты. Настроек мало. Делать нормальное расширение дольше. Разработчик открывает код библиотеки и правит его напрямую.
На ближайшем релизе это может помочь. Функция заработала, задача закрыта, все пошли дальше.
Проблема приходит позже. Нужно обновить библиотеку, а ручная правка может пропасть. Не обновлять тоже плохо, потому что старая версия устаревает. Переносить изменение вручную можно, но сначала надо понять, что именно меняли и почему.
В итоге чужой код становится почти своим, только без нормальной истории. Он лежит внутри зависимости, но уже влияет на работу продукта.
Если библиотеку нужно менять, лучше делать это открыто. Через отдельный слой, расширение, плагин, форк или хотя бы описанный патч. Это дольше на первом шаге, зато потом не нужно бояться каждого обновления.
Быстрые правки в чужом коде редко остаются бесплатными. Они просто предъявляют счет позже.
Open source не означает «можно использовать как угодно». У каждого решения есть лицензия.
Для внутреннего сервиса это может быть простым вопросом. Для продукта, который передают заказчику, продают, тиражируют или развивают как SaaS, условия уже важнее.
Плохой момент для проверки лицензии — перед запуском. Код уже написан, библиотека встроена, сроки согласованы. Если в этот момент выясняется, что условия не подходят, проблема быстро становится технической. Нужно менять библиотеку или переписывать часть логики.
С безопасностью похожая история. Команда может подключить одну библиотеку, а вместе с ней получить еще несколько зависимостей. Часть работает только при сборке. Часть попадает в продакшен. Часть давно не обновлялась.
Когда появляется информация об уязвимости, важно быстро понять, есть ли эта библиотека в проекте и где она используется. Если учета нет, начинается ручной поиск по репозиториям, серверам, контейнерам и старым веткам.
Для систем с персональными данными, заявками, договорами, платежами или внутренними учетными системами это плохой сценарий. Там нужно заранее понимать, что стоит в проекте и кто за это отвечает.
Иногда готовое решение только кажется удобным.
Например, ради одной функции в проект добавляют большую платформу. Сначала это ускоряет работу. Потом приходится поддерживать лишние настройки, зависимости и обновления, которые бизнесу не нужны.
Бывает и другая ситуация. Библиотека почти подходит, но ее постоянно приходится подгонять под процесс компании. Сначала это выглядит как настройка. Потом появляются исключения. Потом обходы. Потом продукт начинает работать не так, как нужно бизнесу, а так, как позволяет инструмент.
В таких случаях иногда проще написать свой небольшой модуль. Не потому, что open source плохой. А потому, что конкретное решение не подходит под конкретную задачу.
Коммерческий продукт тоже иногда спокойнее. Например, когда нужна поддержка поставщика, SLA, сертификация или понятная ответственность за работу решения. Это не делает коммерческое ПО лучше во всех случаях. Просто у него другой набор плюсов и минусов.
В реальных проектах чаще всего получается смешанная история. Где-то используется open source, где-то пишется собственная логика, где-то берется коммерческий продукт. Главное — понимать, почему выбрано именно так.
Перед тем как добавить open source в проект, не нужно устраивать долгие обсуждения. Но несколько вещей лучше понять сразу.
Зачем берем эту библиотеку. Где она будет использоваться. Насколько она важна для продукта. Кто будет ее обновлять. Подходит ли лицензия. Есть ли нормальная документация. Что будет, если через год ее придется заменить.
Если ответы есть, решение можно спокойно брать в работу.
Если ответов нет, библиотеку просто быстро подключили. Это еще не значит, что ее правильно внедрили.
Open source дает бизнесу скорость на старте. Это его сильная сторона. Он помогает не писать с нуля то, что уже давно решено.
Но после запуска готовое решение становится частью проекта. Его нужно обновлять, проверять, описывать и учитывать при доработках.
Если этого не делать, быстрый старт легко превращается в дорогую поддержку.
Поэтому вопрос не в том, использовать open source или нет. Использовать. Без него нормальная разработка почти невозможна.
Вопрос в другом: кто потом будет за это отвечать.
Если ответ есть, open source помогает продукту.
Если ответа нет, это не экономия. Это проблема, которую просто отложили на потом.