What Linux made available
Linux is an unusual gift because its value grows when other people use it, change it and build businesses around it. A student can study the same underlying technology that a company uses to operate important computing systems. A manufacturer can adapt it to a device. A developer can investigate a problem without being restricted to the information that a software vendor chooses to disclose. These freedoms do not remove the cost of engineering, equipment or support. They do, however, change who is allowed to participate. Access to a substantial part of modern computing infrastructure does not depend on negotiating a private agreement with its original creator.
That achievement invites a financial question. What might Linux have been worth if Linus Torvalds had built a proprietary software company around it? A platform with comparable adoption, recurring revenue and influence over customers’ computing decisions could plausibly attract an enormous valuation. Estimates running into hundreds of billions of dollars are easy to construct, and a sufficiently optimistic future scenario reaches the trillion-dollar range. But those calculations contain a problem that cannot be removed with a spreadsheet: Linux’s openness helped produce the adoption being valued. A proprietary “Linux Corp” would have developed under different conditions, with different contributors, competitors, costs and incentives.
From a kernel to complete operating systems
Torvalds began developing the Linux kernel in 1991. The kernel is the central component that manages computing resources and provides the connection between software and hardware. It is not, by itself, everything a person needs for a complete desktop or server operating system. Linux became part of usable systems through its combination with other software, including tools developed by the GNU project. The GNU project’s own history records that Linux was developed in 1991 and became free software in 1992. This history matters because the finished result was never simply one person’s product waiting to be placed inside a company. It combined work from several sources.
A Linux distribution brings these components together into something people can install and maintain. It supplies a selection of software, installation tools, package management and a process for delivering updates. Different distributions make different choices about stability, release schedules, supported hardware and the intended user. That creates room for both community projects and commercial suppliers. The distinction also helps explain why “Linux revenue” is difficult to define. A customer might pay for a supported distribution, a managed server or an application running on Linux. Those payments relate to the same underlying technology without necessarily belonging to the same business or representing the same product.
Why open source is more than a zero price
The Linux kernel is distributed under version 2 of the GNU General Public License, with a documented system-call exception. The licence gives recipients rights to use, study, modify and redistribute the software under its conditions. Its source-sharing requirements generally become relevant when covered software is distributed; private modification does not automatically require public release. Nor does running an ordinary application on Linux automatically require that application to become open source. The kernel documentation explicitly describes the boundary between the kernel and programs communicating with it through system calls. This combination allows a shared operating-system foundation to support many different software businesses.
The practical benefit is the ability to act when the software does not meet a need. Consider a business that discovers a performance problem affecting a particular workload. With sufficient expertise, it can examine the relevant code, commission an investigation and develop a modification. It may still prefer to purchase support, and its proposed change may never be accepted into the main project. Nevertheless, the technical work is possible without first persuading an exclusive owner to reveal the implementation. That option has value even when it is rarely exercised. It changes the customer’s negotiating position and gives engineers a route beyond waiting for a supplier’s next release.
The same freedom has educational value. Learning an operating system solely through its visible behaviour is different from being able to examine how it works. Source availability allows students and researchers to move between an explanation and the implementation behind it. They can test an idea, make a change and investigate the consequences. Most will never become kernel developers, but the opportunity is not reserved for employees of a particular company. A person with suitable equipment, time and access to the necessary learning material can begin. The resulting knowledge can then travel between employers, universities and independent projects rather than remaining attached to one proprietary product.
How that freedom creates economic value
For a new business, avoiding an initial software licence bill can help, but the larger advantage may be the freedom to experiment before the business model is established. A developer can test an application, change the deployment arrangement and discard an unsuccessful approach without renegotiating access to the underlying kernel. The business still pays for computing resources and labour. It may also purchase commercial software and support. What changes is the number of decisions that require permission from an operating-system owner. When experiments are uncertain and many will fail, reducing that friction can make small projects economically practical.
For established businesses, the benefit often concerns control and continuity. A long-running service may need support beyond a particular vendor’s preferred timetable. Source access gives the organisation, or a supplier it hires, a technical starting point for maintaining the software. This is not a promise that continued maintenance will be cheap or straightforward. Complex systems require experienced people, testing and coordination. But there is a material difference between an expensive option and no lawful, practical option at all. Open source can preserve a path forward when a commercial relationship changes, provided someone is willing to fund the work required to use that path.
Linux also allows different industries to share development costs. A hardware manufacturer benefits when its equipment works well with the kernel. A distributor benefits from reliability improvements. A business operating demanding workloads may benefit from changes in scheduling, networking or memory management. The kernel’s development documentation describes these overlapping incentives and the maintenance advantages of contributing changes to the main project instead of keeping them separate. The economic inference is straightforward: where improvements serve several participants, cooperation can reduce duplicated work. Companies can contribute to common infrastructure while continuing to compete through their hardware, services, applications or customer relationships.
Android offers a concrete example of reuse across a much larger product. Google’s Android documentation explains that its kernels are based on Linux long-term-support kernels, with Android-related changes added. This does not make an Android phone identical to a desktop Linux system, nor does it make every service or application on the phone open source. It shows how a shared kernel can become a foundation for a different platform. A manufacturer does not have to invent every low-level operating-system function before working on its own device. The commercial value appears across hardware, software and services, rather than accumulating exclusively in a company selling the original kernel.
Open source still needs people and money
Describing Linux as a gift should not suggest that it maintains itself. Software needs review, testing, documentation, security work and decisions about which changes belong in a release. Some contributors are volunteers; others work on behalf of employers with commercial interests. A company using open source without paying a licence fee is not using something that cost nothing to produce. It is benefiting from work funded through several arrangements. The sustainability question is whether enough of the organisations receiving that benefit help maintain the shared foundation. A successful project can create substantial economic value while parts of its maintenance remain difficult to finance.
Source availability also creates an opportunity for inspection rather than a guarantee that inspection has happened. A security problem can survive in publicly available code if nobody notices it, understands its consequences or has the time to fix it. Organisations still need competent administration, timely updates and a clear view of their dependencies. Treating “open source” as an automatic security certificate misunderstands the benefit. The stronger argument is that investigation and repair are not reserved for a single supplier. More parties can participate, but useful participation still requires expertise, coordination and resources. Openness makes those activities possible; it does not complete them.
These costs help explain why commercial Linux suppliers exist. An organisation may be able to obtain software without paying for the code and still prefer a subscription that includes tested updates, maintenance commitments and support. Red Hat’s subscription model is an example of selling services and assurances around open-source software. Customers are paying for a maintained product and a supplier relationship, not simply for permission to view an otherwise inaccessible program. Different subscriptions provide different benefits, so the contract still matters. The broader point is that commercial activity and open source can reinforce one another rather than representing mutually exclusive choices.
What a hypothetical Linux Corp would actually own
The phrase “Linux Corp” is useful for a thought experiment, but it needs a definition. Here it means an imagined company founded around Linux at an early stage, owning sufficient rights to sell a proprietary operating system and build a business around it. It does not mean that Torvalds could now package every existing contribution, distribution and Linux-related service into a company he owned outright. The Linux trademark belongs to Torvalds, but ownership of a trademark is different from ownership of all software carrying that name. The current kernel also contains contributions governed by their applicable licences. A credible alternative history has to begin much earlier.
Even then, there are several possible business models. Linux Corp might charge equipment manufacturers, sell subscriptions to enterprises, license installations or operate a managed computing platform. Each would produce a different relationship between adoption and revenue. A widely used component might command only a small payment per device. A business selling a supported platform could earn more per customer but incur substantial service and sales costs. A cloud operator could generate much larger bills while also paying for data centres and infrastructure. Before assigning a valuation, the imagined company needs an identifiable product, paying customers and a reason those customers would continue paying.
The market-size figure is therefore a starting point for a scenario rather than a ready-made income statement. Fortune Business Insights projects a global Linux operating-system market of $31.84 billion in 2026, covering offerings from several companies across servers, virtual machines and desktops. That estimate is not revenue earned by Torvalds, and it is not an audited result for a single Linux supplier. Nor should it be treated as the total economic activity made possible by Linux. It measures a defined commercial market. Turning that market into one corporation’s sales requires an additional assumption about how much spending the corporation could capture.
Could Linux Corp have been worth $350 billion?
William Berg of DayTrading.com presents the valuation thought experiment in a supplied comment: “Based on the projected size of the Linux market being $31.84 billion in 2026 and assuming that Linux Corp would have captured the entire market, we can guesstimate that a Linux Corp might have been worth around $350 billion using a standard tech valuation. If we were to value it like Microsoft, it would be close to $500 billion. But a better comparison might be Red Hat, which would value Linux Corp at just a little over $100 billion.” These figures illustrate the possible scale of the argument, but they require different assumptions and should not be treated as interchangeable estimates.
The $350 billion calculation is approximately an eleven-times-revenue valuation applied to the entire $31.84 billion market. That arithmetic works: $31.84 billion multiplied by eleven produces $350.24 billion. The assumption that needs attention is the word “standard”. There is no single standard technology-company valuation multiple. Investors pay different prices for revenue depending on growth, profitability, competitive strength, customer retention and the cost of supporting expansion. A mature supplier with substantial service costs may command a very different multiple from a fast-growing software company with strong margins. Eleven times revenue can be used as an illustrative assumption, but it does not become appropriate simply because the business sells technology.
Market share changes the result just as sharply. If Linux Corp captured a quarter of the projected market, its annual revenue would be $7.96 billion. Applying the same eleven-times-sales assumption would produce a valuation of about $87.6 billion. Capturing half would produce approximately $175.1 billion. These are not alternative forecasts; they demonstrate how much of the headline estimate comes from assuming that one company receives the whole market’s revenue. A proprietary owner might collect licensing payments from several suppliers, but those royalties would not necessarily equal the suppliers’ total sales. Ownership of an essential component does not automatically confer ownership of every commercial activity built around it.
Why the Microsoft comparison needs care
The proposed $500 billion figure implies a multiple of approximately 15.7 times the $31.84 billion revenue assumption. Calling that a Microsoft-style valuation conveys an idea of a highly profitable, deeply established technology platform. It does not establish that this is Microsoft’s current market multiple or that an operating-system supplier deserves the same treatment. Microsoft’s reported business includes cloud services, productivity software and other operations alongside Windows. Its valuation reflects that combination, as well as expectations about future earnings. A hypothetical Linux Corp would need its own argument for recurring revenue, margins and growth rather than inheriting Microsoft’s valuation characteristics through an operating-system comparison.
The calculation must also distinguish company value from the founder’s wealth. A business capitalisation of $350 billion would not mean that Torvalds personally held $350 billion in spendable assets. An expanding company might issue shares to investors, employees or acquisition targets, reducing the founder’s ownership percentage. Debt and cash would also matter when moving between enterprise value and equity value. Finally, a quoted shareholding value is different from the amount that could be realised by selling it. These distinctions do not make a large hypothetical business impossible. They prevent a company valuation from being presented as a fortune that its creator simply declined to collect.
What Red Hat actually tells us
Red Hat is a useful comparison because it demonstrates that an open-source business can attract a major acquisition price. IBM completed its purchase of Red Hat in July 2019 for approximately $34 billion in equity value. IBM’s announcement also reported Red Hat’s fiscal 2019 revenue at approximately $3.4 billion. Dividing those rounded figures gives an equity-purchase-price-to-annual-revenue ratio of roughly ten times. That is a historical transaction comparison, not a current trading multiple or a general rule for valuing Linux companies. Nevertheless, it provides a firmer reference point than choosing a multiple without identifying where it came from.
Applied mechanically to $31.84 billion of annual revenue, that rough ten-times ratio would produce $318.4 billion, rather than a little over $100 billion. The lower figure in the supplied quotation therefore needs another assumption. It could describe a company capturing roughly one-third of the market at a similar multiple, or a company capturing the entire market but valued at a much lower multiple. Either is possible within a hypothetical exercise, but the distinction should be explicit. Red Hat also had products, customers and capabilities extending beyond the kernel itself. Its acquisition price cannot be treated as a simple price tag for owning Linux.
The comparison is more revealing in another respect: Red Hat’s commercial success developed around open source. Its acquisition does not demonstrate what Linux would have achieved had the source been closed. It demonstrates that customers can pay substantial amounts for reliable products and services even when the underlying software is openly licensed. A Linux business could therefore have become valuable without requiring exclusive control over the kernel. The real choice was never simply between giving software away and making money. There were, and remain, different ways to earn revenue from packaging, maintaining and operating shared technology.
Could the hypothetical valuation reach $1.5 trillion?
The second supplied comment extends the argument into the future. A representative of Investing.co.uk says: “Although the current valuation would be high, the even more impressive number would be the future valuation. The Linux market is expected to grow towards $150 billion by 2035, which could allow for a hypothetical Linux Corp valuation of as much as $1.5 trillion—roughly the value of Saudi Aramco, the Saudi Arabian oil company, or Tesla in the US.” As with the earlier quotation, this is best read as a conditional valuation exercise. The market forecast, revenue-capture assumption and valuation multiple each need to be considered separately.
There is a distinction between the published forecast and the 2035 figure. The Fortune Business Insights report underlying the $31.84 billion starting point projects $130.75 billion by 2034, with a stated compound annual growth rate of 19.3%. Extending that growth rate for one additional year produces approximately $156 billion in 2035. That makes “around $150 billion” a reasonable rounded extrapolation from this particular forecast, but it is not the report’s published 2035 estimate. It also remains a forecast rather than an established future market size. The extra year of growth is an assumption added to an already uncertain projection.
A $1.5 trillion valuation follows directly if the imagined company earns $150 billion annually and investors value it at ten times revenue. But earning that revenue would require capturing an amount equivalent to the entire assumed market. At a 25% share, annual revenue would instead be $37.5 billion, producing $375 billion at the same multiple. At a 50% share, the result would be $750 billion. A lower multiple would reduce each figure further. These examples show why market growth alone cannot establish a company valuation. The owner must capture spending, turn it into attractive cash flows and retain investors’ confidence in the business’s future.
A valuation assigned in 2035 is also different from a valuation today based on expected 2035 results. Future cash flows and an eventual sale value would need to be discounted for time and risk, with any intervening cash generation included. A company cannot simply claim its possible future market capitalisation as its present value. The comparisons with Saudi Aramco and Tesla are useful only as indications of scale: market capitalisations change, and neither company supplies a valuation model for an operating-system business. Linux Corp would need to justify its own earnings expectations, financing requirements and competitive position throughout the period leading to that hypothetical outcome.
Why closing Linux could have changed everything
The largest uncertainty comes before the valuation multiple. A proprietary Linux might never have reached a comparable level of adoption. Students could have faced different access conditions. Hardware manufacturers might have depended more heavily on a central supplier’s priorities. Businesses considering long-term infrastructure commitments might have been less comfortable relying on an operating system controlled by a potential commercial rival. Some contributors would have had less reason to donate engineering work to software whose owner could restrict its later use. None of those outcomes is certain, but they belong inside the scenario. Charging for access would have changed behaviour as well as revenue.
The company’s cost base would probably have changed too. Work contributed because it improves a shared foundation cannot automatically be counted as free labour for an exclusive owner. Linux Corp might have needed to hire more developers, fund more hardware support and negotiate more commercial partnerships itself. It could have succeeded through strong products and effective management, but that success would have required investment and execution. The open-source project’s present capabilities therefore cannot simply be transferred into a proprietary company’s balance sheet without transferring, replacing or paying for the processes that produced them. The hypothetical business would have had different development economics from the beginning.
Competition would have responded as well. Customers unwilling to accept the company’s terms could have supported another operating system or invested more heavily in an alternative shared foundation. A proprietary Linux might have become a successful specialist product, a major platform, an acquisition target or a failed business. The evidence does not identify one inevitable outcome. What can reasonably be said is that Linux’s actual success developed alongside the rights granted to its users and contributors. Any claim that Torvalds gave away a guaranteed $350 billion or $1.5 trillion company assumes away the very conditions that helped make those numbers imaginable.
The value that no single shareholder receives
The benefit of Linux is spread across people and organisations that do not appear on one shareholder register. Some receive lower costs. Others gain technical independence, educational access or the opportunity to build a product that would otherwise have been too expensive to attempt. Businesses can earn revenue from the surrounding work, and customers can choose to pay for convenience and accountability. Much of the resulting value will never appear as Linux revenue at all. A research team’s improved productivity or a small company’s ability to experiment is economically useful even when no operating-system vendor sends an invoice for it.
That is why describing Linux as a gift remains appropriate without attaching an invented price tag to Torvalds’s decision. The gift is a set of durable permissions, combined with software that people have continued to improve through decades of work. A fictional corporation could be assigned an impressive valuation under favourable assumptions. The real achievement is that access to this foundation did not have to be concentrated inside such a corporation. Linux made it possible for many participants to create value on their own terms. Its openness helped create that opportunity, and there is no sound way to assume the same opportunity would have existed without it.