Maxim: If you always do what you’ve always done, you’ll always get what you’ve always got.

I often think that Mark Pilgrim had the right idea. For as long as I’ve been doing open source, we’ve been making the same complaints about overwhelm, abusive users, freeloading companies, and ultimately our physical and emotional health, under the rubric of maintainer burnout.

In all that time, we never fixed anything. Deviation from the mean leads to a moral panic, even from folks who you might think would know better, and so nothing ever changes.

And we talk a good game on representation. We’re all for DEI. There are initiatives such as Django Girls and Pyladies. We can really pat ourselves on the back: aren’t we the inclusive community!

But despite all that — as Laís Carvalho argued in her stellar opening keynote to inaugural PyCon Greece — women take up at most 10% of the OSS population.

For all the talk, for all the years, we’ve not moved the needle at all. (My God, what would it be like without the efforts we do make?)

And then there’s AI.

Paolo has been talking this year about AI-assisted contributions and maintainer load. He argues that AI amplifies the existing issues, rather than creating new ones in kind. I think he’s right there.

But the trouble is, we only just had our head above water all these years. AI is like a flood that swamps the whole model. Open source wasn’t sustainable as it was. Whatever is happening now is something else entirely.

§

Being a maintainer sucks. Mostly interactions are fine, great even. But every so often there’s one that really sucks it out of you.

We’ve talked here in past — in relation to Managing Django’s Queue — about extractive contributions, those that take more from a project than they give back, and at scale undermine it.

Beyond the lack of thanks, the lack of recognition, and of compensation, being on the receiving end of aggression and abuse is probably the thing that takes the heaviest toll.

As a white cis straight man I get it easy.

As I’ve been talking about our diversity issues with folks over the years, I’ve heard horror stories. What I see, what I experience is, is nothing compared the routine harassment that women are subjected to online.

I’ve been repeatedly told, by women, that they will avoid interacting in public forums and issue trackers, or that they will do so only carefully and occasionally, and that (for example) they will present in these spaces as men, in order to avoid issues, and to have their contributions taken seriously.

So, we have a place where the open nature of GitHub-driven development elevates extractive contributions, making it unsustainable for even the most economically privileged. At the same time, that environment actively discourages the participation of a wider demographic.

Our system is failing.

More bluntly, if women have to pretend to be men in order to feel safe to participate and to be taken seriously, that’s not an environment I want to be part of.

Measures like codes of conduct help, but they’re not moving the needle. Laís’ “at most 10%” is still the case.

So, given that, if you always do what you’ve always done… — it’s time to try something else.

§

Django — and many other projects — are battling with the new AI powered wave of noise. We’ll see how that goes.

In any case, Django is a massive project. It’s not clear that we even can, even could, make radical changes quickly.

Even the medium sized projects I maintain — think django-filter or channels — are established. People have expectations about how they operate. It’s not clear I can just change that at a stroke. (We don’t want to trigger a moral panic.)

But the newer projects — the Neapolitans, the Mantles, whatever comes next. There I think I do have room to experiment.

So, I’m looking for different ways to structure the contribution model.

It’s an experiment, at this stage. I’m not (at all) sure what it’ll look like, or if it will have lasting positive results. But, if you always do what you’ve always done… — I have to try.

§

I have three loose goals in mind.

The first is to create an environment that is actually welcoming to (inter alia) women. My conjecture is that, even with CoCs in play, it’s the open nature of GitHub, with its drive-by by design approach, that is the source of the unpleasantness. So, whilst I don’t yet know how this’ll be shaped — that’s kind of the project — whatever I do won’t be open in the way we’re used to.

Code will still be open source. It’ll still be licensed as before. It’s just that the contribution process isn’t going to be driven by a textarea just anyone can type in to. Your contributions aren’t going to be presented as an invitation for someone to attack you.

As I say, the substance of the experiment is to see what this could look like.

Second, and I think I might get this for free if we solve the first, I want to reduce the purely extractive contributions.

Part of this is separating support from development: Issues were meant to be about the latter, but that’s not how it worked out. (… — I could say more here but won’t.) Support wasn’t the issue though, not really.

Rather, the problem is more that, because the workshop door is wide open, folks will just walk in, dump their current problem in the middle of the room, and loudly demand that it be made a priority. The difference in tone here from a regular contributor (or a new one, genuinely engaging) is everything. It’s the difference between a demand and a dialogue.

So, in any case, there’s an implied step back from Working in Public: instead of being stood in the middle of the room, for all to see, we need (at least) something like one of those old fashioned dressing screens that you could get changed behind in old period dramas or movies.

Finally, particularly where businesses are using the software, they’ll need to contribute as stakeholders if they want a voice in development.

Christopher Neugebauer gave an(other) interesting talk at last year’s PyCon AU, entitled The Death of Consequences:

There’s an interesting discussion on why copyleft licenses largely failed, perhaps mainly because we missed the boat on sticking to and enforcing them. I’m not so sure about full applications but, at least for libraries I found myself agreeing (with my own preference, perhaps?) for a shared, liberally licensed, open source core, with proprietary code built on top.

But, then, if licensing can’t solve our sustainability model, then what can?

Chris talks about governance, particularly with regard to Kubernetes: at least there, companies will support the project in order to have a voice in how it proceeds.

Now, I don’t know if that scales down to much smaller open source projects. We’ve been banging the drum for years about how companies should sponsor the DSF in order to ensure the sustainability of the framework they built their business upon.

But there was never any consequence for not doing so. As Chris argued, we need a bit of stick as well as some carrot.

So, in a much smaller way, at a much smaller scale, I want to just see — it’s an experiment after all — if asking companies to support the projects they’re using, if they want to input into its development, has any traction at all. If not, no worries. If so, well, maybe it’s something other projects could try.

As I say, I’m not sure how all this rolls out, but I want to try something new.
As ever, thanks for reading. Supporters of the Stack Report will be in on it, however it goes.