When a third-party module's vendor no longer exists

The first is that the Niagara Marketplace storefront no longer serves pages. Every path still tried on that domain — the seller list, a seller profile, a hosted product page — answers with a permanent redirect to one generic landing page on Tridium's own site. Not a 404, which would at least be honest: a redirect, so a link that pointed at a specific product now lands somewhere with no product on it. Those links are cited in documents that are still current, including seven rows of Tridium's own driver list whose only pointer to the software is a Marketplace URL.

The second is that vendors wind down, which is a normal business event rather than a scandal. The one worth noticing is the largest single third-party developer in that list, with around two dozen driver rows against its name. Its website is now a single page: consultancy only from January 2026, no further sales, and the domain itself advertised for sale. Nothing about that is wrong of them. Downstream it is arithmetic — two dozen legacy-protocol drivers, most of them the obvious commercial option for the protocol they speak, now have no vendor behind them and in due course no website either.

With the storefront gone, the surviving public catalogue of third-party Niagara drivers is a PDF: Tridium's Niagara Compatible Drivers & Applications, document reference 2025-0020, last updated July 2025. Each row gives the driver, its developer, a contact URL, the connection type, controller or Supervisor, and the minimum Niagara version. Its opening paragraph says Tridium has not tested all listed drivers, does not certify conformance, and that the list may not be comprehensive — all three worth taking at face value.

It is also thinner than it looks. Pull every domain printed in its For More Information column: 24 distinct ones, three of them Tridium's own. Of the 21 left, this is what they answer today.

So about one pointer in seven does not reach a page, on top of the seven rows aimed at the Marketplace. The document is the only index there is, but it cannot be your inventory: it tells you who wrote a driver, not what is in your station, and increasingly not how to reach them.

Four places hold the answer, and they do not hold the same answer.

The two numbers are rarely close, and conflating them turns a short list of real problems into a long list of imaginary ones. A station's config.bog is itself a zip containing a file.xml, and that XML declares a short alias for every module it references, as m attributes of the form m="b=baja", with component types written against those aliases — t="b:Station". The distinct m attributes are the modules the component tree genuinely depends on.

On a publicly published demo backup — an AX-era one, but the container format has not changed — dist.xml lists 514 installed modules and config.bog references 13. Eleven of the 514 have a vendor other than Tridium; exactly one of those eleven appears in the config.

That ratio is the normal case. Most of what is installed on a long-lived host arrived with a distribution or somebody's abandoned trial, and carries no risk because nothing points at it.

The obvious way to find third-party modules is to filter the vendor attribute for anything that is not Tridium. It reads better than it works. In that same backup the field takes the values Tridium, Tridium Inc. and Tridium, Inc., and separately both Vykon and vykon — a brand of Tridium's own. A naive comparison puts four Tridium modules in the third-party column and splits one vendor in two.

The fix is dull: normalise case and punctuation, keep an explicit list of the names that mean Tridium, and cross-check what is left against the module names in a clean installation of the same framework version. A name that appears in a stock install is Tridium's whatever its vendor string says.

A module already installed and licensed keeps running after its vendor closes. Four things break instead, all at a version change rather than on a date.

Two of the four have a workaround and two do not. Knowing which of your modules sit in which row is the value of doing the inventory early.

These get collapsed into one, and should not be: one is achievable without the vendor and the other is not.

A jar's signature lives entirely in META-INF/. Replacing it touches no class file and needs no source — strip the existing signature files and sign again. So a module that needs only a fresh signature, where the code is fine and the certificate has lapsed, is technically solvable with the vendor gone.

It is not free. You need the right to redistribute the jar, which is a licence-agreement question rather than a technical one; and the signature then asserts that you vouch for code you did not write and cannot read — a real position to occupy the first time it misbehaves on a live site. Decide that in writing, not during a commissioning week. A module that needs a code change is a different matter, and re-signing does nothing for it.

In rough order of how often they turn out to be the right answer.

The cheapest thing on this page and the most often skipped. Downloads, documentation and the licence-request route disappear with a vendor's domain, and a domain advertised for sale can start serving somebody else's content without notice. Four things, as files rather than bookmarks: every jar version you are entitled to, not only the installed one, because a rollback needs the old one; the user guide, release notes and point-mapping reference; the licence files and vendor certificates, with the Host ID each was issued against beside them; and the licence agreement, which decides whether re-signing or redistribution is open to you at all.