Nathan, who completed a PhD at the MIT Media Lab and Center for Civic Media, researches factors that contribute to flourishing participation online, developing tested ideas for safe, fair, creative, and effective societies. Starting in September 2017, Nathan will be a post-doctoral researcher at the Princeton Center for Information Technology Policy, as well as the Paluck Lab in psychology and the sociology department.

Nathan's current projects (C.V.) include large scale experiments on reducing discrimination and harassment online, as well as observational studies on social movements, civic participation, and social change. Nathan regularly liveblogs talks and events and has published journalism in the Atlantic, Guardian, and PBS IdeaLab. He coordinated the Media Lab Festival of Learning in 2012 and 2013.

I first learned Scratch during a class on creative learning with Mitch Resnick, Sherry Turkle, and Karen Brennan. I also conducted a short ethnography on what happens on Scratch when learners get stuck. One possible strategy for getting unstuck involves looking at and modifying others' projects from the Scratch website. So I was excited to learn more from Andres about the values and practices of the Scratch community, as well as the design principles which support them.

Andres began his talk by asking, how do we design social computing systems that support remixing?

Remixing has different names in different cultures. Software developers talk about forking, artists talk about collages and bricolage. According to Lessig and Manovich, remixing is a longstanding cultural practice, going back as far as classical Rome.

The web has made remixing much easier than ever before. In recent weeks, laws like SOPA and PIPA have been part of the legal fight against remixing. According to Larry Lessig, there are basically two views on copyright: abolitionists and zealots: people who want to abolish copyright and people who want to control creative works. This fight takes place in four areas: law, norms, the market, and code itself (The Laws of Cyberspace pdf).

What fascinates Andres is the combination between norms and code, the idea that code can support social and amateur remix creativity. Most of the academic work in this area involves the study of wikipedia, an existing system. Other researchers try to build their own system to study behaviour, using their system as a laboratory. With Scratch, Andres tried an in-between approach, a system that had use in the real world which could also be studied as a kind of laboratory.

For those of you that haven't used Scratch, it's an amazing creative technology ecosystem which enables young people to create animations and games, share them online, and create community through the Scratch website at scratch.mit.edu. Participants can play your project, leave comments, and discuss it with their friends, much like the video sites Youtube and Vimeo. What makes Scratch different is that anyone can download any Scratch project, modify it in the Scratch editor, and re-upload it to your own profile.

At this point, Andres showed us the remix graph of a spaceship game that was remixed to included political figures who were running for office at the time.

Scratch comes out of the educational tradition of Constructionism, rooted in the ideas of Seymour Papert. Andres also drew inspiration from the writings of Ivan Illich, who encouraged ideas of informal learning and "learning webs" long before the web.

After five years, Scratch now has over a million accounts, 250,000 creators, and 2 million projects. What's fascinating is that more than 25% of those projects are remixes. For 71% percent of participants, a remix was their very first project. Andres refers to this figure to point out the power of remix for beginning learners. The Scratch site gets 28,000 new users a month, mostly teenagers, although many adults also learn Scratch from the children in their lives and become active members of the community as well. (statistics)

In addition to posting projects, Scratch users also post examples of their work that other people can reuse. One Scratch community member started to offer consulting services to other Scratch users as part of a "company." Other members of the community wanted to join the company, and after a while, they created a team which now includes a programmer, a chairlady, a game creator, character designers, background designers, webpage designers, and scrolling experts from around the world. This led others to start their own "companies."

In addition to facilitating community practices, the Scratch website tracks the most commonly used bits of code. Andres wondered how particular bits of code become standard practice within a programming community. It turns out that the most successful approaches are driven by community members who are open to sharing and helping other learners. In several cases, Scratch members go on to create their own websites with rich sets of resources to share with others.

Andres also looked at how many remixes lead to a mature project. In the case of some of the most successful games, it can easily take up to 17 remixes before the project becomes stable and successful. Andres showed us a fascinating graph of remixes. In some cases, the remix graph has been used by community members to find other people who are interested in similar things.

Remixing isn't always happy. Sometimes people say "Love what you did with my code!" but people also complain about plagiarism and "copycats." Just as in other parts of the Web, Scratch members care about attribution. They also expect remixers to add some unique contribution.

Some community members formed anti-plagiarism groups to fight what they saw as "copycat" behaviour. They pooled their energy to flag and complain about others' projects. Then one of the community members suggested that the Scratch website give you credit automatically when someone remixes your project.

Did this work? Despite what people said, automatic attribution didn't actually change the proportion of negative comments in the community. To understand why, Andres and his colleagues looked more closely at the project descriptions. They found that while automatic credit didn't affect negative comments, those who used their own words to acknowledge the original creator were much less likely to get a negative response. The Scratch team then interviewed some of thse creators to learn more, asking them "how do you define remixing." One Scratch community member called it "taking someone els'es project, changing a lot of it, sharing it, and giving credit." When they asked about a contentious case, Scratch members tried to distinguish between a "copy" and a "remix."

When the Scratch team looked at just how remixing is done on the system, they found that only 19% of the projects are exact copies. The media remix is 86% derivative, though half of the remixes changed more than 14% of the original project. But this study just studies how much code is added, not what is removed. Andres is now trying to run further experiments to improve that finding.

Positive remix practices can be supported through social processes as well as technical ones. The Scratch team created a "what the community is remixing" section on the front page, conferring status to people with the greatest remix count. The result was unexpected; Scratch participants created remix chains, asking each other to remix and pass along their creations to promote certain ideas into the community through remix. Others created remix competitions, encouraging others to remix their project for the "best color." They created fascinating incentive structures to support this, offering consulting, "love its", the opportunity to star in a project, friendship, and favourites.

Andres concluded with an overarching description of the key elements in a remixing system:

The structure of the system. Do you support attribution? Can projects be decomposed and redesigned? Do you support remix-friendly licenses? (Scratch uses Creative Commons). Are projects naturally modular?

The function of the system What is the utility of the projects people build? Are they inspirational? Can people reconstruct things from components? Is incremental design supported? Do you permit cloning of projects?

Collaboration. Do people work in duos, large teams, by themselves? How do you support that?

Attitudes. Does the originator encourage, restrict, or oppose remix? Do remixers follow norms, are they too cautious about remixing, or are they antagonistic, using remixing as a form of trolling and annoyance?

I asked Andres why Scratch was so successful, when Mako argues Wikipedia's success came from how well defined it is-- encyclopedia articles all have more or less the same format and style. Andres thinks that in the case of Scratch, it's typically small groups or individuals making projects, and individuals have their own ideas. The key distinction is how many people you want to get together to make something big. Depending on the number of people, you might need a higher degree of specificity. Mako says it might just be that they're kids :-).

One of the attendees asked, 'how do you explain creative commons to kids?' Andres showed us the Scratch license explanation, which explains creative commons with a metaphor of baking. Some kids still disagree with the license, and some of them move onto other communities, such as Deviant Art. Andres still isn't clear what to do with this- on one hand, Scratch is supposed to be a community with an ethos of openness. He wonders what would happen if they made other kinds of licenses available.