Collaborative Development of Educational Resources

In the last few years I tried push the collaborative development of educational resources with GitHub for undergraduates students and fail. My vote for the reason that I fail is, as suggest by Justin Kitzes, that

“potential contributors need a certain level of familiarity and comfort with the tools that enable contributions (such as version control or a browser-based Wiki editor).”

Another possible reason is that, most of the time, educational resources are used offline what make difficult for people contribute.

Below you will find food for thought about this topic.


At The Cathedral and the Bazaar Eric S. Raymond wrote about the success of free/open source software development. This type of development wasn’t restricted to software source code but also cover the documentation of such softwares.


At that time, this type of development require people to exchange patches by email and was restricted to who was internet access and knows how handle patches.


In 2001 Wikipedia was launch. It make easy to every one with internet access to contribute with the free/open encyclopedia since Wikipedia’s user don’t need to know handle patches.


With the success of Wikipedia, many sisters sites was launch, e.g. Wikibooks, to store books, and Wikiversity, to store courses.


Unfortunately, this sisters sites didn’t have the same success of Wikipedia and one possible reason for it is, as suggest by Greg Wilson, that

“while lots of people in education can write and edit lesson plans, they appear not to have taken on the broader role of managing the development of collaborative materials.”


In 2008, GitHub was launch and enforce the “fork model” for collaboration. To understand the “fork model” lets go back to the early days of free/open source softwares. During the 80s and 90s, free/open source software developers exchange their contributions/patches using email and the maintainer of the software was responsible to accept or not the contributions. Some times, contributors had their patches reject by the maintainer and fork the software, i.e., start maintainer a new software that is the original one with some patches.


When using GitHub, the first step to contribute with some project is fork it. After you make changes in your fork you can send the changes back to the original project. This approach has some advantages since it make easy to someone without computer background get the version with the changes he/she need.

What next?

  • If MediaWiki, the software that powered Wikipedia, support a “fork model” sisters sites like Wikibooks and Wikiversity would have more success?
  • If a software to import lessons exist educators will use it?