Click here to view the complete list of tools reviews
This article was originally published in the Fall 2011 issue of Methods & Tools
Saros: An Eclipse Plug-in for Distributed Party Programming
Dr. Karl Beecher, Freie Universität Berlin, http://www.mi.fu-berlin.de/w/Main/KarlBeecher
Saros is a plug-in for the Eclipse IDE that enables two or more distributed programmers to develop projects in real-time over the Internet and share each other’s changes. It allows users to communicate in a variety of ways as they collaborate and also to remain constantly aware of their partners' activities through various sorts of awareness information.
Web site: www.saros-project.org
Version tested: 11.7.1
System requirements: Java 1.6 or greater, Eclipse IDE
License & Pricing: GNU GPL. Available for free download at
http://sourceforge.net/projects/dppor via Eclipse update
site http://dpp.sourceforge.net/update
Support: SourceForge-hosted mailing lists and trackers. The members of Software Engineering Workgroup at the
Freie Universität Berlin (the authors of Saros) are also willing to negotiate support for organisations.
The Basics
There is increasing need these days for tools that allow software developers to collaborate across large distances. The rise of free/open source software, an increase in working from home, and organisations distributing their activities across the world are all phenomena which can pose problems for achieving close collaboration. For developers, the problems are centred around the absence of a number of things which are normally taken for granted when we work co-located. Distributed developers may be able to have discussions while having their own copy of the code before them, but as soon as one of them alters their code, they no longer have a common view. Even once you implement a method to propagate those changes conveniently in real-time, there are still issues. All those familiar cues you (sometimes unconsciously) feed each other – which we call "awareness information" – are missing: Which file is he looking at? Which line is she on? What parts of the file has she changed? Is he looking at the code or checking his email?
Saros provides a solution to these problems. As the product of a wider research programme into collaborative development, we created Saros as a tool to embody our findings in how best to achieve distributed collaborative development. The basic ability of Saros is to share one or more projects with some other developers by setting up a session. This simply means that one person (the inviter) asks the others to join them and the invitees each receive a copy of the project(s). Alternatively, if an invitee already has a copy, their version is synchronised so that it is identical to the inviter's copy. Once the session is established, Saros constantly passes messages between all the participants to maintain the session. What information is in these messages? What does a Saros session keep track of?
To help answer these questions, Figure 1 shows Saros in action and labels all of the major features and carriers of awareness information. The first four labels show parts that decorate the existing Eclipse components:
Saros also provides its own Eclipse view to manage the session:
Throughout a session, all these things are constantly varying as everybody types, scrolls, moves between files and so on. It is actions like these that are communicated by the messages which Saros passes around to ensure that everybody's views and files are perfectly synchronised.
Additional features include:
Scenarios
We believe that there are a number of scenarios in which using Saros can be highly beneficial:
Joint review: One participant (the "driver") reviews the contents of one or more files together with other participants ("observers"). The observers use follow mode to watch as the driver reads. The driver can stop to raise questions (via IM or VoIP), highlighting text with the mouse to inform the others what they are questioning. Any suggested changes can immediately be discussed and implemented.
Coaching beginners: This is much like the previous scenario, except that explaining rather than reviewing is the goal. An experienced developer (the "teacher") wishing to introduce beginners to the code takes control of the session and uses IM or VoIP to convey the important points. Each beginner follows the teacher and can raise questions when the need arises. Also, a beginner could individually peek at other regions of the file or even other files without interrupting the flow of the session for the others.
Distributed Party Programming: Two or more participants (parties) work together in a loosely coupled fashion. They work independently much of the time, but can call on one another to help whenever the need arises, possibly for just a short time. The buddy list allows everyone to see who is "in the room" and can therefore be called upon. In this mode, distributed work can even be more powerful than working in the same room, as nobody needs to leave their seat to help others and participation is not limited by whoever can fit around one computer screen.
Distributed Pair Programming: A special case of Distributed Party Programming in which two people develop code or text in continuous close collaboration, discussing the approach and combining the best of their ideas. At any one time, one person acts as a driver and the other is an observer. The observer will use the follow-mode to watch the driver.
Technical Information
Saros is build atop some key technologies discussed here.
To make the whole communication possible Saros uses XMPP (formerly called Jabber), an open standard for message-oriented networked applications. This widely-used and extensible protocol provides for Saros the messaging, roster functionality and presence information. Because it is a decentralised architecture, Saros can be used with any public XMPP server in the world (examples include jabber.org, jabber.ccc.de, as well as our own server saros-con.imp.fu-berlin.de). You can even elect to run an XMPP service on your own server and use that. Regardless, once a server has been located, the user need only create a new user profile and begin using it to run Saros sessions.
The concurrent editing capabilities of Saros are provided by the Jupiter algorithm for maintaining consistency between participants, even as they type simultaneously. The algorithm is based on the GOTO inclusion transformation, which allows each participant to write in real-time on his or her local document while remote modifications of other participants are merged into the document concurrently.
A consistency watchdog continually monitors the project to make sure it remains consistent with everyone else's copy in the session by guarding against unforeseen events that affect consistency (e.g. editing a shared file outside of Eclipse).
It is also worth mentioning that Saros includes the ability to synchronise projects by using version control system information, rather than sending all data between participants. In this instance, if your shared project is under version control, all participants simply share repository information and can interact directly with the repository instead. Most important actions (update, switch etc.) will be sent to all participants and replayed in order to keep the project consistent. At the moment only Subversion is supported, but we hope to include support for other revision control systems in future.
Summary
Saros is a tool that provides a wide range of functionality essential to distributed collaborative programming. It makes up for the deficiencies in working separately by automatically sharing important awareness information. It provides multiple ways to communicate with your fellow collaborators. It has a range of supporting features to replace those capabilities missing in distributed settings. This range of functionality makes it a flexible tool, applicable in a number of common software development scenarios that would otherwise be difficult or slow to carry out. Finally, it is built on technologies and standards that are well-tested and open, making it reliable foundation for your collaborations.
Acknowledgements
The author would like to acknowledge the contributions and assistance of his colleagues in the preparation of this article: Prof. Dr. Lutz Prechelt, Stephan Salinger, Christopher Özbek and Julia Schenk.