[RavenDB] Licensing and pricing
906 views
Skip to first unread message
Ayende Rahien
May 19, 2010, 5:41:59 PM5/19/10
to ravendb
Meta commentary (feel free to skip it to the actual content section):
I have to admit that I had high hopes that the launch event would generate some interest in Raven, but I had no way to foresee the actual reaction. And unfortunately most of that focused on the licensing. While I agree that this is an important issue, I would much rather see a lot more focus on actual product rather than the licensing.
I have been trying to catch up with the flow, but I was teaching for most of the day, so I kept falling behind. Just to give you an idea, my mailbox contains over 250 emails from the last 18 hours about that. I can’t even count the twits. This text is meant to try to bring some order among all those messages.It would also, hopefully, help me explain my thinking and thought process. I know that it is atypical to have a pricing discussion in such a public forum, but I think that this is useful.
I apologize for the length of this message, I didn’t have the time to make it shorter.
Actual content:
When I set out to draft the licensing terms for Raven I had in mind traditional database licensing, which are usually per server. That works, quite nicely, if you have a low number of instances. In the NoSQL environment, that is a problem, because you are expected to run large number of instances, that is a big stumbling block. That is certainly something that I have should have taken into account.
Let us cut to the chase:
I am aware that there are established competitors for Raven out there, most of whom are free for commercial use. I obviously believe that Raven has enough to offer to be worth paying for commercially. Some of the replies that I got back expressed a strong desire for having a free as in beer for commercial use and starting a support & services model to make money on that.
To those people, I can tell you that I am already in the business of providing support & services for a free-as-in-beer product, NHibernate. That gives me a pretty realistic view of the amount of money involved, the amount of effort required and the return on investment. If this was what I wanted, I wouldn’t have gone to all the trouble of developing Raven.
With that said, let us go directly to the details. As Eric mentioned, while Commercial & Enterprise separation make sense for an established product, I am current at the stage where my main concern is gaining acceptance. That was especially apparent with the way just about anyone latched into the pricing of the enterprise edition, without considering the commercial edition.
With that in mind, I think that Raven will have only two modes:
- OSS/AGPLv3
- Commercial
To make things clear, features such as master/master replication, automatic failover, master/slave replication and multi node replication are going to be included in the commercial edition. I had planned to biff up the enterprise version with things like document level security and index replication to RDBMS. I might offer them as separate bundles, licensed commercially independently from RavenDB Core.
As I see it, we have the following personas to consider when we are talking about licensing:
- Commercial – lots of instances – running business critical applications with lots of data on it.
- Commercial – single instance – running business critical applications with modest amount of data on it.
- OEM – want to run potentially hundreds / thousands of raven instances in embedded scenarios.
- Startup – cost sensitive, can probably pay later on.
- OSS – pretty obvious :-)
- Contributor – someone who made a non trivial contribution to Raven in some manner, as decided by me.
- Non commercial / charity / educational – want to run Raven because it is easier / cheaper than an RDBMS.
- Replica only – a reduced cost license for a server that serves as a backup server for the main server.
- Developer – developer instances, nightly build, etc.
OSS - gets to use it for free, that isn’t going to change.
Non commercial usages, the examples that were brought up were things like a website for a .NET user group, running to do list,personal blog, etc. I see no value or need in making those people life harder. The model I am going to follow here is that you are going to have to request a license, and assuming it is a valid non commercial usage, I’ll issue a non-commercial license for that.
Developer licenses – I gave it some thought, and I realized that I really don’t want to try to tell developers what they should do. So, to make things easier all around, if you have a commercial license for Raven, you can develop on it. To make things absolutely clear, there in no CAL or any relation between the number of instances of Raven that you bought to the number of developers that can work on Raven. If you have a single licensed Raven instance and 2,500 developers, they call on work on that Raven instance. This explicitly include anything that you need to use for testing, continuous integration, or build servers.
Startups – Startups can request a commercial edition for free. They will receive two instance licenses, which should be enough to allow most places to grow to the point where if they need more licenses, they can afford them.
Contributor – If you made a non trivial contribution to RavenDB in some way, you get a license. To be more precise, you talk with me, and I will make every attempt to make you happy, period.
Pricing
There are several considerations here:
- I would much rather have a subscription based model than a one time payment. The pricing model is going to reflect that.
- We need to consider three different scenarios:
- A commercial usage with only a single instance.
- A commercial usage with multiple instances.
- OEM
Commercial usage with only a single instance - 45$ / month or 1,450$ perpetual license. If you need more instances in the future, you can upgrade (by paying the difference in the price) to multi instance commercial.
Commercial usage with multiple instances – the licensing model for isn’t per license, but for a license pack that contains 5 licenses. Pricing will be:
- Subscription - 125$ / month for the 1st pack (5 licenses), 75$ / month for each additional pack.
- If you want to run 3 servers, you pay 125$
- If you want to run 9 servers, you pay 200$
- If you want to run 16 servers, you pay 350$
- Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each additional pack.
- If you want to run 3 servers, you pay 3,750$
- If you want to run 9 servers, you pay 5,200$
- If you want to run 16 servers, you pay 8,100$
Perpetual comes with 6 months support, after which you either use the community support or buy a support contract.
Multi instance commercial licenses include replication and all the other HA / DR goodies.
OEM licenses requires a different approach, because OEM scenarios typically means that you are going to push it to large number of client clients (potentially hundreds or thousands of them). That preclude the ability to pay a per instance fee. An OEM license is going to be valid for embedded scenarios only, and is on a yearly subscription basis. The cost is 750 $ per developer for the first year, and 500$ per developer for renewals.
If you don’t wish to renew, you can still use the software and continue to distribute it to customers but you’ll get no more updates or support.
Summary
I would appreciate your opinions. Thanks
~Ayende Rahien
Eric J. Smith
May 19, 2010, 5:55:42 PM5/19/10
to ravendb
I think you have made great strides here and put the product within
reach for a lot of people. In general I think you are getting very
close. My only feedback is that on the pricing page on the website,
this has got to be made dead simple to understand. I know you just
whipped this post together and are explaining yourself, but there are
a LOT of options here. I remember you blogging about how MongoHQ
updated their pricing model and made it extremely simple and easy to
understand. IMO, that is what you need to shoot for even if you have
to make some compromises to get there. It needs to be dead simple and
just as elegant as the RavenDB source code.
On May 19, 4:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
> - Commercial
> in embedded scenarios.
> - Startup – cost sensitive, can probably pay later on.
> - OSS – pretty obvious :-)
> - Contributor – someone who made a non trivial contribution to Raven in
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
reach for a lot of people. In general I think you are getting very
close. My only feedback is that on the pricing page on the website,
this has got to be made dead simple to understand. I know you just
whipped this post together and are explaining yourself, but there are
a LOT of options here. I remember you blogging about how MongoHQ
updated their pricing model and made it extremely simple and easy to
understand. IMO, that is what you need to shoot for even if you have
to make some compromises to get there. It needs to be dead simple and
just as elegant as the RavenDB source code.
On May 19, 4:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
>
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> contains over 250 emails *from the last 18 hours* about that. I can’t even
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> count the twits. This text is meant to try to bring some order among all
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
> *Actual content:*
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
>
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> To those people, I can tell you that I am *already *in the business of
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> providing support & services for a free-as-in-beer product, NHibernate. That
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - OSS/AGPLv3
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - Commercial
>
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> be *included* in the commercial edition. I had planned to biff up the
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> enterprise version with things like document level security and index
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> - Commercial – *lots *of instances – running business critical
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> applications with lots of data on it.
> - Commercial – single instance – running business critical applications
> with modest amount of data on it.
> - OEM – want to run potentially hundreds / thousands of raven instances
> in embedded scenarios.
> - Startup – cost sensitive, can probably pay later on.
> - OSS – pretty obvious :-)
> - Contributor – someone who made a non trivial contribution to Raven in
> some manner, as decided by me.
> - Non commercial / charity / educational – want to run Raven because it
> is easier / cheaper than an RDBMS.
> - Replica only – a reduced cost license for a server that serves as a
> backup server for the main server.
> - Developer – developer instances, nightly build, etc.
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> a website for a .NET user group, running to do list,personal blog, etc. I
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> *Developer licenses *– I gave it some thought, and I realized that I really
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> don’t want to try to tell developers what they should do. So, to make things
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> *Startups *– Startups can request a commercial edition for free. They will
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> receive two instance licenses, which should be enough to allow most places
> to grow to the point where if they need more licenses, they can afford them.
>
> *Contributor *– If you made a non trivial contribution to RavenDB in some
> to grow to the point where if they need more licenses, they can afford them.
>
> way, you get a license. To be more precise, you talk with me, and I will
> make every attempt to make you happy, period.
>
> *Pricing*
> make every attempt to make you happy, period.
>
>
> There are several considerations here:
>
> - I would *much* rather have a subscription based model than a one time
> There are several considerations here:
>
> payment. The pricing model is going to reflect that.
> - We need to consider three different scenarios:
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> perpetual license. If you need more instances in the future, you can upgrade
> (by paying the difference in the price) to multi instance commercial.
>
> *Commercial usage with multiple instances *– the licensing model for isn’t
> (by paying the difference in the price) to multi instance commercial.
>
> per license, but for a license pack that contains 5 licenses. Pricing will
> be:
>
> - Subscription - 125$ / month for the 1st pack (5 licenses), 75$ / month
> be:
>
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
>
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> *OEM licenses *requires a different approach, because OEM scenarios
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> typically means that you are going to push it to large number of client
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
> *Summary*
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
Aaron Weiker
May 19, 2010, 6:07:14 PM5/19/10
to rav...@googlegroups.com, ravendb
I really appreciate you taking the time and energy to work through this with the community. I like the refinements in licensing and it looks a lot more approachable.
Sent from my iPhone
Sent from my iPhone
Ayende Rahien
May 19, 2010, 6:08:34 PM5/19/10
to ravendb
Yeah, I thought about that when I wrote that.
I thought about something like this;
Subscription pricing (monthly):
|
|
# of licenses per pack |
1st license pack |
Additional license packs |
|
Single instance |
1 |
45 USD |
Not available – upgrade available to multiply instances. |
|
Multiple instances |
5 |
125 USD |
75 USD |
Perpetual pricing (onetime payment) - includes 6 months of support.
|
|
# of licenses per pack |
1st license pack |
Additional license packs |
|
Single instance |
1 |
1,450 USD |
Not available – upgrade available to multiply instances. |
|
Multiple instances |
5 |
3,750 USD |
1,450 USD |
OEM Pricing (embedded version only) – includes 1 year support:
|
|
1st year |
Renewal (each year) |
|
Per developer |
750 USD |
500 USD |
Commercial development licenses – unlimited with any commercial license.
Startup offer – Contact us to get two commercial licenses.
Non commercial – contact us to get a non-commercial license.
Josh Coffman
May 19, 2010, 6:04:32 PM5/19/10
to rav...@googlegroups.com
Well to add more a serious response than before, I agree with Eric in that it seems pretty close. At some point you should just launch it, and then see what the response it. You can adjust the price later based on actual market demand and customer feedback. Maybe I'm naive, but seems like that would tend to bare out a natural market price.
-j
@JoshCoffman
480-270-4578 | josh [at] computeristsolutions [dot] com | http://computeristsolutions.com
@JoshCoffman
480-270-4578 | josh [at] computeristsolutions [dot] com | http://computeristsolutions.com
Adam
May 19, 2010, 6:10:46 PM5/19/10
to rav...@googlegroups.com
I honestly think this is very reasonable, you've addressed the multiple servers issue, made life easy for startups and still come out with a very reasonably priced product. I'm already very impressed with the product technically, and liking it more the more I use it, and your attitude to pricing has made it something that I think I could now easily recommend. My opinion in a word is fantastic.
Ayende Rahien
May 19, 2010, 6:13:58 PM5/19/10
to ravendb
Let me put it this way, I would really rather avoid getting 250 emails like that again.
I don't mind being made a fool in public, but there is a saying about those who keep making the same mistakes.
Josh Schwartzberg
May 19, 2010, 6:11:18 PM5/19/10
to ravendb
I highly suggest you provide a very limited entry point for free
commercial usage or else people evaluating options for their startups,
where even a few hundred dollars can make a difference... Imposing a
storage limit, without a performance limitation is exactly what
Microsoft did with SQL Express. This makes it a no-brainer for
initial usage, pushes more developers to know how to work with the
product, makes more developers talk about it, and will likely end up
being a solution they can now recommend since they've actually used
it; even if it was just in a small project.
-Josh Schwartzberg
commercial usage or else people evaluating options for their startups,
where even a few hundred dollars can make a difference... Imposing a
storage limit, without a performance limitation is exactly what
Microsoft did with SQL Express. This makes it a no-brainer for
initial usage, pushes more developers to know how to work with the
product, makes more developers talk about it, and will likely end up
being a solution they can now recommend since they've actually used
it; even if it was just in a small project.
-Josh Schwartzberg
Ayende Rahien
May 19, 2010, 6:16:28 PM5/19/10
to ravendb
Um, you mean, in addition to giving startups two licenses for free?
Tobes
May 19, 2010, 6:19:14 PM5/19/10
to ravendb
I agree it needs simplifying.
a) Open Source RavenDB for people developing OSS.
b) RavenDB Express for the world (free, even if developing commercial
apps)
c) RavenDB licensed for serious players who need more than 200
transactions per second, or RavenDB on 4+ cores. Or whatever.
I'm late to the party here, but to me it's unclear WHO I should be if
I want to buy your product.
The initial high price tag tells me to walk away unless I'm working
with a company with a
large IT budget. It tells me that Raven is for a small subset of the
market.
I doubt that was your intention based on your open discussion
(awesome, btw!). But that is the impression originally got.
T
On May 19, 10:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
> - Commercial
> in embedded scenarios.
> - Startup – cost sensitive, can probably pay later on.
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
a) Open Source RavenDB for people developing OSS.
b) RavenDB Express for the world (free, even if developing commercial
apps)
c) RavenDB licensed for serious players who need more than 200
transactions per second, or RavenDB on 4+ cores. Or whatever.
I'm late to the party here, but to me it's unclear WHO I should be if
I want to buy your product.
The initial high price tag tells me to walk away unless I'm working
with a company with a
large IT budget. It tells me that Raven is for a small subset of the
market.
I doubt that was your intention based on your open discussion
(awesome, btw!). But that is the impression originally got.
T
On May 19, 10:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
>
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> contains over 250 emails *from the last 18 hours* about that. I can’t even
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> count the twits. This text is meant to try to bring some order among all
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
> *Actual content:*
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
>
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> To those people, I can tell you that I am *already *in the business of
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> providing support & services for a free-as-in-beer product, NHibernate. That
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - OSS/AGPLv3
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - Commercial
>
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> be *included* in the commercial edition. I had planned to biff up the
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> enterprise version with things like document level security and index
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> - Commercial – *lots *of instances – running business critical
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> applications with lots of data on it.
> - Commercial – single instance – running business critical applications
> with modest amount of data on it.
> - OEM – want to run potentially hundreds / thousands of raven instances
> in embedded scenarios.
> - Startup – cost sensitive, can probably pay later on.
> - OSS – pretty obvious :-)
> - Contributor – someone who made a non trivial contribution to Raven in
> some manner, as decided by me.
> - Non commercial / charity / educational – want to run Raven because it
> is easier / cheaper than an RDBMS.
> - Replica only – a reduced cost license for a server that serves as a
> backup server for the main server.
> - Developer – developer instances, nightly build, etc.
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> a website for a .NET user group, running to do list,personal blog, etc. I
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> *Developer licenses *– I gave it some thought, and I realized that I really
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> don’t want to try to tell developers what they should do. So, to make things
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> *Startups *– Startups can request a commercial edition for free. They will
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> receive two instance licenses, which should be enough to allow most places
> to grow to the point where if they need more licenses, they can afford them.
>
> *Contributor *– If you made a non trivial contribution to RavenDB in some
> to grow to the point where if they need more licenses, they can afford them.
>
> way, you get a license. To be more precise, you talk with me, and I will
> make every attempt to make you happy, period.
>
> *Pricing*
> make every attempt to make you happy, period.
>
>
> There are several considerations here:
>
> - I would *much* rather have a subscription based model than a one time
> There are several considerations here:
>
> payment. The pricing model is going to reflect that.
> - We need to consider three different scenarios:
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> perpetual license. If you need more instances in the future, you can upgrade
> (by paying the difference in the price) to multi instance commercial.
>
> *Commercial usage with multiple instances *– the licensing model for isn’t
> (by paying the difference in the price) to multi instance commercial.
>
> per license, but for a license pack that contains 5 licenses. Pricing will
> be:
>
> - Subscription - 125$ / month for the 1st pack (5 licenses), 75$ / month
> be:
>
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
>
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> *OEM licenses *requires a different approach, because OEM scenarios
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> typically means that you are going to push it to large number of client
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
> *Summary*
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
>
> I would appreciate your opinions. Thanks
>
> ~Ayende Rahien
> I would appreciate your opinions. Thanks
>
> ~Ayende Rahien
On May 19, 11:16 pm, Ayende Rahien <aye...@ayende.com> wrote:
> Um, you mean, in addition to giving startups two licenses for free?
>
> Um, you mean, in addition to giving startups two licenses for free?
>
Tobes
May 19, 2010, 6:17:45 PM5/19/10
to ravendb
I agree it needs simplifying.
a) Open Source RavenDB for people developing OSS.
b) RavenDB Express for the world (free, even if developing commercial
apps)
c) RavenDB licensed for serious players who need more than 200
transactions per second, or RavenDB on 4+ cores. Or whatever.
I'm late to the party here, but to me it's unclear WHO I should be if
I want to buy your product.
The initial high price tag tells me to walk away unless I'm working
with a company with a
large IT budget. It tells me that Raven is for a small subset of the
market.
I doubt that was your intention based on your open discussion
(awesome, btw!). But that is the impression originally got.
T
On May 19, 10:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
a) Open Source RavenDB for people developing OSS.
b) RavenDB Express for the world (free, even if developing commercial
apps)
c) RavenDB licensed for serious players who need more than 200
transactions per second, or RavenDB on 4+ cores. Or whatever.
I'm late to the party here, but to me it's unclear WHO I should be if
I want to buy your product.
The initial high price tag tells me to walk away unless I'm working
with a company with a
large IT budget. It tells me that Raven is for a small subset of the
market.
I doubt that was your intention based on your open discussion
(awesome, btw!). But that is the impression originally got.
T
On May 19, 10:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
>
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> contains over 250 emails *from the last 18 hours* about that. I can’t even
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> count the twits. This text is meant to try to bring some order among all
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
> *Actual content:*
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
>
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> To those people, I can tell you that I am *already *in the business of
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> providing support & services for a free-as-in-beer product, NHibernate. That
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - OSS/AGPLv3
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - Commercial
>
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> be *included* in the commercial edition. I had planned to biff up the
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> enterprise version with things like document level security and index
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> - Commercial – *lots *of instances – running business critical
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> applications with lots of data on it.
> - Commercial – single instance – running business critical applications
> with modest amount of data on it.
> - OEM – want to run potentially hundreds / thousands of raven instances
> in embedded scenarios.
> - Startup – cost sensitive, can probably pay later on.
> - OSS – pretty obvious :-)
> - Contributor – someone who made a non trivial contribution to Raven in
> - OSS – pretty obvious :-)
> some manner, as decided by me.
> - Non commercial / charity / educational – want to run Raven because it
> is easier / cheaper than an RDBMS.
> - Replica only – a reduced cost license for a server that serves as a
> backup server for the main server.
> - Developer – developer instances, nightly build, etc.
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> a website for a .NET user group, running to do list,personal blog, etc. I
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> *Developer licenses *– I gave it some thought, and I realized that I really
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> don’t want to try to tell developers what they should do. So, to make things
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> *Startups *– Startups can request a commercial edition for free. They will
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> receive two instance licenses, which should be enough to allow most places
> to grow to the point where if they need more licenses, they can afford them.
>
> *Contributor *– If you made a non trivial contribution to RavenDB in some
> to grow to the point where if they need more licenses, they can afford them.
>
> way, you get a license. To be more precise, you talk with me, and I will
> make every attempt to make you happy, period.
>
> *Pricing*
> make every attempt to make you happy, period.
>
>
> There are several considerations here:
>
> - I would *much* rather have a subscription based model than a one time
> There are several considerations here:
>
> payment. The pricing model is going to reflect that.
> - We need to consider three different scenarios:
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> perpetual license. If you need more instances in the future, you can upgrade
> (by paying the difference in the price) to multi instance commercial.
>
> *Commercial usage with multiple instances *– the licensing model for isn’t
> (by paying the difference in the price) to multi instance commercial.
>
> per license, but for a license pack that contains 5 licenses. Pricing will
> be:
>
> - Subscription - 125$ / month for the 1st pack (5 licenses), 75$ / month
> be:
>
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
>
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> *OEM licenses *requires a different approach, because OEM scenarios
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> typically means that you are going to push it to large number of client
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
> *Summary*
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
Tobi
May 19, 2010, 6:24:10 PM5/19/10
to rav...@googlegroups.com
Ayende Rahien wrote:
> *OEM licenses *requires a different approach, because OEM scenarios
> ...
> If you don�t wish to renew, you can still use the software and continue
> to distribute it to customers but you�ll get no more updates or support.
Great! Exactly what we talked about off-list :-)
My personal interest in RavenDB is mainly the embedded use case. And this
is something RavenDB is ahead of its OSS or closed source "competitors".
The closest thing to a an embedded nosql solution is probably "HamsterDB",
but a native .Net solution is much more preferable.
The OEM licensing model and prices are fair and if I don't stumble across
some technical issues, I'm pretty sure, I can convince my boss to spend
some extra bucks and switch to RavenDB.
Tobias
> *OEM licenses *requires a different approach, because OEM scenarios
> ...
> If you don�t wish to renew, you can still use the software and continue
> to distribute it to customers but you�ll get no more updates or support.
Great! Exactly what we talked about off-list :-)
My personal interest in RavenDB is mainly the embedded use case. And this
is something RavenDB is ahead of its OSS or closed source "competitors".
The closest thing to a an embedded nosql solution is probably "HamsterDB",
but a native .Net solution is much more preferable.
The OEM licensing model and prices are fair and if I don't stumble across
some technical issues, I'm pretty sure, I can convince my boss to spend
some extra bucks and switch to RavenDB.
Tobias
Ayende Rahien
May 19, 2010, 6:28:31 PM5/19/10
to ravendb
I don't like the idea of express edition for Raven. I think that the OSS version is where the express edition comes into play.
MS only introduced express because it was either do that or lose everyone who couldn't pay for SQL to MySQL.
And I think that 45$ / mo is a price tag that most projects would find easy enough to pay.
Josh Schwartzberg
May 19, 2010, 6:35:29 PM5/19/10
to ravendb
Not just startups getting 2 free instance, corporate developers could
use an express edition as an entry point with a small internal
application... easing that transition to many more purchases as they
apply it to larger applications.
> ...
>
> read more »
use an express edition as an entry point with a small internal
application... easing that transition to many more purchases as they
apply it to larger applications.
>
> read more »
Joe
May 19, 2010, 6:33:58 PM5/19/10
to ravendb
You mention that the perpetual license comes with 6 months of support,
does the commercial subscription come with support or do we need to
get a separate support contract?
On May 19, 4:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
> - Commercial
> in embedded scenarios.
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
does the commercial subscription come with support or do we need to
get a separate support contract?
On May 19, 4:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
>
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> contains over 250 emails *from the last 18 hours* about that. I can’t even
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> count the twits. This text is meant to try to bring some order among all
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
> *Actual content:*
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
>
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> To those people, I can tell you that I am *already *in the business of
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> providing support & services for a free-as-in-beer product, NHibernate. That
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - OSS/AGPLv3
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - Commercial
>
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> be *included* in the commercial edition. I had planned to biff up the
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> enterprise version with things like document level security and index
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> - Commercial – *lots *of instances – running business critical
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> applications with lots of data on it.
> - Commercial – single instance – running business critical applications
> with modest amount of data on it.
> - OEM – want to run potentially hundreds / thousands of raven instances
> in embedded scenarios.
> - Startup – cost sensitive, can probably pay later on.
> - OSS – pretty obvious :-)
> - Contributor – someone who made a non trivial contribution to Raven in
> - OSS – pretty obvious :-)
> some manner, as decided by me.
> - Non commercial / charity / educational – want to run Raven because it
> is easier / cheaper than an RDBMS.
> - Replica only – a reduced cost license for a server that serves as a
> backup server for the main server.
> - Developer – developer instances, nightly build, etc.
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> a website for a .NET user group, running to do list,personal blog, etc. I
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> *Developer licenses *– I gave it some thought, and I realized that I really
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> don’t want to try to tell developers what they should do. So, to make things
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> *Startups *– Startups can request a commercial edition for free. They will
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> receive two instance licenses, which should be enough to allow most places
> to grow to the point where if they need more licenses, they can afford them.
>
> *Contributor *– If you made a non trivial contribution to RavenDB in some
> to grow to the point where if they need more licenses, they can afford them.
>
> way, you get a license. To be more precise, you talk with me, and I will
> make every attempt to make you happy, period.
>
> *Pricing*
> make every attempt to make you happy, period.
>
>
> There are several considerations here:
>
> - I would *much* rather have a subscription based model than a one time
> There are several considerations here:
>
> payment. The pricing model is going to reflect that.
> - We need to consider three different scenarios:
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> perpetual license. If you need more instances in the future, you can upgrade
> (by paying the difference in the price) to multi instance commercial.
>
> *Commercial usage with multiple instances *– the licensing model for isn’t
> (by paying the difference in the price) to multi instance commercial.
>
> per license, but for a license pack that contains 5 licenses. Pricing will
> be:
>
> - Subscription - 125$ / month for the 1st pack (5 licenses), 75$ / month
> be:
>
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
>
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> *OEM licenses *requires a different approach, because OEM scenarios
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> typically means that you are going to push it to large number of client
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
> *Summary*
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
Tobes
May 19, 2010, 6:40:04 PM5/19/10
to ravendb
I guess I'm lazy. I'd rather have hard-coded limitations, visible on
the packaging, rather than having to decipher OSS licensing
documentation :)
If I'm paying monthly, I expect hosted solution. https://mongohq.com/pricing.
This isn't right vs wrong btw, just my world view. I don't know if I'm
your perfect customer so feel free to ignore :)
T
> > > > I highly suggest...
>
> read more »
the packaging, rather than having to decipher OSS licensing
documentation :)
If I'm paying monthly, I expect hosted solution. https://mongohq.com/pricing.
This isn't right vs wrong btw, just my world view. I don't know if I'm
your perfect customer so feel free to ignore :)
T
>
> read more »
Adam
May 19, 2010, 6:40:04 PM5/19/10
to rav...@googlegroups.com
This looks simpler to me (apple mail won't let format it more nicely but hopefully you'll get the idea):
1 License
5 License Pack
Support details go in this column
Subscription pricing (monthly)
45 USD
125 USD
Perpetual pricing (onetime payment)
1,450 USD
3,750 USD
Eric J. Smith
May 19, 2010, 6:40:10 PM5/19/10
to ravendb
Ayende,
What about keeping this extremely simple and basically accomplishing
the same thing. Here is my idea:
--------------------
Perpetual
$599/instance
Subscription
$25/instance/month
OEM (Embedded Only)
$750/developer/year
If you are a startup company, open source project, or would like to
use Raven in a non-commercial closed source project, please contact us
to request free licensing.
--------------------
This makes everything extremely simple and I think it's about the same
pricing as what you have outlined for most scenarios.
Eric J. Smith
What about keeping this extremely simple and basically accomplishing
the same thing. Here is my idea:
--------------------
Perpetual
$599/instance
Subscription
$25/instance/month
OEM (Embedded Only)
$750/developer/year
If you are a startup company, open source project, or would like to
use Raven in a non-commercial closed source project, please contact us
to request free licensing.
--------------------
This makes everything extremely simple and I think it's about the same
pricing as what you have outlined for most scenarios.
Eric J. Smith
Ayende Rahien
May 19, 2010, 6:41:37 PM5/19/10
to ravendb
Joe,
Subscriptions comes with a commercial support, yes.
2 incidents a year (or 6 months, in the case of perpetual).
Tobes
May 19, 2010, 6:43:43 PM5/19/10
to ravendb
Eric,
Nice, that kind of simplicity is what I'd personally be looking for.
Tobin
Nice, that kind of simplicity is what I'd personally be looking for.
Tobin
theouteredge
May 19, 2010, 6:43:38 PM5/19/10
to ravendb
I think that sounds really good and it makes sense to drop the
enterprise version until you have a stable reliable product that you
are going to be able get large enterprise users to fork out large sums
for.
The deal for startups looks very good, although from a personal
perspective I'd like to see startups being able to get in on the
embedded version as I have a project I'm starting for the windows 7
phone which I want to use the embedded and server version combined.
Embedded version to save data locally and the server version to pull
down shared data.
I've really enjoyed moving my little test site from NHibernate over to
Raven. Its been pretty much friction free and one of the easiest
systems I've ever used, the Client API is very easy to get started
with. The only real problem I've had is in moving my mind set from
Relational thinking to Document :)
On May 19, 10:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
> - Commercial
> in embedded scenarios.
> - Startup – cost sensitive, can probably pay later on.
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
enterprise version until you have a stable reliable product that you
are going to be able get large enterprise users to fork out large sums
for.
The deal for startups looks very good, although from a personal
perspective I'd like to see startups being able to get in on the
embedded version as I have a project I'm starting for the windows 7
phone which I want to use the embedded and server version combined.
Embedded version to save data locally and the server version to pull
down shared data.
I've really enjoyed moving my little test site from NHibernate over to
Raven. Its been pretty much friction free and one of the easiest
systems I've ever used, the Client API is very easy to get started
with. The only real problem I've had is in moving my mind set from
Relational thinking to Document :)
On May 19, 10:41 pm, Ayende Rahien <aye...@ayende.com> wrote:
> *Meta commentary* (feel free to skip it to the actual content section):
>
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> contains over 250 emails *from the last 18 hours* about that. I can’t even
> I have to admit that I had high hopes that the launch event would generate
> some interest in Raven, but I had no way to foresee the actual reaction. And
> unfortunately most of that focused on the licensing. While I agree that this
> is an important issue, I would much rather see a lot more focus on actual
> product rather than the licensing.
>
> I have been trying to catch up with the flow, but I was teaching for most of
> the day, so I kept falling behind. Just to give you an idea, my mailbox
> count the twits. This text is meant to try to bring some order among all
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
> *Actual content:*
> those messages.It would also, hopefully, help me explain my thinking and
> thought process. I know that it is atypical to have a pricing discussion in
> such a public forum, but I think that this is useful.
>
> I apologize for the length of this message, I didn’t have the time to make
> it shorter.
>
>
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> To those people, I can tell you that I am *already *in the business of
> When I set out to draft the licensing terms for Raven I had in mind
> traditional database licensing, which are usually per server. That works,
> quite nicely, if you have a low number of instances. In the NoSQL
> environment, that is a problem, because you are expected to run large number
> of instances, that is a big stumbling block. That is certainly something
> that I have should have taken into account.
>
> Let us cut to the chase:
>
> I am aware that there are established competitors for Raven out there, most
> of whom are free for commercial use. I obviously believe that Raven has
> enough to offer to be worth paying for commercially. Some of the replies
> that I got back expressed a strong desire for having a free as in beer for
> commercial use and starting a support & services model to make money on
> that.
>
> providing support & services for a free-as-in-beer product, NHibernate. That
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - OSS/AGPLv3
> gives me a pretty realistic view of the amount of money involved, the amount
> of effort required and the return on investment. If this was what I wanted,
> I wouldn’t have gone to all the trouble of developing Raven.
>
> With that said, let us go directly to the details. As Eric mentioned, while
> Commercial & Enterprise separation make sense for an established product, I
> am current at the stage where my main concern is gaining acceptance. That
> was especially apparent with the way just about anyone latched into the
> pricing of the enterprise edition, without considering the commercial
> edition.
>
> With that in mind, I think that Raven will have only two modes:
>
> - Commercial
>
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> be *included* in the commercial edition. I had planned to biff up the
> To make things clear, features such as master/master replication, automatic
> failover, master/slave replication and multi node replication are going to
> enterprise version with things like document level security and index
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> - Commercial – *lots *of instances – running business critical
> replication to RDBMS. I might offer them as separate bundles, licensed
> commercially independently from RavenDB Core.
>
> As I see it, we have the following personas to consider when we are talking
> about licensing:
>
> applications with lots of data on it.
> - Commercial – single instance – running business critical applications
> with modest amount of data on it.
> - OEM – want to run potentially hundreds / thousands of raven instances
> in embedded scenarios.
> - Startup – cost sensitive, can probably pay later on.
> - OSS – pretty obvious :-)
> - Contributor – someone who made a non trivial contribution to Raven in
> some manner, as decided by me.
> - Non commercial / charity / educational – want to run Raven because it
> is easier / cheaper than an RDBMS.
> - Replica only – a reduced cost license for a server that serves as a
> backup server for the main server.
> - Developer – developer instances, nightly build, etc.
>
> *OSS *- gets to use it for free, that isn’t going to change.
>
> *Non commercial usages*, the examples that were brought up were things like
> a website for a .NET user group, running to do list,personal blog, etc. I
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> *Developer licenses *– I gave it some thought, and I realized that I really
> see no value or need in making those people life harder. The model I am
> going to follow here is that you are going to have to request a license, and
> assuming it is a valid non commercial usage, I’ll issue a non-commercial
> license for that.
>
> don’t want to try to tell developers what they should do. So, to make things
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> *Startups *– Startups can request a commercial edition for free. They will
> easier all around, if you have a commercial license for Raven, you can
> develop on it. To make things absolutely clear, there in no CAL or any
> relation between the number of instances of Raven that you bought to the
> number of developers that can work on Raven. If you have a single licensed
> Raven instance and 2,500 developers, they call on work on that Raven
> instance. This explicitly include anything that you need to use for testing,
> continuous integration, or build servers.
>
> receive two instance licenses, which should be enough to allow most places
> to grow to the point where if they need more licenses, they can afford them.
>
> *Contributor *– If you made a non trivial contribution to RavenDB in some
> to grow to the point where if they need more licenses, they can afford them.
>
> way, you get a license. To be more precise, you talk with me, and I will
> make every attempt to make you happy, period.
>
> *Pricing*
> make every attempt to make you happy, period.
>
>
> There are several considerations here:
>
> - I would *much* rather have a subscription based model than a one time
> There are several considerations here:
>
> payment. The pricing model is going to reflect that.
> - We need to consider three different scenarios:
> - A commercial usage with only a single instance.
> - A commercial usage with multiple instances.
> - OEM
>
> *Commercial usage with only a single instance *- 45$ / month or 1,450$
> perpetual license. If you need more instances in the future, you can upgrade
> (by paying the difference in the price) to multi instance commercial.
>
> *Commercial usage with multiple instances *– the licensing model for isn’t
> (by paying the difference in the price) to multi instance commercial.
>
> per license, but for a license pack that contains 5 licenses. Pricing will
> be:
>
> - Subscription - 125$ / month for the 1st pack (5 licenses), 75$ / month
> be:
>
> for each additional pack.
> - If you want to run 3 servers, you pay 125$
> - If you want to run 9 servers, you pay 200$
> - If you want to run 16 servers, you pay 350$
> - Perpetual – 3,750$ for the 1st pack of 5 licenses, 1,450$ for each
> additional pack.
> - If you want to run 3 servers, you pay 3,750$
> - If you want to run 9 servers, you pay 5,200$
> - If you want to run 16 servers, you pay 8,100$
>
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> *OEM licenses *requires a different approach, because OEM scenarios
> Perpetual comes with 6 months support, after which you either use the
> community support or buy a support contract.
>
> Multi instance commercial licenses include replication and all the other HA
> / DR goodies.
>
> typically means that you are going to push it to large number of client
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
> *Summary*
> clients (potentially hundreds or thousands of them). That preclude the
> ability to pay a per instance fee. An OEM license is going to be valid for
> embedded scenarios only, and is on a yearly subscription basis. The cost is
> 750 $ per developer for the first year, and 500$ per developer for renewals.
>
> If you don’t wish to renew, you can still use the software and continue to
> distribute it to customers but you’ll get no more updates or support.
>
Ayende Rahien
May 19, 2010, 6:43:55 PM5/19/10
to ravendb
I follow the logic, I am just not sure that I agree.
How do you enforce that?
What limits are you going to set?
How do you prevent it from eating into thing like the single instance option?
Tobi
May 19, 2010, 6:44:07 PM5/19/10
to rav...@googlegroups.com
under the AGPL terms, everyone is free to download it, play around with it
or develop in-house applications. As long as everyone that uses a RavenDB
based application has access to the source code, it's all free.
Because of this, I don't think there's a need for an "Express" version.
And personally I hope, that besides a "commercial success" for Ayende,
some cool RavenDB based OSS projects will come to life.
Tobias
Josh Schwartzberg
May 19, 2010, 6:55:04 PM5/19/10
to ravendb
Let me give you the scenario:
I worked for a ~1500 person corporation in the past, one that
diligently enforced software licenses and paid what was expected.
There were many small applications made to be used by just a few
people, these were often the play toys for new technology. Ones that
you would not deal with going through the process of requesting the
purchase of new software licenses to do so. Getting technology,
mainly open source stuff proven into these smaller apps was the
primary way to make it into the larger applications.. this is the very
real scenario that many corporate developers deal with. There really
needs to be a way to get in this nook with the least amount of
friction.
Just being able to play around with it in the corporate world isn't
enough to prove that it works in the real world to the superiors.
Unless I'm naively understanding the license, and it can be used in-
house commercially?
Josh
I worked for a ~1500 person corporation in the past, one that
diligently enforced software licenses and paid what was expected.
There were many small applications made to be used by just a few
people, these were often the play toys for new technology. Ones that
you would not deal with going through the process of requesting the
purchase of new software licenses to do so. Getting technology,
mainly open source stuff proven into these smaller apps was the
primary way to make it into the larger applications.. this is the very
real scenario that many corporate developers deal with. There really
needs to be a way to get in this nook with the least amount of
friction.
Just being able to play around with it in the corporate world isn't
enough to prove that it works in the real world to the superiors.
Unless I'm naively understanding the license, and it can be used in-
house commercially?
Josh
Tobes
May 19, 2010, 6:55:43 PM5/19/10
to ravendb
> Besides all commercial licensing issues. As long as RavenDB is published
> under the AGPL terms, everyone is free to download it, play around with it
> or develop in-house applications. As long as everyone that uses a RavenDB
> based application has access to the source code, it's all free.
There is a slight "Don't make me think" obstacle here. I have to think
> under the AGPL terms, everyone is free to download it, play around with it
> or develop in-house applications. As long as everyone that uses a RavenDB
> based application has access to the source code, it's all free.
hard, ask questions, and read stuff to work out if I can use this
software.
For example, if I publish an in-house app on RavenDB for a business,
should all people in that business legally have permission to access
the source code?
Having to think isn't necessarily an issue for some customers, but a
potential sales killer for others.
> And personally I hope, that besides a "commercial success" for Ayende,
> some cool RavenDB based OSS projects will come to life.
> Tobias
Ayende Rahien
May 19, 2010, 6:55:56 PM5/19/10
to ravendb
I think that I'll take this under advisement, but i don't think that I'll take steps to implement it at this time.
Adding stuff is easy, taking them away, not so much.
Ayende Rahien
May 19, 2010, 6:57:06 PM5/19/10
to ravendb
Tobi,
That is pretty much how I am feeling about this, yes.
Ayende Rahien
May 19, 2010, 6:57:36 PM5/19/10
to ravendb
That does looks much beter
Eric J. Smith
May 19, 2010, 6:58:50 PM5/19/10
to ravendb
I'd actually say that OEM should be more. Probably $999/developer/
year. It would include support and allow them to only use the
embedded storage engine. My reasoning for this is because you know
that people are going to buy one license and say they only have one
developer working on it when they really have 5-10.
Perpetual would come with 6 months of support and maybe renew for
around $249/instance/year
year. It would include support and allow them to only use the
embedded storage engine. My reasoning for this is because you know
that people are going to buy one license and say they only have one
developer working on it when they really have 5-10.
Perpetual would come with 6 months of support and maybe renew for
around $249/instance/year
Ayende Rahien
May 19, 2010, 7:01:26 PM5/19/10
to ravendb
Eric,
I never thought that you can apply refactoring to a pricing model. Love it.
One comment, though, you mentioned before that there is value in making a big first payment.
Ayende Rahien
May 19, 2010, 7:04:52 PM5/19/10
to ravendb
Andy,
That would probably require some special handling.
Although, to be frank, I don't even know if Raven would work on the phone.
(If it doesn't, and you really need it, I can probably switch things to a different mode that would be fully managed code, might be somewhat slower, but it doesn't matter on a client).
Eric J. Smith
May 19, 2010, 7:05:05 PM5/19/10
to ravendb
Yeah, I thought you might catch me on that. :-) I think this is one
of those compromises that you might have to make to keep things
simple. The whole 1 for this or 5 for this is a bit awkward. Plus
this model is heavily geared toward the subscription licensing which
is great for you. Recurring revenue + technology lock in = good for
you. ;-)
On May 19, 6:01 pm, Ayende Rahien <aye...@ayende.com> wrote:
> Eric,
> I never thought that you can apply refactoring to a pricing model. Love it.
> One comment, though, you mentioned before that there is value in making a
> big first payment.
>
of those compromises that you might have to make to keep things
simple. The whole 1 for this or 5 for this is a bit awkward. Plus
this model is heavily geared toward the subscription licensing which
is great for you. Recurring revenue + technology lock in = good for
you. ;-)
On May 19, 6:01 pm, Ayende Rahien <aye...@ayende.com> wrote:
> Eric,
> I never thought that you can apply refactoring to a pricing model. Love it.
> One comment, though, you mentioned before that there is value in making a
> big first payment.
>
Ayende Rahien
May 19, 2010, 7:05:54 PM5/19/10
to ravendb
Josh,
Yes, the OSS version _can_ be use in house commercially.
Ayende Rahien
May 19, 2010, 7:06:47 PM5/19/10
to ravendb
inline
On Wed, May 19, 2010 at 11:55 PM, Tobes <to...@tobinharris.com> wrote:
> Besides all commercial licensing issues. As long as RavenDB is publishedThere is a slight "Don't make me think" obstacle here. I have to think
> under the AGPL terms, everyone is free to download it, play around with it
> or develop in-house applications. As long as everyone that uses a RavenDB
> based application has access to the source code, it's all free.
hard, ask questions, and read stuff to work out if I can use this
software.
Yes, which hopefully will tell you "screw this, where is my CC"
For example, if I publish an in-house app on RavenDB for a business,
should all people in that business legally have permission to access
the source code?
Yes.
Ayende Rahien
May 19, 2010, 7:07:42 PM5/19/10
to ravendb
Got you, agreed.
Eric J. Smith
May 19, 2010, 7:10:44 PM5/19/10
to ravendb
Yep, this is exactly why I would put all the free options at the
bottom of the pricing page and make them contact you to request a
license. Some of them will just buy it and the ones that complain,
you can point them to the pricing page and tell them to read the fine
print. :-)
bottom of the pricing page and make them contact you to request a
license. Some of them will just buy it and the ones that complain,
you can point them to the pricing page and tell them to read the fine
print. :-)
Ayende Rahien
May 19, 2010, 7:12:55 PM5/19/10
to ravendb
Make sense. This give us this:
|
|
Cost |
Support |
|
Subscriptions |
25 USD / instance / month |
Yes – 2 incidents / year |
|
Perpetual |
599 USD / instance / month |
Yes – 2 incidents / 6 months Additional support contract: 249 USD / instance / year |
|
OEM (embedded only) |
999 USD / instance / month |
Yes – 2 incidents / year |
If you are a startup company, open source project, or would like to use Raven in a non-commercial closed source project, please contact us to request free licensing.
Joel Lucsy
May 19, 2010, 7:16:11 PM5/19/10
to rav...@googlegroups.com
Woah, $999 per month for embedded? Not year?
Ayende Rahien
May 19, 2010, 7:20:33 PM5/19/10
to ravendb
Sorry, copy/paste error. Thanks for catching that.
|
|
Cost |
Support |
|
Subscriptions |
25 USD / instance / month |
Yes – 2 incidents / year |
|
Perpetual |
599 USD / instance / month |
Yes – 2 incidents / 6 months Additional support contract: 249 USD / instance / year |
|
OEM (embedded only) |
999 USD / instance / year |
|
Yes – 2 incidents / year |
If you are a startup company, open source project, or would like to use Raven in a non-commercial closed source project, please contact us to request free licensing.
Tobi
May 19, 2010, 7:28:52 PM5/19/10
to rav...@googlegroups.com
Tobes wrote:
> For example, if I publish an in-house app on RavenDB for a business,
> should all people in that business legally have permission to access
> the source code?
IANAL, but yes, that's what the AGPL is all about. You are not forced to
> For example, if I publish an in-house app on RavenDB for a business,
> should all people in that business legally have permission to access
> the source code?
use the AGPL for your in-house app, but it must be an OSI approved license
(while RavenDB itself still is AGPL). And if someone downloads the code
for your in-house app, he's free to make it available to others.
Tobias
Ayende Rahien
May 19, 2010, 7:36:00 PM5/19/10
to ravendb
No, you are talking about different things.
AGPL is _not_ compatible with other OSS licenses.
_Raven_ specifically allows that.
If you build an in house application, you aren't distributing that, so you can use the AGPL version.
Technically, you application is AGPLed, but it doesn't matter, since it wasn't distributed.
If an internal user wants the source, though, you have to give it to him. What is the likelihood?
Tobi
May 19, 2010, 7:36:44 PM5/19/10
to rav...@googlegroups.com
Ayende Rahien wrote:
> OEM (embedded only)
> 999 USD / instance / year
Eric! What are you doing to me? This was already at 750 USD / 500 USD ! :-)
> OEM (embedded only)
> 999 USD / instance / year
Tobias
Eric J. Smith
May 19, 2010, 7:51:33 PM5/19/10
to ravendb
LOL. Sorry, I just know how these things work from my experience with
CodeSmith. Even with activation, I'd say that 30% of licenses are
used by more than one person. Since there will be no way to control
the OEM license, I'm sure license abuse will be very rampant with that
license.
Ayende, speaking of license abuse, I bet you could implement some sort
of udp license validation to make sure people aren't abusing their
subscription or perpetual licenses.
I guess I should duck now since everyone will be throwing things at
me. ;-) Just remember though, we went from like $140k for 16
instances to like $10k. I think ayende has a pretty reasonable
pricing model now and we all hope he makes a killing from it.
CodeSmith. Even with activation, I'd say that 30% of licenses are
used by more than one person. Since there will be no way to control
the OEM license, I'm sure license abuse will be very rampant with that
license.
Ayende, speaking of license abuse, I bet you could implement some sort
of udp license validation to make sure people aren't abusing their
subscription or perpetual licenses.
I guess I should duck now since everyone will be throwing things at
me. ;-) Just remember though, we went from like $140k for 16
instances to like $10k. I think ayende has a pretty reasonable
pricing model now and we all hope he makes a killing from it.
Tobi
May 19, 2010, 7:54:09 PM5/19/10
to rav...@googlegroups.com
Ayende Rahien wrote:
> No, you are talking about different things.
> AGPL is _not_ compatible with other OSS licenses.
> _Raven_ specifically allows that.
That's what I meant. On http://www.ravendb.net/licensing your are
> No, you are talking about different things.
> AGPL is _not_ compatible with other OSS licenses.
> _Raven_ specifically allows that.
mentioning such an exception to the AGPL.
> If you build an in house application, you aren't distributing that, so
> you can use the AGPL version.
AGPL requires you to provide the source even to the users of your web app,
so you are more or less always distributing it somehow - even in-house.
But I might be nitpicking here :-)
> Technically, you application is AGPLed, but it doesn't matter, since it
> wasn't distributed.
>
> If an internal user wants the source, though, you have to give it to
> him. What is the likelihood?
Tobias
Ayende Rahien
May 19, 2010, 7:57:12 PM5/19/10
to ravendb
That is a discussion for next week, let us resolve the pricing issues before we start talking about how package the commercial version
Corey
May 19, 2010, 11:35:45 PM5/19/10
to ravendb
I think you nailed it. It's simple and reasonably priced when
applicable. Somehow I think all the licensing drama was an evil plot
to demonstrate to the community your ability to listen to their
concerns.
applicable. Somehow I think all the licensing drama was an evil plot
to demonstrate to the community your ability to listen to their
concerns.
Ayende Rahien
May 19, 2010, 11:53:41 PM5/19/10
to ravendb
If I was planning that, I wouldn't do it on the same day I was doing a course, trust me.
Josh Schwartzberg
May 20, 2010, 12:35:47 AM5/20/10
to ravendb
Maybe it's just how I interpret the language, but "non-commercial
closed source project" part does not make me think I could apply for a
free license for my "for-profit" company's internal application that I
spoke about earlier. Maybe some kind of persona driven bullet list
of who can get a free license?
Naive example:
Qualifies for a free 2-user license:
-Internal ticket system at your Fortune 500 company
etc.
etc.
Must purchase a license:
-Your SAS dotcom CRM solution
etc.
etc.
closed source project" part does not make me think I could apply for a
free license for my "for-profit" company's internal application that I
spoke about earlier. Maybe some kind of persona driven bullet list
of who can get a free license?
Naive example:
Qualifies for a free 2-user license:
-Internal ticket system at your Fortune 500 company
etc.
etc.
Must purchase a license:
-Your SAS dotcom CRM solution
etc.
etc.
Karloff
May 20, 2010, 1:26:24 AM5/20/10
to ravendb
Well there you go!
Now I see that a 16 node perpetual license wont cost an arm and a leg,
I know that contributions can or will be honored in a fair way, and I
feel comfortable continuing to invest time learning or extending
RavenDB.
Now let's get back to the product itself ;-)
Karl
Now I see that a 16 node perpetual license wont cost an arm and a leg,
I know that contributions can or will be honored in a fair way, and I
feel comfortable continuing to invest time learning or extending
RavenDB.
Now let's get back to the product itself ;-)
Karl
Ayende Rahien
May 20, 2010, 2:34:57 AM5/20/10
to ravendb
Internal applications can use the OSS version.
If you are a fortune 500 company, i think we can agree that you can pay a license
Yes, I know all about internal purchase gates and the pain of going through them.
Ayende Rahien
May 20, 2010, 2:35:04 AM5/20/10
to ravendb
Yes, please!
Brandon
May 20, 2010, 11:40:10 AM5/20/10
to ravendb
Eric, I disagree. The source code is open. If I wanted to steal the
software, why would I pay anything?
Here's an enlightening blog post from the Peldi, the CEO of Balsamiq:
<a href="http://www.balsamiq.com/blog/?p=382">http://www.balsamiq.com/
blog/?p=382</a>. He makes the case that criminals are always going to
be better than you, so why worry about them? They'll get around the
system. Like him, I'm not against licenses or validation or
activation. But you have to ask, how much business will you lose with
the extra cost? Maybe it would be better to focus on attracting more
people who would pay if the price was lower.
Not to sound like I hate giving you money. :-) You deserve it, and
we can afford it either way.
Different subject... Ayende, when you say "999 USD / instance / year",
do you mean "developer" instead of "instance"? And is there still
renewal pricing available?
Brandon
software, why would I pay anything?
Here's an enlightening blog post from the Peldi, the CEO of Balsamiq:
<a href="http://www.balsamiq.com/blog/?p=382">http://www.balsamiq.com/
blog/?p=382</a>. He makes the case that criminals are always going to
be better than you, so why worry about them? They'll get around the
system. Like him, I'm not against licenses or validation or
activation. But you have to ask, how much business will you lose with
the extra cost? Maybe it would be better to focus on attracting more
people who would pay if the price was lower.
Not to sound like I hate giving you money. :-) You deserve it, and
we can afford it either way.
Different subject... Ayende, when you say "999 USD / instance / year",
do you mean "developer" instead of "instance"? And is there still
renewal pricing available?
Brandon
Markus Zywitza
May 20, 2010, 12:18:12 PM5/20/10
to rav...@googlegroups.com
2010/5/20 Ayende Rahien <aye...@ayende.com>
Yes, the OSS version _can_ be use in house commercially.
If you intentionally want that, it might be good when this is stated explicitly in the license. We had similar issues in the company I work for.
A lawyer specialized on software licensing argued that the viral characteristic of GPL requires you to disclose the source code of a application that uses an GPL-library as a derivative work.He also argued that the the code must not only be disclosed to the users of the application, but also to the public.
According to this, I couldn't use RavenDB for inhouse development, as I must not disclose the code to the public due to orders from my superiors.
As for the commercial version, I'd have the company buy it, but I fear I don't get the budget until I have proven that RavenDB is better suited for our applications than MSSQL+NH.
-Markus
Eric J. Smith
May 20, 2010, 12:54:23 PM5/20/10
to ravendb
That's a good point. I do not have any experience in dual licensed
software. :-)
software. :-)
Ayende Rahien
May 20, 2010, 1:22:53 PM5/20/10
to rav...@googlegroups.com
Brandon,
Yes, 999 is per dev / year (how many typos in one line) ?
And yes, there will be a discount.
I think that the worried isn't be someone stealing it, but by buying one license and then not buying more.
Not from evil intent, but because it just happens that no one thought about that.
Ayende Rahien
May 20, 2010, 1:25:34 PM5/20/10
to rav...@googlegroups.com
Your lawyer doesn't know much, then.
The GPL is actually very clear about that, if you have the binaries, you should also have the code.
If you don't have the binaries, you have no leg to stand on when you want to get the code.
AGPL extends that by saying that if you have the binaries or can access the software over the network.
If you build a Raven based system internally, if I can't access it over the net, I don't have the right to ask for the source.
jdn
May 20, 2010, 9:35:47 PM5/20/10
to ravendb
> If you build a Raven based system internally, if I can't access it over the
> net, I don't have the right to ask for the source.
Can you clarify this a bit?
> net, I don't have the right to ask for the source.
If I develop an internal corporate app, it will typically be accessed
by remote offices going through a whole bunch of nifty firewall
rules. So, it will be 'accessed over the net' but not accessible to
the whole public WWW thing.
How does that scenario play out for licensing and asking for source,
yada yada yada?
jdn
Markus Zywitza
May 21, 2010, 12:52:38 AM5/21/10
to rav...@googlegroups.com
You are right. I just found it here
Thanks for the head-up.
-Markus
2010/5/20 Ayende Rahien <aye...@ayende.com>
Ayende Rahien
May 21, 2010, 3:49:56 AM5/21/10
to rav...@googlegroups.com
We have to define what we mean here, in two different aspects.
I am going to use somewhat loosey definitions here, but it should make the point.
A user of the app has access to the app. That is much easier to follow than talking about network access.
If your application is open to the public (even if it is just a login page), then you should make the code public under the AGPL.
If your application can only be used on the internal network, you DON'T have to make the code public.
_However..._ the code is still under the AGPL, and if any of the users (the people who actually have access to the system) request the source code, you are required to give it to them under the AGPL.
If _I_, as someone who doesn't have access to the application, asks to get the source, you are _NOT_ required to give it to me and are fully entitled to tell me to take a short jump.
Keith
May 25, 2010, 7:11:57 PM5/25/10
to ravendb
hmmmm,
seems to me, Raven is an Open Source (with a commercial option)
document database for the .NET/Windows platform
should be :-
Raven is an Commercial (with a open source option) document database
for the .NET/Windows platform.
seems like "Open Source" is more marketing for what essentially is a
commercial product? With open source to allow people to help improve
the commercial product offering :-)
I dunno, maybe its just me, but something feels a bit off. ( not
to take anything away from the product itself! )
Ayende Rahien
May 25, 2010, 7:21:23 PM5/25/10
to rav...@googlegroups.com
I had this argument several times already.
Raven is OSS, you are perfectly free to use it in under the OSS license commercially. You just have the follow the terms of the license
Most people would rather pay than follow the terms of the license for commercial software.
That doesn't means it isn't OSS, the terminology is accurate.
Keith Nicholas
May 25, 2010, 8:04:07 PM5/25/10
to rav...@googlegroups.com
sure, its accurate :) its all completely correct! no problem with the
correctness. It is fully Open Source. 100%. You are technically
correct.
correctness. It is fully Open Source. 100%. You are technically
correct.
The .NET market segment, which you are pitching at, well, thats mostly
commercial. (not entirely....still a fair few non
commercials.....though even they may not wish to open source their
stuff)
as YOU say, most people will look at the commercial licence. Thats
why I reversed the emphasis in your opening statement.
Also why it feels a bit off.
I think people are going "Woo, cool, *Open Source* .Net NoSql
database, nice!, ooo, nice features, cool,
Linq......oh...wait.....whats this......hey....what.....I have to
pay....*feels a bit duped* still, nice product"
As you also say, you've had this argument several times, meaning the
message you are putting out there is fuzzy.
If you took something like, lets say, "Resharper", the message is
clear, we have a good product and want you to buy it. If you do free
stuff, then we will gift it to you. But the message is generally "we
are here to make money by offering you a good product".
Reply all
Reply to author
Forward
0 new messages