Hi, this manifesto is based on my experience as the head of the OSPO at my previous company. Also, I am not a lawyer nor a legal representative and these are my personal recommendations.
Introduction
The growing adoption of open source code is outstanding. You can't deny it. Many studies proved that more and more companies use and contribute back to open-source tools. However, many enterprises who use massively use open source code don't have a clear understanding of how the open-source community really works. The contribution model of open source is "slightly" different from the proprietary model.
One of the recommended ways to fully understand and master the consumption and contributions of open source code is to officially create a dedicated team whose role is to educate, both internally and externally, about the open-source culture. Such team is referred to it as the Open Source Office Program or OSPO for short.
The idea of the OSPO had been initially introduced by Google in 1999, and since then other companies have adopted it: Facebook, Microsoft, Salesforce, Amazon, Zalando, Dropbox and many more. The OSPO has a major role in any company that takes open source so seriously. The main role of the OSPO is to entitle the internal company open source strategy (or help establish one), explain and guide the use of open source code internally.
Your company can only benefit from adopting open source!
This manifesto explains why and how to create an OSPO team inside your company, and tries to illustrate how open source could be good for your business.
The OSPO at your company
The OSPO team works as an autonomous team, as Marketing and Sales. This team report to top management. Members of the OSPO team works in collaboration with other teams (Engineering, Marketing, Legal and Sales) in order to:
- Embody the open-source strategy of your company both internally and externally.
- Provide internal support and mentoring for open-source contributions by internal contributors (employees).
- Engage with internal teams and external communities.
Let's start off with the parts that would most interest your business: the metrics!
Metrics
The OSPO team with the help of the engineering teams who are maintaining the company's open-sourced code should be able to identify and track some metrics in order to better understand the use of your company's open-source code.
Some of the metrics might be...
01. Open issues and Pull Requests
One of the most important metrics the maintainers should keep an eye on are the number of open issues and PR.
Having a long list of open issues and/or PRs lasting for a long period is definitely a red flag. This is something the team should address as soon as possible. External contributors and users may think the company is not taking that project too seriously or probably the project has been abandoned.
02. Popularity and adoption
One of the easiest yet very important metrics your company should track is the number of people "following", "forking", "staring" or contributing to a particular project.
03. Analytics
In case of toolings such as Command Line Interface (CLI) tools and downloaded binaries, the OSPO team with the help of the legal team may decide to add a tracking system of a particular project's usage.
The OSPO team must make sure this tracking system is explicitly mentioned in the company's privacy policy (or for a particular project's privacy policy) and should be approved by legal.
Keep in mind that users might also opt-out in which case no tracking information will be collected.
04. Social media
Another metric the OSPO team can track and pay attention to are the mentions on the different social media. What do users think about your company's particular open source project? What is the number of good and bad impressions?
If that project has a dedicated account, the metrics to track are the number of active/real followers, interactions, etc.
05. Number of downloads
For projects that are distributed on public registries such as NPM, Maven or Brew, tracking the number of downloads is also a good indicator of adoption.
06. Unique visitors to your documentation
For projects that are distributed as an SDK, another metric to track is the number of unique visitors to the official documentation.
This is a great fallback metric for users who have opted-out from analytics, or who are using your code behind a corporate firewall.
The benefits of OSS for your company
Believe it or not, having a well defined open-source strategy and successful open source projects can be very beneficial for your company and your business.
07. Positive impact
Establishing the company as an active and serious contributor to the open-source community will indirectly have a positive impact on both your company itself and any potential partners. Having a successful open source project used by thousands if not millions of developers and users can only help grow the company's notoriety.
08. Hiring
The company's open-source contributions will also have a positive impact on potential new candidates who would want to join your company. Some of those passionate engineers have probably already contributed to one of your open source projects, which means they are already familiar with all the technical stack and won't need a longer onboarding period.
09. Business Partnership
On the business side, the company's investment in open source won't go unnoticed. Other companies might want to partner with your company because they had the chance to use one of your open source projects and witnessed your company's technical assets.
The OSPO team responsibilities
10. Team members
The OSPO team consists of different skilled housekeepers form different internal organizations: engineering, marketing and legal. The team should be able to provide technical help, address legal concerns with open-source licenses and possible litigations.
11. Communication channels
The OSPO team acts as the spokesperson of your company. They are the public face for your company when it comes to OSS announcements, on different media such as GitHub, Gitlab, Gitter, IRC, mailing list, Twitter, etc... as well as public event and conferences.
12. Public repository
The OSPO team manages the public repository where your company's OSS code is hosted (Github, Gitlab...etc). The team makes sure that all public repositories comply with your company OSS guidelines.
13. Code of conduct
The OSPO team will guarantee that every contributor to your company's open-source code will follow a well-defined code of conduct. Any Code of Conduct violation must be notified to the OSPO team through any media, probably a dedicated email address codeofconduct@company.com.
14. Choose the right license
Before deciding to open source your company's code or using external open-source code, the OSPO team must define and approve the right open source license to use, with the help of the legal department. This will help avoid any possible litigation.
An open-source license allows a piece of code to be freely used (as in Freedom), modified and shared while complying with well-defined guidelines.
The 2 most used permissive open-source licenses are MIT and Apache 2.0.
Make sure to read and understand the terms of OSI licenses before you choose: https://tldrlegal.com/. Ask your legal department for an assistant if needed.
15. CLA: Contributor License Agreements
The OSPO team, with the help of the legal department, can decide whether to set up or not a CLA (Contributor License Agreements) for all or a subset of your company's open-sourced projects.
Contributors to these projects must digitally sign this CLA before they can contribute any code.
Make sure to set up and automate this step as part of your company's contribution process.
16. OSS distributions
Your company distributes its open-source projects through a public repository (Github, Gitlab...etc), and these projects are available to use freely (without restrictions). Individuals and organizations may use these projects in compliance with the terms of their licenses.
Any noticed violation of the license should be reported and the OSPO team must take action.
17. Internal contributions
A bunch of companies does offer a 20% time (or similar) to their employees so they can work on side projects or contributes to open source projects.
The OSPO team is supportive of these kinds of initiatives and must provide all the help and mentoring needed.
18. External contributions
The OSPO team is also supportive of external contributions. These contributions are beneficial for the adoption and success of your company's open-sourced code. The OSPO team should provide the same assistance and help to the maintainers of your company's open-source projects. These are usually the company's own employees (this is not always true).
19. Code that can be open-sourced
In theory, your company can decide to open source all or only parts of its IP (under the right license). This might seem contradictory or even controversial but if the code is mature enough and already stable so external individuals and companies can adopt it, they will; and by doing this, they would certainly want to contribute back and send feature requests and bug fixes.
However, in the interest of the company's project's own success, the open-sourced code should be of good quality (both technical and documentation). The OSPO team must make sure the code being open-sourced adheres to the internal quality guidelines (create one if needed). Any open-sourced code that does not showcase the technical expertise of the company may simply backfire.
20. Contributions celebrations
The OSPO should be able to identify and celebrate both internal and external active and regular contributors. Internal contributions can be celebrated through the company's internal communication media (newsletter, blog, etc.). External contributions can be celebrated online, with the help of the marketing team.
21. Dealing with conflicts
Any licensing infringement or IP related issues should be immediately taken care of by the OSPO and legal teams.
Other technical or personal conflicts should also be handled as soon as they happen and resolved either by the open-source project maintainer or the OSPO team.
Any violation of the company's Code of Conduct should also be taken seriously and the OSPO team must take action if needed.
Conclusion
Investing in an OSPO team and a good open-source strategy can be really beneficial for your company, your employees, your business and the open-source community.
Does your company have an OSPO team? What's your company's open source strategy? I'd be interested in hearing your story.
Illustrations are credited to https://undraw.co/license
Oldest comments (4)
I wouldn't find this very convincing if I wasn't already on board with OSS. Only 3 of these reasons (#7,8,9) actually support why OSS is good for business. Most of the other reasons are about what a pain in the neck it would be. Some of the reasons (#11-15) say to me as a developer, here's a bunch of new hoops you're going to have to jump through to contribute to OSS, and by the way the OSPO will hereafter be taking credit for the contributions you've already been making. (Maybe the piece could use an edit.)
Thanks for the feedback, Joseph.
This whole piece is about how to build an open-source strategy for your company. I have never said this is gonna be an easy journey. But the end result does worth it.
However, I don't understand your last comment about the OSPO taking credit for your contributions? Wanna elaborate? I thought #20 was clear about how the OSPO should be celebrating individuals' contributions?
Nice post!
I have referenced it in my own article
Contributing to open-source is like dancing Tango
Jean-Michel Fayard γ» Oct 11 γ» 6 min read
Awesome! Thank you.