I will pay for an awesome charting product, but I don't want to have to think about how many developers will touch the code, when, how or why.

Something like a license per production site or an unlimited license makes a whole lot more sense to me and allows me to quantify the cost in terms of the value it provides to my business rather than how many developers I have.

Hasn't commercial software been licensed effectively per-user since forever? It used to be per-machine but these days with lots of developers using a desktop and a laptop I think it makes sense to say it's for one user at a time instead and avoid creating lots of silly infringements.

If you don't like anything resembling that form of licensing, perhaps you're projecting a preference for everything-should-be-free culture onto commercial development where someone has to pay the bills? Unfortunately, sometimes that just doesn't work.

Having a per-user or per-machine licence where the licence is not transferrable seems crazy to me, though. We consider such licensing conditions toxic, because all it takes is someone to leave or a hard drive to crash and you've lost your investment, so usually seeing that will end our interest immediately.

(For completeness: We will make a grudging exception for software that is essential to our business and can't be had any other legal way or replaced with any better alternative. However, you don't buy software like that with a quick web site download anyway, and if we get screwed on that kind of deal lawyers are involved. Obviously a charting library is nowhere near this level, though.)

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.

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.

Generally pricing isn't particularly challenging, people exchange money for perceived value so identify the value that you add and charge for that.

So places where you might be adding value;

developer training - A common source of value and one which a lot of non-community FOSS members appreciate. So folks who aren't part of the community or know much about anything find it valuable to have someone who will answer their stupid questions in a timely fashion without insulting them. That could certainly be charged on a per-developer level and annually.

data-hoisting - (see what I did there? clever huh?) basically there is value in getting your data from X hosted on Y. So lets say I periodically scrape all of the stock prices for the DJIA and want to provide an interactive chart for that. A data hoisting service would provide a repository for post-processed and chart friendly data. You can price that with visualization support almost on a contract basis.

custom visualizations - there will be people of course who want to visualize something in a way which is unique, consulting services for them can be quite valuable.

ad-sponsored charts - something between hoisting and foisting but there are charts that people "check" very often (like the 5 day weather forecast, or the traffic delays on various freeways). You can certainly create pages which display visualizations of these and also are "sponsored" by an advertiser. The trades of bit coins for example, rent prices by zip codes, basically changing data sets of interest to both a number of people and to people who would like to advertise to people interested in that data.

EDIT: if you host it for a personal/non-profit project it is free according to Creative Commons Attribution-NonCommercial License

another product we've used in the past is Amcharts, good buy maybe not good as Highcharts