Information about SVS.
social versioning system
overview of SVS
use of SVS in the spring_alpha project
social versioning system
One of the key issues which the development of Free/Libre Open Source Software (FLOSS) has emphasized is the highly socialised nature of working with code and digital media. One of the main aims of the GNU General Public License (GPL), for example, is to ensure that source code stays in public circulation so that the exchange of ideas and knowledge that this facilitates can be maintained. The notion of Open Content has extended such principles to areas of cultural production outside of software, such as writing, music and film-making.
Alongside the use of open and copyleft licenses, various tools have been developed to support such forms of practice. Two of the most widely used are Concurrent Versions System (CVS) which enables teams of programmers working remotely to collaborate on the same project, and Wikis, an online system for creating collaborative web content such as used in the Wikipedia.
Social Versioning System (SVS) is a framework for supporting such collaborative projects that combine coding with other media, and allows programmers and non-programmers to work together. It is initially being developed for the spring_alpha project. spring_alpha is a multiplayer simulation-game, which uses the idea of game design as a vehicle for social enquiry. The game itself exposes the mechanisms of game creation in the way it is played: game content can be publicly edited through web-based level editors, and during gameplay the code that runs the game can be accessed and recoded. An analogy is drawn between the ways in which software systems construct the representation of the gameworld, and how social systems and behaviours construct forms of social governance in the real world. SVS creates an infrastructure for this by combining game engine and design tools with Wiki and CVS mechanisms. Whilst the early versions of SVS will be geared towards the needs of spring_alpha, it is intended that as it matures it will become applicable to other types of project.
As well as facilitating collaborative production, SVS provides ways of reflecting on that process, revealing aspects of how the interaction between those who create the content and code, or play with it, relates to how the game itself develops and behaves.
One way of doing this is by mapping how a particular component, such as a piece of code, changes over time, who was involved in that, and how that relates to other activity such as communication between the participants. Both CVS and Wiki systems use methods of 'version control' which track the history of changes to a piece of code or a web page, allowing older versions to be retrieved and compared with newer versions. SVS combines such functionality with processes derived from social network analysis, which map interactions between individuals within a group of people or between people and particular artifacts that they use and work with.
In fig. 1, for example, the columns of shaded boxes on the left-hand side represent different pieces of code as they evolve over time. Each column is a different code file, and the shading of the box represents how much it has been altered from the previous version (darker shading indicating lots of changes, lighter shading indicating small changes). A particular version of a code file has been highlighted and linked to a graph showing connections between the programmers working on the code. In this each node represents a programmer and the lines show how they are connected to each other (the connection in this case being if they have worked on the same piece of code). Within this diagram three people are highlighted who have all contributed to the code file. This, in turn, is linked to a series of email messages between them discussing some particular changes to the code.
The current version of SVS is based around a simple multi-player gaming system, in which the games can be reprogrammed whilst they are played. A tracking tool is provided which provides similar information to that in fig. 1, relating changes in code to communication between players.
The tools created for SVS are explained in the tutorials and the process of creating and playing some simple games is given in the examples sections of this site. Information for developers is provided in the development section, along with links to libraries used in creating it and sites and articles relating to the ideas behind it in the resources section.
The spring_alpha project is being realised through a combination of software development, through which the game engine is being created, and public workshops, through which game content and game play will be created and explored. At a certain level these two processes merge into one, as playing the game involves reprogramming it. Project participants include people with a range of skills relating to programming, gaming but also those with no such experience but who may contribute more on the level of content ideas and ways of using (and abusing) what gets made. SVS is being used as a way of allowing such diverse contributers to work collaboratively, combining easy-to-use web-based tools for creating content along with more 'hardcore' programming tools. Fig. 3 shows how these different components and processes fit together.
spring_alpha is a 'social simulation' game, similar in some respects to games like The Sims. In such games, the behaviour of characters is coded into the environment and objects with which they interact rather into the actual characters themselves. spring_alpha is set within the overarching narrative of a social uprising in which existing social norms are challenged and new ones created (see the original story). This relates to gameplay through hacking and altering the code that simulates that world, creating new types of behaviour and social interaction. The particular forms these might take will depend upon the ideas developed by participants. How effective this becomes depends on the players' ability to spread these new ideas into the society. To do that requires that they work collaboratively in constructing and improvising new behavioural codes and systems.