Open Source
Inner Source: OSS Inside a Company
PayPal applied the GitHub workflow to 1,500+ internal repositories - and development velocity increased by 30%. How do OSS practices work inside a corporation?
- PayPal Inner Source: 1,500+ repositories, 30% velocity increase - publicly presented at InnerSource Summit 2015
- Google open-sourced Kubernetes in 2014 - now 3,000+ contributors from 500+ companies, including Amazon and Microsoft
- TypeScript (Microsoft, 2012): internal tool → JavaScript development standard with 40M+ users
- IBM inner source programme: 10,000+ developers, significant reduction in code duplication across the organization
What is inner source
**Inner Source** means applying open source development practices to a company's internal repositories. The code stays private, but the processes - open pull requests, public code reviews, transparent issue trackers - are available to everyone inside the organization.
**InnerSource Commons** (innersourcecommons.org) is an open source organization with patterns, books and conferences on inner source. The Learning Path there is the recommended starting point for any adoption effort.
Team A owns an internal library. Team B wants to add a feature. Under the inner source model - what happens?
How to contribute to OSS from work
Working at a company doesn't prevent contributing to OSS. But it requires understanding the applicable IP rights and the company's policy.
**Don't stay silent:** if you want to contribute to OSS, tell your manager. Most companies encourage it - it makes you more valuable and improves the company's reputation. Better to ask than to accidentally violate an IP agreement.
A developer at a major tech company wants to add a feature to an open source ORM. The project requires an ICLA. What should they do?
OSS strategy for a company: why open-source internal tools
Many of the largest OSS projects were built inside companies and later opened. React (Meta), TensorFlow (Google), Kubernetes (Google), TypeScript (Microsoft) - all started as internal tools.
**Open-sourcing failures:** not everything opened up becomes a success. Many projects are open-sourced and abandoned within a year ("open source washing"). Signs of genuine OSS: active maintainers, responses to issues, external PRs being accepted.
InnerSource only works in companies that already have a strong open-source engineering culture
InnerSource spreads through demonstrated success on 1-2 projects, not cultural preconditions. SAP, PayPal, and GitHub adopted it inside traditional corporate hierarchies before engineering culture fully shifted
Waiting for the right culture creates a catch-22 - culture forms through practice. Starting small and proving value is the actual adoption pattern, not a culture-first prerequisite
Meta open-sourced React in 2013. The primary business reason was:
Key takeaways
- Inner source = OSS processes (fork/PR/review) for private corporate repositories
- Trusted Committer - the maintainer role in an inner OSS project, accepting PRs from any team
- Contributing from work: check the IP agreement, find out if a CCLA is needed, document permission
- Companies open-source code for hiring, external contributions and market standardization - not altruism
- React, TypeScript, Kubernetes - all started as internal tools inside large companies
Related topics
The final lesson of the course - inner source closes the loop: from OSS practices to applying them in any context.
- CI/CD for OSS — Inner source uses the same GitHub Actions patterns
- Becoming a maintainer — Trusted Committer in inner source = the maintainer role in OSS
Вопросы для размышления
- Your company has 50 teams, each of which wrote their own date-formatting utility. How would you introduce inner source and convince teams to contribute rather than building their own?
- React was created by Meta for their own needs. If Meta decided to stop maintaining it tomorrow - what would happen to the ecosystem? How does the community protect against this scenario?