Pricing - summary
Oren Eini (Ayende Rahien)
Matt Johnson
I'm developing a product that will be sold to others. If I go with RavenDB, then it seems my choices are:
A) Go with the embedded product for the OEM license.
B) Require my customers to purchase their own server license.
There is no option to distribute the server edition? Maybe through a reseller or ISV program?
Also - Let's say I have two people developing the product today, so I buy two developer oem licenses and start selling my product. Next month I hire another developer to help out. I have to go back and buy more licences? What if he's only there for a short-term contract?
I do like the per-developer model in that larger software houses pay more for the product than smaller ones, but it needs to be qualified in some way. What type of developers do I count? Any working on my product that uses raven? Or just those working on the raven-related pieces? Does my build server need it's own license?
Some of these things will have to be flushed out before we can make a decision about using Raven or not. It's not really a matter of what the price is (within reason) - it's more about the licensing model.
Keep up the great work!
Thanks,
Matt
Oren Eini (Ayende Rahien)
njy
On a related note, may i give you guys a hint on the general issue of
"pricing/licensing"?
Looking at the vfx field (yep: cg explosions, cg humans, cg starships,
that sort of stuff) back some years ago there was this growing trend
for basically all of the 3d software to have divverent version (basic,
pro, banana... you get the point) just like microsoft office basic,
home, deluxe, super duper and whatnot.
On top of that, since to render projects bigger than a flea you would
need some render slaves to crunch frames over frames of your precious
animation, you would have been forced having to pay for some render
nodes, and each pc that you would like to use as a render node needed
it's own license. Then they changed to a license for each cpu, then
for each core. Oh, but there were issues about logical cores vs
physical cores and all of that stuff.
We are talking about licenses of, like, 10.000 $ for each main
license, plus additional licenses and dollars for each render slave.
Oh, and some of those software were available on multiple platforms,
linux, mac and win. And each of them should have a different license.
Right or not that it was, that was the scenario, and users were
stressed out by that situation.
Then, one day in 2004, some very talented and experienced guys left
Newtek (makers of the old and famous Lightwave 3d) and founded a new
company - called Luxology - and released this very very new and
radically different 3d software: it was called "modo".
Everything felt fresh and new, because there was this new software,
with new concepts, being incredibly cool, and was very well written,
enormously innovative and oh boy, it was *fast*.
Oh, and of top of that, they even made a big jump on the pricing/
licensing story: they had only 1 version of the software, with
everything in it. They have only 1 price: 899 $ (if i remember
correctly the price back then), and they give you this "modo" software
in 2 different versions (mac and pc), at the same time! Because, you
know, they say "you can use it on both the PC and Mac as we license
the software to you, not your computer". And the license would last
forever, it was not time-bombed. When a next major release woul came
out, there was a classic full-price/upgrade difference, but that was
all. Oh, and you could use an unlimited number of render nodes, all
for 899 $.
So it was new, fresh and easy... even on pricing/licensing!
Today, some years later, they got a big slice of market share, they
are still alive, they are loved by their customers and evangelize for
free by their users (Apple anyone?). The pricing/licensing strategy
worked out great, and everybody is happy now.
Now, jumping back to you guys: i'm not saying your strategy is wrong,
i'm not saying 4 versions with different usage restictions for cores/
cpus/ram/etc is plain wrong or something, i'm not saying the price is
too low or too high. Obviously there are differences, for example your
sw is OSS, their is not, and so on.
What i'm saying is i admire RavenDB and yo guys, and i would like you
to succeed, and the story up here strikes a lot of similarities to
your story and the story of ravendb: new concepts, a fresh approach,
users loving your work, using it happily and so on.
And since their way of licensing worked out great and gave a relief to
their users from the pain of "software version X pro, 2 virtual cores,
but not more than XYZ MB of ram but..." and it worked uot, i'm just
here asking you to take a look at their path to maybe find some
analogies or ideas, because btw in the economics of the software that
should be considered part of the marketing strategy. And for them, it
worked very well!
Anyway here is the current licensing page for modo, take a look:
http://www.luxology.com/store/modo/index.aspx (now they have 4
version: individual, floating, bulk and educational, plus a couple o
very minor variations).
And here for an intro to how cool is for their uses this licensing
model http://blog.irisproservices.com/2009/01/02/network-rendering-in-modo/
.
I hope this may give you some ideas, thanks for your time.
njy
On Feb 29, 12:04 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:
> Hi guys,
> This is intended as a summary of the previous thread (http://groups.google.com/group/ravendb/browse_thread/thread/f737cb1fe...
> )
Tobi
OEM: Good to see the renewal price beeing lower than the full price again.
Although I'm glad to already have an OEM license for the old price. The
new one still feels (!) a little bit high. For 1599/999 it would be the
most expensive thing in my toolbox. As a "long-time RavenDB user", I know
that it's worth the money but as a new user, 1599 makes the decision a
little bit harder.
To Matt's question about the per/developer licenses: There's no sane way
to technically ensure/verify this. Oren simply has to trust it's
customers. Personally, if I would e.g. hire someone for a month to help me
out on the GUI, I wouldn't care about buying another RavenDB license. For
a developer that joins the project for a longer term I would.
Maybe it would be a good idea to extend the OEM license to:
1599 for the first developer and 999 for each additional developer,
renewal for 999 per developer per year?
Basic/Standard/Enterprise: These mainly target the Web-App business. I
must say, that I don't have very much experience in this area. Whenever I
need to do a tiny Web-App, I usually build this with Rails and put it on a
Linux-box. Anyways: The licensing model is somehow "complicated", which
kinda makes this contrary to what RavenDB technically stands for. Limiting
the database to only use some cores/threads/memory/disk-space seems kinda
odd to me. Why not just limit the number of docs and the use of things
like sharding or replication?
Besides all this, one thing that maybe isn't really promoted enough:
Whatever license you buy - you get RavenDB with the full source code!
Even better: You have to pay NOTHING to get RavenDB without any
restriction and with the full source code, because it's Open Source!
You can play around with RavenDB, build a test spike, create a demo app
for your boss without spending a single dime!
Tobias
Mauro Servienti
Kudos to you for the deep, accurate and interesting, really interesting analysis.
.m
njy
http://www.Taglocity.com Tags: RavenDB
Phil Jones
thoughts:
"RavenDB Basic - monthly subscription only (5$ - 512 MB db size limit,
5
databases limit. 10$ - 1GB db size limit, 10 databases limit). A
single
indexing thread, 2 GB memory limit."
with is Escape Trips (the one you blogged about). Their database is
only ~300MB in size and I currently bought the $25 subscription. I
could save $20 a month. This works good for super small clients, as
the VPS for Escape Trips is: 2GB RAM, 1 virtual core. Although the one
indexing thread is a little bit disappointing.
"RavenDB Standard - what we have with RavenDB right now. 6 CPU + 12 GB
limit.
999$ for a one time payment - 18 months upgrade protection.
399$ for a yearly subscription - as long as you have a current
subscription, you can use the software and get free upgrades.
39$ for a monthly subscription"
looking at moving from SQL Server Express to Standard so the costs are
good in comparison.
P.s. I did mention to Itamar that RavenHQ should have a $5 per month
package as bronze and the free 20mb should just be called free.
Oren Eini (Ayende Rahien)
Oren Eini (Ayende Rahien)
Tobi
> Thoughts about that? Maybe we can do two levels of OEM here.
> One that is cheap around the embedded only mode.
> One that is more expensive around the server option as well.
OEM/embedded + OEM/server - Sounds good to me. Maybe with an option to
extend/upgrade from embedded to server. Right now I'm happy with the
embedded RavenDB, but I can imagine scenarios where a central RavenDB
server + a bunch of rich client apps would make sense. Even an
OEM/embedded for a local database + a central database for stock tracking,
managing discount coupons and so on would be a possible scenario.
Another thing I mentioned previously: Even with OEM/embedded I would like
to be able to have remote access via Raven.Studio. This can be really
helpful for maintenance.
And another question: Right now my application is purely standalone. In
the future I need to somehow connect these applications. (e.g. starting a
sale on one cash register, closing it on another). One way to do this
might be master/master replication. Would this still be covered by the
OEM/embedded license?
Tobias
Dody Gunawinata
- Open Source Project of any type: Free
- Development Work: Free
- Hobby Close Source Project: RavenDB Basic, RavenDB Standard
- One off Small/Commercial Application/Website: RavenDB Basic
- Enterprise Market ISV (Server App): OEM/Server, OEM/Embedded
- Consumer ISV: OEM/Embedded
- SaaS ISV: RavenDB Enterprise, Scale Out Option
- IT Department: RavenDB Standard, RavenDB Enterprise, Scale Out Option
Oren Eini (Ayende Rahien)
On 29.02.2012 11:03, Oren Eini (Ayende Rahien) wrote:OEM/embedded + OEM/server - Sounds good to me. Maybe with an option to
> Thoughts about that? Maybe we can do two levels of OEM here.
> One that is cheap around the embedded only mode.
> One that is more expensive around the server option as well.
extend/upgrade from embedded to server. Right now I'm happy with the
embedded RavenDB, but I can imagine scenarios where a central RavenDB
server + a bunch of rich client apps would make sense. Even an
OEM/embedded for a local database + a central database for stock tracking,
managing discount coupons and so on would be a possible scenario.
Another thing I mentioned previously: Even with OEM/embedded I would like
to be able to have remote access via Raven.Studio. This can be really
helpful for maintenance.
And another question: Right now my application is purely standalone. In
the future I need to somehow connect these applications. (e.g. starting a
sale on one cash register, closing it on another). One way to do this
might be master/master replication. Would this still be covered by the
OEM/embedded license?
Tobias
Oren Eini (Ayende Rahien)
Chris Marisic
What type of developers do I count? Any working on my product that uses raven? Or just those working on the raven-related pieces? Does my build server need it's own license?
It would be like a car maker selling a car that instead of you owning the car, you had to license each driver of the car, but not only the drivers but every single passenger that could ever get in the car which is just absurd. Licensing drivers of a vehicle = ok, licensing passengers of a vehicle = no way.
Chris Marisic
On Wednesday, February 29, 2012 4:53:25 AM UTC-5, Phil Jones wrote:
Although the one indexing thread is a little bit disappointing.
One indexing thread does seem to be a very arbitrary limitation, if you really want the threading to be a higher tier feature, i would think you'd probably want to cover atleast 2 or 4 threads. RavenDB Basic shouldn't have performance outright crippled. Limiting the size the database and the consumption of resources is all very standard for database pricing methods but I've never seen anyone ever majorly reduce the performance intentionally before.
Sean Kearon
- Development Work: Free
Oren Eini (Ayende Rahien)
Sean Kearon
Sean Kearon
Thoughts about that? Maybe we can do two levels of OEM here.One that is cheap around the embedded only mode.One that is more expensive around the server option as well.
njy
On Wednesday, February 29, 2012 10:58:39 AM UTC+1, Oren Eini wrote:
Njy,A simplified licensing story makes my life simple as well, trust me on that.I would much rather be focused on optimizing the indexing code than thinking about pricing strategies.That said, there is a reason why we do those licensing break downs. We are trying to offer the best balance between feature and price for people.
On Wed, Feb 29, 2012 at 4:43 AM, njy
Thanks for the update Oren, appreciated.
Beyers
On Feb 29, 3:51 pm, Chris Marisic <ch...@marisic.com> wrote:
> On Wednesday, February 29, 2012 4:53:25 AM UTC-5, Phil Jones wrote:
>
> > Although the one indexing thread is a little bit disappointing.
>
> really* want the threading to be a higher tier feature, i would think
> shouldn't have performance outright crippled. Limiting the size the
> database and the consumption of resources is all very standard for database
> pricing methods but I've never seen anyone ever majorly reduce the
> performance intentionally before.
with users thinking RavenDB performance is slow in general and have
them move to something else.
Beyers
Matt Johnson
I agree that these kinds of licenses can be difficult or impossible to enforce, but I think ultimately they work better than per-instance licensing. Especially if you are a dependency in someone else’s project.
In our case, we are an ISV that is doing both traditional licensed deployments and SaaS hosted models for our product. We have traditionally used SQL Server, which meant that for hosted we would buy our own servers, and for licensed we would require the customer to have a SQL Server. I think you can do that for SQL, because many people already have SQL Server licensing agreements with Microsoft, and smaller customers always have the option of SQL Express.
If we were to do the same thing with Raven, our customers wouldn’t have the first clue about where to begin. We would have to provide them their Raven license. If we had to tell them to go purchase their own Raven license, it would make selling the product very difficult. Now, if we have royalty free distribution for the embedded product, then it’s not an issue for smaller customers. But it would be equally important to be able to distribute Raven with our software even with the server edition for larger customers. Perhaps the license for that is more expensive on our part, or perhaps it’s not “royalty-free”, but we increase the cost of our software by some amount to include the cost of the Raven license. Either would be acceptable.
The big question is how much performance can we expect from the embedded version vs. the server version? Where do we draw the line from a licensing standpoint? It would be much easier if this was just a technical question of whether or not you wanted the http layer or the direct connection. The licensing issue makes it more complicated.
The absolute best situation from our perspective would be to have one larger annual fee for the ability to deliver either embedded or full server with our solution, royalty-free. We would love to pay this fee per-retail-product, rather than per-developer. Perhaps we could key the raven instance so that it only worked with our software. That would prevent the end-user from getting a completely free license of Raven. Perhaps this lines up with your business model, perhaps not. We would be willing some level of compromise.
That would be for the licensed, deployed version of our software. For our SaaS model, we’d pay separately per instance for our own instances that we use to host the SaaS version.
Oren Eini (Ayende Rahien)
Matt Johnson
- Choice of embedded or server, mix and match as needed.
- Royalty-free distribution to as few or many end-users as we want.
- No limits in terms of cpu, memory, storage.
- Limited to running with just our product.
- Separate fee paid for each distinct product line (not for subvariants or editions of the same product)
Matt Johnson
Phillip Haydon
Roja
part of a new project. I think that it would be very easy at this
point for Raven to move to a complex licence model but I think that it
would be a massive shame. Raven is aimed at switched on developers &
companies; improved productivity, logical interface, nice
functionality not really enterprise purchasing departments. It's also
meant to be "web scale" and my feeling is that the pricing should
reflect this intention. Develop for free, start cheap, payback on
success. Therefore couldn't we go with something nice, simple and well
defined? i.e. an algorithm?
Here is my proposal (based around and about the price-points you
already intended):
Price is based on "slices" where each slice costs $5 per month, for
which you get the following:
Storage = (#slices^2) GB
Memory = #slices GB
Cores = roundUpNextEven(#slices / 2)
Examples:
1: 2GB, 1GB, 2Cores, $5
2: 4GB, 2GB, 2Cores, $10
5: 32GB, 5GB, 4Cores, $25
10: 1024GB, 10GB, 6Cores, $50
This would remove the need to have "crippled" versions and provides a
nice smooth growth plan for users. I would also allow the allocations
to be split across multiple machines if desired which would promote
making use of sharding & replication.
Roja
On Feb 28, 11:04 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
Chris Marisic
On Thursday, March 1, 2012 4:36:20 PM UTC-5, Oren Eini wrote:
With regards to per developer licenses. The way it currently works in my head is that if you have a team of people working on a project using RavenDB, everyone working on the code that runs in the same process as the RavenDB code will need a license.
That's such a silly an arbitrary delimitation. What about UX developers that write pure html/css? They would need licensed under that definition. This restriction is also meaningless and arbitrary, all it requires to overcome this is to create the database sit behind a web service and make the client application call the web service. Microsoft even has explicit provisions in the sql server licensing about this, they refer to it as multicasting. You can't buy 1 CAL for sql server then put a web service on top of it and then use the webservice to let infinite users access it. With this being in regards to licensing model per developer, you don't have way to put a multicasting limiter (that wouldn't be absurdly prohibitive).
The only proper requirement is do you touch EVER touch one or more of the following: IDocumentSession, AbstractIndexCreation, Bundles/Triggers, Management studio, possibly some other facets etc. If they're not touching those, they're not dealing with RavenDB.
Oren Eini (Ayende Rahien)
Oren Eini (Ayende Rahien)
On Thursday, March 1, 2012 4:36:20 PM UTC-5, Oren Eini wrote:
With regards to per developer licenses. The way it currently works in my head is that if you have a team of people working on a project using RavenDB, everyone working on the code that runs in the same process as the RavenDB code will need a license.
That's such a silly an arbitrary delimitation. What about UX developers that write pure html/css? They would need licensed under that definition. This restriction is also meaningless and arbitrary, all it requires to overcome this is to create the database sit behind a web service and make the client application call the web service. Microsoft even has explicit provisions in the sql server licensing about this, they refer to it as multicasting.
You can't buy 1 CAL for sql server then put a web service on top of it and then use the webservice to let infinite users access it. With this being in regards to licensing model per developer, you don't have way to put a multicasting limiter (that wouldn't be absurdly prohibitive).
The only proper requirement is do you touch EVER touch one or more of the following: IDocumentSession, AbstractIndexCreation, Bundles/Triggers, Management studio, possibly some other facets etc. If they're not touching those, they're not dealing with RavenDB.
Matt
On Tuesday, February 28, 2012 11:04:49 PM UTC, Oren Eini wrote:
Hi guys,This is intended as a summary of the previous thread (http://groups.google.com/group/ravendb/browse_thread/thread/f737cb1fe1420dc6/5df1d12137ab4186?)
Oren Eini (Ayende Rahien)
Paul Stovell
Oren Eini (Ayende Rahien)
Paul Stovell
Chris Marisic
On Monday, April 23, 2012 1:41:03 PM UTC-4, Paul Stovell wrote:
What if I buy two Embedded licenses - can I then use two processes? :) Why does the Embedded version even have UseEmbeddedHttpServer if nothing can use it?
I'm pretty sure UseEmbeddedHttpServer is only so you can connect studio to an Embeddedstore.
Oren Eini (Ayende Rahien)
What if I buy two Embedded licenses - can I then use two processes? :) Why does the Embedded version even have UseEmbeddedHttpServer if nothing can use it?
For the sake of keeping my product install ultra simple I'd really like to stick to embedded at first. It looks like I am now faced with hosting ASP.NET within my Windows Service, or modifying my installer to auto-install RavenDB Server, just because of a licensing gap...Also, any idea what the ballpark price for RavenDB Server will be? $1,599, $15,999?
