Paradise is exactly like where you are right now... only much, much better.
— Laurie Anderson
It's hard to make things better if you don't know what "better" looks like, so in the wake of some email responses to last week's post on how to contribute, here are some thoughts on what we'd like Software Carpentry to look like when it's finished (or as finished as something like this ever is).
First, this site will offer short tutorials that are directly relevant to scientists and engineers who want to get more done with computers in less time and with less pain. Each of those tutorials will be available in several formats, including recorded video, plain HTML, and downloadable slides. Topics will be both practical (e.g., common Unix shell commands) and foundational (e.g., how hash tables work); the latter will be included to help people understand, connect, and generalize the former.
Second, this material will be used in lots of courses: half-day conference tutorials on single topics, week-long bootcamps, single-semester classroom courses, peer-to-peer study groups, and of course self-directed online study. And we'd like to see lots of instructors: grad students teaching helping other grad students work through it, corporate trainers repackaging it and selling on-site delivery, professors combining some of our material with their own notes on bioinformatics or combustion dynamics, and so on.
Third, there will be an active community discussing, updating, fixing, and enlarging the content. Right now, Software Carpentry has a bus factor of one: Version 3 languished from 2005 to 2010 while I was busy with other projects, and unless a "Wikipedia effect" kicks in (or more funding materializes so that I can keep going for another year), Version 4 will start going stale on May 1 as well.
As I have said elsewhere, our long-term goal is to raise both standards and skill levels among the overwhelming majority of scientists and engineers who don't think of themselves as computationalists. We will know we have successed when their computational results are as reliable as their physical experiments, and when programming doesn't inspire any more fear and loathing than firing up an oscilloscope.