I have been focusing most of my dev team theory around InnerSource best practices lately.
Just like McDonald’s original saying Ich Liebe Es or the better known I'm loving it, I am loving it. 😍 (see link below)
What is InnerSource?
InnerSource is the practice of applying open-source methodologies and practices within an organization’s internal software development. Think of it as “open source behind the firewall” - it brings the collaborative culture, transparency, and development practices of open source to proprietary software development.
For me, the hardest part of any project is reuse.
I’ve been in teams where we end up siloed and not working together as a whole for a common purpose. As the project goes on, development becomes slower and more error prone. Why? 😱
Common anti-patterns I’ve observed:
- Code duplication across teams building similar functionality
- Knowledge hoarding instead of sharing best practices
- Reinventing the wheel because discoverability of existing solutions is poor
- Documentation debt that accumulates over time
- Tribal knowledge that leaves with team members
Documentation is started and then pushed over the line for some arbitrary date then forgotten about the day after. The benefits below stand out to me, and being in multiple projects of varying sizes I see the potential impact of getting this right:
Key Benefits of InnerSource:
1. Code reuse across the organization grows immensely.
- Shared component libraries reduce duplication
- Common patterns and frameworks emerge naturally
- Cross-team contributions improve code quality
- Inner source marketplaces help discover existing solutions
2. Cross-team collaboration becomes relatively frictionless.
- Pull request workflows enable async collaboration
- Shared coding standards reduce friction
- Mentoring relationships develop across team boundaries
- Knowledge transfer happens through code reviews
3. Development becomes faster.
- Reduced time to market through reuse
- Faster onboarding with better documentation
- Shared tooling and CI/CD pipelines
- Community-driven improvements to common components
4. Quality documentation is discoverable.
- Living documentation that evolves with code
- Searchable knowledge base of patterns and practices
- Community-driven FAQs and troubleshooting guides
- Architectural decision records (ADRs) that preserve context
Implementation Strategies:
Technical enablers:
- Monorepos or well-organized multi-repos with clear ownership
- Standardized project templates and scaffolding
- Automated testing and deployment pipelines
- Code review culture with constructive feedback
- Documentation-as-code practices
Cultural practices:
- Trusted committer model - experienced developers who mentor contributors
- Contribution guidelines that lower barriers to entry
- Regular showcases of inner source projects and contributions
- Recognition programs for cross-team contributions
Conclusion 🐒
I believe I can do better so I will.
My personal action items:
- Start with documentation - Making sure every project has clear contribution guidelines
- Champion code reviews - Using them as learning and knowledge sharing opportunities
- Build reusable components - Thinking beyond the immediate project needs
- Share learnings openly - Writing about what works and what doesn’t
- Mentor across teams - Helping others adopt InnerSource practices
The key is starting small, showing value, and building momentum. InnerSource isn’t just about code - it’s about building a culture of collaboration, transparency, and continuous learning within your organization.