This category sat empty for a long time, which is its own kind of statement. So let me put the plain version at the top, where it belongs:
I am a trans woman. I support, and I write, free and open source software for gender non-conforming, body-positive, sex-positive and kink-positive people, and for the groups and projects that serve them.
Why this is on an engineering site
The rest of nexlab is telescopes, package repositories, GPU schedulers and daemons that are expected to stay up. It would be easy to argue that a line about who I am does not belong next to any of that.
I do not think that argument survives much scrutiny. Software is not written by nobody. It gets its defaults, its threat model and its blind spots from the people who build it, and those defaults land hardest on whoever was not in the room. A form that will not accept your name. A verification flow that demands a document that does not match your face. A moderation pipeline that files your existence under "adult content". A "real names" policy written by people who have never had a real name used as a weapon against them. None of that is a bug report anyone files. It is just what happens when the room is narrow.
So I would rather say it here than have it be a surprise. If you are hiring me, working with me, or running something you would like me to help with, this is part of what you get.
What "support" actually means in code
Not a badge in a footer. Concretely, it means:
- Building the infrastructure these communities cannot rent. Groups working on gender, body, sex and kink get deplatformed as a matter of routine — payment processors, hosts, app stores, ad networks and cloud providers all reserve the right, and all use it. Self-hosting stops being an ideological preference at that point and becomes the only way to still be online next year. Most of what I do for a living — Linux from the ground up, your own hardware, your own stack, no landlord — is exactly the skill set those groups need and can rarely afford.
- Treating identity, privacy and consent as engineering requirements. Chosen names and pronouns that survive a database migration. Data that is minimal by default, because a leak here is not an inconvenience, it is an outing. Deletion that actually deletes. Consent modelled in the schema rather than promised in a privacy policy nobody reads.
- Free licences, on purpose. Software a community cannot read, fork or move is software someone else can take away from them. Everything I put out is free software for that reason before any other.
- Doing the unglamorous parts. Backups, mail that is not silently blackholed, moderation tooling, accessibility, the boring operational work that decides whether a small project is still running in three years. Volunteers burn out on this long before they burn out on the mission.
Why those four words go together
Gender non-conforming, body-positive, sex-positive, kink-positive. They are not the same thing, and I am not claiming they are. They share a technical fate: they are the categories that automated systems quietly decide are a liability. The same classifier, the same payment risk model and the same "community guidelines" catch all four, and the appeal goes to nobody. Whatever your view of any one of them, the engineering problem is identical — how do you build something durable when the platform layer beneath you is not on your side?
That is a systems problem. It happens to be the one I am good at.
If you are working on something in this space
Get in touch. I am interested in the infrastructure end of it — hosting, identity, privacy, moderation tooling, migrations away from a platform that has decided it is done with you, and generally keeping a small project alive without a budget. For community and non-profit work, ask me about rates; they are not the same as the commercial ones.
info@nexlab.net — or find the code at git.nexlab.net and github.com/nextime.