1 |
On 01/11/2017 12:03 PM, Michael Palimaka wrote: |
2 |
> There has been a lot of debate recently regarding Gentoo’s |
3 |
> metastructure. In response to this, there have been various proposals |
4 |
> for reform. These other proposals appear to be focused on changing the |
5 |
> way Gentoo operates to conform with a traditional corporate structure. |
6 |
> I’d like to make an alternative proposal - change the organisational |
7 |
> structure to conform with how Gentoo actually operates. |
8 |
> |
9 |
> Let’s first consider the proposed metastructure of another proposal |
10 |
> that’s currently being discussed: |
11 |
> |
12 |
> |--Council--(various projects) |
13 |
> | |
14 |
> | |--Recruiting |
15 |
> Board --+--Comrel--| |
16 |
> | |--Something else |
17 |
> | |
18 |
> |--PR |
19 |
> | |--Releng (if recognized) |
20 |
> |--Infra--| |
21 |
> |--Portage (possibly) |
22 |
> |
23 |
> This is a reasonable-looking traditional corporate structure, but Gentoo |
24 |
> is not a traditional corporation. Our primary purpose is to produce a |
25 |
> Linux distribution. The Gentoo Foundation exists to handles legal and |
26 |
> administrative matters and should serve the distribution, not the other |
27 |
> way around. |
28 |
> |
29 |
> Despite the best efforts of the Board, the Foundation has repeatedly |
30 |
> been plagued with problems such as poor record-keeping and at one point |
31 |
> even fell into bad standing. I very much appreciate the work the |
32 |
> Trustees have put in (especially in recent months to try and straighten |
33 |
> everything out), but I have serious concerns about the Foundation’s |
34 |
> long-term prospects, let alone handing them more responsibilities and power. |
35 |
> |
36 |
> Gentoo is a community-driven project lead by the Council, and we should |
37 |
> keep it that way. I therefore propose we follow the lead of other major |
38 |
> projects[0] and become associated with SPI[1], making use of their |
39 |
> various services[2] such as accepting donations, and holding funds and |
40 |
> other assets. As an associated project, Gentoo would retain its |
41 |
> independence - SPI would not own, govern, or otherwise control us. |
42 |
> |
43 |
> SPI requires an associated project to have a liaison - a person who is |
44 |
> authorised to direct SPI on behalf of the project. I propose this person |
45 |
> be a Council member, selected from a vote of all Council members. Such a |
46 |
> person must receive at least 50% of total votes and no ‘no’ votes. If |
47 |
> this process fails to result in the selection of a liaison it will go to |
48 |
> a majority vote from all developers. |
49 |
> |
50 |
> The new metastructure would look like this: |
51 |
> |
52 |
> |-- SPI liaison |
53 |
> | |
54 |
> | |
55 |
> Council -- Various projects |
56 |
> |
57 |
> |
58 |
> [0] http://www.spi-inc.org/projects/ |
59 |
> [1] http://www.spi-inc.org/ |
60 |
> [2] http://www.spi-inc.org/projects/services/ |
61 |
> |
62 |
|
63 |
I think this structure could work -- despite being dependent on an |
64 |
outside entity -- as long as our contract with SPI allows us to retain |
65 |
rights to our assets. i.e. they can't rob us blind in the event of a |
66 |
falling out or something. |
67 |
|
68 |
What really should decide this imo are the people who have been doing |
69 |
foundation work already. Ask them if they're okay with throwing away |
70 |
their work for a company to handle it for us. They're the ones most |
71 |
impacted by such a decision and deserve the most influence imo. |
72 |
-- |
73 |
Daniel Campbell - Gentoo Developer |
74 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
75 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |