I took the title of this post from a post by Andrew Cowie of Operational Dynamics. His post is not specific to Perl, but I feel his thesis is very relevant to the Perl community. His post is an abstract for a presentation he gave at an open-source conference. The thesis is that

"There is a fundamental structural problem in the open source movement. Within a given project, things generally find a way to get done, but when a problem lies between two projects (be they peers, one dependent on the other, whatever) then things often remain unresolved…. This is actually the cutting edge area in the free software movement at the moment - trying to find a common ground for not just projects but constellations of projects.."

The idea of constellations of projects sounds an awful lot like CPAN to me. Cowie goes further to say that

"Why there are there 80,000 unfinished one man show projects on SourceForge? The “not-invented-here” syndrome means that so many of us keep re-inventing the wheel; and that’s so often because we think its easier for us to start work on something new than to contribute to an existing project. We all know there are lots of reasons for this, but a big part of the truth is that contributing is hard. That’s what we have to change."

Just replace "SourceForge" with "CPAN" and I think one would agree that Cowie's statements apply to the Perl community.

The closing statement of the post states with respect to open-source projects that "the criterion for success...(is)ensuring that the barrier to other people contributing to your project is low. If we can remove the impediments to collaboration then together we can really make free and open source software the road that into the future."

To me, the single biggest barrier to contribution to CPAN modules can be in communication with the module maintainer(s). I've observed many comments on Perlmonks where someone was trying to do something with a module and the biggest problem was that the module maintainer wasn't responding, had disappeared, etc...

What does the monastery think?

This post produced using Grandfather's Perlmonks node editor--try it, you'll like it.

Updated: fixed links

Replies are listed 'Best First'.
Re: Criterion for success in open source
by Jenda (Abbot) on Feb 13, 2007 at 23:58 UTC

    The catch is that you only get to know about problems. You only notice if there's a problem contacting the module maintainer (which is not necessarily the original author, quite a few modules went through several maintainers), but the thousands and milions of accepted patches, implemented feature requests and reported bugs are invisible. I admit, I don't know what is the number of unfinished and forgotten modules on CPAN, but generally it works.

    In either case ... what do you suggest? ;-)

    Jenda
    Support Denmark!
    Defend the free world!

[reply]
Re: Criterion for success in open source
by DrHyde (Prior) on Feb 14, 2007 at 09:33 UTC
    One key difference between sourceforget and the CPAN is that with the CPAN it is possible for you to take over maintenance of someone elses project if they disappear - that's how I became the Data::Compare maintainer. At sourceforge, you can't as far as I know, and if you want to take over you have to fork the software and create a new project.

    In any case, if there are only 80,000 abandoned projects on sourceforge I reckon that's pretty good. Remember, almost all of the authors on sourceforge - just like on CPAN - don't get paid to write and maintain their stuff. It is a testament to the strength of the development model that despite that we manage to have several thousand perl modules and several tens of thousands of sourceforge projects which are either complete, under maintenance, or under development, and that many of those have hundreds if not thousands of users who rely on them to work reliably.

    As an example of a successful project, for which the authors don't receive a penny in payment, take a look at rsnapshot (of which I am the current maintainer). It has a small number of core developers, several tens of people who have submitted patches, several hundred people on the mailing list, and those people use the software to back up well over a thousand machines between them, ranging from single desktop PCs at home through to the servers on a hospital ship, in casinos, and in government departments and other large companies.

[reply]
Re: Criterion for success in open source
by Scott7477 (Chaplain) on Feb 14, 2007 at 15:27 UTC

    To expand on my initial post, I think that within the Perl community the barriers to contribution are low relative to Sourceforge at least, and on par with other language/platforms in general. I thought up a list of things that someone can do to make a contribution to the Perl community, listed in ascending order of time requirements/difficulty.

    1. Install CPAN modules after installing CPAN::Reporter and using CPAN; or alternatively using CPANPlus to install modules. In either case, a test report is automatically generated reporting the success or failure of the module installation to CPAN Testers, which gives the module author useful information.

    2. Install Chris Williams'(BinGOs) module POE-Component-CPAN-YACSmoke and the minismoker script that is associated with it and run minismoker.pl. The minismoker script run without any flags "obtains a list of recently uploaded modules and processes them." So it tests the modules in question to see if they will install successfully on your machine and reports the sucess or failure to CPAN Testers. One of the nifty things about this is if you have registered your email address with CPAN Testers you'll get emails back showing the test results so you will have a list of modules that you know can be successfully installed on your machine or not without actually having to attempt installation. Chris's work with this has been truly heroic. In the month of January, Chris submitted 10,158 test reports to CPAN Testers using this system that he's developed. That is not a misprint. Chris's approach has been endorsed by at least one of the folks in charge of CPAN Testers here.

    3. If you have a blog, post code that you've written and commentary on Perl issues. Last time I checked Perlmonks is still somewhat opaque to Google searches, so having stuff you've created in a searchable location is worthwhile, I think.

    4. Submit bug reports to CPAN's public bug tracker.

    5. Post patches for bugs that you've identified in modules.

    6 Write a module that fills a hole in CPAN's coverage of functionality.

    7. Take over maintenance of a module.

    I'm sure I've left some things out, but to sum up in terms of my original post I think that the Perl community has made it possible for someone to make meaningful contributions regardless of your skill level with the language, or in other words the barriers to meaningful contribution are low. That said, I thought that chromatic has some thought provoking questions over at use.perl that are worth a read as well.

    Update: fixed external links..D'oh!
[reply]
Re: Criterion for success in open source
by samizdat (Vicar) on Feb 15, 2007 at 14:06 UTC
    I think you're all right. Yes, it could be much better. Is it broken? No! It's amazing how well these bears dance! The tools you speak of in your follow-up attest to the enormous creativity of the OS movement. Compare this with trying to fix an incompatibility between M$ and Symantec... MTBFix is about five years, maybe, if ever. Remember "We'll fix it in five oh"???

    Another point to be made is that the very nature of open source is that the wheels usually *have* been invented before (yes, it's a good thing!), and the info is out there. One of my cow-onks had some common code that built input multiplexing daemons, and we discovered that his code was linking to the wrong library APIs when we used it in two different daemons at the same time... a little research and he discovered "versioned symbols," invented to solve the glibc version crashes that plagued the GNU and Linux worlds for several years.

    I think the real issue is not that there's a lot of chaff out there, it's separating the wheat from the chaff. There are two answers to this: know what you're doing, and know whose code you're running. One could postulate rating systems like PM's XP for projects -- and, yes, they're out there -- but there is no substitute for grokking something until you understand it. If you're in bed with somebody else's code, don't blame me if you get AIDS. :D

    Don Wilde
    "There's more than one level to any answer."
[reply]

Back to Meditations