Hacker News new | comments | show | ask | jobs | submit login
How does Tidelift pay maintainers? (tidelift.com)
84 points by dmoreno 8 days ago | hide | past | web | favorite | 32 comments





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.


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


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.


Agreed. We're not stupid, we know there has to be a rake - so just tell us what it is.

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.


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.


> 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?


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?


> 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

Edit: formatting


The weight is a very difficult problem in my opinion.

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.

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

> 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?


I'm glad I'm not the only person who found this surprising. Withholding payment until a threshold is reached would make some sense, though for some packages they might be waiting years. Another approach might be to reserve some kind of "bump" fund - a small percentage from all the other projects gets reserved, and when small packages get to half the threshold they can be "bumped" in the theory that 5 dollars to a big project is nothing, but to a tiny project might be game changing.

Probing actual line-of-code usage stats would be impractical, I suppose. It's a difficult question, but an important one


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.


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


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.


There is thanks https://github.com/feross/thanks - with an open issue to read the URL from package.json https://github.com/feross/thanks/issues/2

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.


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.


Can’t you just sign a crypto wallet address with the gpg key of the contributors as determined by the project?

That’s likely the simplest way and doesn’t require PayPal or revealing identities of maintainers.

Also works well by nesting encrypting the wallet private with each maintainer so wallet can only be used with all maintainers in agreement. Or establish a smart contract, etc etc.

This seems easy to set up. But many won’t pay.


That exists but it's a different, not-mutually-exclusive thing. The Tidelift Subscription is not a donation tool or money-transfer mechanism, it's a product - produced in collaboration with interested upstream maintainers.

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?


> 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? ;)


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.


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


Here is one example with an estimate: https://tidelift.com/lifter/search/npm/eslint

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?


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 ). If someone earns the money it's theirs and they can send it anywhere they want, charities for sure are an option.

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.

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

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



Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: