InnerSource for Developer Experience and Competitive Advantages

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
   

   View Slide

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

   View Slide

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”
   

   View Slide

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

   View Slide

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

   View Slide

6. 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
   

   View Slide

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

   View Slide

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

   View Slide

9. 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.
   

   View Slide

10. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. 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
    

    View Slide

18. 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.
    

    View Slide

19. 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.
    

    View Slide

20. InnerSource in Action
    

    View Slide

21. 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
    

    View Slide

22. 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.
    

    View Slide

23. InnerSource Practices
    InnerSource with GitHub
    Appendix
    

    View Slide

24. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

28. 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.
    

    View Slide

29. Customer Stories
    InnerSource with GitHub
    Appendix
    

    View Slide

30. 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
    

    View Slide

31. 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
    

    View Slide

32. 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
    

    View Slide

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

    View Slide

34. 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
    

    View Slide

35. 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
    

    View Slide

36. 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
    

    View Slide

37. 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
    

    View Slide

38. 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
    

    View Slide

39. 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)
    

    View Slide

40. 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
    

    View Slide

41. 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
    

    View Slide

42. 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
    

    View Slide

43. 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.
    

    View Slide

44. Resources
    GitHub Enterprise Platform
    Appendix
    

    View Slide

45. Resources
    gh.io/innersource
    

    View Slide

46. Resources
    gh.io/innersource/blog
    

    View Slide

47. Resources
    innersourcecommons.org
    

    View Slide

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

    View Slide

49. View Slide