At some point after a project ships, somebody asks for the code. Perhaps a festival wants to restage the piece, perhaps a student wants to learn from it, perhaps you want it to still exist in five years when the laptop it ran on has died.
Publishing it is the cheapest form of preservation available. It is also not simply a matter of pushing a repository, and the mistakes are tedious to undo. This is the order of operations that avoids most of them.
Step 1: Work out how many licences you actually need
This is the step most people get wrong, because they reach for one licence and apply it to everything.
A creative-technology project usually contains three legally distinct kinds of thing:
The code. Software licences — MIT, BSD, Apache 2.0, GPL — are built for this and nothing else. The practical question is whether you mind someone using your code in a closed-source product. If you don’t, MIT or Apache 2.0. If you do, GPL or AGPL. Apache 2.0 differs from MIT chiefly in granting an explicit patent licence, which matters to anyone using your work inside a company.
The hardware. If there are schematics, PCB layouts or enclosure files, software licences fit badly — they are written about source code and binaries, concepts that do not map cleanly onto a fabricated object. The CERN Open Hardware Licence v2 exists for exactly this, in three variants: S (strongly reciprocal), W (weakly reciprocal) and P (permissive).
The artwork. Your shader output, sounds, 3D models, textures and the piece’s documentation are creative works, not software. Creative Commons licences are the right instrument, and the choice that matters is whether you allow commercial use and derivatives. CC BY-SA keeps derivatives open; CC BY-NC-SA prevents commercial reuse but is incompatible with a lot of collaborative reuse. Note that Creative Commons explicitly advises against using CC licences for software.
So a typical installation repository holds an MIT-licensed src/, a CERN-OHL-W hardware/, and CC BY-SA assets. Say so, per directory.
Step 2: Find the things that should not ship
Do this before the first public push, because git remembers. A secret committed and then deleted is still in the history, and rewriting published history is a far worse afternoon than checking now.
Look for:
- API keys and tokens — anything for a weather service, a mapping provider, an LLM, a cloud bucket. Move them to environment variables and commit a
.env.examplewith the keys named and the values blank. - Venue and network details — hardcoded IP addresses, Wi-Fi credentials, the gallery’s VPN config, DMX universe addresses tied to a specific rig.
- Client and commission material — contracts, fee schedules, floor plans, correspondence. These often end up in a project folder and get committed wholesale.
- Other people’s assets — licensed fonts, stock audio, purchased models. A font licence that allowed you to use it in a commission almost never allows redistribution.
- Personal data — visitor logs, camera captures, anything a body-tracking piece recorded during testing. This is the one with legal consequences beyond embarrassment.
Write the .gitignore first, then audit what is already tracked with git ls-files.
Step 3: Write the README for a stranger, not for yourself
The failure mode is a README that documents the project’s identity rather than its operation. Beautiful screenshot, artist statement, no indication of how to run it.
A README that gets a project used answers, in roughly this order:
- What this is, in two sentences, including what it looked like when it ran.
- What it needs — specific versions. “Python 3.11, TouchDesigner 2023.11, an RP2040 board” beats “Python and TouchDesigner”.
- How to run it — the literal commands, in order, from a fresh clone.
- What hardware it expects, and what it does when that hardware is absent. This one is decisive. A project that crashes without its sensor attached cannot be explored by anyone who does not own the sensor; a project that falls back to mouse input or recorded data can be explored by everybody.
- Which licence applies to which directory.
- What is deliberately missing, and why — the commissioned audio you cannot redistribute, the calibration file specific to one venue.
That last point buys more goodwill than anything else in the file. A stranger who knows what is absent can decide whether the project is useful to them. A stranger who discovers it after an hour of debugging concludes the project is broken.
Step 4: Make it citable, and make it survive you
A GitHub repository is not an archive. It is a hosted service tied to an account you might stop paying attention to.
Two cheap measures:
- Add a
CITATION.cfffile. GitHub reads it and generates a citation box, which means curators, researchers and students credit the work correctly without having to ask you how. - Deposit a release in Zenodo. Connect the repository, cut a tagged release, and Zenodo archives a snapshot and mints a DOI. The DOI resolves whether or not the GitHub repository still exists, and it gives a catalogue entry something permanent to point at.
For machine-readable licensing across a mixed repository, the REUSE specification and SPDX identifiers let you tag licences per file rather than relying on a human reading your README correctly.
Step 5: Decide what you are promising
Publishing is not a commitment to maintain. Say which it is, in one line in the README, and you will save yourself considerable guilt.
“This is archived as-is and will not be updated” is a complete and respectable position. So is “issues welcome, no guarantees on response time.” What generates resentment on both sides is silence, where a user assumes support exists and an artist feels obliged to provide it.
The short version
Audit for secrets and third-party assets, then licence code and hardware and art separately, then write the README for somebody who has never met you, then mint a DOI so it outlives the platform. An afternoon’s work, and it is the difference between a project that gets restaged and one that quietly stops existing when a hard drive fails.