4 ms·
> You've exceeded Y free installs for package X. Choose one of the following license options to continue: > > 1. $49 for a lifetime license > 2. Don't install
by WJW 4y ago
> You've exceeded Y free installs for package X. Choose one of the following license options to continue:
>
> 1. $49 for a lifetime license
> 2. Don't install package
That would be several absolutely radical paradigm shifts in how we use packages; depending on how big Y is some companies I know would blow through that in a single parallel CI run. They slice up their (enormous) test suite in over 100 slices and run each slice in a separate docker container. I also wonder how pricing will be determined. As an extreme example, that colors.js package that was in the news a few months ago because the dev intentionally broke it would not be worth $49 even when it did work. It literally only added terminal coloring codes to strings. JS is kinda notorious for having many tiny packages of course, but even larger pieces of software are extremely difficult to price. How much should postgres cost for example?
Finally, how will they determine which of the devs get how much each? Does it all go to the repo owner or will there be a pro-rata split over each contributor? Both will do some interesting things to the "FOSS community spirit", imagine having a useful PR refused solely because the repo owner doesn't want to share the income with others. I usually don't even bother asking for attribution when making a PR to an open source project, but if I knew the maintainers were getting an income from it then suddenly working for free seems a whole lot less attractive.
- mustache_kimono 4y ago> How much should postgres cost for example? I might match it to install base. How to handle "linux" or "bash" or "coreutils" is the real question. Do "core" projects need this kind of cash? > Finally, how will they determine which of the devs get how much each? Does it all go to the repo owner or will there be a pro-rata split over each contributor? Could be determined on a per project basis. Project could say upfront -- sorry, all money goes to core contributors, or to cancer research. These don't seem like tough problems so much as they seem like nice, high class problems to me.
- solardev 4y agoOrrrr... can we try to not monetize OSS and let project success be an honest reflection of community needs & interests? Funding too often becomes a conflict of interest. I'd rather see small projects come and go as time permits, than have OSS become the next victim of monetization-driven "optimizations"... what's next, Copilot offering better code blocks if you pay for premium suggestions? Functions with cloud DRM that keep some of the internals in a lambda and charge you per invocation? Examples in docs being written for Platinum sponsors instead of common use cases? OSS is one of the few remaining examples of actual public cooperation without a profit motive. Injecting capitalism into it is just going to ruin it. Having the funding model ("is it sustainable") be a separate concern from the codebase ("what's the best way I can make this library/framework") is a GOOD thing to keep separate, almost like the editorial vs advertisement/sales divide in journalism. It's also a good test to see whether an individual project is worth turning into a business. If not, it can (and arguably should) just remain someone's pet project, a labor of love rather than another cheap money grab. I don't want Github to turn into the Android app store, with a bunch of useless apps charging $0.99 for some basic functionality.
- mustache_kimono 4y ago> I'd rather see small projects come and go as time permits, What this really amounts to is that you/large companies like the work you get for free. > OSS is one of the few remaining examples of actual public cooperation without a profit motive. Injecting capitalism into it is just going to ruin it. This is so far off the mark. The profit motive made OSS what it is today. The only issue right now is many OSS devs aren't being paid/appreciated for their efforts. > Having the funding model ("is it sustainable") be a separate concern from the codebase ("what's the best way I can make this library/framework") is a GOOD thing to keep separate, almost like the editorial vs advertisement/sales divide in journalism. Agreed, but remember what you're paying for is the service of packaging. The idea is the package maintainer can keep the garbage out. That's what you're paying them for. OSS is in many ways a market distortion. And that's good for some and horrible for others (e.g. grade school teachers used to get paid much, much less in real terms than they do today). A small fee for commercial, production use of Ubuntu's packaging service, a portion of which funds devs? I'm not certain that's a bad idea.
- wowokay 4y agoWhy is it open source software if the goal is make money off of it? The problem is devs shouldn’t feel like their hobby became a job, they should stop maintaining the code if it becomes to much of a job, or commercialize it. Have a fork that is private and monitized with extra features. The street performer example was spot on, the existence of a package and its promotion doesn’t entitle it to compensation. What if the performers suck and detract from the passerbys park experience? Are they entitled to compensation for indirectly listing to music they didn’t want to hear in the first place?
- mustache_kimono 4y ago> Why is it open source software if the goal is make money off of it? The problem is devs shouldn’t feel like their hobby became a job, they should stop maintaining the code if it becomes to much of a job, or commercialize it. Have a fork that is private and monitized with extra features. Why isn't it? Did Linux stop being OSS when Linus first got paid for developing it? Plenty of devs would love to do the same and make a few dollars from their hobby project! > What if the performers suck and detract from the passerbys park experience? Are they entitled to compensation for indirectly listing to music they didn’t want to hear in the first place? I made top level post re: these questions[0], but I'd make a few addendums to the article: 1. a packaging service for FOSS should always be free for non-commercial use, 2. for commercial use, the pricing should not be on a per package basis but priced for the service of packaging the packages and the pricing should be modest, 3. substantial portion of which (>50%) should then go to the FOSS devs based on their install base, 4. this should except the standard installation, which should receive a highly reduced share. [0]: https://news.ycombinator.com/item?id=31961092 https://news.ycombinator.com/item?id=31961092