How we solved the task of implementing a trial mode in the PVS-Studio code analyzer

For many software developers, choosing and changing the model of the trial mode is one of the most reverent and discussed tasks. For some programs, it is easier to come up with a model, for others it is difficult. And some people do not leave the question: "We did everything right?". The task of choosing a trial model for us, the PVS-Studio developers, is relevant. We decided to share some related thoughts and talk about the new version we came up with. We hope that our reasoning and some thoughts will be useful to other developers.


')

Introduction

The try-before-buy model (or shareware in another way) has long become a classic in modern business selling software. I sincerely envy those who develop free and / or open source software. In a sense, they are spared the need to show the program from all sides to a potential user and at the same time motivate him to buy software. No, of course, they have to promote their programs and the abundance of Google Chrome and Mozilla Firefox advertisements to that. Nevertheless, the situation is different there and I do not consider it.

So what do we have? Static code analyzer is a tool that finds errors in programs like diagnostic messages from the compiler. Need to sell this tool to the user.

Standard approach to selling static code analyzers

On the websites of industry leaders (Coverity, Klocwork, Parasoft), you can always easily find the “Free Trial” button for which, however, lies the questionnaire: who are you, where are you from and why. This is done so that as soon as possible the sales manager in a suit starts hunting, that is, work. In this case, the program itself is sometimes given to the user, and sometimes not given. Why? Well, because, ideally, in a cool company, special forces on a helicopter immediately take off to a decent client: sales manager, technical team to deploy a complex code analyzer environment and launch it on the client’s project, as well as a person with a pendant language to make a presentation about the found in the code of potential client errors. After that, the client says either: “Yes, we take this product for many tens to hundreds of thousands of dollars a year,” or: “Thank you, not impressed.”

Why go to the client, deploying infrastructure and presentation of the errors found? This is done because ANY static code analyzer gives false positives. And if the user sees the first ten messages viewed by false positives, then at 11 messages (even if this is a real error), he can say: "This is not an error." Just because it is not attentive. Of course, the reader will object: “I am not like that!”. Alas, but people are arranged exactly that way and nothing can be done about it. Therefore, it is better when much more experienced people look at the code of a potential client, find errors and make a presentation. Then, most likely, the potential client will become real. And this is not just my thoughts. This is stated in the article A Few Billion Lines of Code Later - Using the Static Analysis of the Bug in the Real World , which I highly recommend to read for those interested in static analysis.

As in PVS-Studio, it was implemented before

We, the developers of PVS-Studio, are a small startup, and the special forces from the previous section are not yet available to us. But we are trying to turn our disadvantages into advantages. Therefore, on our site you can download the trial version without any registration and waiting until the sales manager approves the request for download. This is very popular with our potential users. Actually the “triality” of the work was that the analyzer found all the errors in the code, but for some did not indicate where they were located. With this trial mode, we lived for a long time. And claims have accumulated against it:

1. Often it turned out that interesting errors were hidden, and uninteresting (in other words, false positives), on the contrary, were shown to the user. The impression was that the tool was bad.
2. Users do not always understand that the benefits of static analysis manifest with regular use. It is not enough to “drive out” the tool once, correct the errors that were shown in trial mode, and settle down on it. It is important to run it regularly in order to find errors just introduced into the code as quickly as possible.
3. Finally, with this trial mode, it is very difficult to show the benefits of our very cool ability to Incremental Analysis. This is the mode of operation when the static analyzer automatically starts after compilation and checks only those files that have been changed. This does not show a bunch of diagnostic messages about the entire project, but only those messages that relate to the current user changes. If after editing two or three files and recompiling them, the analyzer says about two errors, but it does not show one of them - somehow it is not convincing that this is a cool opportunity.
4. In addition, we did not know who the potential users of our product are, since we have no registration and other similar forms anywhere on the site.

Based on these shortcomings, it was decided to change the trial model, while maintaining the merit of the existing version in the form of ease of downloading.

Perfect trial of my dreams

Here I’ll distract a little from static analyzers and tell you about two trial models I’m delighted with.

CAD systems

First of all, I envy the developers of CAD-systems, which often trial looks like. The user has access to all the features of the program constantly and without time limit. The only limitation of functionality is that ... the developed model cannot be saved. Without this functionality, the actual use of the tool is impossible, but a potential user can appreciate all the features of the program. Great, just a dream.

Unfortunately, it is not suitable for static analysis, as a report on the errors found can be saved, but it is not such a necessary thing as in CAD systems.

Games like World of Warcraft

I’ll say right away that I have never played World of Warcraft and similar games, but as far as I know, the trial works there. The user can start playing for free, pump his character to a certain level and only then he has to pay for the sequel. This is another ideal scheme, since no one, having reached the 15th level, will be able to refuse to continue.

Although with the release of the playful Visual Studio Achievements Extension plug-in, developers have been upgraded to Visual Studio, and the leveling has become relevant for programmers as well, it’s still not possible for us to adapt it.

What we finally did in PVS-Studio

We came up with the concept of "clicks" - this is a transition to the source code with an error by clicking on the message list. After downloading PVS-Studio without any registration, a potential user gets a fully functional version of the code analyzer. He can check her any projects any number of times. He gets a full list of messages. But he has only a limited number of clicks (transitions to the code). For example, 100. But the number is not important and maybe we will change it. Thus, the user can view and go to 100 diagnostics. I repeat, without any restrictions.

If a user has spent these clicks, then he must take one of the following decisions:

• either buy a license;
• or refuse to use the tool if he did not like it;
• or ask us to extend the trial mode by providing information about ourselves so that we can somehow work with it in the mail.

When buying a license, the user receives a regular key for a year and fully uses the tool (he does not need to think about any clicks). If you refuse to use, everything is also clear.

But the extension of the mode in the PVS-Studio 4.54 version is implemented as follows. After the end of the clicks, the user sends us an e-mail with the following information: name, company, reason for extending the trial mode. And we give him a key for another week. That is, there is a certain amount of manual work on our part.

In the next version after 4.54 we will redo it. There will be an automatic form in the program to indicate this information, and after sending it, the user will also receive, for example, 500 clicks. The trial mode will be renewed once.

If the user does not want to extend the trial, then he will have the following restrictions:

1. When checking new projects, the names of files with errors will not be displayed. Instead, there will be the phrase "TRIAL RESTRICTION".
2. If the user opens a previously saved log with errors found, then the transition to the click code will not work for him.

Of course, the user, even with 0 clicks, can open a previously saved report and manually perform navigation — open the file, go to the corresponding line in it. This can be done. But it must be understood that static analysis is a tool that, above all, saves time (due to early detection of errors in programs before release, not after). If the time of the potential user is cheap or free so that he is ready to do the navigation manually, then static analysis is not for him and he is not our client anyway.

findings

We hope that the new trial model will eventually allow us to increase sales. Well, what you have to do now is download PVS-Studio and try our idea with clicks on yourself.