4 ms·

In no way am I projecting a preference for everything should be free. I specifically said I was willing to pay, but per developer makes no sense to me at all.

In no way am I projecting a preference for everything should be free. I specifically said I was willing to pay, but per developer makes no sense to me at all. I build a commercial product myself that I charge for. My point is that per-developer licensing doesn't make sense on any level... just because "that's how people have always done it" doesn't make it a good idea and that type of pricing doesn't allow me to compare the cost to the value. Instead of thinking, this product is awesome and I can use it on my 5 sites for $X.. I have to think, ok I have 20 developers and 5 of them work on site A, 7 on site B and the rest float around so how many people would need to be developing with the library, etc etc. Right? or am I missing something here and am crazy? which is entirely possible.

Silhouette 14y ago
I agree there are certainly other models that would make sense, given that this is probably a library that's going to be incorporated as part of a larger project rather than a standalone piece of software for in-house use. It seems reasonable to have a predictable price up-front, particularly one that can be transferred to a client as part of an overall project budget if necessary. It also seems reasonable to have a more transparent level of scalability. Something like per-domain pricing might make a lot of sense as an approximation of buying it once for each project where it'll be used. I suspect a commercial project like this is mostly going to be used by larger organisations who aren't going to sneeze at real money, because there are too many good-enough alternatives for the little guys. That being the case, if you want to allow for increasing value as a project grows, you could do something like per-(public-facing)-server instead of per-developer and just make as many in-house machines as you want free. That might be awkward with cloud-based projects that activate and deactivate instances on the fly, so maybe just band it "$x for up to n public servers/instances at once", "$y for up to m public servers/instances at once", "for more servers/instances contact us for special rates". Licensing is always a mess, unfortunately. I think the best you can ever do is probably to present something that is clear in what is covered, realistic in what it costs, and reasonably consistent/predictable.

Silhouette 14y ago

I agree there are certainly other models that would make sense, given that this is probably a library that's going to be incorporated as part of a larger project rather than a standalone piece of software for in-house use. It seems reasonable to have a predictable price up-front, particularly one that can be transferred to a client as part of an overall project budget if necessary. It also seems reasonable to have a more transparent level of scalability. Something like per-domain pricing might make a lot of sense as an approximation of buying it once for each project where it'll be used. I suspect a commercial project like this is mostly going to be used by larger organisations who aren't going to sneeze at real money, because there are too many good-enough alternatives for the little guys. That being the case, if you want to allow for increasing value as a project grows, you could do something like per-(public-facing)-server instead of per-developer and just make as many in-house machines as you want free. That might be awkward with cloud-based projects that activate and deactivate instances on the fly, so maybe just band it "$x for up to n public servers/instances at once", "$y for up to m public servers/instances at once", "for more servers/instances contact us for special rates". Licensing is always a mess, unfortunately. I think the best you can ever do is probably to present something that is clear in what is covered, realistic in what it costs, and reasonably consistent/predictable.