During TestBash Autumn we invited three fantastic community members and industry experts to take part in the discussion: The âWhensâ and âWhysâ of Automation. And they were: @mahatheed , Diego Molina and @lborodajko !
One of the questions we didnât get to was:
What are the advantages and potential drawbacks of using open-source testing frameworks?
The biggest drawback (with open source in general) is the lack of dedicated support, you can raise issues on GitHub and ask on forums, but that usually takes a lot more time.
Some of the advantages would be greater control, flexibility, customization, and no vendor lock-in.
Second the point about issues taking longer to resolve than commercial alternatives. Thereâs also a danger that open source projects just lose momentum and die⊠they may still be useful but nobody is maintaining the project and community dries up. Arguably this is a bigger problem on commercial/closed source apps though, because if those get pulled (looking at you Google) then nobody can continue using it because the owners have complete control.
Jonathan Blow had a good talk on his stream about his gripes with open source software, you can find the clip here:
He had four main concerns -
Lack of Creativity:
Open source software rarely exhibits creativity. He suggests that instead of innovating, open source projects often copy existing solutions in a subpar manner.
Pull Requests and Class Structure:
Finds the concept of pull requests offensive. He argues that there is an inherent class structure in open source, where those who submit pull requests are considered lower class.
Quality and Friction:
He suggests an alternative approach where only trusted individuals are allowed to contribute, leading to higher quality and less friction. He believes that for complex projects like LLVM, contributions from those who barely know the code may not be worth the effort.
Technical Judgment:
He emphasizes the importance of maintaining a culture of technical judgment in open source. He argues that it matters whether code contributions are good, mediocre, or bad, and losing this culture would lead to the decline of software quality.
He had some other arguments against more-so the culture of open-source projects, but theyâre more difficult to concisely state.
Ooof, I must say I totally disagree with the person in the video!
I must admit I was able to watch just 2 minutes but it was enough for me. Iâd want to refute every single of his statements but in the end thatâs just my personal opinion (and his, but he posted it in a video for all the word to see ).
Just two things:
Open source software rarely exhibits creativity. He suggests that instead of innovating, open source projects often copy existing solutions in a subpar manner.
I think thatâs simply not true. He doesnât offer any proof of this, itâs hearsay.
He suggests an alternative approach where only trusted individuals are allowed to contribute
Not just that, he claims that âif you submit a PR, youâre kind of lower classâ⊠OMG what kind of bull is that?! I donât even know how to refute this, it insults my intelligence.
Haha, heâs a very controversial figure, he has a lot of other insanely hot takes.
I donât really agree either, but itâs cool to see someone who is so counter-culture to current standards to give you another perspective and challenge your beliefs, especially from someone who is so skilled.
I donât think I can generalize enough to push my opinion in a certain direction.
Anything can happen with both paid and free tools used in testing.
I recommend learning when tools can be helpful and what they can do for you, and constantly be on the lookout and trying things.
Adapt quickly!
You can often use free or open-source applications instead of their paid equivalents. If you have the permissions to manage your machine, you can install freeware or open-source software yourself.
In the context of being the first tester on a team/in a company:
Another common technical challenge is a scarcity of resources. As the first tester, you might be working in a smaller organization, which usually means a more limited budget than you might find in larger companies with full testing teams. In addition, it may not have occurred to anyone in the organization that there would be a need for a separate testing budget.