| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
As a new Gentoo developer but with a little experience of management of |
| 5 |
open projects, here is my opinion on the subject. |
| 6 |
|
| 7 |
|
| 8 |
1- On NFP |
| 9 |
- --------- |
| 10 |
|
| 11 |
I was still recently a member of Gentoo user base, and I think what the |
| 12 |
user base wants is be sure Gentoo will be there tomorrow and will be |
| 13 |
free (as in beer and as in freedom). The average user probably also |
| 14 |
wants to have more leverage on the direction it's heading. The developer |
| 15 |
wants to make sure his work will not be stolen by a dark corporate |
| 16 |
conspiracy and will remain free. |
| 17 |
|
| 18 |
My experience shows that true democracy in open projects is not viable. |
| 19 |
When truly implemented, it's an illusion or/and a innovation killer. |
| 20 |
Resources are limited, choices must be made, conflicts must be resolved, |
| 21 |
someone must have final word. Management is a vertical thing, not an |
| 22 |
horizontal one. There must be a benevolent dictator or a small group of |
| 23 |
managers. That doesn't seem right, but it's the only effective way. What |
| 24 |
if the manager(s) does not follow the will of the community ? What if he |
| 25 |
becomes a bad dictator, oppressing his people ? The open source |
| 26 |
ecosystem has its answer : the project can be forked. The current lead |
| 27 |
should do his best to avoid that, change his views, step down and let |
| 28 |
another lead take over. But there always is this ultimate solution. It's |
| 29 |
a painful process but ultimately the community will choose. They will |
| 30 |
vote with their feet. |
| 31 |
|
| 32 |
So I think the best is a closed model. Since it's more or less the way |
| 33 |
it works for now, I think the community can accept it. As long as the |
| 34 |
the main goal ('forever free') is clearly built-in. |
| 35 |
|
| 36 |
A lot of devs are here because they love Gentoo's way : technical |
| 37 |
issues, not political issues. A lot of devs will leave (and are leaving) |
| 38 |
if political issues take over. It's the midlife management crisis for |
| 39 |
the Gentoo project, we won't go through unaffected. But hopefully we |
| 40 |
will go through stronger and more effective. |
| 41 |
|
| 42 |
|
| 43 |
2- On Gentoo |
| 44 |
- ------------ |
| 45 |
|
| 46 |
Gentoo is a lot of things. To ensure that the open source ecosystem can |
| 47 |
be applied to it, we must consider them separately. Each could have its |
| 48 |
own lead and fork possibility : |
| 49 |
|
| 50 |
- - Gentoo is portage |
| 51 |
The portage technology is the core of the Gentoo system. It's difficult |
| 52 |
to change without changing the ebuild tree, but could be changed. |
| 53 |
|
| 54 |
- - Gentoo is a tree of packages using portage |
| 55 |
The official portage tree with its arches, ebuilds, stable keywords. |
| 56 |
Alternative/additional portage trees can exist. |
| 57 |
|
| 58 |
- - Gentoo is a distribution using the portage tree |
| 59 |
A distribution is a little more than a package tree : it has releases, |
| 60 |
security updates, installation ISOs, a mirror network... Closely related |
| 61 |
to the precedent, but could be separated from it. |
| 62 |
|
| 63 |
- - Gentoo is a helpful community using the distribution |
| 64 |
The forums and the mailing-lists are also what makes Gentoo a success. A |
| 65 |
lot of users of others distributions find the Gentoo forums more useful |
| 66 |
than their own dist forums. A fork at community level is probably not |
| 67 |
possible. |
| 68 |
|
| 69 |
Should a single NFP cover the whole thing ? Or should you have a portage |
| 70 |
open source project, a tree+distribution NFP, and a community with its |
| 71 |
own hierarchy of moderators ? |
| 72 |
|
| 73 |
|
| 74 |
3- on Coop |
| 75 |
- ---------- |
| 76 |
|
| 77 |
I think the coop idea is very interesting and innovative. But I also |
| 78 |
think it can easily be separated from the NFP/Management issues. The |
| 79 |
coop(s) decide where money is spent. The university-driven coop(s) can |
| 80 |
fund a particular developer if they want his particular work to advance |
| 81 |
full-time. The coop(s) don't have to have the same lead as the NFP(s). |
| 82 |
If they don't like the way it goes, they can just cut the money flow and |
| 83 |
induce a fork by funding a parallel project. Vote using their wallet. |
| 84 |
|
| 85 |
|
| 86 |
Conclusion |
| 87 |
- ---------- |
| 88 |
|
| 89 |
I think we can have a global solution with a distribution (under one or |
| 90 |
several NFP projects with closed leadership), a community not directly |
| 91 |
depending on the distribution (that can choose with their feet between |
| 92 |
forks) and separate coop(s) (that can influence where it goes by using |
| 93 |
its money). I think I rephrase what klieber already said, but I like to |
| 94 |
be verbose, despite my bad English :) |
| 95 |
|
| 96 |
|
| 97 |
- -- |
| 98 |
Thierry Carrez |
| 99 |
koon@g.o -- Gentoo Security project |
| 100 |
-----BEGIN PGP SIGNATURE----- |
| 101 |
Version: GnuPG v1.2.3 (GNU/Linux) |
| 102 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
| 103 |
|
| 104 |
iD8DBQFAfUpyvcL1obalX08RAiu3AKCs9XCOKnNyMAhW2jrY7vAnX+5OWwCfSBEo |
| 105 |
/oBS3oCBAy0DgE3uUdJyqAE= |
| 106 |
=iM66 |
| 107 |
-----END PGP SIGNATURE----- |
| 108 |
|
| 109 |
-- |
| 110 |
gentoo-nfp@g.o mailing list |
Archives