Being insular on tech wastes the talents of many party members who can code. The huge change in the ubiquity of APIs over the last ten years provides endless opportunities to harness this talent.
Political parties, despite what you may hear about stinking-rich non-dom donors, don’t have money to throw at anything they’d like. On tech they find themselves with the dilemma of any charity or non-profit organisation: do we have a non-committal rolling agreement with a consultancy firm, spending a lot more money but getting the security of a contract in delivery without HR costs? Or do we invest for the long term and get an internal team, albeit not quite at salary market rates?
I was the latter for the Liberal Democrats for a couple of years spanning across the 2010 general election. It was a point in my career where I’d just finished my first graduate job and I was expert in some areas (SQL, namely database transaction efficiency and the earlier versions of .NET) and weaker in others. The salary was certainly not market rate and, to put it into perspective, was roughly half what I am on now in the private sector. It was a deeply rewarding job, but it was very consuming, both in time and energy. As well as being the party’s solely employed developer, I was also the party’s solely employed tech support for the products I developed. I slowly realised that as I created more and more products, I was in turn creating more and more support calls from the less tech-savvy volunteers from around the country who used these products. Anybody who has worked for a political party can attest to the fact that members are demanding and seem to be under the unfortunate belief that they are each one of your line-managers. The ever-increasing bottleneck is something that will impact any organisation with limited funds – either they employ more developers or they throw more cash at contractors; often neither is possible.
Things were different back then. Collaborative coding was in its infancy. Github (a source-code versioning system that eases the notion of multiple developers working on the same code base or even hobbyists submitting improvements) was nowhere near the huge success it is now and the business case for fully-open APIs wasn’t properly realised until non-web applications such as smartphone apps started requiring them. Now, with the dawn of libraries like AngularJS which brings the application fully into the front-end and the back-end code simply dealing with the business logic and the interaction with databases, APIs are commonplace. [NB If you don’t know much about APIs, I wrote a lay-friendly article about them here when Moonpig had a small issue with theirs]
The culture on the storage of data has changed since then too. With the absolute need to access data from remote apps, e.g. on your smartphone, and the increasing use of cloud storage for images, contacts, emails, etc. people have become less and less bothered about personal data being accessible online. Convenience now trumps hostility. Also, most political parties now have their data online. When I worked for the Lib Dems they still used the old EARS system for electoral data which was installed on singular PCs and did not communicate, except via manual data exports, to instances on other devices. Now they have the much praised Connect system which can be accessed from anywhere at any time. Labour has Contact Creator and the Tories have long had their own online system to track voter intention.
Allowing coders within your party to develop tools that interact with your data is just common sense. This doesn’t mean they have unmitigated access to everything you hold – in fact, you might even just want to give them access to test data and insist that anybody who signs into their app to use the party’s data does so via an approved authorisation mechanism (I’m happy with OAuth 2, but I’m not getting into that debate here) so no login details ever touch their application and thus only those who are entitled to see the data do. If you’re extra concerned, you can even code-review their contributions on Github before you allow their apps access to live data.
What would you want them to develop? Well why not leave that to them? They work on the ground, they might have the ideas as well as the means for implementing them, but these might include:
- An Android/iOS app for your party members with the added benefit that your CLP/local party/association could send members push notifications to remind them there’s a meeting tonight or that there’s a deadline for sending internal ballots in. Or, more importantly for the party coffers, when their membership is about to expire and allow them to extend it.
- A caseworker app that extends existing canvass data so that when councillors are knocking doors at election time, they can also see the communications they’ve done for that specific voter or the casework they’ve succeeded in doing for that road. It makes for a much better conversation opener to remind people you’ve done stuff for them.
Political parties have long wondered how to manage the number of well-intentioned volunteers who want to develop things for the party. It’s now possible to just let them get on with it. The government have done really well with opening up their data to developers, with startups creating all sorts of weird and wonderful transport apps for example. It’s time the parties got on board with that too.