Christian wrote:
> >Vollunteer project can be just as resistant to innovation as any company,and
> >it can be worse.
+1
> I am having trouble imagining a scenario like this.
I think _Ruby_ falls into that class.
Debian is a borderline example. It literally saves itself by
a) Having everything documented.
b) Reaches out with _good_ communication practices.
c) Makes everything clear.
d) History are not deleted.
e) There are no "unwritten rules".
It has a simple, but overriding prime directive: "We shall release no
software before its time."
> > And that there are other coersive factors at play (e.g. "if I don't like
> > you I won't give you CVS access").
> Some people shouldn't have CVS access.
That was an example.
> >they can stiffle innovation beyond the worst companies.
> I suppose, in theory, this could be true, but I have not seen any examples of
> such blocks on innovation in any FLOSS projects that I have been active in.
a) There are 10 000 or so FLOSS projects. Figure out the percentage
that you have been involved.
b) Look at the history of Linux. Specifically look at why the
various early distribution forks were created.
c) Look at the history of BSD. Specifically look at the makeup of the
various current forks.
>Projects that stifle innovation most certainly will die.
If it is FLOSS, it forks, and the parent _might_, but probably won't die.
> If a volunteer is unhappy, they just might go and create a
separate project to challenge the main projects,
For documentation, or something similar, that is easy to do.
for an L10N project, that is not so easy to do. [There are some
excellent reasons why an L10N project should not affiliate itself with
OpenOffice.org, but fork OOo as part of the L10N project.]
>then use that influence to come back and try to gain a voice in the
main project.
Very few volunteers will do that. They will either find a different
project, or fork the existing one.
xan
jonathon
--
A Fork requires:
Seven systems with:
1+ GHz Processors
2+ GB RAM
0.25 TB Hard drive space
