Amdahl's Law says that the speedup you can get by parallelizing a computation is limited by how much of the computational can't be sped up. For example, if 10% of a program's run time is inherently sequential, then even if you have an infinite number of processors, you can't speed it up more than 10 times.

The same rule applies to organizations like Software Carpentry. We now have almost 200 certified instructors; even working in pairs, and each teaching only once a year, that's enough to run two workshops a week, and we're training more all the time. But someone has to train them, and match them with workshops, and design new templates for lessons, and talk to potential sponsors, and those central activities are now limiting what we can accomplish.

To give you some idea of what goes on behind the scenes, here's what my week looks like:

Hours Activity Notes
11.0 Board discussions Drawing up by-laws, hammering out a funding model, etc.
10.0 Other email Questions about teaching, managing assessment, extracting Git history, etc.
8.0 Instructor training Real-time contact hours, demo teaching, and email
6.0 Discussions with potential partners and funders Some live, some by email
5.5 Writing/reviewing grant proposals Some for us, some for partners
4.0 Writing and revising blog posts Like this one
3.0 Coordinating workshops Arliss and Giacomo handle most of it, but there are always things left over
2.5 Record keeping Managing our list of who taught where, who's signed up for instructor training, etc.
2.5 Reviewing pull requests Should be a lot more
2.0 Research projects The code review study, the language comparison study, etc.
2.0 Technical support Git issues, mailing list issues, web site issues, etc.
1.0 Writing letters of reference Saying nice things about our instructors is the least I can do to thank them

That's 57.5 hours in a week in which I'm not traveling or teaching workshops, and still doesn't include things that are vital to Software Carpentry's long-term health, like writing notes for instructor training, refining the template for new lessons, translating existing lessons into that format, building a tool to check that they conform to our style guide, experimenting with a better build system for workshop websites, and a dozen other things. Asking volunteers to do these things isn't a solution: many of these activities are administrative, have long lead times, and require sustained attention over a period of months, so like any non-profit, we need some full-time staff in the center for continuity.

And that means raising money, not just for my salary (since I've been working pro bono since the start of this month), but also to hire at least one more person to share the load. We also need more institutional partners to provide staff for coordinating workshops in the way that Arliss Collins and Giacomo Peru have been doing.

We can offer sponsors and partners several things in return: an agreed number of workshops each year, on-site instructor training, and help with recruiting and publicity for sponsor activities. They will also have a say in our direction: we're still working on the details, but organizations that back us will be represented on our board and be able to shape what we do and how we do it. If this sounds interesting, please get in touch. We'd welcome a chance to talk about ways and means.

This post originally appeared in the Software Carpentry blog.