Try KernelCare+ for free for 30 days by signing up here: https://lp.kernelcare.com/kernelcare-plus-experiment A lot of people assume open source projects, as they are community driven, are completely malleable, and subject to the desires of their users. Other people think that open source means free, as in “no charge”, and others even mistake open source for “privacy respecting”. Become a channel member to get access to a weekly patroncast and vote on the next topics I’ll cover: https://www.youtube.com/channel/UC5UAwBUum7CPN5buc-_N1Fw/join Support the channel on Patreon: https://www.patreon.com/thelinuxexperiment Follow me on Twitter : http://twitter.com/thelinuxEXP My Gaming on Linux Channel: https://www.youtube.com/channel/UCaw_Lz7oifDb-PZCAcZ07kw Follow me on LBRY: https://lbry.tv/@TheLinuxExperiment:e Join us on Discord: https://discord.gg/nN8wwZPpwr The Linux Experiment merch: get your goodies there! https://teespring.com/en-GB/stores/the-linux-experiment Open source means free This is the one you hear the most often. A lot of people assume wrongly that software that has its source code open for everyone to see or download should not cost anything. This is obviously false, and, most licences allow for the final product of an open source project to be sold. As a matter of fact, all three of the mist popular licenses, the Apache, MIT, and GNu Public Licenses, all allow for this. An FOSS project can charge anything they want for users to download the binaries, or the source code, or both. The user is always right Another common misconception is that since FLOSS projects are based on community contributions, they should always listen to their users, and implement every feature that is asked or demanded. This is obviously completely wrong as well. Just because a project is built by many different individuals that form a comunity, doesn’t mean that the project has no direction or goals. Generally, FLOSS projects have very specific goals that they are trying to achieve, and strong visions, especially when they are forks of another project. The developers are lazy Another one that is frequently heard, generally when a project hasn’t been moving fast enough in one’s opinion, or when a specific bug “still hasn’t been fixed”. FLOSS projects, while they can ask for money, are generally free of charge, use small teams that don’t work full time. There are some exceptions for major projects, that are financed by companies, and have full time staff, but that’s not the case for everything. People expect that, when they have taken the time to submit a bug report, it should be fixed fast. The bug has been identified, so surely it shouldn’t take too long to fix, right? Wrong. There are plenty of reasons why developers might not fix a bug, or redesign their application or desktop environment in mere days or months. The developers might not have the time to dedicate to it. They might not have the hardware to reproduce the bug. They might have noticed that it only affects a small percentage of the users, and as such, isn’t an immediate priority. They might also not be able to reproduce the results, or they might just be working on a feature that will render this bug report obsolete. ## Open source projects should never include telemetry This one is also very frequent. People tend to assume that FLOSS projects should never, in any circumstance, invade a user’s privacy. While I agree with the sentiment, privacy IS, after all, a very important value to defend, a lot of people tend to go overboard there, and include telemetry in the process. Telemetry, put simply, is a class of data collection, that is generally completely anonymous when used by FLOSS projects, and that will help a team decide on what feature, or bug fix to focus. Conflating telemetry and privacy invasion is dubious at best, but let’s assume that telemetry IS bad, however the implementation. There is nothing preventing a FLOSS project from integrating telemetry in their project. Period. It’s not against the values of “Linux”, or “Open source”. It’s not. It’s there for everyone to see, in the code. If users don’t like it, they can move to something else. Open source is less secure This is also a myth that one often hears. After all, if the code is open for everyone to see, it’s easier to find vulnerabilities, right? And to exploit them? Well, yes, but that’s assuming that everyone looking for vulnerabilities has malicious intentions. The very fact that anyone could take a look at the code and find security issues within it, means that they can also be fixed a lot faster than in proprietary software. Anyone can fix it, or give feedback to the developers, so that the issue can be fixed quickly. People propagating that myth also often ignore the fact that most hackers don’t need to see the code to find vulnerabilities. The various “pawn” contests prove that proprietary software is just as easily hacked that open source software.