With the rise of AI and Large Language Models (LLMs) in recent months and years, you might have read a lot about open source software (OSS) in the news, as companies rush to build ever more powerful models using open source models like Meta’s Llama and French startup Mistral’s models.
Over the past decades, open source components have crept into virtually every piece of technology on the planet, whether it's the Linux operating systems that power data centres and cloud services, the Android software behind some of the world's best smartphones, or enterprise development tools like Puppet and Jenkins.
The basis of open source software is that its source code is freely available for anyone to view, modify, and distribute, which can be both a pro and a con, as we will see. OSS comes with a license to use it, and there are different levels of license depending on the type of software at hand.
Developers around the world contributing to something for free, often in their own time, is one of the things that makes the internet great. But there are downsides: a Microsoft engineer recently spotted malicious code in the open source XZ Utils compression tool, likely placed by a nation-state actor, that could have caused havoc. Of course, the fact the tool was OSS made finding the vulnerability possible, so it is swings and roundabouts.
What's the definition of open source software?
Open source, as its name suggests, is a field of software development in which the source code for tools, projects, and programs is made freely available to download, modify, and share. Given it's free-to-use with no restrictions on how you do so, it has become popular among cash-strapped startups and smaller firms.
Another important characteristic is that anyone can tweak the code to suit their purposes. As a result, a thriving and active open source community has developed, with countless developers collaborating on projects and sharing ideas.
OSS harks back to the early eras of computing, when software (and ideas) were shared much more freely among programmers. The GNU Project in the early 1980s is one of the first examples of OSS, helping to set many of the core concepts behind OSS in motion. In 1998, Christine Peterson is credited with coining “open source”, although others around the same time were working on similar concepts.
Open source is sometimes difficult to define thanks to the different types of licenses, and if you are developing OSS it's definitely worth checking at each stage what flexibility you have to use the software.
Who oversees open source software?
Given the distributed nature of OSS, there is no one entity that controls the software. However, there are various entities, from big businesses to smaller, specialized groups, that oversee OSS and ensure that minimum standards are kept.
One of the most prominent organizations is the Open Source Initiative, founded in 1998 by Eric Raymond and Bruce Perens. The OSI termed the emerging software movement as “open source” in opposition to the free software movement, attempting to make a business case for using and developing OSS.
The OSI operates the The Open Source Definition, one of the most widely respected standards in OSS, and the basic principle is that OSS must allow for modification and redistribution under the same terms and all uses. There are 10 criteria to be met for approval by the OSI. Some examples are the Apache License 2.0, Mozilla Public License 2.0, and the MIT License.
Another good example is OpenUK, a non-profit organisation that supports OSS within the UK, a vital function given the UK has a lot of programmers working on various software. Founded in 2018, OpenUK works across Community, Legal & Policy, and Learning areas.
Why is open source so popular?
The most obvious answer is simple: open source software costs nothing.
Looking around, there are many cheap alternatives for popular paid products, such as Blender for 3D computer graphics or LibreOffice Writer for word processing, and in this way, open source programs are inherently more accessible.
The main driving factor behind open source is the idea that as development projects are enhanced and accelerated, the wider the pool of people involved becomes, with developers of varying skills and abilities contributing their own expertise and experience.
This principle of cooperation is helped along by the inherently international nature of projects shared on the internet, with programmers from all over the world collaborating to ensure that finished code is the result of as dedicated and diverse a team as possible.
Sharing couldn’t be simpler for most open source projects: The complete source code is usually posted publicly via code-sharing platforms like GitHub. By keeping projects openly accessible in one place, developers can ensure collaboration is as organised as possible while keeping it organic, and achieve impressive results in short timeframes.
Although allowing so many people to interfere with the source code may be seen as risky, allowing additional scrutiny in the form of an extra pair of eyes – or often enough, several pairs of eyes – boosts the chances of flagging up any bugs, as with the case of XZ Utils. Moreover, open source software lends itself to tighter security, in light of the additional help at hand to shape it or process any problems.
While having many eyes does work, the fact that the Heartbleed bug went undetected in the OpenSSL code for so long means the theory isn't exactly foolproof; it's also possible that rogue developers could use open source to spread malware.
Not everything is rosy, however, and there are a number of issues with open source development, most notably its steep learning curve. Less-seasoned developers may struggle to get to grips with open source projects, and those involved are often highly technically-minded professionals, or the most dedicated of enthusiasts.
The history of open source software
The roots of open source lie in the origins of software and of computing itself. First pioneered by scientists, researchers, and academics, the field was predicated on the free and open sharing of knowledge and information.
One of the ways in which programmers shared their code was via computing books and magazines, which featured full reproductions of source code for readers to copy and use, as crazy as that might seem nowadays. This became particularly popular with the rise of home computers like the Commodore 64 and ZX Spectrum, which could be used to create basic games and apps.
As software development became more commercialised, and competition amongst developers increased, the prevalence of open source code saw a decline. Despite this, hobbyists have continued in the tradition of writing open source software, even as giant software firms have dominated the sector.
As more and more computers became connected to the internet, programmers started sharing their code with each other online, which led to a substantial increase in the number of available open source projects, and eventually to the creation of the Linux kernel by Linus Torvalds, a landmark moment for OSS.
How do companies make money from open source?
OSS developers are not working for free: the existence of licenses, and other forms of monetization, help them earn a living, despite giving away software for nothing at the point of download.
While organisations that specialise in open source products don't generally make money from selling software, many will offer an enhanced version of their product that enterprises can pay to use, as is the case with Red Hat Enterprise Linux (RHEL). These commonly include greater flexibility, more features, easier management, and maintenance options, and generally better interoperability with a range of other platforms and services.
Another tactic often used by OSS vendors is to provide the software freely, but to withhold official support and other additional services from companies that haven't taken out a contract. Since business IT relies on minimising downtime as much as possible, strong support is essential making this tactic very effective.
Why contribute to open source projects?
One of the most obvious reasons developers contribute is the sense of generosity and community spirit it creates; many simply want to help build cool stuff and will contribute to projects that they think are useful and worthwhile.
However, some coders are more utilitarian about the process than others. For example, if a developer is using an open source tool in a particular project, they will often tweak or improve it over the course of their efforts. Those improvements are then circulated to the rest of the software's developers and users, resulting in gradual iterative improvements.
This also applies to companies that use open-source components, who will often contribute large amounts of code to open source projects as a by-product of their own internal development cycles. Companies like Apple, Google, and Microsoft do this. Some companies will also task developers with contributing to existing open source projects out of sheer altruism, but this is considerably rarer.
What's more common is companies gifting tools they've developed internally to the open source community. Part of this is a purely practical effort to outsource the continued development and iteration of these tools to the community at large, but there's also an element of giving back to developers by giving them access to sophisticated software.
Given the extra eyeballs that can be on OSS, companies have an incentive to share as it is likely to make their own tools better and more fully-featured, while also building a good relationship with developer communities.
Is open source safe?
The short answer is: Yes, OSS is safe to use.
In theory, the more people you have reviewing code throughout a build the more likely it is that security holes and errors will be uncovered and fixed. However, no matter how many pairs of eyes the code runs past, human error can and will persist.
The problem with free and widely-shared code is that the vulnerabilities are by default also reused and shared. The most popular open source libraries are embedded into thousands of applications, and if one line of code within a library contains a vulnerability, anything that utilises it will be weakened as a result.
It’s still best practice to check over open source code, even if it’s from a trusted source and seems to work, to check for logical errors and anything else that might have been overlooked in its creation.
Even when vulnerabilities are spotted, a fix takes on average 68 days to be rolled out. Users may think that the creator or developer is responsible for fixing their code, but if the code works for the developer, it's not certain they will revise their work.
The perceived sense of security around open source software adds to the problem. Ultimately, developers who build the code aren't interested in whether their library is suitable for your business, they are concerned with the success of the library itself. Rather than blindly integrating open source code into applications, businesses must carry out their own checks to ensure code is safe.
Open source code can be safe to use with a change of perspective, shifting from the viewpoint that it's faultless and fool-proof to an approach which exercises caution and security.
More on open source
