Как справляться с ситуациями с «истощением» программного обеспечения?

Когда поставщик заявляет, что он больше не намерен предоставлять какую-либо поддержку или услуги какой-либо части программного обеспечения (и заявляет о намерении выйти из бизнеса - не предлагая путей обновления), какой вид обращения доступен для клиента?

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

Вещи, которые я могу придумать:

Необходимо приобрести запасное оборудование и настроить запасную среду, в которой программное обеспечение может продолжать работать.
Различные методы экспорта данных, которые не требуют участия поставщика. (Это может включать в себя тривиальные методы, такие как проверка данных, хранящихся в бэкэнде товарной базы данных, в более сложные методы, такие как очистка экрана, печать на изображение с последующим повторным сканированием и т. Д.)
Параллельные системы, где сотрудники будут дублировать старые данные в новую систему вручную или полуавтоматически
Правовые средства, в случае, если у поставщика финансовые проблемы (как в случае условного депонирования исходного кода )

Есть еще идеи?

Предполагая, что не существует никакого «обхода» (без DRM, без DMCA), законно / приемлемо восстановление данных или обратный инжиниринг?

Отредактированная заметка:

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

— rwong
источник

Сколько времени здесь? Вы клиент или создаете продукт на основе вышеупомянутого поставщика?

Вы можете попробовать купить исходный код у поставщика, а затем поддержать себя? Это довольно сложная ситуация , чтобы быть в.

— btilly

Удивляет, почему данные не были сохранены в каком-то открытом формате для начала ... если они хранятся в виде обычного текста в БД, вы можете скопировать их. Если он хранится в формате xml / обычный текст, вы можете скопировать его. Если это бинарный / зашифрованный, то вам нужно взломать его. Это все выполнимо.

— Работа

@Job: согласился. Важность открытого / простого формата хранения (и концепция «привязки к поставщикам») признается уже более десяти лет. Решения, принятые несколько десятилетий назад, не имели бы такой выгоды задним числом. Тогда богатые клиенты шли с лидерами рынка независимо от стоимости, а менее обеспеченные клиенты должны были принять статус-кво или рискнуть.

— rwong

Подобные истории служат хорошим примером того, почему полезно иметь планы выхода данных. Это может быть использование открытых форматов, как предлагает @rwong, но это также должно означать наличие экспортных оговорок в контрактах.

— Смитко

Ответы:

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

Поскольку вы знаете, что это приложение - то, что вам нужно, возможно, если оно выполнимо, его время для собственной разработанной системы? Таким образом, вы не попадете в эту ситуацию снова.

— GrandmasterB
источник

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

— smithco
источник

Стажеры: местный эквивалент аутсорсинга

— Эрлз

Internsourcing!

— Пол Натан

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

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

Одно замечание: если система является чем-то общедоступной, то это плохой подход, потому что у вас нет способа применить обновления безопасности.

— Билл
источник