neosloc archive

Repositories /

openfantasymap/geomqtt

https://github.com/openfantasymap/geomqtt · commit e24a4a64b17a · evaluated 2026-10-07 with neosloc 0.8.0 · JSON

1.78 integrability index over 9 applicable dimensions
service, library surfaces
$125k → $33k classic COCOMO → neosloc value (27% survives)
buy make / buy = 3.46 over 3 years

Dimensions

Interface surface 4 exemplary [service] A second surface: another transport (HTTP and a protocol, two protocols), an MCP server, a CLI with JSON output, or an SDK.

Can another program use it through a documented, machine-readable surface?

  • next: [library] L4 An API reference is generated from the code (autodoc, mkdocstrings, typedoc, …). (no generated API reference)

library ladder · level 3

service ladder · level 4

Contract stability 1 ad hoc Releases are versioned (semver tags or versioned changelog sections).

Can integrators rely on it not changing under them?

  • next: L2 A changelog exists and marks breaking changes. (no changelog)

all ladder · level 1

  • ✓ L1 Releases are versioned (semver tags or versioned changelog sections). 8 semver tags, latest v0.4.0
  • ✗ L2 A changelog exists and marks breaking changes. no changelog
  • ✗ L3 A deprecation mechanism is used in code (warnings, @deprecated, Deprecation/Sunset headers) or the API is versioned. no deprecation mechanism or API versioning
  • ✓ L4 Across tagged releases, no OpenAPI operation, CLI option or __all__ symbol was removed without first being deprecated. 8 tagged releases compared
Events 3 solid Signed webhooks registrable through the API, or two mechanisms (webhooks, streams, a broker).

Can others react to state changes without polling?

  • next: L4 Events are described by AsyncAPI or CloudEvents. (no AsyncAPI or CloudEvents contract)

service ladder · level 3

Identity 0 absent Not yet: Programmatic authentication (bearer tokens, API keys).

Can a machine act with its own revocable, least-privilege identity?

  • next: L1 Programmatic authentication (bearer tokens, API keys). (no token auth)

service ladder · level 0

  • ✗ L1 Programmatic authentication (bearer tokens, API keys). no token auth
  • ✗ L2 Per-client, revocable credentials (managed API keys, service accounts) or OAuth2. no managed keys or OAuth
  • ✗ L3 Credentials carry scopes or permissions. no scopes or permissions
  • ✗ L4 Standard provisioning or federation (OIDC client credentials, SCIM). no OIDC client credentials or SCIM
Data portability n/a Not applicable: owns no persistent data.

Can its data get in and out, in bulk, in open formats, with an explicit schema?

Agent ergonomics 1 ad hoc [service] Errors are machine-readable: consistent JSON over HTTP, or a standard protocol's native error replies (RESP errors, MQTT reason codes, gRPC status, SQLSTATE).

Can an automated caller use it without guessing, and recover from failure?

  • next: [service] L2 Field-level validation errors, and paginated lists. (no request validation)
  • next: [library] L1 Errors are specific exception types, and library code never calls sys.exit. (no exception classes)

library ladder · level 0

  • ✗ L1 Errors are specific exception types, and library code never calls sys.exit. no exception classes
  • ✓ L2 Inputs are validated with messages naming the bad argument. clients/geomqtt-core/src/config.ts 1 match
  • ✗ L3 Timeouts and retries are configurable. no timeout parameter
  • ✗ L4 Agent docs, and examples that run as tests (doctests). examples don't run as tests

service ladder · level 1

  • ✓ L1 Errors are machine-readable: consistent JSON over HTTP, or a standard protocol's native error replies (RESP errors, MQTT reason codes, gRPC status, SQLSTATE). crates/geomqtt-server/src/resp.rs native protocol error repliescrates/geomqtt-server/src/mqtt.rs native protocol error replies
  • ✗ L2 Field-level validation errors, and paginated lists. no request validation
  • ✗ L3 Typed errors (RFC 9457 over HTTP, or a standard protocol's typed error codes), idempotent writes (Idempotency-Key), and rate-limit signals. no idempotency keys
  • ✗ L4 Dry-run or validate-only, conditional requests, and agent docs. no dry-run
Embeddability 4 exemplary [service] Composition artifacts (compose, Helm, IaC).

Can another system run and compose it without a human?

  • next: [library] L4 Optional features behind extras/features. (no optional extras)

library ladder · level 3

service ladder · level 4

Extensibility 0 absent Not yet: Internal seams: a registry, registration function or plugin manager.

Can behaviour be added without modifying the code?

  • next: L1 Internal seams: a registry, registration function or plugin manager. (no registry or registration function)

all ladder · level 0

  • ✗ L1 Internal seams: a registry, registration function or plugin manager. no registry or registration function
  • ✗ L2 The docs show how to add behaviour through those seams (even in-tree). no registration functions to document
  • ✗ L3 Out-of-tree extensions are discovered (entry points, a plugin directory, configuration) without editing the package. extensions must be added inside the package
  • ✗ L4 The extension API is versioned, has lifecycle hooks, and has example extensions. the extension API isn't versioned
Observability 1 ad hoc [service] A health or readiness endpoint, or a container healthcheck.

Can an operator, or an orchestrating agent, tell whether it works and why not?

  • next: [service] L2 Structured logs. (no structured logging)
  • next: [library] L1 Logs through a standard logger namespace and never prints from library code. (no standard logger)

library ladder · level 0

  • ✗ L1 Logs through a standard logger namespace and never prints from library code. no standard logger
  • ✗ L2 Log levels are used meaningfully (at least two levels). fewer than two log levels used
  • ✗ L3 Optional metrics or tracing hooks. no metrics or tracing hooks
  • ✗ L4 OpenTelemetry instrumentation available. no OpenTelemetry instrumentation

service ladder · level 1

Change legibility 2 partial CI runs the tests; applications pin dependencies (libraries and zero-dependency projects are exempt).

Can an agent change it safely with limited context?

  • next: L3 At least 90% of modules fit 32k tokens and no file exceeds 12k; test/source token ratio at least 0.3; at least 70% of the code is typed. (test/source token ratio 0.09 < 0.3)

all ladder · level 2

Make or buy

Make with agents

175,672 output + 4,391,800 input tokens on anthropic:claude-opus-5-5 ≈ $7.

1.9 agent-hours · 3.6 human days (2.1 steering + 1.5 rediscovering history).

$2,809 over 3 years

Buy (adopt as is)

5 min to running (via service) + 2 min to first use (via service).

240 min/year of upgrades; price $0/year.

$812 over 3 years

Buying wins below $666 per year. How this is estimated.

Classic COCOMO vs neosloc value

Classic COCOMO (sloccount)

4.29 KSLOC → 11.1 person-months over 6.2 months.

$125k

The effort to write it by hand, as COCOMO priced it in 1981.

neosloc value (neoCOCOMO)

Reproduce with agents: 3.1 PM (×0.28 of classic; 59% of behaviour captured by tests, contract and docs).

Rediscover uncaptured history: 0.1 PM (1 fixes in 28 commits by 1 authors).

× leverage 0.97 (integrability) × obsolescence 0.95.

$33k (3.0 PM)

What survives

27% of the classic figure

2% of the replacement cost lives only in code and history.

How the value is estimated.

History

2026-10-07: 1.782026-10-07: 1.782026-10-07: 1.782026-10-07: 1.782026-10-07: 1.78
EvaluatedCommitneoslocIndexMake or buy
2026-10-07e24a4a64b17a0.8.01.78buy
2026-10-07e24a4a64b17a0.7.41.78buy
2026-10-07e24a4a64b17a0.7.31.78buy
2026-10-07e24a4a64b17a0.7.21.78buy
2026-10-07e24a4a64b17a0.7.11.78buy