Category Archives: How Delib gets stuff done

A bit of ‘behind the scenes’ at Delib – how we get stuff done: our tactics, our thinking about how to work, and the tools we use.

How We Keep Warm: Information Radiation

It may be sunny in our Bristol office but like those at Government Digital Service (GDS), we’ve been radiating information on TVs around the office. Ambient information in the workplace helps keep everybody up to speed on what’s going on and what issues there are (if any).

Daily, weekly and yearly stats for the consultations we’re running (updated in real time)

Status of the tests of our applications that are currently in development (green = everything is working; red = something is broken)

Financial stuff that we cannot share on the blog πŸ˜‰

We’ve already talked about how we visualise the workflow using post-its on a Kanban board but since Delib now has a new Australian office it make sense for some things to be shown digitally. We’re planning to make it possible for these screens to be available to those in Australia and those that work remotely, so watch this space…

An interview with Delib’s new Australian consultant: Verne

It’s always nice to welcome new people into the Delib family. The most recent addition to our Australian team is Verne Krastins – an extremely experienced engagement consultant based in Victoria, and a keen guitarist (which is obviously of equal importance!).

As a quick introduction to Verne, we thought it would be a good idea to do a quick interview with him – so here you go:

Delib: When did you first use the internet, and what did you use it for?

VK: My first job in local government communications coincided with me and the internet. Councils in Victoria were amalgamated in 1994, bringing about major investment in communications infrastructure in the new bigger organisations. Then there was the Cluetrain Manifesto a few years later.

Delib: What’s the most awesome difference you’ve made to the community through your engagement work?

VK: I can’t imagine one person can make a lasting difference without others taking over the reigns at some stage. Unfortunately, sustainable engagement is not well done by governments. I’m proud of my part in the 2006 Melbourne Commonwealth Games – I directed a many layered year long community engagement campaign to connect the sectors, and broker them doing things together.

Delib: What’s your top community engagement tip?

VK: Be clear what the engagement is for, and what you’re going to do afterwards with (1) the information, and (2) the relationships, connections and databases created along the way. I’d also add that community engagement is marketing in disguise.

Delib: Who’s your hero [and why]?

VK: I have many. Frank Zappa (musical genius and satarist), Erwin SchrΓΆdinger (he described my favourite concepts, and a fellow theoretical biologist), Salvador Dali (turned me into a part time artist), and of course Jules Verne (who gave me SciFi, and my name).

Delib: What’s your favourite internet meme / phenomenon?

VK: Convergence. The day is coming when we’ll have a device in our pocket that does everything, foldable, expandable to whatever screen size you want, phone/computer. Social networks will have effectively collapsed into me-at-centre.


We’re in the process of fully setting Verne up on our various systems, so once he’s fully up and running we’ll share details more widely. Exciting times πŸ˜‰

Crowdsourcing ideas with Dialogue App: 5 levels of user engagement

The basic principle of Dialogue App is very straightforward: users can submit ideas and tag, rate and comment on other people’s ideas. But from these simple interactions can emerge complex discussion, lively debate, and innovative thinking.

The key to the process is a low barrier to entry. People can approach the discussion with a low level of commitment and, as they become more engaged in the discussion, they can increase the time and effort they put into contributing.

Level 1. “Just browsing, thanks”
Any visitor to the Dialogue can read all user-submitted content (except content which has been removed by moderators). They can browse the ideas, sorting them by date added (most recent first) by popularity (highest rated first) or by level of engagement (ideas with most comments first). Visitors can also search for ideas by keyword or tag.

screenshot of sorting tabs
Tabs let users sort by most recent, highest rated, and ideas with most comments

Even at this stage, before they’ve submitted anything at all to the Dialogue, visitors can make an important contribution to the discussion. Each idea has Twitter and Facebook buttons, so they can share the idea with their social network contacts, extending the reach of the discussion and inviting even more participation.

Tweet and Facebook buttons let users share ideas with their friends

Level 2. “Couldn’t agree more”
After browsing the ideas for a while, it’s likely that the visitor will have opinions, positive or negative, about some of the ideas. Dialogue App lets users anonymously rate other people’s ideas with a number of stars between 1 and 5.

Visitors like this level of interaction because it’s perceived as low risk. Their name is not associated with the rating, and they can change or retract their rating at any time, but they are still having a measurable impact on the discussion.

Users can view the current rating of an idea, and add or change their own rating.

Another way of participating anonymously in the discussion is by tagging ideas. A ‘tag’ is a one- or two-word description of the idea, which other visitors can use to browse similar ideas.

A ‘tag cloud’ in the sidebar of the site shows the most commonly-used tags. The more often a tag has been used, the larger it’s displayed, which gives a really clear overview of the key topics being discussed and their relative importance.

screenshot of tag cloud
The tag cloud shows commonly discussed topics

In order to participate actively in the discussion (adding ideas, comments, ratings or tags) the visitor must register on the site.

It’s vital that the signup form does not put people off, so the Dialogue App just collects the bare minimum of information: a username, email address and password. It takes seconds to fill in.

There is the option for clients to add extra fields to this form, but we generally recommend against it, as a long signup form is one of the easiest ways to lose people’s interest.

screenshot of Dialogue App signup form
The signup form asks for the bare minimum information.

Level 3. “Yes, but…”
Once a user has registered and expressed their opinion anonymously about ideas, they will often want to provide more detail, argue a specific point, or justify their postive or negative rating.

Registered users can add their own comments to all ideas, except those that have been closed to further discussion by a moderator.

Comments are quick to submit: the form is designed to encourage users to keep their comments quite short, although in practice a comment can vary from a couple of words to several paragraphs.

Users can post a comment to the end of the discussion thread

All comments include the username of the person who posted it (the user’s real name and email address are never made public). Seeing their name associated with their comments naturally increases the user’s sense of participation in the community, and so we see this as the next step in their commitment to the discussion.

Level 4. “And now for something completely different”
Of course, new ideas are the core of the Dialogue, and a really engaged user will want to put their own ideas up for debate, as well as commenting on other people’s ideas.

Submitting an idea requires a little more effort than submitting a comment: users need to give their idea a title, then describe the idea, and they are also asked ‘why is your idea important?’ This encourages users to think more carefully about their idea before they submit it and helps maintain the quality of the discussion.

Users are asked for a title, description, and explanation of why their idea is important.

Ideas can contain basic formatting such as bold text, and users can embed images and links to other websites.

Users who have submitted ideas are very likely to return to the Dialogue time and again to read the comments and further engage in the debate.

Level 5. “A bit about me”
Once a user has posted ideas or comments to the discussion, and seen their username published alongside their submission, they are likely to notice that their username is also a link to their personal profile.

A user’s profile shows a list of all the ideas and comments they have submitted, and can also include selected pieces of information that the user chooses to publish about themselves, if the Dialogue is configured to ask for it. While we discourage asking huge numbers of questions in the signup form, the personal profile is the place to collect information about more engaged users, who will often provide it voluntarily.

Dialogue App can be customised to ask users for demographic information

Users with large numbers of ideas, or highly rated or discussed ideas, can become minor celebrities in the context of the discussion, and often like to give more information about themselves than just a nickname.

Profile information can be public (eg occupation, city/county of residence, areas of interest) or private (eg ethnicity, postcode, email address etc). When setting up a new Dialogue App we can advise on commonly collected demographic information, and how best to ask for it.

Dialogue App is proven to be an effective tool for policy crowdsourcing and budget consultation. The numbers show just how easy it is for the public to get involved: we’ve run Dialogues such as HM Treasury’s Spending Challenge where 36,000 registered users submitted 45,000 ideas, and over a quarter of a million ratings. HM Government’s Your Freedom dialogue attracted similar levels of participation. If you’re interested in finding out more about Dialogue App, contact | 0845 638 1848.

3 ways Dialogue App makes it easy to export data, analyse and report on a dialogue process

A dialogue process is a great way to do things like policy crowdsourcing, ideas generation, and participatory budgeting. One of the great things about a dialogue process is that it combines the free flow of debate and ideas with a structure that enables outcomes to be reached. To get to concrete outcomes, it’s often essential to be able to use data to summarise the discussion.

Dialogue App makes it easy to get hold of your data at any time during the discussion or after it has closed. Here’s a quick overview of the information that Dialogue App provides.

1. Top-line stats
When running a Dialogue, you often need to get hold of quick, up-to-date statistics about the discussion. This may be for a status report, press release, or just for your own curiosity. The Results and Reporting control panel is accessible at any time, and provides the following top-line statistics:

  • Number of registered users
  • Number of users who have submitted ideas
  • Number of ideas
  • Number of comments
  • Average number of comments per idea
  • Number of ratings
  • Average number of ratings per idea
  • Number of tags
  • Average number of tags per idea

2. Complete data exports
All the information collected by the Dialogue is available for download at any time. You’re most likely to need this information after the dialogue closes, for creating a final report, but it’s also useful for putting together an interim report, a mailing list, or for performing more complex analysis than the top-line stats provide.

The following data sets are available for download in CSV format:

  • Full user profiles (username, email address, mailing list opt-in status, custom demographic information)
  • All ideas (title, description, username of submitter, date, average rating, number of ratings, number of comments, list of tags, moderation state) sorted by creation date
  • All ideas (as above, sorted by average rating)
  • All ideas (as above sorted by number of comments)
  • All comments (idea that comment is associated with, username of submitter, date, comment)
  • All tags (tag name, number of uses)

CSV files can be opened in spreadsheet packages such as Microsoft® Excel®, or databases such as Access®. Delib can also create custom downloadable reports on request.

3. Web Analytics
Dialogue App is compatible with Google Analytics (and other online web stats if required). This provides invaluable information about your site’s visitors, including:

  • Number of visitors to the homepage and to individual ideas
  • Breakdown of visitors by geographic territory
  • Breakdown of visitors by operating system, web browser and capabilities
  • How visitors arrived at your site (search engine, link from another site etc)

We can help you with setting up Google Analytics if you don’t already have an account.

It doesn’t matter whether you’re running a hyper-local discussion that attracts tens of users and results in a dozen great ideas, or a highly-publicised national debate that gives you 50,000 ideas and a quarter of a million ratings to analyse. We’ve helped clients with both of these, and a great many in between.

Does your organisation need dialogue? We’ll talk you through how it works and how to succeed: Gillian Crea or Ben Fowkes | 0845 638 1848 (UK) +44 1173 812 989 (anywhere else)

Designing for successful crowdsourcing and dialogue: users and roles in Dialogue App

Dialogue App is designed to make it easy to run a successful dialogue process, to achieve outcomes like policy crowdsourcing, ideas generation, and participatory budgeting.

A key aspect of designing for success is the approach to user roles in the app. Dialogue App provides for:

  • Unregisted users
  • Registered users
  • Moderators
  • Site admins

Here’s a quick guide to each of the different types of user in Dialogue App, their responsibilities, and how they interact with the system.

Unregistered users
It’s important that visitors become quickly engaged with the Dialogue, without having to register or log in. Unregistered visitors to the site can:

  • Browse all the user-submitted content on the site, including ideas, comments, ratings and tags
  • Search the ideas using keywords or tags
  • Read the background information about the topic under discussion
  • Share ideas with their contacts on Facebook and Twitter

Registered users
Anyone can register for an account on a Dialogue App site. By registering, a user is able browse the site in the same way as an unregistered user, but they can also contribute their own content. Registered users can:

  • Submit ideas
  • Comment on other people’s ideas
  • Rate and tag ideas
  • Edit their own user profile
  • View the profiles of other registered users.
  • Receive opt-in email updates from the dialogue organisers

We’re very aware that the registration process on many websites can be off-putting, so we’ve ensured that the registration form asks for the absolute minimal information: a username, a password and an email address (although this is configurable at the request of the client).

It’s important for somebody to be in charge of moderating any public dialogue. Moderators can interact with the dialogue in the same way as standard registered users, but they can also:

  • Reject inappropriate or offensive ideas and comments. Rejected content is hidden from public view, but can be reinstated if required.
  • Remove inappropriate, duplicate or irrelevant tags (either from single ideas or sitewide)
  • Lock ideas to prevent further discussion. The idea and its comments will remain visible to the public, but no further comments, ratings or tags can be added.
  • Upload a photo or badge to their personal profile. This will appear next to any ideas or comments the post, to indicate their official status.

Dialogue App can send an email to moderators if an idea or comment has been reported by a member of the public, making it easier to find and remove inappropriate content.

Site admins
Site admins have the ability to set up the Dialogue App, manage its users, customise its appearance and view or download reports and statistics. Site admins can:

  • Perform all moderation actions as above
  • Create, publish and close discussions on the site
  • View top-line statistics about the dialogue (number of users, ideas, comments etc)
  • Download all ideas, comments, user details and tags in CSV (spreadsheet) format
  • Manage the demographic information that is collected from users upon registration, and when editing their personal profiles.
  • Customise the appearance of their Dialogue by uploading a logo (if Delib has not provided a custom theme)
  • Promote and demote other users between different roles, and delete users
  • Edit the background information about the dialogue, the privacy policy, and other text on the site

If you have any questions about how to run an online discussion using Dialogue App, contact Gillian Crea or Ben Fowkes | 0845 638 1848 (UK) +44 1173 812 989 (anywhere else).

5 ways to do better software demos

Software demos are often too long and they shouldn’t be. This great post from We Love Local Government hit a nerve. The post inspired us to set out some principles for how we demo.

Our goal is simply to make it easy for organisations to use the internet to connect people with decision making. We do this by providing awesome cost effective and easy to use apps.

When we demo our apps we want to reflect our principles: humanise stuff, be straightforward and make things easier to understand, be lean and efficient; always be helpful.

Our 5 point demo charter

  1. We establish what people need first. Sounds basic but this is easy to forget when we have a suite of shiny apps and we want to show off all of the features.
  2. Keep to an appropriate time. Our experience shows that an hour is right for most demos. Less than half an hour is not worthwhile and ‘too long’ is too long. However, if the client needs more then we are happy to give it.
  3. We want people to be able to summarize our apps to others. Those involved in the demo need to leave feeling confident in the product and have a clear idea of how it will work for them, not just for our current clients.
  4. We don’t want to show off all of the features at once. Although it may be interesting for the GIS expert in your team to learn that you can embed street view into a consultation record, if you’re talking solely to a procurement specialist this may not be so relevant. It’s another feature to use at a later date but not during the demo.
  5. Listen actively. A demo is a conversation, and a way of helping clients shape their requirements. Would an alternative app or bespoke project meet their needs more effectively?

“Just because we could, doesn’t mean we should”. We want to be the antidote to complicated ICT procurement and software demos are a big part of that.

For more info on our apps or to book a demo get in touch with Ben or Rowena on 0845 680 0575.

“Welcome to our demo”
Our demo team

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?

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 ( or get me on Twitter @delibthinks



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