Telemetry Ethics For Open Source Assistants Implementation Guide: practical systems guide

Open source AI assistants collect usage data to improve models and fix bugs, but most users never read the consent forms. When you ship an assistant that runs locally or on-premise, you inherit the ethical obligation to be transparent about what you send, why you send it, and how users can opt out without breaking core functionality.

This guide walks through practical implementation patterns for telemetry systems that respect user agency while still giving you the signals needed to improve your product. We'll cover consent mechanisms, data minimization strategies, and the architectural decisions that make transparency verifiable rather than theoretical.

Why telemetry ethics matter more for assistants than traditional SaaS

Most SaaS products phone home constantly and users accept this as the price of cloud hosting. AI coding assistants are different. Developers run them against proprietary codebases, internal APIs, and architecture patterns that constitute competitive advantages. A single telemetry event might leak:

• Module names that reveal unannounced products
• API endpoint structures that expose security boundaries
• Error messages containing customer identifiers or internal tooling names
• Code patterns unique to your company's domain

The risk compounds when assistants have deep filesystem access. Traditional analytics might log "user clicked button X" but assistant telemetry could inadvertently capture "assistant read file `/internal/acquisition-targets.md` and generated code calling `stripe.charge(amount=50000000)`".

Self-hosted and open source assistants can't hide behind "trust us" privacy policies. Users can read the source, inspect network traffic, and fork your code if they don't like what they find. Your telemetry implementation becomes part of your user contract.

Design for explicit consent, not implicit acceptance

The standard software pattern—show a modal on first launch asking users to "help improve the product"—optimizes for opt-in rates rather than informed consent. Better implementations give users control before any data leaves their machine.

Goatfied's approach requires explicit `telemetry: enabled` in the config file before sending any events. The first-run experience explains what specific events we collect (compilation success/failure, lint rule matches, retry counts) and links to the full schema in our docs. Users who skip the config choice run in telemetry-off mode by default.

Key implementation details:

• Store the consent decision locally, never server-side. Users should be able to audit telemetry state with `cat ~/.goatfied/config.toml` rather than logging into a web dashboard.
• Provide runtime inspection: a `goatfied telemetry status` command that shows the current setting and lists recent events queued for transmission.
• Support temporary opt-out: `GOATFIED_NO_TELEMETRY=1 goatfied edit` for one-off sessions where users are working on particularly sensitive code.

This adds friction but aligns incentives correctly. If your product value depends on coercive data collection, you have a product problem.

Minimize data collection scope through architectural constraints

The most ethical telemetry is the data you never collect. This requires upstream architectural decisions, not just filtering before transmission.

In Goatfied's agent loop (plan → constrain → edit → validate → retry), we instrument outcomes rather than inputs. We log:

• Whether the generated edit compiled successfully (boolean)
• Which lint rules fired during validation (rule IDs only, not the actual code)
• Retry count before success or abandonment (integer)
• Whether unit tests passed after edit (boolean + test framework identifier)

We explicitly *don't* log:

• File paths or names (except file extensions for language detection)
• Variable names, function signatures, or any code content
• Error message text beyond categorized error codes
• User identifiers beyond an anonymous installation UUID

This architectural constraint means our telemetry pipeline can't accidentally leak sensitive data because it never enters the pipeline. The code that generates telemetry events doesn't have access to the original source being edited.

For managed Goatfied Cloud, we add lightweight job telemetry (queue depth, runner utilization) but keep the same content constraints. The compilation gating that ensures code compiles before commit creates a natural boundary: we track success/failure of each gate without seeing what code triggered it.

Make telemetry infrastructure auditable

Open sourcing your assistant isn't enough if the telemetry endpoint is a black box. Implement patterns that let security-conscious users verify your claims:

**Schema publication**: Maintain a versioned JSON schema for every telemetry event type in your documentation. Users can write their own analysis tools or third-party proxies that validate outbound events match published schemas.

**Local logging**: Write a copy of transmitted events to `~/.goatfied/telemetry.log` with timestamps. Users should never wonder "did that just send something?" because they can `tail -f` the log.

**Proxy support**: Honor `HTTPS_PROXY` and allow users to route telemetry through inspection tools like `mitmproxy`. Some teams want to run assistants on airgapped networks with occasional telemetry batch uploads after manual review.

**Differential privacy where possible**: For numeric aggregate metrics (like "how many retries before success"), add calibrated noise before transmission. Individual events become less precise but population-level statistics remain useful.

Handle edge cases without dark patterns

Real-world telemetry systems encounter unusual states: network timeouts, disk full errors, users who toggle consent mid-session. How you handle these reveals your actual ethics.

**Don't queue indefinitely**: If telemetry transmission fails, retry with exponential backoff but cap the queue at 1000 events. After that, drop the oldest events rather than filling disk. Users with network policies that block telemetry shouldn't end up with gigabytes of queued data.

**Allow selective opt-in**: Some users want to send crash reports but not usage analytics. Support granular categories rather than all-or-nothing.

**Clear data on opt-out**: When users flip `telemetry: enabled` to `false`, immediately purge the local queue. Don't try to "flush remaining events" first—that's exactly the behavior that erodes trust.

**Document retention**: Be specific about server-side retention. Goatfied keeps aggregate metrics indefinitely but individual events for 90 days before deletion. Users who request data export get JSON dumps of events tied to their installation UUID.

Build trust through consistency

The hardest part of telemetry ethics isn't the initial implementation—it's maintaining discipline as your product evolves. Resist the pressure to "just add this one extra field" when debugging production issues. Every expansion of telemetry scope should trigger the same rigor as the initial design review.

When we added support for validating generated code against integration tests, we logged pass/fail outcomes but not which APIs the tests exercised. That made debugging harder, but it kept us aligned with our architectural constraint: we instrument outcomes, not inputs.

Developers are better than most users at detecting mismatches between promises and behavior. Shipping an open source assistant with ethical telemetry isn't charity—it's recognizing that your users have the technical skills to verify your claims and the leverage to fork your project if you lie.

Related reading

• [Goatfied vs Cursor vs GitHub Copilot: a benchmark across 50 real PR tasks](/blog/goatfied-vs-cursor-vs-github-copilot-benchmark-50-pr-tasks)
• [The Goatfied agent loop: how we ship code that actually compiles first try](/blog/goatfied-agent-loop-compiles-first-try)