Open vs. Closed Technology: Approaches to Maximizing Enterprise Value and Social Impact

Introduction

Releasing technology you developed in-house—as open source, for example—can drive adoption in a short time, but it also invites a crowd of competitors offering similar services. Get the decision right and it can accelerate the growth of your own service. But how should you go about making that call?

From society's point of view, making new technology public benefits a great many engineers and researchers. Yet if disclosure means inventors can no longer profit from their work, the incentive to invent shrinks—and innovation, paradoxically, becomes less likely.

In this article, we organize the degree of technological openness into nine levels, ranging from "fully open" to "fully closed," and lay out success stories and cautionary tales at each level. We then set out a way of thinking about how to maximize corporate value and social utility, drawing on recent academic research and the insights of practitioners.

Openness Is Defined by Two Axes: Disclosure and Permission

First, a basic premise: the openness of a technology is not really a single axis. It is made up of two.

The disclosure axis: how much of the technology's inner workings you reveal. This is the degree of information disclosure—whether you publish the source code and technical specifications, expose only the observable behavior, or keep everything secret.

The permission axis: how much use you allow. This is the degree of usage rights—whether you permit commercial use, modification, redistribution, and even competing services; restrict use to non-commercial purposes; or reserve implementation exclusively for yourself.

Patents are a good illustration. A patent discloses the technology in full (applications are published 18 months after filing), yet the right to practice it remains exclusive for roughly 20 years. In other words, it combines maximum disclosure with minimum permission. The nine levels below are ordered by overall "openness," taking both axes together.

The Nine Levels of Technological Openness

Level 1: Fully Open

Description: This covers rights waivers such as CC0 and the Unlicense, together with permissive licenses such as MIT, Apache 2.0, and BSD. The source code is published, and commercial use, modification, redistribution, and even incorporation into closed products are permitted almost unconditionally (only attribution is required). Apache 2.0 includes an explicit patent license grant, which makes it well suited to corporate use.

Terms of use: Little more than attribution (preserving the copyright notice). Modified versions may freely be built into commercial products without being published.

Typical purpose: Maximizing adoption and establishing a de facto standard. Peripheral technologies you don't mind others absorbing—SDKs, data formats, connectors—are opened up to grow the ecosystem.

Success stories: Android (AOSP) opened up the core operating system under Apache 2.0, expanding the entire smartphone market, while Google monetized through the closed layers on top (the Play Store, advertising, and GMS licensing). React, VS Code, and Kubernetes likewise spread under permissive licenses and channel value back into their sponsors' core businesses—cloud, recruiting, and platforms.

Cautionary tales: 1. Docker released its container technology under a permissive license and became the industry standard as a technology. But because the core was completely open, most of the value flowed to Kubernetes (led by Google) and to the managed services of the cloud providers, and Docker itself failed to monetize. In 2019 it ended up selling its enterprise business to Mirantis. It is the single most important example of how "technological success" and "business success" are two different things. 2. OpenSSL, on which most encrypted communication on the internet depends, was being run on a single full-time developer and roughly $2,000 a year in donations when the critical "Heartbleed" vulnerability came to light in 2014. It is a textbook case of the free-rider problem—a public good anyone can use for free, and no one pays for—and it became the catalyst for serious research into the sustainability of open source (Eghbal, 2020).

Level 2: Weak Copyleft

Description: An intermediate type of license that requires you to publish modifications to the files or library components themselves, while allowing the combined product as a whole to remain closed.

Terms of use: As long as modifications to the covered components are published, the code can be built into commercial closed-source products.

Typical purpose: A compromise for cases where you want improvements contributed back but don't want to obstruct commercial integration. Well suited to libraries and components.

Success stories: Firefox (MPL) established itself as a credible alternative to monopoly in the browser market. LGPL-licensed libraries such as glibc have become de facto shared infrastructure precisely because they are so widely embedded in commercial software.

Cautionary tale: Symbian, the Nokia-led smartphone OS, was fully open-sourced under the EPL (a weak copyleft license) in February 2010—after it had already fallen behind Android and iOS. By November of that year, the Symbian Foundation announced it was ceasing operations, and in 2011 Nokia itself ended open-source distribution. The episode showed that opening up after you have lost competitiveness gives ecosystem participants no reason to invest. Going open is an offensive move; it cannot be used to manage a defeat.

Level 3: Strong Copyleft

Description: Licenses that require the source code of the entire derivative work to be published. This prevents competitors from folding your improvements into closed products and monopolizing them.

Terms of use: Commercial use is unrestricted, but anyone distributing a product that contains GPL code must publish the source for the whole thing.

Typical purpose: Preventing free-riding and ensuring improvements flow back to the community. Used as the foundation for community-driven projects and for dual licensing (selling a commercial version alongside the GPL version).

Success stories: Linux (GPLv2) is the most successful open-source project in history and the foundation of servers, cloud, and embedded systems alike. Red Hat, which monetized by supporting Linux distributions, was acquired by IBM in 2019 for roughly $34 billion—one of the highest valuations ever achieved by an open-source company. QGIS (GPL) has likewise won a share of the geographic information systems market that rivals commercial software.

Cautionary tale: After Oracle's acquisition, the OpenOffice.org community lost trust in how the project was being run and forked it as LibreOffice (2010), taking the majority of developers and users with them. Even under an open license, a single company that monopolizes governance and forfeits community trust can end up losing control of the project altogether.

Level 4: Network Copyleft

Description: Licenses that extend the GPL's publication requirement to software delivered as a service over a network (SaaS). They prevent cloud providers from offering a modified version as a service while keeping their changes secret. This is the most defensive of the OSI-approved open-source licenses.

Terms of use: Anyone offering a service built on AGPL code must publish the source, including their modifications. It is typically paired with a "dual licensing" strategy that sells a commercial license to companies wishing to avoid that obligation.

Typical purpose: Maintaining code transparency while deterring resale by the cloud giants and steering them toward paid commercial licenses.

Success stories: Adopted by Grafana, MongoDB (in its early years), Nextcloud, and others. After facing criticism over its 2024 move to a non-open-source license, Redis returned to open source under AGPLv3 in May 2025 (Redis 8). The AGPL is being re-evaluated as a pragmatic way to "stay open while staying protected."

Cautionary tale: MongoDB used the AGPL for many years, but concluded that it was not enough to deter cloud providers from commercializing the software and moved to the more restrictive SSPL in 2018. The very next year, in 2019, AWS announced "DocumentDB," its own independent implementation of a MongoDB-compatible API. This exposed a structural limit of license-based defense: a license can restrict copying of code, but it cannot restrict compatible implementations of a protocol or API developed in a clean room.

Level 5: Source-Available with Competition Restrictions

Description: Licenses under which the source code can be read, modified, and used for many purposes, but which explicitly prohibit offering it as a competing service. By the OSI's definition, these are not open source. The BSL (Business Source License) has a time-limited structure that automatically converts the code to open source after a set period (at most four years).

Terms of use: Broad freedom for internal use and development, but offering the software itself to third parties as a commercial service is prohibited (or requires a commercial license agreement).

Typical purpose: Preserving transparency and the freedom to self-host while protecting revenue from "free-riding resale" by cloud providers.

Success stories: MariaDB (which created the BSL), Sentry, CockroachDB, and others have adopted this model and sustained their businesses on it. MongoDB has maintained a high stock-market valuation since moving to the SSPL, showing that the approach can deliver results as a means of revenue defense.

Cautionary tales: In August 2023, HashiCorp switched Terraform from the MPL to the BSL—and just two weeks later, the community forked it as OpenTofu, which grew rapidly under the Linux Foundation (in a user survey, 38% said they were considering alternatives). Redis, too, saw the Valkey fork emerge within a week of its March 2024 move to the SSPL, and after the backlash it returned to the AGPL in May 2025. On top of that, because the SSPL is not OSI-approved, Redis was removed from major distributions such as Debian and Fedora, costing it the distribution channel itself. Academic research has shown that these forks built communities with greater organizational diversity than the original projects (arXiv:2411.04739, 2024). The lesson: closing something that was once open may be legally possible, but it is a high-risk decision that damages the community you have built as an asset.

Level 6: Non-Commercial or Conditional Release

Description: Licenses that publish the source code or model but restrict use to non-commercial or research purposes, or attach specific conditions based on the scale or nature of use (CC BY-NC, research-only licenses, the bespoke "community licenses" attached to AI models, and so on).

Terms of use: Individuals and researchers may use the technology freely, but commercial use requires a separate agreement or the fulfillment of specific conditions.

Typical purpose: Opening up to researchers and individual developers to earn reputation, feedback, and an ecosystem, while steering all commercial use toward paid arrangements.

Success stories: With its "open-weight" strategy (published weights, conditional use), Meta's Llama series rapidly built an ecosystem that rivals closed, API-only models. In academic software, too, the dual-track model—free for research, paid for commercial use—has proven to be a sustainable source of revenue.

Failure case: The original LLaMA was released under a "researchers only, by application" conditional model, yet within a week of release its weights leaked to 4chan and became downloadable by anyone. This exposed the fact that conditional distribution cannot be technically enforced, and Meta changed course: starting with Llama 2 (July 2023), it switched to distributing broadly from day one under a "community license" permitting commercial use. In other words, Llama's current open-weights strategy was itself born from the failure of strict Level 6 operation (research-only). And even Llama retains bespoke terms such as "companies with more than 700 million monthly active users must sign a separate agreement," which corporate legal teams dislike; cases have been observed of companies choosing Apache 2.0-licensed Mistral or Qwen instead, so the complexity of the conditions has itself become a barrier to adoption.

Level 7: Patents

Description: A system in which the technology is fully disclosed in exchange for roughly 20 years of exclusive rights to practice it. Once the term expires, anyone may use it freely, so patents can be viewed as a time-limited structure that is "forced open after a set period."

Terms of use: Permission from the patent holder (a license agreement) is required. Standard-essential patents carry an obligation to license on FRAND terms (fair, reasonable and non-discriminatory).

Typical purpose: Protecting technology that can easily be uncovered through reverse engineering (mechanisms, manufacturing methods and algorithms that are evident on inspection). The principle is: "if it will be analyzed even when hidden, disclose it and protect it legally." Other applications include defensive filings, cross-licensing and licensing revenue.

Success cases: Qualcomm has made a licensing business built on standard-essential patents for communications standards a pillar of its revenue. The pharmaceutical industry is the archetypal model of recouping enormous R&D investment on the premise of patent-based, time-limited exclusivity (Arora et al., 2001).

Failure case: Kodak held a portfolio of roughly 1,100 patents, including fundamental digital camera patents, which before its collapse was valued at $2.2–2.6 billion. Yet after its bankruptcy in 2012, the portfolio sold for just $525 million. This showed that even when technology is disclosed and monopolized through patents, the value of the patents themselves plummets once the complementary assets—manufacturing, sales, brand—and the business model needed to convert them into commercial value are lost. It is a real-world instance of the proposition theorized by Teece (1986): the profits from innovation flow to whoever holds the complementary assets.

Level 8: Closed Source + API

Description: A model in which the source code stays private and only the functionality is offered, as a product, API or SaaS. The internal implementation is not shown, but use is broadly permitted.

Terms of use: Use within the scope of the terms of service or API agreement. No access to or modification of the implementation.

Typical purpose: Maximizing users and revenue while keeping the implementation and data confidential. The majority of commercial software and API-delivered AI models take this form.

Success cases: This is the mainstream of today's high-margin software businesses: the API-delivered models of OpenAI and Anthropic, SaaS offerings such as Salesforce, and Apple's iOS (the core is private, while developers are given an SDK).

Failure case: In the format war over home VCRs, Sony was reluctant to license Betamax, whereas JVC licensed VHS widely, grew its camp and won the market (Cusumano et al., 1992). This is the classic case in which the outcome of a standards battle was decided not by technical superiority but by the difference in openness—and it shows that in markets where network effects operate, staying closed can be the greatest risk of all.

Level 9: Fully Closed

Description: A model in which the technology is neither published nor filed for a patent, but managed as a secret. As long as secrecy is maintained, the protection period is indefinite—the exact opposite trade-off to a patent.

Terms of use: Practiced only by the company itself. A secrecy management regime—NDAs, access controls and the like—is a prerequisite for legal protection.

Typical purpose: Indefinitely protecting things that are hard to reverse-engineer (server-side logic, training data, manufacturing know-how, customer data).

Success cases: The classic examples are Coca-Cola's syrup recipe (kept secret for more than 130 years) and Google's search ranking algorithm. Where a patent would expire after 20 years, these companies have turned trade secrets into an indefinite advantage.

Failure case: While trade secrets are protected indefinitely, they are vulnerable to leaks. The lawsuit alleging that a former executive carried Waymo's autonomous driving trade secrets to Uber ended in a settlement of stock worth roughly $245 million (2018). A trade-secret strategy only works when paired with ongoing investment not in the technology itself but in the secrecy management regime: talent retention, access controls and contracts.

How to Think About Maximizing the Value of a Service or Company

So which parts should be open and which closed? Broadly speaking, enterprise value is determined by "market and revenue growth potential × defensibility of profits (moat) × capital efficiency of growth"—and a disclosure strategy affects all three.

There is just one principle to start from: "Close what you sell (substitutes); open what drives its use (complements)." The cheaper or freer the complements become, the more demand grows for the core product (your revenue source). So you deliberately open up the "adjacent layer" to your revenue source, expand the whole market, and collect at the core. This idea, which practitioners call "commoditizing your complements" (Spolsky, 2002), is the logic behind Google's structure of giving Android away for free and collecting through advertising and apps. Below, we make this principle concrete in terms of "what to open and what to close."

What to Open

Layers that create adoption and standardization without threatening your own revenue source should be opened. They include the following.

• Core functionality and engines: The parts where there is value in many people using them and in their becoming the standard.

  • Chromium (Google): Opened the browser engine itself. It became the shared foundation for Chrome, Edge and Brave, and gave Google the lead in Web standards.

  • GitLab Community Edition: The complete core of Git management and CI/CD can be deployed on your own servers free of charge.

  • PostgreSQL / Elasticsearch / Docker Engine: The "standard engines" for databases, search and containers.

  • PyTorch (Meta): Became the shared foundation for machine learning, feeding back into Meta's recruitment of researchers and engineers and its own AI development capability.

• File formats, protocols and API specifications: Other companies' tools come to you to connect on your terms.

  • PDF (Adobe): The specification was published and standardized through ISO. Making it a format anyone could read turned it into the de facto standard for documents.

  • S3 API (Amazon): The storage API specification became the de facto standard, creating a structure in which competitors come to conform, marketing themselves as "S3-compatible."

  • OpenAI API specification: So standardized that many LLMs now implement "OpenAI API compatibility."

  • IFC: The international standard for BIM.

• SDKs, connectors and integration components: Complements—the more of them there are, the more the core product gets used.

  • Stripe's SDKs: Published free libraries in every major language that let developers embed payments with a few lines of code, winning over developers en masse.

  • Slack / Twilio SDKs and APIs: Expanded their ecosystems with official libraries that let external apps connect.

  • Terraform providers: Opened the connectors to each cloud, creating a structure in which the core product becomes more valuable with every additional supported target.

• Basic features for individuals and developers: A free entry point that broadens the base.

  • Free plans of GitHub / Notion / Figma / Slack: Free for individuals, paid for team and enterprise features (freemium).

  • Docker Desktop: Free for individuals and small organizations, paid for companies above a certain size.

  • Gurobi's free academic version: People who grew accustomed to it as students become the champions of full license adoption at their employers.

The benefits are as follows.

• Dramatically lower customer acquisition costs: Because developers adopt and spread the product on their own without going through sales, the same growth can be achieved at lower cost, raising capital efficiency (the source of the high equity valuations of open-core companies such as GitLab, HashiCorp and Confluent).

• Building a moat through de facto standardization and network effects: A kind of barrier to entry that closed code cannot create (Kubernetes, Linux).

• Eliminating lock-in concerns: Removing the fear of being locked into a particular vendor lowers adoption barriers in large enterprises and the public sector.

• Recruiting brand and R&D leverage from external contributions: Empirical research shows that companies that not only "use" OSS but "contribute" to it extract greater productivity from that OSS (Nagle, 2018, 2019).

What to Close

The revenue source itself and the core of your competitive advantage should be closed. They include the following.

• The revenue source itself (managed operation and hosted versions): If your core business is selling relief from operational burden, don't open this.

  • GitLab.com / MongoDB Atlas / Databricks: Even with the software itself open, the "service that runs it for you" is kept entirely proprietary. Atlas is the pillar of MongoDB's revenue, and no one is allowed to replicate it.

  • WordPress.com (Automattic): Anyone can self-host the core for free, but the business of selling hosting plus maintenance is closed.

  • Red Hat Enterprise Linux subscriptions: Linux itself may be GPL, but Red Hat charges for an "operations package" of certified builds, long-term support and guarantees.

• Features for organizations and enterprises (SSO, permission management, audit logs, compliance, support/SLAs): Technically simple, but the people who want these are the ones who pay. This is where you charge.

  • GitLab Enterprise Edition: SAML/SSO, fine-grained permission management, audit logs and compliance features are limited to the paid edition. The textbook example of where to "draw the line" in open core.

  • Mattermost / Sentry: The core is open; SSO, advanced permissions and audit features are in the enterprise edition. This practice is so entrenched that the industry calls it the "SSO tax" (there is even a site, sso.tax, that publishes a list of what companies charge for SSO).

  • Grafana Enterprise: The core is open under AGPL; the company charges for enterprise data source connections, reporting and support SLAs.

• Core logic where the competitive advantage lies in the code itself: The parts where disclosure would directly enable imitation.

  • Google's search ranking algorithm: Google opens Chromium and Android, but never discloses any of the logic that determines search rankings—the core of its main business.

  • Netflix's recommendation engine: Netflix has open-sourced many infrastructure tools (Chaos Monkey and others), but the core of its viewing recommendations stays private.

  • The trading algorithms of high-frequency trading (HFT) firms: Kept completely secret, because disclosure would mean the instant disappearance of their edge.

• Proprietary data, trained models, operational know-how, and customer base: the hard-to-imitate "complementary assets."

  • OpenAI / Anthropic frontier model weights and training data: usage is opened up via API, but the model itself and the training pipeline are kept secret (a combination of Levels 8 and 9).

  • Google Maps' map and traffic data: the API is open, but the data assets themselves, accumulated over 20 years, are never handed over to anyone.

  • Amazon's purchase data and review platform: self-reinforcing through network effects, this is the hardest complementary asset of all to imitate.

  • Bloomberg's financial data and terminal user network: the combination of data plus customer base means that copying the features alone will never let a rival catch up.

An Open-or-Closed Decision Checklist

For each individual feature, running through the following five questions is enough to reach a decision.

1. Defensibility test: Is it the source of your competitive advantage? → Close

2. Adoption test: Would opening it increase users and integration partners? → Open

3. Liability test: Would an error create legal or professional liability? → Close

4. Buyer test: Is it a feature the paying customer demands (SSO, audit logs, support, SLAs)? → Close

5. Resale test: If opened, could competitors or the cloud giants resell it as-is? → Close (or protect it with a defensive license such as AGPL or BSL)

The rule of thumb: if a feature meets any of the defensibility, liability, buyer, or resale tests, close it; if it meets only the adoption test, open it.

How Open Is Optimal for Society?

So far we have discussed how far a company should open up its technology to maximize its own value. But what about society as a whole—should technology be open or closed?

In short, the optimal answer for society is likewise neither fully open nor fully closed. It is a deliberately managed mix that permits temporary closure and ultimately returns technology to the open domain—and when this framework works, maximizing corporate profit coincides with maximizing social benefit.

• The ideal price of knowledge is "zero"—but at that price no one would create it: Knowledge and technology have the character of "public goods": once created, they can be used by any number of people at almost zero additional cost (Arrow, 1962). Looking at this property alone, the socially optimal outcome is complete openness, with everyone using them for free. But then developers could never recoup their investment, and innovation would not happen in the first place. "Letting existing technology be used as widely as possible" (static efficiency) and "protecting the incentive to create the next technology" (dynamic efficiency) are structurally locked in a trade-off (Nordhaus, 1969).

• The patent system is society's "bargain" for resolving this dilemma: Society resolves the dilemma through a trade: "we grant a monopoly for a limited period; in exchange, you fully disclose the technology, and once the period expires, anyone may use it." This is the patent system. The roughly 20-year term of protection was designed as the balance point between the harms of monopoly and the incentive to innovate, and antitrust law is the corrective mechanism for when that equilibrium tips too far toward "perpetual monopoly by a single company." In other words, of the nine levels laid out in this article, society has institutionally settled on "Level 7 (disclosure with a time-limited monopoly)" as its default compromise.

• "Profit maximization = social optimum" does not hold automatically: This arrangement is only a "second-best" solution; left to themselves, corporate choices drift away from the social optimum in two directions. First, companies do not open up enough. Much of the benefit of publishing a technology (knowledge spillovers) cannot be captured by the publishing company itself, so the amount of openness companies voluntarily choose is systematically less than the level society would want. Second, monopolies sometimes fail to disappear. The classical assumption that "technology becomes obsolete and profits are naturally competed away" does not hold in digital markets where network effects and self-reinforcing data loops are at work; instead, advantages strengthen over time in a "winner-take-all" dynamic.

• Nor is stronger IP always better: Overly strong protection backfires. Because technology is cumulative—built on the achievements of those who came before—granting excessively strong rights to early inventors blocks the follow-on innovation that would be built on top of them (Scotchmer, 1991). The relationship between innovation and IP strength is not monotonically increasing; there is an optimum, and its location varies by industry (the classic contrast is pharmaceuticals, where strong patents work, versus software, where patents can actually act as an impediment).

• Society calibrates openness differently by domain: The overall design of society can be summarized as follows. Basic research, where knowledge spillovers are large and appropriation is difficult, is supplied almost entirely in the open through public funding and published papers. Commercial development, where investment will not happen without appropriability, is permitted temporary, partial closure through patents and trade secrets. And where a monopoly looks likely to become entrenched, society pulls things back toward openness through antitrust law, the disclosure requirements and time limits built into patents, and the promotion of standardization and interoperability.

• Profit is not the only motive for innovation: Finally, none of this means that "monopoly profit is the sole source of innovation." As open source and open science demonstrate, contributing to public goods and capturing private benefits (learning, reputation, career, improvements to one's own products) can go hand in hand—something established both theoretically and empirically (von Hippel & von Krogh, 2003; Nagle, 2018)—and social infrastructure such as Linux and OpenSSL has been created without relying on monopoly profit. Society supplies innovation by combining "profit motives" with "other motives" (wanting to use the thing oneself, honor and reputation, a sense of mission, the desire to learn, and so on).

Trends in Recent Academic Research

Research on technology disclosure strategy is advancing along four broad lines.

Quantifying the Economic Value of OSS

• Demand-side value has been estimated at $8.8 trillion: A Harvard Business School research team estimated the supply-side value of widely used OSS (the cost to recreate it) at $4.15 billion and its demand-side value (what companies would have to spend to develop substitutes) at $8.8 trillion. Without OSS, firms' software spending would need to be 3.5 times its current level. The study also revealed an extreme concentration in value creation: 96% of demand-side value is generated by just 5% of developers (Hoffmann et al., 2024).

• Sustainability as a public good has become a policy issue: Since OpenSSL/Heartbleed, research into sustainability—"who supports the foundational OSS on which every industry depends?"—has advanced, and the design of funding mechanisms from companies and governments (such as the Sovereign Tech Fund) is being debated in both practice and policy (Eghbal, 2020).

Monetization Strategies and the Consequences of License Changes

• Empirical research on license changes and forks has advanced: Studies analyzing community structure after the wave of license changes in 2023–2025 (Terraform→OpenTofu, Redis→Valkey, Elasticsearch→OpenSearch) found that forks created under neutral foundations (such as the Linux Foundation) acquire a contributor base with greater organizational diversity than the original projects (arXiv:2411.04739, 2024). This provides quantitative support for the governance risk inherent in projects controlled by a single company.

• The ambiguity of "open" and the theory of partial openness: West (2003) theorized that platform companies adopt hybrid strategies of "partial openness" that sit between full openness and full proprietary control, and Dahlander & Gann (2010) organized "openness" in open innovation into four types along the dimensions of direction (inbound/outbound) and pecuniary nature (paid/free). The recent emergence of BSL/SSPL can be read as this design space of "partial openness" being subdivided even further through the invention of new licenses.

Corporate Contribution Behavior and Productivity

• Companies that "contribute" gain more than those that merely "use": Nagle (2019) empirically showed that among companies using OSS, those that contribute code derive greater productivity gains from the same OSS than those that do not (learning by contributing). This finding—that contributing to a free public good generates private returns—corroborates at the firm level the "private-collective innovation model" proposed by von Hippel & von Krogh (2003), which holds that contributing to public goods and capturing private benefit are compatible.

• The relationship between platform openness and innovation: Boudreau (2010) decomposed platform openness into "granting access" and "devolving control," and showed that opening up access greatly increases innovation, whereas the effect of going so far as to devolve control is limited. Outcomes depend not only on "how far to open" but on "what to open (access or control)."

New Issues in the AI Era

• The emergence of a new category: "open weights": In AI models, "open weights"—releasing only the model weights, under conditions, while keeping training code and data secret—has emerged as an intermediate form that does not fit conventional OSS definitions, and research into its economic effects and safety is advancing rapidly. The binary of source code (open/closed) is being replaced by multilayered openness design across data, weights, code, and APIs.

• AI training use is reshaping license design: Copyright disputes over the use of public code and content for AI training have become a new motive for license changes since 2024, and the merits of a new kind of conditional design—"open to humans, closed to AI training"—are being debated from both legal and economic perspectives.

Conclusion

We have organized the open-versus-closed question into nine levels and laid out the appropriate way of thinking for both companies and society. In conclusion, maximizing corporate value calls for neither full openness nor full closure, but for selective openness (the open-core model): "open the layers that generate adoption and standardization, close the sources of revenue, and protect the open layers from resale with defensive licenses."

The optimal answer for society, too, is a deliberately managed mix that permits temporary closure and ultimately returns technology to the open; when this arrangement functions, maximizing corporate profit can be brought into alignment with maximizing social benefit.

References

• Arora, A., Fosfuri, A., & Gambardella, A. (2001). Markets for technology: The economics of innovation and corporate strategy. MIT Press. (A work that systematizes the conditions under which "markets for technology" emerge through patents and licensing, and how the disclosure and trading of technology affect corporate strategy.)

• arXiv:2411.04739. (2024). The new dynamics of open source: Relicensing, forks, & community impact. (An empirical study of three cases—Terraform/OpenTofu, Redis/Valkey, and Elasticsearch/OpenSearch—showing that the forks created after license changes developed communities with greater organizational diversity than the original projects.)

• Boudreau, K. (2010). Open platform strategies and innovation: Granting access vs. devolving control. Management Science, 56(10), 1849-1872. (Breaks platform openness down into "granting access" and "devolving control," and empirically demonstrates that the two have different effects on innovation.)

• Casadesus-Masanell, R., & Ghemawat, P. (2006). Dynamic mixed duopoly: A model motivated by Linux vs. Windows. Management Science, 52(7), 1072-1084. (A theoretical study that builds a dynamic model of a market in which free open-source software and commercial software coexist, and analyzes the equilibrium of this mixed competition.)

• Chesbrough, H. (2003). Open innovation: The new imperative for creating and profiting from technology. Harvard Business School Press. (The book that introduced the concept of "open innovation"—the flow of knowledge into and out of a company across its boundaries.)

• Cusumano, M. A., Mylonadis, Y., & Rosenbloom, R. S. (1992). Strategic maneuvering and mass-market dynamics: The triumph of VHS over Beta. Business History Review, 66(1), 51-94. (A classic case study of the VHS-versus-Betamax format war, showing that the outcome was decided not by technical superiority but by open licensing strategy and coalition-building.)

• Dahlander, L., & Gann, D. M. (2010). How open is innovation? Research Policy, 39(6), 699-709. (Organizes "openness" in innovation into four types along two axes—direction and whether money changes hands—and reviews the benefits and costs of each form.)

• Eghbal, N. (2020). Working in public: The making and maintenance of open source software. Stripe Press. (A practitioner-oriented study of how open-source software is actually built and maintained, revealing its dependence on a small number of maintainers and the resulting sustainability challenges.)

• Hoffmann, M., Nagle, F., & Zhou, Y. (2024). The value of open source software. Harvard Business School Working Paper 24-038. (Estimates the supply-side value of widely used open-source software at $4.15 billion and its demand-side value at $8.8 trillion, and shows that 96% of that value originates from just 5% of developers.)

• Lerner, J., & Tirole, J. (2002). Some simple economics of open source. Journal of Industrial Economics, 50(2), 197-234. (A foundational paper that uses the economics of signaling and career-building to explain why developers contribute to open-source software for free.)

• Nagle, F. (2018). Learning by contributing: Gaining competitive advantage through contribution to crowdsourced public goods. Organization Science, 29(4), 569-587. (Empirically demonstrates the mechanism by which contributing to a public good—open-source software—translates into competitive advantage for the contributing firm itself.)

• Nagle, F. (2019). Open source software and firm productivity. Management Science, 65(3), 1191-1215. (An empirical study of the relationship between the use of and contribution to open-source software and firm productivity, showing that firms that contribute earn higher returns.)

• Spolsky, J. (2002). Strategy letter V. Joel on Software. (A practitioner's essay that lays out the complement strategy in plain terms: "smart companies try to commoditize their products' complements.")

• Teece, D. J. (1986). Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy. Research Policy, 15(6), 285-305. (One of the most important works in technology strategy, identifying the conditions under which the profits from an innovation flow not to the inventor but to the owners of complementary assets.)

• von Hippel, E., & von Krogh, G. (2003). Open source software and the "private-collective" innovation model: Issues for organization science. Organization Science, 14(2), 209-223. (Presents the "private-collective" innovation model, in which contributing to a public good and capturing private benefits are compatible.)

• West, J. (2003). How open is open enough? Melding proprietary and open source platform strategies. Research Policy, 32(7), 1259-1285. (Analyzes the conditions under which platform companies adopt a hybrid strategy of "partial openness" that sits between full openness and proprietary control.)