Photo: The Akvo software development team discuss system architecture at the 2009 Akvo RSR sprint, near Stockholm, Sweden.
At Akvo we create and share internet tools which make it easier for people to implement water and sanitation development aid projects in an effective and transparent way. Akvo.org runs open source software that we call the Akvo Platform. The Akvo Platform consists mostly of components that we have not built, such as WordPress for the blog or MediaWiki for the Akvopedia. But what people really seem to get excited about are our contributions, which consist of the Akvo Marketplace, Akvo Really Simple Reporting and Akvo Widgets – together we often (lazily) refer to these as just Akvo RSR.
The Akvo Platform and its components
The Akvo Platform includes components which can be thought of in general terms as a:
- knowledge base – in this case Mediawiki
- news/featured article system – provided by the blogging system WordPress
- content management system for other pages – using Drupal
- tightly integrated project marketplace;
- reporting system; and
- distributed project progress visualisation system – in the shape of Akvo RSR
Akvo RSR is meant to make it easy to showcase projects, report on progress of the projects and publish information about these projects widely, without having to enter the information many times, even if you are publishing the information in many different places. In that, it seems we have identified something people would like to use in a much wider environment both in development aid and further afield.
For example, we are working closely with a consortium called Connect For Change, in the Netherlands, which consist of ICCO, IICD, Akvo, TextToChange, Cordaid, Edukans. This group is looking to use the Akvo Platform across different development aid sectors, such as healthcare, ICT, as well as water and sanitation. Akvo is also doing consulting work to implement the Akvo Platform as a marketing and communication tool for a private-public partnership organisation in the Netherlands. Another example is a U.S. organisation investigating using the Akvo Platform for participatory projects in the energy sector, and a European outfit looking to improve government and public collaboration around community projects on a national scale.
With all this interest we thought it would be a good idea to explain in more detail some thoughts behind the selection of the components for the Akvo Platform (this blog post), where the Akvo Platform is going (the next blog post) and what we think is currently missing (the final post).
Akvo platform overview
The first thing which is important to realise is that we think that each component that makes up the platform should be relatively easy to replace with another component. For example if you do not want WordPress as your blog you should be able to insert Blogger, TypePad or any other blog tool out there relatively easily.
The second thing is that we are primarily building the Akvo Platform for a purpose: to help make development aid more efficient. This means that we are taking some shortcuts, like we are not splitting our primary contribution – the Akvo RSR components – into standalone pieces, which you could swap out with other pieces easily, as this would be too much work and not give us any significant advantages.
Akvo RSR – Project marketplace, Project reporting and Distributed publishing
At the core of the Akvo Platform you can find three tightly integrated components: a project marketplace, a project reporting system and a distributed publishing system.
The project marketplace, Akvo Marketplace, allows projects which need funding to be posted on the web site in a standardised fashion. Funders that are looking for projects to fund have one easy system to search for projects in. The Akvo Marketplace also contains integrations with systems to perform online donations. These are currently PayPal and the PayPal credit card services, but we will soon be ready with the Dutch IDEAL payment system, too.
Once a project is funded then the system allows for easy project reporting facilities through the Akvo Really Simple Reporting system, much like a blog attached to the pages describing the project. The reporting tools will soon include mobile phone tools, allowing reports to be filed from the field without internet access, all via SMS messages.
Finally, the distributed publishing tools, which we call Akvo Widgets, can present any of the projects in the Akvo system or a group of projects on any other web site. The widget system allows a webmaster to easily place a widget for a project on their web site, and this widget will ensure that the project information presented on the web site is always up to date. If an SMS update with a project status report has arrived in the Akvo system in the last minute, the widgets make sure that the web page they are placed on shows this latest information too, without the webmaster having to do anything.
The Akvo RSR system can be considered a knowledge-base for projects. Projects which have been entered into Akvo RSR will not be removed, so that system can be used as a reference source for project information. What works? What doesn’t work? Who does what? Who uses what technology and where? As we get more projects into the Akvo RSR system on Akvo.org we plan to refine the search systems such that is possible to find answers to these questions easily.
The Akvo Platform also contains a more general knowledge base, the Akvopedia. This knowledge base runs on the MediaWiki system, which is the engine that powers Wikipedia. A key reason we chose MediaWiki for the knowledge base was that we wanted a familiar concept for the users – “everyone” knows Wikipedia, and is familiar with the principles of open knowledge sharing. We haven’t changed the user interface on the MediaWiki, to ensure everyone recognises it as a wiki. A vertical application such as the Akvopedia will of course never have such a large community collaborating on the content as Wikipedia, but we don’t think that should stop us publishing this information openly.
Content management tools
For more general content management in the platform we have chosen Drupal. With general content management we are talking about pages which do not strictly need to follow a specific format, such as the project pages, but are also not publicly editable, like in the wiki. Examples on the Akvo web site are the so called About pages, which describe the team and our effort.
The reason we choose Drupal is that it is the content management system (CMS) with the largest developer community, a large set of extensions and a very flexible and extensible architecture. It has a fairly steep learning curve when you want to extend it yourself, but with the amount of tools available, this isn’t often needed.
A blog – a specialised type of content management
The platform also contains a special type of content management system for featured articles, normally called blogs, in the shape of WordPress. WordPress, like Drupal, has a large developer community and an abundance of extensions.
Why so many components?
Some people have asked us why we have chosen so many components, rather than use Drupal, for example, and a number of Drupal extensions? There are Drupal plugins for blogs and wikis. We could also have built Akvo RSR in the Drupal framework. Why didn’t we do this?
First you may have noticed that Drupal, MediaWiki and WordPress are built using the programming language PHP. And these are great web applications, but we’d prefer not to build things ourselves in PHP. We’d rather build web applications in a more modern environment with better tools and “cleaner” code. We have chosen Python and the web framework Django.
Second, if we had chosen to build it all on Drupal (or WordPress) and you have an aversion against Drupal, for some reason, then you couldn’t use the Akvo Platform. Now you can replace Drupal in the Akvo Platform with Joomla, or just use the generic content management features of WordPress if you like. Of course, you could argue that you have an aversion against maintaining a large number of tools and keeping them up to date, i.e. installing and updating bug fixes and the latest version for all the different Akvo Platform components. This is a valid argument, but we are of the opinion that this is the lesser evil. We’d rather have the flexibility that the multiple-component approach gives us than the convenience fewer tools would give us. But then there is no system as extensive as Drupal built in Django and Python anyway.
So essentially, this way we can select best of breed products and we get to build the components that do not exist yet in a programming language and environment which we prefer.
In the next article I will talk about where we are going with the Akvo Platform in general and about Akvo RSR specifically.
The whole article series about the Akvo Platform: