- Speed, up to 130,000 insert per second
- Familiarity, it support standard SQL, no weird dialects
- Simplicity, it is very easy to operate and to use with binding for any language.
RediSQL finally reached version 1.0.0.
The release does not contains new code, however it is a major shift in our strategy.
We maturate the idea that all the code should be accessible to all our users, even the not-paying one.
This has two main benefits from our perspective:
- It simplify the repository itself and its management.
- More features are tested in the wild giving us more confidence in the code and a better product for everybody.
Of course this benefits also the users, especially the not-paying one since now they can use the PRO features as well.
However we believe that is not enough to just ask for money and donation and that, in order to create a sustainable business — hence a sustainable product — we must sell something.
We looked for something that would not bother very small business or hobbyist users while creating an incentive for medium and large enterprise to pay us for a enhancement.
We set to force telemetrics on the free version of RediSQL while disable telemetrics altogether in the PRO version.
Telemetrics to an outside server
The technical details of telemetrics in RediSQL are already explained in a different post.
In a nutshell, RediSQL collect not sensible data and send them to our servers for analysis. If RediSQL is not able to reach our servers for long enough it shut itself down.
Of course there are a lot of redundancies strategies in place, moreover generous grace periods are enables, the technical post explain the details of how we are doing our best to avoid shutting down users that have connectivity issues and to avoid that problems on our side impact our users.
Rational behind telementrics
The main idea behind forced telemetrics is that small users won’t be bothered by them too much. Moreover they usually have the resource, knowledge and will to set up their own firewall and invest time instead of money.
All the other users can instead use the PRO version, the PRO version does not requires any connectivity to our servers, all the telemetrics part is simply not compiled into the code.
We hope to have strike a good balance with this new policy.
For a company is a bargain to just paid to don’t have one more thing to keep track of.
For small users we allow them to use all the PRO features of RediSQL while just requiring a little more time and attention, of course small users can purchase the PRO version as well.
In order to implement this strategy we had to deviate a little bit from the classical Open Source license.
Indeed RediSQL from version 1.0.0 onward will be released on a custom license derived from the MIT license.
The “RediSQL License” add one clause to the MIT license that simply requires that you leave the telemetrics alone.
Hence you are allow to modify everything in the code and compile it in whichever way you like, as long as you don’t impaired the telemetrics. Hence you cannot remove the telemetrics from the code nor compile the telemetrics away nor impaired it in any way.
Only entities that purchased the PRO version will receive a bare MIT or BSD license that will allow them to remove the telemetrics.
Strictly speaking the “RediSQL License” is not “Open Source” but we believe it is enough for all practical learning and experimental purposes.
Moreover it allow business to explore the code, being sure of the implementation and provide patches and bug fixes while protecting our income.
Why no a different model
We decide to move away from the old model of selling two version with different features because it was complicating the codebase without clear benefits.
Moreover, only a small fraction of the user had a chance to use the PRO features and, despite our tests, we couldn’t be extremely confident that everything was correct, more eyes looking for bugs is always a good thing.
Another strategy could have been to release RediSQL as GPL and sell more business friendly license to big costumers.
While this is a great strategy we are afraid it won’t work in our specific case, most of our costumers are relatively small companies and, moreover, we don’t have the bandwidth to follow the time-frames of enterprise business cycles.
We are excited to try this new strategy and at the same time we are a little scared. Indeed we are not aware of any (successfull) product that tried a similar approach.
However this new approach will align our incentives with the one of our users, we all want a better product with better features open for as many people as possible.
We will not be force anymore to think on what new features should be released as open source and which one should be closed sourced.
Please, feel free to let us know your feedback on the comment below.