I’ve recently started helping Marsh McLennan
in its InnerSource
efforts to tie together the technology capabilities of Marsh, Guy Carpenter, Mercer, and Oliver Wyman.
InnerSource is the use of open source software development best practices and the establishment of an open source-like culture within organizations for the development of its non-open-source and/or proprietary software. The term was coined by Tim O'Reilly in 2000 in his column. Wikipedia
I’ll be sharing some of my learnings from the work over the coming months/years, but for now, I will introduce the concept of why a business might consider InnerSource.
When a business is small, and everyone is highly connected, we assume everyone knows everything.
But as businesses scale and people focus on their projects and specialties, new people join and leave, and knowledge and work get lost. Projects end up with silos and people that are bottlenecks in running them. We sometimes allow hacks to fix a codebase and other dubious practices sneak in as the visibility of our work is hidden, and people are under pressure to deliver.
In InnerSource (or following Open Source practices), we push the practice of creating high-quality code, detailed documentation, code reuse, collaboration, and, most importantly, a happy and healthy engineering culture.
There is a whole list of challenges that InnerSource can help businesses solve.
Here’s some taken from GitLab: