Open Source WMS in 2026: OpenBoxes vs openWMS vs Apache OFBiz Compared

Your warehouse runs on a spreadsheet your predecessor built in 2019. It has 14 tabs, three hidden columns nobody understands, and every stock count turns into two days of arguing about which numbers are real. You have looked at commercial WMS pricing and discovered that a 20-user licence costs more per year than the forklift you bought in 2023. So you started searching for an open source alternative — and found three projects that all claim to be a warehouse management system but were clearly built for completely different jobs.

That is the actual problem. OpenBoxes, openWMS.org and Apache OFBiz are not three versions of the same product. One is a health-sector supply chain tool, one is an industrial material flow controller, and one is a full ERP suite that happens to include warehouse logic. Picking the wrong one costs you six months of integration work.

TL;DR — Quick Verdict

• You manage medical supplies, lab reagents or NGO stock across multiple facilities → OpenBoxes. It was designed for exactly that, ships with expiry/lot tracking that actually works, and the newest release (v0.9.8-hotfix1, August 2026) is actively maintained.
• You run an automated or semi-automated warehouse with conveyors, PLCs and material flow control → openWMS.org. It is the only one of the three with a real Material Flow Control subsystem and a microservice architecture that talks to field devices.
• You need one system for orders, purchasing, accounting, inventory and warehouse operations → Apache OFBiz. Heaviest of the three, but it is the only option that replaces your ERP and your spreadsheet at the same time.

If you just need barcode-driven stock movements in a single warehouse and nothing else, install OpenBoxes and stop reading comparison articles. The other two will make you learn an entire enterprise architecture to solve a problem you do not have.

Head-to-Head Comparison

All repository figures below were pulled live from GitHub while writing this article (22 October 2026).

That table already tells you something important: the star counts are all in the same narrow band (753–1,137). None of these projects has the community gravity of an Odoo or an ERPNext. You are adopting software maintained by a small core team, and that should shape your risk planning as much as any feature checklist.

Decision Matrix — Pick in 10 Seconds

OpenBoxes — The Healthcare Supply Chain Specialist

OpenBoxes was built by and for people who move medicine. Its data model revolves around products with lot numbers and expiry dates, stock movements between locations, and requisition/purchase order flows between a central warehouse and peripheral facilities. If your inventory has a shelf life, this is the only one of the three where expiry handling is a core feature rather than a customisation project.

The repository ships an actual Docker Compose file at docker/docker-compose.yml. Here is the real content, not a cleaned-up version:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

version: "2"
services:
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: openboxes
      MYSQL_USER: openboxes
      MYSQL_PASSWORD: openboxes
    volumes:
      - ./openboxes-mysql.cnf:/etc/mysql/conf.d/openboxes-mysql.cnf
      - ./mysql/:/var/lib/mysql/

  tomcat:
    image: tomcat:7
    ports:
      - "8072:8080"
    volumes:
      - ./openboxes.war:/usr/local/tomcat/webapps/openboxes.war
      - ./openboxes-config.properties:/root/.grails/openboxes-config.properties
    environment:
      CATALINA_OPTS: "$CATALINA_OPTS -server -Xms1024m -Xmx2024m -XX:MaxPermSize=256m -Djava.security.egd=file:/dev/./urandom"

Read that file carefully before you deploy it, because it encodes a decade of technical debt:

• MySQL 5.7 is past upstream end-of-life. You are running an unpatched database unless your distribution backports fixes.
• Tomcat 7 is likewise ancient, and -XX:MaxPermSize was removed in Java 8 — the flag is silently ignored on modern JVMs, which tells you the compose file has not been exercised against a current JDK.
• The compose file expects you to build openboxes.war yourself and drop it into docker/. It is a deployment recipe for developers, not a turnkey appliance.

The pragmatic path in 2026 is to build the WAR from the release tag and run it on a maintained Tomcat with a maintained MySQL 8 instance, then keep the compose file as documentation of the required volume and environment wiring rather than as your production topology. Budget a day for the WAR build and JDBC driver swap; the application itself installs cleanly once the data source is correct.

Where OpenBoxes earns its keep is the operational model. Stock movements are explicit transactions with a reason code, so your audit trail is not reconstructed from a quantity column that someone edited in place. Requisitions flow from a requesting location to a fulfilling location with approval states. Lot and expiry data attach to the item, not to a free-text note. For a clinic network, those three behaviours are the entire product.

openWMS.org — Material Flow Control for Real Warehouses

openWMS.org is the most architecturally serious project of the three and the least friendly to casual evaluation. It is not one application; it is a set of independently deployable business services, each with its own data store and API lifecycle. The root repository explains the intent plainly: high-cohesion business functions live in small components, and an ERP on top sends high-level tasks down while PLCs and sensors sit at the bottom.

The stack is aggressively current. Building the project requires JDK 25 and the Maven wrapper:

1
2
3

git clone https://github.com/openwms/org.openwms.git
cd org.openwms
./mvnw clean verify -DsurefireArgs=-Dspring.profiles.active=ASYNCHRONOUS,TEST

Each business service — inventory, receiving, shipping, transport orders, material flow — is its own repository with its own Spring Boot application and its own PostgreSQL schema. That is excellent for teams that already run Kubernetes and want to scale receiving independently from shipping. It is painful for a two-person IT department that wanted one jar and one database.

What you get in exchange is the only genuine Material Flow Control implementation in the open source WMS space. If your warehouse has conveyor segments, transfer units, or automated storage and retrieval, MFC is the layer that turns “move pallet 1234 from A to B” into device commands with state tracking. Competing open source projects treat the physical layer as out of scope. openWMS does not.

Two practical warnings. First, the project’s own documentation lives on an external wiki, not in the repository — there is no monolithic README that explains the whole system, so plan on reading several service repos to assemble a mental model. Second, because there is no monorepo compose file, there is no single command that brings the system up. You will assemble the service topology yourself, which is exactly the moment when most evaluators give up. If you cannot assign one engineer for two weeks to a proof of concept, choose a different system.

Apache OFBiz — The Full ERP That Includes a Warehouse

Apache OFBiz is a different species. It is an Apache Software Foundation project covering orders, parties, products, manufacturing, accounting and — among all that — inventory and warehouse operations. You do not adopt OFBiz to manage a warehouse; you adopt it because you want one system of record for the entire business.

Deployment is genuinely easy for a project of this size, because the repository ships a real Dockerfile and a DOCKER.adoc that documents it:

1
2
3
4
5
6
7

# from the source directory that contains the Dockerfile
docker build --tag ofbiz-docker .

docker run -it -e OFBIZ_DATA_LOAD=demo \
  --name ofbiz-docker \
  -p 8443:8443 \
  ofbiz-docker

The container publishes port 8443 (HTTPS), loads demo data on first boot, and serves the application — for example the party manager at https://localhost:8443/partymgr. The Dockerfile is a multi-stage build that produces an uninitialised runtime image; seed or demo data is loaded on the first run, and an admin user is created at that point. That is a considerably more modern packaging story than OpenBoxes offers.

The trade-off is weight. OFBiz carries a framework with its own entity engine, service engine, screen widgets and a Groovy/Java business layer. Customising warehouse behaviour means learning that framework, and the official documentation, while extensive, assumes you are comfortable in enterprise Java. Expect months, not days. The reward is that your pick list, your invoice and your general ledger all agree with each other because they are the same system.

One operational note that catches people: the default database is Apache Derby, embedded and fine for evaluation, but not what you want for a production warehouse with concurrent users. Switch to PostgreSQL before you load real data — migrating an embedded Derby store that already contains transaction history is a chore you can avoid entirely.

Pitfalls Nobody Warns You About

Legacy container images are the biggest hidden risk in OpenBoxes. The shipped compose pins MySQL 5.7 and Tomcat 7. If you copy it to production because “it is in the repo”, you inherit two unsupported platforms on day one. Treat the file as a specification of volumes and environment variables, and build your own images.

openWMS is a distributed system, and distributed systems fail in distributed ways. With one database per service, a failed goods receipt can leave inventory and transport orders temporarily inconsistent. You need monitoring, correlation IDs across services, and a plan for replaying messages. If you have never operated a microservice estate, this is not the project to learn on.

OFBiz demo data is not a tutorial. Loading OFBIZ_DATA_LOAD=demo gives you a populated store that looks impressive and teaches you very little about how the entities relate. Build a second, empty instance for your own data and use the demo instance purely as a field reference for what a valid record looks like.

All three assume you understand warehouse vocabulary. Putaway, replenishment, cycle count, transport order, handling unit, location versus facility — if those words are not already part of your operation, no software will fix the process gap. Write down your physical workflows first; the tool choice becomes obvious afterwards.

Licence compatibility still matters. OpenBoxes is EPL, the other two are Apache 2.0. If you plan to embed warehouse logic in a commercial product, Apache 2.0 is the friendlier licence — but none of these projects is a drop-in library, so this only matters if you fork.

FAQ

Is OpenBoxes really free for commercial use?

Yes. OpenBoxes is distributed under the Eclipse Public License, which permits commercial use, modification and redistribution. You pay for hosting, integration and your own time — not for seats. There is no per-user licence tier hiding behind the download page.

Can openWMS.org run on a single server?

Technically yes, in the sense that you can run several Spring Boot services on one host with one PostgreSQL instance and separate schemas. Practically, the project is designed around independent deployables, and you lose most of the operational benefit while keeping all of the complexity. If a single server is a hard constraint, evaluate OpenBoxes or OFBiz first.

What is Material Flow Control and do I need it?

Material Flow Control is the layer that translates warehouse tasks into commands for physical equipment — conveyors, transfer units, automated storage. You need it only if goods move without a human driving a forklift or pushing a cart. For a manual warehouse, MFC adds complexity with no payoff.

Which one handles lot numbers and expiry dates best?

OpenBoxes, without contest. Lot and expiry tracking are part of its core healthcare supply chain model, not a bolt-on. OFBiz can model lots through its inventory entities but requires configuration, and openWMS focuses on logistics units and transport orders rather than pharma-grade traceability.

Can I migrate from a spreadsheet into either system?

Yes, but only after you clean the spreadsheet. All three systems validate structure — a location must exist before stock can be received into it, and a product must have a unit of measure. Export your data, normalise locations and product identifiers, then import through the application’s own APIs or CSV tooling rather than writing directly to the database.

Which project has the healthiest long-term maintenance outlook?

Apache OFBiz has the strongest institutional backing because it is an Apache Software Foundation project with a formal release process. OpenBoxes shows continuous activity and recent tagged releases, which is a good sign for a smaller team. openWMS.org is active but has the smallest contributor base of the three — plan for the possibility that you maintain your fork.

If you are still mapping the wider software landscape around these systems, our self-hosted supply chain planning comparison covers the planning layer that sits above a WMS, and the manufacturing execution systems guide explains how shop-floor control connects to warehouse operations. Teams that also sell over a counter should read the self-hosted POS comparison before committing to an inventory backbone.

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到技术监管时间线，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测技术相关事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com