I currently develop a powerful JavaScript diagramming library (very different capabilities than charting), and charge more than this, though its done per domain and not per developer, with exceptions for OEM customers who need to deploy it everywhere. I'd recommend you go that route instead, most of our customers seem very happy with the model.
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.
I don't understand this per-developer licensing model. Not only is it completely non-enforceable but feels really out-dated and out of touch in the era of FOSS.
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.
I don't understand this per-developer licensing model. Not only is it completely non-enforceable but feels really out-dated and out of touch in the era of FOSS.
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.)
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.
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.
Agree, I don't think per developer makes sense for this charting library but might make sense for other software. Say a text editor like Textmate or Sublime Text 2. Really, we might as well call it per user licensing.
We'll be reviewing the licensing option per feedback from HN. Please send a note to team@polychart.com, would love to hear more about what you think would be reasonable :)
Interesting question. So if I use this to display site metrics for me and my team, is that a commercial use? I'm not selling that service but in that example I would be using it to provide a visual indication of how the site is doing which helps me do my job.
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.
In a world of so many wonderful free open source graphing libraries, it's hard to see any reasonable licensing option for this. It might help if there was a page that listed features that a developer could not accomplish for $300 in flot, highcharts, or ndv3, or other popular options.
Highcharts is cheaper if you use it for a single webpage (90$) but if you want to use if for a real web app it's more expensive (590$ for a single developer).
Having said that, in my enterprise my dev colleagues use it and they think it's a great product.
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
I like the interaction layer (at least the way it's described). The per-developer pricing for this is really strange though. If I implement this in an app, it may start out as my app, and then other developers may collaborate later on, sometimes temporarily. How much would this cost? I have no idea, so I'd probably skip it entirely for any project.
Thanks fourm for the feedback! Let us know what you think would be reasonable and email team@polychart.com for a discount for HN users. (And of course, always free for non-commercial use)
Agree - Flotr2 is awesome. To be fair this library seems to offer a little more in terms of interactive charts, which I don't think FLotr2 does much (I know you can kind of get 'selection' in pie charts, but I don't know of anything else).
you can get 'selection' in bars with the mouse options. I've hacked in better functionality before; it really is not difficult. Pretty much comes down to modding the redraw on mouseclick.
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!
This looks quite awesome!
As a quick suggestion, the wiki (https://github.com/polychart/polychart2/wiki) recommends using github as the CDN which I thought was highly discouraged. However I can't find any official stance on this anymore..did it change?
Ah, that solves that :)
I've seen recommendations of using Github Pages instead, but again I can't find any official Github stance on it. I'm guessing they reserve the right to cut you off if you start using large amounts of bandwidth.
This is pretty cool, but $300 is a lot to pay, even for commercial use. There are a lot of free client-side charting projects out there. Charts.js was a recent one on HN: http://www.chartjs.org/
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.
Agrees with you that Raphael is very awesome. A difference between Polychart.js and NVD3 is its flexibility: the way one can overlay charts, or even plot any change in polar coordinates. (We took a lot of ideas from R and ggplot2, something data scientists use).
We share your love with d3 also, which unfortunately will not ever work in IE. So until the rest of the world catches up... ;)
d3 does work out of the box in IE version 9 and up. With some small modifications, you can still use d3 without even earlier versions of IE. New York Times routinely makes d3 graphics that run in even older versions of IE plus all modern browsers.
d3 produces SVG graphics, which aren't supposed by versions earlier than IE 9.
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.
False. You do not support basic guides like highcharts, you are not the most intuitive and interactive for the browser... yet.
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.
Would like to see a demo with a larger data set size (say, zoomable scatter plot with thousands of points). And an option to edit the demo in jsfiddle.
Thanks for the comment and the feedback on the pricing. Please email team@polychart.com for a discount or alternative model just for HN readers, or if you have other feedback!
It's hard to evaluate when the projects are so new. It was a similar problem with Crossfilter/Datavore/Data.js/Miso Dataset when they all came out.
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.
They are all libraries for managing datasets with fast or convenient filtering. Useful for linking visualizations together through a common data model.
None have become as popular as d3.js though, so it's still hard to compare them.
The interaction model is something that very few charting libraries have. Also we try to make Polychart.js very easy to get started in, so that creating a simple line or bar chart would take minimal amount of code. Vega is amazing as well for how flexible it is.
D3 takes ages to build graphs with. That's why NVD3 made such big news.
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.
Thanks for the feedback. We'll be reviewing the pricing model per the comments from HN. Would love to hear more on what you think would make sense :) team@polychart.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.