I would think the obvious way a corporation could contribute would be financially.

But it's voluntary. When a company (or most individuals) get the product for free, there is little incentive to pay anything.

I think the notion that people (and companies) pay for proprietary software because there is support or some other reasons are complete BS. They pay for software because they have to in order to use it. It's just a cost of doing business.

As free software has become viable (high quality) in some areas, business folks are more willing to allow it. The primary concern is "can it do the job". The second is how much will it cost me?

We were discussing “hire a developer to contribute” vs “financial contribution”. Of course it’s voluntary and the incentive is low, but that’s off topic.

That's what they do to contribute financially to software development. It's called buying a license.

Sure, sometimes they buy closed sourcr licenses, but as a corporation providing services to a third party you don't care about the license - you care very much the software adds the value to the output of the employee who uses it.

The GP was talking about hiring a developer to contribute. I pointed out that financial support is an option. Yes, licensing is one model, but a check is also valid.

I think what you're referring to is paying for -support- There is no blender version of "Red Hat" that companies can rely on to deliver fixes or support.

> ...than hire a developer who may or may never deliver.

I don't really see the difference between this and "accept its drawbacks", except that if your developer turns out to be productive, you have something a lot more valuable on your hands, and if the developer fails, you can replace them (whereas for a given proprietary product, you typically can not replace the vendor while keeping the licensing agreement and investment in training [this last bit being a big part of why in-house developers make sense for Blender, as they always have for 3D animation studios]).

>I don't really see the difference between this and "accept its drawbacks"

The difference is one is known, and the other is unknown. When you're evaluating existing software you can evaluate multiple competitors based on their finished product. You can't do that when you're hiring a developer.

>and if the developer fails, you can replace them (whereas for a given proprietary product, you typically can not replace the vendor while keeping the licensing agreement and investment in training [this last bit being a big part of why in-house developers make sense for Blender, as they always have for 3D animation studios]).

I'd say this argument supports using only existing established successful products, to avoid being burnt.

> one is known

Only if the software you're buying meets all of your current and future requirements, and is maintained indefinitely. If new requirements come up, they're at least not any more helpful than in-house resources (unless a lot of people suddenly have the same requirements at the same time); and if they stop maintaining it, there's a good chance you literally can't do anything about that.

You just have a different set of unknowns, one of which seems more manageable (which is probably why it is more popular), and probably is more manageable in some subset of use cases.

>Only if the software you're buying meets all of your current and future requirements, and is maintained indefinitely.

Nobody expects 3d design software to be maintained indefinitely or expects 3d design software to satisfy future requirements magically. You buy a 3d design software to make you money by creating content. Either it makes you money or it doesn't. The easiest thing to do is to simply buy what everyone else is using because it makes it easier to hire talent from a pre-existing pool of experts, or if need be, train them on a software for which training programs already exist because its popular.

>If new requirements come up, they're at least not any more helpful than in-house resources (unless a lot of people suddenly have the same requirements at the same time);

Well, wait a minute. Before you even get there, you not only have to be good at producing 3D art/content (or atleast good enough to make a decent chunk of change), you have to now hire dev/test/pm folks and successfully run a software development team in-house. I don't find this to be a realistic proposition.

>and if they stop maintaining it, there's a good chance you literally can't do anything about that.

A vendor for any software that you rely on can go out of business. Do you plan to run independent software development teams for your OS, accounting software, browser, IDE, etc ? The answer obviously is no. And the same reasoning applies to your 3d design software.

>You just have a different set of unknowns, one of which seems more manageable (which is probably why it is more popular), and probably is more manageable in some subset of use cases.

I don't agree at all. I think it actually is more manageable.

> you have to now hire ...test/pm folks

Do you? Depends on what you need done.

> I don't agree at all. I think it actually is more manageable.

Well, at that point it is a matter of opinion.