Register for NexusCon 2025!
Perhaps the most famous story in building automation is the history of the dominance of OEMs and vendor lock-in. Here’s the abridged version:
Before the turn of the century, our buildings started going digital—but not all at once. The industry first transitioned from pneumatic and analog controls to digital serial protocols, such as RS-485, which enabled devices to communicate more data more efficiently. This opened the door for new types of control and automation, and a handful of OEM pioneers—names like Honeywell, Johnson Controls, Siemens, and others—led the charge.
Their systems were cutting-edge at the time, but they came with a catch: they often spoke proprietary languages, like Johnson Controls’ N2 or Siemens’ P1. This proprietary approach enabled seamless integration between components of the same manufacturer and provided associated development tools for technicians… if they worked for the company that owned the system.
Next, Ethernet and IP-based communication began to gain ground. That shift promised broader integration and more data availability across building systems. But even with this leap forward, proprietary walls remained. The physical wiring may have evolved, but the vendor lock-in persisted in software, tools, and licensing.
Now, looking back decades later, the average building owner’s blood pressure rises as they recall this history. We hear stories of the hassles caused by vendor lock-in: building owners are forced to use the only service contractor who can access the system to update the system, completely at the mercy of their schedule, their pricing, and their quality of work.
One former healthcare building owner shared a story about receiving an emergency service call for an operating room. They did not have an annual service contract with the OEM installed in the hospital, so when they called for support, they received lead times of 2-3 weeks from the only provider who could assist them. They ended up signing a year-long service contract solely to get someone on site quickly.
The other downside to this proprietary story is the way that it has crippled innovation. While home automation is a less complex industry, we have seen it skyrocket with IoT devices that plug in and seamlessly connect and communicate with one another, whereas our commercial buildings often feel locked into the past.
Finally, there is the growing concern around workforce availability. We’ve discussed the shrinking building automation workforce, which is only accelerated by proprietary technology. It’s not good enough for a prospective technician to know how to code in a common language like Python. When the systems are closed, they also need to work for a company that has a license for proprietary software. They must get certified in the specific systems the company requires, learn to use the proprietary programming language and engineering tools, and adhere to the company's standards. All of this presents a significant obstacle for people outside the industry to get up to speed and do work.
Despite these challenges, the winds have been shifting. Innovative solutions are emerging that promise to liberate building owners from these closed ecosystems. In particular, one buzzword is on everyone’s lips as a beacon of hope for “freedom from lock-in”: open source.
But what does “open source” really mean in the context of building automation, and can it deliver on its promise of flexibility and owner control?
Nexus Labs was built to cut through the bullshit of buzzwords and explain what really matters to building owners, so today, we’ll demystify open source and explore how it’s changing the way buildings are operated—from reducing vendor lock-in to improving service quality—all in a practical, no-nonsense way.
“Open source” in the IT world usually refers to software whose original source code is freely available for anyone to inspect, use, and modify. In the building automation industry, however, the term often gets mixed up with other ideas of openness.
I, like many, was first introduced to the concept of “open” in the building automation world through BACnet. BACnet is an open protocol that allows devices from different manufacturers to speak a common language. Yet, in many ways, the proliferation of BACnet just further muddied the waters of what is open.
“I think our industry gets really locked up on BACnet as the open answer to everything, but BACnet is not truly open. BACnet was made to be an open building automation protocol, but as soon as you start wrapping things behind ‘the firewall’ of an engineering tool, it's not open anymore.”
—Alex Waibel, President, BuildingLogiX
While BACnet emerged out of ASHRAE as a solution to enable devices to communicate more openly with one another, it also became a loophole that allowed larger OEMs to meet a specification requiring them to be “open” while still locking down major aspects of their systems, forcing the use of specialty software and service contracts to make real changes.
Open source goes a step further. It’s not just about devices communicating; it’s about giving you, or any third party, the ability to alter how the software itself works. In buildings, this translates to solutions built on openly available software components (often maintained by a community) rather than entirely proprietary code.
Importantly, open source doesn’t mean free of cost. When Andrew Rodgers of ACE IoT and James Dice broke down open source on the podcast years ago, Andrew gave us an analogy of “free as in speech versus free as in beer.” While “free beer” means you’re getting something at no cost, “free speech” is about having the freedom to use, modify, and share something however you want—and that’s the kind of “free” open source is really about.
Open source is “free” in the freedom-to-tinker sense—you’re allowed to change the software if you want—but it doesn’t guarantee freedom from cost. You might still pay licensing fees, or more commonly, pay integrators and developers for their expertise. Once you’ve paid for a system, do you have the freedom to maintain and adapt it, or are you handcuffed by the vendor? Open source aims to remove the handcuffs.
That said, open source in building automation can be a slippery concept. It’s not an all-or-nothing binary; it exists on a spectrum. Any company can take something built as open source and make it closed again by adding their own proprietary wrapper, and sometimes that can be quite useful.
The core idea is to give owners more freedom of choice. That means the ability to pick or change service providers at will, integrate new technologies on their own timeline, and extend or modify the system’s functionality without begging the original vendor for permission.
Rodgers described it in practical terms: “If you buy a system that does X today, but next year your tenants need it to do Y and Z, an open approach determines whether you can make that change yourself (or with any partner you choose) or whether you’re forced to go back to the initial vendor and their authorized dealers for every little change.” Open source aims to avoid that scenario by ensuring that no single entity has an exclusive lock on the knowledge or tools to service the system.
Another benefit of open-source approaches is the power of community and collaboration. Thousands of developers around the world are effectively co-developing the building blocks of modern BAS. They’re finding and fixing bugs, adding compatibility for new equipment, and enhancing features, often at a pace no single vendor could match.
And since those improvements are open to everyone, your LLM of choice has plenty of information to support you while you develop. Try asking a general AI how to program a proprietary BAS platform, and you’ll likely get hallucinated code.
Yet in the built environment, it’s rarely as black and white as the term open source makes it out to be. Building systems are mission-critical, and most owners rightfully demand stability and accountability. Many open-source-based solutions are offered by companies that provide professional support, training, and warranties, just as traditional vendors do. It’s also perfectly valid to choose a solution that isn’t 100% open source if that yields a safer or more reliable operation. There are still parts of the stack (especially at the equipment level) that manufacturers keep closed for safety or business reasons.
Thus, building owners will find open-source solutions in varying flavors. You might have open-source software at the supervisory or analytics layer, but still use proprietary field controllers, and that can be okay. The key is to maximize your freedom at the layers where it makes sense, and minimize vendor lock at the system level. In the next sections, we’ll explore how this balance is playing out with today’s technology.
No discussion of open systems in building automation can avoid Niagara. Originally developed by Tridium (now part of Honeywell), the Niagara Framework has been around for decades and is deployed in hundreds of thousands of buildings.
Niagara is not open source—it’s a commercial, licensed product. Niagara licenses are typically purchased through Tridium-authorized distributors or OEM partners and are tied to specific hardware. Integrators and contractors must be Niagara-certified to install and program the system using Tridium’s engineering tool, called Workbench. Despite this, Niagara’s emergence was a game-changer for openness in a broader sense.
It provided a common platform that could integrate different brands and systems under one roof. With Niagara, a BACnet HVAC system, a Modbus power meter, and a LonWorks lighting controller could all be brought into a single unified interface.
Just as importantly, Niagara created a multitude of service providers who could work on those systems. Instead of being tied to one service provider for everything, an owner could hire any certified Niagara integrator to service and expand their system. For owners accustomed to being held hostage with no options at all, that was a revelation.
Niagara, along with others, brought in a wave of new opportunity with open data access. When data from various subsystems can be integrated into a common platform, real insights and analytics become available, which brings in a new class of building applications, such as fault detection and diagnostics (FDD).
As Alex Waibel, president of BuildingLogiX noted, “we've utilized Niagara as a gateway for data, because even if you found an open building automation system, it doesn't mean that you have an open or totally integrated building system, because you're going to have lighting control that's going to talk DALI, you're going to have metering infrastructure that communicates Modbus, you're going to have access control and video, which can be extremely proprietary.” The introduction of open systems has allowed FDD providers like BuildingLogiX to gather information from previously siloed sources that can tell a story of what is really happening within a building.
Again, to be clear, Niagara itself is not open source. You, as an end user, cannot see or modify Niagara’s source code—that remains Honeywell’s intellectual property. In practical terms, this means if you don’t like how Niagara does something, you can’t tweak the platform itself; you have to live with its design decisions.
Interestingly, many in the industry accept this trade-off. You gain a stable, supported platform at the cost of not being able to alter it under the hood.
Altura is a service provider that offers master system integration (MSI) services and frequently utilizes Niagara as a tool for system integration. In many cases, they see Niagara’s closed-core model as a feature, not a bug. Jared Arwine, a senior associate at Altura, pointed out that when you buy a Niagara license, “you do buy a sense of security” along with it. You’re paying not just for the software as it exists today, but for the ongoing stream of updates, bug fixes, and security patches that Tridium/Honeywell provides over time.
In a world where cybersecurity threats evolve constantly, having a vendor actively maintaining the system can be reassuring. The vendor has skin in the game—they must keep the platform secure and up-to-date for all their customers, or risk losing them. In contrast, a pure open-source project might rely on the community to address vulnerabilities; that can be very effective (many eyes on the code), but it requires a critical mass of contributors.
There’s also the reality that building automation straddles the physical world, where safety and reliability are paramount. Running a building isn’t the same as running a website—you can’t afford to “move fast and break things” when human comfort or safety is on the line. Many building owners and service providers want a professional vendor standing behind the system, proprietary or not. Niagara struck a balance: it opened up integration and service choices without fully open-sourcing the platform. That makes it a sort of hybrid—not open source, but more open than the black-box systems that preceded it.
Still, Niagara is no longer the only game in town, and it has its limitations. Owners and forward-looking integrators have started exploring truly open-source software in building automation. In the next section, we’ll look at some of the new players and tools pushing the envelope, built from the ground up with open-source tech.
Strato Automation is a relatively newer controls company (established in 2011) that prides itself on leveraging open-source software wherever possible. Under the hood of Strato’s building automation system is Node-RED, a popular open-source function block-based programming and IoT integration platform built on JavaScript.
(Nexus Pro Members should check out our SME workshop deep dive on Node-RED presented by James Coleman)
Node-RED is widely used by hobbyists and enterprises alike in the IoT space. By building on Node-RED, Strato gains a rich ecosystem of pre-built integrations and a global community of contributors. This means that when Strato needs to add a capability, there is a good chance that someone has already created a Node-RED module for it (or at least something to start from).
While Node-RED originated in the home automation and hobbyist world, Strato has built a commercial-grade interface on top of it that makes it simple and scalable for the small to mid-sized 87% of commercial buildings that are often overlooked. These buildings benefit from Node-RED’s low-cost integration system while gaining the professional support and structure of Strato’s OCN+ platform and control products.
.png)
Being backed by an open-source project means Strato’s solution can evolve quickly and isn’t confined to what a single company’s R&D team can support. If a building owner or third-party developer dreams up a new use case—say, integrating a unique piece of lab equipment with the HVAC controls—they can potentially develop a Node-RED plugin to do it, without needing Strato’s permission. This is a fundamentally different model from traditional BAS, where you’d request a feature and hope it appears in the next official release (if ever).
What about support and usability, though? Strato isn’t just dumping raw Node-RED on users and saying “have at it.” They provide a polished interface (they call it OCN+) and professional support on top of the open engine. It’s a blended model: proprietary where it adds value (UI, support, perhaps some custom tools), open-source at the core.
From a building owner’s perspective, a platform like Strato’s offers an intriguing promise. You get a product that behaves much like a traditional BAS (it controls equipment, has graphics and alarms, etc.), but under the hood, it’s built on technology that thousands of people outside the building industry know how to use. The interface is user-friendly for day-to-day operations, but if you need to innovate or troubleshoot at a deeper level, you have the full power of a global open-source community at your fingertips.
Another exemplar of open source in action is ACE IoT Solutions. ACE IoT specializes in helping building owners liberate and use their data, and their stack is built on an open-source platform called Volttron. Volttron is a Python-based platform that was originally developed by the U.S. Department of Energy for distributed energy and building controls. It’s freely available and has a community of national labs, universities, and companies contributing to it. By adopting Volttron, ACE IoT stands on the shoulders of that community rather than starting from scratch.
Andrew Rodgers of ACE IoT emphasized that using open tools like Volttron means service providers can tap into the best solutions the world has to offer for any given problem, “They don’t have to make anything up… they can use what the best of the world has already thought of”.
This approach drastically expands what’s possible in building automation. Imagine trying to do complex analytics or adaptive control on a proprietary BAS—you might be limited by the built-in scripting engine or whatever modules the vendor offers for purchase. With an open-source platform like Volttron, if you need a cutting-edge machine learning algorithm, you can incorporate it directly via open libraries.
Continue reading to learn how open-source is eroding traditional vendor dominance, why it is slowly becoming inevitable, and how it is modernizing the smart building workforce.
If the first part of this article made the case that open source is here and now, this section is about where it’s taking us. The consensus among forward-thinking experts is that, even though we’re moving slowly, we’re on the cusp of significant industry shifts. Open-source philosophies are poised to reshape who the key players are and how building automation technology is delivered and maintained.
We may see an erosion of the big OEMs’ dominance as more nimble, medium-sized vendors gain ground with open solutions. In their place, companies that embrace openness could flourish. Waibel points to firms like Distech Controls, KMC Controls, and others that produce reliable hardware with open interfaces, often at lower cost.
These companies don’t have the decades-old legacy baggage and are more free to incorporate open-source software or open standards from the ground up. In Waibel’s view, mid-tier manufacturers that play nicely with open ecosystems are poised to capture more market share as owners realize they have choices.
Traditionally, if you invested in a proprietary BAS, you were effectively married to that vendor for better or worse. In the open-source future, you can switch partners if things aren’t working out. We already saw how Niagara enabled a version of this by allowing multiple service contractors to bid on the same Niagara job. True open source takes it further: multiple vendors can actually collaborate on improving the same core software. In an open ecosystem, competition shifts to who provides the best service, not who owns the secret sauce.
Once you go open source, the competition between the different platforms dwindles, because they can all benefit from the same pool of information, and it just becomes a personal preference choice. If everyone’s using a common open-source analytics library, vendors differentiate themselves by price, support, and quality of implementation, not by whose proprietary scheduling algorithm locks others out. For owners, that’s a very healthy dynamic: it tends to drive costs down and improve service quality.
In tech, once an open approach proves its merit, it often becomes the standard. Rodgers pointed out that a decade ago, people debated if open-source Linux or Microsoft’s Windows would dominate controller firmware—“now it’s not even a conversation. Everybody’s gateway runs Linux… no one is running a Windows-based controller anywhere”. The inevitability of open tech has a way of sneaking up. We may well see the same story with higher-level BAS software and applications. Once owners and service providers experience the cost and agility benefits, it’s hard to imagine the pendulum swinging fully back to proprietary.
Historically, a building operator needed to know a proprietary programming environment or a niche scripting language to service very specific components within a building. Those skills don’t translate well outside that vendor’s ecosystem. It’s a bit of a dead-end career path to be an exclusively certified programmer in a niche proprietary platform. In contrast, open-source tools in buildings tend to use ubiquitous languages like Python or JavaScript, standard databases, and common data exchange formats.
Hiring a software-savvy technician or engineer becomes easier because the talent pool is larger. And conversely, building automation becomes a more attractive field for new talent if it uses modern tech stack tools. An experienced programmer who knows Python might balk at learning a closed, idiosyncratic BAS programming tool, but they can ramp up quickly on an open-source building platform that also uses Python.
From the owner’s viewpoint, this shift could help alleviate the perennial workforce shortage in controls. Open source is part of a cultural shift that brings Silicon Valley-esque development practices into building operations.
Perhaps the most important trend is a change in mindset among building owners. More owners are demanding autonomy over their systems. Instead of deferring everything to a vendor or an integrator, they want the keys to the backend. This is especially true in certain sectors: higher education and healthcare institutions have been pioneers, often insisting on open systems because they have in-house facilities teams capable of managing them.
In contrast, many commercial real estate owners delegate BAS decisions to third-party managers or just stick with whatever the mechanical contractor is comfortable with—which often means defaulting to the old proprietary status quo. Our industry’s very own representation of the term “nobody gets fired for buying IBM”.
Owner autonomy can sound abstract, but it simply means choice: the choice to switch service providers without replacing hardware, the choice to expand your system without paying a king’s ransom in integration fees, the choice to stay on the cutting edge if you want to (or to stick with tried-and-true, if you prefer stability).
For building owners and operators, the rise of open-source in building automation is a promising development that addresses some long-standing frustrations. It’s important to reiterate that open source doesn’t mean “free” in terms of dollars—you will still invest in software and services, and you’ll still have vendors and partners. The difference is in leverage and longevity.
With an open-source or open-architecture solution, you hold more of the cards. You’re not wedded to one vendor’s ecosystem, you can swap out parts of your system as needs change, and your building’s core “smarts” can potentially live on well past the typical 10- or 15-year rip-and-replace cycle. The added competition and collaboration will drive service quality up and costs down. In essence, open source tilts the balance of power a bit more toward you, the owner.
We’re still at the early stages of this open-source journey in smart buildings. There will be bumps along the way, and not every “open” claim will pan out. But the trajectory is set. Just as Linux quietly took over the backbone of building controllers, open-source tools are steadily working their way up the stack. In a few years, we’ll likely look back at proprietary-only BAS the way we now look at dial-up internet or flip phones—it served a purpose in its day, but technology (and expectations) have moved on.
If the first part of this article made the case that open source is here and now, this section is about where it’s taking us. The consensus among forward-thinking experts is that, even though we’re moving slowly, we’re on the cusp of significant industry shifts. Open-source philosophies are poised to reshape who the key players are and how building automation technology is delivered and maintained.
We may see an erosion of the big OEMs’ dominance as more nimble, medium-sized vendors gain ground with open solutions. In their place, companies that embrace openness could flourish. Waibel points to firms like Distech Controls, KMC Controls, and others that produce reliable hardware with open interfaces, often at lower cost.
These companies don’t have the decades-old legacy baggage and are more free to incorporate open-source software or open standards from the ground up. In Waibel’s view, mid-tier manufacturers that play nicely with open ecosystems are poised to capture more market share as owners realize they have choices.
Traditionally, if you invested in a proprietary BAS, you were effectively married to that vendor for better or worse. In the open-source future, you can switch partners if things aren’t working out. We already saw how Niagara enabled a version of this by allowing multiple service contractors to bid on the same Niagara job. True open source takes it further: multiple vendors can actually collaborate on improving the same core software. In an open ecosystem, competition shifts to who provides the best service, not who owns the secret sauce.
Once you go open source, the competition between the different platforms dwindles, because they can all benefit from the same pool of information, and it just becomes a personal preference choice. If everyone’s using a common open-source analytics library, vendors differentiate themselves by price, support, and quality of implementation, not by whose proprietary scheduling algorithm locks others out. For owners, that’s a very healthy dynamic: it tends to drive costs down and improve service quality.
In tech, once an open approach proves its merit, it often becomes the standard. Rodgers pointed out that a decade ago, people debated if open-source Linux or Microsoft’s Windows would dominate controller firmware—“now it’s not even a conversation. Everybody’s gateway runs Linux… no one is running a Windows-based controller anywhere”. The inevitability of open tech has a way of sneaking up. We may well see the same story with higher-level BAS software and applications. Once owners and service providers experience the cost and agility benefits, it’s hard to imagine the pendulum swinging fully back to proprietary.
Historically, a building operator needed to know a proprietary programming environment or a niche scripting language to service very specific components within a building. Those skills don’t translate well outside that vendor’s ecosystem. It’s a bit of a dead-end career path to be an exclusively certified programmer in a niche proprietary platform. In contrast, open-source tools in buildings tend to use ubiquitous languages like Python or JavaScript, standard databases, and common data exchange formats.
Hiring a software-savvy technician or engineer becomes easier because the talent pool is larger. And conversely, building automation becomes a more attractive field for new talent if it uses modern tech stack tools. An experienced programmer who knows Python might balk at learning a closed, idiosyncratic BAS programming tool, but they can ramp up quickly on an open-source building platform that also uses Python.
From the owner’s viewpoint, this shift could help alleviate the perennial workforce shortage in controls. Open source is part of a cultural shift that brings Silicon Valley-esque development practices into building operations.
Perhaps the most important trend is a change in mindset among building owners. More owners are demanding autonomy over their systems. Instead of deferring everything to a vendor or an integrator, they want the keys to the backend. This is especially true in certain sectors: higher education and healthcare institutions have been pioneers, often insisting on open systems because they have in-house facilities teams capable of managing them.
In contrast, many commercial real estate owners delegate BAS decisions to third-party managers or just stick with whatever the mechanical contractor is comfortable with—which often means defaulting to the old proprietary status quo. Our industry’s very own representation of the term “nobody gets fired for buying IBM”.
Owner autonomy can sound abstract, but it simply means choice: the choice to switch service providers without replacing hardware, the choice to expand your system without paying a king’s ransom in integration fees, the choice to stay on the cutting edge if you want to (or to stick with tried-and-true, if you prefer stability).
For building owners and operators, the rise of open-source in building automation is a promising development that addresses some long-standing frustrations. It’s important to reiterate that open source doesn’t mean “free” in terms of dollars—you will still invest in software and services, and you’ll still have vendors and partners. The difference is in leverage and longevity.
With an open-source or open-architecture solution, you hold more of the cards. You’re not wedded to one vendor’s ecosystem, you can swap out parts of your system as needs change, and your building’s core “smarts” can potentially live on well past the typical 10- or 15-year rip-and-replace cycle. The added competition and collaboration will drive service quality up and costs down. In essence, open source tilts the balance of power a bit more toward you, the owner.
We’re still at the early stages of this open-source journey in smart buildings. There will be bumps along the way, and not every “open” claim will pan out. But the trajectory is set. Just as Linux quietly took over the backbone of building controllers, open-source tools are steadily working their way up the stack. In a few years, we’ll likely look back at proprietary-only BAS the way we now look at dial-up internet or flip phones—it served a purpose in its day, but technology (and expectations) have moved on.
If the first part of this article made the case that open source is here and now, this section is about where it’s taking us. The consensus among forward-thinking experts is that, even though we’re moving slowly, we’re on the cusp of significant industry shifts. Open-source philosophies are poised to reshape who the key players are and how building automation technology is delivered and maintained.
We may see an erosion of the big OEMs’ dominance as more nimble, medium-sized vendors gain ground with open solutions. In their place, companies that embrace openness could flourish. Waibel points to firms like Distech Controls, KMC Controls, and others that produce reliable hardware with open interfaces, often at lower cost.
These companies don’t have the decades-old legacy baggage and are more free to incorporate open-source software or open standards from the ground up. In Waibel’s view, mid-tier manufacturers that play nicely with open ecosystems are poised to capture more market share as owners realize they have choices.
Traditionally, if you invested in a proprietary BAS, you were effectively married to that vendor for better or worse. In the open-source future, you can switch partners if things aren’t working out. We already saw how Niagara enabled a version of this by allowing multiple service contractors to bid on the same Niagara job. True open source takes it further: multiple vendors can actually collaborate on improving the same core software. In an open ecosystem, competition shifts to who provides the best service, not who owns the secret sauce.
Once you go open source, the competition between the different platforms dwindles, because they can all benefit from the same pool of information, and it just becomes a personal preference choice. If everyone’s using a common open-source analytics library, vendors differentiate themselves by price, support, and quality of implementation, not by whose proprietary scheduling algorithm locks others out. For owners, that’s a very healthy dynamic: it tends to drive costs down and improve service quality.
In tech, once an open approach proves its merit, it often becomes the standard. Rodgers pointed out that a decade ago, people debated if open-source Linux or Microsoft’s Windows would dominate controller firmware—“now it’s not even a conversation. Everybody’s gateway runs Linux… no one is running a Windows-based controller anywhere”. The inevitability of open tech has a way of sneaking up. We may well see the same story with higher-level BAS software and applications. Once owners and service providers experience the cost and agility benefits, it’s hard to imagine the pendulum swinging fully back to proprietary.
Historically, a building operator needed to know a proprietary programming environment or a niche scripting language to service very specific components within a building. Those skills don’t translate well outside that vendor’s ecosystem. It’s a bit of a dead-end career path to be an exclusively certified programmer in a niche proprietary platform. In contrast, open-source tools in buildings tend to use ubiquitous languages like Python or JavaScript, standard databases, and common data exchange formats.
Hiring a software-savvy technician or engineer becomes easier because the talent pool is larger. And conversely, building automation becomes a more attractive field for new talent if it uses modern tech stack tools. An experienced programmer who knows Python might balk at learning a closed, idiosyncratic BAS programming tool, but they can ramp up quickly on an open-source building platform that also uses Python.
From the owner’s viewpoint, this shift could help alleviate the perennial workforce shortage in controls. Open source is part of a cultural shift that brings Silicon Valley-esque development practices into building operations.
Perhaps the most important trend is a change in mindset among building owners. More owners are demanding autonomy over their systems. Instead of deferring everything to a vendor or an integrator, they want the keys to the backend. This is especially true in certain sectors: higher education and healthcare institutions have been pioneers, often insisting on open systems because they have in-house facilities teams capable of managing them.
In contrast, many commercial real estate owners delegate BAS decisions to third-party managers or just stick with whatever the mechanical contractor is comfortable with—which often means defaulting to the old proprietary status quo. Our industry’s very own representation of the term “nobody gets fired for buying IBM”.
Owner autonomy can sound abstract, but it simply means choice: the choice to switch service providers without replacing hardware, the choice to expand your system without paying a king’s ransom in integration fees, the choice to stay on the cutting edge if you want to (or to stick with tried-and-true, if you prefer stability).
For building owners and operators, the rise of open-source in building automation is a promising development that addresses some long-standing frustrations. It’s important to reiterate that open source doesn’t mean “free” in terms of dollars—you will still invest in software and services, and you’ll still have vendors and partners. The difference is in leverage and longevity.
With an open-source or open-architecture solution, you hold more of the cards. You’re not wedded to one vendor’s ecosystem, you can swap out parts of your system as needs change, and your building’s core “smarts” can potentially live on well past the typical 10- or 15-year rip-and-replace cycle. The added competition and collaboration will drive service quality up and costs down. In essence, open source tilts the balance of power a bit more toward you, the owner.
We’re still at the early stages of this open-source journey in smart buildings. There will be bumps along the way, and not every “open” claim will pan out. But the trajectory is set. Just as Linux quietly took over the backbone of building controllers, open-source tools are steadily working their way up the stack. In a few years, we’ll likely look back at proprietary-only BAS the way we now look at dial-up internet or flip phones—it served a purpose in its day, but technology (and expectations) have moved on.
Perhaps the most famous story in building automation is the history of the dominance of OEMs and vendor lock-in. Here’s the abridged version:
Before the turn of the century, our buildings started going digital—but not all at once. The industry first transitioned from pneumatic and analog controls to digital serial protocols, such as RS-485, which enabled devices to communicate more data more efficiently. This opened the door for new types of control and automation, and a handful of OEM pioneers—names like Honeywell, Johnson Controls, Siemens, and others—led the charge.
Their systems were cutting-edge at the time, but they came with a catch: they often spoke proprietary languages, like Johnson Controls’ N2 or Siemens’ P1. This proprietary approach enabled seamless integration between components of the same manufacturer and provided associated development tools for technicians… if they worked for the company that owned the system.
Next, Ethernet and IP-based communication began to gain ground. That shift promised broader integration and more data availability across building systems. But even with this leap forward, proprietary walls remained. The physical wiring may have evolved, but the vendor lock-in persisted in software, tools, and licensing.
Now, looking back decades later, the average building owner’s blood pressure rises as they recall this history. We hear stories of the hassles caused by vendor lock-in: building owners are forced to use the only service contractor who can access the system to update the system, completely at the mercy of their schedule, their pricing, and their quality of work.
One former healthcare building owner shared a story about receiving an emergency service call for an operating room. They did not have an annual service contract with the OEM installed in the hospital, so when they called for support, they received lead times of 2-3 weeks from the only provider who could assist them. They ended up signing a year-long service contract solely to get someone on site quickly.
The other downside to this proprietary story is the way that it has crippled innovation. While home automation is a less complex industry, we have seen it skyrocket with IoT devices that plug in and seamlessly connect and communicate with one another, whereas our commercial buildings often feel locked into the past.
Finally, there is the growing concern around workforce availability. We’ve discussed the shrinking building automation workforce, which is only accelerated by proprietary technology. It’s not good enough for a prospective technician to know how to code in a common language like Python. When the systems are closed, they also need to work for a company that has a license for proprietary software. They must get certified in the specific systems the company requires, learn to use the proprietary programming language and engineering tools, and adhere to the company's standards. All of this presents a significant obstacle for people outside the industry to get up to speed and do work.
Despite these challenges, the winds have been shifting. Innovative solutions are emerging that promise to liberate building owners from these closed ecosystems. In particular, one buzzword is on everyone’s lips as a beacon of hope for “freedom from lock-in”: open source.
But what does “open source” really mean in the context of building automation, and can it deliver on its promise of flexibility and owner control?
Nexus Labs was built to cut through the bullshit of buzzwords and explain what really matters to building owners, so today, we’ll demystify open source and explore how it’s changing the way buildings are operated—from reducing vendor lock-in to improving service quality—all in a practical, no-nonsense way.
“Open source” in the IT world usually refers to software whose original source code is freely available for anyone to inspect, use, and modify. In the building automation industry, however, the term often gets mixed up with other ideas of openness.
I, like many, was first introduced to the concept of “open” in the building automation world through BACnet. BACnet is an open protocol that allows devices from different manufacturers to speak a common language. Yet, in many ways, the proliferation of BACnet just further muddied the waters of what is open.
“I think our industry gets really locked up on BACnet as the open answer to everything, but BACnet is not truly open. BACnet was made to be an open building automation protocol, but as soon as you start wrapping things behind ‘the firewall’ of an engineering tool, it's not open anymore.”
—Alex Waibel, President, BuildingLogiX
While BACnet emerged out of ASHRAE as a solution to enable devices to communicate more openly with one another, it also became a loophole that allowed larger OEMs to meet a specification requiring them to be “open” while still locking down major aspects of their systems, forcing the use of specialty software and service contracts to make real changes.
Open source goes a step further. It’s not just about devices communicating; it’s about giving you, or any third party, the ability to alter how the software itself works. In buildings, this translates to solutions built on openly available software components (often maintained by a community) rather than entirely proprietary code.
Importantly, open source doesn’t mean free of cost. When Andrew Rodgers of ACE IoT and James Dice broke down open source on the podcast years ago, Andrew gave us an analogy of “free as in speech versus free as in beer.” While “free beer” means you’re getting something at no cost, “free speech” is about having the freedom to use, modify, and share something however you want—and that’s the kind of “free” open source is really about.
Open source is “free” in the freedom-to-tinker sense—you’re allowed to change the software if you want—but it doesn’t guarantee freedom from cost. You might still pay licensing fees, or more commonly, pay integrators and developers for their expertise. Once you’ve paid for a system, do you have the freedom to maintain and adapt it, or are you handcuffed by the vendor? Open source aims to remove the handcuffs.
That said, open source in building automation can be a slippery concept. It’s not an all-or-nothing binary; it exists on a spectrum. Any company can take something built as open source and make it closed again by adding their own proprietary wrapper, and sometimes that can be quite useful.
The core idea is to give owners more freedom of choice. That means the ability to pick or change service providers at will, integrate new technologies on their own timeline, and extend or modify the system’s functionality without begging the original vendor for permission.
Rodgers described it in practical terms: “If you buy a system that does X today, but next year your tenants need it to do Y and Z, an open approach determines whether you can make that change yourself (or with any partner you choose) or whether you’re forced to go back to the initial vendor and their authorized dealers for every little change.” Open source aims to avoid that scenario by ensuring that no single entity has an exclusive lock on the knowledge or tools to service the system.
Another benefit of open-source approaches is the power of community and collaboration. Thousands of developers around the world are effectively co-developing the building blocks of modern BAS. They’re finding and fixing bugs, adding compatibility for new equipment, and enhancing features, often at a pace no single vendor could match.
And since those improvements are open to everyone, your LLM of choice has plenty of information to support you while you develop. Try asking a general AI how to program a proprietary BAS platform, and you’ll likely get hallucinated code.
Yet in the built environment, it’s rarely as black and white as the term open source makes it out to be. Building systems are mission-critical, and most owners rightfully demand stability and accountability. Many open-source-based solutions are offered by companies that provide professional support, training, and warranties, just as traditional vendors do. It’s also perfectly valid to choose a solution that isn’t 100% open source if that yields a safer or more reliable operation. There are still parts of the stack (especially at the equipment level) that manufacturers keep closed for safety or business reasons.
Thus, building owners will find open-source solutions in varying flavors. You might have open-source software at the supervisory or analytics layer, but still use proprietary field controllers, and that can be okay. The key is to maximize your freedom at the layers where it makes sense, and minimize vendor lock at the system level. In the next sections, we’ll explore how this balance is playing out with today’s technology.
No discussion of open systems in building automation can avoid Niagara. Originally developed by Tridium (now part of Honeywell), the Niagara Framework has been around for decades and is deployed in hundreds of thousands of buildings.
Niagara is not open source—it’s a commercial, licensed product. Niagara licenses are typically purchased through Tridium-authorized distributors or OEM partners and are tied to specific hardware. Integrators and contractors must be Niagara-certified to install and program the system using Tridium’s engineering tool, called Workbench. Despite this, Niagara’s emergence was a game-changer for openness in a broader sense.
It provided a common platform that could integrate different brands and systems under one roof. With Niagara, a BACnet HVAC system, a Modbus power meter, and a LonWorks lighting controller could all be brought into a single unified interface.
Just as importantly, Niagara created a multitude of service providers who could work on those systems. Instead of being tied to one service provider for everything, an owner could hire any certified Niagara integrator to service and expand their system. For owners accustomed to being held hostage with no options at all, that was a revelation.
Niagara, along with others, brought in a wave of new opportunity with open data access. When data from various subsystems can be integrated into a common platform, real insights and analytics become available, which brings in a new class of building applications, such as fault detection and diagnostics (FDD).
As Alex Waibel, president of BuildingLogiX noted, “we've utilized Niagara as a gateway for data, because even if you found an open building automation system, it doesn't mean that you have an open or totally integrated building system, because you're going to have lighting control that's going to talk DALI, you're going to have metering infrastructure that communicates Modbus, you're going to have access control and video, which can be extremely proprietary.” The introduction of open systems has allowed FDD providers like BuildingLogiX to gather information from previously siloed sources that can tell a story of what is really happening within a building.
Again, to be clear, Niagara itself is not open source. You, as an end user, cannot see or modify Niagara’s source code—that remains Honeywell’s intellectual property. In practical terms, this means if you don’t like how Niagara does something, you can’t tweak the platform itself; you have to live with its design decisions.
Interestingly, many in the industry accept this trade-off. You gain a stable, supported platform at the cost of not being able to alter it under the hood.
Altura is a service provider that offers master system integration (MSI) services and frequently utilizes Niagara as a tool for system integration. In many cases, they see Niagara’s closed-core model as a feature, not a bug. Jared Arwine, a senior associate at Altura, pointed out that when you buy a Niagara license, “you do buy a sense of security” along with it. You’re paying not just for the software as it exists today, but for the ongoing stream of updates, bug fixes, and security patches that Tridium/Honeywell provides over time.
In a world where cybersecurity threats evolve constantly, having a vendor actively maintaining the system can be reassuring. The vendor has skin in the game—they must keep the platform secure and up-to-date for all their customers, or risk losing them. In contrast, a pure open-source project might rely on the community to address vulnerabilities; that can be very effective (many eyes on the code), but it requires a critical mass of contributors.
There’s also the reality that building automation straddles the physical world, where safety and reliability are paramount. Running a building isn’t the same as running a website—you can’t afford to “move fast and break things” when human comfort or safety is on the line. Many building owners and service providers want a professional vendor standing behind the system, proprietary or not. Niagara struck a balance: it opened up integration and service choices without fully open-sourcing the platform. That makes it a sort of hybrid—not open source, but more open than the black-box systems that preceded it.
Still, Niagara is no longer the only game in town, and it has its limitations. Owners and forward-looking integrators have started exploring truly open-source software in building automation. In the next section, we’ll look at some of the new players and tools pushing the envelope, built from the ground up with open-source tech.
Strato Automation is a relatively newer controls company (established in 2011) that prides itself on leveraging open-source software wherever possible. Under the hood of Strato’s building automation system is Node-RED, a popular open-source function block-based programming and IoT integration platform built on JavaScript.
(Nexus Pro Members should check out our SME workshop deep dive on Node-RED presented by James Coleman)
Node-RED is widely used by hobbyists and enterprises alike in the IoT space. By building on Node-RED, Strato gains a rich ecosystem of pre-built integrations and a global community of contributors. This means that when Strato needs to add a capability, there is a good chance that someone has already created a Node-RED module for it (or at least something to start from).
While Node-RED originated in the home automation and hobbyist world, Strato has built a commercial-grade interface on top of it that makes it simple and scalable for the small to mid-sized 87% of commercial buildings that are often overlooked. These buildings benefit from Node-RED’s low-cost integration system while gaining the professional support and structure of Strato’s OCN+ platform and control products.
Being backed by an open-source project means Strato’s solution can evolve quickly and isn’t confined to what a single company’s R&D team can support. If a building owner or third-party developer dreams up a new use case—say, integrating a unique piece of lab equipment with the HVAC controls—they can potentially develop a Node-RED plugin to do it, without needing Strato’s permission. This is a fundamentally different model from traditional BAS, where you’d request a feature and hope it appears in the next official release (if ever).
What about support and usability, though? Strato isn’t just dumping raw Node-RED on users and saying “have at it.” They provide a polished interface (they call it OCN+) and professional support on top of the open engine. It’s a blended model: proprietary where it adds value (UI, support, perhaps some custom tools), open-source at the core.
From a building owner’s perspective, a platform like Strato’s offers an intriguing promise. You get a product that behaves much like a traditional BAS (it controls equipment, has graphics and alarms, etc.), but under the hood, it’s built on technology that thousands of people outside the building industry know how to use. The interface is user-friendly for day-to-day operations, but if you need to innovate or troubleshoot at a deeper level, you have the full power of a global open-source community at your fingertips.
Another exemplar of open source in action is ACE IoT Solutions. ACE IoT specializes in helping building owners liberate and use their data, and their stack is built on an open-source platform called Volttron. Volttron is a Python-based platform that was originally developed by the U.S. Department of Energy for distributed energy and building controls. It’s freely available and has a community of national labs, universities, and companies contributing to it. By adopting Volttron, ACE IoT stands on the shoulders of that community rather than starting from scratch.
Andrew Rodgers of ACE IoT emphasized that using open tools like Volttron means service providers can tap into the best solutions the world has to offer for any given problem, “They don’t have to make anything up… they can use what the best of the world has already thought of”.
This approach drastically expands what’s possible in building automation. Imagine trying to do complex analytics or adaptive control on a proprietary BAS—you might be limited by the built-in scripting engine or whatever modules the vendor offers for purchase. With an open-source platform like Volttron, if you need a cutting-edge machine learning algorithm, you can incorporate it directly via open libraries.
Continue reading to learn how open-source is eroding traditional vendor dominance, why it is slowly becoming inevitable, and how it is modernizing the smart building workforce.
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.
This is a great piece!
I agree.