Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Europace's journey to InnerSource

140 views

Published on

Europace is a network-centric organization within a network of organizations (Hypoport). It uses the self-organization framework Holacracy as its operating system---loosely coupled, autonomous teams are working together for a common purpose. But with autonomy also comes a trend towards self-sufficiency. In the years after starting with self-organization we experienced a lot of “reinventing the wheel” instead of company-wide collaboration. In order to find a way out of this dilemma we looked at the open source world, especially on how collaboration works in such a distributed world. What we found was The Apache Way.

Next, a group of people interested and experienced in Open Source founded a community of practise at Europace. Together, we run experiments for applying the patterns of The Apache Way at our teams. As a result of those experiments these patterns can nowadays be found everywhere at Europace, especially when it comes to collaboration between teams. But we did not stop there, we kept on running experiments in order to improve the InnerSource experience at Europace. In this talk you will learn which experiments we run, how we did it and what we discovered on our journey so far.

Published in: Technology
  • Be the first to comment

Europace's journey to InnerSource

  1. 1. GitHub Enterprise Roadshow, Munich 2020-01-29
  2. 2. Engineering Lead </>
  3. 3. a network of organizations TECHNOLOGY CREDIT PLATFORM REAL ESTATE PLATFORM INSURANCE PLATFORM Digitalisation of the credit, real estate and insurance industries
  4. 4. a network-centric organization Connecting wishes with banks
  5. 5. in numbers >200 employees 662 partners on the platform 53.5 bill euro real estate financing transaction volume in 2019 3.5 bill euro credit transaction volume in 2019 housing-saving transaction volume in 2019 11.0 bill euro
  6. 6. Photo by Khachik Simonian on Unsplash
  7. 7. Photo by Dominika Roseclay from Pexels
  8. 8. Photo by mentatdgt from Pexels
  9. 9. Photo by Ian Kim on Unsplash
  10. 10. Photo by fauxels from Pexels
  11. 11. Photo by anna-m. w. from Pexels
  12. 12. Open Source & InnerSource A community of practice for applying The Apache Way in Europace
  13. 13. challenge or opportunity idea solution in one team feedback share with community of practice adoption by other teams recommendation in documentation or principle upstream sharing (public) improvement of solution
  14. 14. Photo by Chokniti Khongchum from Pexels
  15. 15. Collaboration between multiple teams on a shared project #1 Private repository on GitHub
  16. 16. Private repository on GitHub org with pull-requests #1 Private repository on GitHub
  17. 17. ● Use “WIP” labels or draft-pull requests ● Author of pull-request should merge ● Expectation management for reviews ● Pull-request templates are often ignored ● Source code in the cloud has no legal constraints unless it contains user data ● Continuous integration before merge #1 Private repository on GitHub
  18. 18. ● High entry barrier for other teams ● Does not scale well: How to organize repositories ● Unknown GitHub accounts as members ● How to collaborate between teams ● Integration with existing development infrastructure #1 Private repository on GitHub
  19. 19. Scalability: How to organize repositories Unknown GitHub accounts as members #2 Teams in GitHub
  20. 20. Replicate team structure with “teams” feature on GitHub #2 Teams in GitHub
  21. 21. ● Prefixes in repository names are more helpful ● READMEs for better findability ● Teams can manage their members #2 Teams in GitHub
  22. 22. ● Management of many repositories is still cumbersome ● Rules of play for GitHub organization reduce team autonomy #2 Teams in GitHub
  23. 23. High entry barrier for other teams #3 Support channel in Slack
  24. 24. GitHub as a product #3 Support channel in Slack
  25. 25. ● Support is good, documentation is better ● Documentation is good, trainings are better ● It’s good to have a FAQ for repeating issues ● Internal tools are also products #3 Support channel in Slack
  26. 26. ● Documentation for GitHub@Europace ● Git-/GitHub-Trainings ● FAQ on GitHub@Europace #3 Support channel in Slack
  27. 27. Management of many repositories is still cumbersome Rules of play for GitHub organization reduce team autonomy #4 GitHub org for one product
  28. 28. Divide and conquer: GitHub orgs for managing repositories and teams #4 GitHub org for one product
  29. 29. ● Easier separation of repositories ● More autonomy for team around product #4 GitHub org for one product
  30. 30. ● Less transparency due to limited access (only team) ● Extra costs for every organization and additional seats for people of other teams #4 GitHub org for one product
  31. 31. Less transparency due to limited access (only team) Extra costs for every organization #5 GitHub org per subsidiary or product
  32. 32. GitHub Enterprise Cloud #5 GitHub org per subsidiary or product
  33. 33. ● Enforce SSO and 2FA from beginning ● Use units which last longer, i.e. subsidiaries or products #5 GitHub org per subsidiary or product
  34. 34. ● No enterprise search, search does not find internal repositories if not member ● CI/CD integration ● GitHub Registry and Actions ● No migration path to Enterprise SSO ● Azure AD supports only max. number of orgs per SAML connector #5 GitHub org per subsidiary or product
  35. 35. CI/CD with multiple organizations Management of technical users #6 CI/CD with technical user per purpose
  36. 36. Integrate security team into the process of creating technical users #6 CI/CD with technical user per purpose
  37. 37. ● Integrating cloud and on-premise infrastructure is not easy ● Personal access tokens have a too broad scope to be used for CI/CD ● Integrate security team early ● If you only need an RSA key and an access token, don’t ask for whole ActiveDirectory account #6 CI/CD with technical user per purpose
  38. 38. ● Use similar process for integrating other cloud services with on-premise infrastructure #6 CI/CD with technical user per purpose
  39. 39. Who should be contacted for contributions or other questions regarding one project? #7 Trusted committer for InnerSource documentation
  40. 40. Trusted committer or code owner #7 Trusted committer for InnerSource documentation
  41. 41. ● Every project needs at least 2 or 3 active code owners in order to ensure proper maintenance of the code ● CODEOWNERS file in GitHub repositories ● Accountabilities of a trusted committer or code owner should be identical for all teams #7 Trusted committer for InnerSource documentation
  42. 42. ● Questions on non-technical topics need to be answered outside of issues and pull-requests, because many non-developers don’t use GitHub #7 Trusted committer for InnerSource documentation
  43. 43. How to agree on standard technologies between autonomous teams? #8 Open decision process for standards
  44. 44. Use Open Decision Framework from RedHat #8 Open decision process for standards
  45. 45. ● Use IETF RFC 2119 (MUST, SHOULD, MAY etc.) for defining compliance level of technology standards ● GitHub flow for reviewing and applying standards ● Standard committee defined in CODEOWNERS file #8 Open decision process for standards
  46. 46. ● Communication of standards #8 Open decision process for standards
  47. 47. for finding the right direction for guidance on the journey for reducing uncertainty and moving forward

×