The long story on paying lifters
How we split up subscriber fees
Here's how the money flows from subscribers to lifters, through Tidelift:
- We invoice subscribers for their Tidelift Subscription which they pay to us in accordance to the terms of their contract.
- On the third business day of the month, we run all the subscription fees for the preceding month through our algorithm to allocate the income by package they use.
- The allocated revenue is the split between Tidelift's share and that owed to potential package lifters.
- If any package is being lifted by multiple lifters, those are further split according to the allocation those lifters have agreed to. Similarly, if a lifter has agreed to lift more than one package, we combine the income from those packages.
- Finally, we send each lifter's share of income to their virtual wallet via our payments partner.
How we compute how much to pay
For each package, we compute a share of subscription fees. There are three main factors in this computation:
- Subscriber usage. Packages receive a share of fees only from those subscribers using the package.More subscribers using the package means more money!
- How much subscribers pay. If we charge subscribers more, there's more to divide up.
- A weight. A package containing a large framework gets a larger share than one containing a 2-line function. Currently, the weight is based primarily on code size with some adjustments. If we tweak our weightings in the future, we'll strive to do so in a way that avoids radically changing existing income levels.
There's no ceiling on how much a package earns. There is a floor, however: if the payment computation arrives at a trivial total for a package, we reassign the money to other packages. It's impractical to pay very low amounts because there's some administrative overhead for us to pay and for you to lift.
Note that, for some packages, we're guaranteeing a minimum payout per month for a certain period of time. We pay out the guarantee even if the share calculated above is smaller than the guarantee. This guarantee money does not affect calculated payments to other packages.
When you apply to lift a package, we'll review together whether we're weighting it properly. We'd like to know about and adjust for duplicate copies of code, autogenerated code, vendored code, test-only code, and so on. This review may change our income estimate.
Does the location in a dependency graph matter for payments? Example: P is a package and L1 through L5 are dependencies.
P ├────┬─────┐ L1 L2 L3 └─┬──┘ │ L4 │ └─┬─────┘ L5
We don’t currently consider direct vs. transitive (or distance through the dependency graph) in which packages we pay; the rationale is that we’re asking for the same work from maintainers regardless, and we’re paying for work done. So L4 and L5 are paid just the same as L1-L3.
Our reasoning is that the subscriber concern is that all the OSS that ships as part of their application is security-clean, licensing-clean, and going to be maintained into the future; it doesn’t really matter how that OSS happens to be factored into packages. Think about a package that starts out as one big package and decides to break up into lots of little ones, usually there’s then some kind of root package or meta-package that pulls in many of the new more granular packages.
What is the Tidelift share?
We don't want to lock this number down until we have more data, but can commit that the majority of subscriber fees will be paid out to lifters.
One way to think about this is: "in order to pay the most to maintainers in absolute terms, how much does it make sense to invest in sales, marketing, tools, and administration?"
In other words, we are spending some of the incoming money in order to make more money. We're going to be optimizing this in a data-driven way as data arrives, so the exact numbers will change.
We can say for sure though: the reason we founded the company was to help open source creators and maintainers get fairly compensated for their work.
Our goal is to maximize total maintainer earnings in absolute terms rather than maximizing the percentage of revenues paid to maintainers, and we think it's right to spend more on sales (for example) if it increases the total payouts.
Where we send the money for a package
The maintainers of a package tell us who to pay. This can be a corporate entity (for-profit or nonprofit) or an individual.
Dividing money among co-maintainers
If a package has multiple co-maintainers, you'll need to agree as a group on an approach. By default, the first lifter for a package configures the bank account for 100% of the package's earnings, but on request we can split it up among lifters or move bank account responsibility to a different lifter.
For example if you have two co-maintainers who want to split up earnings equally, let us know (via email to email@example.com) and we'll configure your package such that each co-maintainer's configured Hyperwallet account receives 50% of earnings. (Each maintainer will have to sign the lifter agreement.)
When payments are computed and sent
On the last business day of the month, we snapshot subscriber usage and lifter status and begin the process of computing payments. We send payments on the third business day of the next month.
Payment processing through Hyperwallet
We process payments through a PayPal-owned service called Hyperwallet. Hyperwallet allows us to send payments to lifters in most countries around the world.
Information required by Hyperwallet
After you're first approved as a lifter, we'll create your Hyperwallet account, and Hyperwallet will ask you for the following information:
- Completed and signed copy of the applicable tax document:
- Choose one of these Hyperwallet payment options:
- Bank transfer: You will need a Routing Number/Swift Code and Account Number
- PayPal: You will need your PayPal email; this is only available if you are located in the US and use the same email address for your Hyperwallet account
- Proof of identity
If you get stuck or have any trouble, please let us know through firstname.lastname@example.org.
Hyperwallet activation via email
Activation emails are sent when issuing the first payment—don’t worry if you haven’t received an email just yet.
- Upon clicking the “Activate Account” button and you will be redirected to the Hyperwallet Pay Portal via a unique URL.
- Click “Verify my account using my Payee ID” and enter your Hyperwallet Payee ID here. In most cases this will be your GitHub handle, but if you have any concerns, log into your Tidelift account to confirm.
- Complete the Activate Account form by check the appropriate box at the top (Individual or Business) and fill in your personal or business information.
- Next, you will be prompted to set a password* (min of six characters), select two unique security questions and answers, and agree to the terms and conditions of the service to complete the activation process. These security questions are used by customer support to verify the identity of the caller as well as reset a lifter’s password when using the Forgot Password feature
If you don't see a Hyperwallet activation email
If you missed or accidentally deleted the activation email, don’t fret! You can initiate the activation process by navigating directly to the Hyperwallet Pay Portal. Select either “email” or “Payee ID” from the dropdown which will initiate an activation email.
If you don’t receive an activation email, it may be because there are no funds in your account. Please contact us at email@example.com if you believe there may be an issue.
How does Tidelift comply with US sanction requirements?
Our payments processor, Hyperwallet, actively monitors high-risk, restricted, and prohibited country lists against criteria from our regulators daily. Any countries that have been sanctioned will be automatically blocked. Lifters registered in blocked locations will not be able to access the payment portal, nor will lifters in non-restricted countries have the option to payout or change their country to a restricted location. Additionally, payments made to a restricted location will be frozen to ensure no future transactions occur.