Colin's Sandbox

Thoughts on Creating Open Learning Groups

by on Apr.22, 2014, under #digitalcitizenship, #etlead

A recent conversation with some members of my professional learning network made me reflect that there are big lessons to be learned when forming open learning project groups.  In the past I’ve always been a part of organizations / companies that were relatively long-lived endeavors – spanning decades.  The boundaries of collaboration were dictated by people in position of some authority over me for the duration of the project, which was also similarly dictated.

My experience with open learning environments in my master’s program to date have been a luxury for me personally, a safe and secure place to work, so much so that I feel very fortunate.  From conversations with others I know that this is not always the case.  Work can be taken down, debates can occur over comment sections, disputes over domain ownership, and more can all happen.  When forming into these open learning groups there’s quite a few questions that I would seek to figure out and hopefully documenting so it’s understood by all.  I would enumerate those questions as:

  • Who (or what entity / institution) controls the public facing resources (domain name, web site, YouTube channel, Twitter handle, etc.)?  Seems like this is the “project leader”.
  • Can the material be shared freely to any and all through a permissible license?
  • How to handle transition within the organization?
  • How to unwind gracefully out of a project if it’s not working out and not leave others in a lurch? (ongoing reflection)

To me, the second one up there, in conjunction with the effort to put as much of the work as possible out in the open, protects most of the rest.  When projects aren’t going well, or go stale, the disgruntled (or motivated, depending on your point of view) contingent “forks” the project, taking all current (and past) contributions and creating a new project out of it, calling it by a new name.  All previous authors’ names and license terms are retained.   Derived works are typically required to use the same or similar license.  Many forks die, but some go on to live healthy productive lives.  Most all of Linux distributions themselves are produced from three different branches.

When a contribution that someone makes in a downstream branch, project maintainers above may merge those changes upstream.  Everyone wins.

If you ever get a dull moment, check out the Linux Kernel Mailing list.  There are FIERCE DEBATES that are all out in the open.  That first exchange was between the benevolent project dictator for life, Linus Torvalds, and what many perceived as his right hand man, Alan Cox, that resulted in Cox’s departure for a time.   Cox was previously a god in Linux circles, and remained as such after his departure because all the work that is his in the Linux Kernel (and there’s lots, he was an early key player) is attributable directly to him as is the discussion that guided major commits that he made in the Linux kernel.  I think the interesting thing here is that in the Linux world, everything it produces has the luxury of being hosted in a distributed fashion (currently using the protocol Git), verifiable (with all commits signed by author), with revision control allowing you to roll back to any point in time on any file.

One issue is that much of the published work is hosted on proprietary systems such as YouTube, Twitter, and others, so that even though the work is public, it can be controlled by whomever the work was published under, if steps aren’t taken to incorporate the group under some sort of business license and creating business accounts on those services.  Perhaps the key would be to host the work in a distributed system such as Git, hosted by GitHub and mirrored anywhere, by anyone at all as the repository would allow world read-only access.  This would allow anyone, project members or otherwise, to publish documents from there onto any service of their choice as long as they respect the license that was attached to the work.  Maybe something easier to use would be Dropbox or Google Drive, but unless you shell out for additional features it doesn’t look like it meets the requirement to retain revisions.  Neither pass the distributed test.  But using a protocol like Git doesn’t allow for some of the best (and certainly the most popular) collaboration features out there offered by cloud services like Google Apps.

Clay Shirky thinks that this concept of openness and transparency of development should be applied to democracy.

I think it could apply to open learning collaborations as well.  It’s up to individual projects to determine their culture and figure out the tool stack to use that meets their needs.


Leave a Reply

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!