Last year in March I did a lot of soul searching about my mission in the EdTech space. At the time, figuring out the incentives for authors and teachers to produce open educational resources (OER) seemed like an insurmountable mountain to climb. I didn’t see a clear path for interoperability between content sources. OER yes, but OER how?

Since then I’ve learned a lot more about the open content landscape and I’m starting to feel more optimistic about the prospects for OER. Could year 2018 be when the switch-over happens? I think so.

This is a followup on my previous post about the challenges of open educational resources (OER) production and adoption. I’ve come to the conclusion that the key aspect holding back the “OER dream” is not the lack of collaboration tools or the ability for teachers to discover material, but the quality of the content. You can’t write a textbook by committee. It’s as simple as that!

### The state of open educational resources in 2017

I spend the last couple of weeks exploring the open educational resources (OER) landscape and wanted to write down my thoughts and observations about the field. The promise of an OER “revolution” that will put quality learning material into the hands of every student has been around for several decades, but we are yet to see OER displace the established publishers. Why is it that “open content” hasn’t taken off more, and what can we do to make things happen in the coming decade?

### Git for authors

Using version control is very useful for storing text documents like papers and books. It’s amazing how easy it is to track changes to documents, and communicate these changes with other authors. In my career as a researcher, I’ve had the chance to initiate many colleagues to the use of mercurial and git for storing paper manuscripts. Also, when working on my math books, I’ve had the fortune to work with an editor who understands version control and performed her edits directly to the books’ source repo. This blog post is a brainstorming session on the what a git user interface specific to author’s needs could look like.

### Open book writing and typo workflow

Open is better than closed because when you work in the open the whole world can help you (or at least the portion of the world that cares about what you are doing). For books in particular, readers can be tremendously helpful by submitting typo fixes to the book. But how can users submit typos? Surely there is something better than email…

Today I saw a very interesting workflow for reader contributions on the Advanced R programming book website by Hadley Wickham. The book  is being developed on github using the Jekyll static site generator. Each page has an “Edit this” link on the right side:

The url for that button is:

https://github.com/hadley/adv-r/edit/master/index.rmd

Clicking on that takes you to github and a special prompt to create a fork:

Next you can make the change:

And finally the UI offers you to do a pull request:

This is still a complicated process for the reader (3-steps, one feature branch, one pull request), but from the author side this is awesome! You just write and then manage incoming pull requests that improve your content.

Anyone writing their blog posts in the open on github should consider adding the /edit/ links.

Weekend project: find a way to automate this workflow process so readers don’t need to have github accounts. Maybe I could create a “shared” github account “ivans-readers,” allow for login-less-editing to happen on my own server and then see the pull requests coming from ivans-readers on the main repo.