Openfare - Monetize software with one commit.

Last update: Dec 2, 2022

Related tags

Utilities openfare

Overview

OpenFare

🪙 Monetize software with one commit. 🪙

OpenFare monetizes any software library with one code change.

The goal: fund the next million software content creators.

The system:

payment plans defined in code
the OpenFare license
a tool for managing payment obligations across thousands of software dependencies.

The OpenFare License is a lot like the MIT License. The code can be modified, forked, reproduced, executed, and compiled without restriction by anyone. With two exceptions:

Commercial users are subject to payment plans defined in code.
The license and payment plans can only be modified by the license copyright holder.

Simple setup for developers. And payment management across thousands of software dependencies for commercial users.

Join the chat room to discuss further.

Payment Plans Defined in Code

The OPENFARE.json file defines commercial payment plans for a software package. It is always located next to the project OpenFare LICENSE file (usually in the top level directory).

The following example describes two payment plans. One plan is applicable for organizations with more than 100 developers, and the other for those with less. In the former case, a one off payment of 50 USD must be made via Stripe. In the latter case, two payments must be made every 30 days using the Lightning Network, one to Contributor A and the other to Contributor B.

{
    "plans": [
        {
            "conditions": {
                "developers_count": ">=100"
            },
            "payments": [
                {
                    "method": {
                        "name": "stripe",
                        "public_key": "pk_live_thn8fkM3p7jV25rj5HwkRVJq",
                        "url": "https://api.stripe.com"
                    },
                    "recipient": {
                        "name": "Company LLC.",
                        "address": "12, Yellow Brick Road, UK"
                    },
                    "price": "50 USD"
                }
            ],
            "frequency": "once"
        },
        {
            "conditions": {
                "developers_count": "<100"
            },
            "payments": [
                {
                    "method": {
                        "name": "btc_lightning_keysend",
                        "address": "02788242941915ed5a101511b8dfeb6db81e0fcd7546f6a55ef4dedf590a7d7ff4"
                    },
                    "recipient": {
                        "name": "Contributor A",
                        "address": null
                    },
                    "price": "0.0002 BTC"
                },
                {
                    "method": {
                        "name": "btc_lightning_keysend",
                        "address": "03446242941915ed5a101511b8dfeb6db81e0fcd7546f6a55ef4dedf590a7p8kk2"
                    },
                    "recipient": {
                        "name": "Contributor B",
                        "address": null
                    },
                    "price": "0.0001 BTC"
                }
            ],
            "frequency": "30 days"
        }
    ]
}

Motivation

The public software ecosystem has a maintenance problem. Thousands of critical software dependencies are maintained on the good will of casual volunteers. This fragile state means that critical software is abandoned or maintained with a passing interest. A security and stability nightmare.

Sponsorship and donation schemes have largely failed. They are not game theoretically viable strategies for addressing the problem. The solution is micro-payment compensation at scale.

I've written a Hackernoon article on this topic here: Funding the Next Million Public Software Contributors.

Concerns

Can't project maintainers just setup a website with payment plans and customer accounts?

OpenFare defines payment plans in code whilst avoiding the unnecessary overhead of customer accounts or a website. A commercial entity can make use of thousands of software packages. OpenFare standardizes payment plan information across software packages such that it can be managed programmatically at large scales.

What if commercial users neglect to pay? Who will stand up for the project maintainers?

Software developers who work for commercial entities want to pay for well maintained source available software. They understand that the situation is precarious because open source developers largely go unpaid. They also can't easily justify donations or charitable sponsorship when they work at for-profit companies.

What obligation do maintainers have to the project after being payed?

They have no obligation. A maintainer could receive payment and not work further on the project. But the popularity of the project and the associated payment plans would be public information. Competing projects where maintainers are willing to work for the same payments would win out.

What happens if a project uses several versions of the same software package?

For a given software package, only the payment plans given in the latest in use version is considered.

Comments

Document and version lockfile fields semantics
Currently it looks like the OPENFARE.lock fields are basically defined by the rust structs in the codebase and (de-)serialized using serde. While this makes initial implementation fast, it would be good consider the long-term usage of this file. Specifically, different repositories will have OPENFARE.lock files generated by different versions of the tool that will be long-lived (i.e. may not be updated for years/decades). Developers may wish to use other third-party tools to generate and process the files. As such, it would be good to:

Ensure the file format is versioned, so as to allow forwards- and backwards-compatibility. That is, old versions of the openfare binary should gracefully detect and fail when attempting to read OPENFARE.lock files which were generated by future versions of openfare binaries. And they should gracefully handle older versions of OPENFARE.lock files that were generated by older versions, ideally without bumping up the version number.

Document the allowed fields in the file and their meanings.

Additionally as discussed in the matrix chat, it would be good use a file format that allowed for in-file comments as well (hjson was mentioned, although after looking at I'm not such a big fan of it).

Basically this issue amounts to "standardize the OPENFARE.lock file format" to the point where there can exist independent tools that can operate on it.
opened by staktrace 9
Add lockfile json schema, validation, unit tests, and an incomplete integration test
Some initial steps for lockfile validation.

Remaining to do after this:

More validation checks

Get the integration test passing, and add more of them
opened by willhansen 4
Pros and cons of various payment methods
There aren't a lot of payment methods that support the use case targeted by OpenFare (small payments split hundreds to thousands of ways). I'm thinking this would be a good place to discuss which ones are viable to implement and use.

Paypal

Pros:

Familiar to many users

Commonly supported

Cons:

Transaction fees have a percentage and fixed part.

The fixed part adds up quick with many contributors. 0.30$ * 1000 contributors = 300$

Known to freeze accounts sometimes (especially with proximity to cryptocurrencies)

Batch payments require a business account

Bitcoin lightning network

Pros:

Low transaction fees

Fast

Cons:

Requires a bitcoin transaction to get currency on and off the lightning network (expensive and slow)

The technology is not even ready yet? (lnpay?)

Other crypto-currencies

Pros:

More established than the lightning network

Low fees and delays (depending on which currency)

Cons:

Extremely volatile coin values.

Makes listing prices in coins non-viable.

Fetching current coin-to-USD value at time of payment could lead to payers attempting to time the market?

Onboarding and offboarding money must go through crypto-currency exchanges

How to handle a lock file payment method for a currency that no longer exists?

(Only applicable for unmaintained code)

Impossible to pay, so the associated code can only be re-written?

Have a more reliable secondary payment method listed (like paypal, or mailing a cheque) just in case?
opened by willhansen 1
Define a minimum supported rust version

It's usually good practice to define a minimum supported rust version for rust projects. Even if it's "whatever the latest rust release is", it would be good to make that explicit. I had rust 1.57.0 on my machine but it doesn't build openfare-lib because of the format!("{payee_name}___{unique_id}") format strings which are new in 1.58.0.

opened by staktrace 1
Make this repo buildable standalone

Currently checking out this repo and doing a cargo build fails because it contains a path dependency to openfare-js. Looking at the openfare-js code (which is in a sibling repository), that has a path dependency back into this repository. This is not really ideal - either all three (openfare-lib, openfare-js, and openfare) should be in separate repositories using crates.io dependencies, or they should be in the same repository/workspace. I don't recall offhand if you can actually publish to crates.io with path dependencies; I suspect you need to have versioned dependencies for that so it would be better to have that in the Cargo.toml files, and then use [patch] in the workspace file to set up the local replacements.

opened by staktrace 1
Fix typos

This updates "payed" to "paid" in the README. For possibly way too much information as to why this is the correct spelling here, you might be interested in this blog post.

Thanks for this project, excited to see where it leads.

opened by jamesa 1