|
| 1 | ++++ |
| 2 | +title = 'Open source courses' |
| 3 | +slug = "2022/12/12/open-source-courses" |
| 4 | +description = "Courses should be open source: not just the course, but the source and procedure to modify" |
| 5 | + |
| 6 | +[extra] |
| 7 | +authors = "Richard Darst" |
| 8 | ++++ |
| 9 | + |
| 10 | + |
| 11 | +*Part of a series on the [Future of |
| 12 | +Teaching](@/blog/2022-10-17-future-of-teaching.md)* |
| 13 | + |
| 14 | +CodeRefinery courses (like many these days) are open source. This |
| 15 | +should be the minimum requirement for most (all?) courses, and many |
| 16 | +are - but it's important to clearly specify just what this means and |
| 17 | +why. |
| 18 | + |
| 19 | + |
| 20 | +## Four freedoms applied to course material |
| 21 | + |
| 22 | +As usual when we mean "open source", we actually mean "free (as in |
| 23 | +speech)". Let's look at the [Four essential freedoms of free |
| 24 | +software](https://en.wikipedia.org/wiki/Free_software#Definition) and |
| 25 | +see how they apply to teaching |
| 26 | + |
| 27 | +* **Freedom 0: The freedom to use the program for any purpose.**: You |
| 28 | + can use the material and re-teach the lesson yourself. |
| 29 | +* **Freedom 1: The freedom to study how the program works, and change |
| 30 | + it to make it do what you wish.**: Not just the material is |
| 31 | + released, but the necessary planning and instructor hints to do so. |
| 32 | + Beyond that, you should be able to see the "source code" so that you |
| 33 | + can use those techniques yourself. |
| 34 | +* **Freedom 2: The freedom to redistribute and make copies so you can |
| 35 | + help your neighbor.** This is hopefully somewhat clear: a license |
| 36 | + lets you redistribute it yourself, not just link to the current location. |
| 37 | +* **Freedom 3: The freedom to improve the program, and release your |
| 38 | + improvements (and modified versions in general) to the public, so |
| 39 | + that the whole community benefits.** This is the most interesting |
| 40 | + one. Can you improve it and reshare? Do these reshares get lost in |
| 41 | + your fork, never to be seen by others, or can others take advantages |
| 42 | + to them? Or even, can you improve and send back to the original |
| 43 | + source? This is a lot harder for course material |
| 44 | + |
| 45 | + |
| 46 | +## How we do it |
| 47 | + |
| 48 | +This should be clear if you know the main CodeRefinery workshop - it |
| 49 | +is basically a tutorial to the practices we use! |
| 50 | + |
| 51 | +* Git for version control [git-intro lesson]() |
| 52 | +* Github for platform for collaboration [git-collaborative lesson]() |
| 53 | +* Sphinx + Github Actions + Github pages for the actual lesson material [documentation lesson]() |
| 54 | +* [sphinx-lesson](https://github.com/coderefinery/sphinx-lesson) |
| 55 | + provides some minor Sphinx extensions for lesson-like documentation |
| 56 | + sites. |
| 57 | + |
| 58 | +The lessons are treated as open-source software projects - except it's |
| 59 | +documentation, not code. All of the tools nicely fit into place. |
| 60 | + |
| 61 | + |
| 62 | +## The benefits |
| 63 | + |
| 64 | +And what do we get? Anyone can contribute, and even propose changes, |
| 65 | +with minimal effort and without having to ask for permission or files |
| 66 | +first. These changes can easily be tracked, and people can even |
| 67 | +easily create their own versions (linked to ours via forks, so we can |
| 68 | +see and integrate changes later if desired). |
| 69 | + |
| 70 | +**Is there any other way?** At one meeting, we were discussing if |
| 71 | +there is any other reasonable option (other than git + PR/MR workflow) |
| 72 | +that can provide this level of collaboration. The closes we could |
| 73 | +think of was "google docs-like tool" where someone can suggest |
| 74 | +changes. But still, changes can either be suggested, or the lesson |
| 75 | +can be copied and with no more easily suggestions. **From what we can |
| 76 | +tell, we need to use git.** |
| 77 | + |
| 78 | + |
| 79 | +## Why open collaboration is harder for course material |
| 80 | + |
| 81 | +Open collaboration on teaching can be hard, **because everyone wants |
| 82 | +their course to have material perfectly suited to it,** with nothing |
| 83 | +extra. This leads to a tendency to fork material, rather than |
| 84 | +contribute upstream. It might also lead to the tendency to not design |
| 85 | +for reuse, since who would want to use it, anyway? |
| 86 | + |
| 87 | +**How we get around this:** We have to consider this in the design: we |
| 88 | +have to design in enough modularity so that a lesson can be taught |
| 89 | +multiple ways. It can be hard, and not perfect - but it's better to |
| 90 | +have upstream changes to an imperfect lesson, rather than many |
| 91 | +diverged lessons (that probably aren't perfect anyway, since they are |
| 92 | +) |
| 93 | + |
| 94 | + |
| 95 | +## What do we hope others can do? |
| 96 | + |
| 97 | +Try to be more open than before. We don't expect that everything can |
| 98 | +be perfect: git for everything is too much, and not everyone has time |
| 99 | +or skills to do that. But for larger, collaborative courses, it's |
| 100 | +important. CodeRefinery is happy to help advise you in the mechanics |
| 101 | +of things. |
| 102 | + |
| 103 | + |
| 104 | +## See also |
| 105 | +* Our |
| 106 | + [community-teaching](https://coderefinery.github.io/community-teaching/) |
| 107 | + workshop covers this (or will, once it gets more developed) |
0 commit comments