Leveraging Internal Platforms through InnerSource

Author: Arthur Fücher

When we look at the development scenario in large organizations, one challenge stands out: teams working in isolation, duplicating efforts, and missing opportunities for collaborative innovation.

In their research on top-performing tech companies, McKinsey emphasizes the need to eliminate operating-model silos. They found that leading companies are more than twice as likely to organize their engineering teams in product- or platform-centric operating models. This approach reduces time to market, lowers tech solution costs, and enforces greater accountability between business and tech teams.

This intensifies with the creation of internal platforms and frameworks, as was the case with our Backend Driven Content (BDC) – our platform which we have another blog post discussing in more detail – where all mobile development depended on the platform. 

What is InnerSource?

The term was coined by Tim O’Reilly and his definition of InnerSource was “to use open source development techniques within the corporation, or with a cluster of key customers – even if they aren’t ready to take the step all the way to releasing their software as a public open source project.”

Years later, in 2015, the InnerSource Commons Foundation (ISC) was founded and it is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. In the website their definition of InnerSource is:

InnerSource takes the lessons learned from open source software development and applies them to how companies develop software internally

Let’s use a concrete example: imagine we need to develop a new onboarding screen that requires a component that is still not implemented in the internal framework of the company. In the traditional model, you will ask the team responsible for the framework to prioritize this in the backlog and wait until they finish.

With InnerSource, the process transforms:

• The owning team defines contribution process
• Developers from other teams can propose solutions and implementations
• Code reviews involve multiple perspectives, improving quality
• Created components become available for reuse in other projects

Why InnerSource?

The ISC makes an annual survey to understand the State of InnerSource, in 2024 it was a questionnaire administered using Qualitrics and was open for approximately 12 weeks in November-January 2024.

According to the State of InnerSource 2024 report, ~68% of organizations participate in InnerSource motivated by Creating reusable software, Remove silos & bottlenecks and/or Knowledge sharing.

On the other hand, for individuals the value is in Share knowledge (66% of respondents), Get to know more people within the organization (62%) and Improve the quality of the software I (or my team) work on (54%).

How We Structured Our Approach:

When building the platform, we kept one of Nubank’s core values in mind: we want our customers to love us fanatically. In this case, our “customers” are internal developers. That distinction matters—because while we’re not directly impacting Nubank’s end users, the experience we provide to developers ultimately enables them to deliver faster, build better solutions, and create delightful experiences for our customers.

From the very beginning, we built this platform in close collaboration with our internal teams. By treating them as true partners—listening to their feedback and learning from their experiences—we fostered a sense of community and co-creation that shaped the solution together.

• Clear contribution processes: We created standardized flows so that anyone could propose improvements, including documentation, regardless of their team of origin. Reducing the friction between an idea and its implementation.
  For example, to migrate a Flutter component to BDC:

1. The contributor need to check if the component really does not exist
2. We provide a CLI tool for creating most of the boilerplate code
3. The person do some final customization
4. Open the PR filling the template
5. Then open a ticket with the PRs links

All these steps are described in the Contributing Guide in the Official documentation of the BDC platform.

• Sense of community: We want people to feel comfortable to share their thoughts and feedback, help each other and contribute to the platform.
• Improved documentation: People need to be able to learn at their own pace, and have autonomy to go deeper. They can’t be dependent on the Core team of the project always, this does not scale.
• Dedicated roles: The team was composed besides the normal roles (SWE, TM, PM), by a Tech Writer and a Developer Advocate.  Having those dedicated roles helped to focus on different areas in a specialized way, like promoting the culture of InnerSource.

Results

Our internal BDC  community already brings together around 1,000 developers, with more than 85% actively engaging in discussions. Beyond channel activity, the real impact shows up in how teams interact with the platform.

We’ve seen over 90% organic adoption across teams, which directly translates into more contributions and stronger cross-team collaboration. As a result, delivery times have improved—since developers don’t need to wait for the Core team’s prioritization to move forward.

Most importantly, ticket data highlights this shift: while the number of contributions steadily increased, tickets to the Core team related to bugs, crashes, or questions have consistently decreased over time. This trend reinforces how InnerSource is reducing bottlenecks and driving autonomy.

What’s Ahead

InnerSource has proven its value, delivering the results we expected and establishing itself as a solid standard for internal projects.

Today, our Experimentation Platform is also leveraging InnerSource to unblock projects and features, and several internal libraries and projects have started to adopt the same approach.

Looking forward, we are continuously refining our processes, investing in tooling that makes collaboration easier, and most importantly-nurturing a culture where knowledge sharing is natural and valued.
One of the upcoming challenges is managing the growing number of contributions. A possible next step will be to adopt the Trusted Committer pattern, empowering selected contributors outside the Core team with the responsibility to approve or reject contributions.