Robin Winslow
on 31 May 2017
This article is more than 8 year s old.
Nowadays free software is everywhere – from browsers to encryption software to operating systems.
Even so, it is still relatively rare for the code behind websites and services to be opened up.
Stepping into the open
Three years ago we started to move our website projects to Github, and we also took this opportunity to start making them public. We started with the www.ubuntu.com codebase, and over the next couple of years almost all our team’s other sites have followed suit.
At this point practically all the web team’s sites are open source, and you can find the code for each site in our canonical-websites organisation.
We’ve tried to make it as easy as possible to get them up and running, with accurate and simple README files. Each of our projects can be run in much the same way, and should work the same across Linux and macOs systems. I’ll elaborate more on how we manage this in a future post.
We also have many supporting projects – Django modules, snap packages, Docker images etc. – which are all openly available in our canonical-webteam organisation.
Reaping the benefits
Opening up our sites in this way means that anyone can help out by making suggestions in issues or directly submitting fixes as pull requests. Both are hugely valuable to our team.
Another significant benefit of opening up our code is that it’s actually much easier to manage:
- It’s trivial to connect third party services, like Travis, Waffle or Percy;
- Similarly, our own systems – such as our Jenkins server – don’t need special permissions to access the code;
- And we don’t need to worry about carefully managing user permissions for read access inside the organisation.
All of these tasks were previously surprisingly time-consuming.
Designing in the open
Shortly after we opened up the www.ubuntu.com codebase, the design team also started designing in the open, as Anthony Dillon recently explained.
