Our journey to a streamlined open source GitHub organization. The beginning.

Our journey to a streamlined open source GitHub setup. The beginning.

Restoring glory to our Dynatrace open source organization on GitHub.

Open Source may sound simple for a developer:

• Step 1: Open a GitHub Account
• Step 2: Create a repository
• Step 3: Start hacking

Yes, from an individual perspective, this may apply; but from a company perspective, things are way more complicated. And that’s just the beginning of what we’ve learned in our GitHub adventure at Dynatrace.

With this blog post series, I want to share how we transformed our unorchestrated GitHub organizations into a more structured and managed approach with a streamlined process that allows us to handle users, repositories, and organizations in a more accessible way.

As you might expect from the title, this is just the beginning of a series. In this first blog post, I’ll give you an overview of our problems as an open source GitHub organization. In future posts, I’ll detail each problem and how we attempted to resolve it.

Looking into our open source operations, we noticed that many topics were left to develop by themselves and fester, mainly because no official entity or team was taking care of them. Thankfully, the OSPO team was created to restore glory to the Dynatrace open source GitHub organizations.

Some of the problems we identified were:

1. Community standards
2. User management
3. GitHub and accessibility
4. Other code hosters

In the next few sections, I'll go into more detail about each issue. But first, I’d like to answer the question that’s probably already on your mind: why don’t you just use GitHub Enterprise?

Why we don’t use GitHub Enterprise and other prerequisites

Some of the obstacles we’re tackling could be handled more easily using GitHub Enterprise. I.e., SAML for user management, finding dormant users, etc.

However, we have a few good reasons for not using GitHub Enterprise for open source.

1. First, we have our in-house code hosting, but acquiring additional GitHub Enterprise licenses for all developers is a substantial financial effort. We still use GitHub teams where we need more minutes for GitHub Actions or other features, but we try to stick to the free tier.
2. Second, our philosophy is that, in a perfect world, each of our open source projects should mature into a community. It is hard to do so if your integrations and setup rely on a paid plan, and suddenly you can’t rely on the company funds in the same manner as before.
3. Third, we want to make our employees’ lives easier. Therefore, everyone is allowed to use their private GitHub account — no more switching accounts, etc. This can be especially painful/annoying if somebody contributes in their free time to a project which does not fit our company requirements and you accidentally use your work account.

Community standards

Some developers still see open source and GitHub as code dumpsters: Let’s put the code there, and the community will take care of it.

Open source is not just about sharing code; it is about maintaining a community and a suitable environment for collaboration. If we don’t manage to provide this, we should keep things closed.

Luckily this is quite easily covered with new projects. However, we’re facing some community-related issues with legacy projects, like missing license information, code of conduct, security information, and contribution guidelines. This is a big problem, especially for the license information, as other users or companies could use our open source code in their projects.

User management

As we already clarified, all our employees can use their private GitHub accounts to contribute to open source. GitHub for enterprises offers auto-provisioning, and we don’t have this option because we're using the free version of GitHub.

Without SAML, user management becomes a bit more complicated. Now it takes mostly a manual effort to:

• Properly onboard new users
• Correctly deprovision/offboard/remove them
• Ensure proper organization assignment
• Create a reproducible history (i.e., knowing why a user was added and by whom)
• Allow self-management

Overall, there are many things to consider and take care of. And many of these tasks were done manually, especially organization assignments and repository permissions.

Dynatrace-external contributors and service users are the cherries on top that add more depth and complexity to this topic.

Simplicity of GitHub

GitHub lets you create a repository and organizations easily. It is fantastic, but also one of the culprits causing many of our problems. Dynatrace doesn’t just have one GitHub organization; we have multiple ones because it was so easy to create them.

We (the Open Source Program Office) currently ‘own’ about 10 GitHub organizations with Dynatrace in their name, which is already a lot — but there are around 130 organizations with Dynatrace in their name on GitHub. Not all, but certainly a good amount of them was created for our company Dynatrace and to host intellectual property of Dynatrace. Therefore, it is even more important to closely inspect them, integrate them with our user management, and ‘enforce’ our community standards.

Summary

Overall, you see that there was and still is much to do. Most likely, it will never end.

We learned a lot during our adventures to form our open source future, and it was not always easy, but we want to share our approaches, findings, and solutions (as far as possible) with the OSS World. Maybe it helps somebody else; perhaps somebody has a better system; maybe somebody learned from our mistakes and misconceptions. We’d love to know your thoughts, and stay tuned for upcoming blog posts in this series.

Our journey to a streamlined open source GitHub organization. The beginning. was originally published in Dynatrace Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.