Behold! Our code! This is the new-ish stuff that we feel like making public; we have a long list of unfinished projects from decades past, which may be of minor personal interest to our friends but which we think is mostly just clutter, so we've held that back. Our hope and intent is to only publish stuff here if there's a chance of it being useful to somebody, somewhere. It's our gift to the world.

These commits are signed, where's the public key?

Thank you for noticing! Yes it's true, we are the only living user of PGP. Our PGP key is at irenes.asc and, just like this page, it's hosted on infrastructure we physically control.

Why cgit-pink?

We hate to write a whole manifesto about this, but through conversation we've become aware that, as obvious as the reasons feel to us, not everyone is aware of them. We have no expectation that everyone will agree with the rather strong anti-capitalist position we find ourselves taking these days, but at the very least we'd like to write it up somewhere for people who want to understand our choices to read through.

Please skip this section if you're not interested. Seriously, you are under no obligation to read this. Cory Doctorow has said all this better than we can, anyway.

The older we get, the less trust we have in corporations that claim to be friends of free software. For several years now, we've felt unwilling to put new stuff on GitHub, unless that's necessary as part of sending a pull request to someone else. We are similarly distrustful of GitLab and even SourceHut: In all cases where there is a profit incentive, we do not believe that the company's long-term priorities will be aligned with ours. Smaller companies often seem friendlier than larger ones, but anyone who has accepted venture capital is subject to an expectation of unlimited growth, which means that they are all but guaranteed to treat the public they claim to serve with increasing contempt in direct proportion to their success.

Furthermore, we don't want unnecessary change to a system that works perfectly well; we want a stable set of features that we can rely on to keep being there into the future. Our ideal solution to small problems such as publishing our code is to use software with a very small number of volunteer maintainers. Anyone who's selling something is going to be driven to keep doing things to make it seem new and exciting, and that means it's less reliable, both in operational terms and in terms of knowing that the parts of it we care about will continue to receive care and love as everything around them is changed. Too many times, we've seen small but important functionality we needed go away because it wasn't driving enough revenue.

It may be counterintuitive that a program that receives virtually no developer time can be cheaper to maintain than one that has dozens of people assigned to work on it. The conventional wisdom in the corporate world is that maintaining old features is expensive, but the root of the expense is that underlying infrastructure and surrounding context are changing. Again, this is driven by the need for novelty - a need which arises solely and entirely from the profit motive. When we select software which is not driven by those incentives, it can and does remain in good working order for decades with minimal attention. The price of novelty is fragility; we prefer things that are built to last, no matter how dated they may seem.

There's one final point that we feel it would be wrong to leave out: We are firm believers that software should be built as many small tools which are only loosely coupled with each other. This allows experimenting with replacements for individual pieces, and taking the overall ecosystem in new directions, without throwing away the work that's been done on parts that still serve their function. It also is far easier for people who are new to a codebase to ramp up on it, explore, and get creative, when the codebase is smaller. We see the Unix philosophy of small tools with loose coupling as important not merely for engineering reasons, but for social reasons - simpler tools do a better job of promoting a culture of exploration and creativity.

Pursuant to that, we actively want to not have our code publication be done by a tool that also integrates features for project planning, bug tracking, public outreach, continuous integration, and political debate (that's not a joke, we've seen organizations use their GitHubs for any necessary political discussion that arises from their work). Instead, if we someday manage to replicate our consciousness into fifteen extra bodies and therefore need to do project planning on our personal hobby work, we will set up a separate tool for it.

If you want to send us a patch, get in touch through whatever means you deem appropriate. :) If you're not sure how to do that without using a graphical pull-request button, we'll be happy to walk you through any of the many alternatives. Seriously, teaching young 'uns how to do stuff is a source of great pleasure for us, don't be shy.

Enjoy the code!