The conventional funding model, in which grant making bodies hand out six figure sums to qualifying organizations, is broken.
At it’s best the standard grant funding model is woefully inefficient:
- Huge amounts of funds are wasted on ‘administration’
- Time-poor NGOs and smaller orgs are forced to compete for limited funds, guaranteeing that the vast proportion of time invested on applications is wasted
- Funds are generally used to build proprietary tools and closed source products, which limits their availability, reliability, and reusability, further reducing the effectiveness of the funds
- The ‘monolithic’ model of deploying the funds, in which the grant receiver attempts to define the final product to be built, specify it in its entirety before work has begun and employ someone else, usually a consultant, to develop the output, is not a pragmatic method for developing successful projects
- Yet more time and money is wasted on inefficient monitoring and reporting
At its worst, the grant funding model is downright corrupt. Grant recipients employ friends and create new projects to spend funds quickly before deadlines, which rarely delivers high-quality work.
Grant funders cannot be blind to these problems. But in order to change the way they allocate funds we need a new model which minimises waste and corruption – and maximises the productive output of every penny of funding available AND every second of development time invested.
As it turns out, the model already exists. The solution to efficient grant funding is bounties.
The micro-financing of open source bounties increases the productive output of grant funding by at least a thousand times
NB - when I use the terms ‘open source’ and ‘Developer’ I am not just referring to software and people that write code. I am referring to any task for which the work, and the results, (i.e. the ‘development’) is shared openly.
The process of open source bounties works like this:
- Someone identifies a task and creates an ‘issue’ defining the work to be done (which is small enough to be easily manageable by one or two people in days or weeks, or broken down into further issues)
- Someone (not necessarily the person who posted the issue) funds the issue by allocating a ‘bounty’ to it
- If the issue has not been funded, or seems underfunded, a Developer can post a proposal explaining how they would approach the work – and their price
- Developers pitch for the work, by submitting short proposals to the issue
- The Issue creator selects a Developer and opens a dialogue to provide clarification about the task
- The Developer works on the issue
- The Issue creator reviews the work and requests any final amendments
- The Developer finalises the work and posts it in an open forum
- The Issue creator releases the bounty to the Developer
- Anyone else can now view, use, fork or build on the work
Here’s a real life example of how an open source bounty can out-perform other funding models:
In our Murmurations project – which seeks to provide a better way to manage maps and directories, via an open protocol for decentralized data sharing – we work on a voluntary basis, in our spare time.
Our tiny team of three built a freely available, open source protocol and API which anyone can use, download and remix, to aggregate decentralised data.
We had the core technology working, but no way of demonstrating how what we had built was useful for enabling the aggregation of decentralised profiles and other data. In short, we needed a map and directory to demonstrate what we had built.
So we created an issue defining the required work.
We got a tiny grant of 1000 DAI (DAI is a crypto currency which is pegged to the dollar so 1000 DAI ~ $1000) from the Community Currency Alliance – who needed a map of projects in their sector, and used this to create a Gitcoin bounty which we allocated to the issue.
Within a day, a couple of qualified developers had pitched for the bounty and we commissioned a developer we had never met before, but whose previous work demonstrated he had all the required skills.
Within a couple of weeks, and with minimal communication considering the complexity of the task, the developer completed the task.
We released the 1000 DAI bounty and we now have an aggregator which demonstrates the concept of Murmurations by providing a map and directory, which can be filtered by the initial schemas to show different ‘slices’ of the data which is being shared on the Murmurations protocol. The Community Currency Alliance got their map for a fraction of the cost of commissioning a similar project in its entirety and the ‘building block’ they funded is now available as an open source component, which anyone else can use for free, or fork and develop for other uses.
This model delivered increased efficiency in a number of ways:
- The grant maker obtained a superior outcome at a fraction of the cost – in this instance, a map of their sector which pulls data from decentralised profiles – by building on our existing work. By contrast, other mapping efforts have absorbed ~ $250,000 in funding. I.e. This model delivered a 25,000 times saving.
- The Developer did not need to go through a lengthy application and review process. I.e. This model delivered a ~ 10 times saving.
- As well as supporting the development of Murmurations and the CCA the final outcome is available as part of the Commons, making it freely available to others to utilise. I.e. a potentially infinite benefit.
Micro-financed bounties are the holy grail for solving wicked problems
The micro-financing of open source bounties is the holy-grail, not just for open source development, but for humanity as a whole. It offers a dramatically more efficient and democratic way of funding the seemingly insurmountable (and increasing urgent) category of challenges facing humanity – known as wicked problems.
A platform combining the functionality of GitHub (to manage Projects and Issues), Twitter (or some other ‘broadcast’ messaging system i.e. mailing lists), Patreon (for sponsoring issues – in any currency, including crypto) and GitCoin (for allocating bounties to Issues) would do much to catalyse the nascent collaborative potential of the human species.
Introducing The Open Projects Hub
Imagine a platform incorporating the functionality above, called ‘The Open Projects Hub’, on which anyone could submit a Project, and create Issues within Projects, and request funding to finance bounties for Issues.
A platform of this nature would enable anyone, not just institutional funders, to finance bounties for their most pressing needs, thereby creating a democratic, open marketplace for development of any kind.
An Open Projects Hub, which promoted the ‘skills’ and ‘interests’ of individuals as listed in their Profiles, and matched these to the ‘needs’ of Projects, and highlighted larger issues which require more than one or two collaborators, could also facilitate the development of collaborative teams.
Clearly, it would be less beneficial to build such a platform using proprietary tools or as a proprietary platform – and in fact a single ‘platform’ is probably not the best way to deliver for the complex diversity of needs and interests of the funders, developers and co-creators who are needed to make an ‘open projects’ model successful.
A decentralized model, which did not require users to sign up to any particular network or platform, but enabled the aggregation of information and updates about Projects and Issues, and the allocation of bounties to the Issues – regardless of where they are hosted – would be preferable. This is what Murmurations’ provides; A protocol for decentralised interoperable data sharing – and the aggregation of this data – to enable cross-platform and inter-network signalling to catalyse collaboration at scale.
Murmurations is just one concept – and there are other projects which share similar aims. But one thing seems clear, whichever project manages to assemble the necessary ‘building blocks’ in the right way seems highly likely to change the model of grant funding and sponsorship – and accelerate the development of the collaborative commons.
Co-creating the collaborative commons
This is the goal The Open Co-op is working towards – one issue at a time. Check out the next few building blocks we have planned for Murmurations and the funding which has been allocated to, and is required for, these. If you would like to join us to collaborate on the development of Murmurations, The Open Projects Hub, or other aspects of the collaborative commons we’d love to hear from you.