Open Source as a Counter-Strategy to Corporate Hegemony

For most of software engineering history, the choice between proprietary and open source tools was framed as a practical one: cost, features, support, maturity. That framing was always incomplete. It treated as neutral a situation that is anything but: the progressive concentration of digital infrastructure — the cloud platforms, the AI services, the data pipelines that modern organisations depend on — inside a small number of corporations with their own interests, their own political alignments, and their own definitions of who deserves access to what.

The events of recent years have made that incompleteness harder to ignore. Investigative reporting and UN documentation have established in substantial detail that several of the largest technology companies — Microsoft, Google, Amazon, Palantir, and OpenAI — have provided cloud computing, AI inference, and data processing infrastructure to military operations in ways that raise serious questions about where commercial technology ends and lethal targeting begins. Microsoft's Azure platform reportedly stored more than 13 petabytes of intercepted communications data from Palestinian civilians. Google and Amazon share a billion-dollar government contract — Project Nimbus — structured to limit their own ability to restrict how their services are used by military and intelligence units. Palantir's CEO publicly acknowledged the use of his company's battlefield AI systems against civilian populations.

These are not fringe claims. They are documented in UN Human Rights Council reports, AP investigations, and the companies' own policy changes — OpenAI, for example, quietly removed explicit prohibitions on military use from its guidelines in January 2024.

The question this raises for any organisation that uses these companies' services is not a comfortable one: what is the relationship between the fees you pay for cloud infrastructure and the capabilities those same platforms provide to actors whose conduct you may find indefensible? It is a question that open source, structurally, allows you to sidestep.

Two Frameworks for Understanding the Problem

The academic literature offers two particularly useful frameworks for understanding what has happened to digital power — and why it matters for organisations that depend on technology.

Surveillance Capitalism

Shoshana Zuboff's concept describes an economic order in which human experience — behaviour, attention, location, preference — is treated as raw material to be extracted, processed into prediction products, and sold. The key insight is that the "product" of surveillance capitalism is not the service you use. It is you — or more precisely, models of your future behaviour derived from the data your use generates.

Applied to industrial organisations: your factory's operational data — production rates, machine signatures, quality patterns, energy profiles — is extraordinarily valuable raw material. When it sits on a proprietary cloud platform, the extraction logic of surveillance capitalism applies to it as much as it does to a consumer's browsing history. The vendor learns your process. You remain dependent on them to access your own knowledge.

Technofeudalism

Yanis Varoufakis argues that what appears to be capitalism is being replaced by something structurally different: a system where digital platforms function as fiefdoms, extracting rent rather than competing for profit. Cloud infrastructure — server farms, trained models, distribution platforms — is the new productive capital, owned by a handful of "cloudalists" on whom everyone else depends to reach markets, store data, or run applications.

The relevance for manufacturers is direct. An ERP system hosted on Azure, an AI service running on AWS, a SCADA historian feeding into a proprietary cloud analytics platform — each of these is a feudal dependency. You pay cloud rent to access your own operational capabilities. The platform owner sets the terms. Exit becomes increasingly expensive as operational processes embed themselves into proprietary formats and integrations.

Together these frameworks explain why the open-versus-proprietary question is not a technical preference. It is a question about power: who controls the infrastructure of your operations, what they can do with what they know about your organisation, and what leverage they have over your future decisions.

The Ethical Foundation: Four Freedoms

Richard Stallman's free software philosophy, first articulated in the GNU Manifesto in 1985, defined software freedom through four rights that remain the most precise statement of what is actually at stake in the open/proprietary distinction. They are worth stating directly, because each one corresponds to a specific form of dependence that proprietary software creates.

Freedom to Run

Use the software for any purpose, on any machine, for any number of users, without asking permission from a vendor.

Freedom to Study

Inspect how the software actually works. Not the marketing documentation — the code. Requires access to source.

Freedom to Redistribute

Share the software with others. This is what makes communities of practice possible around a shared tool.

Freedom to Improve

Modify the software and distribute your improved version. This is the right that makes open source a living system rather than a fixed product.

Stallman's famous distinction — "free as in freedom, not free as in beer" — points to something that is frequently missed in enterprise software conversations: the ethical imperative is not price, it is liberty. A system that costs nothing but cannot be audited, modified, or run independently is not free in any meaningful sense. A system that costs money but grants all four freedoms is genuinely free. The industrial software market is full of both, and conflating them leads to procurement decisions that trade short-term cost savings for long-term dependency.

Four Dimensions of the Counter-Strategy

Open source is not a single position. It is a set of structural properties that confer specific strategic advantages. Each dimension addresses a specific vulnerability that proprietary software creates.

Auditability

You can see what the software actually does

Proprietary software is, by definition, opaque. The vendor tells you what it does. You cannot verify that claim independently. For consumer applications this is inconvenient. For industrial software that controls physical processes — or handles sensitive operational and personnel data — it is a structural risk.

Open source software can be audited. Security researchers, independent engineers, and the operators who use it daily can examine what data is collected, where it goes, and what logic governs the system's behaviour. This is not a theoretical benefit. It is the only basis on which genuine trust — as opposed to contractual obligation — can be established between a software system and the organisation that depends on it.

Data Sovereignty

Your operational data remains yours

When a manufacturer runs its SCADA historian, MES, or ERP on proprietary cloud infrastructure, the operational data of that plant — production rates, energy consumption, quality profiles, process parameters — lives on servers owned and operated by a third party. That party has its own terms of service, its own government disclosure obligations, and its own commercial incentives.

Open source, deployed on infrastructure you control, changes this relationship fundamentally. Your process data does not leave your network unless you choose to send it somewhere. There is no background telemetry to a vendor's analytics platform, no licensing enforcement mechanism that requires a cloud connection, no situation in which a contract dispute with a vendor results in operational data becoming inaccessible.

For manufacturers in emerging markets — operating in jurisdictions with limited leverage over foreign cloud providers — data sovereignty is not a philosophical concern. It is a practical one.

Economic Independence

The cost of exit does not increase every year

Proprietary enterprise software is designed, structurally, to make switching expensive. Data formats are proprietary. Integrations are certified only with the vendor's own ecosystem. Training and institutional knowledge accumulate around a specific vendor's interface. Support requires purchasing the vendor's own services.

This is not an accident. It is the business model. Economists call it lock-in rent — the premium extracted not because the software is uniquely valuable, but because leaving has become more expensive than staying.

Open source disrupts this model at the root. When the software is freely available and the data formats are open standards, the cost of switching is determined by technical migration effort — not by licensing agreements designed to make exit impossible. For organisations building long-term digital capability, this changes the investment calculus entirely: you are building on a foundation you own, not renting access to someone else's.

Collective Governance

The roadmap is shaped by users, not shareholders

The development priorities of proprietary software are set by product managers who answer to investors. Features that benefit a large enterprise customer with a large contract will be built. Features that would benefit a mid-market manufacturer in a developing economy may never appear on the roadmap.

Open source projects governed by user communities invert this. Organisations that contribute code, documentation, or funding shape the direction of the software in proportion to their contribution — not their contract size. The result, over time, is software that reflects the needs of the people who actually use it, rather than the preferences of the people who sell it.

This is why Odoo has become a genuinely competitive alternative to SAP and Oracle for manufacturing ERP — not because it is cheaper (though it is), but because thousands of organisations have contributed the features they needed, accumulating into a platform that nobody's internal team could have built alone.

The Honest Complications

An argument for open source that does not acknowledge its complications is not an honest one. There are real costs and trade-offs.

Support and accountability are structurally different

With proprietary software, there is a vendor with a contract and a support obligation. With open source, support is community-mediated, commercial support contracts (Red Hat, Odoo Enterprise, Canonical) exist but are not universal, and the organisation must develop internal capability to manage the stack. This is a cost — one that pays back over time, but cannot be ignored at the start.

Open source requires internal capability

An organisation that installs Odoo or deploys a self-hosted data infrastructure without the engineering capability to maintain and extend it has not reduced dependence — it has simply changed the vendor to a more demanding one. Open source amplifies organisational capability but does not substitute for it. The investment in internal skills is inseparable from the investment in open source infrastructure.

Licences matter and vary significantly

Not all open source licences are equivalent. GPL licences (copyleft) ensure that derivative works remain open. MIT and Apache licences are permissive — software built on them can be made proprietary. Organisations building on open foundations should understand what the licence actually guarantees about the long-term availability and modifiability of their tools. "Open source" on its own is not a guarantee of freedom; the specific licence is.

These are genuine constraints, not dealbreakers. They argue for a thoughtful, staged approach to open source adoption — starting where the benefits are clearest and the internal capability is available to sustain the choice — not for avoiding it.

What This Means for Manufacturers in Practice

For industrial organisations — particularly in markets like Pakistan, where foreign cloud vendors have no operational or legal presence, where contract enforcement against multinational corporations is a fiction, and where technology budgets do not permit absorbing annual double-digit license escalations — the open source counter-strategy is not idealism. It is operational risk management.

The practical agenda is not to immediately replace every proprietary tool. It is to make deliberate decisions — from this point forward — that move the architecture toward openness. When the next SCADA historian is procured, evaluate whether an open-standards platform serves the requirement. When the next ERP cycle begins, assess whether the lock-in premium of the incumbent vendor is justified by capability the open alternative cannot match. When AI is added to the stack, choose tooling that runs on infrastructure you control.

Over a five-year horizon, the cumulative effect of these decisions is significant: operational data that stays on your servers, a technology stack that a regulator, auditor, or independent engineer can inspect, and a position in your supply chain that is not permanently encumbered by the pricing decisions of vendors who know you cannot leave.

"The choice is not between proprietary convenience and open source idealism. It is between technological systems that concentrate unaccountable power and those that distribute democratic control. Stated that way, the question answers itself — but only if you are asking it seriously."

Fluxentra's own architecture reflects this position. Our industrial platform is built on open standards — MQTT, OPC-UA, open time-series databases, Odoo for manufacturing ERP — not because proprietary alternatives do not exist, but because the organisations we serve should own their operational capability, not rent it. When a client's budget cycle changes, or a vendor relationship ends, or a new capability needs to be built, the open foundation means the work already done remains fully theirs.