Who's responsible for our cross-pharma code?

[dgkf-roche]

Sort of resurfacing a topic that @joseph-rickert raised in the R Validation Hub (feel free to weigh in if I've missed something).

If we have joint, cross-pharma code projects, who is responsible for their correctness or resulting decisions? Is it just assumed to be without any guarantees at all -- up to the user to decide whether it's trustworthy? If individuals are contributing from a mix of personal and company-affiliated accounts, does that change who is responsible?

In the R Validation Hub we have the luxury of being a working group under the R Consortium (and hence the Linux Foundation, with its storied history of managing free software projects), but we have a growing number of grassroots organizations that don't come with any sort of entity backing them up (thinking specifically about the pharmaverse and openpharma, though I'm sure there are plenty more).

I'm very relieved that things have gone quite smoothly so far, but to get ahead of any discontent, I think we should be asking ourselves: What happens when the direction and interests of the project are at odds between organizations, when licenses are violated, or when a bug has critical business implications?

I would expect this discussion to tackle the questions:

• Who is responsible for open code, and what guarantees of the code should be understood by end users?
• If we aren't already making this contract clear, how should we communicate it?
• Is it necessary to organize under an entity to sponsor these projects and alleviate such concerns?
• Can we settle on guidelines for cross pharma code efforts?

[MikeKSmith-Pfizer]

This is an important point for sure, and one that should be addressed at some point, even if it's not a topic of conversation at the posit::conf session. Thanks for bringing it up.

[epijim]

Thanks Doug - definitely an interesting topic. I have opinions on all of these questions 😀 , but as the topic is to propose topics rather than discuss them here 😆 , I'd add:

For Pharmaverse, they are linked to PHUSE. For openpharma, that GH org is governed by the non-profit 'Open Source in Pharma' (who run R/Pharma), but this topic is very timely as @danielinteractive and I were talking about a closer connection to statistical orgs just today.

I wonder if this is a topic could help build out the PHUSE OS guidance, or if we discuss take the learnings back for further discussion in that group. It touches on governance models briefly already (as well as indemnity and liability). And we have individuals with an interest, and history of discussing this point from 7 companies so far.

Would love to especially discuss this on the 18th:

Who is responsible for open code, and what guarantees of the code should be understood by end users?

I think a lot of our existing statistical codebase was built by passionate people that wanted to get their code out, but as something they did as a personal project - and a 'product mindset' (referring to the term you hear in agile/scrum rather than literal words) is just not present.

As a toy example - when I have released things to CRAN, I did it as I did something I thought maybe is useful to someone else, not as a product I wanted to build for others. I think I have only one package (on CRAN), where I actually wanted to keep growing it based on others feedback and collaboration (and the first time that happened we agreed to deprecate my package and make a new one with a different backend 😆 ). Just starting this discussion would be cool - as I assume there are many packages where life after first CRAN release just wasn't thought about.

Tagging @bailliem and @danielinteractive - I think the discussions coming out of R/Basel could be an awesome example of where this community building amongst statistical package authors could be a vehicle to help tackle Doug's proposed questions.

[danielinteractive]

Thanks @epijim for looping us in! Big questions for sure.

Legally, things are handled in the package and software licenses I think pretty clearly. E.g. I would be pretty sure no company would try to sue R core authors or R Foundation or something if there is a bug in the R software that leads to a wrong p-value. And actually the same for proprietary software since I am sure there will be enough legal statements to prevent that from the software vendor side.

From the side of the software engineering working group (see our goals e.g.) what we are trying to infuse into the biostats community is the skills and habits to become more responsible when writing R packages (and other code of course too, but that is the prime example) - for their own sake, their future own use but of course also for others using their code.

[MikeKSmith-Pfizer]

"An R package is for life, not just for Christmas"...

A governance board of key stakeholders would help here to prioritise development features or to react in the case of a significant bug or failure. In the event of failure, we would want to be sure that individuals are found to fix the bug and also (possibly independently) to verify the fix.

I have seen package development being driven by individuals or groups whose main interest has been to expand functionality, rather than refactor to address usability or efficiency. For academic groups this makes sense because you don't get manuscripts out of refactoring code. But for pharmaverse packages used in clinical trial reporting it will be important to make sure these are well maintained for efficiency and ease of use.