>For this new ecosystem to work, we needed a consistent, universal dev experience for every package on the registry.
That's the most absurd sentence thing I've seen in awhile, editing is orthogonal to package management. But others have that thread covered. This got my attention:
> Pika publishes each package directly from source, so malicious or hacked authors can't skip code review or sneak malicious code unnoticed into the registry.
I don't see how injecting yourself in the middle solves the problem, since exfiltrating data in the background from a downstream app is both necessary for some services and hard to identify as "bad".
What I'd like to see in a registry is a registration fee per project (or pay per publish), non-anonymous registration (provide a government issued ID and mandatory 2FA), delayed deployment after publishing, and aggressive but open auditing. Plus org/user namespacing.
Basically if you have an environment where a bad actor has to pay money, steal someone's identity, and takes awhile before they can even verify their attack has been successful - you'll cover a huge chunk of the attack surface area.
There is a gaping hole in the middle of this whole setup and it's that most actors are good actors and you're now demanding them to pay money. Furthermore, you're asking them to pay money while it gives them no benefit, it benefits third parties. As a publisher, I do not care if people who use my code trust me — if they don't, they don't have to use the code, I have lost nothing. There is no incentive for any package maintainers to join this endeavour. Asking me to provide real-world ID to pay the registrar money? Never going to happen as long as there's a free alternative without the additional constraints.
Raising the barrier to entry can tend to raise the quality of the ecosystem. I can also think of some incentive structures where the money that you pay to publish also helps you get traction/publicity, or to have a system where the top N packages get N% of the pool of money each month.
As for requiring real-world ID to spend money, why are you averse to that? AirBNB does that, your landlord does it, your bank does it. Does your employer do business with people anonymously? I think the bounds of privacy stop once you start shipping product to the world. If you want to remain anonymous, fine, go to an untrusted distribution channel where your code ca remain. If you want people to trust you, put some skin in the game.
None of the examples you've made are appealing to me as an OSS developer. There is no incentive for me to increase publicity — what would it give me? If anything, having a lot of users is annoying: you get irrelevant PRs which are out of scope, beginner users submitting bug reports that are actually bugs in their own code, etc etc.
Your second point is the exact opposite of what most OSS developers want. By and far, most OSS projects are small components that end up somewhere down the dependency tree. This means someone else (a-la React) would get the money while leaving smaller dependencies (a-la string utils) unfunded. This is the polar opposite of what maintainers want.
Your last point of wanting trust is a straw-man. I already made it clear in my previous reply: as an OSS developer, I do not care if people trust my code. There is simply no incentive for me to care about it. People consuming my packages reasonably do want some sort of validation, but that's their desire, not mine, so why would I pay for that?
I don't think I would pay either. But then the question becomes: Why do you publish your software? Why not just keep it all to yourself?
If you have some incentive to share your code I assume it is you want your users to have and use your code. If you want them to use your code you want them to be able to trust that code too.
> Why do you publish your software? Why not just keep it all to yourself?
Because that's how open source works? People publish stuff somewhere and others can use it. Explicitly no warranties are made. Anyone who uses it does so at their own risk.
> If you want them to use your code you want them to be able to trust that code too.
Trust doesn't have to be paid for in a walled garden model. People can use my code because they audited it and found that it's good. Or they could just use it because they know my reputation and trust it.
> People publish stuff somewhere and others can use it.
Definitely. My question was "Why do they do it?". Nothing forces you to publish it. So there must be a reason why you do that. I assume it is because you want other people to use your software, for whatever reason.
So if you want people to use your software surely you want your software to be of high quality, which includes that people can know it is of high quality, which is where validation might help.
Whether you should pay for validation is a different question, I'm not saying you should.
You've made a couple of incorrect assumptions here.
> I assume it is because you want other people to use your software, for whatever reason.
No–as an OSS publisher I just want to make it possible for other people to use it. I don't necessarily have to want them to use it.
> ...surely you want your software to be of high quality
Again, not necessarily. It's a mix of factors–how much time and energy I have, how important the code is to me, whether I actually do want others to use it, etc. But there's nothing inherent in publishing OSS that says it has to be high-quality.
That sounds like paying for exposure, and more downloads of an open-source project usually just means more work for the maintainer.
The problem with IDs and paying for registration is that this is specifically not a business, unless you're talking about a private registry that users also have to pay to consume.
> Basically if you have an environment where a bad actor has to pay money, steal someone's identity, and takes awhile before they can even verify their attack has been successful - you'll cover a huge chunk of the attack surface area.
If you have an environment where a good actor has to pay money, provide their passport name with proof of identity, and has to put up with artificial deployment delays, I think you'll miss out on a huge chunk of good actors.
I'm not convinced that it's possible to outsource your trust and audit decisions to some third-party system. We should be scaling at the speed of actual human trust, not giving up our privacy to companies or our security to randos.
I would add: and bad actors would not be stopped by this, it is easy (and cheap) nowadays to buy identity with document scans enough to pass verification in payment systems. I doubt that any package registry could implement more stringent checks.
And a fee is just a small bump in the way of bad actors that would like to monetize their misdeeds.
There's plenty of places/ways to distribute software anonymously. And depending on software from an anonymous identity with no trust that the registry verified who they were or if subsequent publications came from the same entity is an attack vector.
There is a time and place for anonymity, but I don't think a dependency registry is one of them (most of the time). And I think if you're going to make a new registry, such verification is a way to make yourself different.
> if subsequent publications came from the same entity
The way you do that is by having signed packages. Gov IDs don't help with that, unless the registry verified the ID every time you published an update, which is impractical (unless you have a smart ID card, but most governments don't issue those).
That's the most absurd sentence thing I've seen in awhile, editing is orthogonal to package management. But others have that thread covered. This got my attention:
> Pika publishes each package directly from source, so malicious or hacked authors can't skip code review or sneak malicious code unnoticed into the registry.
I don't see how injecting yourself in the middle solves the problem, since exfiltrating data in the background from a downstream app is both necessary for some services and hard to identify as "bad".
What I'd like to see in a registry is a registration fee per project (or pay per publish), non-anonymous registration (provide a government issued ID and mandatory 2FA), delayed deployment after publishing, and aggressive but open auditing. Plus org/user namespacing.
Basically if you have an environment where a bad actor has to pay money, steal someone's identity, and takes awhile before they can even verify their attack has been successful - you'll cover a huge chunk of the attack surface area.