Explore financial sustainablility options for Arbor's future.

We've talked about this in depth during two different sync meetings:

As funding open source work/communities is by no means a solved problem, there's naturally a lot to talk about. This issue is meant to serve as a central place to continue that discussion asynchronously (since we can likely spend every single sync meeting talking about it).

To be clear, our goals (in priority order) are:

  1. Make Arbor cover its own hosting/development costs
    • domain names
    • hosting fees
    • app store fees?
    • etc...
  2. Reinvest small surplus funds into our community:
    • get professional advice in areas where we have no contributors (legal, design, security, documentation, whatever we need)
    • create some marketing materials to spread knowledge of our platform
    • appreciate our new contributors by sending them small arbor-branded things (like mugs and stickers)
    • making mugs, stickers, t-shirts, and other swag
    • etc...
  3. Fund development work on arbor (which of the below is feasible depends on our budget)
    • implement bug/feature bounties (like bountysource)
    • pay people to contribute part-time
    • pay people to contribute full-time
    • note: this contribution work (in my view) includes not only arbor itself, but also our transitive dependency tree. If we manage to support work on ourselves, we should support the code and infrastructure that we stand on. Also, this may not all be development work. We may look to pay someone part-time for design or other types of contribution. We'll figure that out if/when we ever have this kind of money.

I think that we've identified several viable revenue models for arbor. I'll try to summarize them here:

  1. Usage-based donations
    • Essentially, we track how much load each user puts on our systems per month (requires some development work) and divide our total operating expenses among the users based on what percentage of our load each user was. So if we had $50 in expenses and you were 2% of our load, we'd say that you cost us $1.
    • We then DM (or some other communication method) each user and ask them whether they'd be willing to donate enough to compensate us for their usage. We could also suggest rounding up to the nearest dollar in order to fund development.
    • The idea here is to overcome the diffusion of responsibility by showing each user their own share of our costs. We can't capture that perfectly, but we can approximate it by infrastructure use.
    • The primary drawback here is that there's no guarantee that anyone will choose to donate, regardless of their usage. Income would be extremely unpredictable.
  2. Expensive service use chargeback
    • Arbor will have several semi-centralized services out of necessity. Things like global history search, reliable direct message delivery, and centralized account/key management require some infrastructure, and some of it is expensive.
    • We could charge users based on their utililzation of these services. Global history search would be especially expensive for us because of the cost of running a text indexing service like elasticsearch or one of its friends.
    • Users who didn't rely on those infrastructure components from us would be able to use arbor for free, but those who did would be billed for it.
    • This ensures that the bulk of our costs is covered by those who require them, but it also means that users are dis-incentivized to use important features of the platform.
  3. SourceHut-style hosting subscriptions
    • SourceHut requires anyone who wants to host content (a mailing list. ticket tracker, repo, etc...) to pay a subscription, but not anyone who just wants to contribute to an existing entity.
      • We could adopt a similar model where users need a subscription in order to create a community hosted on our infrastructure, but not to participate in an existing community. The subscription itself might be flat, or it might be scaled depending on the size and activity level of the community.
    • We could also require a subscription in order to create DMs with any user. A paying user could send anyone a DM in our infrastructure, and a non-paying recipient could still reply. However, the non-paying recipient couldn't DM a completely different user. This offers maximum utility for the subscribed users while not totally crippling the unsubscribed ones.
    • The benefits here are that many users could actually use arbor to collaborate in many communities for free. This would likely be a good experience for them, though we'd be eating the cost of their usage.
  4. Beg
    • There's also the old way of just having a snippet in our README asking for donations, and we could certainly do this first, but I don't think it's effective enough to realize even our first funding goal.

The key thing to remember is that we're not like a company trying to monetize our user base. We're trying to find a model that serves our users by making Arbor free/affordable for them, but doesn't completely starve us for the resources that we need in order to survive as a project.

I think that the models above can also be combined in interesting ways. I'd love for members of our community with thoughts on this to chime in here!

Assigned to
5 months ago
2 months ago

~whereswaldon 4 months ago

For the initial project launch, just having a way to collect donations at all seems quite valuable. We were very interested in opencollective.org, but they have a requirement of more than 100 GitHub stars (or similar) for a project before it can use their full platform features. Our GitHub mirrors aren't anywhere near that, and I have no desire to run some kind of campaign to get them there. In the short term we may need to either use a different platform or use a non-default financial host on opencollective. ~amolith is looking into the different financial host options right now.

Other platform options and their considerations include:

  • Github sponsors
    • highly visible in UI
    • matched for first year
    • doesn't solve tax problem at all
    • zero fees
    • lets you embed references to other sponsorship platforms
    • slightly distasteful bc GitHub (proprietary)
  • Liberapay
    • Obscure (relative to the others)
    • doesn't solve taxes
    • Stripe charges 2.93%+30c fee iirc (~amolith)
    • Paypal is another option but I don't remember their fees
  • FOSSPay
    • stripe-based
    • doesn't solve taxes
    • aggregate display of revenue from patreon and github
    • fosspay example
    • can also add custom html at the top (open source)
  • Patreon
    • Creators maybe unhappy and looking for other things?
    • unknown platform fees?
    • doesn't solve taxes
  • Cryptocurrency?

~whereswaldon 2 months ago

I have a liberapay account where I can be sponsored for arbor and other work here. I think that's probably sufficient for handling the release-blocking aspect of this, though I think it'd be wise to set up some other platforms as well.

Register here or Log in to comment, or comment via email.