Стратегия выкручивания рук или сам себе разработчик СУБД

Как разработчику прикладного ПО правильно решить вопрос с импортозамещением СУБД?

• Вариант 1. Мигрировать на незапрещенную СУБД.
• Вариант 2. Самому стать разработчиком СУБД на базе СПО и мигрировать на нее.

А как происходит на практике? Конечно, доминирует первый вариант. Но крупнейшие игроки в разных секторах рынка тяготеют ко второму. И, похоже, в конечном счете реализуют именно его. Хотя создание СУБД – отдельная жизнь, годы работы, огромные инвестиции и риски, потому что для разработки СУБД нужен совсем другой опыт, чем тот, что имеют вендоры прикладного ПО.

Почему же «большие» выбирают этот путь? Потому что второй вариант - это:

• реальная независимость, ни от импорта, ни от чего/кого другого; заманчиво, да еще с учетом, что культура работы с вендорами у отечественных разработчиков СУБД хромает на всех этапах взаимодействия;
• прямой путь к монополизации рынка и расширению сфер собственного влияния; если заказчик вложился в поставщика ERP или АБС на собственной СУБД, такому заказчику легче продать смежный софт на той же платформе управления данными, пусть даже его функциональная готовность слабее, чем у других специализированных поставщиков.

Думается, что второй аргумент много важнее первого – он открывает перспективы зачистки рынка от конкурентов, потому что стратегическим конкурентным преимуществом становится новая СУБД, а не уникальные знания и проектный опыт, аккумулированные в механизмах прикладного ПО.

Это не плохо и не хорошо. Это уже практически данность – объективная действительность, в перспективе которой – получение подавляющего преимущества и, как следствие, стратегия выкручивания рук. Правда в силу масштабности задачи эта перспектива - дальняя, а на среднем горизонте потенциальных монополистов скорее всего опередят разработчики, выбравшие первый вариант импортозамещения. Сохранится ли благодаря этому паритет на рынке? Что думаете, коллеги?