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.

1. GitHub Enterprise Roadshow, Munich
2020-01-29

2. Engineering Lead
</>

3. a network of organizations
TECHNOLOGY
CREDIT
PLATFORM
REAL ESTATE
PLATFORM
INSURANCE
PLATFORM
Digitalisation of the
credit, real estate
and insurance
industries

4. a network-centric
organization
Connecting wishes
with banks

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

9. Photo by Khachik Simonian on Unsplash

10. Photo by Dominika Roseclay from Pexels

11. Photo by mentatdgt from Pexels

12. Photo by Ian Kim on Unsplash

13. Photo by fauxels from Pexels

14. Photo by anna-m. w. from Pexels

15. Open Source
&
InnerSource
A community of
practice for applying
The Apache Way in
Europace

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

17. Photo by Chokniti Khongchum from Pexels

19. Collaboration between
multiple teams on a
shared project
#1 Private repository on GitHub

20. Private repository on
GitHub org with
pull-requests
#1 Private repository on GitHub

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

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

24. Scalability: How to
organize repositories
Unknown GitHub
accounts as members
#2 Teams in GitHub

25. Replicate team
structure with “teams”
feature on GitHub
#2 Teams in GitHub

26. ● Prefixes in repository names are more
helpful
● READMEs for better findability
● Teams can manage their members
#2 Teams in GitHub

27. ● Management of many repositories is still
cumbersome
● Rules of play for GitHub organization
reduce team autonomy
#2 Teams in GitHub

29. High entry barrier for
other teams
#3 Support channel in Slack

30. GitHub as a product
#3 Support channel in Slack

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

32. ● Documentation for GitHub@Europace
● Git-/GitHub-Trainings
● FAQ on GitHub@Europace
#3 Support channel in Slack

34. Management of many
repositories is still
cumbersome
Rules of play for GitHub
organization reduce
team autonomy
#4 GitHub org for one product

35. Divide and conquer:
GitHub orgs for
managing repositories
and teams
#4 GitHub org for one product

36. ● Easier separation of repositories
● More autonomy for team around product
#4 GitHub org for one product

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

39. Less transparency due
to limited access (only
team)
Extra costs for every
organization
#5 GitHub org per subsidiary or product

40. GitHub Enterprise Cloud
#5 GitHub org per subsidiary or product

41. ● Enforce SSO and 2FA from beginning
● Use units which last longer, i.e. subsidiaries
or products
#5 GitHub org per subsidiary or product

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

44. CI/CD with multiple
organizations
Management of
technical users
#6 CI/CD with technical user per purpose

45. Integrate security team
into the process of
creating technical users
#6 CI/CD with technical user per purpose

46. ● 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

47. ● Use similar process for integrating other
cloud services with on-premise
infrastructure
#6 CI/CD with technical user per purpose

49. Who should be
contacted for
contributions or other
questions regarding one
project?
#7 Trusted committer for InnerSource documentation

50. Trusted committer or
code owner
#7 Trusted committer for InnerSource documentation

51. ● 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

52. ● 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

54. How to agree on
standard technologies
between autonomous
teams?
#8 Open decision process for standards

55. Use Open Decision
Framework from RedHat
#8 Open decision process for standards

56. ● 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

57. ● Communication of standards
#8 Open decision process for standards

58. for finding the
right direction
for guidance on
the journey
for reducing
uncertainty and
moving forward