Short answer
Yes, subject to a formal evaluation process led by the OSPO. Publishing an internal project as open source is a strategic decision that commits the organization’s reputation and requires legal, security, and governance reviews before any public release.
Detailed explanation
Why open source an internal project?
Publishing a project as open source can deliver significant benefits:
- Reduced maintenance costs by sharing the work with the community.
- Talent attraction — developers are drawn to organizations that publish high-quality code.
- Improved quality through community review and external contributions.
- Strategic influence over the ecosystem in the project’s domain.
- Reciprocity toward the OSS projects the organization benefits from.
Pre-requisite self-assessment
Before engaging the process, the team should evaluate the following:
Strategic justification
- What is the expected business benefit of opening this project?
- Does this code represent a differentiating competitive advantage that would be risky to expose?
- Is there a community likely to be interested in and benefit from this project?
Scope and volume
- What is the exact perimeter of code to be published? (avoid publishing more than necessary)
- Does the code contain secrets, credentials, tokens, or internal configuration data?
- Does it depend on proprietary components or internal libraries that cannot be published?
Intellectual property
- Does the organization hold full rights to all the code to be published?
- Have contributions from contractors or third-party consultants been incorporated? What are their rights?
- Are any patents potentially linked to the code?
The OSPO approval process
Step 1 — Initial request
Submit the publishing request form (available on the OSPO intranet page). Include: project description, strategic justification, intended code scope, and proposed license.
Step 2 — OSPO evaluation (timeline: [X] weeks)
The OSPO coordinates the following reviews in parallel:
| Review | Owner | Key checks |
|---|---|---|
| IP / Legal | Legal department | Patents, third-party rights, inbound CLAs |
| Security | Security team | Secrets in code, vulnerabilities, git history |
| Technical | Designated Tech Lead | Code quality, dependencies, documentation |
| Governance | OSPO | License, README, CONTRIBUTING, CODE_OF_CONDUCT |
Step 3 — Pre-publication preparation
Before going public, the project must include at minimum:
repo/
├── LICENSE # OSI-approved license of your choice
├── README.md # Description, installation, usage, how to contribute
├── CONTRIBUTING.md # Contribution guide, review process
├── CODE_OF_CONDUCT.md # Community code of conduct
├── SECURITY.md # How to report a vulnerability
└── CHANGELOG.md # Version history (recommended)
Critical: purge the git history of any secrets or sensitive data before publishing. The full history will be publicly visible.
Step 4 — License selection
The license is chosen in agreement with the OSPO based on the strategic objective:
- MIT / Apache 2.0 — maximize adoption (including commercial use).
- GPL / AGPL — ensure that improvements flow back to the community.
- See What licenses are approved?
Step 5 — Publication and ongoing stewardship
Publication is not the end of the process. An active open source project requires:
- A designated maintainer (or team) with allocated time to respond to issues and PRs.
- A defined release cadence.
- Monitoring of community health metrics (stars, forks, contributors, issue response time).
Typical process timeline
The total timeline varies depending on project complexity and review outcomes:
- Simple project, no IP concerns: 2 to 4 weeks
- Complex project, IP or security concerns: 6 to 12 weeks
Common pitfalls
- Publishing with a full unclean git history — tokens, passwords, or API keys may be buried in commit history going back years.
- Opening a project without a dedicated maintainer — a project that doesn’t respond to issues quickly gains a poor reputation and loses contributors.
- Choosing a license without analysis — a wrong license can block adoption or create legal issues later.
- Publishing the entire internal repository instead of a carefully scoped subset.