Open source an internal project only if you can answer six questions: why, who owns it, is the code clean, which license, who will maintain it, and what happens if you stop. If any answer is unclear, wait. A public repository without a maintainer is a liability, not a gift.
Why companies do it
The Linux Foundation guide notes that different companies have very different reasons. Some open source to build an ecosystem around a product, some to attract contributors, some to share the maintenance load. It also quotes a program leader saying you do not want to be the only people contributing to your own project, because you cannot hire all the smartest people. Know your reason, since it shapes everything else.
The six questions
| Question | What a good answer looks like |
|---|---|
| 1. Why? | A specific goal, such as adoption, contributions or standardization |
| 2. Who owns it? | A named team that will act as maintainers, with executive support |
| 3. Is the code clean? | No secrets, customer data, internal URLs or code you do not own |
| 4. Which license? | Chosen by counsel, compatible with every dependency |
| 5. Who maintains it? | Time budgeted for reviews, releases and security reports |
| 6. What if we stop? | An exit plan: archive, transfer or hand over |
Check the code is ready
- History. Secrets in old commits are still secrets. Scan history, or publish a fresh repository.
- Dependencies. Their licenses must be compatible with the one you choose. Inventory them first.
- Third-party code. Confirm you have the right to publish every file.
- Trademarks and names. Decide who owns the logo and name.
- Security. Review the design for assumptions that only hold in your private network.
Check the governance is ready
Write a contribution file, a security reporting route and a short governance note. See what a contribution policy should include and a GOVERNANCE.md for a company-led project. The Open Source Guides advise discussing internally how the company will maintain the project and make decisions, and explaining publicly anything particular to its involvement.
When to say no or wait
| Situation | Better move |
|---|---|
| No maintainer time | Do not publish yet |
| Code mixes proprietary and generic parts | Separate them first |
| The project is a competitive core | Keep it closed or open only an interface |
| You cannot review outside contributions | Publish read-only, say so clearly |
The guide mentions rules that help determine when code should be released as open source or kept as intellectual property. Write yours down.
After release
Expect outside issues and security reports. Have a first reply template ready. See a security report first reply template for maintainers. Track dependencies of the project itself, since users will hold you to account for them.
Where Safeguard fits
Before release, Safeguard's SBOM and dependency scanning lists the components and licenses the project pulls in, and policies and gates can keep the repository clean after launch. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Check what dependencies a project would drag into public view.
Quick check
Is it safe to publish a repository with its full commit history?
Only if you have checked history for secrets and ownership issues. Many teams publish a clean snapshot instead.
Do we have to accept outside contributions?
No. You can publish read-only and say so, but state that clearly in the repository.
Sources
- Creating an Open Source Program, Linux Foundation and TODO Group
- Open Source Guides: Leadership and Governance
Last reviewed: 19 October 2026.
