Tag Archives: developing software

We’re hiring! Developer role in Bristol, UK

Hello, we’re looking for a Developer to join Delib HQ in Bristol.  We think we have a pretty good environment in which to write software. We have a big airy studio in a listed building in the city centre, and we’re a small enough company that everyone knows everyone else. It’s not perfect; there are never enough hours in the day, but we care, we say thanks, and we go out for lunches and drink together after work and I reckon that counts for a lot.

Typically we work well with people who’ve got a Computer Science degree and have been coding since at least their early teens. YMMV. We prefer people who can communicate with humans as well as computers.

We need to get some web app, support and operations stuff done. All developers do a bit of everything:

  • For frontend development we generally use XHTML, Less/CSS and JQuery/Javascript. We have to support a wide range of browsers including mobiles and tablets.
  • We generally use Python for backend development. Generally Python doesn’t suck. We work with python frameworks including Pyramid, Zope and Plone. You don’t need to have used these – or even have used Python – but experience with a web framework would be good.
  • Most of our app data is stored in object databases (ZODB) but from time to time we also use various flavours of SQL.
  • We have lots of devops things to do, including deployment automation for servers around the world. We use Ansible for this, along with a bunch of our own scripts. Again, you don’t need to have used Ansible, but it would be best if you’re not (too) scared of SSHing into linux servers, grepping logs and tweaking apache configs.
  • All our application code, automation scripts and configuration are version controlled using git, as is most of our test data. We all need to be able to modify, build and run each other’s code, so these days we’re pretty hot on documenting things too.
  • All developers take rotating fortnightly shifts as Developer on Support, which means we help our customers and account managers with technical issues via our online ticketing system, help sales people with quoting and tendering, and are generally available to answer questions without being excessively grumpy. This is actually really important – it means that developers get to see how the stuff we’ve built really affects our customers’ lives, and customers love getting a reply directly from the person who can fix their problem.
  • Unfortunately being on Support does also mean being on call. But calls/texts outside office hours are infrequent and if you do get called you get paid for it. Oh and don’t panic – you don’t get calls directly from customers.

These days we’re pretty good at using agile development processes like Scrum and Kanban. We also have grown-up things like continuous integration and Aeron chairs (or sofas to work on if that’s more your style). Bring your own laptop or we can supply one – you’ll get a decent quality Macbook Pro.

Hours and Salary

Could be a full-time, part-time or freelance scenario (but we’re not up for paying extortionate day rates to freelancers I’m afraid). Currently all Delib’s developers are part-time, with the option for scale-up days each month. We find that this arrangement suits our work/life/childcare/hangover requirements perfectly.

We’re offering £30-40k pro-rata depending on experience.

Contact details

Sound interesting? Send a cover letter and your CV to Jayne@delib.net. We don’t place too much faith in CVs, the covering letter is really what we look at. If we like the look of yours we’ll get you in for a standard hiring interview.

We follow the HMG Baseline Personnel Security Standard and you will therefore need to satisfy basic eligibility criteria/certain conditions of employment (e.g. nationality rules/right to work); and provide appropriate documentation to verify ID, nationality, employment and/or academic history, criminal record (unspent convictions only).

No applications will be accepted via recruitment companies.

Cheers,

Andy (Director) and Jess (Developer)

Delib goes agile(r)

Back in May Rowena posted about her experiences at Blue Light Camp and noted that she is a qualified Scrum Master. In fact, we have three Scrum Masters in our team, but how do new Delibbers (like me) fit in to a lean, agile structure?

Simple, we get trained. Recently, a few Delib employees were trained by agile guru Paul Goddard of Agilify, along with some of our friends from Aardman and Mobile Pie, as well as some Team Rubber colleagues.

Agile is a set of practices which aim to make teams deliver better work, faster, and in doing so make our clients happier. In the past year, Delib has grown rapidly, and has incorporated people with no prior agile experience. Many businesses use older, more established methodologies, because this is what they are used to. But are industrial revolution era practices really applicable to small, nimble digital media companies?

One of the core agile principles is continuous delivery of valuable software. This means that we don’t work for a year and then give our customers a large number of new features while crossing our fingers that they like them. Instead, we deliver “pioneer” features to some customers, and get feedback regularly before releasing them to our whole user base.

Paul illustrated the benefits of this with a seemingly simple exercise – taking a bunch of spaghetti, some rope and some sellotape, who can build the highest structure which can hold a marshmallow on top? The winning team was the one which tested whether their tower could hold the marshmallow after every change, and the losers built a huge tower which promptly fell down right at the end when the marshmallow was placed on top.

Adam with his spaghetti tower with a marshmallow on top
I tried not to look too smug after a comprehensive victory

We’ve returned roaring with enthusiasm, and ready to deliver our clients even more top-notch software and services. Our customers’ satisfaction will continue to be our highest priority day in, day out, and not the marshmallow under which our towers collapse at a crucial moment.

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.

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