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.
3. a network of organizations
TECHNOLOGY
CREDIT
PLATFORM
REAL ESTATE
PLATFORM
INSURANCE
PLATFORM
Digitalisation of the
credit, real estate
and insurance
industries
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
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
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
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
33.
34. Management of many
repositories is still
cumbersome
Rules of play for GitHub
organization reduce
team autonomy
#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
38.
39. Less transparency due
to limited access (only
team)
Extra costs for every
organization
#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
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
48.
49. Who should be
contacted for
contributions or other
questions regarding one
project?
#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
53.
54. How to agree on
standard technologies
between autonomous
teams?
#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