Category Archives: Code & Tech Stuff

Clever stuff we’re developing: code, prototypes, tech demos.

Using QR codes to make consultations mobile and easier to access (developer playtime)

Today I have been experimenting with adding QR Codes to online consultations that are created in our Citizen Space product.

This idea has been kicking around the back of my head for a while now, but a chance conversation earlier today reminded my of it. A new Budget Simulator client is looking to increase the number of respondents they get by putting stickers / posters up in bus stops around their town. It occurred to me that since Budget Simulator works on a mobile phone, they could include a QR code on their posters and people could respond to the consultation while they waited for the bus. I suggested it and it looks as though they are going to try it. Keep your eyes peeled for feedback from this!

Anyway, this reminded me of my little plan, so I decided to take some developer playtime and make a prototype happen. Here’s a screen shot of the result:

QR Code Screenshot
The QR Code sits in its own section of the consultation dashboard.

How did you do that?
I’m glad you asked. After a bit of research I discovered that Google provide a completely free (for all uses) service for generating QR Codes. Now obviously I didn’t want to have to rely on Google always being available, so the QR Code is generated once through Google, then stored on the consultation record. One request to Google. Saves bandwidth and time!

So what are the uses of this?
Well the idea is that when a Citizen Space administrator creates a consultation, they have the option to download the QR Code and include it on any printed information they put up around the area(s) the consultation is focused on.

Since Citizen Space is usable on a smart phone, a member of the public can scan the QR Code, visit the consultation and even fill in the quick consult survey if there is one for the consultation. All while standing in the affected area, which should encourage more considered, appropriate responses.

I believe that this would have a measurable impact on the level of participation in individual consultations.

Any drawbacks or limitations?
Yes. There are a number of things that limit the scope of this improvement, and here they are:

  1. Citizen Space works on smart phones, but is not optimised for them. This means that although the user experience is acceptable, there is room for improvement here.
  2. Many smart phones don’t come with QR Code readers as standard. Although they all have free QR Code readers available for download, this is an extra step which could reduce participation to an extent.
  3. Not everyone has a smart phone. I would recommend that the use of QR Codes does not replace including a URL on printed media.

For a more detailed look at the negative aspects of QR Codes see this excellent article by Joe Gillespie: 5 reasons you’re probably wasting time with QR codes

Conclusion (and a Disclaimer!)
I’m excited about this bit of development, and I would love to put it into a Beta version for one of our clients to test in the wild. However, this was done as a proof of concept and there are still lingering questions about the potential for QR codes to be exploited for malicious purposes. At Delib we like to experiment with potential new technologies, but we would never roll out functionality that could compromise the security of our products.

“A better sense of place” – using geo-tools in consultations for searching and sharing (developer playtime)

I’ve recently spent some time playing with the idea of associating Citizen Space consultations with a geographic location.

We already do this to some extent. Consultations can be associated with one or more local wards or areas, so that visitors to Citizen Space can enter their postcode and see a list of consultations related to the area they live in. This is great for helping people find out what’s going on near them, but I’ve been itching to take this geographic information further. In particular:

1) It would be nice to show this information visually, for example on a map. This is particularly useful if a policy relates to a specific object (eg a building, road junction or monument), or an area that doesn’t correspond to pre-defined ward boundaries (eg a bus route, catchment area or park)

2) We love Open Data. If we’re storing data about a consultation, it’s always nice to make it available in a standard format so that other websites and applications can make use of it. We already do this using RDFa for many of our consultation details (see Tom’s blog post for a good run-down of RDFa and the Semantic Web), but currently we’re not sharing any geographic information with the rest of the world.

So how could this work? A sneak peak of Citizen Space pre-release features:

I’ve added some extra fields so that you can enter longitude and latitude coordinates when setting up a consultation. Alternatively, if you want to specify a shape (such as the footprint of a building), a line (such as a bus route), or an outline (such as the boundaries of a catchment area), you can upload a KML file to your consultation. If you have a GIS team or supplier, they should be able to provide this data in the right format.

Screenshot showing fields for adding longitude, latitude and uploading a KML file

When visitors view the consultation record, they’ll see an interactive map marked with the information you specified:

Map showing a single point

Map showing a single point

Map showing an outline

Map showing the outline of an area


While it’s instructive to show a map of the consultation area to Citizen Space visitors, this location data becomes even more interesting if we let third-party users and developers get their hands on it. In my prototype code, I’ve included three ways of sharing the data:

Method 1: KML
If you look at those screenshots you’ll see that there’s a link to a KML feed underneath the map. If you uploaded your own KML file, it will link straight to that file. If you entered coordinates, it will generate a new KML file just containing the point you specified.

KML is a very simple way to share mapping data with other online applications. It can be done using sites such Google Maps and Microsoft Virtual Earth without any programming knowledge. Lets say you’re consulting about a proposed cycle path, and have uploaded a KML file plotting the complete route of the path. A local parents’ group might use the KML data to overlay your route over their existing map of schools, parks and youth centres, to show how child safety could be improved by the construction of the path.

Method 2: GeoRSS
Citizen Space currently provides RSS feeds that let users subscribe to all the latest consultations, or consultations that meet certain search criteria. These feeds are also used by third-party sites to embed up-to-date consultation information, or to aggregate consultations from multiple sources into a single list.

If we have geographic coordinates associated with a consultation, it’s very easy to publish this information as part of the RSS feed, using the emerging GeoRSS standard. Apps that understand and are interested in the location data can use it in much the same way as the KML data above. Apps and users who are not interested in location data won’t see any difference to their feeds.

Method 3: RDFa
We’ve already mentioned how useful RDFa is for sharing consultation information between different websites and applications. Well, it turns out the RDFa specification includes the ability to link your document to a place, using the “based_near” tag. If you’ve entered latitude and longitude information when setting up your consultation, this extra bit of RDFa will be published along with the rest of the consultation record. Sadly I haven’t found many examples of applications that currently use the based_near feature of RDFa, but here are a couple of ideas I’ve been thinking about:

  • A visual version of the Citizen Space aggregator, that can display consultations from many different sources on the same map.
  • A mobile app that alerts you when you’re near an object or place that’s being consulted on.

This new code isn’t in Citizen Space at the time of publishing this post, but will likely be included in a future release.

If anyone else has ideas for making use of location-based consultation data, please drop me a line. The more good ideas we get, the more likely it is that this feature will make it into a future Citizen Space release.

I’d also be keen to hear of formats we could use to share the data other than KML, GeoRSS or RDFa. Has anyone used GeoJSON for example?

Part 3 of “An open source business model for government software; how we’re making it work, in 3 easy parts”

In part 1 of this series I looked at the basics of open source for government, identifying some challenges in making it work. In part 2 I looked more at open source works, and how we met the challenges for Citizen Space (our open source consultation system for government and public sector).

In this post I explore why we chose an open source approach for Citizen Space, ask ‘does it work?’, and make a few recommendations that might help others.

A detour into licensing: Citizen Space is licensed under the GNU General Public License (v2), hereafter referred to as GPL. The GPL is a very elegant piece of law which uses existing copyright law to ensure that users of software have the rights to modify and distribute that software, whilst also protecting contributors from unfair exploitation.

“‘Free software'” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.” – GPL ethos

(Disclaimer: I Am Not A Lawyer, nothing written here constitutes legal advice).

Why did we choose open source for Citizen Space?
Citizen Space is built on a software framework that is licensed under the GPL (v2).
Simply if we wish to distribute Citizen Space to our clients, we are required to use the GPL (v2).

‘Distribute’ is interpreted here as either actually providing a copy of the software (by electronic transfer or removable media), or as an agreement that gives the customer ownership rights in a copy of the software

Did we have any alternative to using the GPL?
No and yes. We have to use the GPL, but we could operate without distributing the software.

I’ll go quickly here, the detailed legal picture isn’t essential. We could have defined that the customer was paying only for the output of the software and not the software itself. The output would be delivered as a service, over the web. In that model, the customer doesn’t own the software, and it’s never distributed to them. Because there’s no distribution, the GPL isn’t invoked.

(N.B this is specific to the GPL v2, which is what we must comply with. Newer versions of the GPL have quite different provisions for services provided over the web).

A service-only model might be a viable way to operate. We chose not to do this. Why?
We wanted to open source.

  • We think providing open source software gives us something distinctive from closed source competitors. It’s reassuring to our clients that they won’t be tied into a costly licensing regime, and that they can switch supplier if necessary.
  • It forces us to be innovative with our business model. This model emphasises creating sustainable recurring revenues by providing support services customers will value (and can also scale up or down according to their needs).
  • Using an open source license simplifies procurement. As we have no option but to use the unmodified GPL, we don’t have to negotiate with legal departments about clauses, or employ lawyers to do so (so avoiding pointless cost on both sides).
  • Open source opens the way for easier collaboration.

Moreover, for this kind of software I simply think that open source is the right way to go: Citizen Space is niche, highly specific to a relatively small market (hundreds or thousands of customers rather than millions), and it’s purchased and operated as a capital asset. Open source isn’t necessary for every system or app, but it’s good for this case.

Cartoon: 'I'd like to query clauses 7, 9, 13, 21, 23 and 49b.' 'Sorry it's just the GPL.  No changes.'

But…why isn’t it just a web app?
The simplicity of a pure web app (things like Basecamp) is appealing: choose a monthly billing plan, pay on a credit card, easy-in-easy-out; customers can export all their data any time, but can’t take the software with them if they leave.

I do see subscription web apps gaining adoption in public sector where they solve generic problems – for example Huddle or Basecamp for collaboration. I watch this with interest. It’s appealing, and operating that model would in some ways be simpler. But there are several factors that make me think the model we have is the right one for now:

  • When we talk to customers, they want to own their consultation software. For them it’s like commissioning a website. The procurement environment for this is typically weighted towards capital purchase. With Citizen Space, they get rights to the software as well as their data.
  • The ongoing service aspect of Citizen Space is comparable to a web app anyway, except we bill on invoice not credit card, which suits government better. We also operate flexible monthly, quarterly or annual billing, with no punitive contract terms. Simply our goal is to make it easy.
  • Compared to a collaboration tool (with millions of potential business users), Citizen Space is niche and sophisticated, with a relatively small customer base. If we tried to operate it from the ongoing service fees alone, there would be insufficient revenue to develop the product further, which wouldn’t be sustainable.

Is it working?
So far, yes. We’ve been operating this way since 2007.

Customers like the open source aspect, and the product continues to find new customers and be developed further. So I’m extremely positive about the open source aspects. Because I’m so positive I’m going to explore three problems with it 🙂

Three problems considered

  • “Is it free?”
  • Could we survive on this alone?
  • Procurement…

1. Is it free?
We frequently talk to potential customers who have an expectation that open source means free (as in zero-cost). This is understandable, but it’s also resolvable quite quickly.

When we explain how it works, people get it. They see pretty quickly that there’s no business model in ‘totally free’, and that for the product to be supported and developed there has to be a source of revenue. They also have no problem with the idea that if it’s valuable to their work, there will be costs.

So ‘is it free?’ is an issue we have to overcome, but it’s just an occasional bit of grit in the wheels, and doesn’t kill the model.

2. Could we survive on Citizen Space alone?
No. We’re a small, efficient team, but the income from Citizen Space alone is not enough to support an entire business. We have to reliably cover a range of roles, and be able to respond quickly to customer needs. This means a certain minimum number of people are needed.

The rate at which people are adopting Citizen Space increases, and this provides income which directly supports more of the roles we need. In that respect Citizen Space is on track to a point where it could be self-sufficient (it would need something between 80 and 120 customers, which we think is very achievable).

But as a business we wouldn’t want to be 100% dependent on one product. It’s not smart. We offer multiple products as well as custom projects because:

  • Not every problem is the right shape for Citizen Space. Not all clients need a system to manage all of their consultation and engagement. For example, for one-off projects, our apps like Dialogue App and Budget Simulator are better suited.
  • Some of our customers need customised or bespoke tools developed which we like to do (and in all cases we offer technical support and consultancy on how to get the best results).

3. Procurement
I won’t talk here about costs imposed directly by procurement processes; it’s an issue, but too big in scope for this post. The short version is that we’ve stopped responding to some opportunities – especially where they involve onerous tender documents. We can’t do business sustainably if we spend too much time responding to onerous (and often self-contradictory) tenders.

This is a problem for the model. It’s not a problem arising from the open source aspect of the model. It’s just a problem with supplying to public sector, and it probably increases total costs for customers (by increasing operating costs of suppliers, especially on small contracts).

There seems to be an awareness of this as an issue in government, and that simply saying ‘you need to be a bigger supplier’ is unacceptable. Maybe it will get better.

Will we open source everything?
No. It’s not necessary or helpful to do that.

Some of the apps we sell are used on a per-project basis, and/or delivered purely as a service. It’s not only unnecessary to open source them, it’s also possibly unhelpful. They’re used by non-technical clients who want a simple solution to their problem. Discussing open source with this group is a distraction they would neither want nor welcome.

But it’s likely that over time we’ll open source more – because in many cases it’s a great route.

In summary then, I’m positive about open source as a model for government software
This series of three posts was in-depth – because I wanted to explore the issues carefully and give a clear indication of what can work well.

As a reminder the model we’re operating for Citizen Space is:

  • We built it with revenue from sales and our own investment.
  • After we’d proved it thoroughly, UK government saw value in funding extra development.
  • Ongoing support and maintenance are provided 100% commercially.
  • Some product development is provided for with a levy. But to reach our vision for the app, we’ll continue to invest and find customers who are prepared to fund or co-fund specific functionality.

Any final recommendations?
Yes.

What we’re doing with open source for government is reproducible.
There’s no magic, and we’ve had no special favours nor been especially lucky. Hard work and a bit of bravery carries us forward. Others can do this (and we owe a debt directly to other open source people who’ve inspired us).

Open source as a policy position for Government when purchasing or investing.
This has multiple dimensions. The case for open source has been made often; a couple of details of how to operate it are of more interest here.

1. When looking for off-the-shelf software, open source and closed source should have a level playing field. There’s no need to favour one or the other. However if open source is chosen, government purchasers might also want to look at how government purchasing adds value back to the ecosystem, especially where open source has a much lower cost than the closed source equivalent.

2. When commissioning bespoke or custom software, government should open source it (unless genuine security reasons preclude that). Traditionally custom software for government has been locked up behind default Crown Copyright. However Crown Copyright is entirely compatible with licenses such as the GPL.

The results of investment by government should be made available for reuse, providing benefits to public sector, to charity, or to businesses. Not all of these will see re-use, because as I’ve shown building a support and development ecosystem around a piece of software takes effort, but a relatively low frequency of reuse is fine, because open sourcing software is a low-cost and low-risk strategy, and there are good benefits to be had when reuse does happen.

Government doesn’t need to commit resources to building support and development ecosystems directly, but rather by measures like procurement rules, and easing the path for SMEs or social enterprises who can build these ecosystems. However government as a major customer (or in-house developer) should accept that it can play a vital role in these wider ecosystems and deliver back (to gain net benefits).

I hope this has been useful and interesting. I’d like to distill these posts down to a slide format that could be shared more widely. In the meantime, if you have questions or thoughts, leave a blog comment, email me (andy@delib.co.uk) or get me on Twitter @delibthinks

cheers,

Andy

Cartoon: 'What are you doing?' 'Planting a thousand flowers' 'They didn't all bloom!' 'That's ok.  It was cheap, and the ones that came up are lovely'

Part 2 of “An open source business model for government software; how we’re making it work, in 3 easy parts”

In part 1 of this series I looked at the basics of open source for government, and identified that there are challenges in making it work, specifically:

  • Development
  • Evangelism and raising awareness
  • Ensuring sustainability, responsive support, and further development

In this post I look a little bit further into ways that open source works, and explore in more detail how we met the challenges above for Citizen Space (our open source consultation system for government and public sector).

“Scratching an itch”
When drafting this post, I wrote a lot of stuff about how open source works. Then I deleted most of it. This is a blog post, not a book. 🙂

A lot of open source development happens because people are ‘scratching their own itch’. The reasons vary: but they’re mostly related to “it’s fun”. At this point, no-one’s employed. No money changes hands. Sometimes a project will snowball and a community will form around it. This is great. Being social is even more fun.

Projects like this live as long as people find them fun. When they stop having fun, they’ll continue to support the project for as long as they feel socially obliged to, then they’ll stop. And they’ll do something more fun instead.

This gets a lot of software written, and a lot of people have fun. But it isn’t how all open source development happens.

Commercial open source
A lot of open source software development is paid for or supported by companies. These range from IT giants like IBM and Oracle to small software houses and web businesses.

How do they contribute to open source?

  • Development: employing developers and other staff to work directly on open source projects.
  • Ecosystem: supporting the community around a project through events, donations, improving things like documentation, marketing the project, helping with legal and governance issues.

Why do they contribute to open source?

  • Revenue: the business develops revenue streams based around using open source software on behalf of paying clients. This can include bespoke development, maintenance, support, training, hosting, and selling hardware that runs open source software.
  • Competition: an open source product is used to challenge a closed-source competitor.
  • Research & development: the business uses open source collaboration to improve products and do pure research.

Companies choose to work in an open source way because they can find both direct revenue streams and other benefits. What about government?

Cartoon: 'Good morning.  I'm from the government and I'm here to help'

Government and open source
I’m going to be prescriptive: government should get more involved in open source software. There are multiple benefits to this, and to an increasing extent, it’s happening. But as these posts explore, there are also multiple challenges for open source government software. Examples of sustainable operating models are needed.

We’ve had to meet these challenges with Citizen Space. How did we do it?

Development – how did we get Citizen Space from an idea to working code
Two simple things funded the majority of Citizen Space development; a third source of funding helped raise the game significantly.

1. Sales
Initial Citizen Space sales were effectively custom builds for specific clients. This is pretty common for software intended for a very specific group of customers (as opposed to mass-market consumer or general business software).

When we started selling Citizen Space in 2004, it cost much more than it does now, and it was less capable and less polished. It was used by early adopters who found it useful and could justify this spend. This provided income which directly supported building the product. Early adopters (‘customer of first resort’?) can be absolutely vital in getting a tech innovation off the ground.

2. We invested
Some of the early custom builds ran at a loss. We took profit generated elsewhere in the business and used it to fund this development. We also used debt-funding (bank loans) to ensure Delib had sufficient working capital to be around for the long term. This required us to build and run a successful consulting and custom development business whilst also developing our apps.

We could have taken the profit out of the business, but our belief is in building a product that can be used by every public sector organisation in the world. That doesn’t happen if we lift out the profits and buy a Porsche each.

Later we invested more to properly productise Citizen Space (because doing a custom build every time is unsustainable in the long run – it costs too much and is a nightmare to maintain). We continue to add custom features when a client needs them and can fund them, but they’re usually rolled back into the product to reduce long-term support costs.

3. Government invested
In 2010 UK government funded further development of the product to improve its suitability for central government. By this point Citizen Space was well established, with 6 years of experience building and operating the system for multiple public sector clients.

This wasn’t a no-strings grant for a nice-but-unproven idea by nice-and-plausible people.
We weren’t given a cheque, crayons and a stack of blank paper 🙂

Instead the project was an intensively managed software development process, consulting with multiple potential users in government, and rounds of testing and acceptance. This upped the overall game, and we were able to justify further significant investment of our own in Citizen Space.

The rationale for government was that by centrally investing, the cost of deployment to each individual department was then significantly lowered compared to typical pricing for a system of this type (from us or competitors). By going for an open source system, there was also the reassurance that departments could switch supplier if necessary, and that the system could be developed further in future.

Cartoon: 'Has my Porsche arrived yet?' 'No Porsche.  Software.'

Evangelism and raising awareness (“Hello, I’m from Delib and I’m here to help”)
In a nutshell, we do sales and marketing. In some ways, it’s that simple. I was going to cut this section out, except that it’s important.

The software won’t get used unless we tell people about it. Some software does go ‘viral’ – spreading by word of mouth – but I’ll just point towards the other two companies in our group; we know when viral does and doesn’t work 🙂

Our approach is pretty straightforward, and involves a lot of time on the phone talking to potential customers. The interesting thing is that it’s a significant proportion of our operating cost. It’s also time that (obviously) can’t be billed directly to clients. So it has to be covered from other revenue, which drives our day rates up. They could be lower if our spend on sales could be lower, but selling to government is expensive.

Charging for support – no bones about it, it’s a win-win for suppliers + customers
Complex software that is used to get jobs done to deadlines often needs support. Software often needs maintenance and upgrading, especially web software that needs to be secure and highly available to multiple users.

Businesses can live or die by their reputation for customer support. Charging for support contracts means an open source supplier can ensure that staff are available to respond to customers, and customers can have a clear expectation of great support.

There are businesses that manage to provide great support for free, but they’ll always have another source of revenue, such as license fees, or some other thing they’re selling (and how good is your broadband provider at support?).

How we’re operating support for Citizen Space
Our customers are broadly non-technical. Most are working in comms, public engagement and policy consultation. They need the reassurance that they will be able to get help when it’s needed.

So to be able to respond quickly to support issues, we have to have a certain level of staffing. Trying to do customer support for free won’t work and we stopped doing this years ago.

It’s good sense then that we operate support and maintenance contracts. We don’t charge excessively, and we’ve found a couple of smart ways to operate this.

1. We work flexibly.
Our developers are the key to looking after the software and our clients; they’re brilliantly flexible, and work 13 days per month out of around 21 possible days. This gives us three advantages:

  • We can scale up when needed.
  • We spread the knowledge across more people, so we’re more resilient and can cover holidays and sickness (and if someone leaves, although we hope they don’t).
  • Our developers like it – they have more autonomy over when they work, they have time for other things, and they don’t get jaded. This isn’t specific to an open source model, it’s just a smart thing to do.

2. We allocate time to support.
Support time is built right into our business model. And if that time isn’t used reactively for a specific client, then we use it proactively, in a variety of ways (which aren’t charged back to any client), including:

  • Improving documentation to help reduce support issues.
  • Improving our systems to streamline maintenance.
  • Developing the product further also to reduce support issues.

This is a result of thinking about what we’re doing in a lean way – identifying that support is a value-adding activity, not a waste, but being clear that reducing the cost of providing support is also good. It’s the attitude of stop cleaning, eliminate the sources of dirt.

Developing Citizen Space further
Citizen Space is good. But we know it could do a lot more. There are features that would be useful to clients, and there will be advances in technology to keep up with. In part 1 I described how we’ll continue to invest, but also how we tackle sustainability head on with a one-off product development levy which each new client contributes to.

A product development levy guarantees continued improvement of the product. By pooling it and ring-fencing it, we can fund feature development and enhancements. It also has an element of positive-feedback: improvements in the product make it attractive to more new customers, which brings in more funding for further product development.

BUT (and there is a but) – the levy has two further interesting aspects, which I’ll discuss in brief.

1. We vary the levy by country. Via central government, UK taxpayer has invested in Citizen Space (which is recouped by providing the system to UK public sector for much less than it used to cost). So quite simply the product development levy is lower for UK public sector customers than it is for other countries (or for any private sector organisation that wanted to use Citizen Space). It’s a fair and sustainable way to ensure development of the product.

2. The levy is not excessive. It’s a relatively small sum and the total raised this way will be useful, but not enormous. So to get more development done, we continue to re-invest profit. Some features will also still need to be funded directly by the clients who require them. This is fine. We’re also exploring how co-funding will work to the same end.

Cartoon: 'I'd like a new feature please'.  'Sounds great! Let's see what we can do.  Do you have any budget?'  'Maybe'

And now a summary…
Open source for government poses challenges. Here’s how we met these for Citizen Space:

  • We built it with revenue from sales and our own investment.
  • After we’d proved it thoroughly, UK government saw value in funding extra development.
  • Ongoing support and maintenance are provided 100% commercially.
  • Some product development is provided for with a levy. But to reach our vision for the app, we’ll continue to invest and find customers who are prepared to fund or co-fund specific functionality.

In the final post in this series I explore why we adoted an open source model for Citizen Space, and ask “does it actually work?”

Part 1 of “An open source business model for government software; how we’re making it work, in 3 easy parts”

The use of open source software by government continues to attract a lot of interest and discussion, ranging across issues such as:

  • How can central government manage tech procurement better and reduce costs?
  • How should government and the wider public sector (local gov, NHS etc) collaborate sustainably with grass-roots innovators?
  • How might a vibrant tech and creative economy be supported, with a particular emphasis on smaller suppliers?

We operate an open source business model for Citizen Space, (which is consultation software designed for government and public sector).

This is the first of three posts examining how we’re making that business model work, how we’ve arrived at it, and some of the pitfalls and benefits. I hope it’s of interest to:

  • people looking at shaping policy around government and public sector IT procurement
  • people who wanting to support innovation and grass-roots projects sustainably
  • suppliers (especially smaller businesses) who are taking on similar challenges

This first post covers some basic aspects of using open source for government, and gives an outline of the business model we’re using.

The second post covers the business model in much more detail, and the third post asks ‘so, how well does it work?’ (spoiler alert: the answer is ‘pretty well’, with extra notes for the keen).

As a service to your eyes, I’ve tried to keep this free of acronyms and buzzwords.

Open source basics (skip this if you’re already familiar with open source)
I’m going to assume readers are familiar with what open source software is, and the basics of how it works. Explaining it in depth is beyond the scope of this post 🙂

If you need a primer or refresher on open source, wikipedia is a useful starting point, as is this definition from the Open Source Initiative.

Some key aspects of open source

  • ‘Free’ does not mean ‘Free’. Open source defines how the software is licensed and ensures the user has certain rights to operate, modify, and distribute the software. It does not mean that working software is provided and supported for no charge.
  • Advantages of open source for end users typically include reduced hassle with licensing, lower costs, and no vendor lock in.
  • Open source software is developed by anyone from single individuals through to large groups, including commercial software companies.

So what do I know about open source?
I’ve been using both open source and proprietary software commercially for ten years, in a variety of digital media businesses, including Delib. We’re involved in open source communities, funding our developers to attend community events and conferences, and contributing where we can, through things like hosting coding sprints.

I also work on open source projects in my spare time. I create add-ons for a successful open source game (which shall be un-named – on the internet no-one knows you’re a dog). My stuff now has more than 500,000 downloads, and an estimated 20,000 active users. There’s no money involved, and I do it for fun. This baffles my wife, but she’s pleased we’ve stopped arguing about what to watch on telly.

In short, I’m an advocate of open source. It’s not the only way to provide software, but it’s a very good way to do so in many cases, and it’s very good for government applications.

Open source for government?
There’s no one true way to ‘do’ open source. What works for a single developer coding for fun will be different to what works for a business providing open source software to thousands of customers, and likely different again to open source for government.

My focus here is on software used by government and public sector to deliver services to the public. This has characteristics including some or all of:

  • Public servants use it as a tool to manage information or processes
  • The public use it to access information, or participate in processes
  • There are typically multiple users of the software within an organisation
  • There are multiple organisations using the software
  • The public servants using the software are non-technical, and need an effective, well-supported tool that gets the job done on time
  • The public expect the system to be reliable, usable, and to take care of concerns like information security

Examples would include content management systems, systems for handling transactions (anything from paying taxes to ordering a new bin), tools for participation and engagement (such as Citizen Space), and things like apps and services to support health and well-being.

There are numerous examples of such tools, in the UK and overseas. Many are prototypes or tech demonstrations, a smaller number are much more established; a few are becoming ‘default’.

Prototypes are relatively easy to generate: sprinkle a little innovation funding and/or rely on the good will of individual developers, and interesting tech demos will get produced.

Scaling up prototypes to sustainably meet the needs of government is a harder problem.

I think it’s a solvable problem, and I think it deserves more attention (and my inner optimist thinks the climate is right to solve it).

Cartoon: 'Sounds tricky.'  'It's not that tricky.  We can fix it.'

What’s hard about scaling an open source project to be sustainable for government?
1. Development. Building sophisticated software takes time + money. It needs to be usable, maintainable, secure, standards compliant, accessible, and low on bugs.

It’s also essential to spend time on understanding the needs of users.
If the software doesn’t do the job, it’s pointless.

2. Evangelism and raising awareness. Users can’t use software they don’t know about.
Awareness of some software spreads virally by word of mouth. Most doesn’t.

Many good software projects (both open & closed source) fail because they’re poorly marketed.
Letting potential users know about a piece of software takes time and effort.

3. Ensuring sustainability, responsive support, and further development. Government and public sector organisations that adopt a piece of software need to know it works today and will still work tomorrow.

Public servants work in a culture that is intolerant of risk (often for the good reason that sensitive public data is being handled); open source software for government needs to accommodate that.

Projects that rely on good will, or some initial funding may die because they aren’t maintained or further developed, or because they lack basic support such as training or documentation.

Sometimes the developers of an open-source project simply move on to work on other interesting problems. Many developers like new problems. Doing support and fixing bugs is less stimulating. When funding has been used up, or they’re giving up their own time, this is perfectly fair. 🙂

Sometimes developers have to stop working on and supporting an open source project because they need to take paid employment elsewhere and can’t commit enough time and energy (in my experience this is a relatively common reason for open source projects to die). 🙁

Cartoon: 'I made a nice thing' 'It's nice. Please send me the manual, information security policy, support terms, and a list of 5 other clients using it.'  '!?'

Solving the challenges
These challenges aren’t unique to open source. A ‘traditional’ license-based software business faces similar challenges, but has a clear source of revenue from sales of licenses.

Nor are the challenges insurmountable; far from it: open source software businesses around the world are being built around solving them.

One way to scale a project sustainably is to start a business and employ people to work on it.

  • Development is handled by employing developers
  • Evangelism and raising awareness is solved by employing people to market the software
  • Support and responsiveness is handled by hiring people to look after users and the project

This isn’t the only way; building a community who will do it for free is one alternative. For government, taking software in-house is another (although that’s employment by other means). Many viable routes exist, but the one we’ve chosen is to build a business and employ people.

So where does the money come from?
Key question then: in the absence of license fees, how do we get the money to make payroll?

  • We charge day-rates for the work we do to deploy Citizen Space for a client. That includes consultancy, project management, and technical tasks. We don’t charge for the software.
  • We offer additional services like training and further consultancy on a day rate basis.
  • We tackle sustainability head on: there’s a one-off levy which goes towards future product development. All new clients are asked to contribute this; it’s pooled and ring-fenced for development of new features. Some clients also directly fund new features they need. Meanwhile we continue investing our profit in the product. Citizen Space is good, but it’s nowhere as good as the vision we have for it, and we continue developing it.
  • We charge for hosting, application maintenance and support, on a quarterly or annual basis. It is possible for clients to host and maintain Citizen Space themselves, but we’re dead certain we’ll be faster and cheaper. This puts recurring revenues into our business and means we can maintain the support infrastructure our clients need without needing to cross-subsidise it purely from the revenue on new sales.

Most of that is pretty standard practice for an open source business model. The product development levy is a little more interesting, and I discuss that in the next post, along with more details about how Citizen Space was developed and is operated, The final post will look at the pitfalls and benefits of this as a business model for open source government software.

Meanwhile, before the second part, here’s a link to an interesting story:
“if you’re not investing in the open source software upon which your business depends, your strategy is probably flawed” » Follow the Brazilian Government’s lead?

» Continue to part 2

In-house project to develop a consultation system? Could that be bad maths? (And sorry if I’m ranting).

Apologies: this is a rant. Ranting is rarely useful or interesting, and we mostly avoid it on this blog. But this one seemed justified. I wrote it in 2010, but didn’t publish it. I’ve spent some time cutting out a lot of stuff, but I hope what’s left is still interesting. So if you’re with me, here we go….

Summary
– Blind insistence on building all ‘IT stuff’ in-house is a shocking waste of money.
– I’m not just a supplier moaning about unfairness. This is significant waste that should stop.

Backstory
Late 2010, discussions with multiple organisations about how our Citizen Space consultation system could integrate with their other web assets (corporate sites, other consultation and engagement tools, Twitter feeds etc). Result: “yes there are multiple standards-based ways to play nicely with others“. Length of conversation, usually about 5 mins.

Meanwhile, back at the ranch…
Also in 2010, we lost a run of Citizen Space tenders for public sector organisations who ‘chose to go with an in-house solution’. So we win some, we lose some. But this was losing for the wrong reasons. Hence: rant. So to business…

The protoganists
On the one hand, we have Citizen Space, or – to avoid the impression I’m just pushing Delib software here – similar productised systems for consultation and engagement, from other suppliers, large and small.
On the other hand we have in-house solutions for consultation and engagement, usually a custom extension of the existing website system.

Can we do some maths?
Citizen Space has had over 1,200 days of design, development and testing.

It has has been co-designed over three years with people from multiple local authorities, government departments and public bodies. We built it using knowledge gained from our previous consultation system which was created in 2003 and developed for around five years.

Citizen Space is productised, tested, and widely used. It’s built using proven open-source software, with no vendor-lockin. It has been audited for accessibility by the Shaw Trust and security tested by Surecloud. We usually host it and there’s no hassle deploying it. There’s a client feedback process and a commitment to ongoing development and upgrades. Citizen Space even comes with a comprehensive user manual.

And we’re not the only ones; there are at least five competing systems for consultation and engagement. We aim to be the best, but we’re certainly not the only ones who’ve got years of experience developing these systems.

But enough about suppliers. What about the in-house project?
Staff time isn’t free. A 30k salary seems a reasonable benchmark for public sector IT and comms staffers. Some will be more, some will be less. But it seems fair. Employing that person should cost about £200 per day in real money (including tax, office costs, training, pension etc).

So for the typical price of a ready-to-go, fully-project-managed deployment of Citizen Space, an organisation could invest perhaps 40 days of staff time in creating their own solution. Which initially seems quite a lot. That’s 40 days to create the entire system. Luxury. It’ll be done by Friday.

That’s 40 days to schedule, project manage, develop, and deploy the system into successful use. Should be fine.

That’s 40 days to allocate staff, organise meetings, capture requirements, get requirements signed off, do initial design documents, get design documents reviewed and signed off, create a technical spec, review the technical spec, develop the database schema and backend code, prototype the GUI, test the GUI, refine the GUI, create cross-browser standards-compliant CSS, review and implement accessibility, implement multi-user and multi-role permissions and security, overcome technical issues and items in the design that were missed, changed or failed test, load-test and performance-test the system, penetration test the software and the development environment, deploy the software for real users, provide instructions and support in using it, deal with teething troubles, and workflow or usability problems that only arise from the system being actively used, and meanwhile maintain the project in a risk managed environment with a clear audit trail on spending and costs, whilst also fully complying with information security and data protection issues. And it will be done by Friday, right?

Do I protest too much?
Perhaps. It’s quite possible that an organisation simply can’t find the budget for Citizen Space – or for any of our competitors, including those who will offer a far-less-complete, but cheaper, (and possibly sufficient) systems for consultation and engagement. In which case, with less budget, it might be fair to spend, say 20 days of internal time developing an in-house solution.

But with 20 days, an in-house project will achieve 1/60th of the features, quality, security and reliability of Citizen Space, or a similar system. And 20 days probably isn’t enough.

And this assumes that cost is the main-driving factor in these decisions. But often it’s not. The outcome often seems to be driven by the not-invented-here fallacy, where organisations spend more to achieve less value because of an unwillingness to accept cheaper, better value external solutions (reasons might be internal politics, wooly thinking, or simply lack of knowledge).

But you’re a supplier Andy. You protest too much.
Well maybe, but I’m passionate about value for money for our clients, and for taxpayers. I’m an engineer at heart, and it makes me sad when I see the wheel being pointlessly reinvented; it’s a waste, and the results are bad. It’s junk engineering, and junk procurement. It often happens for indefensible reasons. And when it happens, taxes are being wasted. Can’t we stop it?

—-

Caveats + ‘for the avoidance of doubt’
1. I’m not blindly against developing in-house projects. Where no standard apps or software exists for a problem, in-house development makes sense.

2. The most common justification for in-house projects is “corporate policy is to use [insert name of CMS vendor or platform here], so we have to use that”. If that’s policy, it would be handy to avoid issuing tenders and RFPs for things that the organisation is not allowed to procure. It’s kind of a waste of resources for UK SMEs. I know sometimes it’s an internal battle, and tenders are part of that battle. But it’s not really cricket; a tender can cost hundreds of pounds in real money to complete (some of the more stupid, lengthier tenders cost thousands). Where multiple suppliers are asked to tender, it’s a fair amount of waste. I’m not sure that private sector businesses should be bearing the cost of politics inside a public organisation so directly. We would like to help though – by sharing better ways to do things – and helping support business cases for using more efficient, proven, off-the-shelf tools from us and other people.

3. I’ve instigated plenty of in-house software builds. Some I was right about, others I was quite wrong. As web software has matured, we’ve switched to off-the-shelf systems. We binned our mass-mailer and use Campaign Monitor. We binned our in-house CRM system and use Zoho. We binned our ticketing system and use Trac. Sometimes we saved money by doing this, and sometimes we spent a little more, but got a much better system, so we could get on with our jobs and stop wasting time trying to invent and fix our own systems.

4. I’ve assumed that organisations measure the cost of internal time and use that in business cases. Am I being really quite naive about that?

5. I tried to cut out most of the really the ranty bits. How did I do?

Using RDFa to create a Google Calendar

Part of what we like to do in Delib is demonstrate how easy it can be explore to Linked Data and get more engagement from a public consultation process.

I’ve just spent an hour or so playing around with the idea of using RDFa and the Citizen Space Aggregator demo to create calendars of consultations:


This calendar is embedded, not a screenshot – feel free to click around!

The calendar above is a Beta version of a feature that I would hope to one day add into core Citizen Space. What I’ve done is take the RDFa information that is stored by the Aggregator from Bristol’s Consultation Finder, and provide a URL that outputs an iCal formatted version of the consultations that are being run.

You can then use this URL to create calendars either in Google, as I have, or subscribe to it using any piece of software that understands the iCal format, for example Apple’s iCal, or even your iPhone!

For anyone interested in doing this, here is the URL: http://www.citizenspace.com/aggregator/calendar_beta?search_source=Bristol+City+Council&search_keywords=

As the astute reader may notice, this takes a search string. Any search that you can make on the Aggregator home page can be turned into an RSS Feed. The calendar works the same way… just swap ‘/rss’ for ‘/calendar_beta’ and you will get your iCal formatted URL containing ONLY the consultations you have searched for.

This is just the beginning… we’ll be making lots of use of Linked Data and RDF… soon!

Opening up the Citizen Space consultation Aggregator

Earlier this year we launched our consultation Aggregator, and put a demonstration site online. This combines all our clients’ consultations running on Delib’s Citizen Space software into a single, searchable hub. We were very pleased with this demo, and its purpose was twofold:

  1. To showcase the capabilities of the Aggregator.
  2. To display a complete list of our Citizen Space clients in one place.

The astute reader will probably notice that our Aggregator demo, as currently deployed, is of much more benefit to Delib than it is to the wider community! As one of the developers behind the Aggregator, this makes me a bit sad, as I know that it can do a lot more than this, both technically and socially.

Technically…
The Aggregator is not limited to aggregating Citizen Space consultations. It will just as happily include consultations published by third-party consultation systems. The only requirement is that they publish their list of consultations as an RSS feed, and that each consultation uses RDFa to specify its start and end dates. Since RDFa markup (including start and end dates) has been a requirement of UK central government consultations since January 2010, there is no reason why any consultations should be published without it these days.

Socially…
A list of consultations that all happen to run on Citizen Space is, in the grand scheme of things, rather an arbitrary division! Helpful for Delib sales maybe, but I’m not a sales person and I’d like to do something bigger!

As far as the public is concerned, it would make a lot more sense to have a searchable database of ALL consultation activity in their country or local area, regardless of the software used to publish the consultations.

How can we fix it?
We would like to start building an aggregated database of all UK public consultations that support the RSS and RDFa web standards. In theory, this should be ALL consultations, but in practice we know that not all software supports these standards yet.

Its purpose would be threefold:

  1. To showcase the capabilities of the Aggregator (sorry but we’re quite proud of it!)
  2. To showcase the awesome power of web standards and linked data in helping different (even competing!) software systems talk to each other.
  3. To provide a useful, up-to date listing of public consultation activity in the UK.

If you would like to nominate a council or public sector organisation to join our gang, please get in touch and send us a link to the consultation RSS feed (this is the feed linking to the actual consultation records, not a news feed, blog feed or anything else), and we’ll start building our fledgling consultation cooperative!

Why Do We Call Our Apps ‘Apps?’

We were asked on our post about the use of IE6 why we choose to call our products (specifically Citizen Space) ‘apps.’ It’s a fair point, as iOS and Android applications seem to have a monopoly on the term ‘app,’ so why are we using it?

But apps aren’t just for mobile phones. It’s short for “application software” which simply describes a program that helps users perform tasks. Our products, like Citizen Space and Budget Simulator for example, do this, but just so happen to be hosted online. So instead of making apps designed to run on a mobile device (such as an iOS or Android application), we make apps which run in an internet browser. The concept of “web application” isn’t new either, it’s been around for over a decade and includes Webmail clients and Wikipedia.

So in summary, we make web applications. And it’s trendy that web, mobile and operating system applications (think Mac App Store) get shortened to “apps.” It also lets us increase productivity and reduce repetitive strain injury risk by typing seven fewer letters 😀

5 Ways We Ensure Quality

Software testing or quality assurance is an area of our work which is often completely invisible to our clients. It is however a vital part of our production process, essential in giving us the confidence we need when we make a new release of one of our apps. I’m going to try and give you an overview of how we do this without going too deeply into the technical detail.

Test early and often
Delib have a strong belief that where possible quality should be built in throughout the development life cycle rather than tested in at the end of a project. This is an important part of the agile development process which we use when making our apps. We test what we do, whether it’s design, code, or documentation, early and often so that defects are found while the work is still fresh in people’s minds and before the defects can become too deeply embedded in the software.

Minimise variation
Any customisation of the software introduces variation which needs to be tested and maintained for every version of the app. Lean manufacturing has taught us that by minimising variation and developing apps which work for people out of the box we can reduce costs and more thoroughly test what we make, increasing the value of what we do for our clients. We recommend to our clients that they avoid paying us to customise our apps when possible so that we can provide them with the most cost efficient solution.

Build in flexibility
Where there is a common need for the same customisation from lots of clients we try to allow for this by building flexibility into the system. This limited and known variation can be accounted for when testing and does not add a huge cost overhead to our development process, while at the same time allowing our clients to change the things they need to.

Use great tools
Tools like Selenium and Jenkins enable us to run automated tests on our apps to ensure that any changes we make don’t break the existing features which our clients rely on. We continually make use of these tools throughout our development cycle.

Try out new ideas
We are always eager to learn about anything which might help us increase the quality and value of what we produce. Moving from the specification driven waterfall development model to the more flexible agile methodology was a big change for us, but adopting lean production methods is the thing that has given us the largest benefits.

What techniques do you use to improve quality? We would love to hear your tips and suggestions.