How does Tidelift pay maintainers?
tidelift.com
tidelift.com
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.
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.
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.
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.
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.
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?
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?
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
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?
Probing actual line-of-code usage stats would be impractical, I suppose. It's a difficult question, but an important one
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.
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.
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.
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.
- 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.
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.
When a company is not open about their fees, naturally I assume the worst. Why would they hide the information otherwise?
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? ;)
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.
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?