DMS PCS, the open-source Port Community System
One community system for every actor of the port city, built from the DMS code that already runs truck appointments, gates and container tracking in production. Open code, so a port can read it, audit it and own its data.
Every feature a PCS needs, in one open platform · 17 bricks, 16 open and 1 kept by DMS · 824 modules in 147 applications already written (measured on 18/10/2026)
The PCS in six sentences
- Well-orchestrated AI agents now write, test and ship software; DMS is automated at 80 %, humans validate the business rules and the go-live.
- Our appointment (VBS) and gate (GOS) software already runs in ports in North America and Europe.
- We rebuilt our port community system on that code: 17 bricks, from vessel call to customs and carbon.
- 16 bricks are open: any port reads the code, audits it and runs it, in the cloud or on its own servers.
- DMS installs and runs it; the subscription starts on the first day of connection, with no setup fee.
- The models and the business rules stay with DMS, covered by two patents filed.
Where it comes from: forty years of port community systems
Port community systems are more than forty years old.
1982 · Hamburg
1984 · Singapore
1999 · Barcelona
2005 · about 30 ports
2026 · open source
Built on code in production
Open, so the port owns it
Developed test-first
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 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
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.
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.
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 bricks 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.
17 bricks, from vessel call to carbon
🪪 Community and identity
Partly in production, being adapted
🚢 Vessel call
Partly in production, being adapted
📄 Declarations and single window
To build
🛃 Customs
To build
🗓️ Truck · barge · rail appointments
Partly in production, being adapted
🚧 Gate and OCR
Runs in production at DMS today
📦 Container status and subscriptions
Partly in production, being adapted
🎫 Booking · release · eBL
Partly in production, being adapted
🔌 EDI hub and connectors
Runs in production at DMS today
💳 Payments and billing
Partly in production, being adapted
🔁 Empties and swap
Partly in production, being adapted
🔐 Data sharing and consent
Partly in production, being adapted
🏛️ Port authority cockpit
Partly in production, being adapted
🌿 Carbon
Runs in production at DMS today
🧩 Public API and agents
Partly in production, being adapted
🌐 Public portal
To build
🧠 Orchestrator and models
Stays at DMS, by subscription
EDI hub and connectors. One translator from EDIFACT · API · CSV to the common model · TOS and rail connectors.
Who uses it. Carrier · terminal · rail · TOS.
Where the code is. First functions working: 7 of 10 endpoints written test-first and merged.
- carrier EDI hub (UN/EDIFACT CODECO · COARRI · COPARN) — runs at DMS today
- railway operator APIs — runs at DMS today
- TOS connectors — runs at DMS today
Customs. Holds · releases · exams · customs status visible to the trucker.
Who uses it. Customs · forwarder · terminal · trucker.
Where the code is. First functions working: 7 of 8 endpoints written test-first and merged.
Declarations and single window. Manifests · dangerous goods · submission to the national maritime single window.
Who uses it. Ship agent · carrier · customs · harbour master.
Where the code is. First functions working: 2 of 4 endpoints written test-first and merged.
- import/export cargo manifest (UN/EDIFACT CUSCAR) — to build
- national maritime single window connector (EMSWe (EU) · IMO FAL) — to build
- dangerous goods declaration (IMDG · UN/EDIFACT IFTDGN) — being adapted
- customs holds and releases — being adapted
- customs exam and scanning — being adapted
- national customs connectors — to build
Payments and billing. Gate fees · penalties · port services · prepaid wallet · ERP link.
Who uses it. Trucker · terminal · port authority.
Where the code is. First functions working: 6 of 9 endpoints written test-first and merged.
- billing · invoices · receipts — runs at DMS today
- card payment · prepaid wallet — runs at DMS today
- gate fees · penalties · peak pricing — runs at DMS today
- connection to the accounting ERP — being adapted
Empties and swap. Return rules · depots · empty exchange between truckers (ContainerSwap).
Who uses it. Trucker · depot · carrier.
Where the code is. First functions working: 6 of 9 endpoints written test-first and merged.
- empty container exchange between truckers — runs at DMS today
- empty return rules · depots — being adapted
Data sharing and consent. Who sees what · consent per data item · log of every read · data-space connector.
Who uses it. Everyone · port authority.
Where the code is. First functions working: 7 of 7 endpoints written test-first and merged.
Public API and agents. A documented API · keys per organisation · a connector for AI agents.
Who uses it. Developers · partners.
Where the code is. First functions working: 5 of 5 endpoints written test-first and merged.
- consent and data sharing between players (data spaces (IDSA / Gaia-X)) — being adapted
- audit log of every exchange — runs at DMS today
- public API · service keys · logs (OpenAPI) — being adapted
- connector for AI agents (MCP) — runs at DMS today
Port authority cockpit. Congestion · avoided trips · modal shift · carbon · control-room screens.
Who uses it. Port authority · city.
Where the code is. First functions working: 11 of 12 endpoints written test-first and merged.
- port authority cockpit · congestion — being adapted
- modal shift · intermodal — runs at DMS today
Carbon. Emissions per trip · per terminal · per trucker · gains from swaps.
Who uses it. Port authority · terminal · trucker.
Where the code is. First functions working: 8 of 8 endpoints written test-first and merged.
- carbon footprint per trip and per terminal — runs at DMS today
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.
Our security work does not stop at the PCS: the Port Cyber Alliance, one of our spin-offs, is a collaborative cybersecurity alliance for port terminals, built on threat sharing.
How we work
A brick is never shown as « available » before its functions are written
Each endpoint is written test-first
Every partner integration gets a readiness endpoint
A product is published only when it is validated
Code climbs four environments before production
What we built along the way
Swap Container
swapcontainer.com
FranceFreight
francefreight.com
Port Cyber Alliance
portcyberalliance.org
CanadaFreight and USA Freight
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.
The model is the one Red Hat made famous: the software is free, the trust is paid, support, maintenance and certification.
Others drew the same line, and each taught us something:
GitLab
Odoo
Mattermost
Elastic
So about 80 % of the platform is free for anyone to download, and the remaining 20 %, the business rules and the configuration, is what a port calls us for.
Language models made code disappear: the asset is the spec
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 %
So the code is no longer what a port pays for
What stays with DMS is the models and the business rules
Our specs: the asset behind the code
sections in the PCS specification
detailed specifications
The specification of the PCS is a CONOP of 29 sections, from the bricks and the feature matrix to governance, risks and the roadmap.
Behind it, 140 detailed specifications, one per need.
Some come with sample data and a ready-to-run API collection, so a team can test the brick on day one.
The specs are shared on request, to engineers, project leads and port management.
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.
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 adopts an open port community system 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.
“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
Open code around, our AI at the core. The models and business rules behind this page are ours, protected by our patents.
Is your port interested?
Tell us about your port and its community. We organise a call (Zoom, Teams, Meet) and show you the bricks that already run.
- A first call. Your port, its community, the systems already in place and what you want to change first.
- The bricks that already run. Appointments and the gate, shown as they work today; the bricks still in development are named as such.
- A first pilot port. Its scope, its connectors and its governance are 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
Open source at DMS
Why we open our code, what is open and how to contribute. Open source
See also: All port solutions
