It’s generally accepted that one of the reasons Barack Obama was re-elected as US President last year was the superiority of the IT system his campaign team used. It will come as no surprise to readers of this blog that it was built on open source foundations, as this fascinating article in The Verge explains:
The historic work the campaign was able to achieve in such a short time was made possible, Ryan [director of front-end engineering] and others argue, because the Obama tech team built on top of open source code — code that has been shared publicly and can be “forked,” essentially edited, by anyone. “The things we built off of open source should go back to the public,” says Manik Rathee, who worked as a user experience engineer with OFA [Obama for America]. The team relied on open source frameworks like Rails, Flask, Jekyll and Django. “We wouldn’t have been able to accomplish what we did in one year if we hadn’t been working off open source projects,” says Rathee.
The natural thing would be to give back to these communities by releasing their work built on it. That’s not, of course, because they have to: since the OFA code was never distributed, there is no obligation to make it freely available. Nonetheless, it could be argued that releasing the code is the right thing to do, and precisely what the people who wrote want to do; but the politicians are saying no:
When the campaign ended, these programmers wanted to put their work back into the coding community for other developers to study and improve upon. Politicians in the Democratic party felt otherwise, arguing that sharing the tech would give away a key advantage to the Republicans. Three months after the election, the data and software is still tightly controlled by the president and his campaign staff, with the fate of the code still largely undecided. It’s a choice the OFA developers warn could not only squander the digital advantage the Democrats now hold, but also severely impact their ability to recruit top tech talent in the future.
That last point is crucial as coding talent becomes more expensive, and companies strive to hire top people for their teams. Money alone isn’t enough: more and more programmers expect not only to work with the best – that is, open source tools and frameworks – but also to have the ability to give back to the communities whose software they build upon. That’s not entirely altruistic: letting people see what a good job you’ve done is a great way of earning peer esteem – and of getting job offers.
The article points out another reason for releasing the code:
“The biggest issue we saw with all of the commercial election software we used was that it’s only updated every four years,” says Ryan. It was these outdated options that convinced team Obama to build all the campaign tech in-house. If the code OFA built was put on ice at the DNC until 2016, it would become effectively worthless. “None of that will be useful in four years, technology moves too fast,” said Ryan. "But if our work was open and people were forking it and improving it all the time, then it keeps up with changes as we go."
That’s an interesting angle that I’ve not seen discussed before. In the past, when code was written for a particular moment, or a particular purpose, it was typically abandoned once that moment and purpose had passed. But releasing it as open source allows others to adopt and adapt it for their own purposes, updating the code as changes occur to the underlying technologies. Potentially, that will make it easier for the original creators to pick it up again if they need to at some point in the future: the codebase will be not be some dusty artefact from the past, but a living piece of code that is still being worked on and improved by a community of users.
It’s yet another way in which open source is superior to traditional software, providing both longevity and continuity that is simply impossible when special-use code is closed.