Open Source Policy

Recently I helped an organization to formulate its open source policy. I’m now open-sourcing this policy ;-).

Introduction

Our organization is using open source projects in our own products.

It’s only natural that we also contribute back to the open source community!

This document discusses the guidelines that apply to open sourcing code, documents, or visuals.

What can be open sourced?

• Code
• Visuals and designs (examples: icon libraries or fonts)
• Documents (examples: best practices, coding style guidelines)

This documents focuses on open sourcing code. Some principles also apply to visuals and documents, only the license will be different.

When does it make sense to open source your code?

1. Your code is usable outside our company: there is a clear “value” for other developers.
2. Your code has good test coverage.
3. Your code is well-documented.
4. Your code is relatively small (not much larger than, say, 3000 lines of code).
5. Your code is not dependent on internal systems.
6. Your code is not making life substantially easier for direct competitors.
7. Your code does not contain any code or libraries licensed from 3rd parties.

Ref 4) You and your team mates will have to support the code over the years and it’s easier to maintain 3 KLOC than 30 KLOC. We don’t have the same resources as e.g. Facebook who pays for multiple, dedicated teams to work on OSS.

Ref 5) Your code must work on its own, without needing any of our internal systems.

Ref 6) If your code would give our competitors a huge competitive advantage (e.g. it reduces their time to market to ship a competing feature) then it doesn’t make sense to open source it from a commercial point-of-view.

Step 1

Ensure the thing you want to open source ticks all seven boxes mentioned above.

Step 2

• Seek approval from the CTO or Head of Engineering to commence with step 3.
• Decide which license structure applies. In all but exceptional cases it will be the MIT license. See this article for an overview of the license considerations.

Step 3

• Write an awesome readme. See https://github.com/matiassingers/awesome-readme for examples and inspiration.
• Check your test coverage. Improve if needed.
• Check your documentation. Improve if needed.
• Ensure no customer names, keys, secrets, et cetera are present in your source code (which should never be the case btw!).

Step 4

Choose a “safe” name for your project. With safe I mean:

• Check if the name doesn’t yet exist on GitHub, GitLab, or elsewhere as an open source package.
• Check if the name doesn’t yield tons of non-technology related results on Google.
• Ask your colleagues for suggestions.

Step 5

• Commit your work to a new, (initially!) private GitHub repository.
• Ask your team mates for a thorough code/documentation review.
• Ask the CTO/HoE to review the files.
• The CTO/HoE will give the final thumbs up to make the repo public.

Step 6

• Set a monthly (preferably weekly) reminder in your calendar, or subscribe to GitHub notifications, to stay on top of issues reported by the community.

Tip: don’t fork this project in order to use a different version of the code in our products. It’s much better to use the code as-is to ensure constant improvements originating from our own use.