It's your code, your project, do what you like with it, including keep it closed source and private.
If you want to open source something, then yes, there are different appropriate places, and you'll need to make a choice whether you want to separate the parts onto different places, or simply bundle it as one whole project and keep it all in one place (sourceforge, github, etc).
Biggest item for open sourcing something? Automated test suite. If you don't have a fully automated test suite already, grab the appropriate modules and write a test suite. It doesn't have to be unit tests - end-to-end testing will suffice, provided end-to-end can give you good coverage. You may need to reorganise things to be test-suite usable - that generally improves usability too.
For Perl modules, get Perl::Critic perlcritic script and Perl::Tidy perltidy script and Damian Conway's .perltidyrc, and make sure all your code complies with that.
no subject
It's your code, your project, do what you like with it, including keep it closed source and private.
If you want to open source something, then yes, there are different appropriate places, and you'll need to make a choice whether you want to separate the parts onto different places, or simply bundle it as one whole project and keep it all in one place (sourceforge, github, etc).
Biggest item for open sourcing something? Automated test suite. If you don't have a fully automated test suite already, grab the appropriate modules and write a test suite. It doesn't have to be unit tests - end-to-end testing will suffice, provided end-to-end can give you good coverage. You may need to reorganise things to be test-suite usable - that generally improves usability too.
For Perl modules, get Perl::Critic perlcritic script and Perl::Tidy perltidy script and Damian Conway's .perltidyrc, and make sure all your code complies with that.