(I am a maintainer of Homebrew.)
Oof, 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.
- https://www.youtube.com/watch?v=XUqLn21AgPI
- https://podcast.thekoinpress.com/episodes/max-howell-support...
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.
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
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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
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.
But for companies and governments it should be a subscription Eg. install AppName sub $10/year
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.
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.
