Analysis of development velocity in an InnerSource context
summary
InnerSource claims faster development by standardizing tools and processes and the talk shows how to measure that: use Bitergia/CHAOSS analytics to compare metrics before and after adoption, focus on merge time and onboarding steps, and log obstacles with friction logs — an experiment found contributing an empty file to a closed project often takes over a month. Analysis finds the number of code review emails grows with patch complexity and review time rises exponentially, so documentation, shared ownership, CI and small changes reduce delay.
AI-written summary · about
chapters (7)
- 0:00Introduction and speaker background
- 1:31Defining development velocity
- 5:50Development pipeline and friction points
- 7:17InnerSource friction points and mitigation
- 10:50Code review and contribution acceptance
- 12:31Measuring development metrics and perceptions
- 14:42Summary and key takeaways
related talks
48mInnerSource Metrics for Changing Engineering Culture and Driving Open-Source...
17mEnhancing Developer Experience through InnerSource and Platform Engineering
23mApplying InnerSource for DATEV's Shared Frontend Library
45mAn Open Source Approach to Driving Developer Efficiency
19mWhen there is no alternative to InnerSource
16mEffective InnerSource Strategies for Resource-Constrained Teams
10mAchieving engineering velocity by optimising developer experience
19mA Frictionless Inner Source Journey
