Hei,
Vadim Belman said:
>
> First, such conflict-based forks cause harm to project reputation.
>
> Second, it confuses potential supporters and this could reduce project
> funding.
>
> Third, developers would get separated between projects. Depending on how
> many would leave the original product, the pace of development of both
> could be slowed down by a factor of 2 or even more.
These are useful perspectives to learn from Rust's recent debacle, but I
think we can learn a few more.
For example:
1. Having a clear an unambiguous governance model is incredibly important
when shit hits the fan.
2. This governance model should spell out clearly what responsibilies and
mandate each governance role or institution has, and how (if at all) they
relate to other parts of the community and governance structures. This is
to reduce the usefulness of "back channel" decisions processes.
3. Corporate stewadship and influence can be very damaging, especially if
it is at odds with community sentiment. So in this sense, it's probably a
good idea to have processes in place that reduces unduly influence.
So in this regard, I'm thinking it would be useful to have another
iteration on Raku's governance documents, to see if they can improved
somehow.
A good constitution (governance documents, charters or codes) help resolve
conflicts quickly and without any fuzz or discussion or media involvement.
- Salve
--
#!/usr/bin/env perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.# <s...@foo.no>
'3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}"; __END__ is near! :)
