Only half-joking on mastodon the other day:

There's definitely been a shift. Once upon a time, it was all about GETTING people to contribute back their changes. Now, it's much more like, no, PLEASE DON'T.

I always thought the deal was simple enough: There's a shared core, Django say, and then there's your product, the thing you build on top of it.

Nobody's business is Django, not really. It's what we do with Django that’s where the money is. Hence the permissive licences: you contribute out of self-interest, because the core is hard, and it’s much better if it’s everybody's problem, and not just ours alone.

But I think that deal has shifted, and I’m not quite sure we’ve noticed.

Code is cheap now, they tell me. I need this feature. Well, you can have that in minutes. What’s more, we need to rebase this when the new release comes out isn’t a challenge either. We like to talk about the commons, and that’s a thing, although perhaps not the thing we thought it was — another day Carlton! — but forget that. What exactly do we gain by ceding control and velocity in getting our changes merged upstream?

Your maintainer almost certainly doesn’t want it.

The cost of reviewing patches didn’t change an iota. It’s still going to take me an evening to go through your code, and if I wanted to talk to a bot, I’d do that myself. The whole reason to engage as a maintainer is the human relationships we form. The conversation with the contributor is what matters. If you take that away, then thanks, but no thanks.

So, if the code is cheap, and rebases are easy, and the maintainer doesn’t have time for your changes anyway, why not just keep them?

Deploy your fork

When I started out maintaining, packaging was hard, at least for me. There was a long list of steps, and I didn't really know what I was doing. Releases were something I had to work up to.

Users would sometimes (often?) ask for a release. I'd say, it's coming, but in the meantime I'd point them to the pip VCS support docs, and mention that they could install from a git branch if they wanted it early.

People should be doing this now. By default.

Don't make a PR. Deploy your fork.

The options grow from simple to more complex:

• pip install git+https://github.com/you/thing@your-branch — This is good enough for most things. (You can put it in [tool.uv.sources] in your pyproject.toml if you're on uv.)
• A step up? Build the wheel, drop it in a folder on your server (or a mount your Docker build can see) and use --find-links for it.
• If you’re doing this across a team? Run devpi (which is arguably a good idea for more advanced teams anyway).

Any of these lets you use your own fork, on your own schedule, without adding to your upstream maintainers’ load.

We’re in the midst of a sustainability crisis. Deploying private forks, rather than pushing upstream by default, has to become the norm.

Talk about your changes

I saw a post a while back about “sharing your prompt, rather than your code”. (I can’t remember exactly where.) But I don’t want your prompt either.

Rather, tell me about your use-case. Put up a blog post; write it by hand. Tell me the why behind your changes. Link to your branch: I can check out a diff if I want to.

Therein lie the seeds of a conversation, which (again) is what it’s all about. However our current moment plays out, it’s the human element that we need to maintain.