What is open-source?
Open-source is the umbrella term for software that is created and shared under one of the many open-source distribution licences. This approach contrasts with proprietary solutions that one can’t reuse or even modify without a company’s permission. You are free to buy an iPhone that has a preinstalled calculator app, but not use portions of its code to make your own solution.
Even though there is no transaction, open-source licences are real and can be enforced. Here are the key things that one may or may not do with open-source software:
- Modifying the provided code
- Distributing modified code
- Linking the provided code with code under a different licence
- Patenting modified code
- Privating modified code, i.e. not contributing it to the community
- Sublicensing modified code under a different, potentially less open licence
The sublicensing part essentially defines whether you can reap the benefits of open-source in a commercial and thus often proprietary manner. Some developers are okay with you making people money for a derivative of their public work, while others won’t allow that.
With a few exceptions, open-source software for developers (and regular people) is free. This is the case for QA solutions, as JMeter, SoapUI, and Selenium software that we integrate with our test manager tool are all distributed at no fee. This does not mean that companies don’t earn money. Selenium is a non-profit organisation, but they still make $180,000 in yearly sponsorships. Looking at commercialised open-source, WordPress was bringing enough hosting and ad revenue to be valued at $3bn in 2019.
Integrate the best open-source QA software into your testing
Benefits of using open-source for developers
So, why is open-source good? There are a number of advantages that have a varying impact on development costs and operations.
- Open-source eliminates time-consuming work. In software development, there is often very little need to reinvent the wheel. Other people’s code is transparent to see that it is not harmful, so why not reuse it if you can? You don’t need to make your own email verification flow when it has had little evolution for a decade. You see that in manufacturing too, from common smart home protocols to game console vendors reusing advanced third-party emulators to make games backwards compatible.
Similarly, open-source works great when you are running a beta test or preparing an early build. Why spend hours making an installation wizard when all you need is to evaluate how key functionality works? It would be even more frustrating to have spent the time if the test reveals the need to make changes fast.
- Open-source brings a new perspective. A good number of open-source solutions had dozens if not hundreds people contribute to them. Most tasks have been approached by the community from more angles than one development team could ever list, yet alone try. This should help you make the perfect solution or fine-tune an open-source one even if efficiency gains are not that exciting to you.
Even more interestingly, you can actually trace how a community arrived at a certain implementation. Public repositories have a history of commits, so you can see the evolution of code over years and even decades. The commit history alongside community discussions may inspire you to take something proven into a new direction.
- Open-source has unprecedented quality. A lot of passion goes into open-source projects. Combined with some developers’ inclination for min-maxing things, you will always have someone trying to optimise great code into something even better. The fact that a certain problem has been worked on together for months and years helps a lot, too.
The sheer amount of extra eyes helps a lot, too. Even if you work at FAANG, it is very unlikely to have more people have a critical look at your code compared to it being available online. If you are a small team that does not focus on tech-savvy customers, there may be very little feedback to turn to without open-source.
Drawbacks of using open-source code
Here are the biggest pitfalls that come from adopting open-source.
- You are not (fully) in control. The most infamous example here is what happened when a product manufacturer entered a copyright dispute with an independent programmer Azer Koçulu over a filename. He felt wronged and unpublished all his contributions, including the 11 lines of code that made CSS lines start with a space. That made Facebook, Netflix, and Spotify websites stop functioning among others.
That specific outage was mitigated quickly, as the npm software registry took matters into their own hands and un-unpublished the code within 10 minutes. It does, however, mean that using a complex nest of open-source packages that reference other open-source code can come tumbling down on you. One can avoid that with a proper update pipeline that is not hindered by misconceptions about DevOps.
- Maintenance can become your problem. The passion behind open-source projects can bring their downfall. If your software relies on a piece of open-source that something like a Google Chrome update broke, the creator may or may not fix it. Suddenly, making things compatible again becomes your responsibility (and potentially a contribution to the open-source community).
Some platforms are more ready for such issues than others. Both WordPress and Jenkins allow a third party to adopt plugins that were abandoned so the development can continue. If it is something less critical, perhaps someone else will take care of a problem before it becomes yours.
Is there a future for open-source?
In our opinion, the future of open-source looks just as bright as the present. There will still be developers that make pet projects which the larger community will benefit from. The startup industry, even if deflated because of the recession, will continue to stitch open-source code together for a product MVP. Large companies will still have the incentive to simplify maintenance of their tech stack by licensing it to the community (e.g. Facebook’s React).
Open-source is an amazing proposition. It allows you to utilise the passion and experience of hundreds of developers, use it in your product, and perhaps make the public code even better. The two biggest pitfalls can be largely mitigated with work that you would likely be doing for proprietary code anyway.
Connect any community QA solution via REST API