Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
Webinar: Evaluation - 05.12
If you happen to visit the PVS-Studio order page, you'll notice that the prices are not displayed anymore. Instead of offering a fixed price, we suggest that you contact us to discuss it individually. It's just an experiment for now whose outcome we cannot predict. Having removed the prices, we don't mean that they will rise. Just on the contrary, we want to offer PVS-Studio to small teams at lower prices. If you want to find out what changes our pricing policy has undergone and why we consider trying the new selling scheme, you are welcome to read further. I'm sure those who don't only develop products, but also have to sell them will find something interesting too.
This article is outdated and does not reflect the current pricing of PVS-Studio. Please refer to the purchase page to get the latest pricing information.
It all started when we (Andrey Karpov and Evgeniy Ryzhkov) wanted to create a couple of small applications in the shareware fashion. Our minds exalted by motivational books were craving for action. We had a number of diverse ideas, but for a long time we didn't manage to invent anything concrete. We knew we didn't want to make another clone of some software. Had iPads and other tablets been already popular at the time, we would have inevitably chosen this area. Also, we don't know for sure how an alternative history would have evolved with us trying to create games or something, and we will never know. But at that moment, we had hard time trying to figure out anything worthy. The iXxx industry didn't exist yet; web design didn't attract us.
Finally an idea occurred to us which seemed just wonderful. We decided to develop a plain code analyzer that would help programmers port their applications to 64-bit Windows platforms. It was quite a topical issue then. Before that, at our previous job, we had faced a very complicated problem with catching big bugs in applications employing more than 4 Gbytes of RAM. There were no utilities to deal with them - at all.
We were sure that such a tool could not but become successful. There were rumors at the time that one - two at most - generation later we would have 64-bit Windows versions only. That would trigger a sharp demand rise, and we would be getting much profit during this period of mass migration. And then we'd pass on to other projects.
But man proposes, God Microsoft disposes. Migration from Win32 to Win64 has stretched to many years, and Win32 doesn't seem to stop getting support in the nearest future. There was no expected burst of demand for tools like ours. Programmers have always shown an interest toward them, but it is very feeble. So, our first product Viva64 designed to detect 64-bit errors never brought us any significant profit. Rather, it evaluated to 0 in the end, but in the beginning we even had to support our living through outsourcing.
The next two paths we took appeared even less successful. Those were an analyzer for OpenMP-based parallel software and the VivaCore code parsing library. In 2008-2009, there was much talking about the multi-core architecture. We are trustful by nature, so we believed that no one would do without concurrency very soon and OpenMP would be the queen of concurrency. And that didn't happen either.
We planned to use the VivaCore library as a basis to develop specialized custom-made tools, but there was not one worthy deal. So, we gradually dropped that. Well, there really were some attempts of cooperation with certain people, but they evolved in the following manner. "Please make this specialized code analyzer and give it to us together with the source code. We'll pay you $2000, or even $3000". It was no fun at all.
The first success came only when the PVS-Studio tool appeared. Initially it included the modules for 64-bit software analysis (Viva64) and OpenMP software analysis (VivaMP). To promote it and just out of despair we started to gradually develop a general analysis module. This part of the analyzer was at first meant to be free and served just to attract programmers' attention to the paid modules (Viva64/VivaMP). We didn't believe that in a few years to come we would be able to compete with a slightest success with Gimpel PC-Lint, Coverity and other, bigger and smaller, sharks of the general analysis industry.
Then, one fine day, we got a letter from a man. He asked if he needed to buy PVS-Studio to be able to use the general analysis module. We answered, "No, it's free. But we'll be glad if you buy Viva64/VivaMP, and we will provide support for you". The man said, "Oh, no, thank you. Since it's free, I don't need anything else. Thank you for a nice free product. If I had to buy a general analyzer, I'd buy yours. I like it very much, but I don't need Viva64/VivaMP".
And it struck us: that's it! People are interested in our product. And the first PVS-Studio 4.00 release included the general analyzer as a paid tool. Since then most of our customers have been attracted to us by that very general analyzer. It also appeared much simpler to promote: the demo samples of bugs it can detect are plain and clear.
All this stuff is not the main subject of the article, of course, but I hope you enjoyed reading it. Now let's speak about the prices themselves.
As I've already said, we initially wanted to develop a plain tool for mass usage. The initial price for Viva64 was about $400. Then a long-term revision of prices took place:
Looks like a series of powers of two, doesn't it? These revisions were made because the tool had failed to become widely popular. Moreover, again and again we got evidence that large companies didn't care much about the prices; and it were mainly large companies who had shown interest toward us since the very beginning, not small teams or individual developers. For this very reason we refused the single-user license.
It used to be like this: a large company would contact us and buy a license for one (ONE!) developer. They gave various reasons for doing so. For instance, one of them was:
We have only one developer responsible for monitoring the project. He reviews analysis results once in a day and sends messages to the corresponding programmers through the bug-tracker if he discovers something. It doesn't matter that the team is large. One single-user license, please.
What arguments can be given against such an attitude? After having a conversation with one more customer like that, we just refused single-user licenses at all. Yes, we lost a part of our potential customers represented by small teams, but it still was better than trying to persuade large serious companies not to be greedy. I guess one may find it hard to imagine how it is, looking at it from the side, so here you are a comparison.
Imagine that you install a gas line in a house. It's not expensive because there isn't much gas supplied through one tube into the house. The tenants bake cakes, fry turkeys, and so on. That's alright. And then suddenly one of them deploys a thermal power station instead of a common kitchen oven. But he is not going to pay more, arguing that he needs only one tube. You see, it's the amount of gas he consumes that we should take into account. It's a pity that making a counter for code amount is a complex philosophical task. I'll tell you about it a bit further. So, you can see now why we refused single tubes (single-user licenses, that is) after somebody had installed one more thermal power station. It turns out that selling fewer licenses at higher prices is more profitable. And that's a pity.
The latest prices you could see on our website were as follows:
These licensing and pricing policies are mainly intended to sell the Site License to large companies, of course. And we do; there aren't many sales, but it keeps on going. However, we don't like the established state of things either. It appears that we've lost all the small and medium teams because they cannot afford buying the tool at such prices. Dropping the price back to $500 is naturally not a way out. I won't give now all our arguments and calculations, just take my word for it: we will earn less while we'll have to support more customers. On the other hand, it's no good leaving it all as it is. This is why we have started our experiment.
Setting different prices depending on project sizes seems to be a simple and right solution. I gave you a comparison with gas line installation before. The more gas a tenant consumes, the more he or she has to pay for it. The more code goes through the analyzer, the larger and more serious the project is. The larger the project, the more money it is reasonable to ask for the tool.
The only trouble is how to invent such a counter. It's not clear what and how to count. At first sight it seems quite easy, of course: we could count some project size units and set the price relying on that number. We considered and discussed this solution for one year. But the more we thought, the more complicated it all turned out. There's a whole lot of various subtleties and nuances that turn this simple and clear idea into something obscure and hard to implement. I don't find it easy to explain all our considerations to a potential customer, so I won't go deep into the subject. Here's just a few aspects that will help you understand how complicated the task is.
Many of you will surely want to share some ideas regarding the issues of counting the project size. Please, don't. We have been musing over all this for a long time and failed to work out an appropriate and smart solution. If I don't react to your comments, you might find it rude, but I don't feel like getting involved into lengthy debates. We've already had enough of them. So, just take my word for it. Yes, you can make such a counter. But no, you can't make it simple and smart.
After all, even with such a counter you'll have to trust your customers. So, it's much easier and better not to invent complicated solutions, but talk to people and find out the team size and the amount of tasks they have to deal with. Those who want to cheat will always find a way to do it.
It's logical to set different prices for projects and teams of different sizes. But we decided not to draw a large table with prices for every possible case. Instead, we want to try discussing the business with a potential customer and offer him the best price. Perhaps we'll change the format of the order page in future, but now we just want to try this particular strategy of selling the tool and price coordination.
Having read all that, the readers may reasonably ask, "So what are the prices for PVS-Studio now?" Here's the answer.
I want to point out that our idea is to rely on the project/team size, not the number of the times the tool will be installed. That's why it is the size of the team we mean, not the number of people who will directly run and work with PVS-Studio.
All of you interested are welcome to email us. We are ready to consider various purchase schemes.
The trial model remains the same. The demo version retains the full functionality, and only the number of "clicks" is limited. By the way, PVS-Studio 5.10 is released soon that will be shipped with the first Standalone version. It can check preliminarily generated (by any means) *.i files, which is meant to significantly extend the analyzer's scope of use. The Standalone version also includes an interface to handle the message list and program text. It's for Windows only for now, yet it is still a big step forward.
Yours sincerely, the Unicorn.
0
0
0
0