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

Поскольку СПО становится все популярнее, то можно предсказать расширение сервисной модели бизнеса, так как она весьма перспективна.

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

Важно понимать, что это справедливо только для России (и похожих на нее стран), поскольку западный бизнес достаточно активно осваивает еще одну модель — продажу устройств, работающих под управлением Linux. На выставке CES'2010 в Лас-Вегасе было представлено несколько новых и очень интересных устройств на базе Linux. Их производят практически все ведущие мировые бренды — Dell, Hewlett-Packard, Sony, MSI, Lenovo, Marvell, ZiiLabs...

Интересно, что по этому пути пошел и наш ближайший западный сосед — Украина. Устройство для чтения электронных книг PocketBook уже давно активно продается, в том числе и в России.

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

Сейчас же будем говорить о том, что есть, — об услугах. В чем достоинства и недостатки этой модели? Может ли ИТ-бизнес, особенно мелкий региональный, ориентироваться только на нее?

Парадокс распространения

Теоретически отказ от оплаты байтов должен привести к тому, что количество пользователей, желающих познакомиться с программным решением, будет серьезно расти. Автоматически снимаются проблемы с “легальными источниками”, потребитель может не опасаться, что в самый нужный момент приложение перестанет работать и потребует что-то кому-то заплатить... В общем скачал откуда угодно и знакомься на здоровье. Причем совершенно бесплатно. Контракт на техподдержку можно заключить когда угодно. Если, конечно, она вообще понадобится.

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

Простота получения программы, конечно, играет какую-то роль. Однако вряд ли определяющую. Нужны активная рекламная компания, много независимых обзоров, положительные отзывы на форумах... То есть в конечном итоге — деньги.

И получается заколдованный круг. Чтобы грамотно продвигать продукт нужны деньги, заработать которые можно на распространении уже популярного продукта. Или СПО-бизнесу надо придумывать какие-то хитрые ходы, которые позволят радикально снизить расходы на традиционные мероприятия по “раскрутке” программного продукта, чтобы второстепенные факторы тоже начинали играть значимую роль.

Парадокс техподдержки

Большинство вопросов, поступающих в техподдержку, связано с тем, что пользователь банально что-то не умеет делать. Специалист при этом не вносит каких-то изменений в код программ, а просто рассказывает, каким образом надо выполнить ту или иную операцию. Вопросов, которые требуют устранения каких-либо ошибок в самом приложении, очень немного. И решают их уже не “на местах”, поскольку для этого требуется обращение к разработчику.

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

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

Аудитория такой поддержки — пользователь неосведомленный. Чем таких больше, тем компаниям, предоставляющим эти услуги, лучше. Стало быть, бизнес, ориентирующийся на сервис, нисколько не заинтересован в уменьшении числа компьютерных “чайников”.

Как следствие — ему нет никакого коммерческого резона писать к своим программам внятные и доступные инструкции, поскольку в данном случае учить пользователя приходится буквально на свою голову.

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

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

Фактически — Сцилла и Харибда. Проплыть по узкому ущелью очень сложно. А все, что сложно, то дорого. Получается еще один заколдованный круг.

Парадокс контракта

Несмотря на то что ПО — объект виртуальный, процедура его покупки не слишком отличается от того, к чему привык потребитель. Разница только в том, что он меняет деньги не на осязаемую вещь, а на набор байтов.

Покупка контракта на техподдержку — совсем другое дело. В обмен на вполне реальные деньги потребитель получит обещание решить его проблемы, если таковые наступят. Фактически — некий виртуальный фьючерс.

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

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

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

Таким образом, обязательства по технической поддержке могут звучать примерно так. Что можем сделать — сделаем, что не можем — сообщим тому, кто может, и будем ждать ответа. Очевидно, что пользователя это вряд ли устроит.

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

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

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

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

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

Парадокс взаимопонимания

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

Это концепция сотрудничества, а не потребления. Действительно, в СПО грань между создателем продукта и его пользователем несколько размыта. Тем более что по правам они вообще ничем не отличаются один от другого.

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

Причем сумма в данном случае не принципиальна. Если в продукте, который стоит хоть какие-то деньги (берутся ли они за сам продукт или за его поддержку — несущественно), пользователь обнаруживает ошибку, то он будет не столько помогать ее исправить, сколько возмущаться самим фактом ее появления и, вероятнее всего, публично. Мол, это СПО — сплошной развод, я заплатил, а ничего не работает. Вот именно в таком тоне. Можно попробовать оправдаться: “А что вы хотите за такие деньги?”, хотя вряд ли это можно признать хорошим маркетинговым ходом.

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

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