That's entirely backwards, to reduce the bus factor, you need more people maintaining less, not fewer people maintaining more.
In any case, the incentives are simply not there, as different projects have very different priorities (which is why there are so many projects). Some folks want to monetize their special sauce (Plotly). Some folks want to focus on high level statistical charting (Altair, Chartify) Some folks want to focus on interactive data exploration (Holoviews) Some folks want to focus on high performance and streaming (Bokeh) Some folks want to focus on high quality static image generation (MPL). The human and economical cost of getting all those groups under one tent is astronomical.
> you need more people maintaining less, not fewer people maintaining more
I see how you got confused, but I was making two separate assertions.
Assertion 1: If you merge the library projects together, and strip out the redundancies between them, then you'll have the same number of contributors, now distributed over fewer total lines of code. So each contributor can learn more of the codebase. (Bus factor goes up.)
Assertion 2: If you refactor the resulting libraries to reduce the total complexity (i.e. reduce the API surface from that of the union of all the merged-in libs), then you can begin to strip out technical debt from the project from the outside in. By eliminating now-dead code, you remove places where bugs can arise, and you lower the number of dependencies (which could otherwise have been sources of API-breaking changes when they update.) Thus, the number of people needed to maintain the project goes down. So the same total functionality can then be maintained by fewer contributors. (You don't actually remove contributors; they just become reserve capacity, with each contributor able to be less-overworked for the same result.)
Alas, it's not so simple. How much actual overlap is there to merge in Bokeh and Matplotlib, for instance? MPL renders images in Python and has no JS component. Bokeh does all of its rendering in JavaScript! The Python API is mostly just a thin wrapper around BokehJS. MPL has no server component at all. Neither of the does what Datashader does for large data sets. Neither of them has a high level statistical charting API, that's only in Seaborn or Chartify. Merging all these things together would cost a fortune in time and money, and at the end of the day not actually reduce the total codesize to any appreciable degree.
5+ years and 321 contributors later, I can state that Bokeh was not easy to write. Fairly sure MPL and Plotly devs would disagree with this assessment as well.
Python has a multitude of vis systems because there are multiple use-cases, sometimes overlapping and sometimes not, and different people prioritize these very differently (and that's OK).
I definitely empathize. It's a technically challenging problem, there are lots of competing important priorities, and we are a small team that can only humanly accomplish so much work at once. Our vision for Bokeh was to be able to create and share interactive data applications with a minimum of python and little-to-no JS and "web tech" required. We are closing in on that vision, so it is my fervent hope (and intention) that we'll be able to turn to this important priority soon as well.
FYI it's really dead simple to write new "bokeh" command line tools as Bokeh apps now. We already have several ("bokeh html" and "bokeh json") but we are definitely interested in make a gnuplot-like bokeh command line tool that you can just point at a CSV or log file and get a visualization right out. E.g. something like "bokeh graph foo.log -x time -y connections --tail" would create an automatically updating visualization of a growing log file. Or if anyone is interested in this functionality and wants to help speed along the development, please let us know!
I wrote most of the docs, and my default day-to-day python is Python 3, so it's really just a matter of forgetting that "Python 3 ready" is something still needs to be mentioned at all. In fact we even have a python 3 only feature at the moment (python->JS compilation) But yes, just to clarify our CI tests run on python 2.7, 3.4 and 3.5
If you are looking for an open-souce plot library that works from JS, python, scala (and potentially driven from any language) you should check out Bokeh. http://bokeh.pydata.org
The current zoom tool is a scroll wheel zoom, not a box selection zoom. Guessing that might be the issue since others have run into the ambiguous description as well. It will be labeled more precisely in master in a few days and in the next release as well.
If that is not the issue, please file a ticket on GitHub!
Do you have the tool selected in the toolbar above? If so, please file a ticket on GH about this. Most of the Bokeh devs are on OSX so it would surprise me if it does not work on OSX, but if there is a bug we want to fix it!
There are already some tools available, pan and wheel zoom, plot resizing, selection (on some plot types). Many more tool types are planned.
As for the architecture, BokehJS is built entirely on top of HTML canvas. The python bokeh library sends data and plot specifications to the browser, which uses BokehJS to render the plot and handle interactive tools, etc.
In any case, the incentives are simply not there, as different projects have very different priorities (which is why there are so many projects). Some folks want to monetize their special sauce (Plotly). Some folks want to focus on high level statistical charting (Altair, Chartify) Some folks want to focus on interactive data exploration (Holoviews) Some folks want to focus on high performance and streaming (Bokeh) Some folks want to focus on high quality static image generation (MPL). The human and economical cost of getting all those groups under one tent is astronomical.