Resolution 2009-03-16.jrk.1: OpenWRT as associated project [revised]

[Ian Jackson]

Don Armstrong writes ("Re: Resolution 2009-03-16.jrk.1: OpenWRT as associated project 	[revised]"):
> For example, if a liason is acting contrary to the wishes of a
> project, and the project reports that this is the case to SPI and
> removes the liason, but the liason reports that it is not the case and
> that the liason has not actually been removed, SPI has to resolve the
> situtation by figuring out what the wishes of the project actually
> are. This requires examining the relevant documents and the decision
> process.

Exactly.

My point is that we should not say that `Carla is recognised by SPI
the authoritative decisionmaker for the OpenWarfare project' unless we
really mean that OpenWarfare is an autocracy with Carla in charge.

Because if we say that `Carla is the authoritative decisionmaker for
OpenWarfare' then we are saying that when half a dozen contributors to
OpenWarfare email us to point out that she's gone off on a bender, we
will honour her decisions (regarding assets held for OpenWarfare)
rather than theirs.  After all that's what `authoritative
decisionmaker' means.  Carla's opponents will have to start their own
fork.

Whereas if we say `we recognise the OpenWarfare Founding Declaration
(attached) as the governing instrument for OpenWarfare and Carla will
be our liason', then when David, Elspeth, Fred et al email us to tell
us Carla has gone mad, we will look at the document and the mailing
lists and so forth (or whatever) to decide who to believe.

> I believe that the cases of this happening should be very
> extraordinary, but they certainly can happen, and the agreement
> between the project and SPI should account for them.

Absolutely.


As an aside:

Note that there isn't necessarily anything wrong with autocracy as a
governance model for a free software project.  For a small project -
where those who might disagree with the autocrat can easily fork (thus
establishing a competing governance as well as a competing codebase) -
it can often be very efficient and straightforward.

When a project becomes large enough that it is very difficult to fork
(or perhaps it is difficult to fork for other reasons), it is more
important that users and developers can effectively exercise their
freedoms _within_ the project's governance structures rather than just
by opting out.

Ian.