You are browsing the archive for Updates.

Presenting public finance just got easier

Tryggvi Björgvinsson - March 20, 2015 in Technical, Updates

This blog post is cross-posted from the CKAN blog.


CKAN 2.3 is out! The world-famous data handling software suite which powers, and numerous other open data portals across the world has been significantly upgraded. How can this version open up new opportunities for existing and coming deployments? Read on.

One of the new features of this release is the ability to create extensions that get called before and after a new file is uploaded, updated, or deleted on a CKAN instance.

This may not sound like a major improvement  but it creates a lot of new opportunities. Now it’s possible to analyse the files (which are called resources in CKAN) and take them to new uses based on that analysis. To showcase how this works, Open Knowledge in collaboration with the Mexican government, the World Bank (via Partnership for Open Data), and the OpenSpending project have created a new CKAN extension which uses this new feature.

It’s actually two extensions. One, called ckanext-budgets listens for creation and updates of resources (i.e. files) in CKAN and when that happens the extension analyses the resource to see if it conforms to the data file part of the Budget Data Package specification. The budget data package specification is a relatively new specification for budget publications, designed for comparability, flexibility, and simplicity. It’s similar to data packages in that it provides metadata around simple tabular files, like a csv file. If the csv file (a resource in CKAN) conforms to the specification (i.e. the columns have the correct titles), then the extension automatically creates the Budget Data Package metadata based on the CKAN resource data and makes the complete Budget Data Package available.

It might sound very technical, but it really is very simple. You add or update a csv file resource in CKAN and it automatically checks if it contains budget data in order to publish it on a standardised form. In other words, CKAN can now automatically produce standardised budget resources which make integration with other systems a lot easier.

The second extension, called ckanext-openspending, shows how easy such an integration around standardised data is. The extension takes the published Budget Data Packages and automatically sends it to OpenSpending. From there OpenSpending does its own thing, analyses the data, aggregates it and makes it very easy to use for those who use OpenSpending’s visualisation library.

So thanks to a perhaps seemingly insignificant extension feature in CKAN 2.3, getting beautiful and understandable visualisations of budget spreadsheets is now only an upload to a CKAN instance away (and can only get easier as the two extensions improve).

To learn even more, see this report about the CKAN and OpenSpending integration efforts.

New Features in December 2013

Tryggvi Björgvinsson - January 7, 2014 in Technical, Updates

Happy New Year OpenSpending! The last month of 2013 was exciting. Even though the community took some time off around the holidays we still managed to squeeze in some really great developments and some big releases.

Image by mattcornock (cc-by 2.0)

Commandline loading

Our loading API got some attention this month when one community member wanted to load data into OpenSpending directly from the commandline. That caused some problems so we needed to do some modifications, both to our documentation which wasn’t clear enough and also some code changes.

After those changes we were finally ready for commandline loading with the help of the wonderful cURL software. How you may ask. It’s as easy as doing:

curl -X POST -H "Authorization: ApiKey <your-api-key-here" --data "csv_file=<url-to-your-csv-file-here>" --data "metadata=<url-to-your-model-file-here>"

If you have a lot of similar data to upload you can now script it with a simple commandline call like that (or a similar one from your favourite scripting language).

Just like the community member said when we finished:

“Time to load some data…”


We continue to provide better international support to our users. In December, two new languages went up to 100%: Nepali and Russian. The teams behind those translations did a great job. The Nepali translation went from zero to complete translation in only a few days while the Russian had slightly bigger problems. For example, they didn’t have a Russian word for dataset (which is a pretty important term in OpenSpending). The Russians are even taking a step further and reviewing the translations to ensure the quality of the translations. This is a precedent other translators can take up, even though we won’t enforce it.

Other climbers on the translation list in December were Czech, Italian (both up to over 60%), Indonesian which is not far from surpassing German (which had been completely translated before we uploaded the new strings back in November) and French, which is not far away from Indonesian.

So, we can start to get excited about some more complete translations soon. Will it be one of the more recent translation teams, one of the older teams, or a completely new language — never before seen in OpenSpending? You can help us reach as many people as possible by helping us translate OpenSpending into your language (if it isn’t available in it yet). Just go to our project page on Transifex and offer help with translations into your language (or ask us to create your language if it isn’t there already). When accepted, just jump in and start translating OpenSpending.

OpenSpending visualisation library

Probably one of the bigger changes in December was what we did to OpenSpendingJS, which we use for our visualisations. We took the first official step in our move away from the bunch-of-javascript-code approach to versioned releases of a javascript visualisation library.

This means that we build a version of the library and you can just drop that into your web page and be certain that it won’t change in the future. This frees us from the problem of not being able to take OpenSpendingJS into new directions. Another big change this brings with it is a clearer distinction between OpenSpending core javascript and OpenSpendingJS visualisations. The previous way to add a visualisation was weird. Either you added it into the OpenSpending core visualisation builder or made it available outside it in a way developers had to grok the whole project to be able to use some visualisation.

Now we’ve made it as easy as possible to add visualisation based on OpenSpending to your sites, drop in the javascript file and create a beautiful visualisation with a simple div element. Want to create a treemap for your dataset? Just do this:

<div class="treemap" data-dataset="<your-dataset-id>" data-drilldowns="<first-drilldown>,<second-drilldown>,<third-drilldown>"></div>

Want more configurations of your treemap. You can also create these elements with a jQuery extension call:

$('#id-of-div').treemap({/*configuration object*/});

This also hopefully makes it simpler to contribute new visualisations to OpenSpendingJS. Just follow how all of the other visualisations are doing things by looking at the code in src/visualisations/. They’re built as jQuery extensions and are well commented.

We’ve already made two bigger releases (0.1.0 and 0.2.0) and one bugfix release (0.2.1) so you can expect a lot of activity around these in the future. Want to help out? Just dive in and help us mold and improve OpenSpendingJS. One thing we want to do is clean up the older code a bit, perhaps package it up in one release and then just remove the code. We won’t hit version 1.0 until at least when we’ve done that.

OpenSpending WordPress plugin

Another thing the new approach to creating the visualisations in OpenSpendingJS as a library allows us to do is create CMS plugins for our visualisations… and that’s exactly what we did. We released our WordPress plugin into the wild. We started work on it a while back but now, with release 0.5, we think it’s usable to the public.

First of all it includes the new OpenSpendingJS library (version 0.2) and we can easily update it with new releases of the OpenSpendingJS library. The other reason is that we submitted it to WordPress and got approved so we’ll be adding it as an official plugin, installable from any WordPress instance in the world with a click of a button (we have yet to upload it, but that’s going to happen really soon).

The WordPress library uses the new visualisation rendering technique by creating divs with the visualisation configurations. We try to standardise the input for all visualisations to focus more on ease of use instead of configurability. If you’re configuring the visualisations a lot, we believe you’ll know how to add a javascript file to your page and call it directly. For some users, ease of use is more important and that’s where the WordPress plugin comes in. Interested in how it works? Take a look at the documentation

This is yet another software package we’re maintaining as part of the ever-increasing arsenal of OpenSpending tools. That’s why we need your help! Do you know PHP/WordPress? Help us improve and maintain the WordPress plugin. It’s quite simple code. Go take a look at the repository.

Bar charts

One thing which finally got released with the new OpenSpendingJS library after having been around for a long time in the code branch containing the new library set up is bar charts. Yes, we now have bar charts! The bar chart implementation that we had in that branch was developed to present time series only, but before releasing the first version of OpenSpendingJS they got a face lift. They can now show time series if you include time in your drilldowns but they can also show COFOG categories (with our well known icons).

This got added into the OpenSpending WordPress plugin discussed earlier so you can easily create the bar charts now, either using OpenSpendingJS directly or the OpenSpending WordPress plugin. Yay!

Inflation support in visualisations

A while back we implemented inflation support in OpenSpending. This has only been accessible to those who know about it but with the release of OpenSpendingJS version 0.2 we have added support for inflation adjustments. This is especially important when creating time series with the new bar charts since that compares data across history and each amount is valued differently.

Inflation adjustment is done automatically in the OpenSpending WordPress plugin where we try to inflate to the value of the year before the current year. In the case where this fails, for example if there is no inflation data available (e.g. when showing budgets for future years or just if the country hasn’t got good data) we don’t do the inflation adjustments.

In OpenSpending this is done using the inflate configuration where you define the target year you want all amounts to be inflated to.


A while back we created three issues with focus on improving the code readability and speed of OpenSpending. These issues were the results of running a python source code checker, flake8 (which is just a wrapper around other source code checkers). The issues all touched upon three different checkers, one was for pep8 compatibility (coding convention), another was for pyflakes (unneccessary imports) and the third was about McCabe’s complexity (too complicated methods).

Running these checkers on the OpenSpending code base gave us a lot of errors, i.e. areas for improvement. Near the end of the year a community member decided to start doing something about it, especially the flakes errors (is there anything better to work on than flakes in December with snow flakes all around us… well if it’s snowing outside).

There were some flake errors left unfixed because they caused test failures so we need slightly more development effort to fix them but we still fixed a lot. The community member that contributed the fixes is a python beginner and will use this to learn more about python. This is just great because this shows that we truly are the newcomer friendly community we want to be. You can join and improve your skills while you work on something that can change the world!

Want to contribute? The three issues are still open for volunteers. You could for example work on the pep8 errors. Nobody has called dibs on that one.

Other Changes

There were of course some other changes we did in December like swapping out a footer link to YourTopia for Spending Stories. We still don’t think we’ve done Spending Stories enough justice on the page so we’ll be looking into making it more prominent. If you haven’t checked that project go to and have a look around.

Remember that you can help develop OpenSpending on many fronts, be it the core OpenSpending platform, OpenSpendingJS, Taxman, the satellite site template or any other software project in the OpenSpending project list. Just have a look at our OpenSpending issue tracker or our OpenSpendingJS issue tracker, that’s where most of the issues are being tracked. Feel free though to add features you think are missing in any project and become a contributor to the OpenSpending project.

Don’t know where to start? We’ve highlighted some stuff on our OpenHatch page.


agonar, Neil Ashton, Nikesh Balami, Vitor Baptista, Mark Brough, Sukma Budi, Lucy Chambers, Pierre Chrzanowski, Iván Cruz, Manish Dangol, DarisLi, inxaoc, jbricetetka, Martin Keegan, kshitizkhanal7, Friedrich Lindenberg, Elisabetta Lombardo, M2M, Leandro Martelli, Alexey Medvetsky, michalskop, Randy Moore, Prakash Neupane, Nela, nichtsistwahr, nkissel, Olga Parkhimovich, Anders Pedersen, Rufus Pollock, Bansaj Pradhan, JanaSekaninova, Nick Stenning, rajansilwal, and Marco Voormolen.

The community contributions continue to grow so this list is getting difficult to compile and there are probably a lot more community members who have contributed somehow to OpenSpending. Just let us know and we’ll add you to the list.

Image of bar chart sketch used in this blog post is by mattcornock on Flickr, released under Creative Commons Attribution, version 2.0.

New Features in November 2013

Tryggvi Björgvinsson - December 12, 2013 in Technical, Updates

It’s so exciting to participate in the OpenSpending project. We continue to raise the bar when it comes to what we as a community can do and that’s just what we did in November. The community is growing and achieving more (as you do when you grow) and this is what makes OpenSpending so exciting to be a part of right now.

Image by (cc-by 2.0)


Sadly we haven’t been putting much focus on translations in the last months but that changed in November. We put a lot of effort into internationalising (often abbreviated as i18n), which means we put effort into making OpenSpending better at handling different global communities. The biggest effort would be marking strings as ready for translation, which we did. This had been done before but a lot of the strings weren’t marked so we ended up with 150% more strings that needed translation.

The second step in the process is the localisation (often abbreviated as l10n), which means doing the adaptation to a specific region or culture. Again the biggest effort there are translations. Going through the strings we marked in the previous step and translating them into a specific target language (locale). The awesome thing is that, that’s exactly where our community shines!

Japanese was the first complete translation (100% of all strings translated), not counting English. The most impressive thing was that the Japanese translation team finished the translations only five days after we pushed out the new strings! Bosnian was also quite impressive. It went from zero to more than half of the strings translated in a single day thanks to a single translator! Italian has been steadily getting more and more translations and now has the second most translated strings thanks to a translator who also does French. These all happened in November, just days after we pushed the new strings so it’s going to be really fun to watch how we grow in translations in the coming months.

Translations are really important for a global project like OpenSpending. If you want to help us reach as many people as possible you can help us translate OpenSpending into your language. Just go to our project page on Transifex and offer help with translations into your language (or ask us to create your language if it isn’t there already). When accepted, just jump in and start translating OpenSpending.

Jinja2 migrations

One of the reasons we were able to push a lot of the new strings for translations was that we finished the migration to Jinja2. Back in September we wrote about how changes in July and August had caused OpenSpending to have two navigational bars. That was because we were in the middle of a transition from the Genshi template system to Jinja2. Pages served with Genshi had a different navigational bar than those served with Jinja2.

We have now completed the migration so we’re only serving a single version of the navigational bar on OpenSpending. Besides being less confusing for the user and improving i18n the Jinja2 templates are simpler for most developer which means we’re now even more newcomer friendly than before (there’s always room for improvement). We hope that this will drive more people to help us out developing and maintaining the the HTML output of OpenSpending.

Are you good at or interested in creating web pages? You can help us make OpenSpending in the browser work better for the users and look better. We use Jinja2 so it’s easy as eating a pie to get started and help out. Take a look at our howto hack for pointers on how to dive in (or offer help).

Measures and metrics

It’s not enough to just have an easy to use template system and an engaged community. We also need to know what to change. That’s why we decided to start watching you… no, not in the NSA revelations way. We just created some measurements to track how users use OpenSpending. What are they looking for and how do they get there? This can then feed into a site redesign to serve users of OpenSpending better, instead of just randomly changing things and hoping it’s good.

We do, of course, have this sneaking suspicion that users go to OpenSpending to either find or upload spending datasets. That’s why we also did slightly more than just track mouse clicks and site visits. We created a user scoreboard which is only available for administrators on OpenSpending. The scoreboard is pretty simple. What it does is see how many datasets users are connected to. This helps us analyse things like, are all dataset uploaded by an elite group of users (who might have some bias) or is there a good diversity of users uploading the datasets (the latter being more beneficial to OpenSpending). The scoreboard also shows us how many users are registered but still haven’t uploaded any datasets. This is an indicator that people might find uploading datasets difficult (which we can then tackle).

So basically we’re just analysing how people use the site to identify problems in order to address them and improve the experience for everyone.

Community home

We already made our first change and we actually didn’t need any analysis to do it because it was really straightforward and obvious that it had to be done.

Back in September, we finalised our community page when we renamed it from to because that’s what it is, the home of the OpenSpending community.

The problem was that hadn’t really been integrated into the OpenSpending platform at so in November we finally did just that. We updated the links in the navigational bar to go to different community pages instead of serving content via and we removed all content except the dataset management aspect and the front page from and just redirect people to instead.

So we’re creating a better separation between the platform and the community. The community is much bigger than a single piece of software. We also updated the site so that instead of serving the blog on the front page we now have a landing page that helps people find what they’re looking for without having to guess where in the navigational bar on the community site it is.

The control of the community home is now more in the hands of the community itself instead of some developers. So now developers can now also focus more on improving the tool itself, instead of guiding community members through a technical maze of how to contribute documentation, blog posts or whatever the community as a whole wants to do in their cyberhome.

Development community growth

The OpenSpending community is growing fast. One concern we have is that the developer sub-community, which hasn’t been growing as fast (but still growing) won’t be able to handle this growth efficiently which would be a big shame. So we are now going to try and reach out to prospective developers who might be interested in our mission and let them know about us.

In November we took a small step in that direction. We put up a profile for OpenSpending on OpenHatch which is a project that is “dedicated to matching prospective free and open source contributors to communities, tools, and education.” There are a lot of interesting projects on OpenHatch so we have some competition on the site, but since OpenSpending has a mission to make the world better for everyone, we have a good chance of getting people interested. We are making efforts of being newcomer friendly. We just need some visibility.

You can help us reach out to developers. Do you know people who might be interested in developing OpenSpending? Let them know about us and help us get them engaged! You can direct them to our community or you can point them to our OpenHatch page.

If you know about any other outreach programs where we can find prospective developers, let us know or help us get in there. We are newcomer friendly and we are an exciting project. This way we all put in a helping hand to help our community grow by helping our development community grow.

Permissions API

On more technical notes, we created a new API resource to check for permissions a user has on datasets in OpenSpending. Checking for permissions might sound a little bit weird but this enables external tools to check if their users (who are also users on OpenSpending) have permission to create, read, update or delete a dataset before they do something. This can, for example, save a lot of bandwidth because the external tools can avoid downloading big datasets in vain because a user didn’t have the right permissions.

We are already working on a project, called os-upload, which allows users to upload datasets on a different page which then sends the datasets onward to OpenSpending.

Currently this uses the API key of users to interact with the site on the users behalf (so that the datasets will be uploaded as the user, not the site). The API key is used to check for permissions and then it’s used again to upload the datasets.

Note that you should avoid sharing your API key with anybody since the API key allows others to pretend that they are you. We will run os-upload as part of OpenSpending, wrapping it under an SSL certificate for secure communications. We’re working on this now but until then we recommend you to test things out with a test account rather than your real account. Going via HTTPS (SSL certificates) is of course not the ultimate security we want but at least we’ll mitigate the risk that somebody gets your API key and it’s just good to have around.

We need your help!. If you know your way around authentication for external sites without giving out your credentials or API key (for example via OAuth or another way) get in touch and help us make OpenSpending and external sites more secure.

Enforced Security

Talking about security and passing API keys around, we decided to make HTTPS the default and only way of interacting with, just like we plan to do with with os-upload. In October we increased our security by adding SSL certificates and HTTPS to In November we enforced it. If you go to you will be automatically redirected to and a secure communication channel established.

This way we can, with higher confidence, use API keys for authorisation and be less afraid that someone might be able to pretend to be someone else on OpenSpending. It’s just all around better to have security by default instead of having it optional.

Simplified API authentication

The enforced security allowed us to simplify the API authentication which was developed for the data loading API. If you wanted to load data via the API you had to use two API keys, one public and one secret. You had to sign your request with your private key which OpenSpending was then able to verify to be sure you were you.

With the enforced security you now only need one API key which you put into the request header (without doing any computations or processing) and OpenSpending can use that API key to look you up. Of course this is why it’s important that you don’t share your API key with anybody because that means they’ll be able to pretend that they’re you.

But now it’s way simpler to load data into OpenSpending. Bring on the datasets!

Taxman standardisation

We touched a lot of important aspects of software development that don’t involve coding in November. Translations was a big thing but we also did documentation. The biggest effort in documentation was the first attempt to standardised how Taxman should work.

We created a page on the Taxman wiki to discuss and try to find the common API for all jurisdictions. This is a first stab and trying to create this common API based on the jurisdictions we already have. We expect this to evolve over the coming months and in the end we’ll have a simple, generic way to access all of the jurisdictions in Taxman.

As it says in the Taxman README:

“At the moment we place no restrictions on what you return from the
calculate function. That said, it is hoped that as we add more jurisdictions
we will work out which parts of the API we can standardise. Consistency
across jurisdictions is very important if TaxMan is to be useful, and at the
moment we are relying entirely on contributors’ discipline to ensure it.”

We’re now heading into the standardisation phase which is very exciting. Do you want to help? We need input about all jurisdictions so we can get this right. You can read through this to see if we’re missing something important for your jurisdiction (or you can even implement the calculations for your jurisdiction according to the common API to see if it works). Just hop on to the Taxman repo and dig in.

Other Changes

Of course there are other changes we did in November. We, for example, updated READMEs to make the information a bit clearer for users and developers, created some documentation (on and worked a lot on the os-upload project.

Remember that you can help develop OpenSpending on many fronts, be it the core OpenSpending platform, OpenSpendingJS, Taxman, the satellite site template or any other software project in the OpenSpending project list. Just have a look at our OpenSpending issue tracker or our OpenSpendingJS issue tracker, that’s where most of the issues are being tracked. Feel free though to add features you think are missing in any project and become a contributor to the OpenSpending project.


Everton Zanella Alvarenga, Nigel Babu, Maya Barisic, Lucy Chambers, Tajima Itsuro, Yoshihide Jimbo, kawando, Martin Keegan, Iwao Kobayashi, Elisabetta Lombardo, masanori.katsuragawa, Takano Mitsuhiro, Prakash Neupane, Takashi Nishibayashi, nyampire, 高木祐介, Anders Pedersen, Rufus Pollock, Joel Rebello, rigg, Toshihide Sato, Hal Seki, Nick Stenning, tosseot, and William Waites. This was quite a big month in terms of development help so there are probably a lot more who have contributed somehow to OpenSpending. Just let us know and we’ll add you to the list.

Image of different currencies used in this blog post is by on Flickr, released under Creative Commons Attribution, version 2.0.

New Features in October 2013

Tryggvi Björgvinsson - November 14, 2013 in Technical, Updates

Compared to September, October may seem a less active month in terms of development. However, though there were fewer features in October they were bigger and took longer to develop. Let’s just dive in.

Image by CarbonNYC (cc-by 2.0)

Increased security

One of the most important features we added in October was SSL certificates, or access via HTTPS. This means we can now encrypt communications between you and the

When you use websites you usually send things like cookies and headers in plain, text (visible for those who want to see it). Cookies are for example used to store who you are and let the server know. If these are sent in plain text, other people can pretend that they are you. Remember how Firesheep was used to gain access to people’s accounts on Facebook, GMail, etc.?

When using our API users can authenticate via the headers they send. When people from CERN added the Data Loading API to OpenSpending back in September they wanted it to be more secure, so instead of just sending your API key you had to use a private api key to sign your request. If we hadn’t done that, other people would have been able to just grab your API key from the plain text header and then start uploading data as you which could cause you some problems.

With HTTPS all that gets encrypted so it’ll be harder for those bad people to pretend they are you (and probably not worth the effort since they’d have to break the same security measures as online banking uses).

Now this is not perfect yet. We don’t enforce the use of HTTPS yet so you will have to ask to serve you the content over HTTPS. We are preparing to enforce traffic over HTTPS in November so you can be secure without even thinking about it (you actually should never stop thinking about security, but this will make your life easier). Until then you can use browser plugins like HTTPS Everywhere that try to use HTTPS first.

When we have the enforced HTTPS we will fall back to the old version of the API authentication because the communications will be secure enough to drop your API key into the header without compromising your account. Easier and more secure times ahead.

Faster dataset index

One of the features we introduced in July and August was a dataset page. The reason for it was that it took a long time to load all of the datasets in OpenSpending so when users clicked on the Datasets link in the navigational bar, nothing happened (even though behind the scenes the browser was just waiting for a response).

We decided to go for a quick fix back in July and August and redirect people to a specific dataset page instead of doing things behind the scenes. That way users would at least see that the browser was working. We also acknowledged that this was not the best solution and invited you to help us out.

We’re now proud to say that the dataset page has been improved. We’re still using the dedicated dataset page but we have put it behind a cache so it’s way faster. We went from the 15 seconds (and up to 24 seconds) measured down to around 0.3 seconds! That’s an awesome improvement and if you’ve ever doubted caching, this is one good reason to use it.

Now there are still tweaks that we could do. For example when the dataset list updates (e.g. when somebody publishes a new dataset) we need to regenerate the cache. We don’t do that automatically at the moment so the first user to visit the dataset page will have to wait all those seconds for anything to happen. We would like to autogenerate the new cache so you’ll never have to wait for seconds.

There are two approaches we could take. One would be to find the bottleneck in the dataset index functionality itself, the other would be to regenerate on dataset publication and serve the older version until the new one is ready.

Would you like to help us out? You can offer your help as both a code reviewer or a coder. We can help you get started. Just let us know you’re interested on our developer mailing list or our IRC channel, #openspending on!

Bosnian budget analysis

For quite some time we have been working on a satellite site, similar to Where does my money go? for Bosnia and Herzegovina, In October we finally launched the Bosnian site! If you look at these pages (Where does my money go? and you’ll see similar functionality but there are a lot of special things about

The country is divided into three entities (they actually have rotating presidents from these three entities) and one of these entities is further divided into cantons. The tax system is different in each of the three entities and people look at salary and taxes differently there than in the United Kingdom.

So we had to make some big changes to the daily bread visualisation, which in their case became a tax calculator (not showing the daily taxes, but just how the taxes are split). We took the chance and redid how we created the colours in the visualisation so the bubbles now follow the same colour scheme as in the bubbletree (on Where does my money go? all of the bubbles were purple).

We also commented the code and hopefully made things more simple for those who want to put up a daily bread visualisation on their site. If you’re interested in the code behind the page, it’s hosted as a github page and the code is accessible from that repository.

Are you setting up your own satellite site? Join the developer mailing list or our IRC channel, #openspending on and we can help you out if you run into some problems.

Other Changes

As always there were smaller changes made to OpenSpending. These other changes were mostly related to the three big changes mentioned above. Things like restructuring the code around the caching mechanism, moving assets behind a CDN (content delivery network), new taxman jurisdictions (actually added a while back) and preparations for the new OpenSpendingJS visualisation library.

Remember that you can help develop OpenSpending on many fronts, be it the core OpenSpending platform, OpenSpendingJS, Taxman, the satellite site template or whatever. Just have a look at our OpenSpending issue tracker or our OpenSpendingJS issue tracker, that’s where most of the issues are being tracked. Feel free though to add features you think are missing in any project and become a contributor to the OpenSpending project.


Thanks to Jiri Kuncar, Alberto Rodriguez Peon, Joel Rebello, and Nick Stenning for their contributions (there are probably a lot more who’ve contributed somehow to OpenSpending so don’t be sad if we forgot you – it’s a bit hard to manage, just let us know and we’ll add you).

Image of padlock used in this blog post is by CarbonNYC on Flickr, released under Creative Commons Attribution, version 2.0.

Features in September 2013

Tryggvi Björgvinsson - October 4, 2013 in Technical, Updates

Image by NCTRUCKINGITEMS (cc-by 2.0)

Like we said in our last development update, September was going to be awesome. And boy oh boy did that come true. There were a lot of great features added to OpenSpending. Some of them we can safely say might change the way people use OpenSpending.

Multiple measure aggregation

The amount measure is required in all datasets in OpenSpending but that does not mean that it has to be the only measure. You can add how many measures you like. For example, amount could show the amount actually spent and you could have another measure budget to show what was budgeted.

For some time now it has been possible to use another measure than amount when aggregating via the api. The only thing you’d have to do is add a url parameter measure, for instance measure=budget to aggregate over the budget measure instead of the amount measure (amount is default).

However there was a problem if you wanted to show the budget and the amount on the same page. You would have to make two requests to OpenSpending, one for the budget and another for the amount. This would make your site (or whatever you have that accesses the aggregation API) slower and adds extra processing to OpenSpending (since it now has to access this twice).

We have solved this! Now you can aggregate multiple measures in the same request. You still use the same url parameter (measure) and you separate the measures with a | just like you do with drilldowns: measure=budget|amount

Broken terms of use

Sander van der Waal noticed something really bad about OpenSpending. When users register for an account on OpenSpending they have to agree to our terms of use. There’s a link to the terms of use on the site but that link was broken and has been broken for some time.

Does that tell us more about how many people actually read terms of use or has this been driving people away from registering? We can’t know but if it is the latter then this has been fixed now. You can now actually access the terms of use and read them. So if you didn’t want to because you couldn’t see the terms of use but agree to them now that you can read them, please come and register.

Timestamps in dataset.json

In August we added important dates to web pages for the datasets so that users can quickly see when a dataset was created or last updated and the time range of the dataset.

You couldn’t access this from the API though. Well you can access the timestamps in the dataset by fetching the JSON at and build the date range. But the timestamps for the dataset in OpenSpending, i.e. created and last modified, were not accessible via the API.

We have now added them to the dataset’s json representation. So if you fetch the json at you’ll see an object called timestamps where you can access the created and last_modified timestamps.

Cleanup of issue tracker

At our September developer meeting we discussed our issue tracker which had passed 100 open issues. We decided to move a few of them into OpenSpendingJS and take a stab at cleaning up any remaining issues. Mark Brough from stepped up and helped us get the issue tracker into shape. We’re now down to roughly 60 issues and we’ve tried to label them (there are still some unlabelled issues left).

Mark Brough actually suggested we should set ourselves a goal of having less than 50 (or even 30) open issues at a given time. That’s a great goal and we should definitely aim for it.

Do you want to help us achieve it? Don’t know where to start? We’ve labelled issues with Volunteer: simple, Volunteer: medium and Volunteer: hard in our issue tracker. Take a look at how we hack on OpenSpending and start submitting pull requests. It’s very easy and we’re a very friendly newcomer community!

Source control

When adding data to a dataset users add a source, analyse it, test it and then load it. The sources added can sometimes have errors in them, errors that are discovered in the analysis, testing, or the loading phase. This means that the source editor can get pretty cluttered.

We now added a possibility to do some source house cleaning. You can remove sources that haven’t been successfully loaded into OpenSpending. The reason you can’t remove a loaded source is that we can’t be sure if we’ll be able to access the source url again to find the right entries (watch out for our data package support which might solve this).

We also tried to improve the user interface a bit. You usually could only work with the source you added last. We now allow you to work with (and therefore delete) older sources… and we have shiny buttons!

Inflation adjustments

A lot of users want to be able to compare datasets between years. How much is my government spending on health care this year compared to 5 years ago? This is a common use case but if one looks closely, all across the world governments seem to be spending more on everything than the previous years (well… it depends). The point is, because of inflation everything goes up and skews the numbers. You can’t really compare data from now with data from 5 years ago unless you adjust for inflation. After taking inflation into account you might see that your government is actually spending less on health care than it seemed like.

Since this is such a commons use case we felt it was quite important to support inflation adjustments in OpenSpending and now we do! Woah! This is huge! We can do it on an entry basis and for aggregations. The only thing required is for you to add an inflate URL parameter with the date you want to inflate everything against, inflate=2012-04-22, so that all amounts will be represented as they were valued at that particular date.

Now, there’s a huge catch to this. Inflation adjustment in OpenSpending is far from perfect. We don’t have good enough data to do proper adjustments because data is released infrequently and valued differently across countries. The data is also quite granular. The date 2012-04-22 will actually inflate against 2012-01-01 because we only have annual inflation data and that’s incorrect. We only get the year 2012 in the data we’re using so we have no idea if it’s January 1 or December 31 and that’s a whole year. So for now we just do the same thing as OpenSpending. When we only have year as value we default to January 1 (even though it’s probably more likely that the value applies to the end of the year).

Since data is released a long time after it has been measured we can’t even do realtime data. So you won’t be able to inflate to the value of money you understand (the current value). You’ll have to use data from last year and mentally try to remember how money was valued then, which is problematic — do you remember the price of bread a year ago?

But even if we cannot represent the value at the current price we can now compare multiple years correctly, by adjusting for inflation (unless the data is so recent we don’t have inflation data for it). The remaining problems can be fixed since they just boil down to bad data being published. We need better data and we need it now!

We need your help! We manage our CPI data, which we use to do inflation adjustment, in a special data package repository. You can help us maintain it. Can you lobby for, find, and add better and more granular data for your country or other countries? If so you would not only help users of OpenSpending, but users of CPI data all over the world (who would like to use this data package).

Rename visualisations

About a year ago, J. Félix Ontañón reported an issue where he wanted to be able to rename the visualisations on It took a while but we have now fixed this (sorry for taking so long fontanon).

We actually did more than what was asked for. You can update the name of the visualisation, the description and the visualisation itself. So if you’ve added a new year to your dataset and the visualisation is for an older year, you can update it to show the most recent year.

The only thing you have to think about is that there might be others that have embedded your visualisations in blog posts or web pages. Now you become a maintainer like us. With OpenSpending we always have to think about how changes affect users of the database and if web sites that rely on OpenSpending might stop working. You have to think about this as well: Will an update to your visualisation break pages that embed it?

Archive a dataset

Another issue reported about a year ago got fixed as well. Miro Scibrany asked for a feature to make a copy of a complete dataset. This is now possible but only if you have system administrator access to the server (this uses the ostool command that comes with OpenSpending).

You can use the same command ostool to load an archived dataset into OpenSpending so this is a really handy way to move complete datasets around. The problem is that it’s not publicly available but we don’t see this as something everyone wants to do since this mostly just helps people who have a development instance running get data from the central database without too much difficulty (and these people are probably already in touch with the core team that can get datasets for them).

If in the future we ever decide to do federation of data we at least now have a working solution to do it which is exactly what the loading API was built around (a working solution). The loading API you ask?

Loading API

Yes. The Loading API. The biggest improvement to OpenSpending this month came from CERN (it’s so awesome to say that our loading API came from the same place as the world wide web). Alberto Rodriguez Peon did a great job with help from fukami and Jiri Kuncar to add a possibility to add and update datasets via the API.

This means that you can now create a script that can scrape data from some spending sources you know and immediately upload it into OpenSpending without having to go through the OpenSpending web page (unless you desperately want to see the fancy buttons in the source controls). This is just awesome news for everyone who add data to OpenSpending. You can automate it! Just write a script, sit back, relax, and have a coffee (or something).

Interested in the loading API? You can see how simple it is in our documentation.

One thing to note is that Alberto Rodriguez Peon developed a authentication mechanism for the API to prevent others from intercepting and gaining access as someone they’re not (by getting their API key). This makes everything slightly complicated for the users (not too complicated). Currently this is the simplest way to do it while remaining secure but we’ve already decided how we’re going to make it simpler but still have it secure so you can expect a simpler authentication pretty soon (there’s only so much you can do each month) but the loading API itself won’t change so you can start using it now.

If you write loading scripts let us know! Let’s not re-invent the wheel over and over again. If you’ve created a script make it free and open source so others will benefit (and others might then improve it for you when we get the simpler authentication).

Other Changes

As always there were smaller changes made to OpenSpending in September (which was a month of huge improvements). We for example renamed to, improved our documentation on the site, and much more.

Remember that you can help develop OpenSpending. Can we top September? If you help us then we have a chance. It’s going to be a challenge keeping this pace so come and help us out. Just have a look at our OpenSpending issue tracker or our OpenSpendingJS issue tracker.


Thanks to Neil Ashton, Vitor Baptista, Michael Bauer, Mark Brough, fukami, Jiri Kuncar, J. Félix Ontañón, Anders Pedersen, Alberto Rodriguez Peon, Rufus Pollock, Miro Scibrany, Nick Stenning, Marco Voormolen, and Sander van der Waal for their contributions (there are probably a lot more who’ve contributed somehow to OpenSpending so don’t be sad if we forgot you – it’s a bit hard to manage, just let us know and we’ll add you).

Image of men loading a truck used in this blog post is by NCTRUCKINGITEMS on Flickr, released under Creative Commons Attribution, version 2.0.

Features in July and August 2013

Tryggvi Björgvinsson - September 24, 2013 in Technical, Updates

We owe you a lot of development updates. Both July and August (and it’s well past middle of September now). September is shaping up to be an awesome month, but more on that later (since there is still room for more awesomeness). In this post we’ll be sticking to the highlights of development for July and August.

Image by Alan Cleaver (cc-by 2.0)

Front Page Changes

Let’s start with one of the reasons it took so long to get write this blog post. In July and August we started the work of migrating our blog from Jekyll to WordPress. Most of you have probably noticed this but it meant that we had two blogs running at the same time. Our main blog which ran at (at the time it was and then we had another, outdated version running on our front page.

This setup was slightly embarrasing so we had to fix it and we did. We changed our front page so that it now shows calls to actions instead of showing a blog since we felt that this would better represent what people visiting would be looking for.

Dataset Page

The dual-blog confusion isn’t the only embarrasing thing about OpenSpending. The number of datasets in OpenSpending has grown spectacularly in the last few months and an irritating bug popped up. We aren’t caching the datasets page properly which means that it takes ages (more like around 15 second) to generate a list of all datasets.

This meant that when you clicked on the dataset link in the navigation bar nothing happened for about 15 seconds, and to most if not all people that looked like OpenSpending was broken. What was really happening was that in the background we were generating the list of datasets, but nothing seemed to be happening since this was all being done via AJAX (in the background with no status updates to the browser).

We got a fix contributed that bought us some time where instead of doing everything in the background via AJAX, the link in the navigation bar now takes you to a web page with all of the datasets. It still takes about 15 seconds to generate the dataset but at least the browser gives users feedback (that it’s still loading the page).

This isn’t the best solution. For example, an remaining issue is that the map on the front page which is generated with the AJAX thing doesn’t show for 15 seconds. We really should fix the dataset list generation issue. It all boils down to doing caching properly.

Would you like to help us out? All help with this issue is appreciated! We need to take a hard look at how we do caching and improve that to make OpenSpending faster and better for you, the users. You can offer your help as both a code reviewer or a coder. We can help you get started. Just let us know you’re interested on our developer mailing list!

Overwrite Drilldown Behaviour in Treemaps

July and August haven’t only revolved around embarrasing things for OpenSpending. There were a lot of awesome things that got implemented and deployed in July and August as well. One of those things was the possibility to overwrite drilldown behaviour in treemaps. Yes this is a complicated description but it’s a really important and cool feature.

OpenBudgetOakland is an awesome satellite site powered by data in OpenSpending and our visualisations (and mixes it with more interesting stuff in a cool way). The team behind the site wanted to give their users the possibility to comment on and share specific drilldowns in the treemap, and give their users some breadcrumbs so they could get back to previous levels.

For this they needed to change the treemap so they could overwrite the default drilldown behaviour. This change has now found its way back upstream and is part of OpenSpending. So all you satellite site maintainers out there! You can now do the same thing as OpenBudgetOakland!

If you want to add breadcrumbs and share locations you can do it in the same way as OpenBudgetOakland. The magic happens in lines 47 to 66 of their main javascript file where they set the drilldown context variable to a self-defined function. You will also have to look at the preceding lines which generate the breadcrumbs based on the urls (since the magic is actually just about redirecting users to another page when drilling down into the treemap).

Public Profile Page

Users of OpenSpending also now have a public profile page on On the profile page you can now add your twitter handle and choose whether or not you want your email and/or your twitter handle to be visible to the general public (not only OpenSpending administrators).

This makes it far more easier to get in touch with users who are managing interesting datasets (for example if somebody wants to help or meet up). User identity is also more visual since we now show the user’s Gravatar, based on the user’s email address.

We also did some minor changes to the navigation bar so that you can see your identity more clearly and the navigation bar isn’t as cluttered. Click on your username to access either your dashboard or your settings.

After you log in you’re taken to your new dashboard (profile page) and besides the old information which was shown in the old dashboard, and the email and/or twitter handle, we now also show a Import a dataset button so you don’t have to go through those 15 seconds of loading a dataset list just to upload a new dataset (we need your help to fix it!)

Speaking of help. There is a hidden embarrasing bug in the new navigation bar associated with the new profile page. We have since this spring been migrating from Genshi templates to Jinja2 templates. We’re not done yet and the changes to the navigation bar only affect the Jinja2 templates. So sometimes on OpenSpending you’ll see the old navigation bar. We really need to finish the migration. There’s really not much left to do.

Do you have any html skills? If so, you can help us finish the migration from Genshi to Jinja2 so that it’ll be more easier to work with OpenSpending’s templates and users won’t be presented with two versions of the navigation bar, depending on where they are on the site.

Data Range

Are you interested in a particular dataset? Do you want to know if it gets updated? Maybe you’re looking at a dataset and want to quickly see the time period for the data or when it was last updated?

OpenSpending now shows important dates for a dataset. When looking at the entries for a dataset you can see at the bottom the time span for all entries (date of the earliest entry and the date of the latest entry).

Also on the about page for the dataset you can now see the date when it was created and the date when it was last updated. Note that these are dates recorded for when things are worked on in OpenSpending, the entries time span is for the dates in the dataset itself. Two different things, but two important things when you’re interested in some spending data.

Dailybread in Satellite Templates

Keen readers might be thinking: “Wait, hasn’t dailybread been in the satellite template since the beginning”. The answer is: “Yes”. However the version which has been in the template since the beginning was kind of useless. It really only worked if you wanted to build exactly the same dailybread as was used on Where Does My Money Go so that doesn’t sound much like a template.

The big change is that the satellite template can now support a non-UK dailybread visualisation. The options of the dailybread visualisation can be overwritten and used in the template. Hopefully this will lead to many more interesting satellite sites.

Taxman goes around

The dailybread fixes to the satellite template mean little to nothing if Taxman isn’t updated. So if you want to create a dailybread visualisation for your country you still need to add the tax calculations. In July/August we saw two new countries added to Taxman. Bosnia and Herzegovina (with all three of their entities which are taxed differently) and Japan (which also introduced a better quality assurance, build process and tests, to Taxman.

Taxman is now up to 6 jurisdictions so there’s still a lot of work left to do there. Is your jurisdiction missing? You can add it to Taxman. Just follow one of the six jurisdictions to see how it’s done. It’s easy!

Other Changes

As you can see there were a lot of big changes to OpenSpending in July and August. There were many more changes, like for example the awesome OpenSpending icons page which is available at (also linked from the OpenSpendingJS README). Some deprecated functionality was replaced in OpenSpendingJS meaning that we now conform to more recent versions of libraries we use.

Remember that you can help develop OpenSpending. This is a community project and the software and all of its eco-system is only as strong as we are together.


Thanks to Neil Ashton, Vitor Baptista, Michael Bauer, Tony Hirst, Yoshihide Jimbo, Andy Lulham, Prakash Neupane, Anders Pedersen, Adam Stiles, Marco Voormolen, and Kenan Zahirovic for their contributions these two month (there are probably a lot more who’ve contributed somehow to OpenSpending so don’t be sad if we forgot you – it’s a bit hard to manage, just let us know and we’ll add you).

Image of clocks used for this blog posts is by Alan Cleaver on Flickr, released under Creative Commons Attribution, version 2.0.

Announcing the OpenSpending Steering Group

Anders Pedersen - September 18, 2013 in Updates

OpenSpending’s code base, datasets, and community have grown rapidly over the past years. In July we announced a proposal for a new community-based governance structure to support the continued growth of the project.

The new steering group and associated teams of OpenSpending will provide that structure. These groups will oversee the development of the OpenSpending project and ensure broad community influence in future plans for the project.

While OpenSpending has always been a community project, the new groups will reflect the formal recognition of a broad community of stakeholders. The legal, institutional, and infrastructural home of OpenSpending will remain with the Open Knowledge Foundation, and the Open Knowledge Foundation continues to be strongly committed to the project.

The Steering Group

The new Steering Group will have overall responsibility for the direction and management of the OpenSpending project. The steering group is to work with the community to plan the overall strategy and to implement community decisions. The responsibilities also include managing the OpenSpending brand and the use of the OpenSpending name and setting and enforcing data licensing and other policies.

Contributors from the OpenSpending community can put themselves forward to serve a two-year term on the Steering Group. Members of the existing steering group will review applications and appoint new members. To bootstrap the process, the Open Knowledge Foundation has invited members to the initial steering group from major OpenSpending stakeholders.

The steering group will include:

  • Justin Arenstein, African Media Initiate (Kenya)
  • Jay Bhalla, Open Institute (Kenya)
  • David Hall-Matthews, Publish What You Fund (United Kingdom)
  • Kaitlin Devine, Sunlight Foundation (United States)
  • Elena Mondo, International Budget Partnership (United States)
  • Oluseun Onigbinde, BudgIT (Nigeria)
  • Simon Parrish, Development Initiatives (United Kingdom)
  • Anders Pedersen, Open Knowledge Foundation (United Kingdom)
  • Federico Ramírez, Fundar (Mexico)
  • Adam Stiles, Open Budget Oakland (United States)


Our News and Website team will run our community site, including the blog and resource pages. Members will also write stories connecting spending news with the data behind them. The team already manages the blog and conducts task management using this Trello board, which includes contributors from across the world.

The data team oversees the contribution of new datasets, issues of data quality and privacy, and the management of the database. They assist community members in contributing new data and make decisions on data-related policies, standards, and legal issues.

The Technical Team comprises the official committers to the OpenSpending code repository. They oversee the technical work, including all code contributions, and are responsible for maintaining technical infrastructure.

Membership in the teams is determined by contribution. Existing team members recognise consistent good work by extending the invitation to join the team.

OpenSpending News Round-up, September 2

Teodora Beleaga - September 2, 2013 in Round-ups, Updates

Fiscal transparency never sleeps, and neither does the OpenSpending community. To keep track of all happenings across the open spending spectrum, we’re rounding up on latest blogs, stories and datasets each week. But we’re only human, so if we miss anything, give us a nudge at info [at] openspending [dot] org.

Updates from around the community

As we enter September we’re getting excited about OKCon, the annual OKFN conference taking place in Geneva on 16-18 September 2013. Highlights include a talk about the demand for open financial data (The World Bank), a panel on opening up procurement data (OKFN) and a workshop on what stories the public spending data should tell (Sunlight Foundation) – all taking place on Tuesday, 17 September 2013. Tickets information – should you wish to join – is available here.

Community member, Félix Ontañón Carmona wrote a tutorial on producing spending flowcharts, in the form of sankey diagrams,  using d3.js and the OpenSpending aggregated API. This was a cross-post with PBS Ideas Lab Blog – a group blog by innovative new media thinkers including Stanford Knight Fellows and leaders from the MIT Center for Civic Media among many others.

Elsewhere on the blog, Marc Joffe, OpenSpending community member, and principal consultant at Public Sector Credit Solutions, explained why New York is among the least likely cities to follow-up Detroit’s bankruptcy example and how the Empire State city has ensured avoidance of such crisis.

Neil Ashton, our chief technical writer and analyst, has jump-started the move of OpenSpending blog content from to, which should explain why you have been seeing seriously pixalated pictures and the like across the blog. Should you have the relevant technical skills and find the will to volunteer to help, please get in touch with Neil via twitter or by writing to our mailing list at openspending [at] lists [dot] okfn [dot] org. For spying purposes, we are tracing changes here.

Financial transparency around the world

Trading Economics published a rough visualisation of Indian Government Spending from 2004 to the first quarter of 2013 using data from the Central Statistical Organisation, India. This follows the news of the rupee’s “biggest fall in a decade” according to Quartz and the country’s slowest economic growth since 2009 according to Bloomberg.

Public Spending UK released planned spending data for 2015 also accompanied by a selection of rough charts. You can download the data using their usual download tool at

In the US, Slate followed up a NY Times article on elected officials’ (namely state comptrollers) investment dealings of taxpayers’ pension funds which they labelled “a match made in hell”.

New datasets on OpenSpending Datasets

Last week saw additional national budget data added from Japan, as well as city spending data uploaded from Lodz, Poland.

There is still much data to be claimed from last month’s mammoth uploads of spending data from Moldova’s BOOST data to Portugal’s transactional spending data. Our team of data wranglers have been busy cleaning these up for you. You can track still their progress and maybe give them a hand if you feel up to the challenge at

Did we miss anything?

While we strive to produce a comprehensive snippet of the fiscal transparency landscape across the world, this mammoth task could easily get the better of us. Should that happen we trust the wonderful community at the heart of OpenSpending to give us a nudge at info [at] openspending [dot] org.


OpenSpending News Round-up, August 26

Teodora Beleaga - August 26, 2013 in Round-ups, Updates

Fiscal transparency never sleeps, and neither does the OpenSpending community. To keep track of all happenings across the open spending spectrum, we’re rounding up on latest blogs, stories and datasets each week. But we’re only human, so if we miss anything, give us a nudge at info [at] openspending [dot] org.

Updates from around the community

First things first, today marks the start of our big move of OpenSpending web content from to and, as you may remember, you’re invited! Our chief technical writer and analyst, Neil Ashton is leading the move and has set-up this spreadsheet to track changes. Should you wish to collaborate on this project contact Neil directly so he can hook you up on the platform.

Elsewhere in the community, we held a Google Hangout last Wednesday where members had a chance to play with a prototype app created in partnership with agency Journalism++ which aims to help citizens understand spending figures. We also discussed suggestions for the IMF on its consultation over the Fiscal Transparency Code (last updated in 2007). You can review our notes here and add your own by Friday, 30 August 2013.

OpenSpending community member, and principal consultant at Public Sector Credit Solutions, Marc Joffe, received a well-deserved grant from the Sunlight Foundation for his work on opening up Californian fiscal data at a local government level. The project aims to continue to gather financial disclosures and process them into standardised data. Read more here and here.

Lastly, as you would expect, the work to open spending data and visualise government budgets very much continued here last week. From Brazil, Vitor Baptista shared how they used the OpenSpending API to visualise Brazilian government spending. Take a look at their graphics here and also check out how they went about solving key challenges, including a limit to the aggregate API which only allows users to request a measure at a time –  all in his post here.

Financial transparency around the world

In the UK, the department for Business Innovation and Skills (in short BIS) shared with the OpenSpending community a tool they put together to help visualise spending – sounds familiar? – check out the beta version at:

Elsewhere around the world, in Qatar, government spending was reported to be on the rise, up 2.2% to $48.9bn. In the US, small businesses turned out to be “poorly positioned” to acquire federal contracts, while in Tunisia, fiscal stamps fees were increased to tackle the budget deficit.

We also came across this post on potential savings big data solutions can bring to government spending. While the study referenced focuses on the US, several ideas can be applied across other countries too. Any thoughts? Please share in the comments below.

New datasets on OpenSpending Datasets

There is still much data to be claimed from last month’s mammoth uploads of spending data from Moldova’s BOOST data to Portugal’s transactional spending data. Our team of data wranglers have been busy cleaning these up for you. You can track their progress here and maybe give them a hand if you feel up to the challenge.

Did we miss anything?

While we strive to produce a comprehensive snippet of the fiscal transparency landscape across the world, this mammoth task gets the better of us every once in awhile. When that happens we trust we can rely on the wonderful community at the heart of OpenSpending to give us a nudge at info [at] openspending [dot] org.

OpenSpending site move sprint

Neil Ashton - August 20, 2013 in Updates

We’re doing a big move of OpenSpending web content! Most of is moving over to, and we need your help to get it there.

We want to make it easier for the community to create and manage OpenSpending’s web content. That’s why we’ve created a new WordPress site at We’re going to make it the new home for all community-owned content – everything currently on except for the OpenSpending system itself – and rename it The help and about pages have already been moved, with updates.

Come help out!

Give us a hand with the move! We’re organizing a site move sprint for the week of August 26 – 31. Here’s the plan and how you can get involved:

  • Check out the site content audit spreadsheet, which explains what pages exist on the old site (Title, Current URL), what we think should be done with them (Action), where they should go on the new site (Dest URL), and whether anyone has dealt with them yet (Status).
  • Please jump in on the sheet, mark some items you want to deal with (in the Owner column), and go to it.
  • Add yourself to the move sprint card on the OpenSpending Trello to let us know you’re participating.
  • If you need access to the WordPress site, please contact me and I will hook you up.