Fund OSS through package managers

I was going to use stronger language, but let&#x27;s just say &quot;this is magical thinking&quot;.<p>1. People don&#x27;t like paying for things, especially when they can get that thing for free with some work on their part.<p>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.<p>In my experience the only way to get people to pay for software is to arrange that they simply can&#x27;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 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.

&gt; You&#x27;ve exceeded Y free installs for package X. Choose one of the following license options to continue: &gt; &gt; 1. $49 for a lifetime license &gt; 2. Don&#x27;t install package<p>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?<p>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 &quot;FOSS community spirit&quot;, imagine having a useful PR refused solely because the repo owner doesn&#x27;t want to share the income with others. I usually don&#x27;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.

Maybe I don&#x27;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.<p>I don&#x27;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&#x27;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&#x27;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.<p>It&#x27;s alright to be proprietary if you can&#x27;t make a living from OSS. You&#x27;ll lose goodwill and users if you go proprietary, but you may be able to make money on who&#x27;s left. In order to do that, you&#x27;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.<p>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.<p>Free Software seems to be a kind of acceptance of the low-reward nature of sharing what you write, but says &quot;if I&#x27;m not going to get rich off this, no one is going to get rich off this.&quot;<p>So I&#x27;ll repeat: I must be deeply misunderstanding the article.

One issue I have: are installed packages really the only criterium?<p>I was dreaming about a system where the OS and runtimes automatically track what is used and how often &#x2F; for how much CPU cycles maybe?<p>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&#x2F;or gui stack etc.<p>But of course that’d still leave lots of open questions:<p>a) people could try to habe the system by using up more resources than needed for example.<p>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.<p>So I think this one is a tough one to do correctly, but Id like to see something in this direction getting traction.<p>I think the major issue is gonna be to get real inertia going &amp; get people to allocate appropriate funds.<p>This reminds me of the brave browser and distributing funds along the news sources you actually consume.<p>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 &amp; triggering the masses.<p>But it seems to be a real hard problem to solve in a good way.

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.<p>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.<p>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&#x27;d be open to donating once or twice on my own terms when I like it but these donation platforms force you.<p>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&#x27;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.<p>Trying to just break down the problem a bit: 1. End users don&#x27;t necessarily donate. This is plausibly due to friction, that it&#x27;s not worth &#x2F; risky managing a bunch of small donations. 2. Corporations &#x2F; 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).<p>Linking this to distribution &#x2F; hosting services to me makes a lot of sense. I don&#x27;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&#x27;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 &#x2F; software side, this seems way more difficult to allocate in an equitable way.<p>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&#x2F;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.

Will the package managers take 30% of all donations?

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&#x27;s a fraud and chargeback magnet.<p>I&#x27;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&#x27;t want this kind of hassle. They have more than enough on their plate.

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?<p>Just thinking out loud, I don&#x27;t know how naive that is (see gpl violations) or how something like that would even be economically structured.

The biggest hole I see there is that not all OSS is used as a dependency. If you&#x27;re talking about fully built, standalone software, then package managers alone can&#x27;t capture that.<p>You&#x27;d have to target the distribution process as well, which essentially means we&#x27;re back to square one since these are vary heterogeneous and there is no single&#x2F;central way of dealing with distribution other than through platform specific or domain specific distribution channels, and these are usually big boys that don&#x27;t give a damn about OSS maintainers.

&gt; or risk getting sued by the original package author or a big platform like npm itself.<p>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.

I believe that’s what the author of Homebrew is trying to do with tea: <a href="https:&#x2F;&#x2F;tea.xyz&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tea.xyz&#x2F;</a>

It would be great if I could pay package managers to take care of the security side of things.<p>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.<p>I would consider paying extra to be the last to receive non-security updates though.

Warning: Reacting to the title<p>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.<p>Just a guess

so... the tasks that burn out maintainers are the really boring tasks of maintaining the project, triaging bugs and doing releases.<p>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.<p>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.

Donations for individuals Eg. install AppName donate $10.00<p>But for companies and governments it should be a subscription Eg. install AppName sub $10&#x2F;year

What if we instead funded open source software by reducing incentives for speculators to drive up housing prices?

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.<p>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.<p>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?<p>If major dependencies are paywalled, how does that affect other packages&#x2F;projects that took on the dependency? This might get messy quick and change developer behavior to write their own libs &#x2F; reinvent the wheel.<p>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&#x2F;free and supplementing around it rather than locking access down.<p>Other platforms like TikTok, YouTube, and others have concepts of creator funds or viewership funds. Perhaps that model may apply better to package managers.<p>Another idea is taking those models to the private consumer and providing access to subscriber only content&#x2F;support that is in addition to what is published on the platform itself.<p>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.

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&#x2F;per CPU per month, $50&#x2F;year, $150&#x2F;lifetime). Combine with maybe a 50&#x2F;50 distribution of income earned to FOSS devs.<p>That income earned might get non-commercial users to transition and drive mindshare benefits which would force some commercial users to switch.<p>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 <i>good thing</i>.<p>The packaging that the major distros do is fundamentally a service, and I&#x27;m shocked this hasn&#x27;t been tried before. Maybe people will rally around the idea -- the major distros should be compensated, if they compensate developers as well.

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.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;openfare&#x2F;openfare" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;openfare&#x2F;openfare</a>