Most warehouse software evaluations start with a feature comparison and end with a surprise. Every feature on the list was genuinely there. What nobody checked was how deep each one went, what the license actually permitted, or who would still be around to fix things two years in.
An open source WMS moves more of that responsibility onto the buyer, which is both the advantage and the catch. The organization owns the codebase and the database rather than renting access to them, and the operating logic can be extended rather than only configured. Owning something also means evaluating it properly, across a wider surface than a proprietary product asks of you.
Three areas cover that surface:
This blog works through all three, with the questions worth asking in each and what a good answer looks like.
Start with defining the operation the system has to support before comparing any products, since the comparison is meaningless without it. An apparel fulfillment warehouse, an aircraft parts operation, and a food distribution center share receiving and shipping in name only. Their inventory and execution requirements diverge almost immediately.
Next, document warehouse locations, SKU counts, daily and peak order lines, concurrent operators, and expected growth. Establish whether you handle individual units, cases, pallets, kits, lots, serial numbers, or expiry dates, since those determine how much of the evaluation is about the data model rather than the screens. Next, list the systems the WMS has to connect to, including the ERP, order management system, commerce platform, and shipping carriers.
Once you have the basic mapping of your warehouse operations in place, move on to finalising on which outcomes matter most: inventory accuracy, faster fulfillment, traceability, fewer manual handoffs, or support for additional facilities. Those priorities are what should drive the demonstrations that follow, rather than the vendor's standard demo script.
Start with the workflows your team executes daily. A typical working checklist covers:
Every serious product will tick all six, however, depth is where they separate. Two systems can both list ‘wave picking’ yet offer completely different control over order selection, wave size, release timing, and exceptions.
These are examples rather than a complete list. Add your own based on the workflows your warehouse actually runs.
The answers worth trusting are those that carry specifics. An aviation maintenance operation of one of our clients, for instance, needed counting-frequency-based scheduling, counts at the individual inventory item level rather than aggregated at the part number, coverage for serialized and non-serialized parts, and scanner-based counting throughout. That capability was built into the Apache OFBiz warehouse module rather than selected from a list of supported count types, which is the difference between a system that can do it and a system that already does.
You can ask the team demonstrating the software to run a complete workflow end to end, including an exception, using orders and inventory that resemble yours. Put your warehouse operators and supervisors in that session since they are the ones who will actually use it. Watch whether instructions are clear, whether errors explain themselves, and whether an interrupted task can be resumed. Usability drives training cost and daily throughput, so it belongs in the evaluation alongside functional coverage.
Operational depth tells you what the system does today. The technical foundation determines what it will cost to change it, and how reliably it will hold up while the warehouse runs.
Check that documented REST APIs cover the workflows you need rather than just the easy ones such as ‘retrieving inventory’. Your integration will probably also need to create receipts, release work, confirm picks, and report shipments.
Ask for real examples of requests, responses, authentication, validation errors, and pagination on large datasets, and identify which version and modules provide them. Then examine failure handling, which is where integrations actually break.
For example: If a shipment confirmation is submitted twice after a timeout, what stops it being processed twice? Can a failed integration be inspected and replayed? Who owns reconciliation when the WMS and an external system disagree?
Settle ownership of each decision and record early, covering order routing, inventory reservations, and shipment status. Clear ownership prevents conflicting updates and makes failures far easier to trace.
The practical test is whether an unusual integration is possible at all. One of our clients for instance, a specialty retailer, runs FedEx and USPS alongside a custom international shipping integration with iGlobal, wired into the outbound workflow rather than bolted on at the end. There is no iGlobal connector to buy, which is exactly the situation an evaluation should probe.
The data model deserves direct attention, since it defines which relationships the software can maintain at all. Ask how products, facilities, storage locations, inventory, orders, receipts, and shipments connect to each other.
Can the system distinguish between total physical stock from stock actually available for allocation? Can damaged or quarantined inventory be held out of fulfillment? Can one product be tracked by location, lot, serial number, and ownership when & where the business requires it?
Test it with a concrete case. For example: A supplier delivers a case of serialized items, some go on hold, and the accepted units are split across locations before shipment. Ask the vendor’s team to walk through how those records stay connected the whole way. Real operations stretch the data model in ways a demo rarely does:
Gaps in foundational relationships are the expensive kind, since they surface across every workflow rather than in one screen.
Warehouse requirements move as customers, facilities, and service commitments change. Evaluate whether the platform absorbs new rules without turning every subsequent upgrade into a development project.
Ask how business services, data access, user interfaces, and background processing are separated:
Source access is only worth something when developers can read the code and extend it consistently, so review the developer documentation and one representative customization to see what future change actually involves.
Ask what evidence supports any performance claim. Daily order totals describe very little on their own. Order lines, scan frequency, inventory updates, concurrent users, and integration traffic all shape the real load.
Run operations together rather than in isolation: receiving and picking while new orders arrive and inventory updates flow out to connected systems, at the busiest expected period plus an agreed growth scenario. Measure operator response times, background processing delays, and whether inventory stays correct under contention. Two users reaching for the same remaining unit should produce a controlled result, not a race.
Batch processing is the usual pressure point, and pickwave generation is the heaviest of them. In one high-volume fulfillment deployment it drove CPU to between 70 and 85 percent for four to ten minutes, every 20 minutes. Handheld scanner traffic sharing that server slows every time a pickwave runs, which pickers experience as the system going soft at the worst possible moment. That deployment carries 11,500 orders a day at peak across two facilities and more than 70 warehouse users, at 50 to 70 database operations per order, and it runs deliberately at 40 to 50 percent capacity so it absorbs 50 to 75 percent order growth without an architectural change.
Ask any vendor for figures at that level of specificity.
Evaluate security at both the application and deployment levels. Establish how users authenticate, how permissions are assigned, and whether access can be scoped by role and facility. Ask who can adjust inventory, approve discrepancies, change configuration, or reach administrative functions, and whether those actions record the user, the time, the reason, and what changed.
That audit trail earns its cost the day a customer disputes a shipment and someone has to reconstruct a receipt in one facility, a transfer, and a pick in another, in order. Timestamps stored in local time give a multi-site database no reliable chronological order at all, so ask how time is recorded before you need the answer.
Confirm where the solution can run and who operates it, covering monitoring, backups, restore procedures, logs, and upgrades:
Ask for evidence that restoration has actually been exercised rather than documented.
This third area is the one proprietary evaluations never require, and the one most often skipped. An open source warehouse management system comes with a software project attached, complete with its own license, governance, contributors, and maintenance habits. Those deserve the same scrutiny as the application.
Identify the exact edition and components proposed for your implementation. Check whether the warehouse applications, barcode interfaces, integrations, reporting tools, and administrative features you need are included or supplied separately.
Ask for a plain explanation of:
Record any subscription requirements, implementation conditions, or dependencies on hosted services. Run the same assessments explained above on extensions as on the core platform, since that is where the surprises usually sit.
Source access does not tell you the terms. Licenses differ considerably in what they permit and what conditions attach to modification and distribution, so read the license for each major component against your intended use.
For organizations that want freedom to customize and commercialize, permissive licenses such as Apache 2.0 are worth prioritizing.
Apache License 2.0 permits use, modification, and distribution subject to its conditions and includes an express contributor patent grant within a defined scope. Redistribution obligations cover providing the license, identifying modified files, and preserving applicable notices, and it does not generally require publishing the source of your modifications.
Separately licensed extensions should be reviewed on their own terms rather than assumed to inherit the platform's license.
Look at who develops the project and how decisions get made. Examine contributions across different people and organizations, how proposed changes are handled, and whether significant discussions happen in public.
Repository popularity says almost nothing about the support your implementation will need. Read substantive issue discussions and completed fixes instead, and judge whether contributors can explain behaviour, review changes, and help newcomers understand the code.
Find out how maintainers are appointed and how releases are approved, and whether knowledge sits with one person or across an active group. The OpenSSF evaluation guide is a useful source of further questions on project maintenance and sustainability.
Follow the release history rather than the announcement volume. Examine what releases actually contain: functional improvements, bug fixes, dependency updates, migration changes, and security maintenance.
Separate feature development from maintenance of stable releases, since a stable branch may deliberately take only fixes while larger work progresses elsewhere. Ask which version is recommended for production and which capabilities exist in that version. Look for a documented upgrade path and evidence that upgrades are manageable in practice.
Find the project's security policy and reporting channel, and check whether advisories:
Judge the response process rather than the CVE count. Public disclosure gives your team something to act on, while an absence of advisories establishes nothing about whether vulnerabilities exist.
Apache OFBiz, for example, publishes a security policy and a vulnerability list with affected and fixed release information, which is the kind of transparency to look for. Then establish who monitors advisories and applies patches to your own deployment, extensions and dependencies included. A community fix only helps once it reaches production through a controlled update process.
Try the documentation before committing to anything. Have a developer follow the installation instructions and work through guidance on configuration, extension development, integrations, and upgrades, and have an operational lead review the workflow documentation. Check whether examples name the applicable version and whether important links still work. Note wherever successful setup depended on knowledge that was not written down.
Then read existing community discussions and ask a specific question in the appropriate public forum or mailing list, with enough context for someone to answer it. Judge several exchanges rather than one, since a single unanswered question proves little. Community assistance and contracted production support are different things, so if the warehouse needs defined response times and escalation ownership, evaluate that arrangement separately.
A capable partner understands the platform and warehouse operations, not one or the other. Ask about years of implementation experience, involvement in the project itself, and production WMS work with requirements resembling yours. Request examples covering traceability, integrations, inventory migration, operational exceptions, and go-live.
Community contributions are reasonable evidence of familiarity with the platform's internals, though they are not a substitute for implementation references, a named delivery team, and a stated approach to upgrades and support. Establish who owns process design, development, migration, testing, training, and production incidents, and how knowledge transfers to your team so the solution stays maintainable. The competencies worth screening for, and the red flags, are worth reviewing before the first conversation.
Compare the full implementation and operating effort, covering configuration, custom development, integrations, data migration, devices, training, hosting, support, and upgrades. Classify each important requirement as standard, configurable, requiring development, or dependent on a separately supplied component, which exposes cost and schedule assumptions while they are still cheap to correct.
Clarify access to source code, deployment instructions, configuration, and business data. If you change partners later, what rights, documentation, and skills will you need to keep going? Practical control depends on those details at least as much as on the core license. The broader trade-off between buying, building, and adapting is worked through in our comparison of SaaS and custom WMS.
Apache OFBiz belongs on the shortlist for organizations that want an open source foundation they can adapt rather than a product they configure. Its enterprise application platform covers warehousing and inventory alongside procurement, order management, manufacturing, and accounting, sharing one architecture and data model rather than being stitched together after the fact, with entity and service engines built for extension.
That matters when warehouse workflows have to connect to other business processes. An evaluation can weigh the warehouse application needed today against how related processes might grow onto the same platform later.
Apache OFBiz provides a good warehouse management foundation. HotWax Accelerator then takes that foundation and builds upon it by adding the execution and planning layers that a high-volume operation needs such as an order routing engine, profile-based pickwave planning, and cycle counting. It also comes along with modern operator interfaces, an API-first design, Apache Solr for search, and Superset for analytics.
HotWax Accelerator is a source-available platform, provided only to HotWax Systems clients as part of an implementation project. It is not open source, however clients get access to the source code and can customize it to fit their operation. Additionally there is no separate license fee for the Accelerator. The cost is for the implementation work itself, not the software. Apache OFBiz remains the open source foundation underneath it.
None of the above substitutes for running the software. Bring the warehouse and technology teams together for a focused proof of concept: receive a partial delivery, put stock away, release a pickwave, handle a picking shortage, pack and ship, process a return, and reconcile inventory.
Record what worked, what needed configuration or development, and what stayed unclear, then set those results against the technical, community, licensing, and support evidence gathered along the way. That combination is what makes the decision defensible six months later.
HotWax Systems has worked with Apache OFBiz for more than 20 years, with contributors and committers on the team, and has built warehouse solutions for aviation and aerospace, food and beverage, and apparel operations.
If you are working through an evaluation like this one, we are happy to talk it through.