Open Source Contributions and You — The Platforms Engineer Perspective

As a Platform Engineer, your work is quite varied. The constant struggle between production health, configurations, benchmarks, and monitoring keeps you constantly busy. On top of that, you are most likely the domain expert for single or several systems, making you the go-to person for everything related. That means you’ve created integrations, CI/CD pipelines, written documentation, and held training sessions at some point.

During this time, you read most of the available documentation and online materials on these systems, but let me guess — you keep maintaining your in-house solutions rather than contribute back, am I right?

Over the past years, I’ve been working with Apache Airflow almost daily and did all the work around Airflow as a domain expert for the organizations I work for — I wrote DAGs, operators, plugins, CI/CD pipelines, internal tools, monitoring, wrote education materials, etc.

Recently I started contributing back to Airflow, and I want to share my thoughts on what it gave me, why you should conquer your fear of contributing to open-source projects too, and what benefits that hold for you!

Remember — Contributions are not only code

By being the master of your domain and incorporating open-source tools into your organizations, you went through a lot. You also probably developed some in-house flows and tools and did a lot of tailoring for everything to work smoothly. All of this gained you knowledge that perhaps no one else has, and your experience and expertise go far and matter.

Contributing is more than just creating features and running code. You can also contribute by spreading your knowledge via tweaking the product’s documentation pages, answering questions on Stack Overflow (although it’s less rewarding sometimes), being a member of Slack channels for a project or related communities, doing code reviews to open PRs, get involved in discussions and of course attend meet-ups, conferences, and roundtable discussions with other companies (if you live next to a tech hub).

All of this plays a role in advocating for the project and helping to spread the word about your skills.

Think you develop good CI/CD and local development flow? Check out the work in the open-source

When working with several companies, I often had to develop and maintain a CI/CD flow for Apache Airflow changes, create a local development environment and tools to be used by the engineers of a given company.

But when you develop for other engineers in the same company, you create tools for ~50 or ~100 people. Those people might not change that often (if you’re lucky), so you can cover A LOT by writing in-house documentation to close knowledge gaps.

With open source projects you don’t have this privilege — you work with thousands of people, and their skills are varied. You need to develop a fantastic test suite to avoid breaking a product that potentially thousands of people use daily. You can take a lot of examples and ideas on how developers who contribute to the open source develop their features, the tools they choose to use, and even how they write their tests. They probably already had covered a lot of things and worked it out on a vast scale.

It helps you become a better engineer

When developing features for our flow we often take things for granted, like our users are somewhat aware of the system, we usually have internal documentation (although it’s far from perfect), and we already have some pre-defined defaults and packages to ease our work.

When you work on open-source projects, you have to think broader. Your feature can potentially be used by thousands of people, directly impacting all its users and companies. You have to think about the generic and abstract cases and how users can abuse your feature, which makes you grow as a professional.

Your code is getting reviewed by many people, which makes your code better written, more readable, and overall more production-grade than what you could write by yourself or as part of a small team.

The potential exposure forces you to do more thorough work. As a platform engineer, you often need to deliver fast, so it’s OK to provide some patches or code that will be improved later but most likely never will.

When working on open-source, your code will be instantly (or almost instantly) available for thousands of users, this makes you think before submitting the PR on the implementation and the code quality. Writing a full test suite (whereas on your local env you sometimes might skip a few scenarios) is now a must. And you need to write proper documentation, make it usable and think about various cases.

Open source forces you to learn a lot more about the product you’re working on. Even small features often make you drill down deeper into the product, write better code and use the proper classes.

It helps you to understand much more of the product than you are used to, and over time you will genuinely understand every bit and byte of the product you’re working on.

As platform engineers, you might not spend as much time on actual coding as you want since support, documentation, altering configurations, and playing with existing systems are time-consuming. Contributing to open source helps you code more and keep your skills sharp.

You can impact the future of the product

As previously mentioned, in my case, I’m contributing to a project that is part of my day-to-day work and mission-critical for the organization I work for.

Working on open-source features and getting involved in discussions opens you to information about the product’s roadmap and lets you influence its growth. You can solve something on the product layer, which is the proper way instead of just patching it internally.

It’s human nature to help someone you are familiar with; if you contribute to an open-source project, other maintainers will learn to know your name. If you submit an issue or a new feature proposal, it will act as a force multiplier, and you could leverage the network of people you built to achieve your goals. Just imagine reporting a production issue and seeing someone from a pool of 1000 maintainers implement it for you! This sounds like a dream, and it’s only because your name will be out there since you have built a community around yourself.

It helps you personally

When you submit a PR to an open-source project, anyone can review it. You need to describe your intentions and write proper feature documentation thoroughly. The reviewers need to be aware of all the context involved in the development process and all the tradeoffs and assumptions you made.

I must say that communicating correctly is a complex skill to master (especially if you’re not a native English speaker or work remotely). Still, once you train this muscle, it also helps you in your everyday work. Communication is hard, so contributing to open source projects can be your training ground on this matter.

When your PR, suggestion, or anything else gets merged, no matter how big or small, it boosts your self-esteem. Having someone unfamiliar with you and your skills approve and merge something you did is like putting a giant “I’m worthy” stamp on yourself. It can even be as little as changing a typo, but knowing that many people use this project, every little change has a giant impact on yourself.

It might help your career going forward. Contributing to a project and understanding the inside and out of it can give you some points while interviewing, but don’t necessarily let your employer know that :).

Let your manager know — Contributing to Open Source is helping your company!

Understanding the product better is good for your employer because you can bring the knowledge you gain back to your organization. You can create better internal tools and write better internal documentation.

You can impact the future of a product your organization is using, and you can affect your company’s roadmap by outsourcing some features to the open-source project (where there’s a fit for that). This potential can lower the development cycle of your team/group and help your company better focus on what matters — the product you develop!

Having you as a contributor to a big open-source project is helping your company’s brand and can also attract senior engineers who also want the opportunity to maintain an open-source project.

Final Notes — Just do it!

To summarize, I encourage everyone to at least try and contribute to an open-source project. I understand that it’s scary and complicated initially, but working with the product, reading about it, and maintaining a product in production gives you the proper knowledge to start contributing back right now.

Usually, larger projects have thorough guidelines for receiving contributions, and mentorship programs are available. From my own experience, the community is really helpful and non-judgmental.

The review process itself is pretty pleasant, and you often get better flow suggestions that only help you see things with a more precise eye and make you learn more.

Contributing to open-source is a win-win-win situation. It helps the open-source project. It helps your employer. And most importantly — it helps YOU.