Hi all,
I would like to gauge the community's appetite for adding **opt-in,
anonymous usage telemetry** to JMeter. Nothing is built yet, and nothing
would be built without rough consensus here first and sign-off from the ASF
Privacy Committee. This thread is to test the idea and shape the data we
would collect.
## Why
We make maintenance decisions with little evidence about how JMeter is
actually used. Telemetry would let us:
- see which samplers, controllers, and other elements people use, so we can
prioritise effort and retire dead features with data rather than guesswork;
- learn which Java and OS versions are still in the field, so we can set
minimum-version policy responsibly;
- measure how widely each UI locale is used, so translation effort goes
where it helps;
- understand how often tests run from the GUI versus the CLI, and at what
scale.
## Principles
The proposal is privacy-first by design:
- **Opt-in, off by default.** Telemetry starts only after the user gives
explicit consent. We also honour the `DO_NOT_TRACK` environment variable
and a JMeter property to disable it.
- **Headless and CI stay silent.** Non-GUI runs cannot prompt for consent,
so telemetry is off there unless a property explicitly enables it.
- **No content, ever.** We never send property values, element or test-plan
names, file paths, hostnames, IP addresses, target URLs, or any free text.
- **Built-in identifiers only.** Third-party and custom classes, functions,
and property keys are mapped to `other` or dropped, so no proprietary
package names leak.
- **ASF infrastructure.** Data would go to the Foundation's GDPR-compliant
Matomo instance, with IP anonymisation, not to any third party we run.
- **Transparent and auditable.** The payload schema is versioned and
documented, and the user can log the exact payload before it is sent.
## What we would collect
| Field | Type | Example | Why it is not personal data |
|---|---|---|---|
| `schema_version` | string | `1` | Constant, set by us. |
| `jmeter_version` | string | `5.6.3` | Public release identifier. |
| `run_mode` | enum | `gui`, `cli` | Coarse mode flag. |
| `os_family` | enum | `linux`, `windows`, `macos` | Family only; no build
number. |
| `java_runtime` | string | `Temurin 17` | Vendor and major version only. |
| `ui_locale` | string | `ru`, `de` | Language tag; no free text. |
| `testplan_size_bucket` | enum | `10-100` | Bucketed element count. |
| `thread_count_bucket` | enum | `100-1000` | Bucketed scale of the test. |
| `distributed` | bool | `false` | Whether remote testing is used. |
| `builtin_element_counts` | map | `{HTTPSamplerProxy: 12}` | Counts per
built-in class only. |
| `builtin_function_counts` | map | `{__counter: 3}` | Built-in functions
only. |
| `modified_property_keys` | set | `[HTTPSampler.method]` | Keys of changed
built-in properties only. Values are never sent; unknown keys are dropped. |
| `run_count` | int | `4` | Test runs in the session. |
## What we would never collect
Property values, element and test-plan names, file paths, hostnames, IP
addresses, target URLs, credentials, custom or third-party class names,
custom property keys, and any free text. The block list is enforced by an
allowlist of built-in identifiers, not by a denylist.
## Open questions for the community
1. Is opt-in telemetry something the project wants at all?
2. Does the schema above cover what would actually help us, and is anything
in it more than we need?
3. How should we count distinct installs for questions such as locale
adoption? A pseudonymous identifier is still personal data under GDPR, so
the options range from no stable identifier and approximate counts to a
rotating, salted per-day identifier. Input from anyone with GDPR experience
is welcome.
4. Where should the consent prompt live, and how do we make opting out
obvious?
If there is interest, the next steps are to refine the schema here, then
take the mechanism and the GDPR specifics to [email protected] for review,
and finally to VOTE if the change is significant.
Looking forward to your thoughts.
Thanks,
Vladimir
