How about token rewards that exchange for real money(or stable coin)?
The project will sell NFT licenses to back it.
Tokens can also be bought and spent to get prioritized attention to the problems, feature requests, and bugs.
Alongside an open forum, this will; 1. Reduce friction (no hassle of; finding a developer who will entertain your request and negotiate the terms with the person) 2. People can pool in tokens (other people who have the same problem can also contribute), and Above all, 3. encourage novice developers to participate.
While I agree that you can do this without a blockchain, Web3/tokenization will; 1. Make it easier for cross-border participation; 2. Encourage early participation (you can hang on to your token rewards and see the value increase when the project becomes popular), and ultimately, incentivize the project's advocacy.
Web3 unlocks ownership; by tokenizing the project, you enable the maintainers to own the project.
This is a "when all you have is a hammer" type of idea. This product can be provided way cheaper without involving any sort of blockchain at all, by approaching the developer(s) directly and offering them money to fix your bugs or write the features you want.
One issue I have: are installed packages really the only criterium?
I was dreaming about a system where the OS and runtimes automatically track what is used and how often / for how much CPU cycles maybe?
And then everybody could dedicate a certain budget for example each month, which then would automatically distributed amongst all apps, packages and linked libraries, from the kernel functions at the bottom, through whichever libc‘s etc are used, up the packages layer, Webservers and/or gui stack etc.
But of course that’d still leave lots of open questions:
a) people could try to habe the system by using up more resources than needed for example.
b) what’s the „value“ of a piece of code run? Who decides what is how valuable?! Maybe someone implemented something really clever, really important, but it doesn’t actually use a lot of resources… other glue code could run a lot but not be especially Hard to implement.
So I think this one is a tough one to do correctly, but Id like to see something in this direction getting traction.
I think the major issue is gonna be to get real inertia going & get people to allocate appropriate funds.
This reminds me of the brave browser and distributing funds along the news sources you actually consume.
I really think this could be amazing, even for society as a whole, with people finally being paid for good work they are putting in and not only the ones who are good at marketing & triggering the masses.
But it seems to be a real hard problem to solve in a good way.
I like the idea but feels like this would reduce incentives to write an efficient software. Bloated runtime like Electron would earn more dividends and more hates.
I like that people are thinking about this, but this particular model bums me out: it assumes that the average package management user is a corporate user, rather than another member of the community. It also disincentivizes one of the major inflows for open source contribution, which is installing a random tool, finding a use case that you need or bug that needs fixing, and contributing it back upstream.
I guess it would also incentivize some weird behavior like buying a project to take it private and try to extract value from users of the toolchains it's been built into.
This would be marginally better than buying a project to inject a backdoor or malware per instance, but it might be a lot more common? (It seems to be much more compatible with existing ~vulture-capital behavior.)
It would probably be Bad for most maintainers if our dependency chains were regularly being roiled by someone taking a package private.
The average "member of the community" is a "corporate user." In my experience, OSS is frequently written in IC's on-the-clock discretionary time in an official, sponsored capacity. It might even be ticketed!
And when those contributors pull in 3rd party tolls and libraries to complete their work, that's when they inhabit the roll of "the average package management user."
To what "community" do you refer that's outside of commercial activity?
The people who this work is ostensibly meant to fund: the ones who engage in open source because they think it’s the right thing to do, or because they’re hobbyists, or they just like helping others.
To be clear, I am both: I am paid professionally as a software developer, and I’m a member of the open source community for my own reasons. My job already pays me, so the question of compensation is meant to pertain to the latter category.
OpenFare is attempting to solve this problem. It allows developers to effectively invoice by adding a file to their software package. No need to modify package managers.
What are the more simple steps a package manager can take today to make this less painful? Asking for a friend as I work on one of these. I hear about the pain here, but not so sure what layer the solution should be at.
While I’ve been exposed to this problem a number of times and have pushed similar concepts like an easy way to see how to donate to a package, I don’t quite grasp the economics nor downstream effects this will have on the world.
If everyone starts to charge money to use their packages, how do we further the development of open source projects and the innovation that brings? How can the student or budget developer be productive if they cannot use packages they rely on to get the job done? What about less developed countries and their access?
If major dependencies are paywalled, how does that affect other packages/projects that took on the dependency? This might get messy quick and change developer behavior to write their own libs / reinvent the wheel.
I do agree that there are better models than donations, but I think we should think in terms of accepting that open source is still open/free and supplementing around it rather than locking access down.
Other platforms like TikTok, YouTube, and others have concepts of creator funds or viewership funds. Perhaps that model may apply better to package managers.
Another idea is taking those models to the private consumer and providing access to subscriber only content/support that is in addition to what is published on the platform itself.
I think this is one of the hardest problems to solve in the package management space. It’s a social problem rather than a technology one and that makes it immensely difficult to start with.
so... the tasks that burn out maintainers are the really boring tasks of maintaining the project, triaging bugs and doing releases.
if end users want timely releases done correctly with secure release processes, signed packages and active security patching, they can pay for that as a service because it is work.
if they want guarantees that their bugs and feature requests will see attention by core developers, they can pay for that as well. there is no guarantee that their paid-for patches will be merged into the main project, so their requests should make sense in the spirit of the project or they should be prepared to pay for maintenance of their custom trees.
> 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.
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.
Orrrr... 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.
> 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.
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.
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?
> 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.
Not really. I'm usually the guy at work advocating that we pay for some service rather than trying to reinvent the wheel. And if I solve some small problem, I push for the company to open source it without a financial and branding push behind it so that other devs can benefit. Not everything should be a capitalist competition.
Patreon and buy a coffee are good models too. And devs are hardly starving to begin with.
I just think some stuff shouldn't be monetized. I on occasion contribute back to OSS too, and it's nice to be able to do that just for fun, as a hobby. Some things turn out better when people are able to detach them from their livelihoods, whether that's a short story or a musical instrument or a small side project. The profit motive ruins a lot.
It's not like funding a project magically increases its quality, either. Then it distorts PRs and roadmaps by making funders de facto product owners. I've run into issues trying to contribute back upstream because it didn't meet the needs of their corporate sponsors. And there will forever be a conflict of interest from that point forward between profit and other concerns.
Besides, the big OSS projects seem to survive fine as is. The small ones aren't making anyone rich and IMO they shouldn't. I wouldn't want my pet weekend project to become another source of financial stress, or have to figure out which lib is best based on pricing models. It sucks the joy out of sharing reusable software.
"I think it's fine for me to make money off certain things, but not for others" and "You're not doing it the right way" is just not a defensible position.
It's like those teachers from an earlier time. Yes, it was really nice for some. We had small classes and a very high quality of instruction, but at the expense of some people were not getting paid what they were worth.
NCAA is another good example. You may like the idea of the student athlete or playing for the spirit of the game, but is that fair to a kid who wants to use his name, image, and likeness rights to make money for himself? Does it make more sense for the university or the NCAA to own these rights?
> I've run into issues trying to contribute back upstream because it didn't meet the needs of their corporate sponsors.
What you're saying is -- the problem will exist no matter what we do. I think it's better that people get paid, if we can pay them.
> And devs are hardly starving to begin with.
And software companies are definitely not starving either. The most advantaged persons in this distorted economy are the users. Having Amazon pay a few dollars is not going to hurt anyone.
> The small ones aren't making anyone rich and IMO they shouldn't.
I agree the article's particular model is not the one I would have chosen. I think there are better ways to do this. See my other comments for how I might do it.
What? There's nothing stopping any dev from charging for their OSS software (and many do, whether individually or as a core part of their business, like Red Hat).
I'm not anti-people-charging for software, whenever they want.
I just don't want OSS communities taken over by profiteering, the same way that the Android marketplace became a cesspool for get-rich-quick crappy apps, or YouTube is filled with automated advertising spam, or the Stack-republishing spam sites. Monetization destroys organic communities -- that's my problem with it.
It's one thing to say teachers should get paid more -- and I fully agree -- another thing to say that say that volunteers contributing to a community project need to be fairly compensated. When you start paying volunteers, it both changes the underlying motives, attracts different kinds of contributors, and also diminishes the emotional reward of their work.
Not saying people can't get paid for indie projects and free (as in freedom) projects, but that there is also value in free (as in dollars) software -- not really just because it's free, but because it creates a different kind of culture and community around it.
This is the critical issue. There is no lack of itches to scratch, or people willing to scratch those itches, so there is no reason to apply market optimisation techniques to that part of the problem. In fact it will provably mess things up [1]
I do think non-market approaches, such as basic income, could be a useful way to help some people to focus more on valuable FLOSS-work. Non-profits, foundations and various coalitions can employ some people, and public spending could be a part.
But I also think there are things n short supply that markets could help with, complementing, rather than supplementing, FLOSS-work. The Linux-kernel is largely created by companies driven by market forces as far as I understand, even if the central administration is largely neutral.
So the market could drive investment in specific initiatives like qa, security, specific capabilities and such, where the central project is a non-profit driven cooperative.
Taking money from A and holding it to transfer to B, no matter for how little a time it takes, is a legal and banking quagmire. Firstly, you are now a trustee of the funds, which sets a pretty high and onerous standard for bookkeeping and cash management. Secondly, banks hate, hate, HATE businesses that take in money from A and parcel it out to B through Z. It's a fraud and chargeback magnet.
I've spent a lot of time with folks from a variety of package ecosystems (RubyGems, PyPI, npm, Maven and Cargo amongst others) and I can promise you, they don't want this kind of hassle. They have more than enough on their plate.
This is not a horrible idea. I might do it a little differently. A free service for non-commercial use and a paid service for commercial use (maybe $5/per CPU per month, $50/year, $150/lifetime). Combine with maybe a 50/50 distribution of income earned to FOSS devs.
That income earned might get non-commercial users to transition and drive mindshare benefits which would force some commercial users to switch.
People should always be free to build from source or even build their own packages, create their own repos, but the kids want native packages and providing more money to package software and make packaging super simple, and well supported for devs is a good thing.
The packaging that the major distros do is fundamentally a service, and I'm shocked this hasn't been tried before. Maybe people will rally around the idea -- the major distros should be compensated, if they compensate developers as well.
I like the idea behind the implementation. The implementation as it stands would kill OSS because majority of the user base of OSS libraries are in no position to pay for every package they install into their fun side projects. This would take away the whole fun point from OSS.
That being said the idea to use package managers as funding channels is not an altogether bad idea. We all use package managers daily and if there were a way to support OSS maintainers through it without any enforcement, it would be huge.
Suppose you install a package for almost every side project. The PM could connect with your Stripe account and allow (not enforce or badger) you to pay directly to the package maintainer. I think one of the most discouraging part of donations to OSS is the recurrent subscription model. If I want to appreciate someone, I'd be open to donating once or twice on my own terms when I like it but these donation platforms force you.
Secondly as a developer I am much more comfortable in my work environment and if donations are integrated into it, I might donate more. Who doesn't like ease?
I think this is a really interesting thought about using package managers, although I would want to consider a few different models.
Trying to just break down the problem a bit:
1. End users don't necessarily donate. This is plausibly due to friction, that it's not worth / risky managing a bunch of small donations.
2. Corporations / Large users, are not well structured to make lots of small donations. The engineers selecting software are disconnected from finance, and pushing through payments is a barrier, with likely some exceptions that can be noted (like companies with individual $ allocations per engineer that they can direct).
Linking this to distribution / hosting services to me makes a lot of sense. I don't agree with the licensing model suggested. Something more like Youtube premium immediately jumped out at me, where I pay x dollars a month to the service, and a portion of that get's split up and allocated to the content creators. On youtube, this sounds somewhat equitable, as I understand it to be a distribution by watch time. On the package manager / software side, this seems way more difficult to allocate in an equitable way.
I like the core of the idea, that if you want to donate, you point your distribution at a service that tracks usage and divides/allocates revenue. And that service manages the allocation of donations, so reduce the friction on individuals and companies, and see the funding for opensource go up.
It would be great if I could pay package managers to take care of the security side of things.
Don’t bother with per package deals though, at least let the package manager deal with that, I want a single predictable invoice giving full access to all packages.
I would consider paying extra to be the last to receive non-security updates though.
I like the spirit of this post.
I think there may be different types of barriers it conflicts with but having conversations like these are important.
I do sometimes think about the distinction of a non-business entity vs a business entity.
Is there a way to allow for individuals computing for the sake of computing (or using open source to create open source) to have free access, while enforcing that any entity making money from the use of the code having to pay for the usage?
Just thinking out loud, I don't know how naive that is (see gpl violations) or how something like that would even be economically structured.
I was going to use stronger language, but let's just say "this is magical thinking".
1. People don't like paying for things, especially when they can get that thing for free with some work on their part.
2. Metering by download is obviously problematic (notwithstanding #1) because now every time your CI job runs yarn install, it gets charged. Meanwhile someone packaging a dependency in a binary that they sell to 1000000 people gets charged once.
In my experience the only way to get people to pay for software is to arrange that they simply can't run that software without paying you. This is obviously in conflict with the concept of OSS. Perhaps you can do something if you can get governments to make it illegal to use OSS without paying, but good luck with that.
If funding happens through package managers there will be race to add packages to make money instead of be helpful, not just to get funding for your actually used OSS project. Package managers will get full of SEO spam. Sites will be full of promotions trying to get your to download their package.
Maybe I don't understand the article, but I assume that any project that did this would immediately be forked into another OSS version and 2-3 bigco maintained versions, and nobody would ever use the original again.
I don't want to have to give my details and current activities to (literally) a hundred different organizations and have my credit card out every time I run apt-get. I can't see anyone tolerating it longer than it took to switch to the fork, which would become the active version. If people are happy to pay, they're going to be happier to pay Amazon or Google than Rando Bob, even though Rando Bob wrote the thing, because Rando Bob could disappear any second.
It's alright to be proprietary if you can't make a living from OSS. You'll lose goodwill and users if you go proprietary, but you may be able to make money on who's left. In order to do that, you're going to have to start over, because all the forks start at the same place you do, and if they deliver better, you lose.
People will be as excited to install these package managers as to install DRM, i.e. not at all. The reason people install DRM is so Netflix, etc. will work. OSS with a million forks will never be as scarce as Netflix content.
Free Software seems to be a kind of acceptance of the low-reward nature of sharing what you write, but says "if I'm not going to get rich off this, no one is going to get rich off this."
So I'll repeat: I must be deeply misunderstanding the article.
The biggest hole I see there is that not all OSS is used as a dependency. If you're talking about fully built, standalone software, then package managers alone can't capture that.
You'd have to target the distribution process as well, which essentially means we're back to square one since these are vary heterogeneous and there is no single/central way of dealing with distribution other than through platform specific or domain specific distribution channels, and these are usually big boys that don't give a damn about OSS maintainers.
43 comments
[ 4.3 ms ] story [ 81.5 ms ] threadOof, this just threw out most of the devs who might be interested in this...
Alongside an open forum, this will; 1. Reduce friction (no hassle of; finding a developer who will entertain your request and negotiate the terms with the person) 2. People can pool in tokens (other people who have the same problem can also contribute), and Above all, 3. encourage novice developers to participate.
While I agree that you can do this without a blockchain, Web3/tokenization will; 1. Make it easier for cross-border participation; 2. Encourage early participation (you can hang on to your token rewards and see the value increase when the project becomes popular), and ultimately, incentivize the project's advocacy.
Web3 unlocks ownership; by tokenizing the project, you enable the maintainers to own the project.
(I am a maintainer of Homebrew.)
- https://www.youtube.com/watch?v=XUqLn21AgPI
- https://podcast.thekoinpress.com/episodes/max-howell-support...
I was dreaming about a system where the OS and runtimes automatically track what is used and how often / for how much CPU cycles maybe?
And then everybody could dedicate a certain budget for example each month, which then would automatically distributed amongst all apps, packages and linked libraries, from the kernel functions at the bottom, through whichever libc‘s etc are used, up the packages layer, Webservers and/or gui stack etc.
But of course that’d still leave lots of open questions:
a) people could try to habe the system by using up more resources than needed for example.
b) what’s the „value“ of a piece of code run? Who decides what is how valuable?! Maybe someone implemented something really clever, really important, but it doesn’t actually use a lot of resources… other glue code could run a lot but not be especially Hard to implement.
So I think this one is a tough one to do correctly, but Id like to see something in this direction getting traction.
I think the major issue is gonna be to get real inertia going & get people to allocate appropriate funds.
This reminds me of the brave browser and distributing funds along the news sources you actually consume.
I really think this could be amazing, even for society as a whole, with people finally being paid for good work they are putting in and not only the ones who are good at marketing & triggering the masses.
But it seems to be a real hard problem to solve in a good way.
I guess it would also incentivize some weird behavior like buying a project to take it private and try to extract value from users of the toolchains it's been built into.
This would be marginally better than buying a project to inject a backdoor or malware per instance, but it might be a lot more common? (It seems to be much more compatible with existing ~vulture-capital behavior.)
It would probably be Bad for most maintainers if our dependency chains were regularly being roiled by someone taking a package private.
And when those contributors pull in 3rd party tolls and libraries to complete their work, that's when they inhabit the roll of "the average package management user."
To what "community" do you refer that's outside of commercial activity?
To be clear, I am both: I am paid professionally as a software developer, and I’m a member of the open source community for my own reasons. My job already pays me, so the question of compensation is meant to pertain to the latter category.
https://github.com/openfare/openfare
While I’ve been exposed to this problem a number of times and have pushed similar concepts like an easy way to see how to donate to a package, I don’t quite grasp the economics nor downstream effects this will have on the world.
If everyone starts to charge money to use their packages, how do we further the development of open source projects and the innovation that brings? How can the student or budget developer be productive if they cannot use packages they rely on to get the job done? What about less developed countries and their access?
If major dependencies are paywalled, how does that affect other packages/projects that took on the dependency? This might get messy quick and change developer behavior to write their own libs / reinvent the wheel.
I do agree that there are better models than donations, but I think we should think in terms of accepting that open source is still open/free and supplementing around it rather than locking access down.
Other platforms like TikTok, YouTube, and others have concepts of creator funds or viewership funds. Perhaps that model may apply better to package managers.
Another idea is taking those models to the private consumer and providing access to subscriber only content/support that is in addition to what is published on the platform itself.
I think this is one of the hardest problems to solve in the package management space. It’s a social problem rather than a technology one and that makes it immensely difficult to start with.
if end users want timely releases done correctly with secure release processes, signed packages and active security patching, they can pay for that as a service because it is work.
if they want guarantees that their bugs and feature requests will see attention by core developers, they can pay for that as well. there is no guarantee that their paid-for patches will be merged into the main project, so their requests should make sense in the spirit of the project or they should be prepared to pay for maintenance of their custom trees.
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.
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.
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.
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.
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?
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
Patreon and buy a coffee are good models too. And devs are hardly starving to begin with.
I just think some stuff shouldn't be monetized. I on occasion contribute back to OSS too, and it's nice to be able to do that just for fun, as a hobby. Some things turn out better when people are able to detach them from their livelihoods, whether that's a short story or a musical instrument or a small side project. The profit motive ruins a lot.
It's not like funding a project magically increases its quality, either. Then it distorts PRs and roadmaps by making funders de facto product owners. I've run into issues trying to contribute back upstream because it didn't meet the needs of their corporate sponsors. And there will forever be a conflict of interest from that point forward between profit and other concerns.
Besides, the big OSS projects seem to survive fine as is. The small ones aren't making anyone rich and IMO they shouldn't. I wouldn't want my pet weekend project to become another source of financial stress, or have to figure out which lib is best based on pricing models. It sucks the joy out of sharing reusable software.
"I think it's fine for me to make money off certain things, but not for others" and "You're not doing it the right way" is just not a defensible position.
It's like those teachers from an earlier time. Yes, it was really nice for some. We had small classes and a very high quality of instruction, but at the expense of some people were not getting paid what they were worth.
NCAA is another good example. You may like the idea of the student athlete or playing for the spirit of the game, but is that fair to a kid who wants to use his name, image, and likeness rights to make money for himself? Does it make more sense for the university or the NCAA to own these rights?
> I've run into issues trying to contribute back upstream because it didn't meet the needs of their corporate sponsors.
What you're saying is -- the problem will exist no matter what we do. I think it's better that people get paid, if we can pay them.
> And devs are hardly starving to begin with.
And software companies are definitely not starving either. The most advantaged persons in this distorted economy are the users. Having Amazon pay a few dollars is not going to hurt anyone.
> The small ones aren't making anyone rich and IMO they shouldn't.
I agree the article's particular model is not the one I would have chosen. I think there are better ways to do this. See my other comments for how I might do it.
I'm not anti-people-charging for software, whenever they want.
I just don't want OSS communities taken over by profiteering, the same way that the Android marketplace became a cesspool for get-rich-quick crappy apps, or YouTube is filled with automated advertising spam, or the Stack-republishing spam sites. Monetization destroys organic communities -- that's my problem with it.
It's one thing to say teachers should get paid more -- and I fully agree -- another thing to say that say that volunteers contributing to a community project need to be fairly compensated. When you start paying volunteers, it both changes the underlying motives, attracts different kinds of contributors, and also diminishes the emotional reward of their work.
Not saying people can't get paid for indie projects and free (as in freedom) projects, but that there is also value in free (as in dollars) software -- not really just because it's free, but because it creates a different kind of culture and community around it.
I do think non-market approaches, such as basic income, could be a useful way to help some people to focus more on valuable FLOSS-work. Non-profits, foundations and various coalitions can employ some people, and public spending could be a part.
But I also think there are things n short supply that markets could help with, complementing, rather than supplementing, FLOSS-work. The Linux-kernel is largely created by companies driven by market forces as far as I understand, even if the central administration is largely neutral.
So the market could drive investment in specific initiatives like qa, security, specific capabilities and such, where the central project is a non-profit driven cooperative.
[1] https://en.m.wikipedia.org/wiki/Motivation_crowding_theory
I've spent a lot of time with folks from a variety of package ecosystems (RubyGems, PyPI, npm, Maven and Cargo amongst others) and I can promise you, they don't want this kind of hassle. They have more than enough on their plate.
That income earned might get non-commercial users to transition and drive mindshare benefits which would force some commercial users to switch.
People should always be free to build from source or even build their own packages, create their own repos, but the kids want native packages and providing more money to package software and make packaging super simple, and well supported for devs is a good thing.
The packaging that the major distros do is fundamentally a service, and I'm shocked this hasn't been tried before. Maybe people will rally around the idea -- the major distros should be compensated, if they compensate developers as well.
That being said the idea to use package managers as funding channels is not an altogether bad idea. We all use package managers daily and if there were a way to support OSS maintainers through it without any enforcement, it would be huge.
Suppose you install a package for almost every side project. The PM could connect with your Stripe account and allow (not enforce or badger) you to pay directly to the package maintainer. I think one of the most discouraging part of donations to OSS is the recurrent subscription model. If I want to appreciate someone, I'd be open to donating once or twice on my own terms when I like it but these donation platforms force you.
Secondly as a developer I am much more comfortable in my work environment and if donations are integrated into it, I might donate more. Who doesn't like ease?
If I can’t get the source and compile it myself without risking being sued by someone then it isn’t really open source anymore.
Trying to just break down the problem a bit: 1. End users don't necessarily donate. This is plausibly due to friction, that it's not worth / risky managing a bunch of small donations. 2. Corporations / Large users, are not well structured to make lots of small donations. The engineers selecting software are disconnected from finance, and pushing through payments is a barrier, with likely some exceptions that can be noted (like companies with individual $ allocations per engineer that they can direct).
Linking this to distribution / hosting services to me makes a lot of sense. I don't agree with the licensing model suggested. Something more like Youtube premium immediately jumped out at me, where I pay x dollars a month to the service, and a portion of that get's split up and allocated to the content creators. On youtube, this sounds somewhat equitable, as I understand it to be a distribution by watch time. On the package manager / software side, this seems way more difficult to allocate in an equitable way.
I like the core of the idea, that if you want to donate, you point your distribution at a service that tracks usage and divides/allocates revenue. And that service manages the allocation of donations, so reduce the friction on individuals and companies, and see the funding for opensource go up.
Don’t bother with per package deals though, at least let the package manager deal with that, I want a single predictable invoice giving full access to all packages.
I would consider paying extra to be the last to receive non-security updates though.
Just thinking out loud, I don't know how naive that is (see gpl violations) or how something like that would even be economically structured.
1. People don't like paying for things, especially when they can get that thing for free with some work on their part.
2. Metering by download is obviously problematic (notwithstanding #1) because now every time your CI job runs yarn install, it gets charged. Meanwhile someone packaging a dependency in a binary that they sell to 1000000 people gets charged once.
In my experience the only way to get people to pay for software is to arrange that they simply can't run that software without paying you. This is obviously in conflict with the concept of OSS. Perhaps you can do something if you can get governments to make it illegal to use OSS without paying, but good luck with that.
But for companies and governments it should be a subscription Eg. install AppName sub $10/year
If funding happens through package managers there will be race to add packages to make money instead of be helpful, not just to get funding for your actually used OSS project. Package managers will get full of SEO spam. Sites will be full of promotions trying to get your to download their package.
Just a guess
I don't want to have to give my details and current activities to (literally) a hundred different organizations and have my credit card out every time I run apt-get. I can't see anyone tolerating it longer than it took to switch to the fork, which would become the active version. If people are happy to pay, they're going to be happier to pay Amazon or Google than Rando Bob, even though Rando Bob wrote the thing, because Rando Bob could disappear any second.
It's alright to be proprietary if you can't make a living from OSS. You'll lose goodwill and users if you go proprietary, but you may be able to make money on who's left. In order to do that, you're going to have to start over, because all the forks start at the same place you do, and if they deliver better, you lose.
People will be as excited to install these package managers as to install DRM, i.e. not at all. The reason people install DRM is so Netflix, etc. will work. OSS with a million forks will never be as scarce as Netflix content.
Free Software seems to be a kind of acceptance of the low-reward nature of sharing what you write, but says "if I'm not going to get rich off this, no one is going to get rich off this."
So I'll repeat: I must be deeply misunderstanding the article.
You'd have to target the distribution process as well, which essentially means we're back to square one since these are vary heterogeneous and there is no single/central way of dealing with distribution other than through platform specific or domain specific distribution channels, and these are usually big boys that don't give a damn about OSS maintainers.