Yuki Hattori (@yuhattor) Customer Success Architect at GitHub Board Member at the InnerSource Commons Foundation Sept 10, 2023 InnerSource Co-creation of software engineers

Agenda 1. DevOps and InnerSource 2. The value of InnerSource 3. InnerSource and Developer Experience

What’s DevOps? "DevOps is about collaboration between development and operations teams" "DevOps is about dealing withIaC." "DevOps is about automation" “DevOps is Kanban for Ops…?” “DevOps is about repeating small deployments”

What’s DevOps, really? https://www.linkedin.com/posts/patrickdebois_my-current-definition-of-devops-everything-activity-6755909565658746880-odKR/

Five areas that DevOps addresses • Reduce organizational silos • Accept failure as normal • Implement gradual change • Leverage tooling and automation • Measure everything

But what you actually see all the time is ...... • Product oriented lifecycle • Cloud Architecture for the specific product / project • Organizational design closed to Dev and Ops contexts

And what you always hear is ...... Let’s reduce the organizational silos!

Now, the question is "How to break down organizational silos at the enterprise level?"

What happens: Trying to innovate in Dejima 出島 Dejima (出島) was an artificial island created exclusively to receive and host European traders in 17th-Century Edo Period Japan in accordance with the shogunate's strict foreign policies.

What happens: Dejima (出島) Dejima (出島) was an artificial island created exclusively to receive and host European traders in 17th-Century Edo Period Japan in accordance with the shogunate's strict foreign policies. You can trade here You cannot

What happens: Dejima (出島) You can do DevOps Agile / Scrum You cannot Because of infinite reasons.

What happens: Trying to innovate in Dejima 出島 You can do DevOps Agile / Scrum You cannot Because of infinite reasons. You can You cannot

The results You can You cannot We are doing DevOps Still Bad Developer Experience

DevOps is great, but to achieve enterprise-level co- creation, we need something that can be enjoyed across the enterprise

What is InnerSource? InnerSource is the application of open source principles to company-internal software development

InnerSource connects teams and code on an enterprise-wide scale DevOps DevOps DevOps Waterfall DevOps Kanban

InnerSource is the core of the modern collaboration XP Collective Ownership DevOps Reduce organizational silos Team Topologies Collaboration across teams/ departments. InnerSource Platform Engineering Don't reinvent the wheel

It’s NOT just about doing open source practices InnerSource is a journey to culturally transform towards an internal sharing economy similar to open source, while respecting corporate culture and internal organizational constraints, and breaking down organizational silos.

The InnerSource Commons Foundation InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. Founded in 2015, the InnerSource Commons is now supporting and connecting over 2500 individuals from over 750 companies, academic institutions, and government agencies.

InnerSource in Action

Share and embed sources of competitiveness The “openness” of the project extends across many teams within the organization. This allows the organization to embed differentiating trade secrets into the code without fear that they will be revealed to outsiders, while benefitting from the creativity and diverse perspectives contributed by people throughout the organization. From “Getting Started with InnerSource” by Andy Oram, an editor for O'Reilly Media

InnerSource Principles Openness - Open projects must be sufficiently documented and discoverable by placing a README.md file and a CONTRIBUTING.md file at the top of the repository. Transparency - The direction of the project/repository, unresolved feature requirements, progress on feature requirements, and decisions of the host team are made transparent. Prioritized Mentorship - With prioritized mentorship from the host team to the guest team by Trusted Committers, contributors from the guest team are leveled up to fully understand and make changes to the host team's project/repository. Voluntary Code Contribution - Participation in InnerSource from both the guest team and host team is done based on their free will.

InnerSource Practices InnerSource with GitHub Appendix

Best Practices - InnerSource Patterns Create a participatory system throughout the software lifecycle and publish design documents to facilitate early discussions. 30 Day Warranty Contracted Contributor InnerSource License Base Documentation InnerSource Portal Design Document Guiding Principles Trusted Committer Improve trust between the two teams by allowing contributors to fix bugs and suggest features with 30 days of support. Encourage contributions to InnerSource through formal contracts and agreements within the organization, rather than as volunteers. Provide a legal framework for sharing source code within an organization and offer new collaboration options. Index InnerSource project information to make it easier for contributors to discover projects of interest. Define ways to recognize ongoing contributor work. Provide standard project documentation and a self-service process for new contributors. Document and make widely available the key principles of InnerSource. Patterns Short Description

InnerSource Patterns https://patterns.innersourcecommons.org/

InnerSource Patterns https://patterns.innersourcecommons.org/

InnerSource Patterns https://patterns.innersourcecommons.org/

InnerSource Program Office - ISPO The InnerSource Program Office (ISPO) provides the means and environment to realize InnerSource within the organization. While the program office promotes development, it is not a development department or a gatekeeper. Main responsibility: • Sharing of InnerSource policies • Measuring InnerSource Metrics (eg. # of PR across teams) • Conducting mentoring/training • Developing incentive models • Ensuring appropriate tooling PR Cross Team PR % Q1 FY19 852k 37k 5.6% Q2 FY19 810k 35k 4.2% Q3 FY19 912K 39k 4.8% Q4 FY19 1.0M 46k 4.1% Q1 FY20 1.2M 43k 3.6% * The above is an example from Microsoft.

Customer Stories InnerSource with GitHub Appendix

The InnerSource initiative thus became the key point. We made efforts to change the way of thinking and ideas by code sharing using GitHub Appendix / Customer Stories Tomohisa Handa / Manager, Agile Development

They can make suggestions and adopt a style of working that’s more open and fits their needs Appendix / Customer Stories Tom Erickson / Supervisor of Global Software Tools and Processes

3M uses GitHub to drive innersource initiatives, eliminate duplicative efforts, tap the organization’s collective knowledge, and collaborate across teams to improve software. Appendix / Customer Stories Paul Pottorff / Cloud and Security Architect

Having everyone together on the GitHub platform is a great advantage for InnerSource. Wolfgang Gehring / FOSS Ambassador Appendix / Customer Stories

What do companies want? Talent attraction and retention Companies now need to place more emphasis on the Developer Experience. Productivity and cost savings Consistency and quality Security and compliance. Speed. * “Why your IT organization should prioritize developer experience” by McKinsey https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/why-your-it-organization-should-prioritize-developer-experience

Sometimes, only the collaboration model aspect is extracted https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/why- your-it-organization-should-prioritize-developer-experience

Share and embed sources of competitiveness The “openness” of the project extends across many teams within the organization. This allows the organization to embed differentiating trade secrets into the code without fear that they will be revealed to outsiders, while benefitting from the creativity and diverse perspectives contributed by people throughout the organization. From “Getting Started with InnerSource” by Andy Oram, an editor for O'Reilly Media

People-oriented vs. Product-oriented Mixing two different purposes “InnerSource” in context leads to misunderstandings and creates friction. Basically, both can be achieved, but know that there are different balances for different purposes. InnerSource for Developer Experience to maximize the value of the people & teams InnerSource as a Competitive Strategy to maximize the value of the product and IP vs

Which is your priority? InnerSource for DevEx: • Transparent and collaborative culture • Improve skill levels through sharing • Employee satisfaction • Production Cost Reduction by preventing reinvention of the wheel InnerSource as a Competitive Strategy: • New value or innovation through co-creation • Quality improvement through sharing • Synergy between products through team collaboration • Production cost reduction by preventing reinvention of the wheel

Potential blockers InnerSource for DevEx: Measurements: Developer Efficiency and Happiness • Fewer legal, tax, and accounting issues • The product itself is not considered of much value • Hard to measure the impact Project examples: Documentation, Templates, Shared libraries, Internal tools, SDK, API, Hackathon projects InnerSource as a Competitive Strategy: Measurements: Value Added • Legal, tax, and accounting issues are very complex • Clearly trying to share "product and technology value,” which of course brings its own set of problems • Middle management unwilling to allow employees to contribute (=provide the value) beyond the team Project examples: Patented Technology, Technologies related to Intellectual Property, Competitive advantage product itself)

R&D Entries One-way sharing The team simply shares the completed components. Collaboration between specific teams The team receives contributions Autonomous collaboration with various teams The team receives contributions widely within the organization Considerations for Each Type and the Respective Evolutionary Paths Apply IT Asset Management best practices to share "software" items in the accounting entries. Establish labor management and sharing rules for each team for Components of the R&D phase (that are not "software" in the accounting entries) Software Entries Established sharing rules for consolidated accounting Establishes rules for transfer pricing taxation Coordinate by discussing in advance how the cost center will be managed Create a template as an InnerSource License so that collaboration can easily occur Organize the organizational view of the InnerSource rules on transfer pricing taxation Since the scope of sharing in a particular project is limited, it may be sufficient to work with the accounting department. Innersource Program Offifce will assist in turning examples into an innersource license and develop an official corporate license Model collaboration as an InnerSource License, so that cost centers and shared rules do not have to be conversed with each team every time. Take into account IP usage rules and usage restrictions, as well as black- boxing of reusable portions. Set rules for IP sharing Develop rules and best practices for sharing limited portions of IP (that hide valuable and patent-related portions of IP, such as sharing only interfaces such as usage SDKs and libraries) Organize the company's view of the InnerSource rules on transfer pricing taxation and prepare internal documents. At this time, there is a possibility that the software could be shippable as a category of software or could be considered as "just labor being provided" to the core hosting company [WIP] More sorting out is needed here Further steps of collaboration are necessary when seeking autonomous and flexible sharing of items beyond internal black boxing, such as sharing only the SDK, or redefining the scope of shared items by splitting the architecture. For example, it is necessary to define a mechanism for selling the developed items to the company or other companies, such as a joint venture. Note: This documentation does not represent a formal GitHub / InnerSource Commons Foundation position based on accounting, tax, or legal considerations. It is a list of items for each of the considerations as a starting point for discussion of the technical InnerSource adoption in the company. 42 Single Legal Entity Collaboration Within the Group International collaboration Collaboration With External Companies

R&D Entries One-way sharing The team simply shares the completed components. Collaboration between specific teams The team receives contributions Autonomous collaboration with various teams The team receives contributions widely within the organization Considerations for Each Type and the Respective Evolutionary Paths Apply IT Asset Management best practices to share "software" items in the accounting entries. Establish labor management and sharing rules for each team for Components of the R&D phase (that are not "software" in the accounting entries) Software Entries Established sharing rules for consolidated accounting Establishes rules for transfer pricing taxation Coordinate by discussing in advance how the cost center will be managed Create a template as an InnerSource License so that collaboration can easily occur Organize the organizational view of the InnerSource rules on transfer pricing taxation Since the scope of sharing in a particular project is limited, it may be sufficient to work with the accounting department. Innersource Program Offifce will assist in turning examples into an innersource license and develop an official corporate license Model collaboration as an InnerSource License, so that cost centers and shared rules do not have to be conversed with each team every time. Take into account IP usage rules and usage restrictions, as well as black- boxing of reusable portions. Set rules for IP sharing Develop rules and best practices for sharing limited portions of IP (that hide valuable and patent-related portions of IP, such as sharing only interfaces such as usage SDKs and libraries) Organize the company's view of the InnerSource rules on transfer pricing taxation and prepare internal documents. At this time, there is a possibility that the software could be shippable as a category of software or could be considered as "just labor being provided" to the core hosting company [WIP] More sorting out is needed here Further steps of collaboration are necessary when seeking autonomous and flexible sharing of items beyond internal black boxing, such as sharing only the SDK, or redefining the scope of shared items by splitting the architecture. For example, it is necessary to define a mechanism for selling the developed items to the company or other companies, such as a joint venture. 43 Single Legal Entity Collaboration Within the Group International collaboration Collaboration With External Companies

Don't be fundamentalist: Which is InnerSource and which is not? Premise: Basically, you are allowed to collaborate if you wantso • In a 100-person company, everyone is collaborating at the Enterprise level in an internal-type repository at GitHub. • In a 2000-person company, 300 people are collaborating within the one single GitHub organization. But not all users of GitHub Enterprise have access to the codebase. • In a 5000-person company, 5 units, 1400 people are collaborating in a single closed repository in InnerSource way

Key Takeaways • The InnerSource can be perceived in many different ways by different people • Don’t only be a Product-oriented or People-oriented thinker, Draw the holistic roadmap and prioritize what you want as an organization • Don't be a fundamentalist, be Flexible and get start with Innersource These will reduce friction, and achieve competitive advantage and the great Developer Experience at the same time.

Resources GitHub Enterprise Platform Appendix

Resources gh.io/innersource

Resources gh.io/innersource/blog

Resources innersourcecommons.org

Resources Recommended free book. innersourcecommons.org/learn/books/

No content