Open mixmix opened 5 years ago
If you don't feel like this is something you can do without funding you could find a maintainer who is interested in doing this on a volunteer basis.
Many projects exist without funding- I maintain a variety of projects (including some with millions of downloads) and up until two months ago (when I joined Tidelift, who now gives me $100 a month) had not received any payment. Open source doesn't need to have a business model.
That being said, any method of funding that people should go with should be able to scale beyond a single project without causing issues.
My comment is not off-topic. It is a legitimate suggestion for solving the problem you're having.
It might be a good idea for you to appoint a neutral third-party to moderate this discussion. I am particularly unimpressed that you edited the original-post in order to make my point off-topic, especially without any sort of comment. That makes me look like I'm intentionally derailing, but when I posted that comment it was perfectly in-line with what you were looking for.
no offense meant. fair call about the edit. It occurred to me after the fact that it was obvious to me (but perhaps not to you) that we're looking for alternative experiments in the context of resourcing + funding. Doing free work is something we already do and is not novel at all <3
That last comment was off-topic, I once again asked why you don't hand the repository over to someone who's willing to do it on a volunteer basis. I'd still like to know the answer to that, but I don't think it's worth making a whole new issue over.
I think it would be better to mark it off topic then to delete it.
The goal of this experiment wasn't to see if we could find volunteers to become maintainers (the answer to that question is obvious). Rather, the goal was to see if we could start to change the dynamic between maintainers and open source consumers.
I'm happy to keep maintaining StandardJS. But I would like to see a shift in the way that we do open source and I'm willing to take a bit of heat personally in order to explore potential solutions.
I’m curious to explore the question: what if anyone could make a living working on open source without needing to be super lucky like me? How much healthier and vibrant would the ecosystem be? How many more new folks could start to participate? What if someone new to open source could adopt an abandoned package, quickly run npm install funding
, and start earning money for maintaining a package? How many more people would be able to join in the fun and opportunity of OSS?
Do you see how "handing over the package to a volunteer" would answer none of my questions?
That's a laudable goal, it would be great if anyone could make money maintaining open-source.
What I don't understand is how you thought that this would get us anywhere closer to that world. How did you imagine this working, best case scenario? Why did you think this would get us anywhere closer to that goal? Who do you imagine would be buying advertisements at enough scale to make this viable as anything other then something that makes you a quick buck?
I'm just having a hard time connecting your actions to what you say your motivations are, so maybe you can walk me through that?
@mixmix you should really take a look at this reddit thread.
How did you imagine this working, best case scenario?
This experiment is likely not going to be the ultimate solution to the open source sustainability problem. However, if everything goes perfectly, here's what I'd want. A maintainer will be able to npm install funding
into their project and start receiving money for their maintenance work. Now, formerly abandoned packages suddenly have a monetary value and, therefore, a reason to be maintained. Bug fixes, security fixes, etc. now will not be ignored. Open source packages will be healthier. Folks who want to quit their job to work full-time on open source now have a means to do so. More quality open source code is written and released. Folks who provide way more value to the world by writing open source code instead of proprietary code are now able to do open source full time. We all win.
As more folks add funding
, many copies of it may end up in a dependency tree. That's fine. Only one message is ever printed out (this package de-dupes the messages). As more maintainers join, more messages are shown, but the total sponsor income must be split among more maintainers. We'd have to see how this played out as no one knows the value of a sponsor message in the terminal (this has never been tried before). There's a chance this makes maintainers a really nice living, or it ends up just being more akin to a "basic income". I don't know how it would play it. That's why this is an experiment.
Who do you imagine would be buying advertisements at enough scale to make this viable as anything other then something that makes you a quick buck?
There are plenty of sponsors who want to get their message in front of developers. Have you ever listened to a developer podcast like The Changelog? Companies pay a pretty penny to get their message in front of devs there. There are plenty of examples of demand from the sponsor side including the companies who use CodeFund, CarbonAds, or ReadTheDocs.
I don't know if you're even a user of StandardJS or what brought you to this issue, but if you're familiar with my work at all, you'll know that I've given away nearly all the code I've written in my lifetime and never expected a payment in return. This isn't about making a quick buck. This is about challenging the assumptions of open source consumers. This is about pushing back on the entitlement to free labor that is pervasive in GitHub issues all across this site.
I'm not a user of standardJs, I arrived here after seeing this on hackernews, and wanted to push back on this lest my terminal become infected by the toxic advertising industry and the constant need to monetize every aspect of our lives.
but if you're familiar with my work at all, you'll know that I've given away nearly all the code I've written in my lifetime and never expected a payment in return.
I'm not familiar with your work, but the first uncharitable glance (and the context of a bunch of angry redditors) does not look great.
I realize that all this negativity can very easily get you down, and I'm just sharing my impression of the situation. If you want me not too, I'll gladly disengage, but I'm hopeful that by sharing my impression you can either fix some of these issues, or better present yourself so it's harder to make this kind of misunderstanding about your character.
This is about pushing back on the entitlement to free labor that is pervasive in GitHub issues all across this site.
Your choosing the name "standardJs", which seems like you're trying to trick users into thinking that your linter configuration is somehow official. Calling your linter configuration the "JavaScript Standard Style" seems at best very arrogant.
It seems like you've done a bunch of self-promotion in order to get your "standard style" as widely used as you could.
Then you decided to monetize it. To me that's not an issues of people feeling entitled to free labour, to me that seems like you tried to put yourself into a position where you're indispensable to a bunch of people's workflows, and then once you were firmly embedded you started trying to extract value from people.
The combination of questionable self-promotion in order to get this kind of workload and then complaining that nobody is paying you to do this work does not garner much sympathy. Especially when there are some great alternative that people do get paid to work on. I hear good things about airbnb's eslint config.
If you want me not too, I'll gladly disengage
Please do.
I'm not interested in re-litigating the naming of StandardJS – there are plenty of issues about this topic on the issue tracker already. Your post also makes a lot of uncharitable assumptions about my motives that feel mean-spirited in nature.
Isn't this a problem that can be solved with a software license?
Maybe there's already one, but otherwise it should be possible to create one to address such problems. I believe that some commercial game engines have (or had) similar licenses.
E.g. Distribute your code with a license that states:
P.S.: IANAL, you should probably consult one to actually implement this.
One of the problem with ads is that it leads to a race war. Everyone starts doing it and then there's 1000 ads per installs. Also people start faking downloads to get more eyeballs to earn more from ads. Then adblockers come along. Then fraud detection comes along. Then they find a way to avoid detection. Etc. It never ends. There's an entire game theory aspect to putting ads in logs.
@dave-dm this is a thread about other ideas to experiment with. If you want to explore problems with ads please start another issue / thread <3
Standard is currently eligible for an estimated $417.00/month via Tidelift for maintenance.
For more info:
I personally think finding a way to easily add funding is a good idea and a great goal to try for. That said I don't think the experiment with ads in the terminal was the right solution.
Here are my possible suggestions:
Reach out to GitHub, GitLab, BitBucket etc... The big money making companies that could fund the projects. Whichever, is willing to fund a package the repo could be moved there. This is essentially paid advertising for these website but without hurting the end user. Similarly, the same can be applied to NPM and other package installers. For example, suppose GitLab offered $4/m amount a month to maintain Y package on their website. NPM also offered $7/m to maintain the Y package by exclusively having installs done through npm. This is literally saying if keeping this package alive brings in 1 new paid user it is worth their cost. EDIT: I don't know how feasible this is if the package is OS someone can just fork it to the other site. There would need to be some cross co-operation between these companies.
Another potential way to monetize is to reach out to Github/NPM where a new button is added next to Support.
Support For Free
=> When a user likes a project enough to want to support but doesn't have the money they can click this button which launches an ad and upon completion of the video the maintainer is sent the revenue. This is controlled advertising that doesn't affect end user negatively.
It is important to remember that Ads are not bad by nature. They can help pay for free software, games, and much more. They become bad and annoying when devs use them in harmful ways. Using ads in a positive and non-harmful way is a wonderful method.
To be honest, I didn't put a lot of thought into this so these ideas might not be great but maybe it can help trigger another better idea in someone.
Cheers!
fwiw, I think the Tidelift model is far-and-away the most likely to get enterprises to contribute to open source in a meaningful way, because it fundamentally understands and works with the enterprise procurement process. At the end of the day, you need to minimize the number of Purchase Decisions (aka Process / Approvals) that Enterprises have to do - this is like, Enterprise Sales 101. OpenCollective, Patreon et al seem purpose-designed to do the opposite! Enterprises are happy to pay a lot of money, as long as they only have to get it approved once - lots of small approvals == lots of approvals == nobody will do it.
Tidelift's model is all about getting enterprises to decide to pay one person, then disburse that money to the projects they use, which is perfect for how large businesses pay for things. Which is good, because what I see from OpenCollective et al is that Enterprises aren't paying, individual developers (usually contributers!) are. That is, in my opinion, inherently Wrong - the people who are producing value should be receiving the money, not losing it!
A model I'd like to mention is an experiment in this space that I've been working on, Scarf (https://github.com/aviaviavi/scarf, https://scarf.sh).
For now it only focuses on CLI tools, system packages, etc and not so much libraries. The idea is to bake usage statistic telemetry into the package manager, and facilitate payments that can be used to lift the telemetry (or even to install, use, or whatever the developer wants to charge for).
My hope is that by making it easy to retain usage statistics and take payments, it will give developers the leverage they need to require that companies pay for their package while keeping it free for individuals
Here's a phrasing of the problem that I like: The people who use open source software are likely to know what they want to fund, but not in the position to have any money to allocate to it.
Capital
-> Company
-> Project
-> Labor
-> Open Source Tools
-> Open Source Developer
.
The problem is moving an asset from (1) to (6) when each person probably only knows about the entities directly next to them.
So today, what tools do the folks who work at companies (4) have at their disposal? Most employees of medium to large firms have discretionary funding to spend on conferences or continuing education. I would propose a campaign to contribute 5% of folk's conference budgets to open source donations that directly make their lives easier. Tools/Sites/Documents could be built to help with the donation and receipt & invoice process to make such a donation acceptable to large companies.
I don't think the problem is one to be solved technically (with new CLIs or app stores), but with better payment and dare-I-say marketing and advertising tools, like a specific Pateron.com for developers (like Github has started with the Tip option).
I think about NPR (USA's national public radio) handles their donation campaigns, or a political donation campaign - they know how to target people when it's the best time to give (end of year tax time, at the launch of new radio shows or podcast seasons, etc). Their payment processes make it really easy to take advantage of employer gift matching, tax deductions, etc. What's the equivalent of this for open source?
(I think this is what it means to transition from an "advertising" model to a "sponsorship" model perhaps)
cc @pauliver, because this whole topic is really interesting.
Related to https://github.com/feross/funding/issues/13#issuecomment-524651535 @feross, are you registered as a non-profit? If you were, I'll bet employers would be able to match individual donations sent your way...
A license that isn't open source is not really a feasible solution for open source projects.
For small, new, or abandoned packages, I think it can be solved by assigning bounty on specific issues just too keep them alive 🤔. Of course, recurrent tip and one-time donation will motivate packages maintainers.
The problem with ads is not only that they are often intrusive because they're out of context, their sine qua non is that they don't tell the whole truth.
My proposed solution is the DevWheels Licence.
For many users the real big advantage of Free Software is not that it doesn't cost them anything, it's that they're not dependent on the developers, and can arrange and share their own improvements. This means nothing closed, fully forkable. DevWheels makes this possible, while allowing the developer to require that certain classes of users pay to use their package. Revenue from forks and merges flows back upstream through derivation graphs in proportion to the value added by each package.
Yes, this is not a licence that the OSI would approve. But it delivers all the benefits that drove Richard Stallman to develop the GPL, and is in my view superior to alternatives such as ads, panhandling, only giving support to a paying few, closing parts, or licences that restrict how users use a package.
The biggest downside is that when everything's open you can't enforce payment using a key or watermark, so most users will pirate. The challenge is to minimise this by charging classes of users according to their ability to pay, emphasising the benefits of ethical behaviour by corporations and individuals, and perhaps by publicly acknowledging those who do properly pay.
JD557: DevWheels is the sort of licence you've described in your post. The key is that if you're going to allow forkability, to be fair you have to compensate not only the original developer, but all who have later added value.
anaisbetts: The problem with Tidelift is that only the paying few get good support, it only works for packages used by bigger corporations, and that the best packages that need the least support get the least funding and the most freeloaders.
tedivm: If you don't make your living through your open software, do you make a living through either closed or partially-closed products? Open software should have a business model so IOSVs (independent Open Software Vendors) can make a living through open products, rather than having to be subsidised by work on closed products.
this is an idea I had a while back, which I think would work, but I'm not personally excited enough to build it.
Users pay "support insurance" which is a small monthly amount, and covers a wide number of modules. If there is an issue with a covered module, the maintainer is paid out of the insurance, for responding to the issue within a time period, say 24 hours. Many people may be paying the insurance, but one person might find the issue. However, other users of a module are probably affected by that issue, but they shouldn't have to think about whether they support it. Given the idea is to respond quickly, maintainers should be payed generously, more than what would be their hourly rate. Also, it might be a good idea to pay the maintainers a retainer - some money even if they don't do anything, because if they only get paid when an issue happens they have an incentive to create issues. This money wouldn't oblige them to continually work on the modules, it would just be a compensation from not taking other work, and being ready to give support at short notice.
challenges: I'm sure there are a lot of legal hurdles to creating an insurance company. Also, there will be lots of challenges with dealing which issues constitute real issues. in short, this will be a lot of work. But I think it will work, especially since the customers are getting clear value.
open source isn't transactional, but money is. If you want to introduce money to something like open source you need to clearly define what it does, what the transaction is.
While this may (eventually) seen as a philantropist goal (in some lights) - assuming it is - this may cause a few of issues :
I assume this project will take a share for "the maintenance of the website/project", so what's the cut here? How will you justify the costs you're taking out of "necessity"? Do you plan to opensource the accounting of such a project - because you'll have to, if you plan to make it honest, and by doing so, you'll openly show how much advertisers pay to appear on someone's terminal and i'm not sure they're willing to show this off.
You'll print only one ad per install (which is probably already too much), but what'd be the rate of retribution to opensource maintainers? Will small projects be retributed in the same way than bigger which can need lots more attention? Or maybe you'd plan to give a different percentage related to how "deep" is the dependency, meaning that the most iconic packages would actually get less of a share than surfacing ones ; or the opposite? Nothing seems fine, right?
How is your solution gonna work with VM, CI tools and such? Are you gonna display ads in them too? Honestly, if that funding
project ever gets out, I'll investigate the earnings and compare it to the cost of a lambda function (or similar) installing my own "most minimal" package in loop ; I'm pretty sure we can make it worth. I'll make money out of advertisers, may dry out this initiative on the way, while no-one would truely benefit from the rest of the ad money. Any attempt to make regulations honestly seems vain, there are way too many configurations/env to wish to truely have a hold on this.
This just to say, aside from the whole "don't pollute my terminal" thing, it doesn't feel like a good solution because we can already see its breakpoints... It truely it doesn't feel solid, regardless of either your intentions may be well funded... or not. (get it?)
@chrishiestand suggested "Boss Bounties" : https://github.com/feross/funding/issues/26
I see that licenses have been brought up in a couple instances:
It seems most people are very much against advertiser messages in build logs. Most people also think if consumers aren't making 💰 from their derivative works, then they shouldn't have to pay for their dependencies either. So I wonder how people feel between feross/funding style ads vs. if @feross were to change the licenses of his libraries to @licensezero Prosperity. After the trail period, commercial use would be based on monthly payment to the project Open Collective?
A license that isn't open source is not a solution to open source funding. If people want to write proprietary code for profit they should just be open about that. Either way- whether they try to co-opt the term open source for their code, or are open about their intentions- groups such as Debian who only use open source code will stop using those no longer open projects.
tedivm: If by "open source" you mean "Open Source", using a licence that the OSI has approved, I don't agree that that is the be-all and end-all. A licence can make code a long way from proprietary, while still being commercial. Let's try to not be so dogmatic about what licences are pure, and more interested in what licences best serve both users and developers.
This isn't about "dogma", this is about words having meaning. If you want to redefine open source you're going to find that the community that has been built around open source is going to have a problem with that- and, frankly, it seems like a bunch of people trying to appropriate a community so they can profit off of it, while at the same time discarding the principles that made that community what it is.
If your software is only "free" for these "noncommercial, educational or commercial use for companies with less than N employees", as proposed above, then you are writing software that is closed source. It means that if I adopt your library as an open source author I have to tell all my users that they can only use it in certain circumstances- that it isn't free or open at all.
Half the reason people use open source software is to get around complicated licenses. There's a reason the MIT license has overtaken the GPL license, and a lot of that is due to how confusing the GPL can be.
Not a maintainer, but I've recently been doing a lot of research into FOSS sustainability. I've come across a bunch of experiments that have different approaches. Some have already been mentioned in this thread.
My question is as we're brainstorming new ideas, how are we using these current experiments to inform us? From a community perspective (as I'm not a maintainer) what are these experiments lacking? Is the platform approach unappealing?
Do we think sustainability comes from the top down (i.e. companies flowing their capital back through their dependency graphs) or from bottom up (i.e. designing new licenses, reimagining value distribution in communities etc...)
Would love to hear people's thoughts on this. Hopefully this isn't off-topic - I think this exercise can help stimulate more directed idea generation.
Open Collective - A platform for launching open source communities as non-profits that have transparent budgets and legitamte legal status. They created the Open Source Collective 501c6, a non-profit umbrella organization, to specifically serve the open source community.
Tidelift - A managed open source subscription backed by creators and maintainers. Basically companies pay a subscription and Tidelift passes on $$ to maintainers of those projects. It seems that they offer support by scanning for security, licensing, and maintenance issues and working directly with maintainers to resolve them.
GitHub Sponsors - I mean, obviously makes a ton of sense. Zero fees, matched contributions (for now). Need to be a sponsored developer and limited to certain funding links that Sponsors is integrated with.
Patreon - "membership-business" almost like a continuous Indiegogo for projects (my own words)
Gitcoin - Crowdfunding and bounties for open source projects. Gitcoin grants has facilitated the distribution of $402k to Open Source since it's launch in Jan 2019.
More experimental experiments:
DAOs i.e. MolochDAO - grant-making decentralized autonomous organization where members govern and manage a multi-sig with crowdfunded capital to distribute to grants aligned with the DAOs mission (funding Ethereum development)
Sourcegrain (experimental project from Protocol Labs) - SourceGrain will make open-source software projects financially sustainable by letting them issue their own project-specific cryptoassets, called grain.
Oscoin - p2p network for sustainable funding through block rewards
@asbjornh Issuehunt takes a ~17% commission. Whereas Boss takes a ~5% commission. Though the higher fee might be worth it for some? Disclosure: I made boss so I'm biased.
@chrishiestand I use neither so I wouldn’t know 😃
Let’s add a properly visible link for it:
Here are some other collections of funding ideas from past discussions in this area.
@feross NPM officially banned this. I think you should mark this repo as achieved and the package deprecated before someone thinks I'd be a good idea to use it.
tedivm:
I understand why you and others want to retain the dominance of permissive licences (with or without Copyleft). They're easy and cheap, and are the best solution for some large projects used by many. But by preventing open software developers from charging directly for their work, you're limiting its development to either those who are independently wealthy or can arrange another source of income.
Many of these sources of income are from a job making closed products, or the software is free but is a resume item for a job making closed products. Proprietary shouldn't always have to come to open software's rescue.
Getting big corporates to pay for assurance and subsidise other users only works for some type of projects, and gives this 1% preferential treatment.
Issue bounties are an unreliable source of income, especially for mature projects.
"Open Core", where most of the software is permissively-licensed, but part of the software is closed, is in my view worse than requiring users to pay for software that is 100% open.
Relying on donations advantages freeloaders, and constant rattling of the tin can be annoying.
No, I think there are many projects where the best solution for both users and developers is to keep it 100% forkable, but have a charge to use it, a charge that can vary according to the type of user and their use. I don't think your characterisation of such a licence as "closed source" is reasonable.
Without such an outlet, more software will continue to be forced to be proprietary, which is a whole lot more restrictive for users than the concerns you expressed.
I can’t speak for others, but honestly, I would happily donate my computing power for crypto mining. It isn’t that intrusive, and gets you the money you want. I’d want to know that a package was doing it, though. See #28.
This first incarnation was an experiment. The plan is to iterate, and try different things in practice to see what works and doesn't.
What should we try next? A slight tweak of this model, a change to something quite different?
You can contribute to this thread by offering things like : :heavy_check_mark: actionable ideas to try (most useful if it includes detail about who would implement it, and how) :heavy_check_mark: links to other experiments (prior or ongoing) :heavy_check_mark: offers of support around experiments
funding
and using it in a project you maintainThis is not a thread about : :x: volunteering as a solution
See also
Discusssion
threads - topics like Probems with FOSS, Dreaming about the future of FOSS, how to evaluate experiments