On May 19, AMI and Meta co-hosted the first-ever, invite-only OpenBMC Meetup at the Meta Campus in Menlo Park, California. The day brought together engineers, operators, silicon vendors, and ecosystem partners for a series of keynotes and technical sessions focused on the next chapter of the OpenBMC™ community. Here is a look at what surfaced in the conversations and where we go from here.
Setting the Stage: The Fork Problem
Meta Software Engineer Patrick Williams, who leads the OpenBMC team at Meta, opened the day with the question that has shaped the OpenBMC community for the past several years: how does an open project that already powers millions of nodes ship like a real distribution? More than 15 active forks of OpenBMC exist today, most maintained by silicon vendors or hardware partners, with a varying cadence of releases. And while Meta deploys directly from master each week, this pace is not feasible for ecosystem vendors.
Patrick also announced the release of OpenBMC 3.0, the project’s first release in more than a year, built on the release. Comparing the pace of innovation today to the development of digital cameras in the 90s and early 2000s, he framed the moment as an inflection point: after several frenetic years of hardware change, with liquid cooling, rack-level power management, dense back-end networks, and co-developed CPU and GPU platforms all arriving at once, the community finally had a window to converge on shared release practices, security work, and standards.
AMI’s Open-First Commitment
AMI Chief Product Officer Zachary Bobroff picked up Patrick’s thread with the perspective of a firmware vendor five years into an open-source shift. AMI has been a firmware company for 40 years, with 35 of those spent shipping proprietary BIOS and BMC firmware. The company’s decision to contribute Aptio®, MegaRAC®, and Tektagon® into the Open Compute Project marked a significant change in direction, and the years since have been spent learning to build firmware with the community rather than for it.
Zach positioned MegaRAC OneTree Community Edition as AMI’s practical answer to the fork problem: a hardware-agnostic, validated OpenBMC distribution that pulls in work happening across silicon vendors and brings it back to a single, releasable tree. He was candid about the journey, noting that AMI did not get everything right at the start but remains committed to contributing back to the open-source community and welcomes the scrutiny that comes with operating in the open.
Hyperscaler Scale, Hyperscaler Expectations
Microsoft’s Partner Software Engineering Manager Thirupathaiah Annapureddy and Principal Software Engineer Dhananjay Phadke took the floor next to bring in the hyperscaler view. Microsoft deploys millions of nodes, most of them carrying one or more BMCs spread across hundreds of platforms and SKUs, in a fleet that mixes Intel, AMD, NVIDIA, and Microsoft’s own silicon. At that scale, the cost of fragmentation becomes an operational tax.
Their priorities were unambiguous: BMCs need solid error handling and high availability. Telemetry must hold up across the fleet so issues can be isolated and repaired quickly, and security fixes need to be deployed quickly. The session echoed Patrick’s earlier call that the community needs to converge on shared standards to keep scaling.
NVIDIA’s Ed Tanous closed out the morning keynotes with the perspective of a silicon vendor. He noted that a single NVIDIA GB200 rack has about 60 different OpenBMC implementations running and made the case for surfacing development intent months before code lands. His remarks were followed by a panel that paired AMI Director of Engineering Pravinash Jeyapaul with Patrick and Ed for a frank, cross-disciplinary conversation about what it actually takes to operate and maintain large-scale OpenBMC environments in production.
The afternoon went deeper into the technical side of OpenBMC development, with Intel BMC Firmware Architect Nirav Shah and Senior BMC Firmware Developer Jason Bills outlining a five-year vision for BMC functionality. The remaining sessions were led by Nuvoton’s Hila Miranda-Kuzy, Celestica’s Avinash Natarajan, and AMI’s Pravinash Jeyapaul on topics including security and platform root of trust, sideband protocols, and the future of BIOS/BMC integration.
Lattice Semiconductor’s Munir Ahmad, NXP’s Wim Rouwet, and AMI’s Winston Thangapandian closed the technical program with a session on extending OpenBMC beyond compute into power, cooling, and networking management.
What Comes Next
To conclude the program, Patrick and AMI’s Brian Vandecoevering closed with a shared message: that the OpenBMC community needs more vendors developing upstream first, more contributors working in public, and more operators willing to push their silicon partners toward shared standards.
AMI is committed to all three points of this message, and to the open-first mindset that is at the foundation of our product development process: shipping production-grade firmware in the open, with the community, and contributing back to the projects we depend on.
We look forward to hosting and participating in more events like this OpenBMC Meetup in the future, and watching this community grow and deepen its involvement and contributions. To continue the conversations from Menlo Park, we invite you to visit the new AMI developer community site at developer.ami.com/developer-community-page/. Our goal is to expand this over time into a hub for resources, idea sharing and community building that strengthens this movement towards convergence.
OpenBMC is a trademark of LF Projects, LLC. All other trademarks and registered trademarks are the property of their respective owners.
