Re: Who owns the GSL?

[Mark Galassi <rosalia at galassi dot org>]

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.