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.<p>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.<p>Please can you include more information on your website.<p>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.
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.<p>I don't feel like these organizations have a right to attempt to represent other entities without express consent.<p>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".<p>The more popular the service becomes, the more leverage they have.
> <i>In return, subscribers can be confident that those packages are well-maintained.</i><p>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)<p>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.<p>3. How much are you charging for this service? Couldn't see a pricing page.<p>4. Who is the intended audience? Large orgs? SME? Single developers?
> There is a floor, however: if the payment computation arrives at a trivial total for a package, we reassign the money to other packages.<p>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”.<p>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.<p>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.<p>Edit: > Each maintainer will have to sign the lifter agreement.<p>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.)<p>What about if they are using a Microsoft Library in their DotNet Core project but have a paid account with Visual Studio / Microsoft?
Silly question perhaps, but can't package maintainers include a standard meta-tag or something in their package for Paypal or something?<p>And having some command like "npm donate" that essentially does the same algorithm as tidelift and prints a paypal address for each package.<p>I'd like that better than having yet another middleman siphoning a part of the cashflow.
I searched around but couldn't find any information on what the company charges for their service, or how large their cut is.<p>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.<p>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.<p>I didn't see any mention of what "trivial" is - presumably that's dependent on payment processor fees, etc?<p>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?<p>Will tidelift need access to my source or runtime to determine billing?<p>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.<p>I think existing models of dual license and patronage (red hat) or just flat out patronage (microsoft, google, Apple projects).<p>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:<p><a href="https://tidelift.com/lifter/search/npm/left-pad" rel="nofollow">https://tidelift.com/lifter/search/npm/left-pad</a>
Looking forward to more info and transparency. This being non-OSS gives me a carpetbagger feel.<p>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?