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:

1. Files in the package explorer are marked by icons. They show which files are currently being accessed by users write-access: yellow icons means they are currently open, green means they are currently in focus. The projects which are shared are also marked.
2. Text that is currently highlighted by another user is marked in the editor. The colour of the annotation corresponds to the colour of that user, so you know who has done the highlighting. The current position of their cursor is also shared by marking it in your editor.
3. Text that has been changed by another user is also marked, although in a slightly different shade of colour, so they can be told apart from highlights. Again, the colour of the marking corresponds to the user who changed it.
4. The current view scope of other users is shown in the sidebars. From this, you can quickly determine which portion of the file a user can see right now.

Saros also provides its own Eclipse view to manage the session:

5. This shows all users in the current session. Each entry has a context menu with further options. Furthermore, users who do not presently have the Eclipse application in focus are marked, so you remain aware of who is "away".
6. You can add users to a permanent list of collaborators, which is stored here in the buddy list, similarly to an instant messaging roster.
7. Every time you start a session, Saros automatically starts a multi-user chat room where all participants can instant-message each other.

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:

• Follow-mode: Whereby you can choose to follow a user's actions; whenever they scroll or switch to another file, the resulting view is replicated on your desktop.
• Simple user management: Users can be granted write or read-only access.
• VoIP: Currently one-to-one, although we hope to have conferencing soon.
• Distributed whiteboard: A canvas on which users can share simple sketches and diagrams.
• Screen-sharing: You can send a video stream of your desktop to another user, either the whole screen or in a zoomed "camera mode" controlled by the mouse.

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.

---

Click here to view the complete list of tools reviews