Wilson Mar bio photo

Wilson Mar


Email me Calendar Skype call

LinkedIn Twitter Gitter Instagram Youtube

Github Stackoverflow Pinterest

Caring about sharing within commerical enterprises using GitHub

US (English)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Estonian   اَلْعَرَبِيَّةُ (Egypt Arabic)   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean


The term “InnerSource” was coined by Tim O’Reilly in 2000.

NOTE: Content here are my personal opinions, and not intended to represent any employer (past or present). “PROTIP:” here highlight information I haven’t seen elsewhere on the internet because it is hard-won, little-know but significant facts based on my personal research and experience.

Innersource is the approach of using open source practices within proprietary organisations which desire to take advantage of the open collaborative way of building software.

InnerSource is the practice of adopting open source patterns internally within an organization – an organization that practices InnerSource may or may not also maintain open source software. “The Apache Way”.

By applying the principles of open source within an organisation, InnerSource helps teams work better together, reduce bottlenecks, and build a much more collaborative, effective and efficient delivery model.

InnerSource has been gaining momentum in the last number of years thanks to the wide range of reported benefits:

  • Increased developer collaboration across silos
  • Better code quality
  • More code re-use
  • Enhanced documentation
  • Higher developer satisfaction
  • Improved talent acquisition and retention


Who are using InnerSource?

Paypal is a big supporter of InnerSource. Since 2016 it sponsored Isobel Drost-Fromm (@divadanese, now a consultant at Nearform) to found innersourcecommons.org (ISC), #InnerSourceCommons), a volunteer organization that holds two summits a year and publishes a repository of “patterns” at

VIDEO: As of 2020, there are over 100 corporate members of ISC.

Public presentations have been made by people from these organizations:

  • Bloomberg
  • Walmart

Many GitHub users highlighted in github.com/customer-stories make use of InnerSource.


April 2020 “Learning Path” script and (with Keith Rudlidge of Nike) on YouTube video, and O’Reilly.com with Johannes Tiigges and (InnerSourceCommons founder) Isobel Drost-Fromm (@divadanese), clarifies key roles in InnerSource:

  • VIDEO Contributors “are also called guests” who contribute code, bug reports, docs. PROTIP: cut dependencies.

  • Trusted Committers (TCs) “are also called hosts”. They review outside contributions, provides mentorship and code reviews to contributors, writes documentation, resources, assets. All to ensure quality. GitHub’s “Maintainer” role and Apache’s “Committer” are more tech oriented with less social responsibilities. Only Trusted Committers merge code.

PROTIP: Have a file in your repo based on this TRUSTED-COMMITTERS.md

PROTIP: Scheduled rotation between coding and TC role.

  • Community members use the project (software).

  • VIDEO: Product Owners are responsible for “defining and prioritizing stories”, driving the vision and managing the organizational aspects of the project.

  • Review Committee

  • InnerSourceCommons mentions a “Dedicated Community Leaders” – people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.

Aaron Stewart, a Program Architect at GitHub, created a video series on Pluralsight has a “Collaborative Coding with GitHub” series that includes “Adopting an InnerSource Culture with GitHub” [1h 42m] released 30 Mar 2020

The course references GitHub’s 32 m “InnerSource Fundamentals” class which creates the “InnerSource Toolkit” website providing a resource others can use to introduce InnerSource.

After going through the course, the repo would look like

  • https://lab.github.com/githubtraining/innersource-fundamentals begins with https://github.com/githubtraining/training-manual

In the course, Aaron also provides a Checklist for Measuring Success

Sharing in Lifecycle

Sharing is a mindset. Toward that end, “Security Guidance for Critical Areas of Focus in Cloud Computing v4.0” has Sharing in its definition of Data Security Lifecycle:

  1. Create
  2. Store
  3. Use
  4. Share
  5. Archive
  6. Destroy

Success Metrics

QUESTION: Under the “Insights” tab for each project???

Along the lifecycle:

A) % of issues created from external contributors

B) % of PRs that come from external contributors

C) % of PRs from external teams that are merged

D) % of reviews that come from external contributors

E) % of code reuse across projects

F) % of repositories using InnerSource components (managed contributing guidelines, assigned TCs)

G) (Days) Responsiveness (how quickly does someone respond to an issue opened by an external contributor)

QUESTION: What are the mechanisms to calculate the above metrics?


Maturity Model

The Apache Project Maturity Model provides a suggested framework for evaluating the overall maturity of an Apache project community, a part of the “Apache Way”. Items include:

  • Code
  • Licenses and Copyright
  • Releases
  • Community
  • Consensus Building
  • Independence (Chatham House Rule)

The above address the mechanics of InnerSource activities.

However, there are also much more powerful forces contributing to the success of InnerSource.

“InnerSource is as much cultural transformation than a technical one.”

Struggle for dominance

In “traditional” work cultures, the “top dog” enjoys more independence. To become a “star performer”, either officially designated or not, is typically achieved through bluster: by openly insulting less brazen colleagues and limiting sharing of knowledge only to show superiority rather than to mentor others.

Some managers may prefer this situation because it “gets the work done”, even if it’s just on the short term.

However, the capacity and growth potential in “hero cultures” are below what can be achieved in more inclusive cultures where open sharing elevate all members.

While heros may be able to deliver on the short term, when considering long term consequences, when the hero inevitably leaves, the organization can become crippled.

Hero cultures are also correlated with a “Not Invented Here” (NIH) mentality that limits adoption of innovation.

Thus, so-called heros are not really “leaders”, but dominators intent on sacrificing others to better oneself.

It’s very difficult to build InnerSource among selfish people.

NIH is one of the patterns that InnerSource practitioners described in InnerSourceCommons.

Vocabulary on patterns

InnerSource practitioners created a vocabulary for describing challenges and proven ways to address them.


The above diagram is explained in this video “InnerSource Patterns - How They Work”.

Problems (challenges) exist within a context. Forces perpetuate the problems. The Resulting context are the conditions we wish to achieve. If we don’t have a known Resolution which affects the forces. If a Resolution is not proven with Known Instances, the pattern is called a donut (with context around a missing Resolution).

A sample pattern is “Management Review”:


“Patlet” is the heading for a summary statement about a pattern.

The “Review Committee” pattern is at https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/review-committee.md


Steps to break down silos:

  1. Work towards a common goal
  2. Motivate and incentivize
  3. Collaborate and create (Transparency improves collaboration)
  4. Execute and measure
  • Transparency - discoverable repositories

  • Engagement - useful templates


  • Communication - repository ownership

See “Gaining by Sharing” by Niel Basjes

Contributing Guidelines

Code conventions

Testing conventions

Branching conventions

Commit message conventions

Steps for creating a good pull request

How to submit feature requests

How to submit bug reports

How to submit issues

Help wanted section - tag Issues

Rollout Checklist of Actions

VIDEO: Silona Bonewald, Director of InnerSource at PayPal, wrote in 2017 a 23-page pdf download “Understanding the InnerSource Checklist: How to Launch Collaboration Within Your Enterprise” downloaded from https://innersourcecommons.org/checklist.

Below is my adaptation of how to create a culture where InnerSource can thrive:

  1. Define program goals, timeline, and Exec sponsor team
  2. Identify pilot group(s) to validate and drive internal success
  3. Create internal portal for InnerSource
  4. Establish the Trusted Committer (TC) role
  5. Establish Search/Tagging conventions
  6. Establish template documentation and repository set up guidelines
  7. Contributing guidelines
  8. Provide example workflows
  9. Provide a temporary repository
  10. Create an InnerSource team within the GitHub organization to provide guidance
  11. Establish and schedule initial workshops



Cultural Inventory questionnaire, interviews, workshops.

Project Guidance training, establishing procedures, mentoring.

Project Assessment evaluation, team structures, documentation.

Implementation awareness, discovery, pilot, repeat.

https://www.nearform.com/blog/journey-to-innersource-danese-cooper-james-mcleod/ Podcasts

https://resources.github.com/whitepapers/introduction-to-innersource/ January 22, 2018

VIDEO: OpenDev 10.2017 | Getting started with InnerSource—open source workflows in the enterprise Ryan Parks shows use of a template repo (java-calculator) containing a .github folder containing: