Re: Who owns the GSL?

Re: Who owns the GSL?

[Diego Saravia]

I am really happy with GSL
I needed something like it, and wow ... I have it.
The people here are nice too,  I get good answers to some stupid
questions, so I learn a lot.

Perhaps Mr Tisdale have a point, but I think that are better ways to
speak about it.
Thanks to all GSL people!!!
Sorry for my english.

> Who owns the GSL?
> Who makes the design decisions?
> Who decides what is included in the GSL distribution?
> 
> The VSIPL API standard is owned be the VSIPL Forum.
> Just about anybody can participate in the VSIPL Forum.
> All you really need to do is show up at two consecutive meetings.
> Everybody who shows up at meetings of the VSIPL Forum
> is allowed to participate in the discussion.
> Decisions are made by a simple show of hands
> after a motion is made and seconded.
> The protocol is very democratic.
> 
> What is the protocol for decision making for the GSL?
> Are we just supposed to bully Brian Gough
> into including our ideas and contributions?
> I thought that the GSL was supposed to be open.
> Shouldn't there be a democratic process
> whereby application programmers and library developers
> can participate in design and development decisions?
> 
> 

--
Diego Saravia
dsa@unsa.edu.ar

Re: Who owns the GSL?

[E. Robert Tisdale]

Mark Galassi wrote:

> The GSL team follows pretty common GNU practices
> in developing the software.

I'm familiar with the stone soup model of software development.

> The people who contribute the software decide what to write.
> There are two loosely defined classes of people who contribute code:
> maintainers and occasional contributors.
> 
> The maintainers typically define the interfaces,
> and when they accept contributions from occasional contributors,
> they might change the interface to match their own idiom.
> 
> If a contributor cannot convince the maintainers
> to make a change to the API that will probably be
> because of a difference in goals.
> It might also be because the maintainers
> have become unreasonable and untractable.
> In the case of core GNU projects (emacs, gcc, gdb, guile...),
> there can be another reason to reject code:
> they require copyright assignment papers.
> GSL does not require copyright assignment.
> 
> This mechanism is self-correcting in many ways:
> if the maintainers become unreasonable and intractable,
> that is good grounds for a fork,
> where someone else takes the code base and develops it from there.
> If it is a difference in goals (like: someone wants to follow
> some kind of standards-body-based standard
> and the maintainers follow another),
> then a dialog with the maintainers is possible
> and wrappers could be used.
> 
> The GNU coding standards say that
> if standard APIs exist they should be followed.
> We started GSL in a climate where no standards existed.
> We spent a lot of time thinking about requirements and APIs
> before coding, and continued to rethink these requirements and APIs
> as the project progressed.
> 
> Ultimately the success of free software projects
> depends on the responsiveness and sensitivity of the maintainer(s).
> I have not yet seen useful input turned down,
> so I think our approach is working well.
> 
> What I described here is not a set of rules:
> it's just the phenomenology of what I have seen happen.

Developing a library like the GSL is different
from developing an application like emacs.
You have complete control over the [emacs] application source code
and you can makes changes as you see fit.
But when you are developing a library for other programmers to use
you only have control over the library source code and
you usually have no control at all over their application source code.
The library API is a contract between you the library developer
and the application programmers who use your library.
You can't change the API without breaking your contract with them.

You say that you spent a lot of time thinking about requirements and APIs
but there is no evidence of that thinking.  You didn't document it.
No rationale has ever been articulated for your design decisions.
The API unnecessarily exposes details of the data representation
and implementation to the numerical application programmer
which appears to indicate that you haven't considered
the possibility of alternate implementations.
Experienced and savvy numerical application programmers must conclude
that it is highly unlikely that the GSL team will be able to support
their API for very long and that the GSL API must change
in order to accommodate better implementations.
This means, of course, that they will be obliged to change
all of their existing numerical application source code
so that it will be compatible with new releases of the GSL.

If you really want numerical application programmers to use the GSL API,
then you should invite them to participate in the design of the GSL API.
Personally, I think that the GSL API design should be changed
to be more compatible with the VSIPL API standard.
The VSIPL API standard represents the collective wisdom
of some of the best experts in numerical computing today.
I think that GSL vector and matrix views should be more like
one and two dimensional Fortran 90 arrays --
they should support arbitrary strides
and all of the arithmetic operations
that are defined on Fortran 90 arrays.

Re: Who owns the GSL?

[Mark Galassi]

The GSL team follows pretty common GNU practices in developing the
software.

The people who contribute the software decide what to write.  There
are two loosely defined classes of people who contribute code:
maintainers and occasional contributors.

The maintainers typically define the interfaces, and when they accept
contributions from occasional contributors they might change the
interface to match their own idiom.

If a contributor cannot convince the maintainers to make a change to
the API that will probably be because of a difference in goals.  It
might also be because the maintainers have become unreasonable and
untractable.  In the case of core GNU projects (emacs, gcc, gdb,
guile...) there can be another reason to reject code: they require
copyright assignment papers.  GSL does not require copyright
assignment.

This mechanism is self-correcting in many ways: if the maintainers
become unreasonable and intractable, that is good grounds for a fork,
where someone else takes the code base and develops it from there.  If
it is a difference in goals (like: someone wants to follow some kind
of standards-body-based standard and the maintainers follow another),
then a dialog with the maintainers is possible and wrappers could be
used.

The GNU coding standards say that if standard APIs exist they should
be followed.  We started GSL in a climate where no standards existed.
We spent a lot of time thinking about requirements and APIs before
coding, and continued to rethink these requirements and APIs as the
project progressed.

Ultimately the success of free software projects depends on the
responsiveness and sensitivity of the maintainer(s).  I have not yet
seen useful input turned down, so I think our approach is working
well.

What I described here is not a set of rules: it's just the
phenomenology of what I have seen happen.

Who owns the GSL?

[E. Robert Tisdale]

Who owns the GSL?
Who makes the design decisions?
Who decides what is included in the GSL distribution?

The VSIPL API standard is owned be the VSIPL Forum.
Just about anybody can participate in the VSIPL Forum.
All you really need to do is show up at two consecutive meetings.
Everybody who shows up at meetings of the VSIPL Forum
is allowed to participate in the discussion.
Decisions are made by a simple show of hands
after a motion is made and seconded.
The protocol is very democratic.

What is the protocol for decision making for the GSL?
Are we just supposed to bully Brian Gough
into including our ideas and contributions?
I thought that the GSL was supposed to be open.
Shouldn't there be a democratic process
whereby application programmers and library developers
can participate in design and development decisions?