gnuplot development

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

Hi,

I would be interested in started developing for gnuplot, but find =20
where to start a bit daunting. Maybe some mentoring of new developers =20=

with simple targets might be a good idea. Is there some sort of =20
'introduction to gnuplot dev' docs?

Dan.


On 19 Jun 2007, at 20:45, Timoth=E9e Lecomte wrote:

> Daniel J Sebald wrote:
>> I'll be tuning out from the list for now...  My thoughts are that =20
>> gnuplot development could use some fresh people to keep it going.  =20=

>> The summers used to be fairly productive, but now not much happens =20=

>> even then.  Should open an invitation for a few more =20
>> administrators or whomever's role it is to sort through patches =20
>> and chart a course for what needs attention.  One or two people =20
>> doing that isn't enough on a voluntary basis.  There are plenty of =20=

>> ideas for new stuff (multiple keys, better 3D/2D layout and use of =20=

>> margins, etc.).  My sense is that people are willing to contribute =20=

>> but become discouraged when patches sit on SourceForge =20
>> indefinitely.  Also, it might be good to review this kind of thing =20=

>> after each release, i.e., Will another release be warranted? What =20
>> new features, if any, should be in a future release? Are there =20
>> enough active contributors and administrators to get there in the =20
>> course of a year or two?
>>
>> Regards,
>>
>> Daniel
>>
>
> Hi Daniel,
>
> For what is worth, I don't think the situation is hopeless, but I
> understand how you feel. The same happens for many open-source =20
> projects,
> apart from the most trendy ones, and it heavily depends on the history
> of the project. For one thing, gnuplot being very old, some parts have
> not been touched for long. gnuplot is highly portable, which is a good
> thing but also a thing to take care of. Anyway, that's not what you
> express here. I would personally love to review your patches if I had
> more time, and it will hopefully happen after my examinations, i.e. =20=

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

> core
> functions in gnuplot.
>
> As far as contributions and administration is concerned, my feeling is
> that Ethan has been doing a great job lately. Of course, this doesn't
> mean that he can be everywhere every time.
>
> To me, the biggest differences between trendy projects that seem to be
> very dynamic and gnuplot today are:
>
> -few people have CVS commit rights, whereas the politic for kde (for
> example) is to give commit access almost immediately after the first
> patch. Other projects work like gnuplot, with a very small group of
> commiters, like compiz, but the latter also has a plugin architecture,
> and those plugins are written and modified by lots of people. Should
> more people get CVS access to gnuplot ? Why not. Apart from you, =20
> Daniel,
> I don't see major and regular contributors that don't have CVS access.
> Anyway, having the right to commit doesn't mean that one should commit
> immediately anything. Staying a while on Sourceforge is a good =20
> thing, at
> least it gives the time to think about the best solution. So the real
> question is : why aren't there more contributors ?
>
> -gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The =20
> target
> audience is quite heavily restricted to scientists, programmers and
> system administrators. In the scientists part, those who may be
> interested in gnuplot are those who aren't afraid of the command-line,
> those who are used to program or to use a shell, and those who are not
> addicted to Matlab but to LateX. Programmers and sysadmins tend to use
> gnuplot to plot stats and profiles, gnuplot is probably well suited =20=

> for
> those people. All in all, I think gnuplot has a small target audience,
> and only a small subset of this audience tend to contribute.
>
> -there are a few alternatives to gnuplot (python, ...) so not all =20
> of the
> target audience ends up using gnuplot. And that's fortunate, diversity
> is good.
>
> -apart from the regular command-line use case, gnuplot architecture
> isn't that flexible. Most works to use gnuplot from another =20
> application
> are either hacks or are not well integrated, so it's not satisfying =20=

> for
> other projects that need a plotting engine.
>
> -gnuplot license discourages new contributors. This license obviously
> doesn't help in protecting gnuplot today. It prevents from sharing
> precious code with others. It results in doubt about the future of
> gnuplot, since because of this license, gnuplot is tied to its =20
> original
> authors, who are now completely out of the development process.
>
> To address these problems and improve the situation, few but radical
> changes are needed:
>
> -make gnuplot core available as a library (including all its
> file/printers terminals, and adapted screen terminals, so that they =20=

> can
> be used as widgets inside other apps).
> It implies to disentangle the command-line parser from the =20
> routines, and
> identify a sensible API. It's a lot of work.
>
> -contact identified contributors/rewrite parts of gnuplot to change =20=

> the
> license, to something reasonable (core LGPL, frontend GPL). This is a
> huge lot of work, but that would definitely worth it. As far as
> rewriting parts, it could a good time to think about external
> libraries/tools. I'm thinking of doxygen for the help formatting,
> flex/bison for the parser. I think we would need to distribute the =20
> jobs
> between several of us, and slowly get them done.
>
> I hope one day those two points will be marked as done. Most of the
> time, this kind of threads end up being unproductive, but I hope your
> mail and this one can help to start the process.
>
> Best regards,
>
> Timoth=E9e
>
>
> ----------------------------------------------------------------------=20=

> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gnuplot-beta mailing list
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta