I’m fully in agreement with the goal here, that for-profit companies should pay for changes they request. And some companies do pay OSS projects for support. SQLite is one high profile example (https://www.sqlite.org/consortium.html), and there are others with varying degrees of success.
The problem I see here is that there is no clear or easy path to making this goal a reality everywhere. What really happens most of the time is engineers at various companies are downloading and integrating open source code because it’s free to use as-is. These engineers aren’t managers and do not typically have the ability to spend company money on software without approvals from management, and while they should ask, the reality is that they don’t ask.
If I’m an engineer inside a for-profit company, with no explicit software budget, what steps should I take to prepare the company for offering bounties? Should something be happening before we download and integrate a new OSS project that sets a management/company expectation of paying for future changes, and what should that look like?
"there is no clear or easy path to making this goal a reality everywhere"
There is also no clear and easy universal path for proprietary software companies to be successful. Running a business is hard. I fully support efforts to make it easier to find financial success, especially with open source. Our expectations need to be reasonable, though. It seems that too many folks think that having a bunch of stars on Github should directly translate into rolling in the cash. But creating a product is only one part of building a successful business.
Again, better tools, better education, and more support are always great!
Honestly I think many companies would be willing to pay for open source if internally engineers could say, "look, we depend on this project for our success and we have a vested interest in seeing it maintained well and getting our features/bug-fixes actioned, and it's a lot cheaper for us to spend $1k/year (or whatever) than for us to pay our own developers to work on it (and not our own features)". I think a lot of business people would respond well to that, and if enough companies do that it could drive a lot of additional innovation and development in open source.
Totally, I think you’re right, a lot of companies are open to paying for it if it’s saving money and providing value. I mean, all companies already do have a software expenditure budget for commercial software.
But I guess it is not simple to just put OSS projects in the same budget bucket as proprietary software. Companies have a special aversion to unexpected expenses. I’ve done business with companies that would rather pay a known monthly fee for all their licenses than only pay for the licenses that get used every month, simply because they can’t account for what it will cost in advance. Practically speaking, always paying bounties for changes would turn OSS into pure commercial software from the buyer’s point of view.
There are a ton of OSS projects that are supported by the author’s day job at a for-profit company. I guess I’m not convinced that if software is offered for free in the first place that it always makes sense to expect money to be offered without asking for it. If an OSS project needs funding, maybe it’s best to just offer it commercially in the first place?
I just don’t necessarily agree with the hyperbole that unpaid labor is “wrong”, because that undermines the initial OSS transaction. The software was offered for free-as-in-beer in the first place, and that is unpaid labor. It’s perfectly fine to request pay for changes, so isn’t that better and more straightfoward than not asking for money but complaining when none comes?
> I guess I’m not convinced that if software is offered for free in the first place that it always makes sense to expect money to be offered without asking for it.
I'm explicitly not talking about the "software ... offered for free in the first place". I'm talking about changes to that software at someone else's request.
> I just don’t necessarily agree with the hyperbole that unpaid labor is “wrong”, because that undermines the initial OSS transaction.
I don't think this is true because of the genesis of the open source software itself. I created it for my needs. I would do it even if I didn't plan to give you a copy, but the transaction between us is near zero cost so I go ahead and let you use it too because I'm a cool guy.
> The software was offered for free-as-in-beer in the first place, and that is unpaid labor.
I'm making a claim that doing something to scratch your own itch doesn't qualify as 'unpaid labor' in any useful sense. It would be like saying doing a hobby is unpaid labor.
> It’s perfectly fine to request pay for changes, so isn’t that better and more straightfoward than not asking for money but complaining when none comes?
The current norm is to not request pay or to expect to pay. My argument is that norm should be inverted and maintainers should expect payment to be offered, and requestor should expect to offer to pay. If a specific dev doesn't want to be paid, then fine. It's really about the norm changing, not mandating individual behavior.
If your software is valuable to me, and I use it without paying for it, then it is unpaid labor. It is irrelevant why you made the software, and irrelevant what the transaction cost is.
> My argument is that norm should be inverted
That norm is being set by the authors, and can be inverted by the authors, right? If devs want to be paid, they can and do ask to be paid, right?
> If an OSS project needs funding, maybe it’s best to just offer it commercially in the first place?
There’s quite a lot of overhead involved in running a business relative to an open source project, and this is probably not the kind of work that an open source developer would find fulfilling. Additionally, even if the developer is also able and willing to quit his job to bootstrap his business, that overhead adds to the cost of the software. On the other hand, it would be easy enough IMO to get companies to set aside $20K/year (give or take based on the size of the business) and task a few principal engineers with divvying it out among their open source projects. That would be a pittance for companies but it would be a big infusion for open source.
Totally agree on the goal, it would be great if companies established slush funds for their OSS support. That said, it’s not anyone’s responsibility to provide an OSS dev with fulfilling work but themselves. If they don’t want to ask for money, chances are they won’t get any. And it’s not really relevant what money is or is not a pittance for a company, they don’t generally decide their expenditures based on having spare cash, they buy what they need and try to keep what they need to a minimum. As an engineer, if I ask for a $20K budget for OSS support, chances are I will be flatly denied. The good news is many companies already do support the OSS they depend on in multiple ways. The largest tech companies are spending a great deal more than $20k on various kinds of OSS support, FAANG companies spend millions on it.
The terms of the economic exchange of any software is the author’s to set. It they want money for their work, in the majority of cases they will need to ask for it, it’s not going to be handed to them, especially when the software is given away for free in the first place. By giving the software away, the author is setting the terms of the economic exchange. Expecting the terms to change later without asking is just as bad as anyone expecting free support.
I think if we want to meaningfully support open source, we should figure out how to pay for the software in the first place to use it, not expect companies to throw a dollar in after the fact or only if they ask for changes. Making change requests does not align with the value of open source for most companies. The primary value is in it’s existence.
We as engineers are making choices that will certain incur maintenance costs choosing any third party solution. And the taller the dependency tree the more fragile everything becomes.
I dropped Drupal years ago because upgrading was such a nightmare. More component-ized solutions can still have the same problem.
Ultimately businesses are making the choices and tradeoffs whether they realize it right away or not. It'd be great if there were a lower friction way to consume and contribute without burying the real costs.
I'm in the same position. We have a huge budget, but literally no way to transfer money to individuals or even aggregators like GitHub. Corporate credit card use for software is forbidden. Everythi g has to go through an 18 month purchase process.
Sonic think a prerequisite for success would be to have a single organization that does the payment processing get set up as a vendor with lord knows how many large companies. That's probably why it's never been done at any kind of scale
Having a payment processing vendor that handles OSS projects is an interesting concept. That sounds like a large hill to climb before we can get OSS project changes funded, but regardless it seems like a viable idea. As an engineer, what would you do internally to nudge things in that direction? What would you say to your manager to plant the seed and encourage it to grow upwards?
The one thing I would never do is advocate internally for 'supporting' or 'sponsoring' OSS. Managers will just hear 'we should pay for something we already get free'.
The best way to sell the idea is to make it transactional. 'We need feature X. It'll cost us N to pay the core devs for it, or we can do it in house for N^2.'
Then put together a spreadsheet of those examples and send them up the food chain come budget time.
Also why it makes sense for maintainers that have the capacity to offer some token "premium support" or something along those lines. "Just give this person money because we like them" is not in the vocabulary for people approving/checking expenses, "Give this person money in exchange for a service we say we want" is totally normal. Even if the "premium" is just something relatively minor like a guaranteed response (not solution) within X working days or private submission of bug reports (and thus not having to worry about redacting logs etc posted in public).
I think recurring support contracts or subscriptions are actually very problematic in the case because the gains will naturally go the projects highest up the dependency tree because they are the most visible.
However, if we payed for change requests in individual projects there would be the possibility for
1. money to trickle down from well sponsored projects to their dependencies when those higher level projects need changes
2. teams to spread money around by directly requesting changes to more obscure projects they depend on.
The problem I see here is that there is no clear or easy path to making this goal a reality everywhere. What really happens most of the time is engineers at various companies are downloading and integrating open source code because it’s free to use as-is. These engineers aren’t managers and do not typically have the ability to spend company money on software without approvals from management, and while they should ask, the reality is that they don’t ask.
If I’m an engineer inside a for-profit company, with no explicit software budget, what steps should I take to prepare the company for offering bounties? Should something be happening before we download and integrate a new OSS project that sets a management/company expectation of paying for future changes, and what should that look like?