orientechnologies/orientdb: technical due diligence, read from its repository

The median source file here is 75 lines. 63 files exceed 1,000 lines, the largest being 6,452. Size is not a defect on its own — some problems genuinely live in one place — but these are where merge conflicts, review fatigue and single-owner knowledge concentrate, and they are the first thing that slows an inheriting engineer down.

9,960 distinct 8-line blocks appear in two or more files. Copy-paste is the cheapest thing a generator does and among the more expensive things to inherit: a fix has to be applied everywhere the block landed, and nothing in the repository records where that is. Tests, fixtures and documentation examples are excluded — those repeat by design — so this is duplication in code that ships. Blocks are matched after normalising whitespace and only across different files.

141 product files are in the new language and 47 are still in the old one, 118 months after the first new file appeared. The new language's share of the lines rose from 7% to 74%, and moved 0 percentage points in the last year. Two languages for one job doubles what an engineer has to know, and the unmoved half is usually what nobody wants to touch. Ask whether finishing it is planned, and what it costs.

Deleted lines per line added rose from 0.75 to 1.04 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.

47 files were marked deprecated over two years ago and still are, the oldest since Oct 2016. A deprecation is a promise to remove. Ask what still depends on these, and whether removing them is scheduled.

The newest release, 3.2.57, is not on the branch this survey read; the newest release on it is 3.2.27. The shipped product may differ from what this report describes. Survey the release branch too.

Strings shaped like credentials appear only where fakes are usual: test fixtures, examples, documentation, placeholders and local stacks. They are almost always fakes. Ask someone to confirm that none of them works anywhere, because a real key in a development file is still a real key.

7 places in product code build SQL by formatting or joining strings rather than passing parameters. 1 of them put a value into the string; in the rest, what the code shows going in is a table or column name, a constant, or something the line does not show. Ask whether any value reaches these strings, rather than a parameter.

6 places read data with a deserialiser that executes what it reads (Java object streams). That is safe on data the system wrote itself and remote code execution on anything else. Ask where each one's input comes from.

45 of 1,055 locked dependencies match 117 published advisories in OSV, 56 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version. This lockfile pins development tools alongside what ships and does not say which is which, so some of these may never reach a user.

Third-party code is committed into this repository without any statement of the terms it arrived under. Unknown terms are harder to deal with than inconvenient ones: an awkward licence can be complied with, an absent one cannot. Each of these needs its origin established before the code changes hands.

The root licence changed 2 time(s). The last change widened rights. Code taken under earlier terms stays under them; check which terms any fork or customer relied on.

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.