What is the best way from your experience to distribute bioinformatics software and what is the best way for you to get software? Do you prefer to download compiled versions from https://sourceforge.net/, or seeing lively github repository and ability to compile yourself is crucial?

Github is great, both source code and compiled binary files are available for most of bioinformatics tools, at least for mine (csvtk, seqkit, taxonkit, rush ...).

Github provides wiki and pages (What I choose) where you can host the documents of the software.

Read the Docs is also a good place for hosting documents, e.g, khmer.

When you distribute your tools what do you measure about its usage?

I distribute binary files via Github release, e.g., seqkit releases. The are tools (https://img.shields.io) that can count download count of every file or whole release, e.g, , more example on seqkit.

I also add tools to bioconda, so people can easily install and update via conda. Brew is also a option for OS X usres. Conda can also show the download counts, e.g., , detail

How do you encourage people to really cite your tools as papers (not just weblinks).

Citation information are available on project page and command-line usage. What I can do is making my software better and hope people will cite them.

Are there any tools to calculate how many times your software was cited as a weblink in papers?

May using Google.

Do you try to get information about users of your software like email addresses, names, countries, phone numbers?

I did not and will not collect any private information of users.

How do you solve licensing and liability issue especially for something you had done on your own spare time as a side project.

It depend on the licenses of the dependencies. For me most of the dependencies are under MIT license and I also use it for my projects.

How do you protect yourself or maybe even find a way to make some money off your tools?

Never think about making money for my open-source projects on Github. Since they are open-source, it hard to protect the code.

Maybe you know a good tutorial on this? If not, let's answer to this questions in the discussion below and make it as a tutorial for everybody interested.

N/A

Here is my very biased point of view of member of the Debian Med project.

What is the best way from your experience to distribute bioinformatics software and what is the best way for you to get software?

We distribute binary package, with names as close as possible to the original, so that our users can install a tool with a command such as apt install name-of-the-tool.

Do you prefer to download compiled versions from https://sourceforge.net/, or seeing lively github repository and ability to compile yourself is crucial?

We download the source from the upstream developers, that we use for building our binary package. Regarding how the source is made available upstream, are not picky but our task is much easier when it is available from a Git repository, and releases available both as a file archive and a Git tag with machine-predictable URLs so that we can detect new releases automagically.

When you distribute your tools what do you measure about its usage?

http://popcon.debian.org

How do you encourage people to really cite your tools as papers (not just weblinks).

We provide citation information in YAML format; see the one of the seaview package for example. Patches are welcome when the information is not up to date.

Do you try to get information about users of your software like email addresses, names, countries, phone numbers?

Apart from the popcon system, which is opt-in and uses encrypted communications, we do not track anything from our users, and we make our best efforts to make sure that the software that we redistribute does not track them either.

How do you solve licensing and liability issue especially for something you had done on your own spare time as a side project.

In brief, we strongly recommend to use an existing, well established, license and never attempt to write one from scratch. More detailed guidelines are available in our upstream guide, that covers many more topics and that I encourage everybody to read !

How do you protect yourself or maybe even find a way to make some money off your tools?

In the Debian distribution, there is only Free software, and this freedom gives the authors and everybody else the right to use the software commercially and earn money from using or selling it. (Be careful that besides Debian proper, there is also the non-free section, that contains open-source software that are not Free, like cufflinks for instance, but we strongly discourage the creation of non-Free software.)

UPDATE: two more questions:

update: two more answers

What do you think about having access for your tool as a library or a package for python, ruby, perl, R, other languages? Is this important and needed?

Tools wrapped up as regular modules/libraries for the languages listed above are easier to package for us, since for each of them we have dedicated teams with considerable experience. This said for C and C++ I would recommend to refrain from distributing a library unless it is really intended to be linked from by third parties, and there is a commitment to properly handle the breakages of backwards compatibility.

Are there any collaborations we can join to provide our tools to be part of bigger packages and still have the ability to publish about them, have control and support, maybe a way to sell it as well?

Publishing is great, and I feel very well the deep pressure for doing so, but sometime I dream of a world where contributing a new function to an existing toolkit is regarded as positively as creating a new stand-alone tool... and not have time to maintain it later.

Do you prefer to download compiled versions from https://sourceforge.net/, or seeing lively github repository and ability to compile yourself is crucial?

You can have compiled binaries on GitHub (and track versions, too): https://help.github.com/articles/creating-releases/

For example, samtools: https://github.com/samtools/samtools/releases

Not sure how trustable SourceForge is now: https://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/

How do you solve licensing and liability issue especially for something you had done on your own spare time as a side project.

GitHub has a nice tutorial for that: https://choosealicense.com/

Since this thread as already grown large I am not going to try to multi-quote but let me see if I can remember things I wanted to respond to.

• Even before I choose to download something you need to convince me to try your software in words. That can be done by a post on Biostars/SeqAnswers and/or a great ReadMe on your SF/GitHub repo. There are many packages out there that can do "X" and I am not generally looking to get a package that will do a one-off thing, unless it is something I can't find in another package.

• If you don't support a specific OS make that clear upfront. Post a list of OS's you (or your users) have successfully tried your software on. If you are providing your software for free you are not obligated to support all OS's.

• Make it easy for users to download/use your software. If you must use a dependency then preferably make it so it would be a compiled entity. Having to go down a rabbit-hole of x needs y, y needs z totally confuses consumers. If you are able to make binaries available for common OS's (along with source for those who work on clusters etc) that is the best option.

• If you can't make a self-contained download entity then consider making your software available via conda/brew/apt-get etc.

• If a grant supports your software development and the agency requires you to collect usage/stats then make it simple. I am happy to provide an email address as long as I am assured that it will be used for just that. Make it a one time thing (for updates I should only need to provide the email address (like IGV)).

• It may be feasible to make money from your software by licensing it for commercial usage/inclusion in other commercial software packages.

• Chances of you having a publication about your software before its widespread usage are small unless it is part of a larger study (this has been a topic of discussion in past). So you are going to have to contend with citations coming for software repo for a while.

• You are going to walking a thin line if you are developing the software on your own time but are still employed. You would want to keep your ducks in order not to get in trouble with your employer down the road.

• Ultimately the quality/utility of your software will decide how far/where it will go.

What is the best way from your experience to distribute bioinformatics software and what is the best way for you to get software?

I use Github for distributing source code and pre-compiled binaries and OS X installers for our BEDOPS toolkit. I use readthedocs to distribute documentation. We transitioned from Google Code. Our documentation efforts were so successful that other toolkits have copied the style and approach of our work, which is praise in its own way!

I also make use of package installers like Bioconda and Homebrew to make our software available (e.g., conda install bedops and brew install bedops). Some people are working on a Debian recipe, so maybe it will one day be available via apt-get or the like.

Do you prefer to download compiled versions from https://sourceforge.net/, or seeing lively github repository and ability to compile yourself is crucial?

Github allows the power user to clone a repository and compile for him or herself, or download precompiled binaries for the less savvy user.

Making source available is key, I think, whichever way you choose to do it, whether Sourceforge, Github, Bitbucket, etc. Closed source tools are black boxes and can't be tested and evaluated properly.

When you distribute your tools what do you measure about its usage?

Github gives limited information about downloads and makes tracking difficult, if not impossible. This is definitely a weakness, in terms of gauging demand for source code, but it's a positive for end user privacy, I suppose.

We can track access to documentation via Google Analytics, which gives a very rough idea of where repeat users are coming from. People can install tracker blockers, as is their right, so the conclusions we can take from this level of tracking are limited, at best.

How do you encourage people to really cite your tools as papers (not just weblinks).

We can't obviously enforce citations, but we post citation information everywhere, including online in the Github front page, the front page of the documentation, and in the --help option of all command-line tools!

Are there any tools to calculate how many times your software was cited as a weblink in papers?

Google Scholar offers some limited options.

Do you try to get information about users of your software like email addresses, names, countries, phone numbers?

No, not really. Keeping track of where people come from is not very easy from Github. We do add a Google Analytics tracker for the documentation site, which offers us a very very coarse snapshot of where interest in BEDOPS is on a country-by-country level.

How do you solve licensing and liability issue especially for something you had done on your own spare time as a side project. How do you protect yourself or maybe even find a way to make some money off your tools?

We have always offered our software under open-source license terms. We haven't obviously been able to stop others from copying the algorithms and approaches we documented in our Bioinformatics paper, but that's just life in academia, I guess.

Some people offer their software with two licenses, one for academia and another for commercial users, which is for-fee. Or they offer support or service contracts. Those may be ways to monetize and support ongoing development efforts.

On the matter of software distribution: As a user/programmer, I find programming languages central repositories (e.g. CPAN (perl), CRAN (R), PyPi (Python)...) incredibly useful and convenient. As a user, I'd rather get precompiled binaries for my system if the software has too many dependencies, in particular on libraries not available from my OS's package manager or for situations where I don't have admin rights.

As for licencing, this is a can of worms. Just as an example, there's some debate about whether the new terms of services at GitHub are compatible with some open source licences (see here).

UPDATE: two more questions:

1) What do you think about having access for your tool as a library or a package for python, ruby, perl, R, other languages? Is this important and needed?

This is often at least really useful. It means that you can integrate it in your own software/library, without having to reimplement it. About other languages, don't forget about Java (and BioJava).

I believe that the best practice is publishing the library + the desktop/web/whatever application to use it straight forward.

2) Are there any collaborations we can join to provide our tools to be part of bigger packages and still have the ability to publish about them, have control and support, maybe a way to sell it as well?

There are several communities like this. I'm thinking for instance at the BioJs community https://biojs.net/ : each component is developed by different group, and published independently (there is even a channel for it on F1000: enter link description here). It makes it easy for programers to search, use and cite the right components.

Another great way (to my opinion) to release software is to create plugins for already widely accepted software rather than creating a new stand alone program. It makes it more visible and easy to integrate with other functions. Cytoscape (enter link description here) is a really good example, and each plugin can be published independently (there are many examples). The Integrated Genome Browser (IGB) is following a similar strategy.