Doesn't the journal have any guidelines or required formats for this sort of thing? Most do, or at least those that publish software releases often do.

If you have a public web site, normally, the URL will be given, often on the title page of the published manuscript. If you are also releasing code, then usually a link to the project page at the repository is also required, but may not be if the web site already has the download link. But the journal's instructions to authors should dictate what is actually required and where it should be placed in the manuscript. Or the corresponding editor should be able to tell you what they require or prefer.

Hi,

first of all, every time I see scientists releasing code as open source I have to congratulate them ! So, congratulations. That being said:

1) in terms of license, you definitely have to choose an appropriate license. Otherwise, anyone can get your code and license to them. It you want to release it as an open source software you have a great number of licenses you can consider, such as GNU/GPL v2 or v3, BSD, etc... you can check this web site for popular ones: http://opensource.org/licenses . If you want it to be a pure open source software, GNU/GPL v3 is a very good option, but take your time do decide.

2) in terms of hosting your source code and making it available, I would suggest you to go with the most common services. CPAN is a very good choice for Perl. It's well stablished, and not supposed to disappear. GitHub is a good option too. Another very well stablished host, that is committed to hosting open source software is sourceforge.net . Sourceforge is completely free and has the advantage of offering space to host a webpage for your project. This is important when you think about continuity. If you host your webpage in your university's server, or your own hosting service, this may change in the future. If you leave the webpage on your sourceforge account, it will remain there indefinitely. Be aware that if the URL of your project changes in the future, the paper will be outdated. That's the advantage of choosing sourceforge in my opinion. Another option is Google code, they offer a very good service for hosting open source projects. But, Google can decide to stop offering this service at any time as they have done in the past with several other of their non-profitable services.

So, what I usually do is to use GNU/GPL v3 license, and host it on sourceforge.net. If I want to have a fancier domain for my projects, hosted outside sourceforge, I still use the sourceforge as reference and have it redirect to the fancier URL.

Cheers,

Luiz

Dear researchers,

your answers has been very useful for us. Thanks a lot.

Michael Black, I think that your point is very good. I should check if the journal provide some specifications. In both repositories CPAN and Github, my program refer to the website were the user can download manuals. On the other and, the website redirects the user to the repositories. Regarding to the manuscript, do you think I should refer both website and repos or just one of them?

Luiz Mostaço-Guidolin: Thanks for congratulating me and for your license types review. I already choose the Perl License (Artistic License). What do you think about that? Do you think is important to talk about the chosen license in the article?

Alireza Zare Bidoki: Although I think you didn't understand my question, your answer is very useful. I will add this section "cite us" to the website when the manuscript is published.

One thing I've never done is deposit source or code in more than one repository. I just find it makes maintenance a real bother once you have to keep track of updating multiple repositories. Like Luiz mentioned, places I've worked where we've published software have always just used sourceforge. One site to maintain, update, and one URL for citations.

In my experience, most journals will want you to pick one (primary) site to reference, and only one. So referring to two may simply not be an option if the journal will not allow it. That is why I say you need to contact the editor or check the journals instructions to authors as anything anyone suggest here may be pointless if the journal's rules or requirements are different.

Oh, and congratulations on the publication too.

Thanks!

I agree with you regarding to use more than one repository could be a little fusy. However, and excuse me if I am deviating the thread of this question, choosing just an option is a big deal at this point of the work. On one hand, I use CPAN because it makes installation (regarding to dependencies) of my Perl-program straightforward and uses a lot of BioPerl modules. On the other hand, I use Github because it is a good platform for collaborative development.

What do you recomend to me given this scenario?

Hi Héctor,

the Perl License is a fine open source license (http://opensource.org/licenses/Artistic-Perl-1.0) , just take a look at this link where they discuss item #8. This item talks about commercial distribution of your software. If you are OK with that, then it's a perfectly fine open source license to use. One of the main differences between open source licenses regard to commercial use.

I agree with Michael that keeping multiple repositories is a pain. In general, I consider CPAN as a good repository for Perl modules, i.e. libraries that add functionality to Perl and which can be included from other perl programs. If your software is not a perl module, but an application written in perl, which is not going to be included as a library in another perl application, then I would go with sourceforge (or even GitHub if you prefer).

Cheers.

My vote would be then (assuming that the journal says you can only use one) CPAN. The rationale being that the primary point of the in-pub citation will be for readers to install and use the tool, not necessarily add to its development. CPAN does make that simple for folks to just grab your software and give it a try.

If you can only cite the one place, you could use CPAN, and in your installation just include a README file that includes information for those looking for the development site (i.e. your Github repository link). That's one way I could see to deal with it.

If the journal is okay with it, perhaps you could include 2 links on the title page. One for "current version installation = CPAN" and one for "development = Github"?

Hi Héctor,

I agree with you that CPAN can make the life of the user easier for installing it, and GitHub is good for collaborations. There is no problem on having two repositories (CPAN + GitHub), it is just extra work to keep two repositories and one website consistent. If you have a good workflow for keeping them synced, and you are comfortable with it, then it's fine.

From this thread I believe this is your first release of a software, just keep in mind that if you plan to release more software in the future, and have to keep all of them synced across three different locations then it will become a real pain. If you have only three different applications, then you will have to keep 9 different locations synced and consistent. And then it won't be fun anymore! :)

But... you are a Perl programmer, just automate the process an you should be fine!

Cheers.

Hi Luis: As you are saying, my program is not exactly a module, it is just a whole program. However, it need a lot of modules available from CPAN as dependencies. Then, as we said above, I need to use this repository in order to make the installation progress more easy for users. Do you know some alternative to solve this dependencies? May be including all of them in the package?

I think that I am already satisfaced with your help, so thanks to all of you!

Maybe in few months I came back and post the published papers. Cross the fingers!

Hi Héctor,

in your case, I would just go with CPAN ! It is good and simple enough. Other solutions would be platform dependent. In Linux you could create .deb or .rpm packages, but it would add extra work unnecessarily. CPAN is a good solution.

Good luck.