Доисторические времена

Постепенное поэтапное улучшение (апгрейд) программного обеспечения не менее (и даже более) распространено, чем апгрейд "железа". Градуальность, постепенность наращивания возможностей в такой "мягкой" среде имеют тысячу и одно воплощение. Ввиду нематериального характера продуктов, сам процесс апгрейда занимает минимум времени и часто даже бесплатен. Быстрая разработка приложений, быстрое прототипирование, ставший уже обыденностью выпуск новых версий продукта вполне можно рассматривать как некие составляющие техники апгрейда.

Но все-таки мы ограничимся рассмотрением "классического" апгрейда - замены компонентов, имеющих стандартный интерфейс. Гибкость самого материала - программных кодов - придает апгрейд-ориентированному программированию такую распространенность, что само явление теряет контуры. Можно даже грубо заявить: все программы - это компоненты. Тогда замену одних программ на другие смело можно называть апгрейдами.

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

Версии

Один из самых знаменитых случаев нестандартного использования механизма версий - СУБД dBase-II, первой версии которой в природе не существовало. Замысел заключался в обходе предубеждения покупателей о "дырявости" всех первых версий. Нехитрый маркетинговый прием сработал великолепно.

Механизм замены версий программного обеспечения - это, безусловно, механизм апгрейда. Замена в сложном приложении одной версии программы на другую происходит только благодаря множеству первоначально незаметных интерфейсов: интерфейсу аппаратуры, программному интерфейсу операционной системы, пользовательскому графическому интерфейсу, всевозможным API (Application Programming Interface) и так далее. Новая версия программы, как правило, рассматривается как компонент и использует почти те же интерфейсы к своему окружению (операционной системе, ранее разработанным программам, данным, накопленным в ходе эксплуатации предыдущей версии), что и старая. При учете этого "почти" говорят о совместимости "сверху вниз" (когда новая версия работает с окружением старой версии, но не наоборот) и "снизу вверх" (когда старые версии могут работать с новым окружением). Чаще же всего попадаются "суженные расширенные" новые версии, часть возможностей которых по сравнению с предыдущими исчезает, а часть - появляется.

Вообще, апгрейд программ "целиком", путем замены версии, представляет собой, пожалуй, самый старый тип реализации бизнес-модели апгрейда. С выпуском продукта (первой версии) на рынок разработчики работу не прекращают, а продолжают выпускать все лучшие и лучшие варианты программы. Внутри версий существуют, как правило, "релизы" (release), внутри релизов - "билды" (builds). За новые релизы и билды денег не берут, их бесплатное распространение просто сохраняет клиентов для фирмы. А за переход со старой на новую версию (то есть апгрейд) владельцев старой, как правило, просят доплатить. В отличие от аппаратуры, такая стратегия для программ вполне прибыльна, если учесть нулевую цену копирования.

Shareware

Полная стоимость программного обеспечения имеет множество составляющих - стоимость его нахождения и тестирования, стоимость обучения, стоимость хранения бэкапа в сумме часто значительно выше, чем стоимость самой программы. Предположим, некий программист, получающий 600 долларов в месяц, тратит весь рабочий день на установку некой shareware-утилиты и обучение пользованию ею на таком уровне, чтобы понять ее полезность в его, программиста, конкретных условиях. Тогда траты на эту программу его работодателем уже составят $600/20рабочих_дней_в_месяц=$30, хотя за саму программу еще не уплачено ни цента.

Некоторые модели бизнеса shareware основаны как раз на поэтапном апгрейде. Нужно только учесть затратность "бесплатного" демонстрационного варианта. Скажем, для квалифицированного специалиста на далеком Западе в вышеприведенном примере неявные $30 легко могут вырасти до $150 при уровне зарплаты в 3000 долларов. Простое обращение внимания на данную программу сразу стоит $150! Поэтому первую ударную дозу, как водится, пользователь получает бесплатно, и я не удивлюсь факту приплаты разработчиком клиенту за первоначальную инсталляцию и опробование. Заплатит пользователь, как водится, потом, - за апгрейд до полнофункциональной версии (вторая, "поддерживающая" доза, - сумма за регистрацию с существенным подъемом функциональности).

Далее обычно предлагаются опять "бесплатные" обновления/дополнения, требующие все-таки трат на инсталляцию и дообучение, но позволяющие закрепить пользователя надолго. Затем в какой-то момент обязательно будет предложено "существенное добавление" или "новый блок", или "следующая версия", и на это вновь будут испрошены "живые" деньги.

Убедительный рост приверженцев бизнес-модели shareware (сейчас shareware занимаются и очень крупные фирмы, только слова такого не произносят) четко демонстрирует, что собственно стоимость программного средства может составлять не самую большую трату для пользователя. Гораздо дороже для пользователя обходится понимание собственных потребностей, а затем освоение нового инструментария.

Add-ons, add-ins, plug-ins

Лет десять назад появился новый класс продуктов - программы add-in и add-on.

Продукты add-on представляли собой программные компоненты, написанные с использованием средств программирования базовых для подобных продуктов систем. Очень популярны хитрые макрокоманды к МS Word или целые бухгалтерские системы к Exсel. Программы add-on не имеют никакого отношения к коду базовой программы, но очень полезны для сокращения времени программирования целевых приложений для всяческих крупных пакетов программ. Для существования рынка таких программ необходимо, прежде всего, существование большого числа пользователей базовой программы.

Add-in-программы как раз используют знание разработчиками внутреннего устройства базовой системы и "цепляются" к ключевым кускам кода базовой программы. Cама базовая программа "не знает" об их существовании. Именно так были устроены многие первые успешные русификаторы Windows.

Конечно, продукты в идеологии add-on и add-in существовали и ранее, но такое наименование они получили только после осознания рыночного потенциала подобных программ. Идея понравилась, привилась и усовершенствовалась.

В результате появилась концепция использования компонентов plug-in, динамически (без перекомпиляции) присоединяющихся на уровне кода к базовым программным комплексам. В отличие от add-in, компоненты plug-in используют специальные интерфейсы, специфицируемые разработчиками базовой системы. Подключение/исключение таких дополнительных компонентов часто называют регистрацией/дерегистрацией их в базовой системе, для чего также есть специальные управляющие интерфейсы.

Браузеры, графические и звуковые редакторы, редакторы текстов, медиаплейеры, СУБД - большинство современных программных продуктов имеет именно такую организацию. Терминология данной модели стремительно "устаканивается".

В результате рынок сегментируется - каждый профессиональный продукт состоит теперь из порознь продаваемых базового модуля и ряда plug-ins. Более того, plug-ins часто разрабатываются третьими фирмами, а разработчики базовой системы изо всех сил стимулируют их появление путем предоставления документации интерфейса plug-ins и даже некоторых интерфейсных компонентов. Разработчики справедливо полагают: был бы интерфейс, а компоненты найдутся. Не нужно объяснять, почему появление интерфейса компонентов plug-in для независимых разработчиков выгодно всем сторонам. Бизнес - это игра с положительной суммой.

Начало истории

Но, оказывается, все описанное выше - доисторическое время. История началась буквально в последние три года, когда появилась новая концепция, значимость которой для развития индустрии программного обеспечения сравнивают только со значимостью появления графических пользовательских интерфейсов. Имя концепции - "componentware" (компонентное обеспечение).

Конечно, новое - это хорошо забытое старое. Да и "старое" еще не слишком хорошо забыто. JavaBeans, DCOM, CORBA - все эти слова сейчас связывают с нашествием компонентной парадигмы в программировании.

В ближайшее время массовый пользователь получит возможность сборки своих полномасштабных приложений из специализированных программных компонентов различных независимых разработчиков. В традиционной литературе по componentware делается акцент именно на этапы поиска необходимых компонентов и последующую сборку приложений. Но я бы обратил внимание на следующий за этими этапами момент времени.

Да, действительно, буквально сразу после сборки и опробования приложения на реальных задачах пользователь захочет провести... апгрейд своей компонентной системы! И можно только догадываться, какие интерфейсы, способы доставки программного кода, модели ценообразования и бизнес-схемы придумают поставщики программных компонентов для удовлетворения вечной человеческой потребности в улучшении своих систем.