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
    • 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 contribution so high it placed the project in a high bus-sensitivity situation anyways.

      Even with hackers as talented as Gaal and Yuval, the internals of Pugs are byzantine enough that really only Audrey can make substantive changes with any appreciable timeliness. Without Audrey, well, compare the progress of Pugs in the past 18 months to its progress in the previous 18.

      Tracking blead GHC certainly raised the barriers to contribution, as did the perpetual performance problems, but I'm not sure that they're the prime factors in the low bus number.