If I were (pump)king

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!"

That's right.  All my JFDI inclinations would probably change overnight into DFIU.

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!

If I were pumpking, I'd be so conservative I'd make Newt Gingritch look like the mayor of San Francisco.

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.

This entry was posted in perl programming and tagged . Bookmark the permalink. Both comments and trackbacks are currently closed.


  1. Posted July 11, 2009 at 9:39 am | Permalink

    Risk management is indeed important. Not only do we need to reduce the risk for any one person participating in the development and release process but we need to reduce the cost of making mistakes.

    Think of it this way: what's the cost of producing a second release candidate if the first one has an awful or embarrassing bug?

    Now what's the cost of producing a second release if the first one has an awful or embarrassing bug?

    How can we reduce the cost of the latter to the level of the former?

  2. Posted July 11, 2009 at 2:45 pm | Permalink

    If you were pumpking, you'd have my vote (not that it matters, though). You really captured what I think is the dichotomy of being a leader, and I strongly believe this sort of thinking is exactly what any large open-source project needs.

    dagolden++ bigtime. I'm looking forward to new posts on the subject that might help further improve the entire Perl community!