Outline Intentions & Desired Outcomes (ex. want to interact with the community to ensure that there is movement on important issues/ideas for the project)
Bert: Hi, first time in a meeting like this. Use open source and npm daily.
I wrote one of these RFCs for solving an issue with funding
Currently people can put a fund field in package.json, but it requires people to actively engage, and do it indepently for every package
Proposal is an attempt to solve this
Create a broker in between. An invidual states the amount they want to give back to the community and the broker works as a proxy during npm install to see what packages individuals install and divvy up funds based on how many times you install every package that has a fund property in a package.json
At the end of the month the broker delivers funds to the packages
Initial MVP would have npm as the broker, but in theory a 3rd party could play the role of the broker and folks could choose the broker they want to use
An additional incentive could include a new form of license that requires payment for commercial use
wes: have you heard of "back your stack" which is part of open collective. They are doing something somewhat like what you are talking about acting as the broker.
bert: in the RFC I call it accountant
wes: check it out because I think it is really cool
wes: I think the existing RFC is a bit broad. Likely good to focus on the technical aspects. Perhaps metric hooks that could report to endpoints. Focusing on the CLI implementation
bert: there are ways of setting up proxies + third parties that could potentially serve as the place to collect this data
Isaacs: This is a very broad RFC, the way I read this there isn't much for the CLI to do differently
bert: I think the primary difference would be a check on install to ensure license compliance
Isaacs: enforcing compliance client side is easy to circumvent
The bigger thing if you don't worry about circumvential, even if you just make a warning you are putting it in front of a person who can't really solve the problem. The working installing is not neccessarily the decision maker about this
Wes: in my experience, pushing through support for OSS funding as an IC is very difficult. There is no switch you can flip and now you are in compliance
Isaacs: this is different from security notifications, where you are putting it directly in front of the person who can remediate
A more effective approach is likely to do that tracking and compliance verification server side and send an email to the operator and chase down the big offenders
If Google is installing and owes you $10k a month you chase them down, not the small organization that owes $2
If the accountant is a separate entity and they are running a separate proxy, there really is no way to ensure the package is installed via the proxy rather than the public registry.
If the default place I'm installing is not doing the accounting it is hard to enforce
This is almost more of a business partnership proposal between GitHub / npm and "Pay it Forward" or Open Collective or similar groups
Already ideas being ideated around GitHub sponsors and integration into npm funding
Want to put license zero on your radar. They have a parity license which allows use for open source. Prosperity license lets you use it as long as your service is free.
Bert: it is good to have on radar but it doesn't really solve the problem
Isaacs: The thing I like about license zero is that the licenses have been crafted by some of the best legal minds in OSS.
Does a good job of identifying what counts as payment to get an exception
The bigger issue is that this is something likely to take to the GitHub sponsorship team or the npm product manager rather than the CLI
Myles: rambles about the OSI, the defenition of OSS and offered to talk 1:1
Isaacs: One challenge is that these types of programs often result in the same small group of people passing around smaller amounts of money
Bigger companies are likely the ones that can pitch in more. Their percurement departments tend to be the place that approves funding, but small ammounts are not likely to get their involvement
The licenses can actually be a major stopper from adoption
Next steps are persuing more of the corporate + server side angle
Christian: it is hard to convince my boss to give a certain sum of money to OSS every month, even though we do contribute. I could imagine this could lead to lots of interesting questions like, why do you use so many packages?
Does this need to happen in npm? Is a GitHub action just as nice? When you have the launch party or go live, maybe you can get some report regarding the packages you benefited the most from and perhaps companies will be willing to give a significant amount of money
Bert: number of installs could be a good metric to figure this, could ask developers why the install so much. Most expensive package will be the one critisized by the employer. It will also reduce the usage of that package. But choosing the minimum amount is up to the library owner.
Isaacs: let's move on, mostly bizdev/server stuff.
Myles: installs not the best metric. perhaps separate how payout vs collection happen.
Killian: With the new peer depedency resolution algorithm there are isues if the peers don't match. Depending on the setup you have the peers might not be able to be matched
Many TypeScript utilities has no upper limit set, but there can be problems.
A way to override specific to peer dependencies. There is an existing RFC for overrides, but it is complex and early stage. Would be good to have something for peers early on
Isaacs: The main thing I would want to dig into would be "what is the peer specific override feature have the the core override feature doesn't"
We are planning to support overrides in early 7, and we don't want to find ourselves in a place where it conflicts
There is a --legacy-peer-deps flag to return to the legacy resolution algorithm
In the future we will give more accurate output of the conflicts
Is there some other / more subtle way to solve this problem
Could we resolve peer deps in a way that allows pre-releases would that resolve this issue for TypeScript?
Peer deps tend to have much broader dependency ranges. Right now beta will not match 12.x and that won't be considered good. If we allow pre-releases in peer-deps that would make things a lot easier.
This could create a problem if nothing else depends on that dependency
The big pushback is how does peer overrides interact with overrides
Wes: It might be worth taking a quick look at gradle, which has a bunch of features around dependency resolution like this. I think overrides solves all of those problems. They don't have the peer dep problem, but it is the same type of problem as an alignment rule when two different ranges are specified and they need to be alinged
I think the override spec handles this, but it might be a bit verbose.
Isaacs: in the RFC right now for the override script you can say "typescript version x" and you'll get that version everywhere
Wes: this is complicated in the case where it is "alright" to have multiple versions and want to override a preference
Isaacs: I'd phrase it as gradle only has the peer dep problem due to the flat tree
Killian: Overrides will solve this, but it depends on when it will land
Isaacs: Have a better peer-deps error msg will make things much better
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe