This is part of a series of blogs called Advice to Y-Combinator non-profit startups. Of course it has wider application than that. Part 1 was some general advice to get this started
There was a discussion on Hacker News about how to make money on open source software, where I chipped in a bit about how we at Akvo do it. I wrote enough to actually make a coherent blog post out of it.
For quite a long time there has been this idea going around that organisations who create open source software should make money on providing software support. This has proven to not be very lucrative for most businesses that try this and other models have been tried, some of which are described in the above discussion.
We took a somewhat different approach with http://akvo.org
We noticed the really poor use of Internet systems in international development aid. More than $120 Bn is spent yearly on this, and nobody really has a clue where the money goes. There is no useful overview. So we started building tools to fix that and supply them as a paid for service.
Everything we build is open source software. We have 45+ people working on this, with paying partners such as the World Bank, UNICEF, Liberian government, Mars Chocolate and many hundreds more. It is not your ordinary business model, but it works and we are growing. You can make open source software and earn a decent living.
Core success factors
We believe that our success comes out of a few core things:
- We brought together domain experts as equals, i.e. people working in international development, water and sanitation issues (our starting market), network organisations, computer software and services, computer software marketing and communications, to solve a problem. This is fairly unusual in both the software and the international development industry.
- We say our team is a three legged stool. Partner team (more about that below), software team and communications team. If we don’t treat all three equally the stool falls over. We go so far that we think it is imperative to not have an organisation run by the tech or the international development side, but by both sides. So we have until know had two directors of the organisation, one from each domain. Working very closely with the comms director.
- Maybe most importantly though, we have a very experienced partner team. They have worked in this market for decades. They know “everyone”. We literally have connections to thousands of organisations through our networks and we understand how to talk to those organisations. Our partner team know where all the gremlins are and how the processes work. They know how to get the required startup and expansion investments as well as how to get the big organisations to use our tools.
Non-traditional sales and marketing
About the partner team. We don’t consider us having any customers. We treat all of the organisations that work with us as partners. They then treat us as partners too and it completely changes the relationship when you are trying to solve a problem. Of course it helps that we are a non-profit foundation. We are also not-for-loss. We have a functional business model. This is obviously critical.
In a traditional company our partner team would consist of strategic sales people, account managers, project managers, consultants, trainers etc. We have a partner team that fulfils all those roles, but they are a _partner_ team. Sales are not done on a quota, no bonuses are paid (which often drive really crappy sales in a s/w company) etc.
We have no marketing and PR team. We have a communications team. Most of our staff communicate. Everyone is in fact encouraged and empowered to speak for the organisation. The communications team just supports everyone learning how to communicate well. We hardly do any PR. We may need to increase it, but it mostly does itself based on our peoples open communication.
No bespoke development
Some open source product organisations try to supplement their income by doing bespoke development on top of their product. We don’t as we find that this only distracts you from building a good product. Our revenue comes from hosting, training and implementation consulting services, but not technical implementation services, but implementing the tools themselves within the organisation.
We avoid technical implementation services, as most organisations we work with have a really low internal technical knowledge. If we then take the responsibility for implementing the technical side, we find that they don’t take the ownership of the bigger issues. These are things like learning to publish open data and the changes in culture which this implies in the organisation. Then their failure to embrace the change needed in the organisation is projected as our failure to implement the technical side.
We have technical account management, but require for our partners who implement our tools to either have in-house the required technical skills or hire in the required skills. If they don’t do this, take ownership of the bigger issues and hire competent technical project management and help, we don’t do the projects, as they are very likely to fail. This may sound obvious, but often it isn’t to the partners we work with.
I could write a lot more, but we are creating the Akvo Handbook, which will outline all of this, and be available under an open content license. You can read it all there then. But don’t hesitate to ask any specific questions you may have.