That part is the deal-breaker for many people who actually use these tools for work. It's difficult to daily drive an objectively worse software, when your pay depends on producing value with it.
Moreover, lots of OSS contributors are from China, Russia, India, Ukraine, etc - so a company may spend even less paying them for particular commits than buying software from bay area company.
It's more about management mindset rather than insolvable problem.
upd: And everybody wins - more quality OSS code, help developers in poor countries, less money to shitty companies like Adobe.
company or individual, that's true. but there's still big opportunity costs and time factors. Pay someone $1000 now to perhaps get some polish/bugfixes in a release 2 months from now... and do what in the meantime? Deal with 15% more time spent in sub-par-for-my-needs software?
You can, but it's not a slam dunk decision, and just because you paid that money, you may still not get things as you want (or when you want).
It’s a marshmallow test for adults.
Many might prefer to have shipped features/products in a timely manner instead and how their performance reviews would look, as opposed to some notion of community.
The situations where you can say: "I'm blocked and am waiting on the library/tool developer to have a look at my GitHub issue, so no new release will be shipped until then," are probably not plentiful. Situations where the person in question can contribute a solution of their own are also not as plentiful as we might like. Situations where the person in question is capable of either solving the problem just for themselves (with a custom build of the tool/library) are also not as plentiful as one might hope, due to possibly different skillsets.
Making the functionality someone else's problem behind a contract of some sort feels like a decent choice in an enterprise setting, which is why you see many purchase something like RHEL licenses because of the support, or why many prefer to overpay for cloud services instead of running everything on prem, or even use paid tools that are "standard" within the niche of the industry that they work in.
For many, the circumstances in which they'll adopt FOSS primarily centers around someone else already having done the majority of the work and the solution being good enough: something like MySQL/MariaDB/PostgreSQL in the database space and something like Angular/Vue/React in the front end space, or any number of libraries/frameworks for back end development, tools like Visual Studio Code or Git, OSes like GNU/Linux or other Linux distros and so on.
One might also argue that a lot of the successful FOSS projects out there actually have corporate backing, but perhaps that's besides the point.
But this point from the comment shouldn't be overlooked:
> You can, but it's not a slam dunk decision, and just because you paid that money, you may still not get things as you want (or when you want).
That's not even going into the dev market situation right now ...
I mean seriously have you people ever been near a situation where these kind of decisions are made ?
Compared to the competitive advantage of having a software developer on staff?
10 companies each contracting 1 dev for an open-source project is a less-efficient allocation of resources than 1 company hiring 10 devs for their commercial software project.
Efficient allocation of scarce resources is best achieved with comparative advantages. A commercial software team has shared context, management, and knowledge that cannot be as efficiently achieved by a decentralized community of contributors. So the commercial team can produce the same software at a cheaper cost. This is a good thing for the economy.
Figma already did the hard work of prod/tech design and fixing browsers, meaning followers will have a much easier path. https://madebyevan.com/figma/building-a-professional-design-...
The same short-term thinking has been espoused at the dawn of every innovation. Thankfully some folks don’t listen.
It can’t get done because every company wants to let some other sucker pay for the feature, and then free-ride after it’s implemented. No individual company would pay the $10k, because the feature is only worth $1k to them, even though it’s worth $20k to society.
Kaleidos, the creators of Penpot, built a tool that they need and invested to make it open. And they get recognition for it which builds their brand and gets them more customers and employees.
Paying for feature X and having that advertised in the ChangeLog and on the sponsors page is a sound business decision.
Soon enough, businesses pay fees to Adobe only to have their data taken hostage in the cloud will be known as suckers.
There are small-margin markets where this doesn't happen, bit then those markets don't have huge companies either.
- Take X% of what they pay to Figma/Adobe and donate to FOSS alternatives.
- Every year, go through an exercise to look for missing features on the open source tool that still keeps you dependent on the proprietary one. Take the results from the feedback and give to the developers.
- (If you are a big company) use the results of this exercise to try to negotiate down on the price of the proprietary system you depend on. If you manage to get a discount, take it and double down on the support of the free alternative.
- Repeat until either you no longer need the proprietary solution or the open source alternative surpasses the closed one in capabilities and market share.
Often it's not just "rough around the edges", but fully missing features that are necessary (or STRONGLY desired) for a regular professional's workflow
It’s kinda interesting, most development is by grants and such, they don’t offer much in the way of support funding. A lot of development is fooling around taking output from a and making it work for b.
As far as a business is concerned, Figma is still available. There is no business continuity risk.
I personally, would say open source provides a much larger business continuity risk. There are many open source projects that are basically dead. They're widely used and quite crucial but development and support has basically stopped the maintainer has moved on with their lifes and have other things they want to do.
A good example would be the Gorilla libraries in Go, it is still being maintained but the fact the maintainer has been looking for such a long time for someone else to take over because they don't have the time really means the library is just kinda existing.
There is a popular User library for the Symfony framework in PHP, it literally says in the docs that people are expected to move off of it because they won't maintain it and lists a bunch of reasons why. How many teams using that library would even know that?
One of the biggest complaints I've seen open soure maintainers complain about is people asking if their project is dead or not. As far as the maintainer is concerned it's maintained, when they have time. But it looks to the world that it is dead.
Just because you can get the source code and use it at any time because the license allows it doesn't mean you're able to depend on it. In fact, since you're often paying no one for it and most often not even said thanks to anyone (myself included). You're entitled to nothing, no support, no note that they won't be maintaining it, etc.
It annoys me when people think that FOSS means it's something you can depend on, when it literally comes with a license that makes sure you understand there is no warranty. That's how much you can depend on it. The person giving it to you says use at your own risk.
I feel the opposite, open source gives people and companies options and the ability to soldier on if someone loses interest in a technology. This site is littered with notices from companies that they intend to discontinue some paid product or service suddenly with very little notice. If a group of people or companies really care about an open source technology, it's easy enough for them to ensure the continued maintenance of something they're getting for free. Also, if you care deeply about a technology, chances are others do as well and those projects will continue well past what a commercial vendor would maintain.
So, you've never had a commercial proprietary library your core product depends upon, being obsoleted and ceased support, without a license nor access to the code to keep maintaining it in-house? Because it happens, and I have.
And it's not just because the library was commercially inefficient, but because it got bought by a competing large corporation, who wanted to replace it in the market with their own solution, and wouldn't bother to support the library for its old users.
When this happens, at least the open source license allows you to keep supporting your use case by yourself, instead of being forced into the new solution being pushed by the vendor.
No, the new library promoted by the vendor was utterly incompatible with our system, being based on totally different assumptions. So the library got replaced by an open-source library that did the same as the original and had a permissive license, which allowed my company to build a wrapper around it at an affordable cost.