Enabling Stigmergic Collaboration on Open Textbooks – Task Division

Problem Definition

Authors cannot easily collaborate with others on a book in Pressbooks. In order for collaboration to occur certain elements need to be present such as “communication, coordination, awareness, task division and conflict resolution”1 Identifying what is required to facilitate collaboration in an editorial workflow will provide a context within which gaps can be evaluated. Determining where we are now with existing tools will reveal what needs to be built, or borrowed.

The focus of this document will be on exploring the technical requirements of task division within the context of stigmergic collaboration. Later documents will focus on other elements of collaboration such as awareness, communication, coordination and conflict resolution.

Overview of Challenges

Collaboration Tools and Adoption

Daniels argues that until the focus of OER is on “production” instead of “reuse” it could not be considered a mainstream adoption.2 David Wiley indicates a relationship between the number of adaptations and how easy it is to make adaptations: “If this is the case, it stands to reason that the easier it becomes to revise, the more revisions will take place.”3 Building tools that support a collaborative process will contribute to increasing adoption of open textbooks. Currently, the most predominant strategies for increasing adoption (and adaptation) focus on principles of availability and discoverability. While these are logical conclusions and necessary in the lifecycle of a resource, they are only relevant when there is a steady supply of resources. Both philanthropy and government initiatives have funded the bulk of open textbooks to date, but this is not a sustainable model and must not be assumed to continue generating a steady supply of open educational resources. Thoughts on what the future of OER production could look like has been presented by academics in the field within the context of a larger question about sustainability.45 A specific approach to collaboration, called stigmergy is cited as being key to the future production of effective OER.


Blog infrastructure, upon which Pressbooks is built was designed for one or more authors to “…control their part of the conversation on their own machine and software while still being tied to a larger conversation through linking, backlinks, tags and RSS feeds.”6 The focus of blog infrastructure design is managing content in a hierarchical paradigm. As a result, very few collaborative elements are available that would support a collaborative workflow. The amount of participation in knowledge creation is controlled through authentication roles which grants levels of access to content and dictates where and how much people can participate. Potential contributors need to seek permission from other people with greater authority than them. The lack of autonomy and available tools drives most authors and editors to collaborate outside of the Pressbooks environment.

Comparatively, wiki infrastructure is designed around a value system that puts collaboration at the centre, however, what is required is consensus. Though the hierarchy in this system is somewhat flattened whereby authentication grants people the ability to edit content, consensus can become a barrier to knowledge creation. Once granted access, edits to the source document can be made and may be subject to a process of review and discussion. Afterwards the changes are either accepted or denied (reverted). While specific ideas about workflow and around how knowledge can be created by multiple authors is at the core of  this type of infrastructure the requirement of consensus for every addition can be an inhibiting factor for innovation. It can also be time consuming to manage and not always appropriate for an academic text.

Combining the best elements of both wikis and blogs has been explored in projects like Federated Wiki and Wikity. Extracting elements of what works in both systems and eliminating what doesn’t has proven to be a worthwhile endeavour. Stigmergic mechanisms can be observed in how both of these projects approach collaboration. At the very least, establishing a relationship between how knowledge gets created and the tools we use speaks to the importance of system design. Some analysis of this endeavour is explained in further detail. 7


Pressbooks responds to a need among self-publishers to have access to a toolset that can deliver high quality digital files to various book sellers. The focus of the design, built on top of blog infrastructure, has been to support the production of these files and the producers of these books. As a result, Pressbooks design continues to be concerned with presentation of content in multiple formats. Where mechanisms exist in the infrastructure for community to interact with content (primarily through comments) they have been turned off. Annotation services may or may not be available to them depending on the author’s/publisher’s decision to turn that feature on. Mechanisms that would allow acting in a participatory way with the content is not encouraged. An idea of community around Pressbooks content is limited to a community of readers, who are a community by chance, are not cognizant of themselves in a community nor of other people in that community. Mechanisms that would allow people to form communities around content or for the purpose of making content are not available.

Audience Specificity

Similar to how open source software used to be “…the sole province of the geek [that] existed behind barricades impassable by ordinary computer users” most advanced software development tools are only accessible to the technologically inclined.8 While some developer tools could be co-opted or used by makers of OER, there is a significant difference between the level of inclination and time most academics have to work with advanced collaboration tools and the level of time and inclination of software developers. Asking that academic publishers use these tools or put aside the time to gain a comprehensive understanding of existing developer tools risks alienating users.

Publishing Process

Care has been taken to ensure that the process of writing is kept private until a finished product is ready for release. During the writing process, the actions of multiple authors or editors are not immediately visible to each other. One exception is if an author attempts to edit a page that another is working on, a pop up notification will appear. Revisions of previous changes can be viewed and reverted to if need be, but is only available to authenticated users in a role with the correct level of permissions. Traces of the editing process are kept completely hidden from public view and are mostly hidden from view for some authenticated users. Comparatively, the publishing process in both open source software and wikis is completely transparent. Not only is every part of the publishing process transparent, including what, when and who made changes but notification systems makes editing events significant to a self-selected group of interested parties. Conversations and discussions can occur around these specific change events and a sense of community is encouraged to develop around the publishing process. While open source developers and wiki authors may be very comfortable with an open and transparent publishing process, the level of comfort academics have with it is an unknown at this point.

Successful Models

Open source software has influenced, and continues effect the creation of open educational resources (OER), from the very specific ways to openly licence a resource to a more broad culture of openness.9  Since the narrative of open source software has had more time to mature the tools and workflows have benefited from that maturation process. The ecosystem of development tools for OSS developers is rich, and complex. “Software development has transitioned from a predominantly solo activity of developing standalone programs, to a highly distributed and collaborative approach that depends on or contributes to large and complex software ecosystems.”10 Technical features have made a huge impact on how software gets made. The popularity of tools like git and Github has also had an extremely positive effect on the proliferation of open source software over the last eight years. A lot of the popularity is due to the strength of the underlying versioning system (git) and the array of collaborative features that support a transparent publishing workflow.

Knowing that the history of open source software has already served as a model for OER means that deconstructing the collaborative elements and workflows that are afforded through these tools and tailoring them to meet the needs of academic publishing has a significant potential to positively effect the production and adoption of OER. The current state of OER publishing tools available to authors of open textbooks is fairly limited, mostly co-opted and only slightly modified from the original intent, bearing a resemblance to the state of open source software tools a decade or so ago.


“The concept of stigmergy provides a theory for explaining how disparate, distributed, ad hoc contributions from individuals could lead to the emergence of large collaborative enterprises”11 Pierre-Paul Grasse defined stigmergy as “the stimulation of the workers by the very performances they have achieved”. The stigmergy process can be observed in some open source development workflows, wikis, also ant and termite behaviours. A more comprehensive explanation of stigmergy can be found here.
Version Control System
“A version control system (or revision control system) is a system that tracks incremental versions (or revisions) of files and, in some cases, directories over time.”12
Centralized Version Control
“[Authors] work on a change and then commit it to a central repository, merging and resolving any conflicting changes. This centrality forces [authors] to constantly deal with changes from a diverse set of [authors] and limits the ability of [authors] to isolate their work and collaborate with others.”13
Distributed Version Control
“There is no inherently central repository. Each [author] has a full copy of the entire history of the system, and [authors] are free to share changes between any repository, provided that at some point the repositories had a common ancestor.” 14
Task Division
How are decisions made about splitting up the work in a collaborative environment?
How do you organize different individuals to work together in an effective manner?
How do you enable essential communication between team members?
Conflict Resolution
How do you resolve conflicts between changes in content?
What activity needs to be tracked and displayed in order to leave enough hints or evidence of previous work?

Current Status of Collaborative Elements

Table 1.1 — Current status of collaborative elements in Pressbooks, Mediawiki and Github.

  Communication Coordination Awareness Task Division Conflict Resolution
  1.  authenticated users can see the revisions of a post
  1.  revert to previous state is possible
  1.  talk pages can be used for discussion
  1.  pages can be added to watchlist.
  2. trustworthy users can review recent changes, and approve
  1.  a list of changes to each page is available. Who made the change, what the change was and when it happened is available to unauthenticated users.
  2. authenticated users can watch specific pages.
  1. revert to previous state is possible
  2. edits/changes can be discussed
  1. discussions can occur around specific events
  2. @mentions can invite specific people into a public conversation
  3. one to one communication is not permitted
  1. coordination around an editing event occurs after notifications are sent out. Pull requests, issues, discussions, mentions send notifications.
  2. notification system invites code review
  1. editing events trigger notifications to self-organizing group of watchers
  2. authenticated users can follow other people
  3. authenticated users can watch repositories
  4. authenticated users can ‘star’ repositories
  5. authenticated users can edit personal profile pages which highlights/quantifies contributions to creating/editing content
  6. transparent publishing keeps and displays a record of all editing events. Who made the change, what the change was and when it happened is available to unauthenticated users
  1. issues/tasks can be created
  2. tasks can be assigned to specific people
  3. milestones and deadlines can be declared
  4. Branches/Forks can be created to work on specific tasks (strong versioning system)
  1. pull request system
  2. built in conflict resolution in git
  3. issues/changes can be discussed
  4. revert to previous state is possible

Approaches to Task Division

Task division in an ant or termite colony is neither dictated by an insect leader or requires consensus among insects. In this type of system, clues/hints/traces of previous work are left for individual agents to decide for themselves which tasks should be prioritized. The self-organization approach to task division affords the most autonomy, drives independent, parallel work and is in line with a stigmergic approach to collaboration. Two main pieces of functionality are utilized for task division in Github; a light project management feature known as an issues list and versioning which includes creating copies in the form of branches, forks or clones. Creating a new copy of the code base allows issues to be worked on in isolation from the main code base.

There are two types of version control systems. Over the last decade Distributed Version Control Systems (DVCS) have become more popular than Central Version Control Systems (CVCS). Brindescu et al. suggest that using one or the other system will have an effect on the types of changes that are made, the quality of changes and the likelihood that people will participate in the editorial process. When a versioning system encourages small changes, allows grouping changes by intent and permits making reference to an issue tracking label, it is more likely that high quality changes will occur in a collaborative environment. 15

Versioning and Workflow

Workflows in both DVCS and CVCS (Fig 1.1 and Fig 1.2), share some of the same qualities. For instance, the first three steps in both systems are to pick something to work on, make a copy/clone of the code base and proceed to make edits on that copy of the code base.

workflow for distributed version control

Figure 1.1 — Workflow in a Decentralized Version Control System[note]E. Kalliamvakou, D. Damian, K. Blincoe, L. Singer and D. M. German, “Open Source-Style Collaborative Development Practices in Commercial Projects Using GitHub,” 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Florence, 2015, pp. 574-585. doi: 10.1109/ICSE.2015.74[/note]

workflow for centralized version control

Figure 1.2 — Workflow in a Centralized Version Control System [note]E. Kalliamvakou, D. Damian, K. Blincoe, L. Singer and D. M. German, “Open Source-Style Collaborative Development Practices in Commercial Projects Using GitHub,” 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Florence, 2015, pp. 574-585. doi: 10.1109/ICSE.2015.74[/note]

The significance in making a copy first, unlike a wiki workflow but not unlike a federated wiki workflow, is that making edits to one’s own copy requires neither approval or consensus. However, within a CVCS, the requirement that the edits be pushed back to a central repository means that both consensus and approval are necessary further along in the process. Within a DVCS the absence of a central repository to push back to avoids the dependency on other people and mitigates the potentially inhibiting effects of those requirements by migrating approval and consensus to an independent, self-controlled environment. Attempts to either bring version control, or implement revision features in WP have been developed with varying degrees of success. In some cases, a copy of the original is made to which edits are applied.

Current Status of Versioning in CMS

  • WordPress — automatically captures revisions of individual posts, available to authenticated users only. Main features are diff, restore previous version. Revisions are stored in the database as separate post types, independent of the the original post.
  • VersionPress — WP plugin in current development. Currently does not work with Multisite WP/PB. Dependency on git, roadmap to remove dependency on git. Versions the entire WP file system, not just content. Very complex plugin at early stages of development.
  • Post Revision Display — WP plugin developed circa 2008/2010. Using built in WP functionality it publicly displays revisions of a post with links to view the differences between posts. Needs visual clean up, code refactoring.
  • Post-Forking — WP plugin developed circa 2013. Allows authenticated users to fork a post, view a diff of the changes they made and merge changes back into one definitive version of a post. Fosters a collaborative approach to content. Most functionality works out of the box with PB, except merge.
  • Persistent Forking — WP plugin in current development by Utrecht University. Does not copy content over. Does provide an interface to create a ‘fork’ of post. Keeps track of parent posts, can display a ‘family’ of forks. Does not work out of the box with PB.

Requirements for Task Division

When a repository is cloned or copied in Github, the copy also brings with it a history of editorial events associated with the original code base. From a stigmergic perspective, this log of activity is an important trace of previous work or activity that any new author/developer can build upon. The requirements for task division which include stigmergic mechanisms are:

  1. The original textbook keeps track of where and how many copies of itself are in the network
  2. The copy maintains a relationship to its ‘ancestor’ or original version.
  3. The copy brings with it a history of editorial events.

From a learner’s perspective, having a list of links to alternate versions of the same textbook could be valuable if another version explains the same concept in a different way. From an author’s perspective, it is evident that copying both the content and information about what was changed are important clues that could give new authors an idea of what they are building upon. When assessing the relevance of the material, a list of recent changes will also give readers and potential authors an idea of how well maintained that particular version is.

1. Original textbook keeps track of copies

Changes to the user interface are required in order to accommodate how the original textbook will keep track of where and how many copies of itself. Both wiki and Github employ similar UI components which gives users the ability to switch between views of readable content (default view) and other functionality. A similar interface is proposed in Figure 1.3.


Figure 1.3 — Interface changes allowing the original textbook to keep track of different textbook versions of itself

User flow involves five or so steps (Figure 1.4): Clicking a button, checking permissions, creating an empty book, getting information from the book to be copied and putting that content into the new book.


Figure 1.4 — User Flow for copying a book

2. Copy maintains a relationship to its ancestor version

Maintaining a link back to the original version of the book allows users of the book to view another author’s version which may describe things in a way that helps them understand the material. (Figure 1.5)

3. Copy brings with it a history of editorial events

A log of editorial events for the book will be brought in to each copy, helping establish hints about previous work. (Figure 1.5)


Figure 1. 5 — Maintaining a relationship to ancestor version and a history of editorial events

Use Cases

  1. Use case: Instructor/Author — I am looking for textbooks that may be relevant to a class that I am teaching. I find one that I like and would like to make some changes to my own copy of the book.
  2. Use case: Student/Learner — I am a student and I would like to understand a concept. I look for other versions of the same book that may explain a concept to me in a way that helps me understand.


Task division in a stigmergic collaboration context requires certain features to be present. Making a copy of a book, for instance, requires maintaining a connection to the ancestor book (vice versa), and a log of the editorial changes. The concept of a DVCS has proven to be effective in open source software and other projects, like federated wiki, that take a similar approach have also reported positive results. Having a distributed system of versions is likely to be more effective than enabling mechanisms for many people to contribute to one central repository and follows the current trend in open software development. The developer lexicon of forking, cloning and branching are concepts that describe a simple act of copying (in different contexts) that risks introducing unnecessary complexity or causing confusion. Using the word ‘copy’ is a label that accurately describes the intended action and minimizes any confusion or misunderstanding.



  1. E. Kalliamvakou, D. Damian, K. Blincoe, L. Singer and D. M. German, “Open Source-Style Collaborative Development Practices in Commercial Projects Using GitHub,” 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Florence, 2015, pp. 574-585. doi: 10.1109/ICSE.2015.74
  2. Daniel, J. Retrieved from Measuring Use and Creation of Open Educational Resources in Higher Education http://www.irrodl.org/index.php/irrodl/article/view/1573/2637
  3. Wiley, D. Examining the Reuse of Open Textbooks http://www.irrodl.org/index.php/irrodl/article/view/1137/2130
  4. Caulfield, M., Choral Explanations and OER: A Summary of Thinking to Date https://hapgood.us/2016/07/12/choral-explanations-and-oer-a-summary-of-thinking-to-date/
  5. Wiley, D., OER: Some Questions and Answers http://opencontent.org/blog/archives/4529
  6. Caulfield, M., Can Blogs and Wiki Be Merged https://hapgood.us/2016/02/22/can-blogs-and-wiki-be-merged/
  7. Caulfield, M., Can Blogs and Wiki Be Merged https://hapgood.us/2016/02/22/can-blogs-and-wiki-be-merged/
  8. Wiley, D. (26). Open source, openness, and higher education. Innovate Journal of Online Education, 3(1).
  9. Wiley, D. (26). Open source, openness, and higher education. Innovate Journal of Online Education, 3(1).
  10. M. A. Storey; A. Zagalsky; F. Filho; L. Singer; D. German, “How Social and Communication Channels Shape and Challenge a Participatory Culture in Software Development,” in IEEE Transactions on Software Engineering , vol.PP, no.99, pp.1-1 doi: 10.1109/TSE.2016.2584053
  11. X. Cui, J. Beaver, J. Treadwell, T. Potok and L. Pullum, “A Stigmergy Approach for Open Source Software Developer Community Simulation,” Computational Science and Engineering, 2009. CSE ’09. International Conference on, Vancouver, BC, 2009, pp. 602-606. doi: 10.1109/CSE.2009.288
  12. Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato, Version Control with Subversion, http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html
  13. E. Kalliamvakou, D. Damian, K. Blincoe, L. Singer and D. M. German, “Open Source-Style Collaborative Development Practices in Commercial Projects Using GitHub,” 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Florence, 2015, pp. 574-585. doi: 10.1109/ICSE.2015.74
  14. E. Kalliamvakou, D. Damian, K. Blincoe, L. Singer and D. M. German, “Open Source-Style Collaborative Development Practices in Commercial Projects Using GitHub,” 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Florence, 2015, pp. 574-585. doi: 10.1109/ICSE.2015.74
  15. Caius Brindescu, Mihai Codoban, Sergii Shmarkatiuk, and Danny Dig. 2014. How do centralized and distributed version control systems impact software changes?. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 322-333. DOI=http://dx.doi.org/10.1145/2568225.2568322


Brad Payne is currently the lead developer for the Open Textbook Project whose work focuses on open source software using PHP (LAMP). When not contributing to other developers’ projects on github, he builds his own. Through exploiting API’s and with a penchant for design patterns, he helps BCcampus implement new technologies for post-secondary institutions. Prior to his current position at BCcampus, Brad worked in IT at Camosun College and the BC Ministry of Education.

You may also like...

3 Responses

  1. August 16, 2016

    […] Enabling Stigmergic Collaboration on Open Textbooks – Task Division – Brad Payne […]

  2. August 29, 2016

    […] Of course, with OER the OpenStax model serves the former case while the Libretexts model (formerly known as the STEMWiki Hyperlibrary) serves the latter. And even better models are emerging. […]

  3. February 9, 2017

    […] Enabling Stigmergic Collaboration on Open Textbooks – Task Division […]

Leave a Reply

Your email address will not be published. Required fields are marked *