When we started Open Source Collective for Clap, we (the maintainers) had a discussion on what to do with the money. We have some maintenance expenses @kbknapp is currently paying out of his pocket every year, like the clap.rs domain name, clap.rs hosting, a VPS build server, etc. We definitely want to use some of the fund to reimburse him, and maybe set some aside as the rainy day fund. Then the discussion moved on to the topic of leftover money and how it should be used. As expected, this is where the most of discussion was revolving around.

Some Open Source Collectives, like webpack, prefer to pay the maintainers a certain amount of money every month. The problem with that is distribution of funds for maintainers is very subjective. What criteria should we use? Should we base it on the amount of work they do? Does the amount of work mean number of commits? Or number of SLOC? Or should we just evenly distribute among all the maintainers?

All the above approaches have their own drawbacks, which I would rather not go into detail. There is also another issue that, given that Clap is part of the Rust CLI working group, the maintainers are more likely to change, which creates more issues regarding the distribution of the funds.

Considering the gravity of the hard questions and low expectancy of the income, we decided that we didn't want the money for ourselves and we would rather invest it in something else.

Some Open Source Collectives, like storybook, just keep it in the account and let it pile up for the rainy day. This is a good strategy and we do intend to do that, but we still wanted to do something with the money so it would help us to speed up the development of the project. One of the obvious ways to do this is to fund the downstream dependencies, but we don't have many dependencies. Another way is to reward bounties for solving Github issues. BountySource and IssueHunt are some examples on how it can be done, and there is some consensus that it helps the development of the respective project.

There are some studies on the above mentioned concept. It's been found that issuing small rewards is the most successful strategy. The smaller the reward is, the more contributors attempt at it, and at least one of them ends up getting the reward and solving the issue. The larger the reward is, the less people attempt at it, and it ends up in a failure. Large rewards are generally issued for complex tasks, and this complexity requires a very deep knowledge of the project from the contributor. Turns out most of the contributors who have this kind of knowledge are maintainers themselves, which just means no new contributor is helping the development.

For example, we had already had a large reward for one of the issues that had been waiting for more than a year. It had attracted very little attention, the people who'd tried to take it on hadn't succeeded, and it ended up closed by one of the maintainers.

We decided to move forward with using the funds to issue $5 and $10 rewards for Github issues we think are easy. Any new contributor can easily finish the task, and the maintainers are freed up to work on more difficult tasks, thus increasing the development speed.

I decided to test this theory (paying from my pocket, we don't have any money in here yet), and I am glad to say that the experiment was a success. There were quite a few new contributors who finished the bounty tasks and claimed the reward (a few rejected the monetary reward and we reassigned the money to other tasks). Now these issues are done and closed, and the maintainers have got some weight off their shoulders.

We are happy to announce that we will proceed forward with "tiny bounties" once we start getting money on this platform.