Jul 10, 2020
Thinking of building tools for journalists & activists?
Think again.
Software isn’t secure. This hurts everyone, but it places the most vulnerable at excessive risk. Journalists, activists, queer people, sex workers, union organizers… Everyone deserves safe tools, but the danger isn’t distributed evenly.
From time people decide to build secure software to help protect the most vulnerable in society. Sometimes, people interested in this sort of project email me. A recent message mentioned a project to build collaboration tools for journalists with “the security of Signal and the comfort of Google Docs”. I’ve seen a number of variations on this query, and I’ve sent similar replies every time — here’s the template.
Thanks for reaching out about your project!
This is an incredibly ambitious undertaking. That’s not a compliment (it’s not necessarily a criticism either). You have picked a very difficult task! It will be a lot of work to get right. And potentially harmful if you don’t.
Making tools for journalists (or any other threatened group) is not necessarily a great approach. It’s an approach which paints a target on the people who download or use that tool. It’s usually much safer to make tools which are generally useful, but which you know solve a need journalists have. Look at Signal’s successful example.
You are not the first person to be interested in a project like this. It’s a very attractive idea: who doesn’t want secure, usable tools? But actually making that real is a challenge. You will probably not succeed, and that the ways that you will not succeed are probably not things you’re currently considering.
I have some suggestions.
Limit your project scope. “the security of Signal and the comfort of Google Docs” is huge. The comfort of Google Docs with the security of Google Docs is a massive software and infrastructure engineering effort on its own! A huge number of Google engineers, not to mention project managers and designers and all the rest, make that product what it is. Even if you eventually want to build a whole suite of tools, I strongly recommend that you pick just one narrow tool to start with.
Pick one useful underserved tool. There are quite a few projects which try to make messaging tools, or whistleblowing tools, or document-editing tools. Proton has been trying to build an end-to-end encrypted collaborative calendar for literally years. Don’t try to build any of those. Pick a tool that nobody else has tried to build this way, and pick one which is relatively straightforward. Ideally something which doesn’t feel glamorous! I’m talking about time-tracking/timesheets, invoicing/invoice-tracking, or inventory-management. Eleanor Saitta has an excellent essay on writing secure tools with many more examples. While you’re reading Elanor’s work, consider looking through her two-part series on building software for NGOs and related groups.
Make your tool usable. It doesn’t matter how secure something is if it’s not usable. This is somewhat along the lines of the point about making tools for a particular threatened group — if something is even a bit of a challenge to use, only people interested in a challenge will use it. Usability is almost certainly not something that the people specializing in the security of a tool can estimate well. Usability is a professional skill that doesn’t necessarily overlap with software engineering. And this is a hazard in volunteer projects, because people with software development skills often can’t build usable interfaces, and people with design and usability skills often can’t build what they design.
Build a diverse team. It is exceedingly unlikely that you have the full breadth of skills and life experiences needed to achieve these goals. You will need a team. That team will need to include people who (at minimum) cover the following skills: cryptography, software engineering, infrastructure/devops, design, accessibility, writing, localization and translation (including language skills), project management, product management, fundraising, marketing & communication, team management, and organizational leadership. And this team needs to be there for a long time — there’s no shortage of abandoned software in this space. You need to maintain and update your tools. A throwaway project is a net harm.
Raise grant money. You can start this project with a volunteer team, but you can’t finish it that way. You need to pay your collaborators (and yourself!). This is not a project worth investing in, because the people who need it most can’t pay for it. It has none of the characteristics that make venture capital interested in software. You need a stable funding source outside of traditional capitalism.
I put all those things first, because I’m hoping that the overview will help you internalize the overall scope of what you’re talking about. Sneakily, however, that’s not what I actually recommend. My real, fundamental recommendation is the following.
Join an existing effective project. All of this is a huge undertaking! Even if you eventually want to do this independently, you’ll probably be much better at that if you start off by joining an organization which already has a lot of the capabilities described. Consider Signal or SecureDrop or Martin Kleppmann’s local-first software research or… well, I’m sure you can find for others which are a better fit for you personally.
