Open Source in Enterprise: Bridging Cultures

May 1st. International Workers' Day.

A day that celebrates labor, solidarity, and the dignity of work. While often associated with factory lines or protest marches, I believe it’s also a powerful moment to reflect on the people behind the software we build every day.

Because behind every commit, every deployment, every legacy system maintained or refactored, there are human beings collaborating, learning, and striving to do better.

In the world of enterprise IT, "Open Source" often feels like a nice idea that belongs elsewhere — in startups, tech conferences, or shiny GitHub repos maintained by passionate developers in their free time. Not in the world I work in every day.

My reality, as a Chapter Lead in a large bank, is quite different. My teams operate in a demanding environment where Java, React, and even mainframe technologies coexist. It’s a world shaped by regulatory constraints, legacy systems, and decades of technical decisions. A world where the words “open” and “source” are rarely seen in the same sentence.

And yet — the deeper I go into this world, the more I realize something important:
Open Source is not about tools. It’s not even about licensing. It’s a way of thinking — and that mindset is already alive here.

1. Between Systems and People

As a Chapter Lead, my role is to support teams in their craft. That means helping them grow technically, but also shaping a culture where quality matters, where collaboration thrives, and where each engineer can find their place — and their voice.

Some of our systems are modern, written in React and Java. Others are older, stable, and deeply integrated into the company’s operations — built in COBOL and still running on mainframe.

The technical complexity is real. But over the years, I’ve come to understand that the human complexity is even more fascinating — and more rewarding.

I work with incredibly talented individuals from all over the world. Each brings not only their skills, but also their culture, their experiences, their way of thinking. Navigating this diversity has been one of the most enriching aspects of my career. And it has taught me something essential:
what really matters is not just what we code — but how we code together.

And through all of this, we, as managers and leads, remain present on the field. We're not watching from a distance. We are part of the daily life of the teams, helping where needed, unblocking obstacles when they arise, and always listening.
We believe management is here to serve the teams, not the other way around. Our approach is not top-down. It's human-centered.

2. Rethinking What "Open Source" Really Means

When you mention Open Source in enterprise contexts, people often think of technical libraries, Linux distributions, or licenses like MIT or Apache 2.0. But that’s just the surface.

If you strip away the tooling and the jargon, what remains are principles — and these are universal:

🌐 Transparency — making things visible, even when they're not perfect.
🤝 Collaboration — inviting others into your process, rather than working in silos.
📖 Knowledge sharing — helping others grow by documenting, explaining, teaching.
💡 Autonomy and trust — giving space to explore, contribute, fail, and learn.
🡥 Community spirit — caring about collective progress, not just individual output.

These values are not just technical. They are deeply human. And they resonate far beyond any Git repository.

3. Trusting People to Take Ownership

One of the most powerful shifts we've made as a team is to give people the time and the space to work deeply — and to share openly.

We’ve moved away from top-down schedules packed with status updates, to a more fluid and empowering model. In this environment, people have the freedom to:

pair-code with colleagues in other squads or locations,
participate in Communities of Practice (CoP) focused on architecture, testing, or tooling,
attend or lead internal workshops and academy sessions to grow their skills and share expertise.

These sessions aren’t mandatory. They aren’t tracked on any KPI dashboard. But they work — because they are built on intrinsic motivation. When people are trusted and given the right context, they rise. They teach each other. They challenge each other. And they grow — together.

4. Building an Internal Contribution Culture

Of course, we’re not contributing daily to public Open Source projects. But we’ve built something just as meaningful within our own walls: an internal culture of contribution.

Here’s what that looks like:

🗺 We document everything as if it were public — not just the “what”, but the “why”.
🔮 We run weekly demos and code tours, to let teams showcase their work and get feedback.
🔊 We promote pair and mob programming, especially when juniors and seniors from different regions work together.
✨ We co-constructed a DevOps Improvement Roadmap, supported by external coaches, that helps teams elevate their craft in areas like test coverage, observability, CI/CD, and architecture.
🌟 We celebrate improvements — even tiny ones — because progress is built on those invisible but essential steps.

And most importantly: we don’t just write code. We write stories, habits, and systems that make the next step easier for everyone else.

That’s Open Source too — just under a different name.

5. Legacy as a Living System

When people hear "mainframe," they picture something static, outdated, maybe even dead. But I see it differently.

Legacy systems, in many enterprises, are like old cities: complex, rich, and full of hidden beauty. But they need curious and patient explorers — people who are not afraid to ask "why," or to shine a light into the dark corners of procedural code.

We organize onboarding sessions to demystify how batch processing works. We invite questions — and often rethink answers we thought were obvious.

This is not revolution. It’s evolution. But every step brings us closer to something healthier, more transparent, and more maintainable. And that’s what matters.

6. Conclusion: Walking the Open Path

There was a time when I thought Open Source only lived in open code. Now I know better.

Open Source is a mindset — and it can live anywhere. Even in a legacy-heavy bank. Even in regulated industries. Even in multicultural teams spread across continents and time zones.

It lives when we:

open our work to others,
take time to teach and be taught,
trust people to own and improve what they build,
and believe in progress — even slow, quiet, unglamorous progress.

Every week, I see signs of this mindset in my teams. In the way they share. In the way they challenge. In the way they build not just software, but confidence, quality, and community.

We may not release the next great Java library to the world. But inside our teams, we’re living Open Source every day. And that, to me, is the most meaningful contribution of all.

Open Source in the Enterprise: Bridging Cultures, Codebases, and Mindsets

Table of contents