Our open source software
As part of our commitment to open source, we release everything we can with an open source license. This is a selection of the most interesting and useful components that you might want to use in your own projects.
You can find all of our open source software over on our Github page. Here’s a walkthrough of some of what’s there, what it does and why you might want it.
We use zc.buildout to manage our Python software stacks.
We don’t like buildouts that are hard to maintain. Our isotoma.recipe.facts recipe allows us to automatically adapt configuration with usernames, ip addresses, tag information and more that is gathered automatically at deployment time. Our isotoma.recipe.portmap recipe allows us to allocate ports relative to a single base port, reducing the number of variables that change between instances of a buildout. Our missingbits package adds the ability to repeat sections of your buildout many times.
Where possible we use software from the Ubuntu repositories, rather than installing and maintaining our own versions. This allows us to leverage the effort Ubuntu put into quality and patching, and allows us to rely on Ubuntu’s patch cycle for most issues. To support this we have custom recipes to configure stack components:
If you are deploying with buildout on Ubuntu you can use these as drop-in replacements for many of the more standard recipes, and you’ll find many of them have significant improvements over the originals. Any upstream authors who want to use this code, please feel free!
Django is one of our core competencies, and we use for preference for building complex web applications.
By default, Django’s support for LDAP is read-only. django-ldap-pixiedust provides bidirectional synchronisation of user profiles and passwords, allowing you to use Django’s user maintenance features to update your LDAP user directory.
Security 101: You limit who has shell access to your servers. But it is convenient for your developers to be able to see the logs of applications they wrote and support. django_logtail gives you secure live streaming of the logs your application is writing to.
Plone is an Enterprise-grade Content Management System that we use when really challenging document-centric content management is required, particularly where there are compliance issues.
We use plonestack to deploy and manage Plone. It takes care of dependencies and many other sharp edges in managing Plone deployments.
We deploy Plone with buildout using many of the recipes above. We use zkaffold to load content for developer and test builds.
We have a proof of concept automatic testing framework that does targeted fuzz testing of Plone sites. It’s called sashimi. The concept is simple: Try and find combinations of content that trigger 500 errors.
We use buildbot for continous integration. It’s written in Python and one of our DevOps guys is a subsystem maintainer and regular contributor.
We’ve submitted a bunch of patches upstream.
- We modified SVNPoller to persist its state between server restarts ensuring that it detected commits that occurred during downtime
- We added a LatentSlave implementation that used KVM (via libvirt) to allow each build to happen in a clean VM (a feature we use extensively)
- We allowed all change pollers to be triggered by web hooks, allowing simple progression from checking a source code repository on a timer to having the source code repository tell buildbot something happened.
- We patched WebStatus to allow additional Jinja2 loaders for people heavily customising their buildbots HTML
- We made the SVNPoller "multi-project" aware
We also submit bug fixes and refactor code to make it easier to customize.
Our biggest customisation is buildbot_travis. This provides a radically different approach to standard buildbot configuration. Uses can put a .travis.yml file in their source code control system. The buildbot server is given a list of repositories to watch and everything else is managed in these YAML files.
We maintain Yaybu, a simple python configuration management system and cloud provisioning tool.
Isotoma was founded on a principle of using Open Source software wherever it makes sense to do so. In practice this means that there have only been a handful of times when we’ve ever specified proprietary software for our customers.
We use Open Source software for a number of reasons, but two stand out: Quality and Maintainability.
The best Open Source software is at least as good, if not better, than the very best proprietary software. Common components of our stacks such as Linux, Postgres and Django are better than any of their proprietary rivals.
When you use proprietary software you are placed on the vendor’s upgrade treadmill. You have to take the versions they want, when they want you to, and you must continue to pay for support and maintenance, even when your platform is stable.
Although we use the latest recommended versions for new builds we’re happy to continue to support old deployments, because we have access to the source code of all components we know we’re able to support your software ourselves, without needing access to the vendor.