Re: Who owns the GSL?

["E. Robert Tisdale" <edwin at netwood dot net>]

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.