Comments 11
Это не спасёт, потому что код гниёт. Если кто-то хочет вам что-то похоронить (действием или бездействием), то он вам похоронит. Оно просто не будет работать на новой ОС с поддерживаемой версией языка и т.д. Через 3-5 лет у вас obsolete, через 7 вы на пятой центоси без права ставить из epel'а. А поддержка "своими силами" возможна только если это что-то очень простое.
Во-вторых, задача шире - dependency autonomy, и это не пять поставщиков "компонент". Свой миррор дистрибутива (с снапшотами перед обновлением), свой кеш pypi, npm, cargo, whatever. Свой миррор хаба с репликацией всех нужных имаджей. Свой гит с репликацией с GH/GL.
Если я правильно понял, то речь о code escrow. При депонировании кода надо публиковать каждую версию, чтобы код был актуален. Все зависимости должны быть включены. То есть заказчик получает последнюю версию кода продукта. Действительно, это нетривиальный этап перед релизом продукта. И итоговый пакет может включать огромный объем данных со всеми зеркалами. Некоторые репозитории предоставляют услугу проверки, как дополнительная гарантия, что код соберется.
Минус этого подхода в том, что часто используются проприетарные компоненты. И у того, кто будет использовать код должны быть соответствующие лицензии.
> Идеально устойчивый продукт тот, который разрабатывается полностью собственными силами, с использованием открытых технологий
> Минус этого подхода в том, что часто используются проприетарные компоненты
к сожалению есть одно обстоятельство которое надо учитывать, а именно независимо что написано например в gpl license, general law всегда имеет приоритет, и general law в том числе включает sanctions, кстати китайцы прекрасно знают это, и вероятно работают над своей собственной tool chain и пр., конечно не без копирования, что пока еще доступно в open source
Хорошее замечание. Тут есть целое поле для рассуждений.
Первый случай - санкции корпоративного уровня. Одна кампания не продает продукт другой компании, или не продляет контракт. От этого использование OSS спасает.
Второй случай - санкции государственного уровня и при этом OSS решение разрабатывается энтузиастами из разных стран. Это самый интересный вопрос: под какое законодательство попадает их продукт.
Третий случай - разработка OSS продуктов организациями. В этом случае законодательство страны регистрации регулирует деятельность компании.
imho, ситуация непредсказуемая даже для open source, если предположим сегодня доступ есть, нет гарантии что будет через неделю, собственно для этого даже не надо новых законов, чисто административные решения, на каком именно уровне существующие санкции известно, вероятно немецкая, швейцарская или иная юрисдикция в этом вопросе роли не сыграют
Большой компании важно не чтобы программа существовала. Её и так не отбирают. Важна поддержка, обновление, реагирование на ошибки запросы на обновление. Никакой code escrow тут не поможет.
А в условиях конкуренции это не просто важно - критически важно, потому что не просто отсутствие поддержки, но даже промедление может оказаться фатальным для продукта, в который вгрохана масса ресурсов.
Тема escrow по прежнему интересна. Мне казалось, что все копья сломали еще в предыдущий раз.
Выбор между остаться с ПО и без поддержки, или иметь ПО и его исходный код, который можно использовать для выпуска патчей или небольших доработок. Именно второе дает escrow.
Конечно этим пользуются крупные компании у которых либо есть внутренние возможности дорабатывать в случае доступа к коду, либо платить внешнему консалтингу.
Это не выбор вообще. Точнее, это выбор между "Найти замену немедленно!" и "найти замену за пару месяцев!", что в процессах крупной компании одно и то же. Крупной компании важно не чтобы программа могла выполнять какие-то функции, а чтобы она их выполняла гарантированно. Никто в коде копаться не будет, тем более, часто там не программисты этим занимаются, а девопсы. Нужна именно поддержка.
не чтобы программа могла выполнять какие-то функции, а чтобы она их выполняла гарантированно
На практике ПО чаще всего поставляется "как есть", а поддержка и гарантии - отдельным договором и за отдельный прайс. В таком случае, в общем-то, вполне достаточно того, чтобы программа в принципе существовала и работала: если официальный вендор не желает сотрудничать почему-то (санкции, кризис, маркетинговая политика), то наверняка найдётся сторонняя консалт/саппорт-компания, которая готова всё это обеспечить за, возможно, чуть большие деньги. Или, если у заказчика есть ресурсы, это можно устроить собственными силами, создав отдел поддержки.
Вы с энтерпрайзом давно последний раз работали? НИКТО не купит программу как есть, ТОЛЬКО с поддержкой. Когда в энтерпрайзе покупается что-то, человек платит не из своего кармана. И, часто, сам не пользуется. Ему пофиг, как оно работает и сколько стоит, важно чтобы вписалось в бюджет и его не сделали крайним. Вот чтобы не сделали крайним, ему важна поддержка. Чтобы поддержка и была крайней, если что. Нет поддержки - нет смысла покупать.
Устойчивое к санкциям ПО