This was my contribution to the workshop, “From Emma to Marca: Technology and Pedagogy in a Decade of Open Source Writing Software Development,” organized by Christy Desmet for the 2014 Conference on College Composition and Communication. I’ve revised the title a bit here to reflect more accurately the final contents of my brief talk.

 

 

My contribution continues our conversation about big picture issues of open source development, trying to answer the question, “What do we gain by bringing this sort of educational technology development in house, rather than outsourcing it to–mostly–corporate developers of proprietary software?” And my answer to that question is, “We acquire more control over our personal data and intellectual property.”

To begin, I would like to consider the obvious questions involved in a decision whether to adopt a given technology in any class. As Ron and Sara demonstrated in their overview of the <emma>/Marca development process, when teachers and program administrators are involved in the development process, we aren’t just asking these questions, we also acquire a lot more control over the answers.

This shift, from tech consumer to tech creator, mirrors to some extent the shift we are encouraging our students to make, from passive readers or content consumers to active readers and authors. And, like our students, when we began looking at the world from this new perspective, we realized that, in addition to the obvious questions everyone always asks, we also needed to begin thinking about a different set of questions that are equally relevant to our ethos as writers, teachers, and makers.

In April of last year, the New York Times ran a story titled, “Teacher Knows if You’ve Done the E-Reading.” In the article David Streitfeld describes digital texts that track “when students are skipping pages, failing to highlight significant passages, not bothering to take notes — or simply not opening the book at all.” The data collected isn’t just made available to the teacher in the course, however. As Streitfeld later points out, “Eventually, the data will flow back to the publishers, to help prepare new editions.”

The development of new teaching technologies that allow us to track student data with increasingly comprehensive granularity presents significant opportunities to improve teaching and learning at every level. It also, as Audrey Watters points out in a webinar she prepared for the Educational Technology MOOC, or #etmooc, titled, “Who Owns Your Education Data?,” raises concerns about what happens to student and instructor data and intellectual property once the course is over.

The “defaults” in place under federal law give our students control over the intellectual property they create and their educational data. Further, although as a legal matter some schools might argue instructors’ course materials are “work for hire” and owned by the institution, as a practical matter, teachers are generally free to reuse and share the course materials we create as we see fit. When we use proprietary, enterprise educational technology, however, the interests of both students and teachers may be governed by terms of service we, as individuals never even see, and might not understand even if we had the opportunity and time to read them. In the best of circumstances, where a user freely decides to “click the box” in order to download iTunes or join Facebook, the terms of service are a contract of adhesion, in which one party–not the user–has all the power to decide its terms and conditions. In an educational setting, where use of the technology is a condition of employment or participation in the class, the situation is even more coercive.

The terms of service govern our rights with regard to individual technologies. They also have the potential to govern how institutions craft intellectual property policy. As providers increasingly require institutions to sign over rights to data and intellectual property in the terms of service for enterprise-level technology solutions, institutions will almost inevitably begin to require students and teachers to sign over those same rights, so the institution has the authority to manage them “in bulk,” so to speak, in its dealings with technology vendors.

We can already see MOOC providers influencing institutional policy in this way. Just yesterday, Inside Higher Ed ran a piece by Carl Straumsheim about how some big universities are dealing with intellectual property issues raised by MOOCs. MIT, for example, is taking a middle of the road approach to interpreting its intellectual property policy when edX content is involved: “If faculty members who have created MOOCs with significant use of MIT’s resources leave MIT, they still own their rights to teach their course elsewhere, though without the produced recordings. MIT keeps that footage, as well as a license to continue the MOOC based on the course materials it helped produce.”

Because <emma> development has always been part of an ongoing research project at UGA, concern for user privacy informed the development process from the outset. All <emma> users at UGA are asked for their consent to participate in research. The content of the consent form was reviewed and approved by an IRB, and access to <emma> for instructors and students is not in any way conditioned upon acceptance of its terms.

As the <emma> interface migrated from the desktop to the web browser, accessibility, universal design principles, and compliance with section 508 of the Americans With Disabilities Act moved onto our list of development priorities. With the evolution from <emma> into Marca, we have confronted these questions as we set medium to long term development plans and–for those of us who work on the GoMarca side of things–as we draft terms of service for hosting and support.

Marca is open source, so that means individual institutions can host and administer their own installations, and maintain control over all of the data collected, including making it subject to an IRB

Since <emma> and Marca share a common code base, and because the core development team continues to work at UGA on the <emma> project, the necessity of keeping <emma> accessible means we continue to follow best practices for universal and accessible design in the “production” branch of the Marca code on GitHub.

With regard to intellectual property, Marca already allows students and instructors to export individual documents, and our medium-term development plans include offering more robust export and data control options. Building an API, an application program interface, that would allow other developers to join the Marca developer community in that effort is also on our agenda.

Concerns about data, privacy, and intellectual property inform the terms of service under which hosting and support are offered to individual users. We negotiate at arm’s length with individual institutions, and the resulting agreements contain clear and express limitations on how user data is used outside the course, and a clear statement that all intellectual property rights in user-generated content is retained by the users themselves.

Finally, we are working to develop a user portfolio, one that students can build outside a course from the archive of artifacts they’ve generated during their coursework. We envision a user portfolio that could be kept completely private, shared only with a limited audience, or made public on the web.

In the average CMS, a course becomes a kind of digital “museum” once the semester or quarter is over, and sometimes even while the term is in progress. It is a space of restricted access, often filled with things we no longer own. What I think we have begun to create with <emma>/Marca is a “community garden,” or an online “maker space,” where individuals are provided with access to tools and resources, which are themselves owned by the community. And, at the end of the day, or the term, these individuals remain free to share or take home the fruits of their labor.