<p>Here is a list of the advantages of having Bioconductor for the bioinformatic community:</p>

<ul>
<li><strong>Outreach</strong>: You have a <strong>repository for the field</strong>, in that language. </li>
</ul>

<p>Some packages related to bioinformatics (in R) are distributed through personal repositories, CRAN, github, bitbucket, sourceforge, but they are less used and harder to find.<br>
There are such efforts in other languages too: Biopython, Bioperl, Biojava, ...<br>
Also is harder to find the repositories related to a subject in CRAN, you don't have the BiocViews, the equivalent is optional and not usually filled,  which is quite useful when looking for a method.</p>

<ul>
<li><strong>Quality</strong>: In Bioconductor each package is tested in Linux, Windows, and iOS, to make sure it works in all major operative systems (with all the dependencies). </li>
</ul>

<p>In some rare cases like <a href="https://bioconductor.org/packages/release/bioc/html/Rsubread.html" rel="noreferrer">this one</a>, a packages is not supported for certain platform, but you can known it by checking the <a href="http://bioconductor.org/checkResults/release/bioc-LATEST/Rsubread/" rel="noreferrer">build report</a>.<br>
You are required to provide a vignette and examples in every exported element (and the vignette, examples and tests should pass). You are required to be able to install the package with stricter quality than CRAN, because there is a manual review (They pointed out a <em>comment</em> in one of my functions!).<br>
They also provide docker images of the base packages. You don't need to install the latest R version to use the Bioconductor! But developers do so (at least when checked by Bioconductor servers) to ensure that the package will keep working in next R release. </p>

<ul>
<li><strong>Reusing</strong>: Bioconductor provides the basic elements to a big number of applications. </li>
</ul>

<p>For example the summarizedExperiment class is provided so that any package that needs a similar object can (should) use it. Or GSEABase is the base package to deal with GSEA enrichment analysis, providing functions, methods and classes for gene sets, and collections, making easier for anyone to create their own GSE analysis.<br>
It is easier to build upon the work of others if you know you are following the same quality standards. </p>

<ul>
<li><strong>Support</strong>: To support Q&amp;A is mandatory, the package maintainer must be registered in the <a href="https://support.bioconductor.org" rel="noreferrer">webpage</a>. </li>
</ul>

<p>While in CRAN usually the support is given by each package in its own way, in Bioconductor you can directly reach the maintainer and the users by posting in the same central place. </p>

CC BY-SA 3.0
2017-06-11T10:44:08.963Z
Did you try submitting to CRAN? As far as I understand they also [run tests, and perform a package review](https://cran.r-project.org/web/packages/policies.html); some people even complain that CRAN people are [too pedantic](http://kbroman.org/pkg_primer/pages/cran.html).
Iakov Davydov
CC BY-SA 3.0
2017-06-11T10:13:24.243Z
2017-06-11T22:00:10.837Z
2017-06-11T22:00:10.837Z
llrs
<p>Regarding what the advantage is to you as a developer of having a bioconductor package rather than using CRAN:</p>

<ol>
<li>There's a hierarchy of package quality, with bioconductor on the top (followed by CRAN and then "random github repos"). While there are many excellent CRAN packages, the average bioconductor package is better tested and documented. So if I as a user have two different packages that I can use and one is on bioconductor and the other CRAN, then I use the bioconductor package.</li>
<li>Higher visibility. Since bioconductor packages are held in higher regard, they also become more visible. Further, the different "views" (e.g., "Alternative Splicing" and "Transcription") make it convenient to find relevant packages. You can always search CRAN, but allowing tagging like this aids in discovery.</li>
</ol>

CC BY-SA 3.0
2017-06-11T10:16:06.020Z
I have been using a lot of packages from both CRAN and Bioconductor, I haven't noticed that CRAN packages are worse in any sense. I even noticed that documentation of  some packages from Bioconductor was worse (at least that was the state several years ago).
Iakov Davydov
CC BY-SA 3.0
2017-06-11T10:17:22.323Z
You've had nice luck with CRAN packages then.
Devon Ryan
CC BY-SA 3.0
2017-06-11T15:28:51.787Z
Pretty sure the quality hierarchy is wrong: if a package is maintained on Github, odds are its quality is in fact superior than that of the average CRAN or Bioconductor package. This might soon change once Github becomes more widespread amongst beginning R programmers but I’m pretty certain it currently still holds.
Konrad Rudolph
CC BY-SA 3.0
2017-06-11T17:12:56.453Z
@KonradRudolph the "if" in your first sentence is a big one.
Devon Ryan
CC BY-SA 3.0
2017-06-11T19:22:33.643Z
@DevonRyan My mistake, I meant "is hosted on". There's a risk it's unmaintained (but the same is true for centralised repositories) but the odds of quality given location = Github are still high. I'll grant that it's possible that the *variance* of quality is also higher on Github, but even for that I'm not sure.
Konrad Rudolph
CC BY-SA 3.0
2017-06-11T21:45:54.040Z
@KonradRudolph the most of Bioconductor packages are maintained on GitHub (at least the most of I have used). I have GitHub R package as well, but it is definitely not passing any tests, it is working on my computer in the way that I use it. No being on GitHub is not any sign of quality... but true, if the package is only there, nobody will know about it, so there won't be any bug reports.
Kamil S Jaron
CC BY-SA 3.0
2017-06-11T10:09:41.653Z
2017-06-11T10:09:41.653Z
Devon Ryan
<p>The most important reason is that Bioconductor has growing set of common data structures and base packages. If package X and package Y needs to work with the same type of data, having a common data structure in the core Bioconductor package Z makes our lives so much easier. I could do something in package X, take out the results and keep working on my data with package Y. This works because I'm using versions of package X and Y that are compatible with the data structure defined in package Z. The Bioconductor team makes sure that all packages use the common data structures and already existing packages where possible, so that we're all on the same page and so that people don't reinvent the wheel again and again.</p>

<p>Also, there's a sophisticated process around <a href="https://www.bioconductor.org/developers/package-submission/" rel="nofollow noreferrer">getting your package accepted to Bioconductor</a>. This ensures that packages use data structures and functions already available in other Bioconductor packages (where reasonable), it ensures that packages are well written, that they have good documentation, and that they are well tested.</p>

CC BY-SA 3.0
2017-06-11T10:18:55.697Z
2017-06-12T10:22:33.963Z
2017-06-12T10:22:33.963Z
stianlagstad
<p><strong>Benefits of central repository for Community</strong></p>

<p>Having a central repository for packages is very useful. For couple of reasons:</p>

<ul>
<li>It makes very easy to resolve <strong>dependencies</strong>. Installing all the dependencies manually would be exhausting but also dangerous (point 2).</li>
<li>Package <strong>compatibility</strong>! If I install package with dependencies, I would like to be sure that I install correct versions of all the dependencies.</li>
<li><strong>Reliability</strong> thanks to unified and integrated testing. <code>Bioconductor</code> is trying really hard to force developers to write good test, they also have people manually testing submitted packages. They also remove packages that are not maintained. Packages in <code>Bioconductor</code> are (reasonably) reliable.</li>
</ul>

<p>In the end, installing dev versions of R packages is in my opinion <strong>very bad practise</strong> for reproducible science. If developers delete GitHub repo, commit hash you have used won't be enough to get the code.</p>

<p><strong>Benefits of central repository for developers</strong></p>

<p>I forgot about the advantages for you as developer to submit your package to <code>Bioconductor</code>:</p>

<ol>
<li>Your package will be more visible</li>
<li>users will have a guarantee that your code was checked by third person</li>
<li>Your package will be for users easier to install</li>
<li>Your package will be forced to use standardized vignettes, version tags and tests -> will be more accessible by community to build on your code</li>
</ol>

<p><strong>Bioconductor specific advantages over CRAN</strong></p>

<p>I see the big advantage in the <a href="https://support.bioconductor.org/" rel="noreferrer">community support page</a>, provided by <code>Bioconductor</code>. <a href="https://bioinformatics.stackexchange.com/a/643/57">@Llopis' comprehensive elaboration</a>. </p>

CC BY-SA 3.0
2017-06-12T17:41:24.813Z
I think you're missing: data packages. CRAN has quite strict file size limits (5 MB) and biology needs e.g. genomes. Your points 1 and 3 are debatable (1: bio yes, otherwise no; 3: I'd argue it's harder, needs an external installer).
Michael Schubert
CC BY-SA 3.0
2017-06-12T18:10:44.503Z
You do not want write package with genomic data stored inside anyway - we rather write packages for pulling data from databases. But point taken.
Now I see I made a smart move, when I numbered both overall advantages for community and advantages for developers.
Kamil S Jaron
CC BY-SA 3.0
2017-06-12T18:32:17.560Z
Ok, I turned upper numbers to bullet points and I made clear that I am speaking about central repositories in general.
Kamil S Jaron
CC BY-SA 3.0
2017-06-13T10:16:33.220Z
@KamilSJaron Regarding data packages, they’re an established best practice in Bioconductor (see BSGenome) though I tend to agree: I dislike how the Bioconductor data packages clutter my disk.
Konrad Rudolph
CC BY-SA 3.0
2017-06-11T07:13:30.900Z
2017-06-12T18:31:09.837Z
2017-06-12T18:31:09.837Z
Kamil S Jaron
<p>What are the advantages of having Bioconductor, for the bioinformatics community?</p>

<p>I've read the '<a href="https://bioconductor.org/about/" rel="noreferrer">About</a>' section and skimmed the <a href="https://genomebiology.biomedcentral.com/articles/10.1186/gb-2004-5-10-r80" rel="noreferrer">paper</a>, but still cannot really answer this.</p>

<p>I understand Bioconductor is released twice a year (unlike <code>R</code>), but if I want to use the latest version of a package, I'll have to use the dev version anyway. A stamp of <em>approval</em> could be achieved much easier with a tag or something, so it sounds just like an extra (and unnecessary) layer to maintain.</p>

<p>Related to this, what are the advantages as a developer to have your package accepted into Bioconductor?</p>

CC BY-SA 3.0
2017-06-11T15:27:21.227Z
+1 … the idea of having centralised repositories is becoming more and more out of fashion because there’s no clear evidence for its supposed benefits.
Konrad Rudolph
CC BY-SA 3.0
2017-06-11T21:42:56.027Z
Is the question "What are the advantages of having Bioconductor over CRAN?" or "What are the advantages of having any kind of central repository? - lets take Bioconductor as example"?
Kamil S Jaron
CC BY-SA 3.0
2017-06-12T09:52:38.493Z
@KamilSJaron My question is neither -- or both: _What are the advantages of having Bioconductor, or any similar central repository, over CRAN?_ If anything, the focus is on having any R repo for bioinformatics, as opposed to a website, where the approved packages are listed.
Peter
<r><bioconductor>
Why Bioconductor?
# Why Bioconductor?

(Asked by: username_0 on 2017-06-11)

What are the advantages of having Bioconductor, for the bioinformatics community?

I've read the '[About](https://bioconductor.org/about/)' section and skimmed the [paper](https://genomebiology.biomedcentral.com/articles/10.1186/gb-2004-5-10-r80), but still cannot really answer this.

I understand Bioconductor is released twice a year (unlike `R`), but if I want to use the latest version of a package, I'll have to use the dev version anyway. A stamp of *approval* could be achieved much easier with a tag or something, so it sounds just like an extra (and unnecessary) layer to maintain.

Related to this, what are the advantages as a developer to have your package accepted into Bioconductor?

**Tags:** r, bioconductor
> **Comments:**
> **username_1**: +1 … the idea of having centralised repositories is becoming more and more out of fashion because there’s no clear evidence for its supposed benefits.  
> **username_2**: Is the question "What are the advantages of having Bioconductor over CRAN?" or "What are the advantages of having any kind of central repository? - lets take Bioconductor as example"?  
> **username_0**: @KamilSJaron My question is neither -- or both: _What are the advantages of having Bioconductor, or any similar central repository, over CRAN?_ If anything, the focus is on having any R repo for bioinformatics, as opposed to a website, where the approved packages are listed.  

---

## 4 answers

### Answer by username_2 on 2017-06-11. Score: 18 | Accepted answer

**Benefits of central repository for Community**

Having a central repository for packages is very useful. For couple of reasons:

* It makes very easy to resolve **dependencies**. Installing all the dependencies manually would be exhausting but also dangerous (point 2).
* Package **compatibility**! If I install package with dependencies, I would like to be sure that I install correct versions of all the dependencies.
* **Reliability** thanks to unified and integrated testing. `Bioconductor` is trying really hard to force developers to write good test, they also have people manually testing submitted packages. They also remove packages that are not maintained. Packages in `Bioconductor` are (reasonably) reliable.

In the end, installing dev versions of R packages is in my opinion **very bad practise** for reproducible science. If developers delete GitHub repo, commit hash you have used won't be enough to get the code.

**Benefits of central repository for developers**

I forgot about the advantages for you as developer to submit your package to `Bioconductor`:

1. Your package will be more visible
2. users will have a guarantee that your code was checked by third person
3. Your package will be for users easier to install
4. Your package will be forced to use standardized vignettes, version tags and tests -> will be more accessible by community to build on your code

**Bioconductor specific advantages over CRAN**

I see the big advantage in the [community support page](https://support.bioconductor.org/), provided by `Bioconductor`. [@Llopis' comprehensive elaboration](https://bioinformatics.stackexchange.com/a/643/57).

> **Comments:**
> **username_7**: I think you're missing: data packages. CRAN has quite strict file size limits (5 MB) and biology needs e.g. genomes. Your points 1 and 3 are debatable (1: bio yes, otherwise no; 3: I'd argue it's harder, needs an external installer).  
> **username_2**: You do not want write package with genomic data stored inside anyway - we rather write packages for pulling data from databases. But point taken. Now I see I made a smart move, when I numbered both overall advantages for community and advantages for developers.  
> **username_2**: Ok, I turned upper numbers to bullet points and I made clear that I am speaking about central repositories in general.  
> **username_1**: @KamilSJaron Regarding data packages, they’re an established best practice in Bioconductor (see BSGenome) though I tend to agree: I dislike how the Bioconductor data packages clutter my disk.  

---

### Answer by username_3 on 2017-06-11. Score: 10

Here is a list of the advantages of having Bioconductor for the bioinformatic community:

* **Outreach**: You have a **repository for the field**, in that language.

Some packages related to bioinformatics (in R) are distributed through personal repositories, CRAN, github, bitbucket, sourceforge, but they are less used and harder to find.  
There are such efforts in other languages too: Biopython, Bioperl, Biojava, ...  
Also is harder to find the repositories related to a subject in CRAN, you don't have the BiocViews, the equivalent is optional and not usually filled, which is quite useful when looking for a method.

* **Quality**: In Bioconductor each package is tested in Linux, Windows, and iOS, to make sure it works in all major operative systems (with all the dependencies).

In some rare cases like [this one](https://bioconductor.org/packages/release/bioc/html/Rsubread.html), a packages is not supported for certain platform, but you can known it by checking the [build report](http://bioconductor.org/checkResults/release/bioc-LATEST/Rsubread/).  
You are required to provide a vignette and examples in every exported element (and the vignette, examples and tests should pass). You are required to be able to install the package with stricter quality than CRAN, because there is a manual review (They pointed out a *comment* in one of my functions!).  
They also provide docker images of the base packages. You don't need to install the latest R version to use the Bioconductor! But developers do so (at least when checked by Bioconductor servers) to ensure that the package will keep working in next R release.

* **Reusing**: Bioconductor provides the basic elements to a big number of applications.

For example the summarizedExperiment class is provided so that any package that needs a similar object can (should) use it. Or GSEABase is the base package to deal with GSEA enrichment analysis, providing functions, methods and classes for gene sets, and collections, making easier for anyone to create their own GSE analysis.  
It is easier to build upon the work of others if you know you are following the same quality standards.

* **Support**: To support Q&A is mandatory, the package maintainer must be registered in the [webpage](https://support.bioconductor.org).

While in CRAN usually the support is given by each package in its own way, in Bioconductor you can directly reach the maintainer and the users by posting in the same central place.

> **Comments:**
> **username_4**: Did you try submitting to CRAN? As far as I understand they also [run tests, and perform a package review](https://cran.r-project.org/web/packages/policies.html); some people even complain that CRAN people are [too pedantic](http://kbroman.org/pkg_primer/pages/cran.html).  

---

### Answer by username_5 on 2017-06-11. Score: 3

Regarding what the advantage is to you as a developer of having a bioconductor package rather than using CRAN:

1. There's a hierarchy of package quality, with bioconductor on the top (followed by CRAN and then "random github repos"). While there are many excellent CRAN packages, the average bioconductor package is better tested and documented. So if I as a user have two different packages that I can use and one is on bioconductor and the other CRAN, then I use the bioconductor package.
2. Higher visibility. Since bioconductor packages are held in higher regard, they also become more visible. Further, the different "views" (e.g., "Alternative Splicing" and "Transcription") make it convenient to find relevant packages. You can always search CRAN, but allowing tagging like this aids in discovery.

> **Comments:**
> **username_4**: I have been using a lot of packages from both CRAN and Bioconductor, I haven't noticed that CRAN packages are worse in any sense. I even noticed that documentation of  some packages from Bioconductor was worse (at least that was the state several years ago).  
> **username_5**: You've had nice luck with CRAN packages then.  
> **username_1**: Pretty sure the quality hierarchy is wrong: if a package is maintained on Github, odds are its quality is in fact superior than that of the average CRAN or Bioconductor package. This might soon change once Github becomes more widespread amongst beginning R programmers but I’m pretty certain it currently still holds.  
> **username_5**: @KonradRudolph the "if" in your first sentence is a big one.  
> **username_1**: @DevonRyan My mistake, I meant "is hosted on". There's a risk it's unmaintained (but the same is true for centralised repositories) but the odds of quality given location = Github are still high. I'll grant that it's possible that the *variance* of quality is also higher on Github, but even for that I'm not sure.  
> **username_2**: @KonradRudolph the most of Bioconductor packages are maintained on GitHub (at least the most of I have used). I have GitHub R package as well, but it is definitely not passing any tests, it is working on my computer in the way that I use it. No being on GitHub is not any sign of quality... but true, if the package is only there, nobody will know about it, so there won't be any bug reports.  

---

### Answer by username_6 on 2017-06-11. Score: 2

The most important reason is that Bioconductor has growing set of common data structures and base packages. If package X and package Y needs to work with the same type of data, having a common data structure in the core Bioconductor package Z makes our lives so much easier. I could do something in package X, take out the results and keep working on my data with package Y. This works because I'm using versions of package X and Y that are compatible with the data structure defined in package Z. The Bioconductor team makes sure that all packages use the common data structures and already existing packages where possible, so that we're all on the same page and so that people don't reinvent the wheel again and again.

Also, there's a sophisticated process around [getting your package accepted to Bioconductor](https://www.bioconductor.org/developers/package-submission/). This ensures that packages use data structures and functions already available in other Bioconductor packages (where reasonable), it ensures that packages are well written, that they have good documentation, and that they are well tested.


---

