Borehole · Project · free tier
odoo/docker
Free reading: not for reliance
bf04b8f · 320 commits · 15 files
Read 2026-10-23

odoo/docker: technical due diligence, read from its repository

What Borehole read in odoo/docker's code and history at bf04b8f: its licence, security advisories, releases, review practice, tests, dependencies and operations. Every finding cites the file and line it rests on. The full report also covers the team and asks the questions the code cannot answer.

DimensionRating
Architecture & Codebase — including AI provenancestrong
Engineering Process & SDLC Maturityadequate
Product & Engineering Maturityadequate
Security & Reliability Posturestrong
Observability & Operationsadequate
Fit with the Acquirernot assessable

Architecture & Codebase — including AI provenance

strong

No finding.

Engineering Process & SDLC Maturity

adequate
02.1

Little of the recent change carries a trace of review

adequate

In the last 24 months, 3 of 63 commits (4.8%) carry any trace of review: a merge, a pull-request reference, a Reviewed-by or Reviewed-on trailer, a Closes/Fixes reference, a maintainer's sign-off on someone else's change, or a change applied by someone other than its author. That is low but not absent. Review may happen in a workflow this history does not record; a buyer should ask how change is approved before it ships.

Evidence
3 of 63 commits in the last 24 months carry review evidence; 13.8% across all 320
02.4

Nothing in the history is tagged as a release

adequate

Across 11.8 years of history there is not one tag. There may still be a deployment process, but this repository holds no record of what shipped when — which is the record a buyer needs to reconstruct an incident or a regression after the fact.

Evidence
0 tags across 320 commits and 4327 days

Product & Engineering Maturity

adequate
04.1

Change keeps returning to the same few files

adequate

Five files out of 54 absorb 53% of all file-level change. Concentration like this is where debt is usually being serviced rather than repaid: the same code is reopened because it is load-bearing, fragile, or both. A repository cannot tell you which — that is a conversation with the team.

Evidence
14.0/Dockerfile — 99 commits touched it
15.0/Dockerfile — 95 commits touched it
13.0/Dockerfile — 93 commits touched it
16.0/Dockerfile — 91 commits touched it
17.0/Dockerfile — 87 commits touched it
04.5

Effort is shifting from building to rewriting

adequate

Deleted lines per line added rose from 0.61 to 0.87 between the first and second halves of this history. Rework is normal and often healthy, but a rising ratio means an increasing share of the team's time is spent replacing code that already exists rather than building what does not. Whether that is deliberate repayment or churn is a question for the team.

Evidence
first half 0.61, second half 0.87 (split 2020-11-12)

Security & Reliability Posture

strong

No finding.

Observability & Operations

adequate
06.8

One request cannot be followed through the logs

adequate

Nothing in the service carries a request or correlation id, and there is no tracing. When a customer reports a failure, the log lines that belong to their request cannot be picked out from everyone else's.

Evidence
no request id, correlation id or tracing found
06.9

No error reporter is wired in

adequate

Nothing in the service initialises an error reporter (Sentry, Rollbar, Bugsnag, Honeybadger or an APM agent). An exception in production reaches a person only if someone is reading the logs, which usually means a customer reports it first.

Evidence
no error reporter initialised

Fit with the Acquirer

not assessable

Not rated: structurally not assessable from a repository.

Read more, or read your own

The full report on odoo/docker: every dimension, the questions for the room, and the audit log.

Survey a repository: free on public repositories. Private code is read on your own machine by a collector whose source you can read first.