Caring about sharing within commerical enterprises using GitHub
Overview
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
References:
- GitHub wrote a PDF at resources.github.com/downloads/InnerSource.pdf
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
- https://github.com/paypal/InnerSourcePatterns
That now is redirected to:
https://github.com/InnerSourceCommons/InnerSourcePatterns
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.
- Ford
- Continental (Tires)
- Dow Jones
- Spotify
- Twilio
-
Stripe “InnerSource removes friction”
- Lloyds Bank Group
- American Airlines
- Microsoft
- VIDEO: Comcast
Roles
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.
-
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
innersource-completed-pluralsight
- 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:
- Create
- Store
- Use
- Share
- Archive
- 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
Culture
Steps to break down silos:
- Work towards a common goal
- Motivate and incentivize
- Collaborate and create (Transparency improves collaboration)
- Execute and measure
-
Transparency - discoverable repositories
-
Engagement - useful templates
workflows
-
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:
- Define program goals, timeline, and Exec sponsor team
- Identify pilot group(s) to validate and drive internal success
- Create internal portal for InnerSource
- Establish the Trusted Committer (TC) role
- Establish Search/Tagging conventions
- Establish template documentation and repository set up guidelines
- Contributing guidelines
- Provide example workflows
- Provide a temporary repository
- Create an InnerSource team within the GitHub organization to provide guidance
- Establish and schedule initial workshops
Resources
https://www.wikiwand.com/en/Inner_source
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:
- CODEOWNERS
- CONTRIBUTING.md
- ISSUE_TEMPLATE.md
- PULL_REQUEST_TEMPLATE.md
https://www.youtube.com/watch?v=D3C12ojRcp0