Open Source in practice – CleanerVersion

This blog’s topic of the month of September 2014 was dedicated to “Open Source”. This motivated us to put the pure theory of “Floss”, “Cathedrals” and “Bazaars” into practice. We succeeded! And hope that there will be a lot of copycats at Swisscom.

This blog’s topic of the month of September 2014 was dedicated to “Open Source”. This motivated us to put the pure theory of “Floss”, “Cathedrals” and “Bazaars” into practice. We succeeded! And hope that there will be a lot of copycats at Swisscom. 

“That’s it, the code is ready, tests are passing and the last couple of features are being completed. As already discussed with Mike [my boss], we want to publish the sources of the CleanerVersion module for Django (a web framework for Python) as open source. We are keen to upload the whole thing to Remains only…”

These were more or less our thoughts as soon as we had green lights for going open source with our CleanerVersion code (see below for a technical description). A couple of questions, however, persisted despite our increasing determination for the publication:

  • Do we need a license? If so, which one?
  • What channel will be used for publishing CleanerVersion, since the code belongs to Swisscom…?
  • Who else besides our boss has to agree on going open source?
  • What needs to be done once the code is published?
  • Who will maintain the code when we are not available anymore here at Swisscom or in this team?
  • Etc. (whatever else needs to be considered)

Questions upon questions, it seemed like this whole “open source” business was something to better be prepared for. I’ll try to give some answers to the above-mentioned questions using the concrete example of CleanerVersion.

In a first step, a license had to be chosen, which was appropriate for our requirements. But which are our requirements? Since we don’t have a lot of experience in publishing open source code, we had to ask ourselves a couple of questions (again). Does someone who uses our module and builds something new on top, has to publish the sources of their final product? Are we even allowed to commercially deploy the used components? Should CleanerVersion be used commercially? Luckily, there are some useful resources in the web which answer many of these questions. Further we got some helping hands internally (at the Legal department of Swisscom) to cover the rest of unanswered questions regarding licensing.

“Any Code that is developed as a result from a Swisscom work order belongs to Swisscom, if not specified otherwise.” This (kind of dusty and bumpy) sentence means, that Swisscom’s CI and branding needs to be correctly represented. To make things easy, there is a Swisscom Organization on Github where open sourced code developed at Swisscom gets published. This also includes forks of third party repositories being extended to correspond to internal needs and deployed somewhere at Swisscom.

Meanwhile, Github is part of a whole software development ecosystem, that grew over time driven by the growth of open source communities and the number of open source projects. Integration among components of that eco-system is seamless. What is nice about it, is that it’s mostly usable for free as long as your project is open source. There is for example the continuous integration tool Travis CI which is used for testing, the Coveralls test coverage tool telling us how good our tests are, or the ReadTheDocs platform for having your project’s documentation generated and published.

Since we’re just “normal” project collaborators at a Swisscom project, we knew we had to ask our boss if it would be okay to open source parts of the project. For obvious reasons, the maintainers of the Swisscom Github Organization also entered the game and gave us their go-ahead, by giving us the possibility to publish the code on the portal.

But now, let’s go: “git remote add…” , “git push origin master” and the most important step was done.

From that moment on, the device was “wait for contributors!” – you could think… But that’s not quite how things happened in our case. Beside the fact that our daily jobs continued, we also wanted to spread the word and make CleanerVersion better known. So, we sat down again and tried to identify the channels, forums and platforms, where we would reach out for potential contributors and users being interested in using our module. For Django-specific open source modules, Django-packages is a cool platform giving the possibility to compare multiple packages with each other. The ultimate source for Python modules is called PyPi. Every other action that generates some visibility potentially draws the interest of some future contributor.

In order for Swisscom to ensure that published sources are not used against their intent as specified by the license, a central directory of published open source software is being planned. That directory would include information about what component is published with what license. It should be possible to have a tool enabling a systematic approach of having an overview how the code is used and whether it violates the regulations issued by the license.

As everyone knows, it is important to document code if you want it to be used by someone else. So, since we wanted to build up a community, documentation was crucial in our case. Comments and other docs (being automatically formatted using tools like Sphinx) are also useful if we need to hand the code over to some other Swisscom collaborator. With them knowing the concrete use case of the code and knowing the docs they would be ready for taking over the maintenance lead for the module.

Other than all these points, we should not forget that source code files are considered as documents, too. And there is a classification policy at almost every bigger company. So, everything that was being open sourced had to be classified as “Public” or it had to be removed if it had to be handled more sensitively.

That’s about what happened during the past couple of weeks with regards to CleanerVersion – it would be a pleasure if you would take a look at it, too!

Oh, just one more thing: Shortly after publishing the code we had the pleasure to welcome our first external contributor! How did they participate? They corrected some typos in the comments… every contribution is valuable! 😉


CleanerVersion for Django

CleanerVersion is a generic Historization and Versioning solution for Django, which allows tracking changes on conventional Django model objects and their relationships over time. It is then possible to query for the state of a network of objects at a given point in time.

The CleanerVersion module implements the paradigm of Slowly Changing Dimensions (Type 2) which is tightly bound to Datawarehouse theory.

There are only a few dependencies: CleanerVersion requires either Django 1.6 or 1.7 and a relational database. It has been tested on SQLite3 and PostgreSQL9.3. Once these two parts are set up, you are ready.

Besides the navigation of one object version to the next or previous one, it also supports querying across relationships (one-to-many and many-to-many) at a specified point in time.

The development of CleanerVersion was a collaboration of Swisscom and Liip in the context of a Swisscom project.