Re: gnuplot needs more developers/administrators

[<tim...@en...>]

Daniel J Sebald wrote:
> I'll be tuning out from the list for now...  My thoughts are that gnupl=
ot development could use some fresh people to keep it going.  The summers=
 used to be fairly productive, but now not much happens even then.  Shoul=
d open an invitation for a few more administrators or whomever's role it =
is to sort through patches and chart a course for what needs attention.  =
One or two people doing that isn't enough on a voluntary basis.  There ar=
e plenty of ideas for new stuff (multiple keys, better 3D/2D layout and u=
se of margins, etc.).  My sense is that people are willing to contribute =
but become discouraged when patches sit on SourceForge indefinitely.  Als=
o, it might be good to review this kind of thing after each release, i.e.=
, Will another release be warranted? What new features, if any, should be=
 in a future release? Are there enough active contributors and administra=
tors to get there in the course of a year or two?
>
> Regards,
>
> Daniel
>  =20

Hi Daniel,

For what is worth, I don't think the situation is hopeless, but I=20
understand how you feel. The same happens for many open-source projects, =

apart from the most trendy ones, and it heavily depends on the history=20
of the project. For one thing, gnuplot being very old, some parts have=20
not been touched for long. gnuplot is highly portable, which is a good=20
thing but also a thing to take care of. Anyway, that's not what you=20
express here. I would personally love to review your patches if I had=20
more time, and it will hopefully happen after my examinations, i.e. next =

week. I can for sure review the history ones, but I'm afraid I won't be=20
able to understand much of the hidden3d one unless I devote a lot of=20
time to it... until now I've carefully stayed away from the graphic core =

functions in gnuplot.

As far as contributions and administration is concerned, my feeling is=20
that Ethan has been doing a great job lately. Of course, this doesn't=20
mean that he can be everywhere every time.

To me, the biggest differences between trendy projects that seem to be=20
very dynamic and gnuplot today are:

-few people have CVS commit rights, whereas the politic for kde (for=20
example) is to give commit access almost immediately after the first=20
patch. Other projects work like gnuplot, with a very small group of=20
commiters, like compiz, but the latter also has a plugin architecture,=20
and those plugins are written and modified by lots of people. Should=20
more people get CVS access to gnuplot ? Why not. Apart from you, Daniel, =

I don't see major and regular contributors that don't have CVS access.=20
Anyway, having the right to commit doesn't mean that one should commit=20
immediately anything. Staying a while on Sourceforge is a good thing, at =

least it gives the time to think about the best solution. So the real=20
question is : why aren't there more contributors ?

-gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The target =

audience is quite heavily restricted to scientists, programmers and=20
system administrators. In the scientists part, those who may be=20
interested in gnuplot are those who aren't afraid of the command-line,=20
those who are used to program or to use a shell, and those who are not=20
addicted to Matlab but to LateX. Programmers and sysadmins tend to use=20
gnuplot to plot stats and profiles, gnuplot is probably well suited for=20
those people. All in all, I think gnuplot has a small target audience,=20
and only a small subset of this audience tend to contribute.

-there are a few alternatives to gnuplot (python, ...) so not all of the =

target audience ends up using gnuplot. And that's fortunate, diversity=20
is good.

-apart from the regular command-line use case, gnuplot architecture=20
isn't that flexible. Most works to use gnuplot from another application=20
are either hacks or are not well integrated, so it's not satisfying for=20
other projects that need a plotting engine.

-gnuplot license discourages new contributors. This license obviously=20
doesn't help in protecting gnuplot today. It prevents from sharing=20
precious code with others. It results in doubt about the future of=20
gnuplot, since because of this license, gnuplot is tied to its original=20
authors, who are now completely out of the development process.

To address these problems and improve the situation, few but radical=20
changes are needed:

-make gnuplot core available as a library (including all its=20
file/printers terminals, and adapted screen terminals, so that they can=20
be used as widgets inside other apps).
It implies to disentangle the command-line parser from the routines, and =

identify a sensible API. It's a lot of work.

-contact identified contributors/rewrite parts of gnuplot to change the=20
license, to something reasonable (core LGPL, frontend GPL). This is a=20
huge lot of work, but that would definitely worth it. As far as=20
rewriting parts, it could a good time to think about external=20
libraries/tools. I'm thinking of doxygen for the help formatting,=20
flex/bison for the parser. I think we would need to distribute the jobs=20
between several of us, and slowly get them done.

I hope one day those two points will be marked as done. Most of the=20
time, this kind of threads end up being unproductive, but I hope your=20
mail and this one can help to start the process.

Best regards,

Timoth=E9e