Collaboration/Technical Info

« Collaboration

This content relates to a deprecated version of Mbed

Mbed 2 is now deprecated. For the latest version please see the Mbed OS documentation.

What do we have now?

Right now the majority of the above features already exist within

Regular users will be familiar with publising and importing programs and libraries, which has been a very popular feature, with over 7000 versions of programs and libraries published.

However, some types of more collaborative workflows are more difficult than they should be.

For example it's not easy to really work together on a program or library, because:

  • It's difficult to see exactly who changed what code and when.
  • There's no way to automatically merge two sets of changes to a published program
  • There's no way to allow other people to make changes to a published program

Furthermore some of the underlying technical details of how code publishing works on mbed means that we have ruled out gradual improvement or tinkering around the edges; a completely new approach is required!

Collaboration 2.0

Here's what we built.

First, we should define some terminology. For the purposes of discussing collaboration:

  • The mbed IDE is the Client
  • The website is the Server

Everything within the Client is private and completely seperate from the website (the 'Server'). Therefore collaboration with the outside world can only happen in the context of going via the Server.

Given that mbed is currently a quite self contained environment, we are in a slightly unique position of being able to control both the client and the server. This is contrast to other web based collaboration systems such as Github (, Google code ( and Bitbucket ( We could design any system we wanted.

However, we have chosen to make mbed collaboration 2.0 non-proprietary. There's several reasons for this including:

  • Not reinventing the wheel - version control is not a unique problem to mbed
  • We benefit from the great work done by others in this field
  • The system we design will be more familiar to those with experience of similar systems
  • Keeps our options open for improved integration with external tools

After evaluation of several different approaches, we have chosen Mercurial ( the foundation of our collaboration system. This again is for a number of reasons, including:

  • Mercurial is a distributed version control system which enables the peer to peer development model we are aiming for. More at (
  • Mercurial is well supported by a variety of languages and tools across several platforms (Windows/Mac/Linux)
  • Mercurial is actively developed and used by a large number of projects
  • We felt that Mercurial is easy and logical to use on the commandline
  • Mercurial is written in Python, and so is a lot of, so the integration is a lot smoother

See also: Migrating to the new system and Introduction

All wikipages