Octobox is supporting its dependencies
In October 2018 Andrew and I began an experiment in open source sustainability. Today we’re drawing a line under that experiment with one final gesture: $10,000 to support the software that supports us.
For nearly four years Octobox.io has provided Andrew and myself with a vehicle to explore issues concerning the sustainability of open source software. We began our first experiment, creating an open source business and we pledged at least 15% of our revenues to support the community. Within six months Octobox had over 100 paid accounts that brought in thousands of dollars a month in revenue. We refunded 100% of the donations that we used to incubate Octobox in its first 18 months and Octobox Ltd. has since covered 100% of the maintenance costs for its 7,000+ active users.
In 2017 Andrew and I believed and we still believe that the open source community can solve many of the challenges it faces itself, with a little organisation and better communication. Today’s announcement addresses one of these challenges directly:
The opportunities to create a financially sustainable open source project are not equally distributed.
As we wrote nearly two years ago Octobox is in a privileged position: an open source project with an accessible revenue stream that works. We believe that with this privilege comes a responsibility and an opportunity: to improve the software upon which we rely by sharing the rewards that we have derived from it. However, since writing this we have seen a repeated pattern:
Solutions that address the problem of financial support for open source software behave like competitive marketplaces.
In these marketplaces projects vie for the available resources (money, attention, contribution) and inevitably the marketable projects with the exposure, the storied leaders and in many cases the success are the winners. Marketplace-based solutions are great for funding future investments, for supporting projects in which we see potential for a future we have yet to realise. But they will not solve the problem of funding the unseen infrastructure that lies below the waterline. In order to do this we need to adjust our lens:
We need to fund projects based on what we use rather than what we see.
Recently we’ve seen projects like LibreSelery, Flossbank and FairOSS pursue approaches based on the idea that people are not always the best judge of who and what requires our support. Each of these projects incorporates some assessment of exactly what you depend upon in deciding how best your support could be utilised. They each have their own merits and we encourage you to explore what each has to offer.
Over the last three months we’ve been working with Joel and Pete at Flossbank to add support for the Ruby ecosystem and adding payments services so that maintainers can add their preferred payment method. We’ve been hugely impressed by what they’ve already built so far and we can’t wait to see what they build in the future. As a vote of of confidence today we’re making the following announcement:
Octobox is investing $10,000 in the dependencies on which it is built through Flossbank.
The complete list of packages, and the amounts are available in this gist and on our Flossbank profile. If you’d like to claim the investment for your project then please register for Flossbank or contact me directly at benjam@octobox.io.
Donating $10,000 is the simple bit, how to distribute it among the 462 different packages that Octobox includes directly, or indirectly is another matter. At which point we must apologise. We’re not about to share the perfect algorithm, scrawled on a dorm window in Cambridge, MA. We won’t even pretend we have a fair approach to solving this problem. If you’d like to know more Joel has shared Flossbank’s approach on the Sustain OSS forum.
Our intention here is to encourage others to make similar investments in their dependencies, to make people think a little about their biases when they look to support the software they depend upon, to highlight the fact that we need a number of approaches if we are to ensure the sustainability of the software we depend upon today as well as the software we will build upon tomorrow, and finally to encourage those with the time, the expertise and the experience to join the conversation about how best to solve this problem together.
Thanks
Andrew & Ben