New pattern proposal: Internal Developer Platform

[caldeirav]

Proposing the Internal Developer Platform under the maturity 1-Initial to start getting contributions across the InnerSource Commons.

The pattern will be presented and discussed in our upcoming community call: "Promoting InnerSource Practices with an Internal Developer Platform"

[welcome]

💖 Thanks for opening this pull request! 💖 The InnerSource Commons community really appreciates your time and effort to contribute to the project. Please make sure you have read our Contributing Guidelines.

If you are submitting a new pattern, the following things will help get your pull request across the finish line! 🏁

• Confirm that you have used our pattern template. Please remove any placeholder text and sections that your pattern did not need.
• We run a number of automated checks on your PR. Please review the output of those checks on the PR itself, and see if any issues got flagged that you can fix yourself.
• Make sure you have added your new pattern to the list of patterns in the main README.md. If you are unsure where to add your pattern, just let us know by commenting on your PR and we will help you.

This project has a small number of maintainers, volunteering their time to this project. So please be patient and we will get back to you as soon as we can. If we don't acknowledge this pull request after 7 days, feel free to chat to us about it in our Slack workspace.

[spier]

hi @caldeirav . Thank you for sharing this pattern with us, even including a sketch and everything! Amazing start!

The pattern contains a lot of detail about how the IDP should be structured, and implemented.

What I am missing is a stronger connection to InnerSource. As in, what are the type of InnerSource challenges that the IDP helps to solve?

For concepts like an IDP that are already pretty widely adopted (e.g. Backstage and all), we sometimes face this challenge when trying to describe the impact of the concept as a pattern. We want to clarify whether the concept is "a useful Engineering practice in general" or if it is specifically supporting some of the areas that InnerSource tries to solve for.

Some of the typical reasons for applying InnerSource can e.g. be found here.

Please don't get me wrong, I am not saying that the IDP concept can not be an InnerSource pattern. It is likely more about identifying (and highlighting in the pattern) how this connects to InnerSource.

If it helps I could also try to highlight individual sections in the pattern where I feel we could try to connect it more clearly to InnerSource? Please let me know if that would help.

[caldeirav]

here

Hi @spier, thank you, it is always helpful to have third party reviews because from my perspective I suspect a lot of the "connections" you describe between the IDP practice and InnerSource happened organically through experience. I would definitely like to make this clearer for readers.

First and foremost, we just had a community talk on the subject (recording now available here) and we shared about the symbiotic relationship between IDP and InnerSource from two angles:

1. An Internal Developer Platform is an essential component to scale InnerSource strategies and practices across the organisation at some point. In large organizations, not standardizing development practices makes it very hard for InnerSource contributors to be effective at contributing to new projects across a large number of teams.
2. Conversely, InnerSource practices can supercharge your IDP journey through channeling internal contributions to platform engineering requirements which are common blueprints to address problems faced across the organization.

But let's tie this to some of the concrete challenges referred to in the link you shared here:

Reduce development silos caused by excessive ownership culture
An IDP breaks down silos by standardizing tools, environments, and processes across teams. It fosters InnerSource practices, where code and resources are shared across teams, reducing excessive ownership over particular tools or systems. By providing a centralized platform, IDPs make it easier for teams to collaborate, access shared resources, and contribute to each other’s work without the traditional territorial boundaries​.

Increase innovation speed by reducing time spent solving similar issues by fostering healthy code reuse
IDPs provide a central repository of templates, services, and reusable components, which encourages code reuse across the organization. Developers can access these assets directly from the platform, reducing duplication of effort. By integrating with documentation, APIs, and existing solutions, IDPs streamline the process of leveraging previous work, enabling teams to focus on innovation rather than reinventing the wheel​.

Increase development speed by better cross-team collaboration
IDPs offer shared tools and environments, facilitating cross-team collaboration by providing transparency into what other teams are working on and how they’re solving problems. Teams can easily contribute to or adopt each other’s work, aided by a self-service portal that enables them to set up environments and access services independently. This reduces communication overhead and accelerates collaboration​.

Solve project/team dependencies beyond "wait it out" and "build workarounds", thereby reducing engineering bottlenecks
IDPs allow teams to self-serve infrastructure, environments, and tools, reducing dependency on other teams to manually provision resources. By centralizing access to infrastructure and automating common processes like CI/CD pipelines, dependencies are less likely to create bottlenecks.

Increase quality
IDPs increase software quality by enforcing standardized practices and providing built-in guardrails for governance, security, and compliance. Automated testing and deployment pipelines ensure that all code adheres to the organization’s quality standards before it goes into production. Moreover, since developers can focus more on solving high-level problems rather than fighting with tooling and environment setup, they have more time to improve code quality​.

Increase employee happiness
As highlighted in our presentation, increasing Developer happiness is the number one objective of an IDP (we talked about Platform-as-a-Product). By reducing friction in the development process, an IDP allows developers to focus on what they do best which is writing code and solving meaningful problems. Self-service capabilities reduce waiting times for resources, while centralized platforms eliminate the complexity of managing disparate tools. This leads to a more streamlined developer experience, which in turn boosts job satisfaction and productivity​.

Increase success of new hires
IDPs simplify the onboarding process by providing new hires with easy access to pre-configured environments, documentation, and templates. Rather than spending their first weeks figuring out how to set up their development environment or learning which tools to use, new hires can start contributing much faster. The IDP serves as a single point of entry for everything they need, dramatically reducing ramp-up time​. As discussed during the presentation, developer onboarding time (we measure it typically by looking at the first approved commit) is key metric in IDP implementation.

Build actionable documentation
An IDP integrates documentation directly into the development workflows via self-service portals. Teams can access API documentation, code examples, and templates from the same place they access tools and environments. This centralization ensures that documentation is kept up-to-date and easily accessible. Furthermore, by encouraging InnerSource contributions into the documentation itself (from users), teams can continuously improve documentation based on real-world usage​.

I would definitely like to have your advice on 1) Whether the above makes sense and clarifies your ask (or if you still see gaps) and 2) What would be the best way to integrate the additional information into the pattern template?

And also accessorily what the best way is to get this pull request through while still getting feedback from potential contributors. Thank you for your feedback!