Why We Choose Open Source Tooling (and When We Don’t)

At QBayLogic, our commitment to open source isn’t ideological—it’s intensely practical. Our compiler is open source. The tools we build upon are open source. This approach has become the norm for how we work, and it would be difficult for us if these foundations weren’t open source.

But, being pragmatic, we use proprietary tools where open-source alternatives don’t (yet) exist or don’t scale to our needs. The choice, again, isn’t about philosophy—it’s about what delivers value to our clients and keeps projects on track.

This article outlines why we choose open source wherever possible, and why sometimes we don’t.

Why Our Clients Like Open Source

Our two biggest projects right now both involve clients who specifically want open-source technology. For one client in cybersecurity, being open source is a hard requirement. For another major technology company, it’s a strong preference. These aren’t outlier cases, it’s a clear trend.

What’s driving this demand?

First, long-term maintenance and avoiding vendor lock-in. Technology companies and organizations have learned that tools often become legacy after 10 or 20 years. They want to invest for the long term, and they need the technology they use to not only last but also grow with them beyond the 10-20 year timeframe. They increasingly recognize that continued community support and industry adoption mean that open-source solutions tend to be longer lasting.

When you’re building systems that need to operate for decades, like medical devices, aerospace systems, critical infrastructure, you can’t be dependent on whether a vendor stays in business or maintains support for a particular product.

For larger organizations, the calculation is equally practical even if the reasoning differs. Major technology companies will take over maintenance of a tool if they need to. They strive to avoid being dependent on one party for maintenance and open-source technology allows them to hire, or insource, maintainers for a tool or platform that’s no longer supported by a company or community. This is extra important, since the products we create for them are usually enablers of their core business, meaning they are critical parts of their daily processes.

Different clients care about open source for different reasons, but the underlying driver is the same: reducing risk, maintaining control over their technology stack and getting their projects delivered.

The Practical Advantages We Experience Daily

Beyond what clients want, open-source tools fundamentally change how we work and contribute significantly to our ability to deliver products on time.

Running unlimited instances of software without license restrictions is as important to us as it is to our clients. In fact, it is the biggest practical advantage of open source over proprietary tools. We can run many tests in parallel when we make changes to our code. We can run tests overnight. We’re unencumbered in spinning up as many simulations and tests as we want, as often as we want. If we had a limited license pool, we might suddenly feel restricted – running tests only at night, for instance – and that would potentially slow down the development cycle or be an incentive to skip certain tests.

At QBayLogic we always work on complex, innovative and novel technology. We explore the unexplored and go beyond the state of the art. In other words: most of the things we do have never been done before. By definition, this comes with uncertainty.

We’ve developed a way of working that eliminates many of the risks of such projects, simply through how we design and develop our products. But we can’t predict every issue upfront and the ability to explore corner cases exhaustively makes the difference between catching problems early and discovering them late in the project, where they can cause delays and extra cost.

We feel the impact of this every single day: we predictably and successfully complete projects that contain incredible uncertainties on time and on budget.

Self-service debugging saves weeks. When something goes wrong with a proprietary tool, you’re at the mercy of vendor support. If there still is any. We’ve experienced two-week debugging sessions on issues where proprietary tools weren’t supporting something properly, with no official way to even communicate the problem without opening a support contract. Two weeks of lost time and frustration.

With open-source tools, if something isn’t working, we can look into it and possibly fix it ourselves, making our work significantly easier, more efficient and more fun.

No procurement bureaucracy for clients. If we use proprietary tools, delivering the end product for validation to the client can sometimes involve talking to distributors or vendors to get licenses, going through our customer’s purchasing department and budgeting processes. When things are free and open source, they don’t show up in the budget and don’t slow down the implementation.

Research organizations and universities working with us find this particularly important. They want their teams to just get started, not navigate procurement bureaucracy.

We can also test software without going through the pain of getting a demo license from the vendor, allowing us to quickly test new approaches and technology. Demo licensen only last for a limited amount of days and/or have feature restrictions. Hence, finding out if a tool will work for us, needs to be precisely planned, while we can try open source tools at any time, for as long as we like and without functional restrictions. This tremendously improves development cycles and increases the flexibility of our engineers.

And, of course, cost. Open-source software is free in two meanings of the word: first, it’s available to anyone that wants to use it and anyone that wants to put in the effort can contribute (this is what the open-source community calls ‘free, as in speech’). But it’s also free to use at zero cost (know colloquially as ‘free, as in beer’).

If we had to use proprietary tools for everything, our operating costs would increase substantially. But the cost isn’t just financial. License-based tools create a dependency that can incentivize less-than-optimal engineering practices, like testing less or using less effective tools because it saves money, which makes no sense from an engineering perspective.

When We Don’t Use Open Source (And Why)

There are still functionalities that open-source tooling does not provide sufficiently. For the final stages of FPGA development – synthesis, place and route, bitstream generation – we still often use proprietary tools from FPGA vendors.

Open-source alternatives have developed mostly in the last five to seven years, giving us the option to use open-source tooling in these areas. But there’s a significant limitation: we need to buy specific hardware to use the open-source tooling, since the open source tools only work with a small subset of available FPGA hardware.

The proprietary tools also represent 50 years of accumulated intellectual property: valuable IP that can do remarkably advanced things.

The Industry Shift We’re Part Of

This isn’t just a QBayLogic preference. We may be ahead of the curve on this, but it’s clearly an industry trend partially driven by universities wanting to use open source tools. The reason, again, is practical: they want frictionless tools that are easy to use, where students won’t encounter installation problems or access issues. Universities can get free licenses for proprietary tools, but that’s not the point. The open-source tooling has made a genuine effort to be easier to use these days than the closed-source alternatives.

To a certain extent, tool vendors have contributed to this shift by increasingly adopting the Software-as-a-Service (SaaS) model. Although this model has advantages, it prevents universities and smaller companies like us from accessing all the intellectual property needed to deliver innovative products or services or do cutting edge research. The monthly software bill would simply kill our margins and our operational flexibility.

When universities adopt these tools, graduates enter the workforce familiar with them, meaning young people push the adoption of open-source tooling, either by advocating it within companies or founding startups.

We’re past the tipping point on this and some big companies are starting to adapt and experiment with these approaches. This shift started with a catalyst: Claire Wolf open sourcing a critical component that had been closed for a long time, which allowed the community to grow around it.

Some companies still making money from proprietary tools and SaaS naturally resist this change, but all surrounding companies in the ecosystem benefit significantly from open source adoption.

The transformation is happening gradually, but it’s happening. And we’re proud to be at the front of the wave.