Darkpan => CPAN Service?
With all the discussion about CPAN reliability and hair pulling over worrying what's going on in the Darkpan, I was just thinking: Why not extend CPAN for Corporate / Non Free stuff? Basically we'd extend CPAN so that authors could release source code under more restricted licenses but you'd have to pay a reasonable fee for the privilege.
This would accomplish the following:
1) Encourage people to follow the best practice of writing everything as CPAN module, so that they could take advantage of CPANs vast smoke testing system and receive more timely alerts to when new releases of dependencies causes breakage.
2) Be a source of income for the Perl community, which we could use to fund important stuff
3) Create less worry about causing breakages
4) Allow a company to generate an alternative income source for their code.
Now, I'm an open source believer, and do my best to convince my employers to release as much code as possible, since this almost always ends up as better code once it's in the wild. But there's always going to be some things that are in house, stuff that reflect the unique business rules and the companies investment in technology. Given that we all agree validating Darkpan is important and that writing your code as well tested CPAN modules is the right way to code Perl, do we think there's an opportunity here to build out something everyone can benefit from?
My Groups
-
POE Updated: 2 days ago
-
Perl Updated: Nov 3, 2009
-
ProNet Vox Community Updated: Oct 29, 2009
Neighborhood
Explore friends, family, friends & family, or entire neighborhood.
Comments
I was wondering how putting corporate code onto the CPAN would particularly help? Like in terms of the code itself, does making the code CPAN-friendly actually make the code more robust, or easily maintainable, etc?
My organization is currently in the process of cleaning up all of its code in the DarkPAN, and this seems like a good idea at face-value, but I'm wondering what the long-term benefits are of putting code up on the CPAN, basically.
I would have to pitch this to management, to take advantage of a for-pay CPAN service (which, again, at face-value, sounds really good).
Thanks in advance,
Ifty.
Actually I don't think companies would put their secret code on CPAN anyway.
As to answer Ifty, I think there can be huge benefits to put your code on CPAN
assuming it can be reused by others. (that is, assuming it has an open source license). These are usual things that open source can provide with the extra features of the Perl community. So you will get free of charge:
1) Peer review
2) Automated testing
Possibly you'll get
3) Patches to fix issues
4) Patches for further features
5) Your deployment process can be further streamlined and standardized.
If you put new versions on CPAN early maybe even before you start using it
then you have a chance that others will find the bugs in it and maybe even fix them before your company encounters them.
Another level could be to grant source access to authors of dependent modules. This would assist in debugging, and again could be part of the thing you pay for.
I'm envisioning this as another way for CPAN authors to make some extra money supporting thier open source stuff for Darkpan stuff, as well as bringing in some money for all of CPAN to use for feature enhancements or to fund grants.
Basically it's a pay to play system, where the more secret you want your code and or the more support you want would have a price associated. Right now most CPAN authors maintain their code for free, as part of their feeling of duty to the community and as a way to gain merit, but this model has a downside in that if I am busy getting paid to do something else, I might not have time to support the code. On the other hand, this has lead to how we are really getting better at sharing co-maintence for modules where many people have shared interest. So I don't want to destroy that. Just some stuff on CPAN get's busted and no one ever fixes it :) I'm just brainstorming on ways to tweak the model a bit. I definitely don't want to turn CPAN into some sort of global repository for code no one can use. The idea would need a lot more thought.
As for the issue of making your code a CPAN module even if you don't plan CPAN release, well, that's considered a best practice, although not really documented in one place. I have a very late blog for the next BlueChild installment that discusses this in detail (too much probably, which is why I am so late with it.)
There's already enough REAL scarcity in the world.