I have spent most of my career inside small companies, so the Siemens Element story catches my attention every time. A 1000 product enterprise codebase did not become a public open source project overnight. The team spent a decade on inner sourcing (an internal practice where company divisions use the same collaboration patterns that open source projects use, but inside a single corporate firewall) before they touched GitHub. I think that timeline is the part most enterprise teams skip, and the part most enterprise open source launches blow up on.
I went looking for the operational lessons in the published write up of the Open Source India 2025 talk by Laxminarayan Chandrashekar from Siemens Technology and Services. What follows is the engineering blueprint the team used, with the bits I think translate to a smaller shop.
The starting point is not code, it is access
The Siemens team faced a familiar problem at scale. Independent business units across medical imaging, building automation, and industrial systems were solving the same UI problems in parallel. The hardest part was not technical. The hardest part was letting an engineer in one division find the work an engineer in another division had already shipped.
Before any decision about MIT licenses or GitHub repositories, the Siemens team stood up an internal GitLab instance at code.siemens.com and treated it as a single hub for cross business unit work. That sounds mundane. It is also the step most teams skip. Friction of the kind the original article describes (engineers could not find what other engineers had built) is a tooling and process problem before it is a licensing problem. Fixing it required nothing about open source at all.
A decade of inner sourcing followed. Engineers across divisions contributed bug fixes and features back to the shared design system rather than carrying parallel forks. Maintainers wrote an internal inner source license so every Siemens unit could legally reuse and modify shared repositories without involving lawyers on every pull request. Those two moves, a single internal hub and a license that did not require legal review per change, are the foundation the open source release stood on.
Architecture before publicity
When Siemens finally decided to publish, the team did not dump the whole monorepo into a public repository. They split the codebase along an axis that mattered for legal and branding reasons. Public components became a GitHub repository under a permissive license. Proprietary themes, Siemens branding assets, and specialised business logic stayed inside the internal monorepo.
That split is not optional. Releasing software under MIT does not transfer trademark rights. You cannot ship a logo with the permissive code and expect the public to keep using it correctly. Siemens decoupled the brand from the components so the open source release was usable by anyone, including teams that wanted to rebrand the design system for their own OEM (original equipment manufacturer, a company that builds products sold under another company’s brand) hardware.
The team also picked a public distribution channel that mattered more than the source code itself. The component library shipped to GitHub at github.com/siemens/element and published as an NPM package under @siemens/element-ng, with a hosted playground at element.siemens.io. Each of those is a familiar surface for the developer audience Siemens wanted to recruit. Putting the project on a registry that was already in their workflow mattered more than any choice about file format.
The dual platform strategy that keeps the secrets secret
The most useful detail in the Siemens story is what stayed internal even after the public release. Public issues, public pull requests, public roadmaps: yes to all of that. Internal bug triage, product context discussions, security vulnerability reporting: all of that stayed inside the corporate firewall.
Reasoning here is simple. Public issue trackers are a place where engineers accidentally paste confidential product context, customer names, or internal architectural details that should not be in a commit message. Siemens built two separate pipelines. Public CI/CD mirrored the public repository and ran on public infrastructure. Internal CI/CD synced the same code into the enterprise monorepo, where security teams and product managers could review changes with the full internal context attached.
If you are thinking about open sourcing a corporate codebase, the dual platform pattern is the recipe. Do not try to filter confidential information out of a single public tracker. Run two of them, with automated sync between them, and keep the canonical triage surface inside your own network.
What translates to a smaller team
The Siemens playbook is mostly enterprise scale, but three lessons apply to a five engineer team that wants to publish an internal library.
First is the timeline. Ten years of inner sourcing before the public launch is not a Siemens specific quirk. Duration reflects how long it takes for engineers across an organisation to actually trust a shared library, learn the contribution workflow, and stop carrying private forks. If you are planning an open source launch, plan two years of internal use before the public release. Anything shorter and you are publishing code you have not yet exercised at scale.
Second is the legal decoupling. Strip the brand before you publish. If your company name, logo, or trademarks are inside the components, refactor them into a separate layer before you push. The community can replace them later. You cannot retroactively un publish a trademark you embedded in a button class.
Third is the tooling. Pick the public distribution surface that your audience already uses. NPM for JavaScript components. PyPI for Python packages. crates.io for Rust. If your library only ships on GitHub and the install steps involve cloning a repository, your adoption ceiling is the number of people willing to clone a repo. Siemens picked GitHub plus NPM plus a hosted playground because their audience already lived in those three places.
Fourth is the inner source license. Most small companies do not have one, and most small companies do not need a long one. Two pages that say “anyone in the company can use, modify, and contribute back to the shared repositories, with no legal review per change” is enough. Lawyers can refine it later.
Trade-offs
Inner sourcing before open sourcing is expensive. The Siemens team ran an internal GitLab, an internal license, dual CI/CD pipelines, and a separate issue triage process for years before any public benefit appeared. Cost is real engineering time and corporate attention that could have gone to shipping product.
The brand decoupling work is a one time tax that compounds. Refactoring every theme, every logo reference, every trademarked component before publishing is a chunk of work that does not produce features. It only becomes valuable when the public release lands.
Dual platform maintenance doubles the surface area. Every change to the public library has to be mirrored to the internal monorepo. Every internal change has to be reviewed for confidential content before it gets mirrored back. Automation that keeps them in sync is itself a system that can break.
Timeline itself is the most expensive trade-off. A decade of internal work before any public visibility is a commitment most leadership teams will not make. Siemens earned that latitude by reaching 1000 internal products and 900 internal contributors before going public. Smaller companies will not get the same runway. Honest version of this playbook for a small team is: do two years of internal use, do the brand decoupling up front, do the dual platform sync from day one, and accept that the public release will not shift revenue on its own.
What I would tell past me
Three things, if I could send them back to the version of me that thought about open sourcing an internal library once.
- Plan for years, not weeks. Inner sourcing is not a sprint. It is the longest part of the work and the part you cannot shortcut without breaking the public release.
- Decouple the brand before you publish. Once a trademark is in a public commit, you cannot take it back. Refactor the brand layer out, then publish the rest.
- Pick the distribution channel your audience already lives in. A public GitHub repository with no NPM or package manager presence is a graveyard. Publish where your users install from.
- Write the inner source license before the public one. Two pages that say “anyone in the company can use, modify, and contribute back” is enough to start. You cannot retrofit the workflow once the codebase is public.
If you only do one of these, do the brand decoupling. Everything else can be recovered with time and effort. A trademark embedded in a public component is forever.