Paths to sustainability

Last month I attended Sustain Summit 2018: an inspiring 'one-day event for open source sustainers' organised by Open Collective. It was great to spend a day with people who are working hard to tackle the sustainability problem. Some focused on their own projects, others looking more broadly across the open source ecosystem. The sustainability conversation has moved on significantly since the last time I looked, in about 2013, and there are lots of new ideas and projects with the potential to impact how we work.

In this post, I want to try and do two things: give a comprehensive account of CiviCRM's sustainability story; and share some ideas that I think could be useful for the road ahead.

Our sustainability story

A couple of times during the conference, I found myself telling our sustainability story (my version of it at least) and it struck me that although we often share parts of it at events and in blog posts, we have never written the whole thing down for public consumption. With the result that this knowledge is distributed very unevenly around our community, and especially lightly amongst those that have joined us more recently. This isn't good: if we want people to be involved in sustaining CiviCRM, we need to tell them how we got here. Plus I think that this story is of interest to the open source sustainability nerds out there. So here - with a large dose of 20/20 hindsight - is an opinionated history of CiviCRM sustainability.

I discovered CiviCRM in 2008 while searching for an open source non profit bandwagon to jump onto. I had been helping non profits with CRM for a few years and wanted to find a community of practice I could become a part of. CiviCRM ticked all the boxes: version 2.0 had a decent set of components that worked well for my clients; there were thousands of people online in the forums, discussing new features and helping each other out; bugs were being squashed as soon as they were found, and new releases were coming out at a steady pace. A diverse global community coordinated by a small core team at the centre - the promise of open source - I was impressed and hooked.

Sorry, did anyone happen to see where I put my Kool-Aid?

There is an important piece missing from the account above: who was writing the code? My assumption was that the vast majority of it was coming from the community, with the core team focused on leadership, code review, and the infrastructure necessary to keep things running smoothly. That was how all open source projects ran, I thought. But in CiviCRM's case, the majority of the code was written by the core team. CiviCRM's founders had been lucky enough to secure a significant amount of seed funding at the start of the project, and were using this to pay the core team to get CiviCRM off the ground. Of course, this isn't a particularly unusual method of development - there are many open source projects where the code is written more or less by a core team - and it was working nicely for CiviCRM. They were responsive to user feedback, put a tonne of effort into growing the community, and were improving the product with each release. So why mention it here?

The core team were not massively up front about this funding, and that was probably a mistake. I think the motivation was to promote the long term vision of a project sustained within the community, and that keeping quite about the seed funding was a way to manifest the vision. In fact, it had the opposite effect, letting the community off the hook to a large extent.

When great new features are coming down the pipe with each release, it is easy to forget to ask where they are coming from. Those that were contributing back could relax, assuming that their contributions, when combined with everyone else's, were enough to propel the project forward. Those that weren't contributing were at least thankful that enough others were doing so that they didn't need to.

To be fair, external funding was not the only source of income in the early years. The core team did take significant steps toward self sustainability, carrying out a number of consulting contracts with organisations that were able to fund the improvements that they wanted to see in CiviCRM, and reaching out to encourage others to do the same.

But the majority of users did not take them up on the offer. 'We'll think about it', and 'We'd love to, but we're a cash strapped non profit' were common answers. Plus, CiviCRM was doing OK without them, right? Admittedly, this was a fairly big and unusual ask to make of organisations in a sector that tends to be conservative in their technology choices. Bottom line: most people assumed the project was already financially sustainable through contributions from the community.

The end of seed funding

Over the next few years I became more involved with CiviCRM and ended up joining the core team as community manager in 2013. This coincided with the end of seed funding. It was time for CiviCRM to stand on its own two feet and we started a concerted effort to get sustainable.

We invested in our home grown crowd funding platform: Make it Happen; started the Paid Issue Queue letting people with the money jump the queue and get the fixes they needed into CiviCRM; created a Partner Programme for service providers that wanted to financially support the project, and a Member Programme for end users that wanted to do the same. We told anyone that would listen that you could Hire the Core Team to develop the features for your next project (providing that it was inline with our wider objectives). And we took some baby steps towards financial transparency, sharing our financial situation with an inner circle. Going completely open on day one, we agreed, would risk scaring people off - we would get there eventually but one step at a time.

Our founders also took a step back from the project around this time. They said we could call in an emergency - thankfully, we have never needed to. In 2016, I jumped back over to the other side of the fence and started consulting again. Cat herding had been lots of fun, but it was time to become a cat again.

CiviCRM today

Fast forwarding a couple more years, today we are a long way past seed funding, and the core team is still here - something I am grateful for every day - and certainly not something that was guaranteed back in 2013. The core team has changed significantly: it is smaller these days, more focused on leadership, code review, and infrastructure (the things I had presumed it was doing when I first joined). Our community has stepped up in lots of ways, playing crucial roles in areas that were previously the core team's domain: security and governance spring to mind. The core team continues to innovate: Spark is a new hosted CiviCRM solution launched by the core team to help onboard new users. Out of all of the sustainability initiatives we have tried, Hiring the Core Team, the Partner Programme and Make it happen have probably made the biggest contribution to sustainability.

We've proved that we can survive post-founders and post-seed-funding, but all is not perfect in CiviCRM land. The million dollar question is are we sustainable? Yes we have a solid user base at the moment, but do we have the resources to stay relevant to these users in the years ahead? Right now, I don't think we do. I think we need to pick up the pace, and the rest of this post is an attempt to speed us along this path.

Foundations and corporates

One criticism you often hear levelled against CiviCRM (admittedly by software traditionalists) is that by choosing to be open source and aiming ourselves at non-profits, we have made things doubly hard for ourselves. Not only have we eliminated our ability to generate revenue through license fees, but we've chosen a market that is not exactly rolling in money.

The obvious come back to this is 'foundation funding'. Surely there are many organisations out there who would fall over backwards to support a project that is delivering a public good specifically aimed at the non profits they serve? Our experience has been that these kind of funders are hard to come by. It may well get easier over time, as open source seeps into the conciousness of the funding public, but for now it is still a challenge. Why might this be?

A lot of foundations are averse to funding back end infrastructure like CiviCRM, preferring front-line projects with easy to measure outcomes. One way around is to submit joint end user and core team funding bids that focus on the front-line project (and if you are a non profit fundraiser with an idea along these lines, I encourage you to explore how you might make that happen).

An alternative approach is to seek out funders that are familiar with open source. Where might we find these? It turns out many large tech corporations have programs to give back to open source, and a number of these were present at Sustain. These programs exist because corporations recognise the key role open source technology has played in their success. They would miss it if it were gone and they want to ensure it survives. The catch, most of the time, is that these programs focus on giving back to the specific projects that the corporations rely on - a kind of strategic altruism. That said, many corporations also have philanthropic side projects. Twilio, for example, runs twilio.org. With a bit of imagination and some relationship building, it shouldn't be impossible to find a corporate or two happy to sponsor us in this way.

But if our aim is to be self sufficient - sustained from within our community - then aren't we kind of admitting defeat by asking for help from outside? Why would a foundation agree to fund a project that has ambitions to be self sufficient. Wouldn't they be bailing them out? Letting the consultants off the hook? To answer that question, it helps to define what exactly we mean by self sustaining.

What does self sustaining mean anyway?

One simple definition is that in a self sustaining open source project, all work is resourced from within the community - from the non profits and software developers that use it in their day to day work. That seems about right at first glance, but it breaks down when you look a bit closer. Here are a couple of examples of self sustaining funding in CiviCRM.

1. A consultancy with multiple clients using CiviCRM realises that many of them would benefit from a new feature, and they get their internal development team to write a new extension providing the feature. Maybe they fund the development from their surpluses, or maybe they pitch the idea to their clients who collectively fund it.
2. A non profit realises they need a new feature for their day to day work, and that others would also benefit from the feature, so they decide to release it as an open source extension. With a bit of luck, they think, others will also join in and contribute improvements. They might fund it from their reserves or from a specific budget. Or they might pitch an external foundation to fund it. Maybe they develop it internally, or maybe they contract a developer to do the work.

In each of the above examples, the money ultimatley originates outside the ecosystem, makes one or two stops in a non profit, or consultancy, and ends up in the bank account of the people that did the actual work. I think a better definition of a self sustaining ecosystem is one where the funding comes from people with a stake in the project. In many cases, the stake is indirect, for example in the case of a foundation supporting a non profit that relies on CiviCRM, but it exists. Funding CiviCRM is the mechanism the foundation uses to effect the change they want to see.

With this definition of sustainability, asking for help from outside funders is legitimate, and somewhere that we should focus our efforts. We need to spend time helping external funders understand their stake in CiviCRM, and why it is in their interest to support the project.

Before moving on, I want to quickly mention another aspect of sustainability that I think is key to self sustainability: diversity. As all non profits know, relying on a single source of income is not a good idea. The more diverse your income streams, the less vulnerable you are to the whims of any single funder. In an open source project, as well as diversity of income, we can also consider diversity of contributions. The more people that contribute and review, and the more perspectives we are exposed to, the better our product and the stronger our community. As we've moved past seed funding, we've seen both our income and our contributions diversify, and this has had a positive impact on the project.

Ethical consultants

Here is another question. Is it OK for money donated to a non profit to be funnelled to a for profit consultancy to develop software? Should donors be OK with their money ending up into the pockets of a for profit software consultancy rather than remaining in the organisation they donated to? It is easy to dismiss this question as a bit naive: non profits are always going to be dependent on the services of specialist for profit firms (accountants, lawyers and so on), but it is worth exploring a bit.

We all have our 'favourite' anecdote of the non profit software project that didn't live up to the hype, or was never delivered, while the consultant pocketed the cash. It's tempting to think of open source as the solution to this problem, but just as many of us can point to a similar story for a project built with open source.

Just because we have chosen to work with non profits, to release all of our code as open source, and just because we are 'in it for the right reasons', that doesn't make us automatically eligible for money from funders. What matters is that we deliver, and if we want non profits and foundations to give us money, we need to put systems in place to hold ourselves accountable.

A key part of accountability is transparency. If potential donors can see who gave what, why they gave it, and how it was spent, then they can make an informed decision on whether to support us.

In a fully transparent system, I think, it becomes less important if a specific item of work was carried by a non profit, a for profit, or by a freelance individual. What is important is that there is a record of what happened so that people are able to see if the person did they do what they said they would do. People who know more about the legal structures of organisations and how they impact individual motivations might take issue with that idea (I am certainly not an expert) but I think it is worth exploring the ways that we can use transparency as a tool to encourage our best work and ensure that we are living up to our hype.

Transparency is not a guarantee of success. Things will continue to go wrong from time to time. As we all know, occasional failures are the price of trying something new and difficult. But while it doesn't eliminate failure, transparency does force whoever carries out the work to deal with the consequences of failure, and prevents people from delivering multiple failures, at the expense of non profits, with no accountability. For those that are doing things right, transparency should tip the balance in their favour.

Accountability, transparency and Open Collectives

Open Collectives are a framework that can provide a lot of what we need to create transparency. Quoting from their website, Open Collectives are 'a new form of association, transparent by design'. Here, for example, is the page for the Open Collective that organised the Sustain conference, on which you can see the annual budget for the collective, where the money has come from, how it has been spent, and the current balance.

Open Collectives make it easy to collect money, issue invoices, administer expenses, and so on. They can also help with the legal side of things: local chapters can act as hosts for collectives. For example Open Collective UK is a community interest company that could support a UK based collective.

Granted, CiviCRM does a great job on many of the workflows mentioned above: collecting money, organising events and so on. The good news is that both systems are open source and there is lots of potential for collaboration, though that's a topic for another post.

Open Collective is certainly not the only project tackling sustainability in Open Source. It stood out to me because of the focus at the organiastional level and the emphasis on transparency. Tidelift and Gitcoin also stood out as interesting solutions to the problem, and there are many others that we might explore.

Believing in our funding model

In comparison to some newer open source projects, CiviCRM's funding model can look fairly 'traditional'. Many newer projects today are choosing a hybrid model: for example an 'open core' community edition alongside a more feature complete commerical offering, and I sometimes wonder if our funding model is a bit idealistic. Sustain restored my faith in our model by providing examples of open source communities that are making it work, some of which are following a path similar to us. QGIS and Eclipse are both sustained in large part by businesses that provide professional services around the product, and contribute back financially and in-kind. Here is the Funding section of the Eclipse Foundation's Wikipedia page - the majority of their funding from membership dues, and according to their annual report, their revenue has been increasing year on year since 2014: in 2017 it was $5.6M and in 2018, they estimate it will be $6.5M. If we can increase the size of our community and the number of active contributors, we can make CiviCRM work along similar lines.

For a bit more inspiration, here is a great post with details of how Hoodie is funded, and some funding metrics for the Ghost project.

How much do we need for sustainability?

This is an important question that we can't answer right now. But we do need a good answer to it. If we can say to people "Our target is to reach $X in income in the next Y years, by growing our community by Z%. Here is our plan to do it - would you like to help?", then that is a fairly compelling pitch. Without something along these lines, it is much harder to convince people to put their hands in their pockets.

A few thoughts to wrap up

The CiviCRM community is a diverse place. One of our great strengths is the freedom to experiement and choose how we work without getting permission from anyone else. I'm not trying to tell anyone how to run their business, or that we all need to transition to Open Collectives in the next twelve months. Just sharing some ideas that inspired me that I hope might inspire you too.

I am looking forward to trying this stuff out over the next few months and would love to work with others that want to do the same. Two things I would love for us to do are: come up with some specific figures for the journey over the next 3-5 years; and experiment with Open Collective for a specific CiviCRM development project. Let me know if you would be interested in either of those. With a bit of luck, self sustainability will just be a stop along the way - we'll reach our goal and keep on going on the other side.

Thanks to everyone at Sustain, and everyone in the CiviCRM community whose thoughts and work over the past few years have inspired this post. And thanks for reading it! I would love to hear your thoughts and feedback on my analysis, and would be happy to expand on any parts of the history that I have missed out.