How Open Source Enables Collaboration in Creating a Platform

A platform is a collaboration system: platform teams depend on application teams, and both need shared standards, as Marcy Paramonova and Stéphane Cusin explained in their talk Building Cloud Native Culture in a Bank at KubeCon & CloudNativeCon Europe. Engineers trust a platform through its predictable behavior, not its features.

Open source gave something we desperately needed: a shared standard and a common language between teams, vendors, and tools, Cusin mentioned. Open source was not an obvious choice in a bank environment. There were questions about support and accountability.

A banking environment first requires trust, Cusin argued:

Trust was not a decision. It is built by operating the platform day after day and through consistency. As platform engineers, we learned that developers do not trust a platform because of its features; they trust it because it behaves predictably.

A platform is a collaboration system, Paramonova said. Developers and product teams depend on a platform team. The platform team depends on the application teams, and both need to go forward; for that, they need shared standards.

Open source users not only consume the technology, but they also contribute to it, create communities around it, and exchange ideas about technology, Paramonova said. Our interpretation of one of those exchanges was our Genius Bar sessions:

We wanted to step back from our usual supporting driver tickets and offer something new and fresh to our users. We did open support sessions when they could come, and we would solve their problem with them. And over time, a lot of people got interested, so we’re actually joined by a lot of infrastructure teams

Engineers can benefit by upskilling their soft skills, which helps everybody work better together, Paramonova said. She mentioned that they have a community-driven approach, where people create clubs or communities around technology, and maintain them.

Ownership changed the engagement among the engineers, Paramonova said. They are not only trusted to execute tasks, but also trusted to make real decisions and have a real impact.

Being an engineer is about problem-solving and being passionate about it. And being an engineer means sharing your passion for problem-solving, Paramonova mentioned.

Open source is not just a software choice; it&squo;s a commitment, Cusin said. If you only change the tools, but not how people think, collaborate, and build, you will hit a wall.

Open source was never a directive from the management, Cusin mentioned. It was never a dogma. It was never “nobody told us you must use open source”. It was a compass, something that helped us orient this subject, Cusin concluded.

InfoQ interviewed Marcy Paramonova and Stéphane Cusin after their talk.

InfoQ: What have you done to build trust with your platform&squo;s users?

Stéphane Cusin: We invested heavily in standardization, automation, and operational excellence. Whether teams deploy to development, testing, or production environments, they should have the same experience and the same expectations. We also made platform responsibilities explicit. Teams know which services are operated by the platform team, what service levels they can expect, and where their own operational responsibilities begin.

Another important aspect was reducing cognitive load. Instead of exposing every Kubernetes capability, we tried to provide sensible defaults and opinionated workflows. Developers should be able to focus on their applications rather than on understanding the complexity of the underlying infrastructure.

Marcy Paramonova: When we introduced new components or features, we did not wait for perfection before sharing them with our users. We gave people visibility into what we were doing and why.

That transparency turned out to be more valuable than a polished product. Users became early testers and collaborators rather than passive consumers. Over time, that relationship built something that a release announcement never could.

InfoQ: How did your engineering culture shift over time?

Paramonova: Open source communities have a specific culture. They document their decisions. They contribute back. They make ownership explicit, so people know who maintains a component, who makes decisions, and where to go for help.

We tried to internalize those practices. When you adopt Kubernetes, you are not just adopting a container orchestrator. You are joining a community with norms, expectations, and a way of working together. That pulled us toward more transparency, more shared ownership, and a stronger sense of craft.

The culture did not shift because someone announced a culture initiative. It shifted because tools demanded a certain way of working, and over time, that way of working became ours.