Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

InnerSource for Developer Experience and Compet...

Yuki Hattori
November 08, 2023

InnerSource for Developer Experience and Competitive Advantages

Yuki Hattori

November 08, 2023
Tweet

More Decks by Yuki Hattori

Other Decks in Technology

Transcript

  1. Yuki Hattori (@yuhattor) Customer Success Architect at GitHub Board Member

    at the InnerSource Commons Foundation Sept 10, 2023 InnerSource Co-creation of software engineers
  2. Agenda 1. DevOps and InnerSource 2. The value of InnerSource

    3. InnerSource and Developer Experience
  3. 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”
  4. Five areas that DevOps addresses • Reduce organizational silos •

    Accept failure as normal • Implement gradual change • Leverage tooling and automation • Measure everything
  5. 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
  6. 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.
  7. 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
  8. What happens: Dejima (出島) You can do DevOps Agile /

    Scrum You cannot Because of infinite reasons.
  9. What happens: Trying to innovate in Dejima 出島 You can

    do DevOps Agile / Scrum You cannot Because of infinite reasons. You can You cannot
  10. DevOps is great, but to achieve enterprise-level co- creation, we

    need something that can be enjoyed across the enterprise
  11. What is InnerSource? InnerSource is the application of open source

    principles to company-internal software development
  12. 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
  13. 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.
  14. 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.
  15. 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
  16. 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.
  17. 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
  18. 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.
  19. 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
  20. 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
  21. 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
  22. Having everyone together on the GitHub platform is a great

    advantage for InnerSource. Wolfgang Gehring / FOSS Ambassador Appendix / Customer Stories
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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)
  28. 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
  29. 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
  30. 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
  31. 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.