Last time we built hue-forge together - a real little tool with a friendly front door, sensible defaults, a shareable link and an HTML tag - and I ended the episode with a nagging feeling I couldn't shake. The tool lived on my machine, in my head, mine. And I asked you: what happens when you don't just let people use your thing, but let them crack it open, change it, add the harmony you forgot, fix the bug you never noticed, and hand their improvements back to you and everyone else? Allez, that's today. That messier, more generous, more alive way of making things has a name, and you've heard it a thousand times: open source. But I don't want to talk about it like a licence lawyer. I want to show you what it actually feels like to put your creative code into the commons and let it grow legs :-).
Here's the honest thing nobody tells you when you start. Open source is barely about code. It's about manners again - the same lesson as episode 140, except now the manners are pointed at a whole crowd of strangers instead of one. How do they find your work? Are they allowed to use it? Do they know how to help? What happens when someone hands you a gift you didn't ask for? Get those right and a sketch you made on a Tuesday evening can end up in projects on the other side of the world. Get them wrong and your lovely tool sits in a folder forever. So let's get them right.
Back in episode 136 we got comfortable with git - commits, branches, a project that remembers its own history. Open source is just the next tiny step: you take that local history and you push it somewhere public so other people can see it. For most of us that's a hosting site like GitHub or GitLab, but the mechanics are the same everywhere. You make a repository, you point your local project at it, and you push.
# turn hue-forge from a private folder into something the world can see.
# (episode 136 got us to `git init` and commits - this is just the next step)
cd hue-forge
git init # if you hadn't already
git add .
git commit -m "hue-forge: seeded palette generator"
# then, after making an empty repo on the host, point at it and push:
git remote add origin https://github.com/yourname/hue-forge.git
git push -u origin main
That's genuinely it for the technical part of going public. The push is the easy bit. What matters far more is everything a visitor sees the moment they land - because most of them decide in about ten seconds whether your project is worth their evening, and they decide it without reading a single line of your actual code.
Here's a thing that surprised me the first time someone explained it: if you put code on the internet with no licence at all, the legal default in most places is that nobody is allowed to use it. Not "free for all" - the opposite. Your generous gesture of sharing means nothing, because you never actually said "yes, you may." A licence is you saying yes, in writing, in a way people can trust. It's the invitation card on the front door.
For creative code, my go-to is the MIT licence, because it's short, it's kind, and it basically says "do whatever you like, just keep my name on it, and don't sue me if it breaks." You drop it in a file called LICENSE at the root of your project.
MIT License
Copyright (c) 2026 yourname
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...
See how much that little file does? Those few paragraphs are the difference between a stranger nervously wondering "am I allowed?" and a stranger happily building your palette tool into their own project. Makes sense, right? And it links straight back to that license field we already put in package.json back in episode 140 - now the field and the actual file agree with each other, which is exactly the honesty a package promises.
{
"name": "hue-forge",
"version": "1.0.0",
"description": "Seeded, harmonious colour palettes for the browser.",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/yourname/hue-forge.git"
},
"keywords": ["creative-coding", "generative", "color", "palette"]
}
That new repository field is another small kindness - it tells the world (and package tools) exactly where the source lives, so anyone who installs your tool can find their way home to the code, the issues, the whole conversation.
Now, creative coders have a lovely wrinkle here that plain-software people don't: we make two things at once. There's the code, and there's the output - the actual image, the pattern, the palette. And an MIT licence on your code says nothing about the picture it produced. So a lot of us reach for a second kind of licence for the art itself: Creative Commons. It's the same spirit - "here, use it, just credit me" - but aimed at creative work instead of source files.
The really neat trick is that you can bake that permission into the artwork itself. Remember when we exported to SVG back in episode 29? SVG is just text, which means we can slip a little metadata block right inside the file that travels with it forever.
// embed a Creative Commons notice INSIDE the SVG, so the licence travels
// with the artwork wherever it goes - no separate readme needed.
function svgWithLicense(shapesMarkup, author) {
return `
Generated art by ${author}.
Licensed under CC BY 4.0 - use freely, just credit the maker.
${shapesMarkup}
`;
}
I love this because it solves a real problem quietly. Art gets separated from its source all the time - someone saves your image, re-posts it, sends it to a friend - and by the time it's three shares deep, nobody remembers where it came from or whether they can use it. Bake the licence into the file and the answer travels with the picture. The art carries its own invitation. Alee, that's the kind of small, permanent thoughtfulness that makes the commons actually work.
We touched this at the very end of episode 140 - the README is the front door - but for an open project it does double duty. It has to sell the tool to a user in the first ten seconds, and it has to reassure a would-be contributor that helping won't be a nightmare. The trick is the same as always: lead with the shortest path to a smile, then let the details wait below for the people who fall in love.
# hue-forge
Seeded, harmonious colour palettes for the browser. Same seed in, same
palette out, every time.
import { createForge } from "hue-forge";
const forge = createForge({ seed: "antwerp", harmony: "triadic" });
forge.palette(); // -> ["hsl(...)", "hsl(...)", ...]
## Why
Because picking colours that go together by hand is hard, and a seed you can
share is magic.
## Contributing
Love a new harmony rule? A dark-mode toggle? Open an issue or send a pull
request - see CONTRIBUTING.md. First-timers very welcome :-)
That last little line does more heavy lifting than the whole rest of the file. "First-timers very welcome" is you holding the door open. So many people have a fix or an idea and never share it because they assume the maintainer is some intimidating genius who'll roll their eyes at them. A single warm sentence tells them otherwise. I've had people tell me that one line was the reason they sent their very first pull request ever - and honestly, that feels better than any amount of stars.
If the README is the front door, CONTRIBUTING.md is the little map you hand someone once they're inside and asking "okay, how do I actually help?" It doesn't need to be long. It needs to answer the three questions every nervous contributor has: how do I run this, how do I not break it, and how do I send my change back?
# Contributing to hue-forge
Thanks for wanting to help! Here's the whole dance:
1. Fork the repo and clone your fork.
2. `npm install` - though honestly hue-forge has no dependencies :-)
3. Make your change on a new branch: `git checkout -b my-new-harmony`
4. Run the tests: `npm test` (see below - please keep them green!)
5. Push your branch and open a pull request.
New harmony rules are the easiest, most welcome contribution. Add your angles
to the HARMONIES object in src/harmonies.js and add one test for it. Done!
Notice how it points people straight at the easiest useful thing - "new harmony rules are the easiest, most welcome contribution." You're not just listing rules, you're gently steering a newcomer toward a win they can actually land. That's the difference between a contributing guide that reads like a legal form and one that reads like a friend saying "ooh, start here, this bit's fun."
This is my favourite trick in the whole open-source toolbox, and it costs nothing. When you know your project has a small, self-contained, genuinely-doable improvement, you don't quietly do it yourself. You write it down as an issue, tag it, and leave it there like a little gift for a stranger. On most hosts the convention is a label literally called good first issue, and people who want to start contributing go hunting for those.
Think back to the homework I set last week - "add one thing I left out, a fifth harmony rule." That's not just homework. That is a perfect good-first-issue, and here's what one looks like written down for a newcomer:
Title: Add a "split-complementary" harmony rule
Labels: good first issue, enhancement
hue-forge currently supports analogous, complementary, triadic, and
monochrome harmonies (see src/harmonies.js). It'd be lovely to add
split-complementary: the base hue plus the two colours either side of its
opposite. The angles are roughly [0, 150, 210].
To do this:
- add `"split-complementary": [0, 150, 210]` to the HARMONIES object
- add a test in test/harmonies.test.js following the existing ones
- that's the whole thing! shout if you get stuck.
Great first contribution. No colour-theory PhD required :-)
Read how that's written. It names the exact file, gives the actual numbers, links the change to a test, and ends with "shout if you get stuck." You've turned a scary blank void of "contribute to my project??" into a paint-by-numbers task a nervous beginner can finish in an evening and feel proud of. Making tasks that welcoming is a genuine skill, and it's the real engine of a healthy project - not the code, the invitations to help write it.
Now flip it around, because this is where a lot of well-meaning makers accidentally kill their own projects. Someone takes you up on it. They fork your repo, add split-complementary, write a test, and send it back as a pull request. What you do in the next five minutes decides whether they ever contribute to anything again. And the single most important habit is: thank them before you critique them. Even if the code isn't perfect. Especially if it isn't.
> Thank you so much for this - split-complementary is a lovely addition and
> your test is spot on! One tiny thing: could you wrap the hue with `% 360`
> like the other rules do, so 210 + a high base doesn't overflow? Happy to
> merge the second you push that. Really glad you're here :-)
See the shape of that? Warmth, then a specific small ask with the reason attached (episode 142's % 360 wrap!), then a promise to merge. No "this is wrong." No silent list of nitpicks. A person on the other end of that message feels helped, not judged - and helped people come back. This is the exact same idea as errors that teach instead of scold from episode 140, just aimed at a human instead of a console. The kindest thing you can do for your project's future is make its first contributor's experience feel great.
And when the change is good, you don't sit on it. You test it and you merge it, and their name is in the history forever now.
# reviewing a contributor's work locally before you merge:
git fetch origin pull/12/head:split-comp # grab their PR as a branch
git checkout split-comp
npm test # the tests from episode 137, earning their keep
# green? merge it and say thank you again in the release notes.
That npm test is episode 137 finally paying off in a way you feel in your gut. When a stranger's code lands in your project, tests are what let you say yes with confidence instead of fear. You're not reading forty lines hoping you spot the bug - you're running the safety net you already built. Open source and testing are secretly best friends.
The moment other people build on your tool, changing it becomes a responsibility, exactly like we said in episode 140. Open source cranks that up, because now you might have dozens of strangers depending on you. The grown-up convention for keeping their trust is semantic versioning - that 1.4.2 shape - and the loveliest way to make it real is a CHANGELOG.md: a plain, human list of what changed and when. Not a git log. A story your users can actually read.
# Changelog
## 1.1.0 - 2026-08-04
### Added
- New "split-complementary" harmony, contributed by @a-kind-stranger! Thank you :-)
## 1.0.1 - 2026-07-28
### Fixed
- Hairline seams between swatches on fractional canvas widths.
## 1.0.0 - 2026-07-20
- First public release. Seeded palettes, four harmonies, URL sharing.
Two things I want you to notice there. First, the middle number went up (1.0 to 1.1) because we added something without breaking anyone - that's the semver promise doing its quiet job. Second, and this matters more than it looks: the contributor is named and thanked right there in the changelog. Their five-line fix is now part of the permanent, public story of the project. That credit costs you nothing and means the world to them. 't Is een klein gebaar, but it's the whole culture in miniature.
So far we've talked about people contributing to your thing. But open source flows both ways, and this is the part that closes the loop on this whole series. Every tool we've leaned on - the p5.js we started with, Three.js from the 3D episodes, Tone.js from the sound arc - is itself an open-source project, made of contributions from people exactly like you. And the day you hit a bug in one of them, or a gap in its documentation, you're allowed to fix it and send that fix home. That's called contributing upstream, and it is the single most satisfying thing I do as a developer.
You don't need to be a wizard. The most valuable upstream contributions are often the humblest ones - a typo in the docs, a confusing example made clearer, a missing sentence that would've saved you an hour. Here's a real-shaped example: you notice the docs for a library function don't mention that an argument is optional, so you fix the comment and send it.
// BEFORE - the upstream docs you found confusing:
/**
* Draw a spiral.
* @param {number} turns how many loops
* @param {number} decay how fast the radius shrinks
*/
// AFTER - your one-line kindness, sent as a pull request upstream:
/**
* Draw a spiral.
* @param {number} turns how many loops
* @param {number} [decay=0.9] how fast the radius shrinks (optional)
*/
That is a completely legitimate open-source contribution. One clarified parameter. It'll help every single person who reads those docs after you, forever, and you'll get your name in the contributors list of a tool thousands of people use. The first time you see your little fix merged into something you learned from - honestly, it's a feeling I'd wish on everyone. The ecosystem taught you; now you taught it back a tiny thing. That's the commons breathing.
One last gentle thing, because I don't want to sell you a fairytale. Building in the open can feel exposing. Your half-finished code is right there. Someone might open an issue that reads a bit blunt. You might get a pull request you don't have the energy to review this week. And that's all fine. A tiny SUPPORT.md or even a line in your README that sets honest expectations protects your own evenings, and honesty is a kindness too - to you.
## A note on pace
hue-forge is something I maintain for fun in my spare time. I'll get to
issues and PRs when I can - probably weekends. If something's urgent for you,
please just fork it! That's what the licence is for :-)
Setting that expectation out loud does two things: it stops well-meaning people feeling ignored when you're just living your life, and it reminds you that you don't owe strangers your weekends. The commons is generous, but it should be generous to the maker too. A project you resent maintaining helps nobody. Protect the joy that made you share in the first place - allez, that joy is the actual point.
Step back and feel the shape of what we've done across these last few episodes. In 140 we learned to build tools for others. In 142 we actually built one. And today we let go of it - gave it a licence, a welcoming README, a map for helpers, a good-first-issue to hand a stranger, and the manners to receive their gift graciously and credit them for it. That's the full arc: from a sketch that runs on your screen, to a tool in other people's hands, to a living thing that other people help build. Your cleverness stops being yours and starts being ours, and it comes back to you bigger than it left. Wa een mooi idee, when you sit with it.
And here's the door that opens next. Once your work lives in the open, the natural pull is to make things worth contributing to - richer, deeper, more surprising generative systems that make people go "ooh, how did that work, let me look." We've spent a long stretch on culture and craft and manners; I think it's time we got our hands dirty with some seriously beautiful maths again. The kind of patterns that have made artists and mathematicians stare for centuries - how shapes fit together, how symmetry works, how space itself can be carved up into something gorgeous. So this week, your homework is a real one and I mean it: take hue-forge, or any sketch you're proud of, and actually put it online with a licence and a friendly README. Even if nobody ever stars it. Just to feel what it's like to open the door. Because next time, we start building the kind of thing people can't help but want to open the door to :-).
git push (episode 136's git, one step further) - the easy part. What matters is everything a visitor sees in the first ten secondsMIT file says "yes, freely, just keep my name on it" and makes your package.json license field honestCONTRIBUTING.md is the map - how to run it, how not to break it (npm test from episode 137!), how to send it back. Point people at the easiest useful thinggood first issue is a gift - write your small improvements down as labelled issues instead of quietly doing them. Name the file, give the numbers, end with "shout if you get stuck"So that's the whole circle closed - from making art for yourself, to making tools for others, to making a thing the whole world can help you build. The lovely surprise, one more time, is how little of it was code and how much was just care: a licence file, a warm sentence, a thank-you in the right place, an issue written so a stranger feels brave enough to try. Go put one sketch of yours in the open this week and feel that door swing. Then come back, because we're about to dive back into some proper generative maths and make things worth opening the door for. Merci voor het lezen, en tot de volgende keer :-).
Sallukes! Thanks for reading.
X
@femdev