The Hidden Cost of Contributing to Open Source

Software has always been something people shared. Something we learn from, draw inspiration from, and build upon.

I'm a very mathematical person. My time is always structured, my efforts are consistent. Always. Because of that, I tend to work fast and efficiently. When I reach out or take on tasks, things usually move quickly.

That's why I was naturally drawn to open source. It seemed like the perfect place for someone like me. A space where real contributions could happen fast, where efficiency and good ideas would be welcomed. At least that's what I expected.

What Open Source is Supposed to Be

Open source is a way to contribute to the software you use, to the world, and to leave your own mark on it. It's about improving reliability, fixing what's broken, and making things better for everyone.

It has always been a way to verify. When a bug shows up, more eyes on the code means it gets spotted and fixed faster. That's where the whole "safer" reputation comes from. The idea is that the community acts as a living review system. People spot issues the original authors missed.

And supposedly, if you follow the standards laid out in the repo with which you are working, point out real problems, and submit solid work, your contribution is welcomed. The fast, efficient contributor who doesn't waste time on pointless stuff and just gets things done? That's the ideal.

The initiative is supposed to be celebrated. It was meant to be a welcoming, collaborative place. A meritocracy where good code wins.

But the reality is often very different.

Nowadays, contributing is frequently not welcomed. Decent PRs get met with hostility, bikeshedding, or outright rejection. Even on very popular projects! The same maintainers who gatekeep the repo are often the ones killing momentum. This isn't rare anymore. Sadly, it's become pretty common. I've experienced it quite a few times myself.

It's worth noting that small contributions are usually okay: a typo fix, a minor doc update, a one-line bug fix. To an extent, the door is still open for those. But the more serious and active you get: the bigger the feature, the deeper the change, the more time you invest. The worse it often becomes. That's when the walls go up.

Worse, in many cases the loudest maintainers aren't even the original creators. They jumped in later, sometimes with limited real-world experience in the domain, and after 5+ years they're still enforcing the same rigid, unhelpful standards. You see this pattern in projects that exploded in popularity during the 2015–2020 boom. All of a sudden the maintainer team is full of people who treat deep external contribution like a threat to their fiefdom instead of help.

The result? Issues stay open for years, valuable PRs rot because they "can't be implemented right away," and the project slowly stagnates while the maintainers pat themselves on the back for "maintaining quality."

That's what a lot of open source has become. The beautiful ideal is still there in some projects (Linux kernel, some smaller passionate communities), but far too often it's replaced by ego, gatekeeping, and burned-out contributors who just walk away.

My Recent Experience

It started simply enough. I made a small change, and it went through without any issues.

Then I moved on to a more meaningful improvement: cleaning up error handling and adding proper fsync on the directory for crash safety in the file writing function. Since the code was originally copied from container networking library, I first submitted the changes upstream there. Once that was in motion, I brought the updated version into the distribution of k8s.

At this point, a maintainer suggested moving the logic to a file handling abstraction library instead of maintaining it ourselves. I agreed and started updating both repositories to use that library for atomic writes.

When it came to Windows support, things got complicated. The library maintainer had previously stated that reliable atomic writes on Windows weren't really possible. I opened a discussion there to explore better options, but the conversation turned dismissive. My proactive approach across the projects was described as "aggressive" and even "smelly."

That's where the tone shifted noticeably. What began as a solid technical improvement across related codebases became an unwelcome effort in the eyes of the main maintainer.

For contrast, around the same time I made a similar lateral change in another project (improving atomic installation of CNI configs and binaries), and it was received positively and merged without drama.

Where Things Went Sideways

What began as a proactive effort to improve crash safety and atomic file writes across related projects quickly turned negative. The suggestion to handle the changes properly and consistently was framed as aggressive. Even the idea of contributing upstream where the code originated was met with resistance and dismissive language like "smelly."

That's when the environment started to feel unwelcoming. Instead of engaging with the technical merits, the focus shifted to pushing back against the scope and thoroughness of the contribution itself.

It makes you wonder about the main maintainer in particular. As one of the long-time maintainers of the k8s distribution (and someone deeply involved with blue cow company), he carries a lot of responsibility for the project. He's been around for years shaping its direction (without having any credentials to do so he is doing bad work). But in moments like this, it felt like the priority was some principle of the current way of doing things rather than welcoming improvements that required coordination and deeper changes. The contrast became very clear when I made a similar lateral improvement in another project, where it was accepted smoothly and merged without drama.

The Hidden Costs

It is a peculiar time to be called "AI" by the very people you interact with and try to help. You invest real effort, you collaborate, you bring improvements. And sometimes you're still met with hostility and unprofessionalism.

To be honest, it takes a toll. Especially when it happens in important projects. It makes me believe in open source a little less. It chips away at the dream of open software where we can actually contribute together, get smarter together, and build something better as a community. But sometimes life doesn't turn out the way you expect, and that's okay.

Still, at some point you have to raise the white flag. You see the red flags and you simply move on. Because no matter how good your work is or how pure your intentions are, the relationship gets tainted. That's exactly what happened to me. Having to step away for the foreseeable future felt pretty abrupt, especially after I expected to contribute a lot.

I used to think that getting better, constantly educating myself, reading technical books and taking detailed notes (sometimes going over 800 pages in just 3 days), writing, drawing, improving every way I can, was clearly a positive thing. That it would be valued.

Yet not only was I rejected in interviews for being "too smart" and the team "not having good enough complexity," but I've also been pushed out of open source projects just because I was deemed "not right."

Well, they say things have a smell to them. Or so I was told recently.

Why engage in a productive argument when you're not capable of it? It's easier to resort to personal attacks. Instead of solving the actual problem, some people focus on targeting the person behind the PRs, because they can't handle being challenged on the work itself. Because they have no capacity to.

Lessons Learned

I was sitting in a park, looking at the trees. It was a peculiar moment. The birds were chirping, the bench was hard under my back. I put my hand on the back of the bench, reclined, and just relaxed for a while.

I was telling one of my pals what had happened. His only real advice was simple: disengage from the project for a long time and remove the company behind it from your LAMP list (a list of companies to engage, collaborate, help and contribute to).

To be honest, I was very disappointed. The whole experience left a really unpleasant aftertaste, especially because I was serious about contributing and becoming a meaningful part of the project.

And that's exactly what I did. My expertise, my effort, and my skills can be taken somewhere else. Somewhere they will actually be valued.

That's the lesson. And at the same time, that's the beauty of open source. You can always find your own people. One project might disappoint you, but another one will welcome the way you work. You can contribute, create new ventures, and get involved in the things that excite you.

Ultimately, you HAVE A CHOICE. That's the real lesson.

Bad interactions and toxic ecosystems show you exactly what you don't want. So you can learn from them, improve on them, and build something better for yourself. It's a lesson in how to treat people and how to deal with people who are difficult.

The lesson is that you can still build something you truly love and enjoy being part of. Whether it's an open source project or your own company in the space.

There are many other projects out there that will welcome high-quality contributions without all the drama.

Final Thoughts

It is a system issue. It's an issue with conduct, with respect, and with quality of character. You can't build real character on a whim. It takes deliberate work over many years. And sadly, most people never develop it.

Somehow bad behaviour has become acceptable in our world. Everything runs on utility, and too many copy the attitude of people who reached success despite lacking any real depth or sophistication. That's the ultimate laziness, instead of looking inside, asking hard questions, and thinking deeply about their actions and beliefs, they just imitate what "worked" for others.

To be honest, this experience left me a lot more sceptical of contributing to anything that is not mine.

That's how my experience went. At first it was alright, but the more serious and important my contributions became, the worse it got. So I stepped away from contributing to the project for the foreseeable future.

There are always better projects out there, and I've already found mine. There are many. You have a choice. You can walk away. You can choose not to use, not to contribute, and not to waste your energy on projects that don't value you.

After all, there is better fish in the sea. Places where your effort is appreciated, where you are treated with respect, and where you can actually thrive.