Polychart.js: An Interactive Charting Library
polychartjs.com
polychartjs.com
The charting space by contrast seems significantly bloated to me. This library may well be awesome, but I'd recommend you explain within my first minute or two on the page why this is better than the host of free options out there.
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
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.
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.
It looks really nice, though, definitely good job.
It's free, and I don't see many features added that flotr2 doesn't have.
I still cant see how this would justify a $300 price tag, but perhaps its the FOSS philosophy taking over.
I dunno. I prefer to release anything I deem worthy of ridicule by the FOSS community under wtfpl. Power to the people!
$ curl -I https://raw.github.com/Polychart/polychart2/develop/polychart2.standalone.js
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
While this new one does offer interaction between charts, that wouldn't be too hard to add into other existing free projects that have event systems to hook into.
I'd say $50 - $99 would make it more worthwhile.
Alternatives to Raphael is d3.
Alternatives all together is NVD3. If you haven't seen this one, go check it out.
We share your love with d3 also, which unfortunately will not ever work in IE. So until the rest of the world catches up... ;)
There are ways to turn d3's SVG output into a canvas element. Those earlier version of IE also support VML, but I don't recall any quick ways of doing from d3 output to VML off the top of my head.
Polychart.js can now be licensed under a per-domain or per-company license. We continue to offer discounts to startups (as we're one ourself!)
Otherwise, why wouldn't people simply buy 1 license and have as many developers as needed work on the codebase?
It seems like this feature is the most overlooked, and it is one of their strongest selling points. As you mouse along the chart regardless of your y axis it has guides that will show the datapoint tooltip information closest to your x axis if you have a line selected or have mouseover'd a line.
Your charting library is however well thought out, there are a few features that I would be interested in seeing from morris.js and rickshaw.
If I had to pick, I'd go with Vega because I think it has the most potential to develop a community around it. Especially as a bridge between Python/R and D3.js through JSON. Think iPython notebooks, R Shiny, etc.
None have become as popular as d3.js though, so it's still hard to compare them.
What you get when you buy a license is support. Which I remember was the main reason we had for not choosing NVD3 last time, and went with a library with much better documentation.
(do agree with other comments that per-dev pricing is a bad model, though)