Introducing RapidMiner 7.2, Free Versions of Server & Radoop, and New Pricing

Dear Julio,

Thanks for taking the time to write such a thoughtful response – I can clearly see your passion and that you are a fan of RapidMiner. Many thanks for that! Let me quickly comment on some of the points you made. I hope that I manage to explain better why we made the changes we made and what those have been based on.

What is the right restriction? Limited features? Rows? No restriction at all?

Let me start on the last idea (which I know you did not say but others actually suggested this): no restriction at all. I got a couple of dozen people reaching out to us or me personally suggesting that we should not have ANY limitation and just ask people to give what they are willing to give. Or charge for services only. This idea has unfortunately a fundamental flaw: we would be out of business within a few months and then the software is gone for all users. This can certainly not be what we as a user community desire (yes, I include myself here). There was actually a time where we have been able to grow with training and support alone but with every new version RapidMiner got more intuitive and better, and we also invested a lot into documentation and freely available educational materials. This business would no longer be sustainable just based on selling this kind of services. So there HAS to be a form of restriction in the software itself. We need to generate license revenues for the 100+ people who develop the RapidMiner platform today.

So what is the right form of restriction?

You would be surprised how many people actually have asked for free connectors to commercial databases in the past 12 months – I would say this was roughly the same amount of people who are now asking for larger or no row limits. But in addition, a lot of people also asked for free versions of Server and even more people for a free version of Radoop. What people often forget is that just because a certain feature is not important to them, it for sure is for others. So there is always somebody who complains that something is missing.

The main problem with this feature-based limitation is that users had no chance to solve their problem at all or make at least a proof of concept if a certain desired feature was missing completely. So they are basically screwed or could never make the case for creating a budget for starting a commercial relationship with RapidMiner. That was not good for them and of course also not good for RapidMiner.

As a consequence, people became VERY creative, e.g. by combining multiple different platforms or coding their way around restrictions in R and Python. This has not been the greatest experience for our users but let’s be honest here, this also is not really helping our commercial conversion rates. In a nutshell, this was certainly not what we have intended with the old model.

Last but not least, a feature-based model is much harder to explain. You might not believe this but our prices are actually extremely competitive if you compare the total cost of ownership to our competitors like SAS or IBM. This is only possible if we save on marketing and sales costs, i.e. by simplifying the packaging and pricing in such a way that our passionate inside sales reps can explain this in a short phone call instead of hour-long meetings. And this directly reflects in lower prices.

Ok, but if a feature-based restriction is not great and no restriction is not an option at all, what else can there be? Entering the row-based limitation!

This way everybody can now use all the features of the complete platform on a meaningful data set size. And all academics and personal learners can even use the complete platform for free on unlimited rows.

How do I know that 10,000 rows are meaningful? Well, guess what, we are a data science company. OF COURSE we have analyzed the data set sizes our users are typically analyzing. I actually even gave a presentation on some of this data at the KDD 2016 conference in San Francisco two days ago. Here is a link (http://www.kdd.org/kdd2016/speakers/view/ingo-mierswa) and I think a video of this will be online soon as well. Anyway, the result has been very interesting: In the first 3 months of product usage, more than 90% of our users analyze data smaller than 10,000. And there is also a journey, i.e. over time the likelihood increases that you analyze larger data sets. This is often the result of going into production with your models or at least into a deeper validation phase. So you are leaving the early prototyping phase at this point. For some this might happen faster than for others but the overall journey is the same for most analysts.

But now I have to ask you: you are a commercial organization going into production with a model built in RapidMiner and you don’t let your supplier participate from this – even at this point? That does not seem to be right to me either…

My last comment on this would be: you can always build a model on 10,000 rows only. It is not that the processes would break (in fact, we made the down-sampling quite comfortable for the user). It is just that the accuracy is typically somewhat lower. So this is good enough at a prototyping phase or for a proof of concept. But of course if you go into production you want your models as good as they can be. But then again my argument from above holds.

Ok, row limits it is. But what is the right price then?

Software pricing is half art and half science. Our product management team has applied both techniques here… They in fact analyzed the data from our own customers, prospects, our competitors, did dozens of interviews with customers and industry analysts and made a recommendation. So I think this is as “science-y” as pricing can be.

But in fact what you are suggesting is not that far from our actual pricing. The smallest server is USD 15k per year and this means you can analyze 3 to 5 million rows with multiple users in parallel (depending on the width of the data sets of course). For 99% of our users this is all the data they have and pretty much equivalent to “unlimited”.

On the “serious premium for commercial connectors”: Yeah, you would think so. In reality though people use R scripting to get around this premium. Damn, our users are too smart 😉

On your segments:

1. Roughly 50% to 60% of our users are academics and personal learners – they fall naturally into the “free” segment thanks to our educational program: https://rapidminer.com/academia/educational-program/. The same is true for all who never reach the limit or don’t care about the limit.
2. Open SW: as I tried to explain, they are actually not willing to pay anything. Those users even would prefer to save a couple of hundred dollars per year and work around the feature limitations with 3rd party software or scripts. I was kind of surprised by this myself but this is what reality is.
3. See comment above on Server and Server pricing. I actually do not think that we are that far away from each other in most realistic scenarios. But also keep in mind that we have seen a lot of users who installed Studio on machines with >256 Gb of memory with 64 cores, i.e. they have been mis-using Studio as Server to avoid to purchase a Server license. Again, I wish things would have been different but I have to deal with realities here.
4. Integration: this is very interesting since we actually did this in the previous model where we had our Deployment Server which came at the highest price point. I must admit that this approach actually failed and this segment at this point is not really existing. For most of our customers, deployment did not mean the integration into other systems but just writing out the results into a database or even Excel files. And if there was integration, it was done by coding anyway. If and when the market around this changes, we will certainly reconsider but at this point this is unfortunately not a large or commercially interesting segment for us.

I shared a lot (but of course still not all) pieces of information we found in the past 12 months and I hope that by doing this you and others better understand why we needed to make changes to the model. In a perfect world, this might not have been necessary but with all the different requirements we came to the conclusion that approach is the best compromise for most parties involved.

If you are in Segment 3 and want to have a commercial discussion: let’s start it and not give up before we actually talked about your specific situation. Often there is a possibility to change configurations in a way still leading to an acceptable deal for both sides.

Many thanks again for your thoughts and passion. I really appreciate this.

Best,
Ingo