Khronosdotorg: the markdown files that back the Khronos.org resource pages

Two markdown files per technology, split by who owns them

The repository holds a collection of resources for all of the Khronos Working Groups. The nominal structure is small and easy to grasp: each technology has two files, bluebox.md and resources.md.

The split between them matters, because ownership differs. Each Working Group maintains its own bluebox.md, so the descriptive part of each page is owned by the group that owns the specification. The resources.md file is built and maintained with help from the Khronos Group Community, which the documentation addresses directly as you.

That division is the point of the project. Technical accuracy for a specification comes from the group that writes it, while the surrounding links, tutorials, samples and third party material are a broader job that the group explicitly delegates outward.

For a reader in a hurry, the README lists the technologies with links into their resource pages: KTX, OpenCL, OpenGL ES, OpenVG, OpenVX and SPIRV. It also marks OpenMAX, OpenWF and WebCL under a heading that reads Not in active development, each with its own resources link. Those two lists, and the directory layout beneath api/, are the fastest way to understand what this repository contains.

How the page structure maps onto the api directory

Based on the repository layout, the site content is organised by technology under the api directory, with one folder per API family. The README links point at paths of that shape, for example api/ktx/resources.md, api/opengles/resources.md and api/spir/resources.md.

One entry departs from the pattern. OpenCL has two files listed rather than one: a resources.md and a separate community-resources.md. Whatever the split means internally, it is the one technology where the community material is kept in its own file rather than folded into the main resources page, and that is worth knowing before you add a link to the wrong one.

The rest of the tree supports the content rather than the APIs. At the top level there is README.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md for participation rules, a LICENSES/ directory, and REUSE.toml. A legal/ directory sits alongside the api/ tree, and .github/ is present for the workflows that would drive a static site build from these files. The primary language of the repository is listed as HTML, which is consistent with a set of pages destined for a website.

None of this repository is a specification document. There is no shader language source, no header file, and no loader. It is the editable text of a website, one API folder at a time.

Contributing a link fix: the workflow the project asks for

The project gives contributors two ways in, and it asks for both pull requests on bluebox.md and resources.md files.

If you notice a missing link, or find a current link that is out of date or broken, the documentation says to let the group know. You may either create a pull request, or contact the project directly through the contact page linked from the README.

There are no build steps, package managers or toolchain commands to run here, and the documentation does not describe a local preview server. The work is editing markdown in the right folder for the technology, then opening a pull request against the repository. Because there is no documented local preview, the review of a change happens on the site rather than on your machine, which is a meaningful difference from a typical code contribution and worth knowing before you start.

The exact file to edit is not always obvious from the README alone. For OpenCL, the resources page and the community resources page are separate files, and the bluebox.md for a technology sits alongside the resources.md in the same api folder. The Working Group that owns a technology maintains its own bluebox.md, so a change to the descriptive copy of a specification may need to come from that group rather than from a community pull request.

Why the bluebox stays with the Working Group

The reason for the split between bluebox.md and resources.md is visible in the ownership statement, and it is a reasonable design rather than an accident.

A bluebox is the descriptive block that identifies a technology on the site: what it is, what it is for, and how it relates to the rest of the group. That text changes when the specification changes, and the Working Group knows that better than anyone outside it. Letting anyone else rewrite it would create a churn problem, so the group keeps ownership.

The resources.md file is different in kind. It is a curated set of links that grows constantly as new tutorials, samples, tools and articles appear and old ones rot. No Working Group can watch that space continuously, so the group asks the community to do it. That is a low-risk delegation because a resource link is additive and its correctness is checkable.

The practical effect for an adopter is that a pull request touching resources.md is likely to be reviewed quickly, since the change is narrow, while a pull request touching a bluebox.md may need the Working Group to weigh in. If you want to correct a specification description, going through the contact page is the path the documentation points at.

The technologies marked as not in active development

The README separates the technology list into two groups. KTX, OpenCL, OpenGL ES, OpenVG, OpenVX and SPIRV are listed first. OpenMAX, OpenWF and WebCL appear under the heading Not in active development.

That label applies to the technology, not to the repository. The repository is not archived and the last push was on 2026-09-17. What the heading tells you is that the working group behind those three APIs is no longer pushing the specification forward, so the resource pages for them are historical documents rather than living ones.

That distinction matters for two kinds of reader. Someone looking for current material on OpenGL ES or SPIRV is in the right place. Someone looking for guidance on OpenWF or WebCL should understand they are looking at a body of knowledge that has stopped changing, and that community links to it will decay faster than links to active technologies.

It also explains why the repository keeps those pages at all. A standard body with a stopped working group still has users, and the archived link lists still help the people who depend on it. Keeping the files costs nothing and preserves a record of where the content came from.

Licensing that the repository page cannot answer

The repository page lists the licence as unknown, which is an honest statement rather than an oversight you should paper over in your own review.

What the repository does contain is a LICENSES/ directory and a REUSE.toml file at the top level, alongside a legal/ directory and CODE_OF_CONDUCT.md. The presence of a REUSE configuration indicates that the licensing of individual files is tracked inside the repository, which is the standard way to handle a collection where different files may carry different terms.

Because the repository is a collection of pages rather than a single coherent code artifact, per file licensing is a sensible arrangement. It also means that reading the repository page alone tells you very little, and you need to look inside LICENSES/ and REUSE.toml for the actual terms before reusing any of the text. Anyone planning to copy the wording of a bluebox or resources page into their own documentation should check those files and decide for themselves, rather than take the permissive expectation from a project that is mostly open standards work.

The repository also carries no GitHub releases. Changes are made through pull requests directly on the default branch, main, so the commit history is the change log.

Editorial conclusion

Adopt Khronosdotorg if your job involves keeping the Khronos.org technology listings accurate, because the pages on the live site are backed by the markdown files held here and pull requests from outside the Working Groups are explicitly invited. Do not treat it as a source of API code or a specification, since it contains neither. Before your first contribution, read CONTRIBUTING.md and CODE_OF_CONDUCT.md, check whether the technology you want to touch sits under the api directory for an active Working Group or one of the entries listed as not in active development, and confirm the licensing situation in LICENSES/ and REUSE.toml, since the repository page lists the licence as unknown.

Frequently asked questions

Official sources

1. Issues
2. KhronosGroup/Khronosdotorg on GitHub
3. Project website
4. README