I never had imagined I'd write the Open Source Policy of a multi-billion dollar company. Here I am now, leading the Open Technologies Program Office at Postman, putting together what shall become exactly that. And while I'm at it, here's the principles, concepts and resources that I'm using. Just in case you get to be in a similar situation. 🫶
Split the policy up
One policy will probably not do it. Consider 4 areas, I call them "books", not all being in the initial responsibility of your Open Source Program Office (OSPO):
- Using Open Source as an individual or team
- Using Open Source in the Tech Stack of your products
- Contributing to Open Source
- Creating Open Source
Using Open Source as an individual or team
This probably needs the least regulation. You can't control it anyway, as people will be using Open Source the minute they start working. Chrome, VS Code, even your operating system - macOS, Windows, of course Linux <3 - contains a hell of a lot of Open Source. If your company decided to manage the individual use of Open Source, it is on your IT department to manage devices, installation, security and risk.
Using Open Source in the Tech Stack of your products
Let's assume your company is using Open Source to build its product or service. It could be that there's already something in place, but not called a policy. It could be a guideline, a memo or a full process on how to handle Open Source, who reviews the licenses, and where to list components. Find this and collaborate to make existing rules parts of the new Open Source policy. This likely needs investigation and collaboration.
Contributing to Open Source
Depending on your company's values and culture, contributing to Open Source could range from being considered a priority,
a high awareness lip service (e.g. "in our DNA"), it could be welcomed but not encouraged, or it could merely be tolerated or even discouraged. An Open Source Policy can help mature the company to a better member of the Open Source ecosystem by creating awareness for the principle that Open Source projects can only exist with contributions. And the responsibility for contributions are with the people using the projects. This part of the policy should make it as clear as possible what is necessary to contribute to Open Source as well as be as simple and intuitive as possible to remove barriers for people willing to contribute.
Creating Open Source
This is not for everyone, and it might be you'd never make use of this part of the policy. But chances are high some team one day has a motivation to transfer company intellectual property to Open Source. Be it a converter of some sort, or a web framework that the team came up with as a by-product. Put a lightweight process into place that enables the company to assign the tasks to the right people (e.g. legal review, code review, sign-offs), and manage maintenance over a period of time. There's no use in open sourcing some code and forget about it, arguing that somebody would take care if it mattered to them. This part of the policy should make clear that building and nurturing a community is an essential and indispensable part of open sourcing a project.
Pull in other stakeholders
IT, Engineering, Product, Legal - these are folks that may already have an interest in Open Source processes or see a value of better management (e.g. to manage risk).
You will probably end up suggesting the creation of an Open Source board or council of some sort.
Think of Open Source management as a cycle
You're trying out an Open Source project.
You like it so you consider using it more or in a workflow.
You consider using it for implementation in the tech stack.
You find issues or bugs, so you fix them to make your product better.
You create a helper tool and feel this could be beneficial to others.
You open source it, so others could use and contribute to it.
Others use your tool.
It all starts over.
Be open and comprehensible
During your research, you will run into the risk of using abbreviations and terminology. This shows that you are growing into your shoes, as you understand more and more of the topic. And you can be proud of this extended ability of understanding. Since you are writing this topic, you are probably also the most literate person when it comes to policies, licenses and strategy of Open Source. The ones reading this policy didn't have the time or opportunity to educate themselves as much, so to be open and inclusive, you will need to package all policies in a way that is understandable for them. For everyone in your company. On that same note it is important to bake into your policies your company's stance on diversity, equity inclusion and belonging. To require a Code of Conduct for contributions and newly created projects is a must.
Learn from others
Here's some great starting points for creating your Open Source policy. I found them useful. I hope you do, too!
Top comments (0)