For the last decade, the loudest Enterprise Resource Planning (ERP) roadmaps have pointed in the same direction: up, into the vendor’s cloud. For a law firm or a distributor, that direction is mostly fine. For a manufacturer, the roadmap runs into a fact no slide deck can move: the machines are bolted to the floor in the building, and the ERP has to talk to them.

So here is my position, stated plainly so you can argue with it. The future of ERP is open source, shipped the way Linux is shipped: a shared core, with vendor- and industry-specific distributions built on top. And for manufacturers in particular, a true ERP cannot run efficiently or economically as pure Software as a Service (SaaS). It has to live close to the shop floor, which means it has to live comfortably on the same open Linux stack that already runs the industrial edge.

That is an opinion, not a forecast with a confidence interval. Below is the case for it, the strongest arguments against it, what artificial intelligence (AI) coding agents change about those arguments, and the places where I think it still needs a caveat.

Linux already solved the distribution problem

The way I read the history, Linux did not win by being one product. It won by being one core that many organizations could package for different needs. Debian is a distribution; Ubuntu is one of many distributions built on Debian’s work; Red Hat Enterprise Linux (RHEL) is a commercial distribution with a support subscription attached. The kernel underneath is shared. What differs is curation, release cadence, defaults, and who answers the phone at 2 a.m.

ERP has most of the parts for the same model already sitting on the shelf:

Project Core license What it shows
ERPNext on the Frappe Framework ERPNext: GNU GPL v3; Frappe: MIT A framework-plus-application split, close to a kernel-plus-userland split. Manufacturing is in the core feature list.
Odoo Community: GNU LGPL v3; Enterprise: proprietary Open core. The open edition is real, and the paid edition is not open source.
Odoo Community Association Community modules Lists 20,000-plus community-built Odoo modules, which is a package repository in all but name.
Apache OFBiz Apache License 2.0 An Apache top-level project since 2006, with manufacturing and material requirements planning (MRP) modules.
iDempiere GNU GPL v2 Community-run since 2011, with long-term support (LTS) releases.
Dolibarr GNU GPL v3 Describes itself as a “multi-distribution model”: on-premise, self-hosted cloud, or SaaS.

What’s mostly missing is the step Linux took in the 1990s: the industry distribution. Think of it as Ubuntu for job shops. A curated, tested bundle of the core, the manufacturing modules, the U.S. tax and payroll localizations, and the machine connectors, released on a predictable cadence, with a vendor you can pay for support and leave if you need to. Nobody types apt install erp and gets a running plant. But someone can maintain the equivalent of a well-tested package list for a 60-person Front Range machine shop, and charge for doing it well.

That is the first half of the thesis. The second half is about where the server sits.

Why the shop floor keeps the ERP close

A manufacturing ERP is not just a ledger with a warehouse attached. The transactions that matter most, like backflushing material, recording lot and serial genealogy, putting a quality hold on a batch, or reporting scrap against a work order, come from machines rather than from someone with a clipboard in a well-connected plant. The International Society of Automation publishes a whole standard on this boundary, ISA-95, Enterprise-Control System Integration, because getting it wrong is how plants end up re-keying production by hand.

The machines speak open industrial protocols. Open Platform Communications Unified Architecture (OPC UA) is the platform-independent framework from the OPC Foundation, and open62541 is an open-source implementation of it under the Mozilla Public License 2.0 that runs on Linux, real-time operating systems, and other platforms. MQTT is an OASIS-standard publish/subscribe protocol, and the Eclipse Foundation’s Sparkplug specification defines how industrial data rides on it. Its client libraries and reference implementations, Eclipse Tahu, are open source too. The protocols at the bottom of the plant are already open. The question is whether the ERP at the top meets them on equal terms.

Three forces push that meeting point toward the plant instead of a distant cloud region:

  • Offline resilience. When the internet connection drops, the line keeps running. If the ERP can’t receive production, the plant has to choose between stopping and keeping paper records to re-key later, and paper is where genealogy and inventory accuracy go to die.
  • Latency and determinism. Programmable logic controllers (PLCs) and computer numerical control (CNC) machines run their own control loops, and nobody sensible puts those in the ERP. But the layer that turns machine events into transactions, such as the manufacturing execution system (MES), the historian, and the ERP’s production module, works better when the network path is one you own and can troubleshoot.
  • Data volume and egress. Sending data into a public cloud is generally free, and Azure’s pricing FAQ says as much for inbound transfer. Getting it back out is not. Microsoft’s published Azure bandwidth pricing (checked October 2026) lists internet egress from North America over its own network as free for the first 100 GB a month, then about $0.087 per GB for the next 10 TB. In fairness, AWS says over 90 percent of its customers pay no data-transfer-out charges at all because of a similar 100 GB monthly allowance. Egress is not a tax on everyone. It is a tax on exactly the data-heavy, machine-connected plant this essay is about, especially one that pulls sensor history back down to an on-site MES or a second platform every day.

And the Linux side of the stack has spent the last few years becoming more industrial. In Linux 6.12, released November 17, 2024, the real-time preemption patch set (PREEMPT_RT) was merged into mainline after roughly 20 years of work, so a real-time-capable kernel is now a configuration option, not an out-of-tree patch. The Linux Foundation’s Civil Infrastructure Platform maintains super-long-term kernels with a ten-year maintenance period, aimed at industrial automation and infrastructure, the kind of timescale plant equipment lives on. ELISA is working on tools and processes for certifying Linux in safety-critical systems. LF Edge hosts open edge-computing projects across industrial manufacturing and other sectors. And Margo, also under the Linux Foundation, is writing an open standard for running edge applications across vendors, with statements of support on its site from ABB, Rockwell Automation, Schneider Electric, Siemens, and Microsoft. Margo is still in preview releases, so treat it as a direction of travel, not a finished standard.

Be precise about what that does and doesn’t prove. Your ERP does not need a real-time kernel. Hard control stays on the PLC. The point is that one open kernel family now credibly covers everything from the edge controller to the ERP server. That means one operating-system skill set, one patching pipeline, and one set of open protocols from the sensor to the general ledger (GL). An ERP built to live on that stack fits the plant. An ERP that can only live in its vendor’s region has to be bolted onto the plant through a gateway.

The strongest objections, taken seriously

“Hybrid already solves this: SaaS ERP plus an edge gateway”

This is the best counterargument, and in many plants it’s the right architecture. Microsoft describes Azure IoT Operations as a data plane for the edge. It runs on Azure Arc-enabled Kubernetes, includes an edge MQTT broker, supports OPC UA, and processes data locally before sending it to the cloud. Even Odoo’s own approach is an Internet of Things (IoT) box, a local gateway that needs its own subscription on top of the Odoo one, which Odoo says is designed to give your database access to devices on your local network. Hybrid is real, it ships, and it works.

Notice two things, though. First, look at what the hybrid answer actually is: Kubernetes and an MQTT broker running at the plant. The hard part already lives on Linux on your side of the internet connection. Once you’re operating that, I’d argue the extra cost of running the transactional core nearby is smaller than the “cloud versus on-premise” debate suggests. Second, the gateway sets the limits. Microsoft’s own documentation says Azure IoT Operations can operate offline for a maximum of 72 hours, with possible degradation in that window. That’s an honest, useful number, and it’s a design limit you now have to plan around. A three-day holiday weekend with a fiber cut is not a hypothetical in rural Colorado. The gateway is also the vendor’s, so lock-in doesn’t disappear. It moves to the edge.

The caveat I’ll concede: for an assembly shop where production is reported by people at terminals rather than by machines, SaaS ERP plus a light gateway is a perfectly sound choice, and I wouldn’t talk anyone out of it. The thesis is strongest where machine data drives transactions.

“Open source isn’t free”

Correct. The license fee goes away, but the implementation, data migration, training, hosting, security patching, upgrades, and support do not. Some well-known projects are open core: Odoo’s Enterprise edition, for example, can only be used with a paid subscription. In our experience the license is rarely the line that sinks an ERP budget. The people-hours are.

Here’s why the thesis survives anyway. Open source changes who you’re allowed to pay for that work and what you keep when you stop paying. The distribution model is the business answer to “isn’t free”: you buy a support subscription from the distro vendor, the way companies buy RHEL, but the code, the data model, and the exit stay yours. A total cost of ownership (TCO) comparison that counts the license line and ignores the switching cost is measuring the wrong thing.

The caveat: if you have no in-house information technology (IT) capacity and no budget for a partner, a well-run SaaS ERP can cost less for years, and “we own the code” is cold comfort when nobody on staff can read it. Open source moves cost from licenses to people. Plan for the people. AI coding agents shrink that people cost, which I’ll come back to below, but they don’t remove it.

“A 50-person plant can’t out-secure a hyperscaler”

Also fair. Self-hosting means owning the patches, the backups, and the incident response. Two answers. First, open source does not have to mean on-premise: managed hosting for open-source ERP exists, from Frappe Cloud for ERPNext to local managed service providers, and Dolibarr explicitly offers on-premise, self-hosted, or SaaS. You choose where it runs and who runs it, and you can change your mind. Second, the edge stack you need for machine integration has to be secured either way. Siting the ERP next to it doesn’t add a new kind of risk. It adds one more workload to a discipline you already need.

“There aren’t enough consultants”

As far as we can tell, there are fewer implementers for ERPNext or iDempiere than for the big proprietary suites, and that is a real risk for a buyer. It’s also the clearest sign that the industry distribution is the missing piece. A distro vendor’s whole job is to make a long tail of modules into something a smaller partner network can support. AI coding agents work on the same gap from the other side: a small partner with agents and a readable codebase can plausibly cover more plants than it could before.

What AI coding agents change about the people problem

Three of the concessions above come down to the same constraint: people. Open source moves cost from licenses to labor, implementers for open-source ERP are thin on the ground, and a plant with no technical staff can’t own code nobody can read. That’s also the constraint that has been moving fastest.

AI coding agents now do supervised work on real codebases, well beyond autocomplete. GitHub says its Copilot cloud agent can research a repository, plan changes, fix bugs, implement incremental features, and improve test coverage. It works in its own temporary environment where it can run tests and linters, and it hands back a branch or a pull request for a person to review. Anthropic describes Claude Code as a tool that reads your codebase, edits files, and runs commands. And METR, a nonprofit research group, reported in February 2026 that use of agentic tools such as Claude Code and Codex grew among open-source developers through 2025. A growing share of the developers it tried to recruit for a productivity study said they would not want to do half their work without AI.

For a manufacturer on an open-source ERP, that capability lands on exactly the work the earlier caveats worried about:

  • Connectors. An adapter that subscribes to Sparkplug topics on the plant’s MQTT broker, or reads OPC UA nodes through open62541, and posts counts and scrap to an ERPNext or Odoo work order.
  • Plant-specific modules. A Frappe app or an Odoo module for an inspection form, a scrap-reason code list, or a label format your biggest customer insists on.
  • Reports and migrations. The report the controller has been rebuilding in a spreadsheet every month, and the scripts that move item masters and open orders out of the old system.
  • Tests and upgrades. Tests written with each change, and, when the next major version ships, a first pass at reading the upstream changes and proposing fixes for what broke.

Here’s why this strengthens the open-source case specifically, not just ERP in general. An agent can only work with what it can read. An open-source ERP gives it the whole codebase, the data model, and the project’s history of changes. Open protocols give it a published specification and an open reference implementation to test against. A proprietary SaaS ERP gives it an application programming interface (API) at best, with a black box behind it. The agent can call the API, but it can’t read why the vendor’s posting logic behaves the way it does or predict what next quarter’s release will change. The main public benchmark for these agents, SWE-bench, is itself built from real GitHub issues in open-source Python repositories. That’s telling: open code is where agents can see the code, the issue, and the tests all at once. Open code plus open protocols is the environment agents work best in, and it’s the environment this essay argues manufacturers should be choosing anyway.

Keep the claim the right size. I’m not offering a productivity multiplier, because the best evidence doesn’t support a clean one. METR’s randomized trial in early 2025 found that experienced open-source developers took 19% longer with AI tools than without, even though they believed they had been faster. METR now says those results are out of date. Its February 2026 update says developers are likely sped up more now, but that its newer data is only very weak evidence of how much. The narrower claim I’ll stand behind: agents lower the floor. They reduce the specialist headcount it takes to own and maintain a modest set of connectors, modules, and reports on an open codebase. They don’t make the work free, and they don’t make it safe by default.

The limits are where most of the risk lives:

  • A human owner still reviews and merges. Every agent change should arrive as a pull request that a named person who understands the plant reads, tests, and approves. That’s the governance pattern from our earlier post, ERP customizations should be the default, applied to the shop floor. An agent with no reviewing owner is not a team. It’s an unattended commit history.
  • Agents get shop-floor safety logic wrong. A model doesn’t know that a guard interlock exists, what your lockout procedure is, or why the line has to stop when a sensor goes quiet. Control and safety logic stay on the PLC, under the people and standards that already govern it. The agent’s work ends where machine events become transactions. It writes to the ERP, never to the controller.
  • Security and supply chain. A 2024 study of 16 code-generating models and 576,000 code samples found that, on average, at least 5.2% of the packages suggested by commercial models and 21.7% of those suggested by open-source models did not exist. Each fake name is an opening for an attacker who registers it. Pin dependencies, review every new package, run agents with least privilege, and keep them away from production credentials and the plant network.
  • Agents don’t replace process knowledge. An agent doesn’t know why you backflush at the operation instead of at completion, or which customer’s lot rules live in a contract rather than in the system. That knowledge is the business, and it still lives in people. Agents shrink the coding, not the knowing.

The updated caveat: the “SaaS until you have the people” advice still holds for a plant with nobody technical at all. But “the people” is now a smaller number than it was. For many small plants, one technically minded owner plus a part-time partner, working with agents under review, can plausibly own a modest open-source deployment that would have needed a dedicated developer a few years ago. That’s a judgment, not a measured result, so test it on your own work before you bet on it.

Where the thesis holds, and where it bends

Plant profile My read
Machine-connected production: genealogy, overall equipment effectiveness (OEE), automated backflush, regulated lots Strongest case. Plan for ERP and MES near the floor on Linux, on an open-source core, with cloud for analytics and backup.
Mixed: some machine data, mostly people reporting at terminals Either path works. Choose on exit cost and offline tolerance, not on the demo.
Light assembly or make-to-order with manual reporting SaaS ERP plus a gateway is fine. Keep your data exportable.
One technically minded owner and a small partner budget Now plausible, which it mostly wasn’t before. Run an open-source core, with AI coding agents drafting connectors, modules, and reports, and every change reviewed by that owner or the partner.
Nobody technical and no partner budget SaaS first, until you have at least one person who can review changes. Open source without owners is just abandoned software you happen to have a copy of, and agents without a reviewer make it worse, faster.

What to do this quarter

You don’t have to bet the plant on my prediction to act on it. These steps pay off whichever way it goes:

  • Map the machine-to-ledger paths. List every transaction that starts as a machine signal, such as counts, scrap, temperatures that trigger holds, or labels, and note how it reaches the ERP today. That list is your real integration scope.
  • Measure your offline tolerance. Ask operations: if the internet connection dropped at 6 a.m. Friday, what stops, and when? Compare the answer with what your current or proposed ERP can actually do offline, in writing.
  • Price egress against your own volumes. Use the cloud vendor’s pricing page, not a sales estimate. Count data leaving the cloud, not just data entering it.
  • Ask every ERP vendor four questions. What runs at the plant when the link is down? What open protocols, such as OPC UA or MQTT with Sparkplug, does it speak natively? Under what license are the edge components? In what format, and at what cost, do we get all our data out?
  • Stand up a sandbox. Put an open-source ERP (Odoo publishes packaged installers for Debian and Ubuntu, and ERPNext’s Frappe Framework officially supports Debian and Ubuntu) on a spare Linux box, load one product line’s bill of materials, and see how far you get in a few weeks. Then ask an AI coding agent to write one small connector or report against that open code, and have someone review the pull request it produces. That review will tell you more about your real staffing need than any vendor’s estimate. The point is to see what’s possible and to build your negotiating position, not to replace your system. For what happens when that kind of evaluation never takes place, see Frankenstein’s ERP: the monster you already own.

Next step

Linux didn’t win because anyone mandated it. In my reading, it won because a shared core with many distributions turned out to be the cheapest way to fit a huge range of needs without handing any one vendor the keys. I think manufacturing ERP is heading the same way, for the same reason, with the added push of physics: the machines are in your building. If you’re weighing an ERP decision for a plant and want a vendor-neutral second opinion on where it should run, what it should speak, and how much of the work agents can carry, see our ERP consulting for manufacturers.