The port community system of the future will be open source
Well-orchestrated AI agents now build software. DMS, a company automated at 80 %, has rebuilt its port community system that way: a free PCS that every port can read, audit and run at home, made of the appointment and gate software DMS already runs in ports.
100 % of the features of a PCS in one open platform · 17 bricks, 16 open and 1 closed · 824 modules in 147 applications (measured on 18/10/2026)
The context
Software as we knew it has disappeared: language models ended it, and well-orchestrated AI agents now write, test and ship the code. DMS is automated at 80 %. Humans validate the business rules at the start and the go-live at the end; agents do the rest.
What we already had, and what we rebuilt: our appointment (VBS) and gate (GOS) software runs in ports; we rebuilt a small TOS for South America and Africa (not deployed yet); and with our cloud agents we built a PCS.
A free PCS
We had our own PCS and meant to sell it. When a partner told us about a project to open one up, we chose to give ours. What remains is organising its deployment: any port will download it, read it and install it.
Built on real software
Four layers already in production: appointments (VBS) and gate (GOS) in North American ports, the web customer portal (WCP) in Canada, North America and Europe, which handles its users’ payments every day, and billing. 824 modules already written.
100 % already there
Every feature a PCS needs is covered by the platform, from the community and truck appointments to vessel calls, declarations and customs.
Then day one
The code is open and the setup is offered: DMS installs and runs it. The subscription starts on day one, from the first connection.
What stays with DMS
The models and the business rules, our real added value: quotas, truck turn time, forecast, resource planning, stacking, swap. Two patents filed cover the macro and micro levels.
With the ports
The port authority announces, the community governs the roadmap, DMS builds and runs. Each terminal keeps its own business rules.
The port community systems that exist today
17 systems compared from public information, to be verified with each operator. Names are trademarks of their owners, shown only to identify each system.
| PCS | Port · country | Governance | Open code | Functions | What we learn |
|---|---|---|---|---|---|
| Portbase | Rotterdam · Amsterdam · Netherlands | not-for-profit organisation backed by the port authorities | No | vessel call notification · declarations · manifests · truck/barge/rail appointments · container status | a PCS backed by the port earns the trust of the whole community |
| DAKOSY | Hamburg · Germany | company owned by port players | No | community EDI · export/import customs · container status · transit | customs EDI is the backbone that makes a PCS indispensable |
| SOGET S)ONE | Le Havre · French ports · France | private company | No | port single window · customs · manifests · cargo status | the customs link creates the value — the rest plugs in around it |
| MGI Ci5 | French Mediterranean ports · France | private company of the port community | No | cargo tracking · customs · port community data | a PCS tracking feed is worth most when third-party applications can read it |
| PORTNET | Singapore · Singapore | run by the port ecosystem | No | vessel call · port services · billing · status | a PCS that bills port services becomes the counter for every payment |
| Valenciaport PCS | Spanish Mediterranean ports · Spain | port authority foundation | No | vessel calls · cargo · inland transport · data | a port authority can fund a PCS as a common good |
| Portic | Barcelona · Spain | port community company | No | EDI · transport orders · status | the local community wants to keep control of its data |
| Destin8 (MCP) | Felixstowe · UK ports · United Kingdom | private company | No | customs · container status · payments | after Brexit the customs link made usage explode |
| Port Optimizer | Los Angeles · United States | driven by the port with an industrial partner | No | supply-chain data visibility · arrival forecasts | a port data portal without integrated appointments leaves a gap — the place of a VBS |
| NxtPort | Antwerp · Belgium | community data platform | No | data sharing · APIs · data marketplace | data sharing only takes off if everyone keeps control of their rights |
| dbh Logistics IT | Bremen · Germany | private company | No | EDI · customs · status | historical PCSs are EDI integrators |
| Kale Logistics | several ports and airports · India | private company | No | SaaS PCS · documents · payments | multi-port SaaS already exists on the air side — not open source |
| Maqta Gateway | Abu Dhabi · United Arab Emirates | subsidiary of the port group | No | single window · payments · services | a PCS backed by the port group moves fast but does not export |
| Port-MIS | Korean ports · South Korea | public administration | No | vessel calls · declarations · statistics | the regulatory side is first a matter of state (national single window) |
| eModal | US ports · United States | private company | No | trucker community portal · appointments · fee payments | in the US truckers pay their fees through a single portal — an established habit |
| TradeLens | global · — | consortium of a carrier and a software vendor (discontinued) | No | document sharing · blockchain | a platform backed by one carrier did not convince its competitors — neutrality matters more than technology |
| US public PCS initiative | US ports · United States | public funding · open-source publication announced | announced | common PCS for ports | the only other open-source initiative we know of |
What the benchmark tells us
None of these systems is open source: a port can neither read the code nor run it at home, and each installation is a project of its own. Hence our answer: one all-in-one platform, made of open bricks and plugins, that each port installs, audits and extends.
What each port community system covers
| PCS | Vessel call | Declarations | Customs | Truck appointments | Gate · OCR | Container status | Payments | Data sharing | Empties · swap | Open code |
|---|---|---|---|---|---|---|---|---|---|---|
| Portbase | ● | ● | ● | ● | ○ | ● | ? | ◐ | ? | ○ |
| DAKOSY | ? | ● | ● | ? | ○ | ● | ? | ◐ | ? | ○ |
| SOGET S)ONE | ● | ● | ● | ? | ○ | ● | ? | ◐ | ? | ○ |
| MGI Ci5 | ? | ● | ● | ? | ○ | ● | ? | ◐ | ? | ○ |
| PORTNET | ● | ◐ | ? | ? | ○ | ● | ● | ◐ | ? | ○ |
| Valenciaport PCS | ● | ● | ? | ◐ | ○ | ● | ? | ◐ | ? | ○ |
| Portic | ? | ◐ | ? | ◐ | ○ | ● | ? | ◐ | ? | ○ |
| Destin8 (MCP) | ? | ◐ | ● | ? | ○ | ● | ● | ◐ | ? | ○ |
| Port Optimizer | ◐ | ○ | ○ | ○ | ○ | ● | ○ | ● | ? | ○ |
| NxtPort | ○ | ○ | ○ | ○ | ○ | ◐ | ○ | ● | ? | ○ |
| eModal | ○ | ○ | ○ | ● | ○ | ● | ● | ◐ | ? | ○ |
| DMS open-source PCS | ○ | ○ | ◐ | ● | ● | ● | ● | ◐ | ● | ● |
● yes · ◐ partly · ○ no · ? not known. Other systems: public information, to be verified with each operator. Our row: ● runs today, ◐ being adapted, ○ to build.
Where we differ
Some of these are not in the PCS specifications yet: they come from the software DMS already runs in ports.
Truck appointments at the core
Slots, quotas per block and waiting lists are the heart of the platform, not an add-on to customs EDI.
A community of thousands
Truckers, dispatchers and drivers handled every day, with their own accounts and roles per port.
Gate with OCR
Plates and containers read at the gate, the appointment checked in seconds, the EIR issued on the spot.
Empty swaps
A trucker returning an empty is matched with one looking for an empty: two trips become one.
Rating of every player
Each organisation is rated on what it really does (punctuality, no-shows, turn times), in the manner of ride-hailing apps.
Turn time per truck
The time spent in the terminal is measured from gate in to gate out, per truck and per company.
What is missing everywhere
Seven gaps shared by the port community systems of the benchmark. No system is named: these are gaps of the category, not of one product.
No one is open source
A port can neither audit the code nor run it itself.
Costs: audit · With an open PCS: sovereignty
The truck is forgotten
Historical PCSs were born from EDI and customs. Truck appointments, the gate and empty swaps are add-ons; here they are the core.
Costs: congestion · With an open PCS: shorter queues
Integrators, not products
Every installation is a custom project. Nobody installs in five minutes.
Costs: time to start · With an open PCS: install in minutes
Captive data
Players hesitate to share because they cannot see who reads what. A signed log and consent per data item remove that brake.
Costs: trust · With an open PCS: data that flows
One port at a time
A trucker working in two ports has two accounts and two interfaces. Federation between ports does not exist in these systems.
Costs: double work · With an open PCS: one account
Carbon is missing
Avoided trips and modal shift are not counted, while port authorities must report them.
Costs: reporting · With an open PCS: savings counted with the GLEC framework and ISO 14083
Local terminals pay twice
A terminal buys an appointment system, then a gate system, then a portal. With appointments (VBS) and gate (GOS) inside the PCS, local terminals save those purchases.
Costs: cost of tools · With an open PCS: all in one
The connectors are given away too
The connectors to terminal operating systems, EDI and OCR cameras are part of the open code: an integration starts from a connector that already works, not from a blank page.
Terminal operating systems already connected: Navis N4 (versions 4.0, 3.8 and 3.2), Octopi, Master Terminal, Atlasoft, and more. Names are trademarks of their owners, shown only to identify each system.
TOS connectors, both ways
Read vessel calls, container status and holds from the terminal operating system; write appointments and gate transactions back. One connector per TOS and per version.
A modular ETL
One sub-module per TOS, the same common model at the output. Adding a terminal means adding a sub-module, not rewriting the pipeline.
The OCR API contract
The contract our gate uses with OCR cameras, with its JSON collection: any OCR vendor plugs in by following it.
Where we stand
A qualitative map built from public information: openness of the code (left to right) and depth on the landside, where trucks meet terminals (bottom to top). The other systems of the benchmark are shown as unnamed dots.
Open-source PCS = PCS + VBS + GOS + Billing + WCP + Community management + Rating
Positions are a judgement from public information, not a measurement.
What already runs
The PCS is not a project starting from zero: it reuses the parts of the DMS platform that are written and, for most of them, in service today.
VBS · truck appointments
37 modules · in production
GOS · gate and OCR
141 modules · in production
Core platform
67 modules · organisations, slots, vessel calls, data pipelines
Identity and federation
18 modules · single sign-on, roles per port
Intermodal · barge · rail
32 modules · transport plans, forecasts
Empties and swap
41 modules · matching empty containers
Billing
14 modules · invoices, payments, wallet
EDI hub
4 modules and 22 carrier connectors · carrier messages
Carbon
code written · emissions per trip, not yet in service
AI agents
13 modules · connector for AI assistants
Support
10 modules · tickets and service levels
Customer portal
a web portal · in production
When the code was written
| Area of the code | Modules | First → last month written |
|---|---|---|
| Api | 3 | 05/2025 → 07/2025 |
| Appointment | 10 | 05/2025 → 02/2026 |
| Authority | 5 | 05/2025 → 02/2026 |
| Booking | 5 | 05/2025 → 04/2026 |
| Carbon | 4 | 05/2025 → 10/2026 |
| Edi | 9 | 05/2025 → 08/2026 |
| Empties | 3 | 05/2025 → 12/2025 |
| Gate | 10 | 05/2025 → 08/2026 |
| Identity | 11 | 05/2025 → 09/2026 |
| Notifications | 3 | 05/2025 → 10/2025 |
| Payment | 8 | 05/2025 → 04/2026 |
| Status | 4 | 05/2025 → 05/2026 |
| Support | 2 | 05/2025 → 05/2026 |
| Vessel call | 7 | 05/2025 → 02/2026 |
| Data | 5 | 10/2025 → 09/2026 |
| Customs | 4 | 02/2026 → 02/2026 |
| Declarations | 2 | 02/2026 → 02/2026 |
| Forwarders | 1 | 09/2026 → 09/2026 |
Dates from the first commit of each module in git, measured on 18/10/2026.
Feature by feature: all there
48 functions a port community system needs, brick by brick. 26 are already in the DMS code, 16 need adapting, 6 are still to build. A link opens the public product page when one exists; the others are described in the sub-applications below.
Community and identity
accounts · organisations · roles · permissions (in the code)
one organisation present in several ports (federation) (to adapt)
two-factor login · magic link (in the code)
access card · TWIC (in the code)
Vessel call
vessel call schedule (in the code)
vessel visit and berth operations (in the code)
stowage plan (BAPLIE) (to adapt)
arrival notification and FAL forms (to build)
port dues · pilotage · towage · mooring (to build)
Declarations and single window
import/export cargo manifest (to build)
national maritime single window connector (to build)
dangerous goods declaration (to adapt)
Customs
customs holds and releases (to adapt)
customs exam and scanning (to adapt)
national customs connectors (to build)
Truck · barge · rail appointments
truck appointment by slot and quota (in the code)
one portal for several terminals (to adapt)
waiting list · transfers · delay requests (in the code)
barge and rail appointments (to adapt)
Gate and OCR
automated gate · OCR · plate reading · barriers (in the code)
EIR · equipment interchange receipt (in the code)
weighing · seals · reefers (in the code)
Container status
container status and history (in the code)
subscription to a container’s events (in the code)
vessel GPS tracking (to adapt)
Booking and release
booking · release · delivery order (to adapt)
letter of guarantee (in the code)
electronic bill of lading (eBL) (to build)
EDI and connectors
carrier EDI hub (in the code)
railway operator APIs (in the code)
TOS connectors (in the code)
Payment and billing
billing · invoices · receipts (in the code)
card payment · prepaid wallet (in the code)
gate fees · penalties · peak pricing (in the code)
connection to the accounting ERP (to adapt)
Notifications
email notifications · messaging · chat (in the code)
Empty containers
empty container exchange between truckers (in the code)
empty return rules · depots (to adapt)
Forwarders
forwarder portal · files · documents (to adapt)
Data sharing
consent and data sharing between players (to adapt)
audit log of every exchange (in the code)
Port authority
port authority cockpit · congestion (to adapt)
modal shift · intermodal (in the code)
Carbon
carbon footprint per trip and per terminal (in the code)
API
public API · service keys · logs (to adapt)
connector for AI agents (in the code)
Support
support · SLA · tickets (in the code)
Public portal
public customer portal (to adapt)
« in the code » means the function exists in DMS today, not that every port can switch it on yet. Statuses as of 23/10/2026.
The 17 bricks of the PCS
Each brick is a sub-application a port installs as it needs. 16 are open; the orchestrator stays with DMS. The status says where each brick stands today: « in development » means its tables, lists and screens exist and are tested, not yet its functions.
Community and identity
one account per person · one record per organisation · roles per port · federation between ports
Code: open · Status: in development
Vessel call
from arrival notice to departure: ETA · berth · operations · FAL forms · port dues
Code: open · Status: in development
Declarations and single window
manifests · dangerous goods · submission to the national maritime single window
Code: open · Status: in development
Customs
holds · releases · exams · customs status visible to the trucker
Code: open · one connector per country · Status: in development
Truck · barge · rail appointments
the DMS VBS as a brick: slots · quotas · multi-terminal · waiting list
Code: open (core) · models closed · Status: first version
Gate and OCR
the DMS GOS as a brick: OCR · plate reading · barriers · EIR · weighing
Code: open (core) · models closed · Status: in development
Container status and subscriptions
one single view of the container · its events · its subscribers
Code: open · Status: in development
Booking · release · eBL
from booking to delivery order · letters of guarantee · electronic bill of lading
Code: open · Status: in development
EDI hub and connectors
one translator from EDIFACT · API · CSV to the common model · TOS and rail connectors
Code: open · Status: in development
Payments and billing
gate fees · penalties · port services · prepaid wallet · ERP link
Code: open · Status: in development
Empties and swap
return rules · depots · empty exchange between truckers (ContainerSwap)
Code: open (marketplace) · matching engine closed · Status: in development
Data sharing and consent
who sees what · consent per data item · log of every read · data-space connector
Code: open · Status: in development
Port authority cockpit
congestion · avoided trips · modal shift · carbon · control-room screens
Code: open (screens) · forecasts closed · Status: in development
Carbon
emissions per trip · per terminal · per trucker · gains from swaps
Code: open · Status: in development
Public API and agents
a documented API · keys per organisation · a connector for AI agents
Code: open · Status: in development
Public portal
the community website: tracking · appointments · documents · support
Code: open · Status: planned
Orchestrator and models
the models that decide: quotas · forecasts · resource planning · business rules
Code: closed · two patents filed · Status: in development
Statuses as of 20/10/2026, updated as each brick is delivered.
The projects
A repository is linked here only once it is public.
DMS PCS
In development · Licence to be announced
GOS core
Coming soon · Licence to be announced
VBS core
Coming soon · Licence to be announced
Container Vessel Schedule
Coming soon · GPL-2.0-or-later
Connectors
Coming soon · Licence to be announced
Safer because open
Code that everyone can read is code that everyone can audit.
Code anyone can read
Anyone can audit the core. A flaw is reported through a public security policy, fixed in public, published with its date.
One instance per port
A port’s data never sits next to another port’s. Federation shares identity and empties, never operational data.
On premises possible
The same installer runs behind the port’s VPN, on its own servers. DMS has already installed on premises at a terminal.
Least privilege
Roles per port and per organisation · two-factor login · API keys per organisation, revocable.
Signed log
Every read of someone else’s data is traced: who, what, when. The data owner sees it.
Service targets
| What | Target | Note |
|---|---|---|
| Core availability (cloud) | 99.9 % per month | proposed target · on premises: depends on the port infrastructure |
| Read API response | < 500 ms (95th percentile) | proposed target |
| EDI message translation | < 1 min end to end | proposed target |
| Gate decision on an appointment | < 2 s | proposed target |
| Retention of the data-access log | per the port’s law (at least 1 year proposed) | proposed target · to agree with each authority |
| Critical security fix published | < 72 h after report | proposed target |
These are proposed targets, agreed with each port; they are not measured guarantees.
The standards the PCS speaks
A PCS is worth the messages it understands. Each standard is tied to a brick.
| Standard | Use | Brick |
|---|---|---|
| UN/EDIFACT | BAPLIE · CUSCAR · CODECO · COARRI · COPARN · IFTDGN | EDI hub · Vessel call · Declarations |
| IMO FAL · ISO 28005 | vessel call forms, ship-to-port electronic exchange | Vessel call |
| EMSWe (European Union) | European maritime single window | Declarations |
| DCSA | Track & Trace · Booking · eBL | Container status · Booking |
| ISO 6346 | container identification | Gate · Status |
| IMDG | dangerous goods | Declarations · Gate |
| GLEC · ISO 14083 | transport emissions calculation | Carbon |
| OpenAPI · MCP | public API · AI-agent connection | API |
| IDSA · Gaia-X | sovereign data spaces | Data sharing |
DMS is a member of TIC 4.0, the initiative that standardises terminal operations data.
One instance per port, cloud or on premises
The open core runs at the port; the DMS orchestrator is called through an API; federation links the ports.
Port A · one instance
The open PCS core and the port’s own database. Nothing is shared with another port’s instance.
Port B · one instance
Same core, its own database, its own rules. Each port decides when it updates.
On premises · behind the port VPN
The same core and a local database on the port’s own servers, when the data must not leave them.
Around each instance
- Federation: identity and empties shared between ports, never operational data
- DMS orchestrator: called through an API for the closed models and business rules; the core never depends on it
- Terminal operating systems: feed each instance through the connectors
- National single windows: declarations exchanged with each instance
How the public repository will be organised
open-pcs/ ├── core/ shared core ├── modules/ 16 open bricks ├── connectors/ TOS · carriers · customs · single windows ├── installers/ docker · cloud · on-prem ├── docs/ specs · UML · guides └── tests/
One brick = one module = one main table. The core never depends on the orchestrator: without it, each brick keeps simple rules. The repository opens once the code is ready and scanned for secrets.
The code is free, the API is billed
Software as we knew it is gone. Well-orchestrated AI agents now write, test and ship code, and DMS works that way: agents build, people set the business rules and decide the go-live. When code costs this little to write, it is no longer what a port should pay for.
So we open it. A port, its integrators and its community read the code, audit it and run it, in the cloud or on their own servers. Open code is safer code: anyone can check what it does. It frees a port from lock-in: no single supplier holds its data or its integrations. And it lets everyone move faster, because a port that needs a feature can build it on the same bricks as everyone else.
The code is open
On premises or in the cloud: any port downloads it, reads it, runs it.
The setup is offered
DMS installs the platform and runs it for the port, with no setup fee.
The subscription starts on day one
From the first connection, even with a single user: the API and the data behind it.
Open
- the code of the appointment system (VBS), the gate system (GOS) and the PCS bricks
- the TOS, EDI and customs connectors
- the cloud and on-premises installers
- the documentation, the UML and the tests
At DMS
- the AI models: quotas, forecasts, turn times, resource planning, orchestration
- the business rules configured for each terminal and each port
- installing, operating, supervising and optimising each installation
- the subscription to the API and to the data behind it
The models and the business rules behind them are ours, protected by our patents, and they are not licensed with the open code.
Compared with open-core companies
| Company | Free | Not free | What we keep from it |
|---|---|---|---|
| Red Hat | the full system | support, maintenance, certification | the software is free, trust is the product |
| GitLab | the community edition | enterprise features, hosting | the boundary must be clear and written |
| Odoo | the community edition | enterprise edition, hosting | openness brings partner integrators |
| Mattermost | the server | compliance, large teams | sovereignty matters to the public sector |
| Elastic | the engine | managed services, advanced features | a too-permissive license lets a large cloud resell the product |
The port keeps its data, on the infrastructure it chooses. A repository is linked from this page only once it is public, and each brick shows its real status: « in development » until its functions are written and tested.
“One AI platform for the whole port city: setup offered, open code, and a subscription from day one.”
Olivier Raveau · Co-Founder & CTO, DMSLOG.Ai · About us
With the port authorities
The PCS is a common good of the port: the authority announces it, the community governs it, DMS builds it.
The port announces, DMS builds
A joint letter in which the port authority announces the deployment; DMS commits through its CEO. If the port prefers, the letter can come from DMS.
A community board
Terminals, truckers, forwarders, carriers, customs: one seat each to prioritise the public roadmap.
Data rules voted
The board sets the default sharing rules; each data owner can be stricter, never looser.
Open contributions
Every contribution goes through review and tests. DMS maintains the core.
Each rule above is a proposal, agreed with each port before it applies.
How a port works with us
Who brings what. A starting point to discuss with each port, not a contract.
The port authority
the port, its community, the governance and the public mandate
Partners who know the ports
introductions, funding paths, the first pilot port
DMS
the code (appointments, gate, core), the team and its AI agents, installation and operation
The port community
priorities, feedback, contributions
From a first call to a first port
What is true today, then the order of what follows. No date is promised: each step is set with the port.
| When | What |
|---|---|
| Today | The bricks of the appointment system (VBS) and the gate system (GOS) are opened one by one; each shows its real status, « in development » until its functions are written and tested. |
| Today | This page: what the open-source PCS is, how it is built and how it is governed. |
| Next | A first pilot port: vessel call, declarations and customs connectors configured with the port. |
| Then | The port authority cockpit and data sharing between the members of the port community. |
| Then | Federation between ports: shared identity and empties, never operational data. |
What could go wrong, and the answer
A port that builds on open-source software should know where it can fail. Here are the six risks we see, and what we do about each one.
A large player takes the code and resells it
Our answer: strong-reciprocity license for the core (AGPL proposed) · registered trademark
Likelihood: 30 % (our estimate) · Response: reduce
Customs and single windows differ by country
Our answer: one connector per country, outside the core · start with one pilot port
Likelihood: 60 % (our estimate) · Response: reduce
Parallel initiatives split the effort
Our answer: talk early and propose one shared project
Likelihood: 40 % (our estimate) · Response: share
The community does not contribute
Our answer: DMS stays maintainer · value comes from configuration and operation, not contributions
Likelihood: 50 % (our estimate) · Response: accept
A flaw published before its fix
Our answer: SECURITY.md · coordinated disclosure · fix within 72 h targeted
Likelihood: 20 % (our estimate) · Response: reduce
Confusion between the open core and the models
Our answer: written boundary · two patents filed
Likelihood: 25 % (our estimate) · Response: avoid
The likelihood is our own estimate, a judgement rather than a measure. Responses: reduce · share · accept · avoid.
Open code around, our AI at the core. The models and business rules behind this page are ours, protected by our patents.
Want to contribute or integrate?
Integrators, ports and developers: tell us what you would build on these bricks. We answer every message and organise a call (Zoom, Teams, Meet).
- Your message. What you want to build, connect or replace, and for which port or terminal.
- A call. We show the bricks that already run, the open core and where the closed models stop; the bricks still in development are named as such.
- A first piece of work together. A connector, a brick or a pilot, with its scope and its rules set with you; no date is promised before that.
For port authorities
What the port gets, how it is governed, how a port works with us. Port authorities
The open port community system
The 17 bricks, feature by feature, and how a port deploys them. Port community system
See also: All port solutions
