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

    New trial mode for PVS-Studio

    For many software developers, selecting and changing a trial mode model is one of the most anxious and discussed tasks. For some programs it’s easier to come up with a model, for others it’s difficult. And for some people the question doesn’t leave: “Have we done everything right?”. The urgent task of choosing a trial model is also for us, the developers of PVS-Studio. We decided to share some related thoughts and talk about what new option we came up with. We hope that our reasoning and some thoughts will be useful to other developers.



    Introduction


    The try-before-buy (or otherwise shareware) model has long become a classic in the modern software business. 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 should promote their programs and the abundance of Google Chrome and Mozilla Firefox advertising is proof of this. Nevertheless, the situation there is different and I do not consider it.

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

    Standard Approach for Selling Static Code Analyzers


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

    Why go to the client, deploy his infrastructure and present on the errors found? This is because ANY static code analyzer gives false positives. And if the user sees the first ten viewed messages as false positives, then on the 11th message (even if this is a real mistake) he can say: “This is not an error”. Just because it’s not attentive. Of course, the reader will object: “I am not like that!” Alas, people are arranged 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 customer will become real. And these are not only my thoughts. This is stated in the article A Few Billion Lines of Code Later - Using Static Analysis to Find Bugs in the Real Worldwhich I highly recommend reading to those interested in static analysis.

    As we have implemented in PVS-Studio 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 weaknesses into advantages. Therefore, on our website you can download a trial version without any registration and waiting until the sales manager approves the download request. This is VERY liked by our potential users. Actually, the “triality” of the work was that the analyzer found all the errors in the code, but for some it did not indicate where they were located. With this trial mode, we lived for quite some time. And claims to him have accumulated:
    1. It often turned out that interesting errors were hidden, and uninteresting (in other words, false positives), on the contrary, were shown to the user. It seemed that the tool is bad.
    2. Users do not always realize that the benefits of static analysis are manifested with regular use. It is not enough to “run away” the tool once, to correct those errors that were shown in trial mode, and calm down on this. It is important to run it regularly to find the errors that have just been entered into the code as quickly as possible.
    3. Finally, in such a trial mode, it is very difficult to show the benefits of our very cool Incremental Analysis feature. This is the operating mode 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 talks about two errors, but does not show one of them, it is somehow not convincing that this is a cool feature.
    4. In addition, we did not know who the potential users of our product are, since nowhere on the site do we have registration and other similar forms.

    Based on these shortcomings, it was decided to change the trial model, preserving the dignity of the existing version in the form of ease of download.

    The perfect trial of my dreams


    Here, I digress a bit from static analyzers and talk about two trial models, which I love.

    CAD systems


    First of all, I envy CAD developers, who often have trial looks like this. The user is available 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 real use of the tool is impossible, but a potential user can evaluate all the features of the program. Super, just a dream.

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

    Games like World of Warcraft


    I must say that I have never played World of Warcraft and similar games, but as far as I know, trial works there like that. The user can start playing for free, upgrade his character to a certain level, and only then he needs to pay for the continuation. This is another ideal scheme, since no one, having reached the 15th level, can refuse to continue.

    Although with the release of the humorous plug-in Visual Studio Achievements Extension for pumping developers for Visual Studio, pumping became relevant for programmers as well, but we still can’t adapt it.

    What did we finally do in PVS-Studio


    We decided to use the concept of “clicks” - this is a transition to the source code with an error by clicking on the message list. Having downloaded PVS-Studio without any registration, a potential user receives a fully functional version of the code analyzer. He can check her any projects any number of times. He receives a complete list of messages. But he has only some limited number of clicks (jumps to the code). For example, 100. But the number is not important and maybe we will change it. Thus, the user can look and go to 100 diagnostics. I repeat, without any restrictions.

    If the user has consumed these clicks, then he must make 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 him 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, too, is clear.

    But the extension of the regime in our version PVS-Studio 4.54 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 the extension of the trial mode. And we give him the 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 this. There will be an automatic form in the program for indicating this information, and after sending it, the user will receive, for example, another 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, file names with errors will not be displayed. Instead, there will be the phrase “TRIAL RESTRICTION”.
    2. If the user opens a previously saved log with the errors found, then the transition to the code by click will not work for him.

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

    findings


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

    Also popular now: