Working draft · version 0.1 · started September 2026

OpenDEX

An open, vendor-neutral specification for measuring Digital Employee Experience.

OpenDEX defines a shared taxonomy, precise metric definitions and a machine-readable schema for DEX — so telemetry produced by different tools can be described, exchanged and, eventually, benchmarked consistently, instead of every team inventing its own definition of "login time." It's a specification project, not a product, and it's still a working draft.

Scope

What OpenDEX is — and isn't

Stated twice: once as ambition, once as restraint.

It is deliberately not another DEX product, a DEX score owned by one company, a ranking of vendors, a replacement for platforms like Nexthink or Lakeside, a consulting framework, or — at this stage — a benchmarking company.

A standard that only one vendor controls isn't a standard anyone should trust.

From the original OpenDEX proposal

Positioning

Two different problems, easily confused

Vendor-neutral thinking about DEX is emerging from more than one direction. Most of it lives one layer up from OpenDEX: it asks how an organization should run a DEX practice — people, process, technology. That's a real question. It isn't this one.

The operating question
How should an organization run a DEX program?
The OpenDEX question
How should DEX measurements be described and exchanged?
Operating output
A discipline — roles, cadence, escalation
OpenDEX output
A machine-readable language for the data underneath it
Nearest analogy
An ITIL-style operating model
OpenDEX's analogy
OpenTelemetry, FOCUS, CloudEvents

Different problems, better solved together: an operating model can tell a team how to run DEX; it still needs a shared way to say what login time or packet loss actually means.

Architecture

Four pillars, held deliberately narrow

No maturity model, no RACI, no instructions on how to staff a team. Just four layers, in order.

i.

Taxonomy. What things count as DEX in the first place — a shared vocabulary across device, application, network, collaboration, security and sentiment.

ii.

Metric definitions. What each measurement precisely means: unit, start event, end event, exclusions, aggregation, sampling.

iii.

Data schema. How a measurement is represented on the wire, so it moves between systems without a hand-written translation layer.

device.login_time — example record
{
  "metric": "device.login_time",
  "value": 14.2,
  "unit": "seconds",
  "timestamp": "2026-09-01T09:14:02Z",
  "device": "anon-device-id",
  "os": "Windows 11"
}
iv.

Interoperability. Can two unrelated DEX platforms produce data a third system can consume without custom mapping? That's the real test.

Taxonomy v0.1

A first, deliberately small taxonomy

Roughly thirty to fifty metrics across six categories — not five hundred. A usable starting vocabulary matters more than early completeness.

Device · boot, login, CPU/memory pressure, disk health, uptime Application · launch time, crash rate, freeze, response time Network · latency, packet loss, DNS, Wi-Fi quality, VPN Collaboration · call quality, audio/video, meeting connectivity Security · AV/EDR status, firewall, encryption, patch state Sentiment · IT satisfaction, ease of resolution, friction

No universal "OpenDEX score" is defined at this stage, on purpose — collapsing this into one number is the fragmentation problem the specification exists to avoid solving too early.

Charter v0.1

Nine working principles

  1. Vendor neutral.
    No platform gets a deciding vote by default.
  2. Open specification.
    Published, versioned and changed in the open.
  3. Practitioner driven.
    Written by people who run DEX programs, not only people who sell tools for them.
  4. No vendor ranking.
    OpenDEX describes measurements. It never scores or ranks products.
  5. No mandatory scoring formula.
    It says what to measure, not how every organization must weight it.
  6. Interoperability over differentiation.
    The goal is comparable data, not a distinctive methodology.
  7. Transparent governance.
    Decisions and disagreements get recorded, not smoothed over.
  8. Evidence over opinion.
    Claims about what DEX should measure get tested, not just asserted.
  9. Privacy by design.
    No raw employee data, no identifiers, aggregation thresholds from day one.

Year one

Four movements, September 2026 – August 2027

Built to hold its shape regardless of how quickly vendors, practitioners or data show up — each movement works either way.

September – November 2026

One — Foundation

Publish the OpenDEX Charter v0.1 and an initial governance draft. Stand up the specification repository. Draft the first taxonomy. Begin a biweekly Working Note documenting open questions in public.

December 2026 – February 2027

Two — Community

Recruit five to ten Founding Contributors. Open four working groups. Run the first OpenDEX Roundtable and publish what came out of it.

March – May 2027

Three — Validation

Ship a small reference collector. Run an interoperability challenge across independent and synthetic data sources. Launch a small benchmark pilot and publish distributions, never company-level scores.

June – August 2027

Four — Institutionalization

Publish OpenDEX v0.9 with taxonomy, schema, reference implementation and governance in place. Form a Technical Council with no single-company majority. Release OpenDEX v1.0.

Target: OpenDEX 1.0, by the end of August 2027.

Get involved

Who this is for, starting now

OpenDEX begins with a small founding group, not a follower count. The measure of a good first year is the number of independent people who materially shaped the specification.

The Founding Practitioner track

New practitioners join with a defined sixty-to-ninety-day charter, not an immediate title: recruit a handful of peers, run practitioner interviews, review the taxonomy, produce real use cases, help host a roundtable. Strong contribution in that window is how leadership roles get decided.

SIG 1Measurement — what should be measured, and why.

SIG 2Schema — how a measurement gets represented.

SIG 3Benchmarking — how organizations can be compared safely.

SIG 4Practitioner Experience — what DEX means operationally, day to day.

Every two weeks, a short Working Note takes up one open question — instead of a polished announcement — so the paper trail of an unfinished specification stays honest and visible.

Governance & IP

An initiative, not a product — nobody owns it, nothing gets divided

OpenDEX has no founders and no equity. All early participants share the same standing: contributor. "Founding contributor" describes when you joined, never what you own.

No founders

Participation is by standing, never by stake. No one joins as an owner, because there is nothing to own.

No equity

No shares, no paid seats, no ROI. The only contribution currency is skill and name.

Not Anakage's product

Proposed by Anakage, then deliberately handed to independent, community-run governance.

OpenDEX began as a proposal published by Anakage and is deliberately moving toward independent, community-run governance — see the roadmap above. Anakage neither owns the specification nor controls its future: a contribution to OpenDEX is a contribution to the community's shared language, not to any company's product.

No interest category, single company, or individual gets a deciding vote by default — and no platform can retrospectively own the standard it helped write.

From the original OpenDEX proposal

If a contributor from Company A comes in

You join as yourself. Your employer gains nothing they didn't already have the right to: contributing doesn't transfer ownership of your employer's IP, doesn't give Company A a seat at a special table, and doesn't let the specification become a spec-for-hire. What it does is put your name on a public record of work that the whole community can build on.

Who owns my contribution?
No one exclusively. For the specification, the working group holds it; for implementations, the open source licenses in each file govern it.
Who owns the OpenDEX name?
Eventually, a neutral entity — the Community Specification framework is designed so a single founding organization can host the effort while ownership transfers to participant governance.
Can my employer contribute too?
Yes. You simply confirm you're legally entitled to make the grants on the IP you bring — including, where applicable, on behalf of your employer.
Is any of this investment or a stake?
No. There are no shares, no seats by payment, no ROI. Contribution is good-faith, and governance remains consensus-based.

In other words: a contributor's capital is their skill and their name — never a claim on the project.

Projected legal instruments

Open, model legal terms OpenDEX plans to adopt at v0.1, quoted verbatim so the intent is unambiguous. Both instruments were designed for exactly this position — shared standards that no single company can quietly own.

Community Specification framework Joint Development Foundation · SPDX Community-Spec-1.0
  1. Governance Policy 1.0 · §3.2 · Lack of dominance

    The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints.

  2. Governance Policy 1.0 · §3.1 · Openness

    Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation.

  3. License 1.0 · §2.1 · Patent grant (excerpt)

    Contributor grants Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims included the Approved Specification that are within Scope for Licensee's Implementation of the Approved Specification, except for those patent claims Contributor excludes by a written notice ...

  4. Contributor License Agreement · Employer representation

    I represent that I am legally entitled to make the grants set forth in the documents above. If my employer(s) has rights to intellectual property that may be infringed by the materials developed by this Working Group, I represent that I have received permission to enter these agreements on behalf of that employer.

Developer Certificate of Origin Version 1.1 · as used by the Linux kernel
  1. Clause (d) · The public record

    I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

Quoted from the model documents above; OpenDEX will adopt its own versions at v0.1. This page is not legal advice — Governance and IP docs are a draft item on the year-one roadmap.

Source

Specification repository

The next artifact being built, deliberately after the charter and first taxonomy draft are solid rather than before.

● Not yet public — in progress

The repository will hold the taxonomy, schema, examples, a reference implementation, and the governance documents below. It goes live with the v0.1 release, with issues and pull requests open from day one.

specification/ · examples/ · reference-implementation/ · governance/ · CONTRIBUTING.md · GOVERNANCE.md

This button will link straight to it once it's public. For now, the fastest way in is the contributor track below.

Join

Become a founding contributor

Practitioners, engineers, researchers and vendor-side people are all useful here — especially anyone willing to argue with a metric definition.

Tell us what you measure today, what you don't trust, and what you wish a specification like this got right. That's the whole application.

join@opendex.dev is a placeholder — point it at a real, monitored inbox before this page goes live.