Choosing and changing the model of trial mode is one of the most relevant and widely discussed tasks for many software developers. It is easy to make a model for some programs and difficult for others. And some people are haunted by the question: "Have we made everything right?" The task of choosing a trial-model is relevant to us, PVS-Studio developers, as well. We decided to share some of our ideas regarding this subject and tell you about a new alternative we have invented. We hope that our arguments and some ideas will be helpful to other developers too. Introduction The try-before-buy model (or shareware) long ago became a classic one in contemporary business of software selling. I sincerely envy those who develop free and/or open-source software. They are sort of free from the necessity to show all the features of their software to potential customers and motivate them to buy it at the same time. They have to promote their programs, of course, and plenty of Google Chrome or Mozilla Firefox advertisement confirms that idea. However, there is a different situation there, so I won't dwell upon it. So, what do we have? A static code analyzer - a tool that detects errors in programs like compiler does through its diagnostic messages. We need to sell this tool to a user. Standard approach to selling static code analyzers On websites of the industry leaders (Coverity, Klocwork, Parasoft), you can always easily find the button "Free Trial" which, however, has an inquiry form behind it: they want to know who you are, where you are from and why you are here. It is done for the sales manager in his suit to start his work, i.e. hunt, as soon as possible. What the user is concerned, he/she both may be given the trial version or not. Why? Well, because there is a scheme in tough companies they try to follow: when they deal with a worthy customer, they send a helicopter to him/her with special forces consisting of: the sales manager, a technical crew to deploy complex environment of the analyzer and launch it on the customer's project, and a person with a ready tongue to perform presentation on errors found in the potential customer's code. After that the customer either says: "Yes, we buy this product for many ten-hundred thousand dollars per year" or "Thank you, we are not impressed". What for do they need a visit to a customer, infrastructure deployment at his/her side and presentation on detected errors? They need it because ANY static code analyzer produces false positives. And if a user sees the first ten messages which are not errors, he/she might say about the 11th that it is not an error (even if it is). Just because of inattention. Of course, every reader will argument: "I'm not that way!". Alas, people are all that way and there's nothing to do with that. That is why it's better when much more skilled people look through the code of their potential customer, find errors and perform a presentation. Then the potential customer is most likely to become a real one. These are not only thoughts of mine. The same ideas can be found in the article A Few Billion Lines of Code Later - Using Static Analysis to Find Bugs in the Real World which I recommend to read those of you interested in static analysis. What did we have in PVS-Studio earlier We, PVS-Studio developers, are a small startup and we cannot afford sending special forces for now as described in the previous section. But we try to turn our disadvantages into advantages. That is why you can download the trial version of our tool from our website without any registration and waiting for the sales manager to approve your download request. Our potential users like it VERY much. What was "trial" about our tool was actually that it found all the errors but did not show location of some of them. We have lived for a long time with this trial mode, and there have appeared many reasons for us to feel dissatisfied with it: It often happened that interesting errors were hidden, while uninteresting (false reports, to put it simply) were shown to the user who had an impression that the tool is bad. Users do not always understand that the profit from using static analysis is revealed when it is used regularly. It is not enough to "run" the tool just once, fix those errors that were shown in the trial mode and feel content with it. It is important to launch it regularly to find errors just brought into the code as soon as possible. Finally, it is very difficult to show advantages of our very cool capability called Incremental Analysis in such a trial mode. Incremental Analysis is a mode when the analyzer is launched automatically after compilation and checks only those files that were changed. Thus, you see only messages relevant to your current changes instead of a heap of messages regarding the whole project. When you edit two or three files and recompile them, and the analyzer tells you about two errors but shows only one, it doesn't convince you that this capability is cool. Besides, we never knew who potential users of our product were because we don't have any registration and other similar forms on our website. Proceeding from these disadvantages, we decided to change our trial model keeping the advantages of the previous one in the form of easy download. My dream ideal trial I will digress from static analyzers a bit here and tell you about two trial models I am delighted with. [strong]CAD-systems[/strong] First of all, I envy CAD-system developers who often have the following trial model: all the software capabilities are available to user all the time without time limitations. The only functionality limitation is... you cannot save the model you have designed. Without this function you cannot use the tool but can evaluate all the program's capabilities. Super, it's just a dream. Unfortunately, it doesn't suit static analysis because even though you can save a report on detected errors, it's not such a crucial thing as in CAD-systems. [strong]Games like World of Warcraft[/strong] Let me tell you right away that I have never played World of Warcraft and other similar games, but as far as I know, they have the following trial model: a user can start playing free, develop his/her character up to some level and only then he/she has to pay to continue the game. This is another ideal scheme, since no one will refuse to continue on reaching the 15th level. Although release of the humorous plugin Visual Studio Achievements Extension to develop Visual Studio developers made this development relevant to programmers as well, we cannot adapt it to our tool in any way. What we have finally done in PVS-Studio We have invented a concept of "clicks" - passing to the source code containing errors through clicking in the message list. Having downloaded PVS-Studio without any registration, a potential user gets a full-blown version of the code analyzer. They can use it to check any projects as many times as needed. They get the whole message list. But they have a limited number of clicks (transfers to code). For example, it can be 100. But the number is not crucial and perhaps we will change it. Thus, a user can look through and pass to 100 diagnostics. No limitations, mind it. If the user has exhausted the number of clicks, there is one of the following decisions for him/her to make: purchase a license; refuse using the tool if he/she doesn't like it; ask us to prolong the trial mode and provide personal information to us so that we can communicate with this user further via e-mail. When purchasing a license, the user gets a usual registration key for one year and can use the tool at full extent (no clicks to worry about). When user refuses to use the tool, everything is clear too. But what prolongation of the trial mode is concerned, it is implemented in PVS-Studio 4.54 version in the following way. When the number of clicks is exhausted by user, he/she sends us an e-mail with the following information: name, company, reason for prolonging the trial mode. And we give him/her a key for one more week. That is, there is some amount of manual work on our side. We will change it in the next version after 4.54. The program will have an automatic form to fill in this information and after sending it the user will get more 500 clicks, for instance. The trial mode can be prolonged only once. If the user doesn't want to prolong trial, he/she will have the following restrictions: When checking new projects no names of files containing errors will be shown. Instead, there will be the phrase "TRIAL RESTRICTION". If user opens an already saved log with found errors, transfer to the code by click won't work. Of course, even when user has 0 clicks, he/she can open a preliminarily saved report and perform navigation manually, i.e. open a file and go to the corresponding line there. You can do it. But you should understand that static analysis is a tool that, first of all, allows you to save time (due to early detection of errors in software before its release, not after). But if our potential customer's time is so cheap or even free that he/she settles for manual navigation, static analysis is not for him/her and such a person is not our customer anyway. Conclusions We hope that the new trial model will finally help us enhance sales. And what you should do now is download PVS-Studio and try our idea with clicks yourself.
