It’s fun to speculate “what if” on all the radical changes I’d want to make, but really, if I suddenly became pumpking, my first thought would probably be “Oh, sh*t… I better not f*ck this up!”
What If I released a horribly broken Perl? Do I want to be known as “worst pumpking EVAR!”? Do I want that hanging over my head for all time? Do I want to go to a Perl event and be pointed out to newbies as “the guy who screwed up Perl”? Do I want it on Wikipedia or Yahoo or Google when I apply for jobs? Hell, no!
But I’m not pumpking and so I advocate for change and faster progress. Still, I have a lot of empathy for the reality of the situation that pumpkings are in. ((Volunteered to be in, no less)) I think it’s a situation that is probably unavoidable when one individual signs up to be accountable for the success or failure of a large, public project.
I think the answer – to the extent there is one – is that Perl needs to find ways to spread the potential blame beyond a single figurehead and also lower the public penalty for failure.
That means fragmenting accountabilities in constructive ways that don’t jeopardize overall progress. It means having more explicit sandboxes for experimentation. It means taking smaller steps. It means having better risk management. And, frankly, I think it means having better management as a whole.
That’s hard to contemplate for a consensus-driven community of volunteers. But I think it’s a necessary step to achieve what appear to be some consensus goals. I’m not saying we need a constitutional convention (though it’s an interesting thought exercise), but I think the current model passed a tipping point long ago.
In some future posts, I’m going to come back to these themes from a number of angles and try to put some structure around what I see as the fundamental issues and options. While I don’t think there should be changes until 5.10.1 is released, I think it’s wise to start laying out the framework for a constructive dialog in the future.