Open Source Isn’t the Strategy. Choice Is.

Technology has a tendency to turn into camps. Microsoft or open source. Cloud or self-hosted. SaaS or custom development. Low-code or traditional code. Managed services or infrastructure you control. We spend a surprising amount of time debating which approach is better when, in many cases, the more important question is whether we are solving the right problem in the first place.

At texlytics, we believe technology decisions should begin with the needs of the business. Once we understand the problem, the constraints, the people involved, and what success actually looks like, then we can determine which technology is best suited to the job. That sounds obvious, but it is remarkably easy for organizations to reverse that process and begin with the technology they already own.

When the Vendor Starts Driving the Architecture

Every organization develops technology preferences over time. Companies invest in platforms, hire people with specialized skills, negotiate enterprise agreements, establish vendor relationships, and accumulate years of institutional knowledge around particular ecosystems. Standardization can be extremely valuable because it reduces complexity, improves supportability, strengthens governance, and allows teams to develop deeper expertise.

The problem begins when standardization stops being a means of supporting the business and becomes the objective itself. A company can gradually reach the point where the first question asked about a new requirement is no longer, “What is the best way to solve this?” but instead, “How do we do this with the platform we already have?”

Sometimes the answer is that the existing platform is exactly the right tool. There is tremendous value in using capabilities that are already licensed, supported, secured, and understood by the organization. But that conclusion should come from evaluating the problem, not from assuming the answer before the evaluation begins.

Once an organization starts making technology decisions around a vendor rather than a business requirement, the architecture can begin reflecting the limitations of the technology instead of the needs of the company. Eventually, every problem starts looking like something that should be solved with whatever tools happen to already be sitting on the shelf.

Why Open Source Matters to Us

This is where open-source technology becomes important to our strategy. It is not because we believe open source is inherently better than commercial software, and it certainly is not because open source means free technology. There are still real costs associated with implementation, infrastructure, support, maintenance, security, upgrades, customization, and the people required to manage it.

What open source provides is another option. Depending on the application, it can give an organization greater control over its data, infrastructure, hosting, customization, integrations, and long-term direction. It can also provide an alternative when licensing structures, platform restrictions, or vendor roadmaps make a commercial product less attractive for a particular business requirement.

That additional choice is what interests us. We want to be able to evaluate an open-source platform alongside a commercial product and make the decision based on capability, economics, security, scalability, maintainability, and fit. The licensing model should be part of the evaluation, but it should not predetermine the outcome.

We Still Bet Heavily on Microsoft

Anyone familiar with our work knows that we use Microsoft technology extensively. Fabric, Azure, Power BI, SQL Server, Teams, Power Platform, and Microsoft’s AI ecosystem can all play important roles in the systems we design. We use those technologies because they are exceptionally capable and because, in the right environment, the integration between them can create significant business value.

Using open-source technology does not conflict with that strategy. There are problems where Microsoft provides the strongest solution, others where a specialized commercial platform makes more sense, and still others where an open-source application provides greater flexibility or control. In many environments, the best architecture will contain all three.

That is an important distinction. Being vendor-agnostic does not mean avoiding major technology vendors, nor does it mean building everything yourself. It means being willing to evaluate alternatives without allowing an existing vendor relationship to make the decision automatically.

Integration Changes the Conversation

Modern integration capabilities make this approach increasingly practical. APIs, cloud services, data platforms, event-driven architectures, and standardized interfaces allow systems from very different technology ecosystems to work together in ways that would have been considerably more difficult in the past.

A business might use a commercial ERP for financial operations, an open-source application for a specialized workflow, Microsoft Fabric as its enterprise data platform, Power BI for analytics, Azure for cloud services, and several SaaS products for specific business functions. There is nothing inherently wrong with that architecture if the systems are intentionally selected, properly governed, securely integrated, and collectively serve the needs of the business.

Of course, there is a limit. Adding technology simply because we can creates its own problems. Every additional platform introduces another system to secure, integrate, support, document, monitor, and eventually replace. Vendor independence should never become an excuse for unnecessary complexity.

The objective is not to maximize the number of technologies in the environment. It is to avoid unnecessarily restricting the technologies available to solve a problem.

Vendor-Agnostic Doesn’t Mean Vendor-Indifferent

Being vendor-agnostic also does not mean pretending that every platform is equally capable. Technologies have different strengths, weaknesses, maturity levels, support models, security capabilities, ecosystems, development communities, and total costs of ownership. Those differences matter, and evaluating them is part of responsible technology leadership.

There are also legitimate reasons to accept some level of vendor dependence. A managed platform may eliminate substantial operational overhead. A commercial product may provide support, compliance, security, or specialized capabilities that would be expensive to reproduce internally. An integrated ecosystem may dramatically reduce the complexity of delivering a solution. Avoiding vendor lock-in at any cost can become just as irrational as ignoring it completely.

The goal is to understand the tradeoff being made. If we choose a proprietary platform, we should understand what we gain from that decision and what flexibility we give up. If we choose open source, we should understand the additional ownership and operational responsibility we may be accepting. Neither model removes responsibility from the technology decision.

Technology Should Preserve Options

One of the things I believe we underestimate when evaluating technology is the value of future choice. Most technology evaluations naturally focus on immediate requirements: what the system can do today, how quickly it can be implemented, what it will cost, and whether it solves the current business problem.

Those questions are essential, but architecture also has to account for a future we cannot fully predict. Businesses grow, acquire other companies, enter new markets, reorganize operations, replace leadership, change infrastructure, and encounter requirements nobody anticipated when the original system was selected. Vendors change too. Pricing models evolve, products are acquired or discontinued, roadmaps shift, and technologies that once seemed permanent eventually become legacy systems.

A good technology decision solves the problem in front of us without creating unnecessary constraints around the problems we will face later. We cannot eliminate every dependency or predict every future requirement, but we can be deliberate about the dependencies we accept and preserve flexibility where doing so has meaningful value.

That is why open source has become an important part of the technology strategy at texlytics, while Microsoft and other commercial technologies remain equally important parts of our toolbox. We are not betting on one licensing model, one vendor, or one technology ecosystem winning everything.

We are betting on maintaining the ability to choose the right technology for the problem, understanding the tradeoffs that come with that choice, and building systems that can evolve as the businesses behind them evolve.

Open source isn’t the strategy. Choice is.