Building InnerSource Community: What Goes Behind the Scenes?
summary
Maintainers must make a component actually reusable, modularize it, and prepare repository readiness with clear docs, permissions and onboarding steps; register it or tag it so it achieves discoverability (or list it in a central InnerSource portal); publish governance (review lead times, ownership, conflict resolution), design archives and roadmaps for transparency, run office hours and community calls, acknowledge outside contributions and appoint trusted committers, and track KPIs like external PRs and reuse to prove the program works.
AI-written summary · about
chapters (21)
- 0:00InnerSource introduction
- 2:07What is InnerSource
- 7:23Assessing project reusability
- 8:29Making projects InnerSource ready
- 10:16Ensuring project discoverability
- 11:19Governance policies
- 12:03Transparency in projects
- 13:06Inclusive documentation
- 14:12Open mindset in teams
- 16:59Bridging to users
- 18:25Nurturing InnerSource community
- 19:06Acknowledging contributions
- 20:31Empowering community members
- 21:15InnerSource vs OpenSource
- 22:18Recognizing maintainers
- 23:05Q&A: Governance policies
- 24:49Q&A: Business alignment
- 26:15Q&A: Measuring success
- 27:41Q&A: Metrics storytelling
- 29:30Q&A: Security-isolated projects
- 32:48Closing remarks
related talks
24mInnerSource Patterns for Success
25mDriving the InnerSource Program at SAP
39mSolving (team) dependencies - the Open Source way
36mInnerSource at Scale: A Platform-centric Approach
16mOvercoming InnerSource Challenges: 3 pitfalls and 2 key success criteria
30mInnersource: open source collaboration patterns beyond public FOSS projects
09mInnerSource 101
40mBuilding an Open Source Community from the Ground Up: 10 Lessons Learned from Inner...