In 1991, a Finnish university student posted a message online: "I'm doing a (free) operating system, just a hobby, won't be big and professional like GNU."[1] That student was Linus Torvalds, and the operating system became known as Linux. Over thirty years later, Linux runs 96.3% of the world's top servers, 100% of supercomputers, and over 70% of smartphones (through Android).[2] Microsoft CEO Satya Nadella once declared "Microsoft loves Linux" — a statement that would have been considered heresy twenty years prior.[3]

Open source software used the incredible pricing strategy of "free" to completely reshape the landscape of the software industry. But "free" was never truly free — it merely shifted costs elsewhere. When that shifting mechanism breaks down, crisis emerges.

I. The Economics of Free: Why "Zero" Can Defeat "Premium"

1.1 The Marginal Cost Revolution in Software

To understand why open source software can sweep the market at zero cost, one must first understand the cost structure of the software industry.

Traditional physical goods follow the law of increasing marginal costs: manufacturing the one-millionth car doesn't cost much less than the first (raw materials, labor, and logistics all cost money). But software is different — developing the first copy of code requires massive investment in human resources and time (extremely high fixed costs), while the cost of copying and distributing it approaches zero (extremely low marginal costs).[4]

This cost structure implies that the "natural" pricing tendency for software is free. Once development is complete, the cost of selling one additional copy is virtually zero, so theoretically the price can be driven infinitely downward. Microsoft was able to maintain high prices by relying on "artificial scarcity" — using patents, copyrights, licensing agreements, and other legal tools to create a scarcity that doesn't actually exist.[5]

Open source software breaks through this artificial scarcity. When source code is publicly available and anyone can copy and modify it, "scarcity" vanishes, and the price naturally returns to marginal cost — that is, zero.

1.2 Network Effects and the Battle for Standards

The free strategy works also because the software market exhibits powerful "network effects": the more people use a particular piece of software, the greater its value to each user.[6]

Take programming languages as an example: Python is powerful not just because of its clean syntax, but because it has an enormous package ecosystem (PyPI hosts over 500,000 packages).[7] These packages are the result of contributions from developers worldwide. Once Python established this ecosystem advantage, latecomers found it nearly impossible to catch up — even if they designed a better language, they would lack the supporting packages and community.

Open source software is particularly adept at leveraging network effects. Because the code is open, anyone can contribute improvements, develop plugins, and write documentation. This "crowdsourced" development model allows open source projects to accumulate vast functionality and ecosystems at costs far lower than commercial software.[8]

1.3 Chris Anderson's "Free" Economics

Chris Anderson, former editor-in-chief of Wired magazine, systematically analyzed digital-age "free" business models in his book Free: The Future of a Radical Price:[9]

  • Cross-Subsidies: Product A is free, Product B is paid. Example: Gillette gives away razors and sells blades.
  • Advertising: Content is free, advertisers pay. Example: Google, Facebook.
  • Freemium: Basic version is free, advanced features are paid. Example: Spotify, Dropbox.
  • Gift Economy: Creators contribute for free, gaining reputation or other non-monetary returns. Example: Wikipedia, early open source software.

The business model of open source software typically combines the "gift economy" (core software is free) with "cross-subsidies" or "freemium" (services, support, and enterprise editions are paid). This hybrid model worked well — until the cloud era arrived.

II. The Evolution of Open Source Business Models

2.1 The Red Hat Model: Selling the "Hat," Not the Software

Red Hat is the classic case of open source commercialization. Its core product is a Linux distribution — a completely free operating system. So how does it make money?

The answer is "subscription services." What Red Hat sells is not the software itself, but rather:[10]

  • Technical Support: Enterprise customers can get expert assistance when they encounter problems.
  • Security Updates: Regular vulnerability patches and security fixes.
  • Certification and Compliance: Ensuring software meets enterprise and regulatory requirements.
  • Training and Consulting: Helping enterprises adopt and optimize open source technologies.

This model was enormously successful. In 2018, IBM acquired Red Hat for $34 billion, setting the record for the largest acquisition of an open source company.[11] This proved that open source software can create tremendous commercial value — at least under certain conditions.

2.2 The Open Core Model

Another popular model is "Open Core": the core software is open source and free, but advanced features (usually those needed by enterprises) require payment.[12]

GitLab exemplifies this model. Its core version (Community Edition) is completely free and open source, but the Enterprise Edition includes additional security, compliance, and management features that require a paid subscription.[13]

MongoDB also adopted a similar strategy early on, with the core database engine available for free while offering paid management and monitoring tools. The logic of this model is: individual developers and small projects use the free version (expanding the user base and market share), while enterprise customers pay for advanced features (generating revenue).

2.3 The Cloud/SaaS Model

With the rise of cloud computing, many open source companies pivoted to offering managed services. The logic is simple: the software is free, but operations have value.[14]

Take MongoDB as an example: enterprises can download, install, and maintain MongoDB themselves (free but labor-intensive), or they can use MongoDB Atlas — the officially provided managed service, billed by usage. For most enterprises, paying for the managed service is more cost-effective than self-maintenance, because operations require specialized talent, and talent costs far exceed subscription fees.[15]

These three models — service support, open core, and cloud hosting — once sustained a thriving open source business ecosystem. But a problem arose: when cloud giants also entered this game, the rules changed entirely.

III. The "Legal Plundering" by Cloud Giants

3.1 AWS's "Fork" Tactics

In 2019, Amazon Web Services (AWS) launched DocumentDB — a database service "compatible with MongoDB."[16] Note the wording: "compatible with," not "based on." AWS did not use MongoDB's code, but its API was fully compatible with MongoDB, meaning users could switch seamlessly.

This was entirely legal. APIs (Application Programming Interfaces) are generally not protected by copyright, so anyone can develop a "compatible" alternative as long as they don't copy the source code.[17] AWS leveraged its vast cloud infrastructure and customer relationships to directly offer MongoDB's functionality without paying MongoDB Inc. a single cent.

A similar situation occurred with Elasticsearch. AWS launched Amazon Elasticsearch Service, directly using Elasticsearch's open source code to provide a managed service for profit. Elastic, the company behind Elasticsearch, complained: "We write the code, they make the money."[18]

3.2 A Digital Tragedy of the Commons

Economist Garrett Hardin proposed the concept of the "Tragedy of the Commons" in 1968: when a resource is communally owned and anyone can use it, people tend to overuse it, ultimately leading to resource depletion.[19]

Open source software is experiencing a digital version of this tragedy. The code is the "commons," and anyone can use it (that's the very point of open source). But when users include giants like AWS, who can extract enormous benefits from the commons while contributing almost nothing back, the ecosystem becomes unbalanced.

According to estimates, AWS generates over $5 billion in annual revenue from open source-related services, yet its contributions to the open source community (measured by code commits) are negligible.[20] This asymmetric relationship of "extraction" exceeding "contribution" is the fundamental reason many open source companies have changed their licenses.

3.3 The Free-Rider Problem

The deeper issue is the "Free-Rider Problem." In economics, free-riding refers to enjoying the benefits of a public good without bearing any of the costs.[21]

Open source software is a public good: it possesses "non-excludability" (no one can be prevented from using it) and "non-rivalry" (one person's use does not diminish others' ability to use it).[22] Theoretically, public goods should be provided by governments or financed through some collective mechanism. But the "production" of open source software is highly dependent on voluntary contributions from individuals and companies.

When contributors see giants free-riding for profit while they themselves struggle to make a living, the motivation to contribute declines. This is why "burnout" among open source projects is an increasingly serious problem: core maintainers bear a disproportionate share of responsibility yet receive no commensurate compensation.[23]

IV. The License Wars: Walls Going Back Up

4.1 MongoDB's SSPL Controversy

In 2018, MongoDB made a decision that shocked the open source world: it abandoned the AGPL license in favor of the self-created "Server Side Public License" (SSPL).[24]

The core provision of the SSPL states: if you offer MongoDB as a service to users (for example, providing a MongoDB managed service like AWS does), you must open source the entire codebase of your service. This requirement is extremely stringent — it effectively demands that AWS open source its entire cloud platform's code, which is commercially impossible.[25]

The Open Source Initiative (OSI) refused to recognize the SSPL as an "open source" license, arguing it violates the open source definition's principle of "no discrimination against fields of endeavor."[26] But that was precisely MongoDB's purpose — it intended to discriminate against the "predatory" use by cloud giants.

4.2 Redis's License Transformation

In March 2024, Redis announced it was abandoning the BSD license in favor of dual licensing: Redis Source Available License v2 (RSALv2) and Server Side Public License v1 (SSPLv1).[27]

This decision triggered fierce backlash from the community. Redis is the world's most popular key-value database, depended upon by countless projects. The license change meant: cloud service providers could no longer offer Redis managed services for free and would need to obtain a commercial license or use alternatives.

The Linux Foundation responded swiftly, announcing support for a Redis fork called "Valkey," co-maintained by AWS, Google, Oracle, and other companies.[28] This move was deeply ironic: the cloud giants criticized for "free-riding" were now jointly "forking" the project that wanted to charge fees, continuing to offer a free version.

4.3 HashiCorp and the Terraform BSL Dispute

In August 2023, HashiCorp changed the license for all its products (including the widely popular Terraform) from MPL 2.0 to the "Business Source License" (BSL).[29] The BSL allows viewing and modifying the code but prohibits using it for commercial purposes that compete with HashiCorp.

This similarly triggered a fork movement. The Linux Foundation-backed OpenTofu project continued maintaining an open source version of Terraform.[30] HashiCorp then accused OpenTofu's code of plagiarizing new features from the BSL version, escalating the dispute to a legal level.[31]

These cases reveal a harsh reality: the open source world is splitting into two camps — original companies trying to build commercial moats, and an alliance of communities and cloud giants insisting on "pure open source."

V. The Survival Strategy of Tailwind CSS: An Alternative Case Study

5.1 From Side Project to a Multi-Million Dollar Business

Amid the noise of this license battlefield, Tailwind CSS offers a rather different case.

Tailwind CSS is a "utility-first" CSS framework created by Adam Wathan in 2017.[32] Its core library is completely free and open source (MIT license), but Tailwind Labs generates revenue by selling a UI component library (Tailwind UI) and development tools.

According to Wathan's public disclosures, Tailwind Labs surpassed $10 million in annual revenue in 2023, with a team of fewer than 20 people.[33] This is a remarkable level of efficiency — by comparison, many venture-funded open source companies with hundreds of employees are still operating at a loss.

5.2 Analyzing Tailwind's Business Model

Tailwind's success is built on several key strategies:[34]

  • Core Always Free: The CSS framework itself maintains the MIT license with no restrictions whatsoever. This ensures maximum adoption and community support.
  • Charge for Complements: Tailwind UI is a set of beautifully crafted pre-built components that save developers significant time. It is not an "advanced version" of Tailwind CSS, but an independent product built on top of Tailwind.
  • Clear Value Positioning: The free Tailwind CSS solves the problem of "how to write CSS"; the paid Tailwind UI solves the problem of "how to design beautiful interfaces." The two are related but do not overlap.
  • Personal Brand and Community Building: Wathan actively participates in the community, openly shares his experiences, and builds his personal brand. This transparency earns the trust and support of developers.

From an economics perspective, Tailwind's strategy combines "public goods" (the CSS framework) with "private goods" (the UI component library). The former establishes market position and user base; the latter captures commercial value. This avoids both the trap of "charging for core features leading to declining adoption" and the dilemma of "everything free leading to inability to profit."[35]

5.3 Tailwind's Potential Crisis

However, Tailwind's model is not without risks.

In 2024, Wathan admitted in a podcast that the pressure of maintaining an open source project is immense: community expectations constantly rise, competitors (such as UnoCSS) keep emerging, and the team's time and energy are limited.[36] He mentioned that without the commercial revenue from Tailwind UI, he likely would have abandoned the project long ago.

The deeper crisis is "value decoupling." Tailwind CSS's enormous success creates value for the entire web development industry, but Tailwind Labs can only capture a small fraction of it. Millions of developers use Tailwind to build websites, and the economic value those websites create far exceeds Tailwind Labs' revenue. This gap between "value creation" and "value capture" is a shared dilemma of all open source projects.[37]

Another concern is "fork risk." Tailwind CSS uses the MIT license, meaning anyone can legally copy, modify, and redistribute it. If someone (say, a large corporation) decides to "fork" Tailwind and invest more resources in development, they could theoretically replace the original. This scenario is common in the open source world — Node.js forked into io.js, MySQL forked into MariaDB, Redis forked into Valkey.[38]

5.4 Generative AI: The Complement Strategy's Killer?

However, the greatest threat Tailwind faces may not be competitors or forks, but the rise of generative AI.

Tailwind UI's value proposition is "saving developers the time of designing and writing UI components." But in 2024, this value proposition is being eroded by AI coding assistants.[50] Using tools like Claude, GPT-4, Cursor, or v0.dev, developers can generate complete Tailwind CSS components through natural language descriptions in mere seconds — including responsive design, dark mode, animation effects — at a quality comparable to Tailwind UI's paid components.

The economic implications of this shift are profound. Tailwind Labs' business model rests on a premise: "Designing beautiful UI components requires substantial expertise and time, thus worth paying for." But when AI can generate components of equivalent quality in seconds, this premise collapses.[51]

Ironically, Tailwind CSS's open source nature accelerates this predicament. Because Tailwind's syntax is completely public and millions of open source projects use Tailwind, the code from all these projects becomes training data for AI models. AI learns from free open source code, then freely generates output of comparable quality to paid products — a new form of "value extraction" even more thorough than AWS's cloud services.[52]

Real-world examples have already emerged. Vercel's v0.dev can generate complete React + Tailwind components from text descriptions;[53] AI integrated into the Cursor IDE can generate Tailwind code directly within the editor; even the free ChatGPT can produce usable Tailwind components. Developers no longer need to purchase Tailwind UI — they simply describe "I want a pricing card with a gradient background," and the AI generates it.

This reveals a fatal weakness in the "complement strategy": when complements (UI components) can be auto-generated by AI, they cease to be an effective revenue source. Tailwind Labs faces a dilemma:

  • If it maintains the status quo: Paying customers may defect to free AI-generated alternatives.
  • If it pivots to AI services: It must compete with AI giants like OpenAI, Anthropic, and Google — companies whose resources and technology far exceed those of a 20-person team.

The Tailwind case may serve as a warning: in the generative AI era, any business model built on "design patterns" or "boilerplate code" could be dismantled by AI's auto-generation capabilities. This affects not only Tailwind but all open source companies selling component libraries, templates, and design systems.[54]

VI. The Core Dilemma of Open Source Economics

6.1 The Decoupling of Value Creation and Value Capture

The fundamental economic dilemma of open source software can be expressed with a simple formula:

Total Social Value (created by open source software) ≫ Value Captured by Creators

Research by Harvard Business School professor Manuel Cebrian and others estimates that the value open source software creates for the global economy reaches trillions of dollars, yet the compensation received by open source developers constitutes only a tiny fraction of that total.[39]

This decoupling leads to two problems:

  • Underinvestment: If creators cannot receive fair compensation, they will reduce investment and contributions, leading to declining software quality or abandoned maintenance.
  • Unfair Distribution: Value flows to participants who are good at "extracting" rather than "contributing," undermining the cooperative foundation of the ecosystem.

6.2 The Coase Theorem and the Absence of Property Rights

Nobel laureate in economics Ronald Coase proposed that when property rights are clearly defined and transaction costs are sufficiently low, markets can achieve efficient resource allocation through negotiation.[40] But the "property rights" of open source software are ambiguous — it deliberately relinquishes some exclusionary rights.

This property rights ambiguity was an advantage in the early stage (promoting widespread adoption and collaboration), but becomes a disadvantage in the commercialization stage (difficulty in capturing value). The wave of license changes is essentially an attempt to redefine property rights boundaries — allowing "use" but restricting "sale."

6.3 The Collective Action Problem

Political scientist Mancur Olson argued in The Logic of Collective Action that large groups have difficulty organizing collective action because every member has an incentive to free-ride.[41]

The open source community is facing exactly this dilemma. Millions of users benefit from free software, but those willing to pay for support are only a minority. Crowdfunding platforms (such as GitHub Sponsors and Open Collective) provide donation channels, but the actual amounts raised are far from sufficient to support full-time development.[42] Most users' mentality is: "Someone else will donate; I don't need to." The result is that no one donates.

VII. Possible Paths Forward

7.1 Corporate Sponsorship and the Foundation Model

One solution is a "beneficiary pays" mechanism. Organizations such as the Linux Foundation and Apache Foundation collect membership fees from large companies that benefit from open source, using the funds to support the maintenance of open source projects.[43]

The logic of this model is to transform "voluntary donations" into "paid memberships," incentivizing payment by offering exclusive services (such as technical support, brand usage rights, and decision-making participation). However, this model is better suited for large, infrastructure-level projects, while small projects struggle to receive equivalent attention.

7.2 Government and Public Funding Intervention

Given the "public good" nature of open source software, some scholars advocate that governments should provide financial support. The EU's "Next Generation Internet" program has already begun funding open source projects.[44] The German government has also established the "Sovereign Tech Fund," specifically supporting critical open source infrastructure.[45]

This approach treats open source software as "public infrastructure" for the digital age, much like how governments fund roads, bridges, and public health. But it also faces challenges: How does the government determine which projects are worth funding? How does it avoid the problem of "picking winners"? How does it maintain the neutrality and independence of open source?

7.3 New Licenses and the "Fair Code" Movement

New licenses like SSPL and BSL represent a "third way": neither fully open source nor fully proprietary, but "conditionally open."[46]

The "Fair Code" movement seeks to establish a new category and narrative for such licenses: the code is public (readable, learnable, contributable), but commercial use is restricted.[47] This model attempts to find a balance between "community value" and "commercial sustainability."

Critics argue this is "fake open source" or an "open source betrayal," but proponents counter: if pure open source cannot sustain its creators, then such idealism will ultimately only lead to project abandonment, benefiting no one.

7.4 Deepening the Complement Strategy

The Tailwind case shows that "open source core + paid complements" is a viable path. But it requires creators to have business acumen and the ability to identify and develop "complements."[48]

For technically oriented creators who are not adept at commercialization, one option is to partner with a business counterpart: the creator focuses on core technology while the business partner handles packaging, sales, and support. This "division of labor" model is common in the traditional software industry but is not yet widespread in the open source world.

VIII. Conclusion: The Price of Free

"Free" is never truly free. It merely means the costs are borne by someone else.

The "free" of open source software has long been sustained by the passion of developers, the sponsorship of corporations, and the collaboration of communities. But when these support mechanisms prove insufficient to counter the scaled extraction by cloud giants, the system falls out of balance.

We are witnessing a major turning point in the open source movement. From the idealistic utopia of the 1990s, to enterprise-level adoption in the 2000s, to the cloud computing explosion of the 2010s, we have now entered the "post-pure open source" era.[49] In this era, "open source" is no longer a binary choice (open or not), but a spectrum — with various shades of gray between fully open and fully closed.

For developers, this means being more thoughtful: when using an open source project, am I also "free-riding"? Can I give back to the community in some way? For enterprises, this means incorporating "open source support" into the cost structure — if your entire technology stack is built on free software, should you be paying for it?

And for open source creators, perhaps the most pragmatic advice comes from Wathan's experience: don't just create free things — also find something to sell. Idealism can be a driving force, but it cannot be a business model. In this sense, the crisis of open source software is also an opportunity for maturation — moving from the romance of "free" to the reality of "sustainable."

References

  1. Torvalds, L. (1991, August 25). comp.os.minix newsgroup posting. Google Groups Archive
  2. W3Techs. (2024). Usage statistics of operating systems for websites. w3techs.com; Top500. (2023). Operating system share for supercomputers. top500.org
  3. Foley, M. J. (2014, October 20). Microsoft's Nadella: 'Microsoft Loves Linux'. ZDNet. zdnet.com
  4. Shapiro, C., & Varian, H. R. (1998). Information Rules: A Strategic Guide to the Network Economy. Boston: Harvard Business School Press, Chapter 1.
  5. Lessig, L. (2001). The Future of Ideas: The Fate of the Commons in a Connected World. New York: Random House, pp. 53-58.
  6. Katz, M. L., & Shapiro, C. (1985). Network Externalities, Competition, and Compatibility. American Economic Review, 75(3), 424-440. jstor.org
  7. Python Package Index (PyPI). (2024). Package statistics. pypi.org
  8. Raymond, E. S. (1999). The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Sebastopol: O'Reilly Media.
  9. Anderson, C. (2009). Free: The Future of a Radical Price. New York: Hyperion.
  10. Red Hat. (2023). Annual Report 2023. redhat.com
  11. IBM. (2018, October 28). IBM to Acquire Red Hat, Completely Changing the Cloud Landscape. Press Release. ibm.com
  12. Riehle, D. (2012). The Commercial Open Source Business Model. In Technology Innovation Management Review, 2(1), 8-17. https://doi.org/10.22215/timreview/506
  13. GitLab. (2024). GitLab Features by Tier. gitlab.com
  14. Cusumano, M. A. (2004). The Business of Software. Communications of the ACM, 47(5), 20-21. https://doi.org/10.1145/986213.986226
  15. MongoDB. (2024). MongoDB Atlas Documentation. mongodb.com
  16. Amazon Web Services. (2019, January 9). Introducing Amazon DocumentDB (with MongoDB Compatibility). aws.amazon.com
  17. Google LLC v. Oracle America, Inc., 593 U.S. ___ (2021). supreme.justia.com
  18. Elastic. (2021, January 14). Doubling Down on Open, Part II. elastic.co
  19. Hardin, G. (1968). The Tragedy of the Commons. Science, 162(3859), 1243-1248. https://doi.org/10.1126/science.162.3859.1243
  20. Delfino, M., & O'Grady, S. (2022). The Open Source Sustainability Crisis. RedMonk Research Report.
  21. Samuelson, P. A. (1954). The Pure Theory of Public Expenditure. The Review of Economics and Statistics, 36(4), 387-389. https://doi.org/10.2307/1925895
  22. Ostrom, E. (1990). Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press.
  23. Eghbal, N. (2020). Working in Public: The Making and Maintenance of Open Source Software. San Francisco: Stripe Press, Chapter 5.
  24. MongoDB. (2018, October 16). MongoDB Issues New Server Side Public License for MongoDB Community Server. mongodb.com
  25. SSPL License Text. mongodb.com
  26. Open Source Initiative. (2019). The SSPL is Not an Open Source License. opensource.org
  27. Redis. (2024, March 20). Redis Adopts Dual Source-Available Licensing. redis.com
  28. Linux Foundation. (2024, March 28). Linux Foundation Launches Open Source Valkey Community. linuxfoundation.org
  29. HashiCorp. (2023, August 10). HashiCorp adopts Business Source License. hashicorp.com
  30. OpenTofu. (2023). OpenTofu: The Open Source Infrastructure as Code Tool. opentofu.org
  31. Claburn, T. (2024, April 4). HashiCorp accuses OpenTofu of copying BSL-licensed code. The Register. theregister.com
  32. Tailwind CSS. Official Documentation. tailwindcss.com
  33. Wathan, A. (2023). Full Time Open Source podcast interview. Syntax.fm Episode 678. syntax.fm
  34. Tailwind Labs. (2024). Tailwind UI - Beautiful UI components. tailwindui.com
  35. Shapiro, C., & Varian, H. R. (1998). Op. cit., Chapter 7 (Networks and Positive Feedback).
  36. Wathan, A. (2024). On open source sustainability. Twitter thread. twitter.com/adamwathan
  37. Nagle, F. (2019). Open Source Software and Firm Productivity. Management Science, 65(3), 1191-1215. https://doi.org/10.1287/mnsc.2017.2977
  38. Wheeler, D. A. (2015). Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers! dwheeler.com
  39. Hoffmann, M., Nagle, F., & Zhou, Y. (2024). The Value of Open Source Software. Harvard Business School Working Paper 24-038. https://doi.org/10.2139/ssrn.4693148
  40. Coase, R. H. (1960). The Problem of Social Cost. The Journal of Law and Economics, 3, 1-44. https://doi.org/10.1086/466560
  41. Olson, M. (1965). The Logic of Collective Action: Public Goods and the Theory of Groups. Cambridge: Harvard University Press.
  42. Open Collective. (2024). Platform Statistics. opencollective.com; GitHub Sponsors. github.com/sponsors
  43. Linux Foundation. (2024). Members. linuxfoundation.org
  44. European Commission. Next Generation Internet Initiative. ngi.eu
  45. Sovereign Tech Fund. sovereigntechfund.de
  46. Perens, B. (2023). What Comes After Open Source? perens.com
  47. Fair Code. Definition and Principles. faircode.io
  48. Nagle, F., Wheeler, D., & Lifshitz-Assaf, H. (2024). Report on the 2024 Census of Free and Open Source Software. Linux Foundation Research.
  49. O'Reilly, T. (2023). The End of the Open Source Era? O'Reilly Radar. oreilly.com
  50. GitHub. (2024). GitHub Copilot Research Recitation. github.blog
  51. Mollick, E. (2024). Co-Intelligence: Living and Working with AI. Portfolio/Penguin, Chapter 5.
  52. Henderson, P., et al. (2023). Foundation Models and Fair Use. arXiv preprint. https://arxiv.org/abs/2303.15715
  53. Vercel. (2024). v0 by Vercel - Generative UI. v0.dev
  54. Eloundou, T., et al. (2023). GPTs are GPTs: An Early Look at the Labor Market Impact Potential of Large Language Models. arXiv preprint. https://arxiv.org/abs/2303.10130

← Back to Insights