Как мы решали задачу реализации trial-режима в анализаторе кода PVS-Studio




Для многих разработчиков программного обеспечения, выбор и изменение модели trial-режима является одной из самых трепетных и обсуждаемых задач. Для одних программ придумать модель проще, для других сложно. А некоторых людей не покидает вопрос: "Мы всё правильно сделали?". Актуальна задача выбора trial-модели и для нас, разработчиков PVS-Studio. Мы решили поделиться некоторыми сопутствующими мыслями и рассказать о том, какой новый вариант мы придумали. Надеемся, что наши рассуждения и некоторые мысли окажутся полезными и другим разработчикам.

Picture 1

Введение

Модель try-before-buy (или по-другому shareware) давно стала классической в современном бизнесе продажи программного обеспечения. Я искренне завидую тем, кто разрабатывает бесплатное и/или открытое программное обеспечение. Они в каком-то смысле избавлены от необходимости показать программу со всех сторон потенциальному пользователю и одновременно мотивировать его купить софт. Нет, конечно же, они должны продвигать свои программы и обилие рекламы Google Chrome и Mozilla Firefox тому подтверждение. Тем не менее там ситуация иная и я ее не рассматриваю.

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

Стандартный подход к продаже статических анализаторов кода

На сайтах лидеров индустрии (Coverity, Klocwork, Parasoft) вы всегда легко найдете кнопку "Free Trial" за которой, однако, кроется анкета: кто вы, откуда и зачем. Это делается для того, чтобы как можно раньше sales manager в костюме начал охоту, то есть работу. При этом саму программу пользователю иногда дают, а иногда и не дают. Почему? Ну потому что в идеале в крутых компаниях к достойному клиенту сразу же вылетает спецназ на вертолете в составе: менеджер по продажам, техническая команда для развертывания сложного окружения анализатора кода и запуска его на проекте клиента, а также человек с подвешенным языком для проведения презентации о найденных в коде потенциального клиента ошибках. После этого клиент говорит либо: "Да, мы берем этот продукт за много десятков-сотен тысяч долларов в год", либо: "Спасибо, не впечатлило".

Зачем выезд к клиенту, развертывание у него инфраструктуры и презентация по найденным ошибкам? Это делается потому, что ЛЮБОЙ статический анализатор кода дает ложные срабатывания. И если пользователь первые десять просмотренных сообщений увидит ложные срабатывания, то на 11 сообщение (даже если это реальная ошибка) он может сказать: "Это не ошибка". Просто потому что не внимателен. Конечно, читатель возразит: "Я – не такой!". Увы, но люди устроены именно так и ничего с этим не поделаешь. Поэтому лучше, когда намного более опытные люди просмотрят код потенциального клиента, найдут ошибки и сделают презентацию. Тогда, скорее всего, потенциальный клиент станет реальным. И это не только мои мысли. Об этом говорится в статье A Few Billion Lines of Code Later - Using Static Analysis to Find Bugs in the Real World, которую очень рекомендую прочитать тем, кто интересуется статическим анализом.

Как у нас в PVS-Studio было реализовано раньше

Мы – разработчики PVS-Studio – маленький стартап, и нам спецназ из предыдущего раздела пока недоступен. Но свои недостатки мы пытаемся превратить в преимущества. Поэтому у нас на сайте можно скачать trial-версию без всякой регистрации и ожидания, пока sales manager одобрит заявку на скачивание. Это ОЧЕНЬ нравится нашим потенциальным пользователям. Собственно "триальность" работы заключалась в том, что анализатор находил все ошибки в коде, но для некоторых не указывал, в каком они месте находятся. С таким trial-режимом мы жили довольно долго. И к нему накопились претензии:

  • Нередко получалось так, что интересные ошибки оказывались скрыты, а неинтересные (проще говоря, ложные срабатывания) наоборот показывались пользователю. Создавалось впечатление, что инструмент плохой.
  • Пользователи не всегда понимают, что выгода от статического анализа проявляется при регулярном использовании. Недостаточно один раз "прогнать" инструмент, исправить те ошибки, которые были показаны в trial-режиме, и успокоиться на этом. Важно регулярно его запускать, чтобы как можно быстрее находить ошибки, только что внесенные в код.
  • Наконец при таком trial-режиме очень трудно показать преимущества нашей очень крутой возможности Incremental Analysis. Это режим работы, когда статический анализатор автоматически запускается после компиляции и проверяет только те файлы, которые были изменены. Тем самым показывается не куча диагностических сообщений про весь проект, а только те сообщения, которые относятся к текущим изменениям пользователя. В случае если после правки двух-трех файлов и их перекомпиляции анализатор говорит про две ошибки, но одну из них не показывает – как-то не убедительно, что это крутая возможность.
  • Кроме того, мы так и не знали, кто потенциальные пользователи нашего продукта, так как нигде на сайте у нас нет регистрации и прочих подобных форм.

Исходя из этих недостатков, было принято решения изменить trial-модель, сохранив достоинство существующей версии в виде простоты скачивания.

Идеальный trial моей мечты

Здесь я немного отвлекусь от статических анализаторов и расскажу про две trial-модели, от которых я в восторге.

CAD-системы

Прежде всего, я завидую разработчикам CAD-систем, у которых часто trial выглядит так. Пользователю доступны все возможности программы постоянно и без ограничения времени. Единственное ограничения функциональности заключается в том, что... разработанную модель нельзя сохранить. Без этого функционала реальное использование инструмента невозможно, однако потенциальный пользователь может оценить все возможности программы. Супер, просто мечта.

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

Игры типа World of Warcraft

Сразу скажу, что я ни разу не играл в World of Warcraft и им подобные игры, но, насколько мне известно, там trial работает так. Пользователь может бесплатно начать играть, прокачать своего персонажа до какого-то уровня и только потом ему надо платить за продолжение. Это еще одна идеальная схема, так как никто, дойдя до 15-уровня, не сможет отказаться от продолжения.

Хотя с выходом шутливого плагина Visual Studio Achievements Extension для прокачки разработчиков под Visual Studio прокачка стала актуальна и для программистов, все-таки нам это никак не приспособить.

Что в итоге сделали мы в PVS-Studio

Мы придумали использовать концепцию "кликов" – это переход к исходному коду с ошибкой при помощи клика в списке сообщений. Скачав PVS-Studio без всяких регистраций, потенциальный пользователь получает полнофункциональную версию анализатора кода. Он может проверять ей какие угодно проекты сколько угодно раз. Он получает полный список сообщений. Но у него есть только какое-то ограниченное количество кликов (переходов к коду). Например, 100. Но число не принципиально и возможно мы его будем менять. Таким образом, пользователь может посмотреть и перейти к 100 диагностикам. Повторюсь, без каких либо ограничений.

Если пользователь израсходовал эти клики, то он должен принять одно из следующих решений:

  • либо купить лицензию;
  • либо отказаться от использования инструмента, если он ему не понравился;
  • либо попросить у нас продлить trial-режим, предоставив информацию о себе, чтобы мы могли уже как-то с ним поработать в почте.

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

А вот продление режима у нас в версии PVS-Studio 4.54 реализовано так. После окончания кликов пользователь отсылает нам e-mail со следующей информацией: имя, компания, причина продления trial-режима. И мы ему даем ключик еще на одну неделю. То есть имеется некоторое количество ручной работы с нашей стороны.

В следующей версии после 4.54 мы это переделаем. Будет в программе автоматическая форма для указания этой информации, и после ее отправки пользователь будет получать еще, к примеру, 500 кликов. Продлеваться trial-режим будет один раз.

Если пользователь не хочет продлевать trial, то у него будут следующие ограничения:

  • При проверке новых проектов не будут выдаваться имена файлов с ошибками. Вместо них будет фраза "TRIAL RESTRICTION".
  • Если пользователь открывает заранее сохраненный лог с найденными ошибками, то у него не будет работать переход к коду по клику.

Конечно же, пользователь, даже имея 0 кликов, может открыть заранее сохраненный отчет и вручную выполнять навигацию – открывать файл, переходить к соответствующей строке в нем. Это сделать можно. Но надо понимать, что статический анализ – это инструмент, который, прежде всего, позволяет экономить время (за счет раннего обнаружения ошибок в программах до релиза, а не после). Если же время потенциального пользователя дешевое или бесплатное настолько, что он готов делать навигацию вручную, то статический анализ не для него и он не наш клиент в любом случае.

Выводы

Мы надеемся, что новая trial-модель в конечном итоге позволит нам увеличить продажи. Ну а что вы сейчас должны сделать, так это скачать PVS-Studio и попробовать нашу идею с кликами на себе.



Найдите ошибки в своем C, C++, C# и Java коде

Предлагаем попробовать проверить код вашего проекта с помощью анализатора кода PVS-Studio. Одна найденная в нём ошибка скажет вам о пользе методологии статического анализа кода больше, чем десяток статей.

goto PVS-Studio;


Найденные ошибки

Проверено проектов
344
Собрано ошибок
12 970

А ты совершаешь ошибки в коде?

Проверь с помощью
PVS-Studio

Статический анализ
кода для C, C++, C#
и Java

goto PVS-Studio;