Open source / inner source

[mikemonteith]

Can we have some guidance around where open source should be used, and at a minimum we should be practicing "inner source".

https://en.m.wikipedia.org/wiki/Inner_source

I often find myself having to ask for read access to code within my own programme at NHS digital and my requests for read access to all developers by default falls on deaf ears.

[arctangent]

I think the "inner source" idea is a good one. It is important that code for a given system (or business domain) should be owned/maintained by a single team who should judge whether or not to accept pull requests from other teams (which is what the Wikipedia article says in its "quality assurance" section).

With respect to your first question, are you asking when we should use open source software (1) or when our software should be open sourced (2)?

If (1), then couldn't the answer be that we always avoid closed source software unless there is no open source alternative that meets the requirements? (I assume in our hypothetical situation it has already been decided that the code can't/won't be written in-house.)

If (2), then I see no compelling reason not to open source publicly-funded code unless there is a realistic and significant security risk. New systems/subsystems should be open source by default, and the argument for spending time to open source legacy systems (or parts thereof) is strengthened in proportion to their potential reusability by the wider community.

[mikemonteith]

I was asking about where we should open-source our own projects. I strongly agree with you that our position should be open source by default

[stefaniuk]

The wording of section "12. Make new source code open" of the NHS service standard is quite interesting.