
How does Tidelift pay maintainers? - dmoreno
https://tidelift.com/about/lifter
======
sammorrowdrums
I really like the sound of this, however when there is a lack of transparency
on the site regarding costs, and breakdown of how the money is divided
(payment handling, a cut for the company themselves etc.) - and you need to
"request a demo" to find out enough to make a decision, no matter how genuine
this proposition is, I feel it loses a lot of it's open source positive
credentials.

As a side example, Elementary OS App Store is an example of more what I'd
expect, they try to encourage payment for open source projects and handle the
distribution of funds, but they have transparent costs and the project itself
is open source.

Please can you include more information on your website.

Also in terms of vulnerability mitigation, NPM have started giving me
warnings, so I am much better able to handle the upgrade / management / damage
limitation of using packages with known vulnerabilities for JS at least. I'm
sure that's coming more widely, so for me the Licence stuff is great, and some
of the vulnerability info is handy, but if I was to use the service it would
be to primarily pay out for packages I use professionally, so with the current
info provide, that's an instant no. I'd have considered it genuinely if I knew
what it was exactly you were proposing.

~~~
hp
Tidelift co-founder here, thanks everyone for the interest.

I've added a discussion of Tidelift's share to the docs at
[https://tidelift.com/docs/lifting/paying](https://tidelift.com/docs/lifting/paying)
TLDR our commitment is to pay out at least 50%.

What we're doing at Tidelift is an enterprise software product (analogous to
something like Red Hat Enterprise Linux), but a difference is that instead of
hiring a bunch of people to repackage upstream projects, we're offering
upstream maintainers the _option_ to participate directly by helping us do the
work - for a revenue share, rather than a flat fee.

The app store analogy isn't quite right; an app store provides a catalog and
some review services, but much of their 30% rake is profit as far as I know.
The Tidelift share includes funding all the non-engineering parts of an
enterprise software business, including a crucial one, a sales team.

The point of this is to make the pie larger. We want to pay the maintainers
(at least) 50% of a lot of money, instead of 90% of a little money.

btw there are a number of options out there to make straight donations to
projects and we support those! That isn't mutually exclusive with what we're
doing here and in fact many of our participating maintainers also take
donations.

~~~
sammorrowdrums
Thanks for a bit of added clarity. I do understand it is more than an app
store model, good luck with making open source projects more sustainable.

I actually do wonder if some of your revenue should go on bug bounties too,
rather than project income only (even though I know some of that will probably
be put towards bug bounties), but regardless I hope it changes the ecosystem
for the better.

The main part of the Elementary OS app store analogy was that it is all free
software, and their intention was to encourage people to pay for it
regardless, which is the only crossover with you - I think the guys there
would actually be interested in this model too.

------
doesnt_know
My personal (and possibly unpopular) hot-take on these types of schemes are
that they should be against the law. It's the same concept with the Brave
browser.

I don't feel like these organizations have a right to attempt to represent
other entities without express consent.

I mean they take money on behalf of other individuals/organizations, advise
those paying them that they will forward the money on and then attempt to
coerce the target entity to sign their contract, accepting based on their
terms/pay out ratio, usually based on some opaque "formula".

The more popular the service becomes, the more leverage they have.

~~~
toofy
Yeah, I'm with you.

It seems like many of these types of projects are sometimes forcing themselves
in the middle when none of the parties involved invited them. Your example
with brave browser is a great example.

They're like some kind of weird Man-In-The-Middle Attack brought along a
marketing team.

------
sleepychu
> _In return, subscribers can be confident that those packages are well-
> maintained._

1\. How can they be confident of that? (Hint: it seems like what you're saying
is that you'll place some conditions on maintainers, presumably if you see
enough adoption this could make you a powerful stakeholder)

2\. I see tidelift offers some value in managing your other dependency
concerns, I assume they extract some money for this. What is the ratio of
money paid to maintainers v.s. extracted by tidelift.

3\. How much are you charging for this service? Couldn't see a pricing page.

4\. Who is the intended audience? Large orgs? SME? Single developers?

~~~
malux85
Good questions - also how does Tidelift avoid people gaming the system?

E.g. my node_modules folder is full of thousands and thousands of packages,
could I, as the maintainer of several of those packages, split them into 100
sub packages, all dependent on each other and claim 100x the money?

~~~
cmroanirgo
> how does Tidelift avoid people gaming the system?

From the website [0]:

"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. Please do not try to game the system by putting extra junk in your
package—we will penalize this, and more importantly your users and other
maintainers will suffer. If we tweak our weightings in the future, we'll
strive to do so in a way that avoids radically changing existing income
levels. "

It seems they're aware of the possibility of gaming.

[0]
[https://tidelift.com/docs/lifting/paying](https://tidelift.com/docs/lifting/paying)

Edit: formatting

~~~
dest
The weight is a very difficult problem in my opinion.

~~~
janekm
Indeed. Amongst other issues this scheme appears to encourage making a large
volume of moderately-useful changes to a lot of repositories, rather than a
smaller number of difficult but essential changes.

~~~
prepend
The Facebook effect coming to OSS. Lots of activity and noise, little to
negavitve value.

------
Crosseye_Jack
> There is a floor, however: if the payment computation arrives at a trivial
> total for a package, we reassign the money to other packages.

Not sure I like this. It’s not very clear for a start. I read it as they do a
calculation on each subscribers code use, if they deem its “not worth it” they
give the money to someone else, they didn’t say what that floor is or offer to
“hold the money until it reaches a valid payout value”.

From what I read it as if your code was valued at $0.05 for a sub they will
give that 5c to someone else but what if 1000 subs was using that code? Would
the maintainer get that $50.

Also seems they are weighing it on the code side of the project not the actual
code used. What if I’m importing Newtonsoft’s Json library but “only” using
using the object serialization function The release zip for that is
6.something MB where I may feel that the websocket server/client I use which
come in at 130KB~ provides me with “more value”. But based of the size of the
two repos Newtonsoft would be getting much more of my sub than the websocket
lib.

Edit: > Each maintainer will have to sign the lifter agreement.

What happens if they haven’t signed the agreement? (The link to the agreement
404’s) lets say a sub signs up thinking “great all my repo maintainers will
get paid...”, you detect they are using Repo X that has not signed up to your
service because they don’t know about it (yeah sending a email / issue on GH
saying “Hey, we have money for you, just give us your bank details” won’t get
the email immediately sent to spam :-p) What is happening to those funds? Are
you letting the subs know their money is not being collected? What if I don’t
want to agree to your terms (I dunno, don’t like your font choice or
something) and I will never sign up, would the money I would be getting get
split up to the other repos the subs are paying for? Do you tell them that
Repo X isn’t getting a cut of their money? (Remember the sub may think Repo X
is really worth the money.)

What about if they are using a Microsoft Library in their DotNet Core project
but have a paid account with Visual Studio / Microsoft?

~~~
fastball
Because a two-line package should not need money to maintain it.

The payment is intended to make up for some of the time the developer of the
dep expended, it's not supposed to be proportional to the utility other
developers get out of it.

That's what makes it still OSS and not commercial software.

~~~
Crosseye_Jack
> Because a two-line package should not need money to maintain it.

I didn't bring up "two line packages", the websocket package in question is
more on the size of 20k of code lines.

> The payment is intended to make up for some of the time the developer of the
> dep expended, it's not supposed to be proportional to the utility other
> developers get out of it.

Repo size doesn't always mean time expended.

> That's what makes it still OSS and not commercial software.

OSS can still be commercial software. Code could be A/GPL and still offer
commercial license's to remove restrictions.

And as others have said in this thread its often the smaller / less well
"known" packages that don't get much "love" when it comes to financial
support.

------
TheChaplain
Silly question perhaps, but can't package maintainers include a standard meta-
tag or something in their package for Paypal or something?

And having some command like "npm donate" that essentially does the same
algorithm as tidelift and prints a paypal address for each package.

I'd like that better than having yet another middleman siphoning a part of the
cashflow.

~~~
IshKebab
Nice idea, and that isn't even mutually exclusive with an online version.
Having this as a website definitely has advantages - you can easily set up a
monthly payment, the receiver gets semi-reliable recurring income rather than
sporadic one-off donations, you can pay by direct debit.

I think the real problem would be what is the meta-tag? There isn't really a
standard for "send money to this URL". You could support Paypal I guess, but
do they have an API for sending money? And then you're reliant on Paypal which
is fairly notorious for just cutting off anything vaguely unusual (like this
would be) and keeping the money.

~~~
jrm2k6
I was going to start working on this, but yeah the issue is that the website
would still act as a middleman to send the money around. There are a few
problems with this:

\- some use paypal, some use patreon, some use neither so where do you send
the money

\- even if it was either paypal or patreon, they would take their cut which is
unfair.

\- even if organizations/foundations would give their bank account info, you
could probably use stripe to send the money to the right place, but not sure.

I would be happy to discuss about this by email as I think it is an idea that
could be further explored.

------
joosters
I searched around but couldn't find any information on what the company
charges for their service, or how large their cut is.

When a company is not open about their fees, naturally I assume the worst. Why
would they hide the information otherwise?

------
undecisive
> 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.

The less-known players are typically the ones that get nothing for their
effort, regardless of the size of their codebase or the effort put in.

I didn't see any mention of what "trivial" is - presumably that's dependent on
payment processor fees, etc?

I get that this is early days - very well known packages have 0 subscribers -
what is the plan to springboard this? I'm guessing a couple of big names with
big paychecks to spread around is part of the plan? Or just hoping for HN
notoriety? ;)

------
prepend
How do they calculate value to subscriber? Is it based solely on subscribe/not
subscribe? Do I pay the same as an individual as my corp? Do I pay based on
the number of my projects that use the subscribed package? Do I pay based on
how much of the package I use (one tiny method vs one giant method vs every
single method)? Or based on the number of time I use it as measured by static
analysis? Or dynamic?

Will tidelift need access to my source or runtime to determine billing?

While it’s a good idea to help maintainers, I’m not sure this will help. The
cost of accurate payout seems more expensive to determine fairly than
commercial licenses.

I think existing models of dual license and patronage (red hat) or just flat
out patronage (microsoft, google, Apple projects).

Or just having a wallet address in repos and let users choose how much to
donate. Maybe wash it through a common wallet or include a hashtag in
transactions so you can gamify it. I get a badge on my Github profile for how
much I’ve given and received. My organization can show what projects they
support. But this shouldn’t be a company. There’s no infrastructure. Having a
company take 30% (or whatever non-zero level) of donations just to distribute
would turn this into the WoundedWarrior of OSS.

------
peteretep
I can't find any packages that have an estimate. Even some of the more popular
NPM stuff:

[https://tidelift.com/lifter/search/npm/left-
pad](https://tidelift.com/lifter/search/npm/left-pad)

~~~
karulont
Here is one example with an estimate:
[https://tidelift.com/lifter/search/npm/eslint](https://tidelift.com/lifter/search/npm/eslint)

------
prepend
Looking forward to more info and transparency. This being non-OSS gives me a
carpetbagger feel.

There are also maintainers who cannot or would not like to receive payments.
What happens to their share? Redistributing it seems troubling. Could
maintainers direct it to charities or something?

~~~
hp
The payments are not a donation, they are earned by helping provide the
Tidelift Subscription service (the set of tasks and responsibilities
enumerated at [https://tidelift.com/docs/lifting/tasks-
overview](https://tidelift.com/docs/lifting/tasks-overview) ). If someone
earns the money it's theirs and they can send it anywhere they want, charities
for sure are an option.

~~~
prepend
This makes sense. So if I cannot “earn” money for my contributions, I just
wouldn’t sign up to be a lifter and my project would not be included in your
program.

------
Nilef
I’d like to see a Humble Bundle model where I can choose which split each
package gets

~~~
peteretep
That rewards packages that you know you're using, rather than the ones you're
actually relying on.

