Leveraging open source in 2025 and beyond: A business primer

Today almost all major companies use open source software to some degree. If a company has any kind of web presence, for example, they are at the very least using open source software somewhere in their development toolchain. The ‘2024 State of Open Source Report’ indicates that nearly 70% of organisations increased their usage of open source software in the past year.

There are good reasons for this widespread adoption. With open source businesses can reduce costs and accelerate development velocity, allowing them to focus more on the people and culture that truly differentiates their company. With access to the latest innovations, backed by a community of contributors keeping the most popular projects secure and up-to-date, companies of all sizes can reduce their time-to-market without falling victim to vendor lock-in. They can adapt solutions to meet their unique business needs, and attract and retain talented engineers who are passionate about giving back to the open source community. Rather than paying a third party to continue doing what they were already doing, organisations can have a direct impact on the backlog and features coming in OSS projects they contribute to.

However, these benefits can come with significant challenges. It can be difficult to find the right solution to fit your use case, and evaluating a project to determine its quality, safety and maintenance level can be tricky. Maintainers might not have time to address issues or may lose interest, leaving your team to fix problems or add necessary features to projects you rely on. Documentation can be sparse or outdated, and keeping up with updates and patches can be challenging — especially when they break something your team needs.

Before deciding to buy into a vendor or build something yourself, take some time to look for open source offerings that might fit your needs and your tech stack. There are a variety of places to find open source software beyond just searching Google, and knowing how to look can save you a lot of time. In general, you want to find projects that meet a real need in your application, and don’t do a lot more than what you require. Be wary of solutions that lock you into a particular framework or platform, and always have a migration path in mind to cover you if something goes wrong.

GitHub is currently the largest open source community in the world, and it can be a great place to kick off your search. Besides just searching for keywords related to your use case, you can also browse its collections, topic tags and trending lists to discover new projects. When browsing a topic (like data visualisation), you can filter by the programming language used and sort by criteria like the number of stars (equivalent to "favourites" or "likes"), the number of forks (alternative versions of a project created by the community), or when each project was last updated. Pay attention to the star count — this is a good indication of how many people have used the project over time. It’s not a perfect measure, but it can help you spot projects that are early in their development or haven’t seen wide adoption. Look for projects with a clear, informative README page and with recent updates to indicate they are still being maintained.

Another place to look is within a package index for the programming language ecosystem your team most commonly works with. This might be npm for JavaScript or TypeScript users, Python Package Index (PyPI) for Python developers, crates.io for Rust coders, or NuGet for .NET programmers. Package indexes will often have statistics about the number of downloads over time, how frequently new versions are released, the open source license in use and the dependencies of the project. This is all good information to evaluate the health of a project and identify if it is a good fit for your team.

Older communities like SourceForge used to be good sources of open source software. However, in recent years many have faced significant criticism over the use of adware-laden installers (in some cases adding them to projects without maintainer consent) and difficulties in battling malware. It’s best to steer clear of these communities.

Once you’ve found an open source project that appears to meet your needs, it’s time to take a closer look. You want to find a project your teams can use effectively to solve your use case and build on long term, without introducing risk greater than building yourself or buying from a third-party vendor would involve.

If the project is large and widely adopted you’ll want to read through the changelog to see how often disruptive or backwards-incompatible changes are introduced, to make sure your developers will be able to keep up with updates. If the project is smaller, you’ll want to ensure the maintainers are still committed to it and are updating it regularly. If a project is abandoned or hasn’t been updated in a long time, you may consider using it as inspiration for an internal build, but make sure to still consider open source alternatives before proceeding.

Your ultimate goal is to ensure your engineers won’t run into common pitfalls around lack of support, issues when upgrading or deploying, or skills gaps when customisation is needed.

One of the first places to take a look is the project’s documentation. Documentation is one of the main things that maintainers often wait until later to fill in. This is because the surface area often changes quickly and radically in the early stages of a project. If the documentation is sparse or incomplete then it may be a good indication that a project is not production-ready yet. In addition, many mature and widely adopted projects complement a good README with a detailed documentation website that is easy to navigate and search. Here are some things to watch for:

• Is the README file and the documentation easy to understand?

• Does it explain high-level concepts as well as describe usage?

• Is the documentation thorough, or does it just seem like an afterthought?

• Has it been kept up-to-date as things have changed over time, and is there a changelog?

• Is the code free of messy, out-of-date comments?

• Are there examples?

Tests are one of the other main things that are frequently filled in later as a project approaches production readiness. This depends somewhat on the maintainers, though. Some developers follow a test-driven approach, so their tests will be filled in earlier on in the project lifecycle. Look for good coverage across the major functional portions of the codebase, and make sure the tests are well-considered and useful, and actually validate what the maintainer intends. Tests are also useful to help complement the documentation, demonstrating how to use the software in different contexts to achieve different use cases. These are some key things to consider:

• Is there good unit test coverage that is run automatically with new changes?

• Are there integration tests that exercise the solution as a whole?

• Are the tests well-considered and useful?

• Are they up to date with changes?

• Do they cover your use cases and demonstrate different scenarios?

• Are there skipped or placeholder tests?

For smaller projects with a tightly limited scope, maintenance may only occasionally be necessary. For larger projects, there will typically be regular changes and a clear release cycle if the project is still being actively maintained. To get a more complete picture, make sure you look through the project’s open issues to see how responsive the maintainers are when questions are raised. If there are a lot of older issues with little interaction then that’s an indication the maintenance has fallen off, even though support is needed. The points below will help you spot any warning signs:

• When was the last code commit?

• How frequent are commits and releases?

• Are there functional changes, and not just dependency updates?

• When was the last version published, and is there a clear versioning strategy?

• How many issues and pull requests are outstanding, and how old are they?

• Do the maintainers participate in discussions and provide constructive feedback?

• Are they proactive in their response to Common Vulnerabilities and Exposures (CVEs) and security vulnerabilities?

Now it’s time to move beyond the project repository and look at the community as a whole. Larger projects will typically have a homepage with links to things like chat support groups or wiki pages with community contributions. Look for outside content as well, like articles on developer blogs or posts on forums like Stack Overflow or Reddit. Ask yourself these questions:

• How many people are using the OSS and contributing to it?

• Where can you go if you need help?

• Are there large companies supporting or contributing to the project?

• How many downloads over time are there on package management indexes?

• Are outside forum questions frequently answered?

• Are there many active divergent forks?

Going back to the ‘2024 State of Open Source Report’, the biggest challenge cited by respondents was maintaining security policies or compliance. 79% reported that it is at least somewhat challenging, and 44% described it as challenging or very challenging. There have been some high-profile security incidents related to open source software in recent years — like the XZ utils backdoor inserted by a supply chain attacker, the peacenotwar incident initiated by the node-ipc maintainer, or the event-stream incident involving cryptocurrency theft.

There are many resources available to help you evaluate the security and safety of open source software that your organisation wants to use. The Open Source Security Foundation (OSSF) is a great source of information about safety, like its ‘Concise Guide for Evaluating Open Source Software’. The Open Web Application Security Project (OWASP) is another great organisation, with a detailed ‘Application Security Verification Standard’ to help you assess open source security. The Linux Foundation maintains a security framework specifically focused on supply-chain security, Supply-chain Levels for Software Artifacts.

Take advantage of vulnerability scanning tools like Snyk and the OWASP Dependency-Check on a regular basis, checking for known vulnerabilities. Stay updated with CVE lists, using automated tools like Dependabot where available to monitor your dependencies.

Another important consideration is the license that open source software is released under. Licenses can come with important restrictions around how the software can be used, and how modifications should be handled. The Open Source Initiative mentioned earlier is an excellent source of details about the various licenses in use and what their restrictions are. The Linux Foundation maintains the OpenChain Project, which focuses on open source license compliance with resources for how to adopt open source responsibly.

Pay close attention to the requirements of the license chosen by the project maintainers, especially when integrating with proprietary software. Make sure you have a well-defined compliance policy that defines acceptable use and license guidelines, and is easy for your engineers to follow and manage. Ensure you perform due diligence on the use of open source across vendors that you work with, as well.

Some licenses may be incompatible with others, so be sure to evaluate new licenses in comparison with the existing license from open source software that you have adopted already. Also, consider how the project’s licensing may change in the future. Some projects start out on a compatible license, but may release future versions under a different license. This has been seen recently in shifts by HashiCorp, Elasticsearch, Redis, MongoDB, Red Hat and others.

Exercise care when using projects that are not approved by the OSI. While the OSI is not the final word on whether or not something is truly "open source," it is the most commonly agreed upon source of open source licenses. If you are evaluating a license that has not been accepted by the OSI, there will be added responsibility on you to truly understand the license requirements and potential pitfalls. While some non-OSI licenses are legally sophisticated and have proper licenses, there are also many "novelty" or layman-originated licenses that — while well-intentioned and/or humorous — could create real legal ambiguity or risk when used in your software project.

If the project you have selected has passed all of the scrutinies thus far, there’s a very good chance that it will work well for your organisation. The last thing to consider is how well it fits your team and tech stack, and to do some advance planning in the event that things go wrong.

Take a look at your current tech stack and the other open source tools that your engineers are using, and ask yourself:

• Does it have a good developer experience (DevEx) and work well with the tools your teams already use?

• Is it compatible with the versions of major libraries your team is using?

• Does it work well with your tooling and build process?

• Is the codebase transparent enough that your team can specialise it to cover important use cases?

• Does it include large dependencies you don’t need?

• Will it be easy to deploy, and will it significantly impact your infrastructure budget?

Do some brainstorming with your team around what happens if the project is abandoned, or it switches to an incompatible license. Consider the migration path towards another tool if needed, or of maintaining your own fork of the project if required. Would your team be able to handle fixing bugs and making changes to the project if the maintainers went AWOL, or would they be able to move to something else without starting from scratch?

You’re under no obligation to contribute code to open source projects that you use, but doing so can bring a number of benefits. Solving problems and adding features to open source projects is one of the best ways for your developers to gain a deeper understanding of the software you depend on, far beyond what they would learn by just using it.

Working on open source can sharpen your engineers as they take advantage of the experience of other community members, and help drive progress towards features that can benefit your business and inspire other companies to share their innovation in the same way. It can also go a long way towards retaining great talent, giving them the opportunity to build their reputation and help drive the future of the industry.

At Nearform, we have extensive experience both contributing to and making use of excellent open source software. Over the years our team has included core maintainers of high-profile projects like Node.js, React and React Native; innovative project creators; and excellent lead developers who have successfully navigated countless open source software integrations. Open source is at the heart of what we do, empowering our team to collaborate with cutting-edge experts and help move the industry forward.

We are dedicated to helping our clients embrace powerful open source tools in a responsible way — taking quality, security, licensing and team fit into consideration to help our partners meet their goals faster with lower costs and increased flexibility. If your team could benefit from some expert guidance and a thorough review of your existing open source utilisation or to help evaluate new libraries and tools, we’re here to help!

Contact Nearform today to get the conversation started. We’d love to help you take advantage of the amazing world of open source in a sustainable and secure way!