By Zachary Bobroff, Chief Product Officer, AMI
AMI has been a firmware company for 40 years. For the first 35 of those, we built strictly proprietary BIOS and BMC solutions, and those products still serve most of our customers very well. But a gradual shift was quietly underway, so that by 2021 the Open Compute Project had become the gravitational center of data center innovation. From there forward, hyperscalers, ODMs, and silicon vendors were all building in the open. We could either participate or watch the industry move without us. That was not a hard call.
Where the Real Value Lives
The thing that most customers value from AMI is not the base capability of booting a platform or managing it. Value lies in the advanced features, the speed of security fixes, and the path to market. Open-source foundations like EDK II and OpenBMC™ sat on the periphery for years, handling those base layers. Contributing our code to OCP across Aptio®, MegaRAC®, and Tektagon® let the community share in validation and core innovation while we focused higher in the stack, on the work that can truly differentiate our customers’ products.
AMI sits between system manufacturers like OEMs and ODMs and data center operators like hyperscalers and neoclouds. While open-source projects like EDK II and OpenBMC offer great places for collaboration, OCP is where you find the most interaction between operators and manufacturers. Leveraging these open-source projects and AMI’s unique market connections provides a great way for AMI to contribute to OCP-specific platforms. That position gives us a rare line of sight across the whole firmware landscape, and we take the responsibility that comes with it seriously.
Learning to Move at Open-Source Speed
That shift is still underway. Open source moves at a pace that catches many by surprise. In the traditional OEM world, firmware updates ship every six months – after months of broad testing. Hyperscalers operate differently. They use systems one way, replace them like field components, and expect regular updates. We had to build product solutions for both speeds: rapid cadence for hyperscalers, and a more stable and longer-validated code base for everyone else.
Speed alone is not the point, though. Our CEO Sanjoy Maity recently described the challenges facing AI data center operators as a 5-Headed Hydra: fragmentation, security, power and thermal management, fleet scale, and the criticality of the control plane. Each one feeds the others. You cannot ship firmware faster without also tightening security. You cannot unify a fragmented code base without thinking about how it scales across thousands of nodes. The velocity question we wrestled with inside AMI is just one head of that Hydra, and open source is how we started fighting all five at once.
Contributing code also taught us something we did not expect. Committing is not enough. You must explain why a change matters to the community. Every contribution goes through two to three months of review before it merges. A community-led project moves fast in some directions and slower than you would predict in others. We are still learning that rhythm.
A Distribution, Not a Fork
One of our biggest initiatives at AMI right now is MegaRAC OneTree™ Community Edition (CE), our distribution of OpenBMC built as an open foundation for production-ready deployments. The Linux Foundation version is the upstream source of truth, but in practice, hardware and silicon vendors have forked it in different directions. If you are using a BMC from one vendor and a host processor from another, you are cherry-picking from scattered branches to assemble a working stack. That is the fragmentation problem. Other forks in the market tend to be tied to specific hardware vintages or a single vendor’s platform.
MegaRAC OneTree CE is hardware-agnostic by design, built to support multi-vendor environments because that is the reality most operators live in. Think of it the way Ubuntu™ or Fedora relate to the Linux® kernel. The kernel is the foundation; the distribution makes it usable at scale.
Our principle is upstream-first. We pre-vet features with maintainers to streamline reviews and commit to upstreaming everything that the OpenBMC project will accept. Some changes ship in MegaRAC OneTree CE first because we can move faster on our own code base, but they go upstream on the back end. This is not a fork. It is a release and versioning discipline layered on top of a project that, candidly, is not well-versioned today.
With so many contributors on different release cycles and different priorities, the hardest engineering problem is one that outsiders rarely see: version control. Who decides when a version is cut? How do you patch it without breaking someone else’s cycle? That coordination challenge is the real work behind the scenes.
Transparency as a Security Posture
I understand the concern that open-source firmware makes security teams nervous. But the algorithms at work here are known industry standards, and nothing needs to be hidden. Opening the code means third-party audits and community review can happen in parallel. When zero-day attacks can materialize in minutes, transparency and fast patching cycles beat obscurity.
Tektagon, our open-source Platform Root of Trust solution, operates as a secure orchestration layer. It verifies that firmware is authentic and correctly signed. It manages the boot process rather than trying to control it. AMI is also the only vendor with OCP SAFE compliance across boot, manageability, and security firmware. That gives operators an auditable, defensible foundation that a closed stack cannot match at the same speed.
Growing the Market, Not Just Competing in It
One impact of open source stands out that many underestimate: it grows the total addressable market. OpenBMC opened manageability beyond servers, into CDUs, power shelves, switches, and other infrastructure that never had it before. Lower barriers to entry create more devices that need servicing, and that creates more opportunity for our commercial capabilities on top. I do not see this stopping as AI factories continue to scale. Complexity will only increase, and that complexity will directly drive new hardware innovation, expanding the surface area for manageability and control.
Built With, Not For
Our open-source work is not a gift to the community. It is something we build with the community. Likewise, our Community Edition solutions are not stripped-down versions of our commercial products. They are a genuine baseline for innovation, a foundation that stands on its own. Some users will deploy that code and never pay AMI a dime. That requires investment and risk tolerance on their side, and that is fine.
But for those who hit the limits of community-based code and want production-grade support and lifecycle management, we are already in the conversation. The shift from proprietary to open contributor is not finished. I do not think it ever will be. That is the nature of building in the open.
Finally, open source is not a destination you arrive at. It is a discipline you practice. From our first contribution in 2019, AMI is admittedly still early in that practice relative to some of our peers. But as the graph below shows, we have made a concerted effort to meaningfully increase our contributions to the OpenBMC project in the last 6 months across our total number of contributions, merged changes and the number of qualified contributors.

What we bring to the table is deep platform expertise, a broad view of the firmware landscape, and a genuine willingness to do the work in public. We expect criticism along the way. We also expect to earn trust the only way open source allows: one contribution, one review cycle, one upstream commit at a time.
OpenBMC is a trademark of LF Projects, LLC. MegaRAC OneTree is a trademark of AMI US Holdings, Inc. Ubuntu is a trademark of Canonical, Ltd. Fedora is a registered trademark of Red Hat, Inc., or its subsidiaries in the United States and other countries. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. All other trademarks and registered trademarks are the property of their respective owners.
