John Ellis is the President and Head of Product for Codethinka world-class provider of critical, high-performance software projects.
Open-source software is publicly available software developed and distributed with its source code, allowing anyone to enhance, view, modify and distribute it.
Open-source software fosters collaboration and transparency, setting it apart from proprietary alternatives, often leading to faster innovation, greater security through peer review and reduced development costs.
This is not new—and it’s more prevalent than you might realize. With roots in the 1980s free software movement, open-source software components are estimated to constitute 70% to 90% of all software today. Those outside the software engineering world may not realize how critical open source software is—or the vast proportion of large enterprises that rely on open source in some form.
There are a number of myths that prevail about open-source software. Let’s tackle five of them.
Myth 1: Proprietary code is better quality than open-source code.
We’ll start with a big one. When choosing software, you’re going to make the choice that’s best for the business. It’s easy to follow the assumption that proprietary code is the way to go. Many think that it’s better quality or will make the company more money.
But on the topic of quality, consider the inherent differences between each. Open source, by nature of being open, is open to judgment, whereas proprietary software is hidden. It’s not transparent to customers, who won’t have the visibility to evaluate if it’s bad quality or unmaintainable. Think about how many people are looking at open source versus proprietary software over time. Developers will recognize this concept as Linus’s Law: More reviewers means more opportunities to catch bugs.
When it comes to revenue, make the choice based on your business models and buyers. For example, if you’re in the pro audio industry, the software is the product. Choose the proprietary route where the software can be a differentiator. But if you’re a car manufacturer looking for infotainment software, the consumer likely isn’t making the decision on that alone. In that situation, go with open source.
Myth 2: Large open-source projects only have full-time developers working on them.
Many think that all successful projects are well-funded and supported by full-time developers. Chromium is an example of a project that one might think fits that description: As the codebase for popular browsers like Google Chrome, it’s well-funded by Google. But volunteers contribute to Chromium, too.
Contributing to OSS is about more than being hired to complete a job. So why does a developer decide to contribute in their spare time? They may contribute a single feature that they want to use. Or, it could be purely for personal development and the pride that comes with working on an impactful project.
On the flip side, look at Rust or Python: They involve a breadth of developers continuously working on them. There are a lot of companies relying on these projects without realizing the volunteer work that supports them.
Myth 3: Open-source licensing is complicated.
Licensing open-source software can appear complicated because there are lots of different licenses. But when you boil it down, there are really only two types: permissive and copyleft. A permissive license is fully open. You can use the code any way you want; some permissive licenses may require you to give credit.
A copyleft license offers the ability to change or adapt anything in the code—if you freely share what you produce under the same license. This makes it slightly more difficult to comply than with permissive code. But the easiest way to comply is to release your code under the same or a compatible license.
Ultimately, proprietary licensing is itself very complicated. When a manufacturer decides to use proprietary, commercial software in their cars, complying with the license from the software seller is complicated. Consider the number of licensing lawyers needed as a tell-tale sign here.
Myth 4: It’s dangerous for companies if their employees contribute to open-source software.
There’s a wide range of perspectives on this topic across the software development industry ranging from very open to as closed as you can get.
Some companies do not allow employees to contribute to open-source software at all. Driven by the fear that their code base will get leaked, this comes down to risk prevention. Alternatively, some companies allow contributions but require prior vetting to ensure employees aren’t contributing to a project that competes directly with their business.
Companies with an open perspective allow their employees to contribute to anything. This tends to be fueled by the belief that what you do in your spare time is yours, and during business, time is owned by the company.
Myth 5: Open source is about code.
When you hear “contribute to open source,” you may automatically think about writing code. But everyone can contribute. You don’t have to be able to code in order to make an impact.
You can contribute to non-coding elements such as reviews, design elements, translations, artwork and documentation. Meetups are a key element since the open-source communities are so distributed. Whether it’s the global Python events (PyCon), GUADEC (for GNOME) or Akademy, attending meetups is an important part of participating in the open-source community.
Ultimately this all comes down to doing what’s best for the community: the people involved in these projects. The community shapes the code, so making an impact starts with understanding and support.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
