“Open source is wonderful - if you know what you’re doing.” - Richard Seidl
Today I’m going to be a spoilsport. Or a hall monitor. Your pick. I’d like to share a few thoughts with you about open source. For many people, it’s simply “free software”. Unfortunately, it’s not that simple.
Licenses
Even though open source software is freely accessible, that by no means implies you’re allowed to do whatever you want with it. And the jungle of possible licenses is vast. BSD, GNU, GPL, MIT and so on allow or prohibit commercial use, modification, attribution, and everything else you can define there. As a starting point, this is a good place to begin: Comparison of free and open-source software licenses
And seriously: pay attention to this. Ignoring licenses can get very, very expensive.
Maintenance and support
Open source projects are community projects. You have to work for your support yourself. Through forums, repositories, and the community itself. You can of course check all that in advance. But it can also be over very quickly when the project and its contributors go inactive or shift their attention to other projects. Sure, that can happen with commercial software too, for example when the company gets bought, but at least there you have contracts that give you a frame.
Quality
“Surely they’ve tested this”… yes, maybe. Maybe not. In my experience, open source projects are usually quite well equipped when it comes to tests close to development. But I also keep seeing projects that have few business-level, cross-cutting tests, and there are sometimes gaps in interface testing too. So if you use open source: don’t forget to test 🙂
Give and take
It’s tempting: on GitHub and elsewhere you’ll find open source projects on countless topics, like an all-you-can-eat buffet. But it’s not meant to be a one-way street. Open source lives on participation and community. So please always ask yourself: what can you give back? Maybe there are projects of your own you could make available? And if you’re not a programmer? Well, help the teams with feedback, feature ideas and above all: bug reports. We’re testers, aren’t we? This is where we can do the open source community a real service: with meaningful, reproducible defect reports. The community will thank you.
Frequently Asked Questions
Does freely accessible source code mean that you can use and modify the software however you like?
No. Freely accessible does not mean legally free. Licenses such as BSD, GNU, GPL, or MIT have different rules regarding whether commercial use is permitted, whether modifications are allowed, and whether the author must be credited. Anyone who ignores these conditions risks very costly consequences. Before using the software, it’s essential to review the specific license.
Why is open source more than just free software?
The lack of a purchase price is only part of the equation. Added to this are license terms that may restrict use and distribution, support that you have to seek out yourself in forums and repositories, and test coverage that you cannot take for granted. Those who factor this in make good use of open source. Those who only focus on the word “free” will eventually be in for a surprise.
How do you get support if an open-source component causes problems?
Through the community: forums, repositories, and the contributors themselves. You can check how active these channels are before making a decision. However, you can’t rely on them in the long term. If a project becomes dormant or contributors turn their attention to other topics, support will dry up without anyone being contractually obligated to provide it.
Is commercial software the safer alternative when it comes to support?
Not necessarily. Commercial vendors can also be acquired, and products can disappear. The difference lies in the framework: With commercial software, there are contracts that define obligations. Community projects lack this framework, which is why the activity of the project and its contributors themselves becomes a selection criterion.
How well are open-source projects typically tested?
Many projects are quite well-equipped when it comes to development-related testing. Gaps tend to appear in domain-specific, cross-functional testing, and sometimes in interface testing as well. The assumption that “they must have already tested that” therefore doesn’t hold up. Anyone who integrates open-source components into their own systems should test them themselves rather than relying on testing done by others.
How can you contribute to an open-source project if you don’t code?
Feedback, feature ideas, and, above all, bug reports. Meaningful, clear bug reports are valuable to the teams, and that’s exactly what testers are trained to do. Open source isn’t a one-way street: projects thrive on participation. If you can publish your own work, you’re giving back even more directly.
