How do you take a massive internal enterprise codebase used by over 1000 products and successfully release it to the public? In this session, you can glimpse the 10-year evolution of the Siemens Element Design System. Learn how we tackled enterprise silos by establishing a thriving inner-sourcing culture across global teams, and discover the strategic, legal, and architectural playbook used to transition from proprietary code into an open source ecosystem without risking brand integrity or security.
Taking a massive internal enterprise codebase used by over 1000 products and successfully releasing it to the world is one of the most complex undertakings in modern software engineering. Many developers firmly believe that the internal software crafted within their enterprise far exceeds the quality of freely available public tools. They naturally feel that this engineering excellence should be shared with the broader global community. However, translating that ambition into reality is far easier said than done. Executing this transition involves unraveling decades of architectural complexity, navigating intricate legal frameworks, ensuring compliance across international boundaries, and safeguarding corporate brand integrity without compromising security.
The decade-long evolution of the Siemens Element Design System offers a definitive operational blueprint for this technical transformation. Over ten years, Siemens systematically dismantled entrenched organisational silos, cultivated a thriving inner-sourcing culture across global engineering teams, and ultimately deployed a strategic playbook to transition proprietary software into an open source ecosystem.
Dismantling Enterprise Silos Through Inner-Sourcing
A decade ago, Siemens faced a classic enterprise challenge: deep organisational silos. Operating as a massive global conglomerate across radically diverse domains, ranging from medical imaging devices like magnetic resonance imaging (MRI) machines to complex building automation systems, finding information within the company was often significantly harder than searching the internet. Independent business units frequently developed duplicate solutions and parallel libraries simply because they lacked visibility into assets created by other departments.
This operational friction motivated the initial push toward inner-source collaboration. The primary objective was aligning web and mobile platforms across all business units to ensure brand consistency, elevate application performance, maximise component reuse, and foster cross-functional engineering collaboration. Rather than allowing each division to build isolated front-end interfaces, Siemens sought to create a unified ecosystem where teams could seamlessly leverage existing, battle-tested components from a shared corporate repository.
Siemens Element: Building the Core Design System
The foundational project driving this transformation was Siemens Element, a comprehensive design system originally engineered for the smart infrastructure domain. Designed as a complete user interface (UI) foundation, Element encompasses core design tokens, typography, standardised color schemes, layout components, user experience patterns, and icon sets. It was engineered not just for standard web platforms, but also for complex hardware interfaces powering internet of things (IoT) devices and cloud platforms.
Crucially, when development began ten years ago, the team chose an inner-source model rather than hard-coding the library exclusively for a single business unit. They engineered Element to be flexible, modular, and extensible so that disparate engineering divisions could adopt, customise, and contribute back to the codebase. This internal alignment was essential because going open source on day zero is rarely viable for enterprise software. Success requires first instilling a collaborative culture, establishing internal maintainer workflows, and nurturing an active contributor community before opening the codebase to the public.
Engineering Strategies and Architectural Best Practices
Siemens executed its inner-source strategy by strategically combining open source software with selective commercial off-the-shelf tools. The maintainers adopted an upstream-first philosophy: rather than maintaining isolated internal forks of popular open source packages; they actively contributed bug fixes, performance enhancements, and new features back to public projects like Angular and ngx-datatable.
To establish a frictionless developer experience, Siemens launched code.siemens.com, an enterprise GitLab instance serving as the central hub for company-wide collaboration. The team prioritised modular architecture, keeping the core Element library lightweight while isolating specialised components so that application teams could import only what they needed. Guided by the core engineering mantra of ‘do less, but do it well’, the maintainers prioritised exceptional code quality, comprehensive unit and end-to-end test coverage, detailed documentation, and continuous knowledge-sharing through internal workshops and technical hackathons.
Pillars of Inner-Source Success: Infrastructure, Approach, and Culture
The long-term success of Siemens’ inner-sourcing initiative rested on three structural pillars: environmental infrastructure, project approach, and team culture. From a legal standpoint, operating across global geographies introduced complex compliance considerations, including intellectual property distribution and cross-border tax implications when transferring software between international subsidiaries. To resolve these friction points, the team collaborated with corporate legal experts to draft a standardised internal inner-source license, granting every Siemens unit the legal freedom to utilise and modify shared repositories.
From a product approach perspective, the maintainers focused ruthlessly on real-world developer and user needs over purely theoretical technical optimisations. To accelerate enterprise adoption, they created automated command-line interface (CLI) tooling that enabled developers (even those without front-end expertise) to generate a production-ready, brand-aligned application scaffold in under twenty minutes. Supported by radical operational transparency across roadmaps, issue trackers, and technical planning, the maintainers cultivated a two-way community where developers felt empowered to submit pull requests and directly shape the platform’s trajectory.
Business Drivers Behind the Open Source Pivot
After a decade of internal refinement, with over 1000 production products actively relying on the Element design system and more than 900 internal contributors involved, business imperatives shifted the project towards open source deployment. Original equipment manufacturers (OEMs) building automation hardware for Siemens required long-term maintenance and external access to the design libraries, which was difficult to manage within a restricted internal network.
Simultaneously, the expansion of the Siemens Xcelerator ecosystem, an open digital business platform enabling third-party developers to build custom integration services, demanded a publicly accessible design foundation. Hosting the codebase on GitHub eliminated onboarding friction for external partners, significantly elevated corporate technical transparency, enhanced developer recruitment efforts and ensured seamless integration with modern generative artificial intelligence (AI) development workflows and automated code indexing tools.
Navigating Legal, Branding, and Operational Challenges
Transitioning a decade-old enterprise codebase to a public open source repository presented substantial legal, technical, and operational hurdles. Releasing software under permissive open source licenses like MIT introduces brand compliance risks, as corporate logos and trademarked visual identity assets cannot be freely distributed without strict usage governance. To overcome this, the engineering team decoupled the architecture, separating reusable, themeable UI components from proprietary Siemens branding assets.
Communication and security management added another layer of complexity. To prevent accidental leaks of sensitive internal product context or confidential security vulnerabilities through public issue trackers, Siemens implemented a dual-platform strategy. The production source code was migrated to GitHub for public visibility, while internal bug reporting, product context discussions, and proprietary security triage remained securely contained within internal network boundaries.
The Transformation Playbook and Technical Architecture
To execute this transition seamlessly, Siemens established a repeatable open source playbook. The strategy began with defining a clear business rationale, followed by rigorous legal clearing through dedicated open source compliance officers. Architecturally, the codebase was split into two synchronised environments: a public open source repository on GitHub stripped of proprietary code, and an internal enterprise monorepo containing proprietary themes, assets, and business logic.
The rebranded Siemens Element Design System was officially released publicly on GitHub at [github.com/siemens/element](https://github.com/siemens/element) and published as a global node package manager (NPM) package under @siemens/element-ng, accompanied by an interactive live playground hosted at element.siemens.io. Underneath the surface, sophisticated continuous integration and continuous delivery (CI/CD) automation pipelines maintain continuous bi-directional synchronisation between the public GitHub repository and the internal monorepo. When universal enhancements or bug fixes are submitted publicly, automated workflows process and mirror the code back to the internal ecosystem, ensuring the external public release and internal enterprise environments remain perfectly aligned.
Strategic Balance and Enterprise Takeaways
Faced with the choice between remaining purely inner-sourced or fully opening every layer of software, Siemens selected a balanced hybrid model. By open-sourcing reusable, non-critical UI components while keeping proprietary branding assets and specialised business logic internal, the company successfully balanced community engagement with enterprise intellectual property protection. Today, a multi-geographical team spanning India, Switzerland, Germany, and Italy continues to maintain and evolve the platform.
The primary takeaway for enterprise engineering organisations is clear: do not jump directly into open source without first establishing a mature inner-sourcing culture. Establishing internal collaboration networks, enforcing rigorous code quality standards, and securing clear executive alignment are mandatory prerequisites. When executed strategically, open sourcing transforms proprietary software from an isolated corporate asset into a thriving, globally collaborative ecosystem that drives innovation, builds cross-industry trust, and elevates modern software engineering standards.
The article is based on the talk ‘A SiMPL Journey from Inner Source to Open Source’, by Laxminarayan Chandrashekar, Siemens Technology and Services, at Open Source India 2025. It has been transcribed and curated by Jiya Jay Singh, Electronics For You.
