The project, licensing and contributing

The questions that are about the project rather than the software: what the licence lets you do, how finished this is, how to get a change in, and how to report something wrong. Most of these have short answers, and two of them — production readiness and security reporting — have answers that are deliberately unflattering.

What licence is it under?

Why

Two properties of that licence are worth knowing before the commercial question, because they explain the choice. It is a strong copyleft licence: if you convey the program or a work based on it, whoever receives it must get the same freedoms you had, including the source. And it is specifically GPLv3 with section 13 added — the Remote Network Interaction clause — which exists for exactly one case, software whose primary use is being a server.

That choice was made against the architecture rather than for ideological reasons. dev3d is designed to be operated as a server: the console is a browser view onto a local process that holds the provider keys, the database, the workspaces and the plugin host. Under a permissive licence, someone could take it, modify it, host the modified version as a service, and never publish a line of what they changed — and because users never receive a binary, there would be no distribution event to hang an obligation on. An ordinary GPL would not close that either, because its obligations attach to conveying a copy. Section 13 is the one standard clause that speaks to hosting, so it is the one that was picked.

Two things the licence does not require, which people often assume it does. It does not require you to contribute anything back to this project: the obligation is source for your version, offered to your users, and a tarball behind a URL in your own console satisfies it. And it does not apply to a plugin you write, provided you are using the documented plugin interface rather than copying dev3d's source into your plugin; the plugin's licence is your choice and the marketplace shows whatever the manifest declares. License walks through section 13 in plain terms and lists the cases in a table.

Can I use it at work, or commercially?

Why

The only thing the licence constrains is what you do with a modified version that other people reach over a network. Run it unmodified and section 13 asks nothing of you at all, however many people use it and however much you charge. Modify it and keep the modification to yourself, with no remote users, and again nothing is asked. Modify it and let others use your modified version over a network, and you must prominently offer those users the Corresponding Source of your version at no charge — prominently meaning a route a user can actually find, and "your version" meaning your version rather than upstream's repository or a diff against it.

For a plugin author the question is separate, and the answer is the same in practice. A plugin is your own work; the host hands it a narrow object with five members — the manifest, the settings, a logger, a tool-registration function and an event subscriber — and does not hand over the router, the store, the run engine or the office state. Everything a declarative plugin contributes is data the host validates and acts on itself, so no code of yours runs at all. Declare the licence honestly in the manifest, because the listing shows it as a badge and the site falls back to a default when the field is missing — a default that is not your choice.

Is it production-ready?

Why

Take what is proven first, because it is more than a 1.0 usually gets. The verification is layered and each layer covers something the others cannot: engine tests that drive real runs against a scripted provider and a scratch workspace, proving that files land on disk and that budget halts work; a smoke harness that drives a running server as a real client over the socket, checking office state on connect, streaming deltas, replay from the persisted log and the refusal paths; a web harness that drives the client store with one synthetic frame per event variant, because a typecheck cannot prove a reducer correct; and a failure-path suite that asserts the degradations rather than assuming them — an unusable database path still yielding a working non-persistent store, a missing skills directory yielding an empty catalogue, a malformed skill file skipped with its reason instead of taking the boot down. Verification lists what each suite proves and what it cannot.

Now the part that decides the question. Nothing has been tested adversarially: no suite attempts a sandbox escape, a hostile plugin or a concurrency race, and the confinement and budget gaps that exist were found by reading the source rather than by a failing test. That is a statement about the evidence as much as about the code. Specifically: the orchestrator has no authentication and is intended for the loopback interface, and everything on the socket — hiring, firing, changing a floor's budget, installing a plugin, submitting work — is available to anything that can open a connection. A cross-origin write from a browser is refused with a 403, which closes the drive-by case and not the local one. Eight of the fifteen built-in tools are confined to the workspace; run_shell and git are confined only by their working directory and gated only by an approval round trip that a single environment variable can skip; and plugin-supplied tools and MCP tools are not confined by the host at all. The hard budget ceiling is checked per stage, so a long stage can overshoot it.

The measured conclusion, which is the one to act on: this is trusted-network software for a machine you control, running projects you have chosen to point it at. That is a real and useful category — plenty of tools are exactly that — but it is not the category "safe to expose", and the honest answer to "is it production-ready" depends entirely on which of those you meant. Known gaps is written precisely so that you can make that call before a run makes it for you.

How do I contribute?

Why

Start with the constraint that shapes every contribution: Node 24 is a hard floor. The suites execute TypeScript directly through the built-in test runner, and persistence is built on the unflagged SQLite module — so on an older runtime the server may still start, which is the worst case, because it means an untested build. If a suite fails instantly with a module or type-stripping error, check the runtime version before anything else.

The project's own contributor document is the repository's docs/development.md, and it is the thing to read before writing code: the repository layout with what each directory owns, the verification commands with what each suite covers, the pre-release checklist in order, and the asset pipeline's ordering constraint — every Blender script resets the scene, so running them out of order replaces the furnished office with a bare shell rather than re-exporting what is there. It also states the environment's own trap plainly: some tests need child processes with piped streams and report themselves skipped where a sandbox blocks that, which is why a suite run can legitimately show skips and why a skip is neither a failure nor coverage.

Two habits make a contribution land more easily, and both come from how this documentation was written. First, verify a claim against the source rather than against the README — that file is edited as the project moves and is stale in several places, and every project of this age has that problem. Second, where you correct something, say that it was corrected; the documentation here states corrections as corrections rather than folding them quietly into the prose, on the grounds that a set which silently revises itself teaches a reader to trust it less.

What the project is least likely to accept is a change that trades honesty for polish: a limit quietly softened, a default quoted from memory, or a behaviour described as working when it is aspirational. The awkward parts of this site are deliberate, and Verification explains the standard each claim is held to.

Where does the source live, and is there a commercial offering?

Why

Being precise about what is and is not available is more useful than a reassuring sentence, so here it is. The software is free of charge and self-hosted: you run the orchestrator, you pay the model vendors directly, and nothing in the architecture routes through a service operated by this project. This site serves documentation and a plugin marketplace; it does not run offices for anyone, and it has no visibility into yours. The marketplace stores plugin listings and serves bundles and a catalog document, and that is the whole of it.

What the repository contains is the entire thing: the shared contracts package that both the orchestrator and the console compile against, the server with its engine, router, skills, tools, plugins, store and server layers, the web application, the shipped example plugins, the skill catalogue, the Blender scripts that build the office asset, and the verification harnesses. Nothing is held back for a paid edition, and that is not a marketing position — the licence makes withholding it pointless, since a hosted fork would owe its users the same source anyway.

For commercial questions that are not about the software — licensing dev3d differently, embedding it in a proprietary product, or an internal policy that simply forbids AGPL — the route is the contact form, and the absence of a commercial page is not an absence of an answer. What does not exist is a support contract, a service level, or anybody on call: this is a project you adopt rather than procure, and the honest expectation is that you read the design thesis and Known gaps before you decide, because those two pages are the closest thing to due diligence that exists.

Can I self-host the marketplace?

Why

The host-side contract is genuinely small, and understanding it is what makes self-hosting a real option rather than a theoretical one. The catalog document is parsed by hand, so its shape is strict: a format version, a name, an optional homepage, and a plugins array. Each entry carries a complete plugin manifest — validated by the same validator that validates a plugin on disk — plus a download URL and an optional sha256. The host matches on the manifest id, compares the version to decide whether an update is on offer, and verifies the checksum before unpacking anything. A download URL may be relative, resolved against the catalog's own URL, so the document and the bundles can sit together on any static host.

What that leaves you to build if you want your own marketplace is the producing side: somewhere to put bundles, a way to generate the document, and whatever review or policy you want in front of it. That is not trivial, and it is the part this site exists to provide for the public case. It is also worth noting what the host does not require: there is no registration, no token, no handshake between publisher and host, and no notion of an account on the marketplace side.

How do I report a security issue?

Why

Saying this plainly is more useful than inventing a process, so here is the real position. The repository carries no SECURITY.md and no contribution guide; the documented routes are the repository's development document for contributors and the contact form on this site. If you are reporting something about a plugin — a bundle that does something its manifest does not disclose, or one that ships a credential — say the plugin id and the version, and the marketplace policy's own guidance applies: both are shown on the listing, the version matters because the report is about specific bytes, and a report about a malicious bundle is acted on first and discussed afterwards. Including the sha256 pins your report to exactly what you downloaded.

For a vulnerability in the software itself, the shape of a useful report is the same as anywhere: what you did, what happened, what you expected, and the version — 1.0.0 for this release, with a checkout ahead of the tag legitimately differing. A report that names the file and the behaviour is worth far more than one that names a category, and this documentation's own standard is the reason: every claim on this site is meant to be traceable to a file, so a report that contradicts a page here is actionable in a way that "seems insecure" is not.

Still unanswered?

• Contact — licensing questions, documentation errors, plugin reports and security reports all arrive here.
• About — the project in one page, including where the source is.
• Documentation — the whole manual, grouped by section.
• License — the AGPL in plain terms, with the common cases in a table.
• Known gaps — what is unfinished, what is a deliberate trade, and what nobody has verified.
• Verification — what has been proven, and what each suite cannot prove.