Professors, Don't Let Your Students Grow Up to Be Proprietary Software Users
I am currently cutting over all of my course management to rely on open-source, text-reliant software and files.
I have been through several course management tool cut-overs at several schools, plus experiencing the general difficulty of bringing one's accumulated knowledge and data forward from one position to the next, and with the last new course management tool I had to adopt, I had had it!
Of course, you have to use whatever course management software your school requires: well, they require it, and the students are used to it. But you can just fill up the content area of that tool with links to your open-source repository, where the real meat of your course resides. To do this:
A GitHub repository should take the place of your Moodle / Blackboard / Canvas / Whatever course module as the focus of where you collect your course materials. When you rely on GitHub for this function, you get:
What's more, all of the work I have done with proprietary formats has been subject to multiple crashes, cross-platform incompatibilities, and so on. That doesn't happen with HTML files. In addition, since HTML is text-based, it is easy for you or a programmer you hire to process and transform those files with simple Perl, Python, awk, or shell scripts.
The above doesn't mean you should never use proprietary software for your courses: there are times when a PowerPoint presentation may provide the "pop" you need bring out some point with some fancy animations or transitions. There are times when an Excel spreadsheet can be just the ticket for capturing how the parameters to some model affect its output. But you can store these files in GitHub as well! So, basically, if you go open source, you can incorporate proprietary whenever you wish. But the reverse is hardly true.
And here is my first effort following these precepts.
I have been through several course management tool cut-overs at several schools, plus experiencing the general difficulty of bringing one's accumulated knowledge and data forward from one position to the next, and with the last new course management tool I had to adopt, I had had it!
Of course, you have to use whatever course management software your school requires: well, they require it, and the students are used to it. But you can just fill up the content area of that tool with links to your open-source repository, where the real meat of your course resides. To do this:
A GitHub repository should take the place of your Moodle / Blackboard / Canvas / Whatever course module as the focus of where you collect your course materials. When you rely on GitHub for this function, you get:
- Complete portability of your accumulated course-specific files from one institution to another: a school may deny you access to their course management system after you leave, but they can't deny you access to your own GitHub repository!
- The ability to share the work you have done as broadly as you want. No one needs a University ID to view your GitHub repository.
What's more, all of the work I have done with proprietary formats has been subject to multiple crashes, cross-platform incompatibilities, and so on. That doesn't happen with HTML files. In addition, since HTML is text-based, it is easy for you or a programmer you hire to process and transform those files with simple Perl, Python, awk, or shell scripts.
The above doesn't mean you should never use proprietary software for your courses: there are times when a PowerPoint presentation may provide the "pop" you need bring out some point with some fancy animations or transitions. There are times when an Excel spreadsheet can be just the ticket for capturing how the parameters to some model affect its output. But you can store these files in GitHub as well! So, basically, if you go open source, you can incorporate proprietary whenever you wish. But the reverse is hardly true.
And here is my first effort following these precepts.
Comments
Post a Comment