At one of my previous professional engagements, my boss was talking about internal open source and that we want to start adopting this concept within the organisation.

Now let me be clear about one thing - in my humble opinion, it is always better to participate in the “open” open source. It’s a service to yourself, to your colleagues, the engineering community, many industries, basically a service to mankind, and after all we are using these nifty open source libraries and products all the time. I can’t find a good reason why companies and engineers should not participate in open Source. The most common excuse I hear is “it’s a liability” or it’s “a responsibility we can’t take right now.”. Of course it takes a step from creating a library for internal use to sort of transform it into something more abstracted, it introduces some extra effort. But to be honest, as a good engineer and a great team committed to producing excellent working software, you want to do this step anyway.

Nevertheless, I can see internal open source as a way or a starting point to open up your cooperation to that concept of open source contribution. Also, within smaller and larger organisations, it can be beneficial to adopt the Open Source model to increase code share between the teams. Lastly, the thing you want to start sharing with each other might be something super specific to your organisation and your use case, and it might also contain some IP you don’t want to give away with a free open source license.

The concept of internal open source plays very well with microservice architectures under certain assumptions, and it is supported a certain agile organisation design with chapters or communities of practice creating a culture of exchanging knowledge between teams and agreeing to common functionality.

The Internal Open Source process can also apply very well to services and applications.

Internal Open Source Pre-Conditions

• need to agree on a common language - the value is reduced if many languages are in use without a cross-compilation
• think in libraries and modules - or in applications / independent services
• reorganise your code base to externalise libraries that do a certain thing and that you can see being useful to other people in your organisation
• have a person or a team to be the maintainer for the library
• encourage other people in your organisation to participate
• platforms like gitlab or github are making it really easy to facilitate the governance through merge requests and issue tracking

Steps to Adopt Internal Open Source

Decide on a Platform

Github or Gitlab are both excellent. Personally I am a huge fan of Gitlab.

Decide on standards

Some things you need to think about: * release notes and change log * tagging * test coverage * code style * code quality checks * vulnerability checks * documentation of interfaces * contribution guide

Agree on Governance

Here are some questions you need to ask yourself:

• who is owner of the project?
• what is the merge request process?
• what is to be expected when someone raises an issue?
• how do you agree on a roadmap going forward?

Have a CI process

The new library should be integrated, tested and packaged automatically. In Github, you can do that with TravisCI, in Gitlab you got Gitlab CI built in. Steps that the CI process should include: * automated execution of test suite * execution of code analysis * vulnerability checks * packaging of the artefacts as a library or docker image

Use Semantic Versioning

Following SemVer as a rule to version the libraries will help the users of the library

Have a Release procsss

A release process should include the following