Common Open-Source Myths

Open-source software is everywhere, but especially so within the software industry itself. There are a lot of free libraries, frameworks, and even tools (such as IDE’s or databases) that we can use to create software without having to pay a single cent for it.

Because of this, those in contact with open-source sometimes can develop a certain bias towards believing some of the myths running around internet, such as that open source maintainers don’t do a lot other than merging code from others, or that contributing to open-source is a waste of your time.

Truth is, we owe a lot to open-source, and we should take the time to understand it properly. Let’s talk about some of the most common misconceptions around open-source and why they’re wrong.

#1 Working for open-source is like giving away your time for free

While it might be true that you’re not getting paid money for the time you put into an open-source project, another very true fact, is that you do get some benefits from the activity. Those benefits can take different forms:

• Networking. Through the process of interacting with other contributors or even project owners, you get to know other developers. Who knows what you’ll be working on next, but worst-case scenario, after a successful interaction on an open-source project, you’ll have made contacts who you can probe for or ask questions in the future.
• Improving your skills. It’s not that open-source projects need to be learning grounds, some of them might only allow for experienced developers to contribute. However, as long as they don’t mind your lack of expertise, you can take this opportunity to learn about what it means to work as part of a development team. Following standards, reading (and writing) contribution guides, understanding how to submit a proper Pull Requests. These are all skills you don’t necessarily pick up on a normal, closed source, software project.
• It can be a source of income for you. I know, it might sound counterintuitive, since the assumption here is that you’re not getting paid to write open-source. And that is true, you’re not, but you can still get paid for it. What? A very common tactic many companies use is giving the product for free as open-source, but providing paid support (such as RedHat). Or maybe they provide a free, open-source version of their product, and a cloud-based version, working as a SaaS (like OpenReplay does). There are even further alternatives like writing books and selling certifications about their products that could become their main income source.

Overall the process is very enriching and you’ll be a better developer (if not also a bit richer) for having been through it.

#2 Open source project owners only merge code

If you believe this it means you’ve never owned an open-source project. Merging code is part of the work, yes, but you can’t just merge any type of code. Think about owning an open-source project as being the sole adult in charge of a group of kids. If you make sure they’re entertained, that they go to the bathroom often and that they get fed when they need to and with the proper type of food, then you’re set. You can extrapolate that analogy to a software project, having to deal with multiple developers, their idiosyncrasies and the different ways they like to work.

Most of the owner’s time is spent:

• Reviewing pull requests, making sure they comply with the project’s standards. This is a time-consuming task because even when they might have the standards properly documented, not every contributor will read the documentation. Blessed their hearts!
• Answering issues and making sure they’re valid problems. Some of the time, they’re due to 3rd party libraries failing and causing problems with their projects. And some others they’re definitely their responsibility to fix. So it’s a matter of double-checking and making sure they have all the required information.
• Writing feature proposals and keeping track of them. Usually big open-source projects have a committee that decides the next set of features, and the best way to implement them. To get this group of people working, it’s important to properly define the features. For example, take a look at the proposal for the Temporal features from the next version of ECMAScript, there is a whole section for it, with contributors working on it, double-checking their peers and so on. The first step to a great feature is making sure everyone planned for it first.
• Review issues and tag/retag them. To properly manage issues it’s important to tag them and keep track of them within the issue-tracking tool of choice (usually Github’s issue-tracking tool). Look at the list of tags from ECMA’s Technical Committee issue tracking, they’re using over 10 different tags covering things such as wont-fix, or bug to simplify the tracking tasks.
• Coding. Right, most of the time these owners are in fact, one of the first few developers who started working on the project and they’re also putting in the hours to write code for it.

The point here is that there is a lot more to open-source project management than meets the eye. And if you, as a contributor (or not even that) assume it’s just a matter of merging PR’s, you’re underestimating the work they do. So don’t.

#3 Real companies don’t care for open-source

What is a “real” company anyway? You know what? Don’t answer that, it doesn’t matter. Truth is that many companies are built around open-source. Companies such as RedHat, Canonical (heard of them? they created Ubuntu), Cloudera and many others rely on services and related products around their open-source projects. As you can see, I’m not just referring to startups that released a public Github repo a few months ago, I’m talking about well-established, industry-leading companies.

And for all of them, a version of their product is free for everyone to use, and not only that, but their code is freely accessible (thus being open-source), however, they’re not losing business or any money because of that. Being open provides a sense of transparency that helps users trust more in those products. Especially for those that deal with private data, where being open helps show users what exactly are they doing with that information.

Don’t confuse your current enterprise company, paying millions of dollars for the products you’re using as being the only way to handle “real business”. That’s just one way, but the open-source path is also a very valid, and prolific one.

#4 It’s open-source, so I can do whatever I want with it

Yes the code is accessible, and yes, you can download it and review it. But no, you can’t do whatever you want with it, open-source doesn’t mean it’s “free”. It means you’re able to read the code and that you may use the product, but you have to pay attention to the license associated with each project before you make use of the code.

The problem is that there are so many different licenses out there with such complex legal terms, that it’s very hard to keep track of what you can or can’t do with that code. But be careful, that will not excuse you from having legal repercussions if you’re ignoring them. Some licenses will let you modify the code and use it for commercial use, others will not let you change the code without proper attribution to the parent project, and others will not even let you change it, at all. Make sure you read it the license or at least that you know which license applies.

It’s so hard to keep track of every little detail, but there is no need to worry about it, you can use the TLDRLegal website, which will give you the summary of every open-source license out there.

Keep that in mind, open-source is not the same as “free for all”, make sure you look for the LICENSE.TXT file inside the repo which is where the information about the license usually is, or carefully read the README.MD file, which could also contain that information.

Open Source Session Replay

OpenReplay is an open-source, session replay suite that lets you see what users do on your web app, helping you troubleshoot issues faster. OpenReplay is self-hosted for full control over your data.

Start enjoying your debugging experience - start using OpenReplay for free.

Open-source is filled with myths, ironically, coming from within our industry. It’s important to understand the reality behind open-source and the real work that goes into one of these projects. Be it a one-man-band or a full committee that decides on the direction of the product, the basic principles covered here apply anyway.

As developers, we tend to see the end result and assume it’s easy. Hopefully, by now, you’ve realized that easy is not exactly the word that describes these initiatives.