In my experience, most teachers don't develop courses from scratch. Instead, they take whatever material is at hand, modify it to meet their needs, and then—well, that's usually where they stop. Unlike open source software developers, they usually don't give it back to the community in any explicit way. Instead, the next person who needs a starting point has to stumble over it in a Google search, and the original creator may never know that someone improved upon what they did.
Back in December (of 2011), I wondered whether the fork, merge, and share model that underpins so much of modern open source software development could be applied to education. It turns out that lots of other people have been thinking along these lines (and that some of them have actually done something about it):
- Joseph Reagle: fork-merge-share (describing, among other things, a geek-oriented solution to one practical obstacle I mentioned)
- AJ Juliani: Why Every Educator Should Read Hacker News
- Aaron Shaw: A Modest Academic Fantasy
- Ethan Watrall: I want "forking a class" to become part of our vernacular (Twitter)
- Brian Croxall: Forking Your Syllabus (ProfHacker)
- Lincoln Mullen: How to Fork a Syllabus on GitHub (ProfHacker)
- Katherine Harris: Acknowledgments on Syllabi (tracking sources)
- Michael Feldstein: When It Comes to Content, Say "Yes" to Wrappers But "No" to Containers
"GitHub for Education" is a handy shorthand for this idea, but "the idea" isn't necessarily, "Let's put educational materials in GitHub", but rather, "Let's facilitate a culture of spontaneous-but-structured collaboration and improvement." (You can see why we say "GitHub for education" instead.) I'd like to start experimenting with this, so my question is, if the source materials for Software Carpentry were on GitHub instead of in our own Subversion repository, would you actually start contributing patches?