gnu-misc-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Turning GNU into a bottom-up organization


From: Mark Wielaard
Subject: Re: Turning GNU into a bottom-up organization
Date: Tue, 22 Oct 2019 01:04:44 +0200

Hi,

On Mon, 2019-10-21 at 17:16 +0200, Félicien Pillot wrote:
> On Mon, 21 Oct 2019 17:08:33 +0200
> Mark Wielaard <address@hidden> wrote:
> > In practice GNU already is mostly a bottom-up organization, where
> > the GNU hackers that do the actual work shape the project, but it
> > would be nice to make it more formally so.
> 
> What do you suggest?

First I am probably using the wrong terminology. Second bootstrapping
something like this is probably much trickier than I anticipate.
Especially given the current GNU governance structure or non-existence
of it, depending on who you ask. But let me try to explain how GNU
would ideally look like to me. Then we can discuss how practical those 
suggestions would be.

I would like to see GNU organized in such a way that GNU volunteers,
who devote so much time and energy to GNU, will be able to grow and
become the next generation of GNU leaders through some kind of
apprenticeship. People should always be on the outlook of who could
replace them by mentoring and promoting others who show they contribute
positively the GNU way.

Various GNU project actually already work a bit like this. First you
become a contributor by submitting some trivial patches, then you add
more meaningful patches and a copyright assignment/disclaimer, when
consistently providing meaningful patches and showing you can cooperate
with other developers following the GNU way you get committer status
and can mentor others by reviewing and installing their patches, you
might become a subsystem maintainer or even a GNU (co-)maintainer and
be trusted to and responsible for writing policy for the project. The
GNU maintainers of related packages can then come together to form a
technical committee to coordinate GNU policy to make the GNU system
more consistent that others might then adopt for their packages.

One practical problem with that is of course interpreting what the GNU
way is. We all probably have a feeling of what is and isn't the GNU
way, but it is actually hard to describe the core. That is not because
we haven't documented that, but ironically because we have documented
so much :) Just look at the documents that a GNU maintainer is supposed
to interpret and decide whether or not they are applicable to their
project and/or use to write more specialized policy for their project:

Information For Maintainers of GNU Software:
  https://www.gnu.org/prep/maintain/

GNU Coding Standards:
  https://www.gnu.org/prep/standards/

For the basic ideas of GNU and Free Software:
  https://www.gnu.org/gnu/the-gnu-project.html
  https://www.gnu.org/philosophy/free-sw.html
  https://www.gnu.org/philosophy/categories.html
  https://www.gnu.org/philosophy/compromise.html
  https://www.gnu.org/philosophy/words-to-avoid.html
  https://www.gnu.org/gnu/linux-and-gnu.html
  https://www.gnu.org/gnu/gnu-linux-faq.html
  https://www.gnu.org/philosophy/open-source-misses-the-point.html

There are a lot of shoulds, but very little musts in those documents.
Which is good, because the amount of information is really a lot. And
it gives GNU maintainers a lot of freedom to implement the suggested
policies and decide what does or doesn't apply in the specific
(technical) context of a package. But it takes a lot of time to
describe the responsibilities, delegation and decision frameworks for a
package to bring in more people who can share the maintainer load. It
would be good to try to distill a small core of musts, a summary of
sorts, that can be more easily communicated as a kind of social
contract for GNU.

e.g. the free-sw definition as defined by the FSF might be seen as our
core. But some of the things in words-to-avoid are just nice to haves,
of sometimes playful ways of speech. While some things in the standards
like the requirements around usage of trademarks is again essential,
but now for legal reasons (and then there is the imho odd reference to
not using "win" in that same section, which seems more like a nice to
have again). Basically I believe we have too much information. And it
would be good to be more clear on which information is what and how
essential it is to the GNU way.

Another practical problem with this is that I can see how this works
when we narrowly define GNU as a collection of packages that form the
GNU operating system. But there are other GNU volunteers than just
developers. There are people who maintain websites, translators and
those that keep various infrastructure running, like savannah or
package specific servers and those that organize meetings and
conferences like the GNU Tools Cauldron or the GNU Hacker Meetings. And
then there are things like the GNU Education Team or packages/projects
which are kind of extensions of the core GNU operating system. I
haven't really thought how to precisely fit everybody in the bottom-up
hierarchy, which admittedly is very developer/package oriented.

Cheers,

Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]