> On Tue, Oct 10, 2000 at 06:01:16PM -0400, Dan Sugalski wrote:
>> "General consensus" is best, but that can't be guaranteed. "Consensus of
>> the ruling council" is more attainable, but there's that whole "ruling
>> council" thing to contend with. "What Larry says" is best, but what
> happens
>> if he doesn't, or gets hit by a bus at some point?
>
> I'd be happy with "what the project manager says". We trust the project
> manager to be able to gauge "general consensus" and decide what's best for
> Perl. It gives us a "what Larry says" style polity without the sacred cow.
>
> And if the project manager goes mad (in the case of Nat, more mad :) and we
> have to shoot him, then Larry should do that. And if Larry gets bussed, look
> around at other open source projects and see what happens when the
> maintainer's unmaintainable - people either stick it out, or fork.
I think open source has all this built in. If you go nuts, Dan,
someone with authority pulls your commit access. If I think you're
not nuts, then you and I go off and fork our own perl (you get to do
most of the work). The better development effort wins.
I repeat my suggestion from a couple of days ago that someone author
a document on "how to politely fork your own development effort,"
something akin to the discussion on the subject from Karl Fogel's
_Open Source Development With CVS_, but tailored to the Perl scene.
It should be entirely possible for a person to politely start his own
development on a P*rl-compatible interpreter (or even a spec) and
invite developers to participate on his project without abandoning the
real one. (In reality, I think we all know it's usually a little
different, but it's possible in theory, at least.) Such a document,
while hopefully never needed, would help remind everyone that Perl
really does depend on the will of the community (and always has and
always will).
jdb
