CRAN instead of Bioconductor?

[HenrikBengtsson]

Have you guys considered releasing this package and matrixStats derivatives (DelayedMatrixStats(*) and sparseMatrixStats) on CRAN rather than Bioconductor? AFAIU, there's nothing specific to Bioconductor in them.

Having them on CRAN would reach a much bigger audience, give them much exposure, increase their usage by users and packages, and improve quality in the long run. This would benefit users and developers outside of the Bioconductor sphere. I find it's unfortunate to "hide them away" on Bioconductor. (I think there are other packages on Bioconductor that the same argument apply to)

cc/ @PeteHaitch @const-ae

[HenrikBengtsson]

Ah... I hit submit before adding:

(*) Yes, DelayedMatrixStats depends on other Bioconductor packages to support specific data types but maybe those could be Suggest:ed dependencies?

[LTLA]

DMS has some pretty hard dependencies on the BioC stack; DA isn't really optional, as the whole purpose of DMS's existence is to wrap matrixStats methods for DelayedArray objects. Installing DMS without installing DA wouldn't make much sense.

[HenrikBengtsson]

Ok. So, if not possible for DelayedMatrixStats, the question/suggestion remains for MatrixGenerics and sparseMatrixStats.

[LTLA]

I'll throw in my 2c.

I had also considered this question for a few of my packages that don't really have a hard BioC dependency, e.g., basilisk, beachmat (<2.1). These are infrastructure packages that could have been generally useful on CRAN. In the end, I decided against it in favor of the BioC build system for a variety of reasons:

• Familiarity. This goes both ways - the BBS maintainers (hi @hpages!) are also familiar with me, so I can trust that they will help with debugging some of the more difficult issues. For example, getting basilisk to build across all systems was an awful experience, and I can't imagine CRAN maintainers would have spared the time to help me.
• The separate devel/release streams, which simplify development and experimentation without disrupting users. Specifically, I can co-develop solutions with other package maintainers in a shared CI environment, which is very useful for collaboration.
• Automation. I can just push my changes to the BioC git server and it gets deployed the next day, no questions asked. IIUC pushes to CRAN go through manual review (how do they find the time!?) and the repo policy suggests that updates occur no more than every 1-2 months. That's a pretty long interval in my world, especially on the devel stream. Hell, I have some GitHub Actions that automatically to nightly pushes to the BioC Git servers - I imagine that CRAN wouldn't stand for any of that.

Of course, I appreciate the cost to users not knowing or wanting to use Bioconductor, but putting it on BioC didn't inhibit me from solving the problem that I built the package for, so I didn't worry too much about it.

[hpages]

Yep, for all these reasons.

Note that you could also make that case for S4Vectors, IRanges, and a few other core infrastructure packages. There's nothing specific to Bioconductor about Rle, DataFrame, Hits, IRanges, Views, or NumericList objects. It's just that maintaining such a complex class hierarchy on CRAN would not be practical. It's a lot easier with fast cycles between pushes and daily build/check reports. Also a lot better for everybody's health.

'xcuze me but I have to go take care of the big bird now... Happy Thanksgiving!

[HenrikBengtsson]

Happy Thanksgiving to you too.

[PeteHaitch]

My reasons are similar to @LTLA and @hpages, although not as strongly held/felt since I don't maintain anywhere near as many packages as they (or you, @HenrikBengtsson) do!

I do still think there might scope for MatrixGenerics (and perhaps even sparseMatrixStats) to be on CRAN since there's nothing specific to Bioconductor about these and they are quite tightly coupled to matrixStats (even if the coupling is in spirit rather than formal dependencies). In fact, I raised this topic a couple of years ago when I first started on MatrixGenerics (#2) where we had a brief discussion. But we ultimately resolved to go via BioC for the aforementioned reasons of familiarity/intimacy with BioC development process and expertise.

Personally, I think I'd be comfortable with a migration to CRAN for MatrixGenerics when the package/API is stable, but there's still a bit of work to do on that front (particularly with regard to DelayedMatrixStats) which may force reconsideration of some decisions in MatrixGenerics(?).

[const-ae]

I am just catching up again with my Github issues, sorry.

One of the contributing factors for me was that MatrixGenerics repo already existed under the Bioconductor brand on GitHub. And it felt natural to put MatrixGenerics and sparseMatrixStats on Bioconductor together.

I think I'd be comfortable with a migration to CRAN for MatrixGenerics when the package/API is stable, but there's still a bit of work to do on that front

I would also be fine with moving MatrixGenerics and sparseMatrixStats to CRAN. I maintain packages at both repositories and for me both maintenance models work.

However, I actually do wonder what a bit about the potential use-cases for sparseMatrixStats outside single cell transcriptomics (but that could also just be my limited creativity). I think most people who store their data in sparse matrices want to ignore the non-explicit elements, whereas I treat them as zeros.