Collaborate

Contribute to an open problem, co-author the next study, or run the testbed on your own bench and tell the project what you see.

1. Contribute to an open problem

The home page lists the hard ones: each is real, open and scoped so one strong engineer can own it. Pick one, open an issue on its repository to say you are on it, and send changes with a DCO sign-off (git commit -s). There is no CLA.

Every repository carries an AGENTS.md with its rules and a set of skills under .claude/skills/ (Rust patterns, gateway verification, experiment methodology, the zone-backend contract). They are written for people and for coding agents alike, so either can start from them. Getting started takes you from a clean machine to a measured experiment.

2. Co-author the next study

One paper, co-authored on this testbed. The project brings the running, reproducible testbed: the control plane, the manifests, frozen results for four hypotheses and the archives behind every figure. A partner brings domain depth the next study needs reviewed. The studies it is built for, each blocked on something concrete (roadmap):

Study	What it measures	Needs
`exp-011`	ADAS traffic over a slice: CARLA → ROS 2 → Autoware, closed loop	a Tier 2 GPU host
`exp-012`	A TSN gateway: 802.1Qbv/Qav + gPTP against today's queue-tree slices	TSN expertise
kernel timestamps	`SO_TIMESTAMPING` in place of userspace probing; re-run H1–H4	NIC and kernel timing expertise
`vxedge vehicle up`	A whole vehicle in software, end to end (the phase-3 gate)	SDV middleware: Kuksa/VSS, uProtocol, Zenoh

A good fit: you need a re-runnable testbed about as much as it needs your expertise; you already work with 5G/RAN, automotive E/E or an SDV consortium (Eclipse SDV, SOAFEE, 5GAA, COVESA); and you publish running code with your papers. Not on offer: an MoU, a platform integration or an open-ended partnership. The first collaboration is one paper.

3. Run it on your bench

One workstation is enough for Tier 1. Reproduce exp-001, compare your archive against the published manifest hash, and open an issue with what matched and what did not. A result that diverges on different hardware is exactly the evidence the parity ledger needs.

vxedge is a pre-release: the manifest schema and vxAPI may change between minor versions, so pin the release you test against. Published results are frozen and do not change.

Write in

hello@vxedge.dev, with one paragraph: the problem or question, what you would run, and what you would bring. Security reports go to security@vxedge.dev.

The code

Everything is at github.com/vxedge: the control plane (vxedge), measurement agents, OTA and telemetry services, the MCP server, SysML v2 models, the loadable registry, and every experiment manifest with its frozen summary. Code is Apache-2.0; docs, results, figures and models are CC BY 4.0.

How to cite

Generated from CITATION.cff:

@software{djaafri_vxedge_2026,
  author  = {Djaafri, Fouzi},
  title   = {vxedge: specification and results of an all-software
             SDV network-slicing testbed},
  version = {0.1.0},
  date    = {2026-07-13},
  url     = {https://vxedge.dev},
  license = {Apache-2.0 AND CC-BY-4.0}
}

Paper #1, the phase-1 dataset (H1/H3/H4), is in preparation for arXiv, with a citable, archived reproducibility bundle alongside it.