Six? steps to open sourcing - review of content

[Dr William A Bryant]

Thanks this is a great template to start framing projects with an open source mindset. A few points on the steps to open sourcing. First I count 10 sections, but not sure if these sections correspond to the 6 steps of not. I would recommend a numbered list in the intro to the section to give readers some bearings when reading.

Also it would be great to get a more consistent structure in each subsection, e.g.:

1. Requirement summary: what is the key take-home for the section,
2. Detail: specific list of steps that should be satisfied (and are they mandatory for all projects?),
3. Explanation: why this is required/what it does/why it is a good idea,
4. Scope: how much is relevant to different projects (when they can be anything from collections of functions up to large open source apps)?

A few specific comments:

1. Repos: there is an additional sublist of requirements within this - could this be specifically linked to the checklist (Appendix B) or just a list in the "Detail" section?
2. Licences: some examples in this regard would be really useful to get a feel for when each licence is appropriate. Further there is a lot of text on regulatory requirements, but this is not very informative unless you have a good grasp on the regulatory landscape. e.g. what is a "digital health tool"? How is clinical use defined? Perhaps a list of criteria for repos that can be open-sourced, rather than the other way round, so that smaller PoC or non-clinical analytics projects can be checked off without the need of an expert in healthcare regulation? Also, what is the relevance of the regulatory discussion specifically to open-sourcing as opposed to health-related development in general? If the problem is not specific to open-sourcing then perhaps it should sit separately to this?
3. Team responsibilities: how does the development team know when to involve a Data Protection Officer? Do they have a role if there are no real data included in the repo?
4. Commits etc: where development occurs in a private repo elsewhere, are meaningful release note sufficient in lieu of meaningful commit labels (which would not be available on publication to the open)?
5. History: could this be folded into the commits section?

[Andrew Harding]

Hi William, some great structural suggestions here I'll get to swiftly, including the 6/10 which is something I'll keep an eye on as we edit and consolidate into the future!

The regulation question is really interesting and something we're talking to the Multi Agency Advisory Service to work through. Some of those definitions are things we can define or refer to in the policy, but MAAS is keen to catch folks who are coming from this policy so we're figuring out what that looks like. Open source is of particular relevance to Software As Medical Device regulation, because the regulation kicks in every time a tool is implemented, which means it's of concern every time the code is copied to a new context. There's scope here to use open source to help make the regulatory process easier and more efficient both with compliance that's easier to reproduce and applications that are easier to track.

The latest MHRA consultation includes sections on open source. I believe it's in an analysis stage at the moment but as that updates so will we.

The question of 'real data' is also something under pretty hefty discussion. I can see that your role is super relevant there, can we maybe set up a chat to talk about that and your 'Open data' issue further?

[Dr William A Bryant]

Thanks I'd love to chat - I'll send through an email to set up a time.

[Andrew Harding]

Most of this is now folded in, or can be with static site generation. Those structural notes are still great but I need to figure out how they work with an HTML version.