Когда поставщик заявляет, что он больше не намерен предоставлять какую-либо поддержку или услуги какой-либо части программного обеспечения (и заявляет о намерении выйти из бизнеса - не предлагая путей обновления), какой вид обращения доступен для клиента?
Пожалуйста, рассмотрите это с точки зрения клиента . ИТ-персонал заказчика, скорее всего, рассмотрит только технические варианты, но, скорее всего, есть и нетехнические варианты, которые клиент также может использовать. Кроме того, какие разумные шаги могут быть предприняты клиентом заблаговременно, чтобы минимизировать нарушение, например, в условиях контракта?
Вещи, которые я могу придумать:
- Необходимо приобрести запасное оборудование и настроить запасную среду, в которой программное обеспечение может продолжать работать.
- Различные методы экспорта данных, которые не требуют участия поставщика. (Это может включать в себя тривиальные методы, такие как проверка данных, хранящихся в бэкэнде товарной базы данных, в более сложные методы, такие как очистка экрана, печать на изображение с последующим повторным сканированием и т. Д.)
- Параллельные системы, где сотрудники будут дублировать старые данные в новую систему вручную или полуавтоматически
- Правовые средства, в случае, если у поставщика финансовые проблемы (как в случае условного депонирования исходного кода )
Есть еще идеи?
- Предполагая, что не существует никакого «обхода» (без DRM, без DMCA), законно / приемлемо восстановление данных или обратный инжиниринг?
Отредактированная заметка:
Это сочетание нескольких анекдотических, но реальных историй. Я не принимаю непосредственного участия ни в одном из них. Это просто мое желание узнать о том, как в целом обрабатывается ситуация, связанная с окончанием срока службы программного обеспечения. Я не намерен делать оригинальную историю звучащей слишком «трудной» для решения.
Ответы:
Обратный инжиниринг вполне приемлем по вашим собственным данным. Предполагая, что у вас есть файлы базы данных для начала. Если это хостинговый сервис, вам, возможно, лучше просто заплатить комиссию и попросить их экспортировать данные. IMO, это очень грубо и непрофессионально с их стороны требовать плату за это, но некоторые люди не заботятся о таких вещах.
Поскольку вы знаете, что это приложение - то, что вам нужно, возможно, если оно выполнимо, его время для собственной разработанной системы? Таким образом, вы не попадете в эту ситуацию снова.
источник
Одна из стратегий, которой нет в вашем списке, - пригласить команду стажеров и дать им лето, чтобы разобраться. Поскольку это, вероятно, будет одноразовый проект, не будет иметь значения, хорош ли код, занимает ли это много часов или просто требует много ручного ввода данных.
источник
Если продукт является чем-то, что вам не нужно вносить изменения, не предвидите, что вам потребуются изменения и оно будет работать на вашем собственном оборудовании, всегда есть возможность принять риск, чтобы продолжать использовать его.
Это не фантастика, и это может быть неприятно, но в зависимости от продукта и поставщика вы можете найти, если подумаете, что ситуация ничем не отличается от ситуации, когда поставщик технически его поддерживал.
Одно замечание: если система является чем-то общедоступной, то это плохой подход, потому что у вас нет способа применить обновления безопасности.
источник