Scrolls
5 min read
On this page

Releasing Open Source

Deciding to open source company code is easy. Doing it well is hard. The decision involves legal review, intellectual property considerations, license selection, documentation, community setup, and an ongoing commitment to maintenance. Companies that release open source without planning end up with abandoned repositories bearing their name, which damages their engineering brand more than never releasing at all.

When to Open Source Company Code

Not everything should be open sourced. The decision depends on whether the code provides competitive advantage, whether it benefits from community contributions, and whether your company is prepared to maintain it publicly.

Good Candidates

Code worth open sourcing:
- Shared infrastructure tools (build tools, deployment scripts)
- Non-competitive libraries (HTTP clients, serialization, logging)
- Developer tools (CLIs, editor plugins, testing utilities)
- Standards implementations (protocol libraries, format parsers)
- Internal frameworks that solve common problems
- Research implementations (papers, algorithms, benchmarks)

These categories share a common trait: they are not the source of your competitive advantage, and they benefit from community contributions and bug reports.

Poor Candidates

Code you should not open source:
- Core product code (your competitive moat)
- Code with embedded business logic specific to your company
- Code that depends on proprietary internal services
- Code with hardcoded credentials or internal URLs
- Code that cannot be extracted from the monorepo cleanly
- Code nobody on the team wants to maintain publicly

The Strategic Question

The key question is not "can we open source this?" but "should we, and will we sustain it?" Open sourcing code creates an obligation. The community will file issues, submit PRs, and ask questions. If your team ignores them, the project's reputation (and your company's) suffers.

Decision framework:
1. Does this code provide competitive advantage? If yes, stop.
2. Would the community benefit from this code? If no, stop.
3. Would the code benefit from community contributions? If no, reconsider.
4. Is the team willing to maintain it publicly for 2+ years? If no, stop.
5. Can the code be extracted without exposing proprietary systems? If no, stop.
6. Does leadership support the ongoing time investment? If no, stop.

Before releasing code as open source, it must go through legal review. This protects the company from intellectual property disputes and ensures the code does not expose proprietary technology.

IP Ownership

The first question is: who owns the code? In most employment agreements, code written by employees on company time is company property. But there are edge cases:

IP ownership checks:
- Was the code written by employees or contractors?
- Do contractor agreements assign IP to the company?
- Does the code include any third-party code?
- Are third-party licenses compatible with the chosen open source license?
- Does the code implement any patented algorithms?
- Has the code been reviewed for trade secrets?

Patent Considerations

If the code implements patented technology (your company's or someone else's), open sourcing it has patent implications. Some licenses (like Apache 2.0) include explicit patent grants. Others (like MIT) do not. Legal counsel should review patent exposure before release.

Export Control

Some software is subject to export control regulations, particularly cryptography. If your code implements encryption algorithms, it may require an export control review. This is especially relevant for US-based companies.

License Choice

Choosing the right license is a strategic decision that affects adoption and community dynamics.

Common choices for corporate open source:

Apache 2.0:
- Permissive, includes patent grant
- Most popular for corporate projects
- Used by: Kubernetes, TensorFlow, Spark

MIT:
- Simplest permissive license
- No patent grant
- Used by: React, VS Code, .NET

BSD 2-Clause:
- Similar to MIT
- Used by: FreeBSD, Flask

MPL 2.0:
- File-level copyleft
- Modifications to MPL files must be shared
- Rest of your code is unaffected
- Used by: Firefox, Terraform (before license change)

For most corporate open source releases, Apache 2.0 is the default choice. It is permissive enough for widespread adoption and includes patent protection that gives both the company and users legal clarity.

The Approval Process

Establish a repeatable approval process so that teams know how to release open source without ad-hoc decision-making.

Approval process:
1. Proposal
   - Team submits proposal: what, why, which license
   - Includes maintenance commitment (who, for how long)

2. Technical review
   - Code reviewed for proprietary dependencies
   - Credentials, internal URLs, and secrets removed
   - Code can build and run outside the company environment

3. Legal review
   - IP ownership confirmed
   - License compatibility of dependencies checked
   - Patent review if applicable
   - Export control review if applicable

4. Security review
   - No hardcoded secrets
   - No exposure of internal architecture details
   - Security scanning of the codebase

5. Approval
   - Sign-off from legal, security, and engineering leadership
   - Maintenance plan documented
   - Publication schedule agreed

Launching the Project

A launch without documentation, examples, and community infrastructure will fail. First impressions matter. A developer who visits your repository and sees a bare README with no examples will leave and not come back.

Documentation

Minimum documentation for launch:
- README.md: What it does, why it exists, quick start
- Getting started guide: installation, first use, basic example
- API documentation: all public interfaces documented
- Architecture overview: high-level design for contributors
- CONTRIBUTING.md: how to contribute
- CODE_OF_CONDUCT.md: community standards
- LICENSE: the license file
- CHANGELOG.md: version history

Examples

Working examples are more important than documentation. A developer who can run an example in five minutes is more likely to adopt the project than one who reads ten pages of docs.

Example requirements:
- Complete, runnable examples (not fragments)
- Cover the most common use cases
- Include a "hello world" that works in under 5 minutes
- Test examples in CI to ensure they do not break

Community Setup

Community infrastructure:
- Issue templates: bug reports, feature requests
- PR template: what to include in a pull request
- Discussion forum: GitHub Discussions, Discord, or Slack
- CI/CD: automated testing on PRs
- Labels: good first issue, help wanted, bug, enhancement
- Security policy: SECURITY.md with disclosure instructions

The Launch Announcement

Launch channels:
- Company engineering blog post
- Hacker News / Reddit / relevant community forums
- Twitter/X and social media
- Conference talks (if timing aligns)
- Internal announcement to employees

Do not over-hype the launch. An honest description of what the project does and why you built it is more effective than marketing language. Developers are skeptical of corporate announcements. Let the code speak for itself.

Ongoing Commitment

The launch is the beginning, not the end. The hardest part of corporate open source is sustaining it after the initial excitement fades.

Who Maintains It

Maintenance models:
- Dedicated team: a team whose job includes open source maintenance
- Rotation: engineers rotate through open source duty
- Volunteer: engineers maintain it in their spare time
- OSPO: the Open Source Program Office coordinates maintenance

Best: Dedicated team or rotation with explicit time allocation
Worst: Volunteer with no time allocation (leads to abandonment)

Time Allocation

Maintenance is real work that requires real time. Engineers need explicit time allocated for:

Ongoing maintenance tasks:
- Triaging issues (30 min to 1 hour per week)
- Reviewing PRs (1 to 3 hours per week, depending on volume)
- Fixing bugs and security issues (variable)
- Updating dependencies (1 to 2 hours per month)
- Releasing new versions (2 to 4 hours per release)
- Responding to community questions (30 min to 1 hour per week)
- Writing release notes and changelogs (1 hour per release)

If management does not allocate this time, it will not happen. Engineers will prioritize product work over open source maintenance because product work appears in performance reviews and open source maintenance often does not.

The Abandonment Risk

Signs a project is being abandoned:
- Issues go unanswered for weeks
- PRs sit unreviewed for months
- No releases in 6+ months
- Maintainers stop responding
- Dependabot PRs pile up

Consequences of abandonment:
- Users stuck on unmaintained software
- Security vulnerabilities go unpatched
- Company reputation damaged
- Community trust lost
- "Company X abandoned their project" becomes the narrative

If you cannot maintain the project, archive it. A clearly archived project with a "this project is no longer maintained" notice is better than a project that appears active but is actually dead.

The Risk of Abandoning a Project with Your Company Name on It

When a project has your company's name on it, its health reflects on your engineering brand. A well-maintained open source project attracts talent. An abandoned one repels it.

Before releasing, ask:
- "If we stop maintaining this in 2 years, will it damage our reputation?"
- "Are we prepared to either maintain it or gracefully archive it?"
- "Would we be better off contributing to an existing project instead?"

Sometimes the right decision is not to release a new project but to contribute features to an existing one. This avoids the maintenance burden while still building your engineering brand.

Common Pitfalls

  • Releasing without a maintenance plan. The launch gets attention, but maintenance is what matters. Without a plan, the project will be abandoned within a year.
  • Skipping legal review. IP disputes after release are expensive and embarrassing. Do the legal review before publication.
  • Bare-minimum documentation. A README that says "install it and run it" is not documentation. Developers need working examples and clear guides.
  • Over-promising community engagement. Do not promise "we review all PRs within 48 hours" if you cannot deliver. Under-promise and over-deliver.
  • Open sourcing code that depends on internal systems. If the code cannot build and run outside your company, it is not ready for open source.
  • No clear ownership. "Everyone maintains it" means nobody maintains it. Assign specific people and allocate their time.

Key Takeaways

  • Open source company code when it is non-competitive, benefits from community contributions, and your team is committed to long-term maintenance.
  • Legal review covering IP ownership, license compatibility, patent exposure, and export control must happen before any code is published.
  • Apache 2.0 is the default license choice for corporate open source due to its permissive terms and patent grant.
  • Launch with complete documentation, working examples, community infrastructure, and a maintenance plan, not just a README.
  • Ongoing maintenance requires explicit time allocation in engineering schedules. Volunteer-only maintenance leads to abandonment.
  • An abandoned project with your company's name on it damages your engineering brand. If you cannot maintain it, archive it gracefully.