Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I've always seen open source projects (be it parrot or a small CPAN module) as split into two.

    There is the implementation side of a project, and there is the strategic side of a project.

    Many many projects screw up at a strategic level because, frankly, their management sucks.

    CPAN as a whole tends to get it right, specifically because it makes no assumptions about how the code should be managed (only how it is released) and the permissions model allows for people to take over modules easily when the original author disappears.

    But so many authors, myself included in some cases, make stupid mistakes that harm their projects in the long term. Mistakes like not dealing with user issues promptly. They don't address complaints, but won't hand over release/commit either.

    Thus my preference to just hand out commit as often as possible.

    This also worked for Audrey with pugs, but may have been let down by the whole blead GHC problem making the barriers to contribution so high it placed the project in a high bus-sensitivity situation anyways.
    • Thus my preference to just hand out commit as often as possible.

      A management problem lurks in that as well, however. Do you vet contributors such that they assign you some sort of copyright or perpetual license to the code they write? I squawked about the potential release of Pugs into the public domain for several reasons. One was my potential legal liability as a contributor.

      This also worked for Audrey with pugs, but may have been let down by the whole blead GHC problem making the barriers to con