4 ms·
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 publi
by unlinked_dll 7y ago
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.
- manigandham 7y agoThat 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.
- Etheryte 7y agoNone 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?
- galaxyLogic 7y agoI 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.
- yawaramin 7y ago> 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.
- galaxyLogic 7y ago> 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.
- yawaramin 7y agoYou'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.