I’m genuinely surprised more people don’t apply the economic concept of loss leader products to software. It’s a common economic principle that is used, but not named, within the software community already. Naming it can help us create a better paradigm for software development if it were more widely understood what tradeoffs we’re making with it. So, what is a Loss Leader in the traditional economic sense? By Wikipedia’s definition, “A loss leader is a pricing strategy where a product is sold at a price below its market cost to stimulate other sales of more profitable goods or services”.
However, in Software, I change this definition to “A Loss Leader Software is a software that is free (or pays a user) to attract a user to utilize your software so that you can nudge the user towards another product or service you can generate revenue on to continue to fund the development of both”. It’s what has led to the development of browsers, operating systems, and open-source software, and I’ll make the case that it has the potential to change how FOSS is funded, too. I’ll make this case by:
- First, introduce the concept in the context of Web2
- Next, explain how the strategy is taking hold in Web3 Wallets
- Then, describe how it’s used in open core software business models
- Finally, apply the concept to altruistically maintained open-source software
How Google funds 2 browsers, an operating system, and a search engine that they make no money on
Google’s entire business model was built on the concept of loss leader software, and it’s a strategy that took Sundar Pichai from being the leading advocate for Chrome to helping lead Android. From there, he went on to become the CEO of one of the largest companies built on loss leader software. He saw the strategy and executed it, even if he may never have called it this (I’ve not seen him call it this at least). Fundamentally, Google started as a search engine to index the Web, but it wasn’t generating any revenue for Google. Google Search started as a research project incubated at a university, and was converted to a business after finding that its research was very effective.
So to fund the development of their search engine, they added ads to the search engine results page with a product called AdWords, which generated 70 million in revenue in the first year. This ended up turning Google Search into one of the most used loss leader software because the product itself, Google Search, wasn’t self-funded in any way. People used Google Search because it was free. Had they charged for the right to use Google Search, fundamentally fewer people would have used it due to the laws of supply and demand. Of course, the quality of it mattered as well, but that quality came from being able to employ many engineers to improve their search quality. So, to fund the development of Google Search, the loss leader software at the time, AdWords was the actual product that they produced and sold to fund the development of the software, and that worked tremendously well for them. So well, in fact, that their ad product suite generates 2/3rds of Google’s revenue to fund all the other software Google builds, Mozilla builds, and much of the content found on the Web as well (via displaying Google ads on their site).
Eventually though the ability for them to grow became limited by how many users they could get to discover their site, so they made a deal with Mozilla Foundation to have Google become the default search engine of Mozilla which at the time had struggled to fund itself after finding that the original model of selling a browsing software (Netscape’s original strategy) wasn’t working leading to AOL basically paying Mozilla 3 million dollars to spin itself out and go manage the product within the foundation. So at the time, Mozilla’s crisis in July of 2003 was also an opportunity for Google in 2004. Google was also looking to grow its business by getting more eyeballs on its site. They both solved their problems through a revenue-sharing agreement. While this deal hasn’t been publicly disclosed, it can be somewhat inferred from the Google anti-trust case plus Mozilla Foundation tax filings. To give context of how much this deal is worth, $400 million was paid to Mozilla for their 2021 traffic referrals, which accounted for 80% of Mozilla’s revenue.
This is also why today, Mozilla has been making so many recent changes with AI and exploring its own ad products. Fundamentally, Firefox is a loss leader Software, but 80% of that revenue that funds it isn’t even a product they own and maintain. Which meant they were potentially up a creek without a paddle when Google’s antitrust case came to court. This was because they might not have been able to make these search deals anymore. This is also why Mozilla is on the hunt for its own revenue streams. They need to diversify their revenue to continue to fund the development of Firefox, their loss leader. Which, personally, I think is a good thing for the Web, and I hope they find it and can get themselves growing again. All good ecosystems need competition, but I digress.
What’s interesting about Google’s Ad products, though, is that it didn’t just fund Mozilla, but it also funded Google Chrome. From Google’s perspective, they didn’t like the idea that their website‘s experience was potentially controlled by Microsoft via Internet Explorer (which was being a bit abusive with their market power) and Mozilla, and that was a business risk they didn’t want to take. Especially now that they had the funds to subsidize the development of their own browser, which was their second loss leader software, but it helped them to grow search, their first, and ultimately their bottom line of revenue generated by their ads. So Google Chrome set out to build a better browser and did a wildly successful job at it. They made the Web faster and more secure.
This success led to a new problem, though, which was again that in order to further gain distribution of Google Search, Google Chrome needed to be downloaded. Whereas some of their competition, Internet Explorer and Safari namely, were built into the operating system as a default software. Unfortunately for Google, there wasn’t any assurances that they had that the other browsers would care to prioritize features that made sure the experience of Google Search remained fast and optimal to keep growing revenue from their ads product. So, this is where the Android Operating System comes in. Around the time that they were looking to grow the Web, the Web was also shifting to a mobile first experience because of the release of smartphones. The first version of Android was released just 21 days after the beta announcement of Google Chrome. Google Chrome was Google’s countermove to Microsoft’s dominance on the Web via Internet Explorer. This dominance came about by being the default browser of Windows, and it was Google’s 3rd loss leader software, but it proved to be one of the most valuable choices Google made.
See, the value of loss leader software is that they have network effects through distribution, and that distribution means that the Android operating system could eventually grow to 3.9 billion users. This enabled Google Chrome to grow to roughly 3.6 billion users (numbers aren’t exact), which meant that Google could drive that much traffic to their search engine, and ultimately fund the development of the Android operating system, Google Chrome, Google Search, Mozilla Firefox, and even much of the content on the Web today. That is because YouTube and nearly every other site rely on Google AdSense to monetize their content via that same Ads product. This is because they were able to leverage the distribution of loss leader software to nudge user behavior towards their revenue-generating products.
How Wallets are Becoming the Loss Leader Software of Web3
What I find interesting about this concept of loss leader software, though, is that it’s leaking into new parts of software development too. The most prevalent example where I’ve seen this occurring is with cryptocurrency wallets. No user inherently pays for wallet software, but it’s a very high-value piece of software that crucially helps every user of Web3 collectively secure trillions of dollars of value. So it goes without saying that every user expects this software to be secure, but in the same way that you don’t pay for a banking app, users are unlikely to pay for a wallet. So what are the revenue lines that wallets use to subsidize the development of the wallet software?
Metamask is probably the best example to look at because they’ve done a great job, in my opinion, of utilizing the distribution of their wallet to grow revenue lines. Without knowing the specifics of their business dealings, I’d venture to guess from on-chain flows that their primary source of revenue has historically been defi swaps, which, as of 2025, are estimated to have generated $325 million in revenue, which is generated by charging .875% of the total transaction volume. With estimates of 30 million MAU, which I assume includes their Metamask Institutional product, where the majority of that roughly $37.1 Billion (estimated based on fee revenue / percentage of fee) of swap volume would have come from.
However, unlike Google’s ad product, MetaMask Swap volume is highly correlated to the prices of cryptocurrencies, which means that during bear markets, it brings with it reduced market volume and revenue declines. So, in the Web3 space, this is what has led to the need for more revenue lines to grow their business, including feature integrations of other protocols that lead to financial transactions and revenue-sharing agreements. These revenue lines include product features like crypto on-ramping, staking, trading Real World Assets, betting on Prediction Markets, and options trading called “Perps”, crypto card, or their own stablecoin. Put another way, if there’s a protocol or feature that will generate revenue from fees, then a wallet in the Web3 space will probably integrate it and collect a portion of that revenue. These are the revenue generation schemes that loss leader software like cryptocurrency wallets live on in the Web3 space. This also means that there’s the potential for more middlemen in Web3 than what currently exists, depending on how these protocols get plugged in together to produce end-user journeys in the wallets.
So if the goal of Web3 is to make finance cheaper, faster, more private, and more secure than it is, it should consider the costs of the software it produces and delivers. In my opinion this should come in the form of business models that operates over a larger volume of transactions, but at a cheaper cost per transaction. I personally believe the market-based transaction fees networks use for gas rather than variable percent transactions is Web3’s core innovation to date. This will end up leaving more in the users’ pockets and get more users switching to Web3 if protocols can also adopt similar fee models. We’ll then have an opportunity to capture large amounts of transaction volume by undercutting the variable fee paradigm currently used whenever possible. And growing the volume means growing the revenue we generate faster for the businesses that build this software.
Is “Open Core” software also a loss leader software?
What’s interesting beyond traditional products is the concept of open source software, which also operates as loss leader software. What open core means is that some portion of a software product exists as open source software to entice users or developers to integrate and build upon it, but then key features or hosting services are operated and maintained at an additional cost. In this way, technically, the primary cost of the software production and maintenance is not revenue-generating. Technically minded folks can essentially take a copy of the software and do what they want with it, including extending it, which is valuable for the open core software business.
On the other hand, they can fork it and compete with it, which is good because it also extends the software or its features to expand the market. However, it’s bad because it potentially creates a new competitor who can steal their market share. So, how do open core business models fund the cost of this free development? They typically subsidize it by building proprietary features on top of it or charging to maintain and host that software instead. Today, Google Chrome is technically an open-source product of Chromium. The primary difference between Chromium and Google Chrome is that Google Chrome serves the interests of Google solely through the collection of more user data beyond just Google sites, so they can personalize their ads better. On the other hand, Chromium is an open source project and serves the interest of the Web primarily (it’s complicated to justify this, so I’ll leave the exercise to the reader).
Some other good examples of open core business models are MongoDB which is an open source project that was originally licensed under AGPL v3 before 2018 and then it was changed to Server Side Public License which was a response to Amazon Web Services contributing little back to the majority to the maintainance of the open source project while doing a good job monetizing it with Amazon DocumentDB and hosting MongoDB Atlas. This introduced a tragedy of the commons problem, and so the license was changed to make sure that enough revenue flowed back to MongoDB, the company, to fund the development of MongoDB, the product.
Another interesting example of this is TailwindCSS, which actually developed both the loss leader software and used their docs to nudge people towards their premium products to monetize the framework with products like Tailwind UI, Tailwind Play, and Enterprise Templates. The struggle with this approach is that when AI came about, it changed how developers gather information about the CSS framework, and meant there was less opportunity to monetize it. This ultimately led to a negative impact on their business because while the TailwindCSS framework was growing substantially, it was becoming harder for them to fund the development, and ultimately led to them being able to put less income into the hands of the developers maintaining that software.
How does this apply to Altruistic OSS?
First off, what do I mean by Altruistic OSS? I use this term to distinguish software that is maintained as a hobby or via sponsorships like GitHub sponsors, and does not have a sustained revenue model. Many people will likely know this under the “Free Open Source Software” movement, but I don’t like the term “free” because the developers who produce and maintain that software are still paying with their time and expertise. I don’t even like the term “free” for the consumer because often this absence of payment is paid for either with time by the end user with bugs or less prioritized software, which is more than understandable. The maintainer still has to feed themselves, pay for their entertainment, and afford their lives.
There are many different pieces of software like this, including projects like the Linux Kernel. While there are massive businesses that have been built on this project, they don’t have direct influence over the ability to nudge users towards their revenue lines. Yet, there’s an entire economy built on the production, maintenance, and deployment of the Linux kernel. Whether it’s from Canonical with Ubuntu or Linux Foundation events that train people how to use the software or build on it, but charge for ticket sales. But is there another way?
In my mind, I think there is for software like OSS software distributed through package managers like NPM, Rust crates, or PyPI. While much of the software distributed through these package managers falls under the FOSS principle, it still bears a burden to those who rely upon it. As a perfect example, I help bump the dependencies of open source software we rely on in Brave Browser. It is substantially cheaper for us to rely on a package that properly uses semantic versioning, handles security bumps promptly, and is responsive to feature requests or pull requests that I submit to make it easier for us to rely upon these dependencies. So that’s what these maintainers can be charging for, and it could be the package manager’s role to serve as the store, the payment provider, dispute arbitrator, and distributor of the software, charging a fee for it.
Should we accept the costs that come from this business model?
I’m sure there are other opportunities to generate profit centers that align with the principles that FOSS was built on as well. The question is, will the “free” side of OSS accept that they still face the burden of costs to produce, maintain, deploy, and support the software? In conclusion, the concept of loss leader software is a widely pervasive model for producing software that is widely accessible and still profitable. It’s been used for decades now and will likely continue much further beyond. I suspect we’ll see similar economic models continue to emerge from AI and whatever comes beyond it because the power of software is that the cost per unit of producing new software is the same for 1 user or 1 billion users. The cost of producing, maintaining, deploying, and supporting the software scales slightly differently, but these costs are often baked into the profit centers as long as one exists. So the question in my mind is, should we accept the tradeoffs that come with loss leader software such as “enshitification” or “bloatware” to offset the costs of “free to use” software? Is there a better way to handle these legitimate costs that exists so that as many people can continue to have access to software and information equitably while still being able to fund the software development lifecycle?
Thank you to @Cyph3rVae, @FryCookVC and @gnukeith for the review and feedback here.