Because of anti-customer features. Hard to implement those in a FOSS project, without a fork undermining you.
this post was submitted on 27 Jun 2023
21 points (100.0% liked)
Free and Open Source Software
17966 readers
5 users here now
If it's free and open source and it's also software, it can be discussed here. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
Not only anti-customer features. Any kind of product monetarisation becomes much harder in a FOSS project.
Say, you built this cool piece of software/hardware/product.
You can either keep it closed source and sell it. Anyone who wants to clone it, needs to put in a similar amount of R&D to what you did. If you have patents, you can even stop them from copying your stuff all together.
Or you can open source it. That means, you need to spend more money to get your product open source ready. The design files need to be good enough that someone other than you can use them. You need a good documentation, so that others can actually replicate your work. All that is not cheap. And then someone else will come along and copy your stuff. Since they have no R&D attached to it, they can easily sell the product cheaper than you did (or even give it away for free, see e.g. CentOS).
If they are super anal about that, they even add your Github page as the place to put feature requests/bug reports. Happened e.g. to a game console cartreader project where I contributed.
Do the math: Which option gives you better return on investment?
Tbh pirating closed source software is as easy, as installing forked code. Maybe you could add a non-competition clause to a new open source license, so that the original FOSS software company has the legal high ground over anyone that undersells them.
Well you could, but then it wouldn't be open source anymore. You could still call it 'public source' though. The threat of competing forks is one important mechanism keeping FOSS projects on the straight and narrow, imo.
It is easier to exploit users when it is closed soutce that's why
It's not always easy to combine the different requirements for those companies.
Some companies have trackers/advertising in their software. In that case, puting them open source would mean that everyone would see the code and be unhappy about the adverts.
Another issue is pirating. Open sourcing the code could maybe allow easier pirating, either by removing the trackers/adverts or by just not buying the software.
Managers can also not know, or not care about open source.
Another issue is that open sourcing it in a way where someone can modify it, may create issues with some people trying to redistribute the software, even if the licence doesn't allow that, which would create more legal work for those companies.
Understandable
Businesses have a core mission. If you open a piece of software then you would need to have someone to support it internal to the company, it increases company liability, it increases distraction, and to justify all of those downsides it would have to have a clear upside.
The other problem is that companies are short term. Even if you could demonstrate all of the above, this could not be sustained for very long. Priorities would change and personnel would be reassigned or move on. Keep in mind head count costs are very high for companies. Moreover often head count is harder to get and maintain then the $ it represents to the company. By this I mean you might think head count is just $ on a project, but generally in terms of getting resources head count and $ are totally separate things.
I was going to respond, but you said it so much better than I could have.
The tension between liability and control is real.
Yes there is the control end too. To develop software internally in a company you have to show there it gives you a proprietary advantage that other companies do not have and cannot buy. So that leads one down the confidentiality path. Every stupid thing then gets justified based on confidential and proprietary even if it is a stupid argument (not saying it is always a stupid argument). Imagine then saying let's open the software. Might even be the correct thing to do but then you'd have to admit your proprietary arguments were BS.
Then even if you did that, you would have to do a deep code audit to remove anything that could potentially be an issue. Then you'd have to run that all through legal and up the flag pole to executive level. Then they would ask, why are we doing this. You had better have a good answer.
To add to another comment, my company is not really afraid of it, but the amount of overhead needed to contribute to OSS projects is very high here. Basically, we have to ensure that we are releasing clean, well documented code, with proper contribution guides, that a person here can “own” with updates. Any code beyond bug fixes we push would have to be approved beyond our normal code review process. We don’t want to have our Junior Intern Dev start pushing code publicly that makes our code look bad…. Or our senior devs hah.
Finally, GPL makes things tricky for us, as we take the license seriously. We tend to release code in a more permissive license for that reason, and actively try to use MIT/BSD for that purpose. So we have to be careful, and it is much much easier to just not release code into the wild.
Oh and for new projects, we have to justify why we should make them publicly OSS - will it actually benefit the community in some way?
I don’t get why big companys are afraid of open source software.
Some definitely have a legitimate fear - incorrectly linking their closed source app with a GPL 3 project can put them in a place where they need to disclose their source to an end user. Some people refer to GPL as "poisonous" for this reason.
The RHEL issue one is definitely an interesting beast, though. It will either improve their sales or piss off enough people in the community into not maintaining RHEL support and telling their large customers that RH/IBM are no longer trustworthy. This could be Oracle's time to actually give something back to the community and shepherd a new 'open' enterprise standard distribution, but given their track history....
Redhat grew at a nice, sustainable pace through open source software for many years. A few years ago they were purchased by IBM who now wants to see fast, less sustainable growth so they can make some money from their investment. The fastest way to do that is to force some of their open source users into paying.
Good luck capitalizing a non permissive licensed software.
Its actually simple they can't do it. They are only interested in the €€€
Didn't we move past "everything should be OSS!" Like 15 years ago?
I'll just leave here the response from obsidian. If you can extract truthful reason from this corp double speak, please share
Anybody who is afraid of showing proof (which making the code open source does) should be given a wide berth
They were depending on you not knowing, and that is never good for you
They were depending on you not knowing, and that is never good for you
It's most often done for the sole purpose of retaining the ability to more easily profit off of your work. When you open source your software you are basically taking the most straight forward profit model off the table. Some projects do of course manage to still make it work, but only when the user base is composed of tech-savvy enthusiasts. If you're open sourcing a desktop application targeted at the average user, like a game. It's never going to work unless you hold something back (e.g. art assets).
We need to stop with this false narrative that developers choose to keep their software closed sourced for malicious reasons. The truth is that profiting off of FOSS software is inherently difficult.
This would be a valid generalized assessment if proof or not was the only concern when open sourcing. But it's not.
view more: next ›