How Web-Era Engineers Changed the World — And Why That Same Question Has Come Back in the Age of AI

2026年4月30日 18:01

A deep historical essay on open source, protocol wars, and the timeless logic of building infrastructure

"Can you turn the problem you face at work today into a solution the world can use?" This question hasn't changed since 1993. What's changed is the speed at which solutions travel — and the speed at which the world transforms after they arrive.

If you find this article valuable, please leave a ❤️ — it also saves it to your bookmarks. And if you have a topic you'd like me to explore next, drop a keyword in the comments.

Introduction — A Story About People Who Ran Across an Unmapped Field

This article is, technically, a story about the history of technology. But what I actually want to write about is something else entirely.

It's about this: how does a technology go from a toy to the backbone of the world?

In 1993, the World Wide Web was an unmapped field where no one knew the rules. There were no textbooks. No precedents. No elders to share battle-tested wisdom. And yet, within a decade, this thing called the internet had become the nervous system of the global economy.

Now, in 2026, we find ourselves standing before another unmapped field. AI agents, the Model Context Protocol, autonomous workflows driven by large language models — once again, we're in territory where the textbooks don't exist yet.

How structurally similar are these two "fields"? Where do they diverge? And what can we read from the history that has already happened?

To find out, I went back to primary sources — original documentation, contemporaneous accounts, interviews, and archived records — and tried to trace exactly what happened.

Chapter One: The Web in 1993 — When Nobody Knew How to Use It

The Arrow Tim Berners-Lee Released

In 1989, a young British physicist working at CERN in Switzerland submitted a proposal to his supervisor about improving information sharing among researchers. His manager's response was famously terse: "Vague but exciting."

That memo became the origin point of the World Wide Web.

When Tim Berners-Lee published the first web server and browser in 1991, the system was designed for internal document sharing at research institutions. He made a deliberate and consequential choice: he released it as an open standard. No patent. No licensing fee. Anyone could use it freely.

The full implications of that choice weren't understood by anyone at the time.

In 1993, the web was used primarily by university researchers and a handful of technically extraordinary engineers. The average office worker had never heard the word "internet." Even when the media began calling it the "information superhighway," almost no one could picture concretely what that meant.

And yet within a few years, the Mosaic browser developed by NCSA had spread across the world, and the entire architecture of global information flow had fundamentally changed.

Why so fast?

To answer that, let's start with the story of one engineer.

Brian Behlendorf and the "Patchy Server"

October 27, 1994. San Francisco, California.

A website called HotWired went live. It was the world's first commercial web magazine — the online arm of Wired magazine, a public experiment testing the hypothesis that "the web is not just a toy for researchers."

The first webmaster of HotWired was a 21-year-old named Brian Behlendorf.

According to Cybercultural's detailed investigation, HotWired was running the NCSA web server, but it "couldn't handle password authentication on the scale that HotWired needed." This was a serious problem. Offering paid content required user authentication at scale.

There was no commercial support line to call. No manual. No vendor to escalate to. The person who had originally written the NCSA server code — Rob McCool — had already left NCSA and just joined Netscape. Submitted patches were going unintegrated.

So Behlendorf read the source code himself and wrote a patch.

Then, chatting with other webmasters on the WWW-Talk mailing list — the electronic forum where early webmasters exchanged information — he discovered something remarkable: developers all over the world had been facing exactly the same problem and writing their own patches independently.

The same problem, being solved by the same people, separately, one by one, all over the world.

This was fundamentally inefficient. Behlendorf saw it clearly.

According to the Apache Software Foundation's official history, in February 1995, Behlendorf and Cliff Skolnick set up a mailing list, and eight core developers began pooling their patches against the NCSA server codebase. The first public release, version 0.6.2, shipped on April 27, 1995.

The name "Apache" has two competing origin stories. One is that it's a pun — "a patchy server," built from accumulated patches. The other is that Behlendorf chose it as a reference to the Apache Nation — warriors who held out longest against encroachment, a metaphor for free, open-source software resisting Microsoft's proprietary ambitions. In a 2000 interview, Behlendorf himself said he wanted a name that connoted "take no prisoners — be kind of aggressive and kick some ass."

Both explanations feel right, in their own way.

According to the Apache official site, Apache 1.0 launched on December 1, 1995, and within a year had surpassed NCSA to become the most widely used web server on the internet. By 2009, it became the first web server software to serve more than 100 million websites.

Not a commercial product. Not backed by a major corporation. Software built by engineers who stole time between their day jobs, exchanging patches over email — and it dominated a market that Microsoft had entered.

First principle: "If you solve your own problem, give the solution to the world."

The Night "Open Source" Was Born

While Behlendorf was building Apache, the same "share your patches" culture was spreading across the planet. Linux, Perl, Python, sendmail — each one began as someone's tool for solving their own problem, and became shared infrastructure for humanity.

But there was no unified term for what all these people were doing.

The existing phrase was "free software." And it caused a persistent, exhausting problem. In English, "free" means both "free as in freedom" and "free as in zero cost." Every single conversation with a business person required the same detour: "We mean free as in freedom, not free as in beer."

The person who solved this naming problem was a woman researcher named Christine Peterson.

According to Opensource.com's account, on the evening of February 2, 1998, a strategy session was held at the Foresight Institute's office in Los Altos, California. In the wake of Netscape's historic announcement that it would release the source code for its browser, Eric Raymond, Brian Behlendorf, Michael Tiemann, and others gathered to discuss how to spread this movement.

Between meetings that week, Christine Peterson — executive director of Foresight Institute — landed on a different phrase.

"Open source."

By Peterson's own account: "While not ideal, it struck me as good enough." She tested it on Eric Drexler, Mark Miller, and Todd Anderson, who liked it. A friend in marketing said "open" had been overused, but no better alternative emerged.

On February 5, 1998, at a meeting at VA Research, Todd Anderson proposed "open source" to the group. Eric Raymond endorsed it.

According to the Open Source Initiative's official history, by the end of February, both O'Reilly & Associates and Netscape had begun using the term. Raymond promoted it to the media; Tim O'Reilly promoted it to the business world.

By April, O'Reilly's conference — originally announced as the "Freeware Summit" — had been renamed the "Open Source Summit." Attendees included Linus Torvalds (Linux), Larry Wall (Perl), Brian Behlendorf (Apache), and Guido van Rossum (Python).

A word created a concept. A concept created a movement. A movement created infrastructure.

The night "open source" was born, the mode of production for the world's technology began to change.

Chapter Two: "Give It Away for Free" — The Paradoxical Business Strategy That Netscape Invented

Andreessen's Bet

October 13, 1994. Marc Andreessen's Netscape Communications Corporation made a startling announcement in its first press release.

According to Wikipedia's Netscape Navigator article, Netscape declared it would make Navigator available without charge to all non-commercial users.

Why?

The strategy: give the browser away for free, dramatically accelerating the growth of the internet-using population, then sell the server software those users would rely on at premium prices.

According to Encyclopedia.com's detailed case study, Netscape's web server products (the NetSite Web Server line) were priced between $1,500 and $50,000. These were sold to corporations building online stores and corporate intranets — infrastructure that needed to support credit card transactions and enterprise-scale user management.

Per Internet-history.info's analysis, the business model was "free for individuals and students, per-seat licensing for corporations" — $49 per seat for enterprise licenses. Revenue doubled every quarter through 1995.

EBSCO Research confirms that Navigator 1.0, released December 15, 1994, captured 75% of the internet user market within four months. More than eight million copies were downloaded in the first year. Within two weeks of launch, the company had collected $365,000 in product revenue.

Britannica Money notes that by June 1996, Netscape claimed 38 million users — making Navigator the most widely used personal computer application in history up to that point.

On August 9, 1995, Netscape went public. The stock opened at $28 and hit $75 on the first day, valuing a 16-month-old company at $2.9 billion. This was the proof of concept that launched the dot-com era: an internet company with no profits and a short track record could be worth an absurd amount of money.

Second principle: "Spreading the technology and making money happen in different places."

The Browser Wars and the Politics of "De Facto Standard"

Netscape's success provoked a reaction from Microsoft.

In autumn 1995, Microsoft decided to bundle Internet Explorer with Windows. This was an asymmetric war: to compete with IE, Netscape had to fund browser development entirely from browser-related revenue, while Microsoft could subsidize its browser from the enormous profits of Windows and Office.

But beneath the browser war, a more important battle was being fought: what becomes the standard?

Britannica explains that Netscape collaborated with Sun Microsystems to define JavaScript, and established cookies as a fundamental web infrastructure element. Without going through any official standards committee. They created de facto standards by shipping them — and the market followed.

This is the essence of technology evangelism.

An evangelist is someone who, in a market where network effects operate, builds support for a particular technology to critical mass and establishes it as the standard. Netscape shaped the technical direction of the web not just through technical superiority but through aggressive developer outreach, an open plugin architecture, and early adoption of Sun's Java platform.

JavaScript is the exemplar. Brendan Eich wrote it in ten days in 1995. Netscape shipped it in Navigator. It became the standard language for web interactivity almost overnight. W3C formalized the spec later — the standard came first, the committee came second.

Standards are made by evangelists. Standards make markets. Markets make ecosystems. Ecosystems make moats.

The company that first understood this cycle most clearly was Netscape.

(The irony is that Netscape ultimately lost this game to Microsoft. IE was integrated into Windows, eliminating even the need to download a browser. Netscape's server revenue was eroded by the free Apache server. Netscape's case study attributes its failure primarily to "a vulnerable business model and bad business decisions." In 2008, AOL ended support for Netscape, and it was gone.)

"The Cathedral and the Bazaar" — Raymond Articulates a Revolution

The open-source culture and development methodology that Behlendorf had embodied was articulated with startling clarity in 1997, when Eric S. Raymond wrote The Cathedral and the Bazaar.

Wikipedia notes that the essay was first presented at the Linux Kongress on May 27, 1997, in Würzburg, Germany. Raymond drew on his experience with the fetchmail project and his observations of the Linux kernel development process to contrast two models of software development.

The Cathedral model: careful, centralized, release when fully ready. Closed development. The GNU project's methodology.

The Bazaar model: open, decentralized, release early and often. The Linux kernel's methodology.

Raymond's most famous principle became known as Linus's Law: "Given enough eyeballs, all bugs are shallow." The more people can see the code, the more likely any bug is to be found and fixed.

What made the essay landmark was that it argued, with empirical evidence, that open-source bazaar-style development didn't just match commercial software development — it surpassed it.

Tinycomputers.io's recent retrospective observes something remarkable about the timing: "When Raymond presented his paper in 1997, the term 'open source' didn't exist. He was writing about 'free software' and the Linux development model. The phrase was coined months later, in February 1998, at a strategy session in Palo Alto, partly catalyzed by the essay's success and Netscape's decision to release the Navigator source code — a decision Raymond's essay directly influenced."

The essay generated the word. The word generated the movement.

Chapter Three: What the Bubble Taught Us — What Vanished and What Remained

The Nasdaq Frenzy — +600% to -78%

According to Wikipedia's dot-com bubble article, between 1995 and its peak in March 2000, the Nasdaq Composite index rose 600%. It then fell 78% from its peak by October 2002, erasing all the gains of the bubble period. More than $5 trillion in market capitalization was wiped out.

This was a global phenomenon. Goldman Sachs's historical account notes the crash radiated outward to Tokyo's Mothers Market, Seoul's Kosdaq, Frankfurt's Neuer Markt, London's techMARK, and Paris's Nouveau Marché — effectively a global collapse of technology equities. The Nasdaq would not reach a new all-time high until April 23, 2015 — fifteen years later.

Pets.com (pet food delivery), Webvan (grocery delivery), Boo.com (fashion e-commerce) — these companies became symbols of the bubble. Each raised enormous capital, ran splashy marketing campaigns, and was worth zero within months.

But something was accumulating quietly during the frenzy.

Britannica Money's analysis notes that while most publicly traded dot-com companies had failed by 2002, a handful became the defining beneficiaries of the next several decades: Amazon, eBay, Google, PayPal.

Amazon's stock fell 90% from its peak. Most analysts in 2000 expected it to go bankrupt. In 1999, it reported net losses despite $1.64 billion in revenue. But it survived — because it was building actual distribution infrastructure and steadily expanding beyond books.

eBay survived by making real-world peer-to-peer commerce work online, treating trust as the product.

Google had not yet IPO'd, but was steadily building the ad platform business model that would define it.

PayPal was making itself indispensable as payments infrastructure.

Why Only the Infrastructure Layer Survived

Among everything that came out of the dot-com era, there is a stark pattern to what survived and what didn't.

Application-layer companies (Pets.com, Webvan, Boo.com) vanished.

Infrastructure-layer software (Linux, Apache, MySQL, PHP — what came to be called the "LAMP stack") did not vanish.

Why?

Application-layer companies depended on investor enthusiasm to survive. When the enthusiasm evaporated, so did the business model. Their value proposition was "the excitement around the internet as a new technology."

Infrastructure was different. Linux predated the bubble. So did Apache. MySQL and PHP each started as someone's "tool to solve my own problem." Nobody was building any of them to get rich in the bubble. So when the bubble came, and when it burst, development continued regardless.

EBSCO Research Starters note that despite its many failures, the dot-com era left significant positive legacies. The excessive capital that flowed into the internet during this period is part of what allowed Google and Amazon to ultimately succeed — the infrastructure was there when the market finally matured.

The real legacy of the dot-com bubble was not the applications that survived. It was the infrastructure that had been accumulating, independent of the bubble, that formed the foundation for Web 2.0.

Third principle: "The people who build the infrastructure are the ones who build the world after the bubble."

Chapter Four: Mitchell Hashimoto — From One Engineer's Problem to an Industry Standard

The pattern from the Web era — solve your own problem → give the code away → it becomes infrastructure — repeated itself with startling fidelity in the cloud and infrastructure era.

The most important modern example of this pattern is Mitchell Hashimoto.

Vagrant: A College Side Project

According to the HashiCorp origin story, Hashimoto began his first project, Vagrant, during nights and weekends at the University of Washington — to solve the "reproducibility of development environments" problem he faced in consulting and research.

Nobody asked him to. He was frustrated, so he built it.

Vagrant allows developers to easily create and manage virtualized environments — a solution to the nightmare of "it works on my machine but not in production."

In an interview with EnterpriseReady, Hashimoto recalled: "No one was isolating environments in that way. That's why it hit a nerve when it finally did. It was unique."

Vagrant was released as open source and rapidly became a standard in the DevOps community.

Terraform's "Long Burn"

In 2011, the day after AWS released CloudFormation, Hashimoto published a blog post on Tumblr.

According to HashiCorp's official Terraform history, the post said he was impressed with the concept but believed what the industry truly needed was an open-source, cloud-agnostic solution. He laid out the idea for Terraform in that post — and he gave the idea away, inviting anyone to solve it.

Years passed. Nobody did.

So in July 2014, Hashimoto built it himself: Terraform 0.1, supporting only AWS and DigitalOcean — rough and early, but real.

By his own account: "Terraform was far from an overnight success. Downloads were mostly stagnant for the first 18 months. We even talked at one point about maybe shutting down the project."

But by the end of 2016, the project had over 750 contributors and providers for Azure, Google Cloud, and more. Downloads began doubling every month. By 2018, commercialization via Terraform Enterprise had begun. In April 2024, IBM acquired HashiCorp for $6.4 billion.

Thirteen years from the blog post. Ten years from the first line of code.

The structure is identical to Apache. Solve your own problem. Release it open-source. Let the community grow it. It becomes infrastructure. Build a commercial model on top.

Chapter Five: The 2026 Protocol Wars — Is MCP vs. A2A the Browser War Redux?

The N×M Problem of the AI Agent Era

Here is where we arrive at the present.

In the world of AI agents in 2026, the exact same structural problem that plagued the early web is happening again.

Per Anthropic's official blog: as AI assistants have become mainstream, every data source and tool has required its own custom integration. With N AI applications and M tools and data sources, you potentially need N×M different integrations — what Anthropic called the "N×M problem."

To solve this, Anthropic released the Model Context Protocol (MCP) as an open standard in November 2024.

Wikipedia's MCP article describes it as "an open standard and open-source framework introduced by Anthropic in November 2024 to standardize the way artificial intelligence systems like large language models integrate and share data with external tools, systems, and data sources." It aims to address the challenge of information silos and legacy systems.

A Medium analysis reports that MCP went from 100,000 downloads in November 2024 to 97 million monthly SDK downloads by late 2025 — one of the fastest adoption rates of any protocol in computing history.

Google's A2A and the Start of the Protocol War

According to Koyeb's analysis, in April 2025 at Google Cloud Next '25, Google announced the Agent-to-Agent (A2A) protocol — an open protocol designed to standardize communication between AI agents.

Google positioned A2A as "complementary" to MCP: "A2A is an open protocol that complements Anthropic's Model Context Protocol, which provides helpful tools and context to agents."

But reality is not so simple. A2A and MCP are theoretically complementary but practically competing for ecosystem mindshare. Developers can only invest their energy into so many ecosystems. Google launched A2A with an impressive partner list — Salesforce, PayPal, Atlassian, Accenture, BCG, Deloitte, McKinsey, PwC, and 50+ others — but notably absent from the launch partners were Anthropic and OpenAI.

This maps almost perfectly onto the Browser Wars of the late 1990s.

Netscape and Microsoft fought over JavaScript specs, CSS interpretation, and proprietary HTML extensions. Which company held the "de facto standard" determined how web developers worked. Now, Anthropic's MCP and Google's A2A are fighting the same battle — at the protocol layer for AI agents.

MCP's "Cathedral and Bazaar" Moment — Open Source Determines the Standard Again

Per Agnt.one's analysis, MCP has been adopted by OpenAI, Google DeepMind, Microsoft, and others — moving rapidly toward industry-standard status. Even Google's Demis Hassabis described MCP as "a good protocol... rapidly becoming an open standard for the AI agentic era."

A Medium report notes that in December 2025, both MCP and A2A were donated to the "Agentic AI Foundation" under the Linux Foundation, with OpenAI, Google, Microsoft, and Anthropic all signing on. Competitors agreeing on common infrastructure: this almost never happens in technology.

The AWS Open Source Blog confirms AWS has joined MCP's steering committee: "Open standards run deep in our DNA." — the same logic that drove the Linux-era open-source strategy.

As Koyeb aptly puts it: "The real battleground for AI protocols is adoption. The protocol that wins will be the one that develops use, tool support, and ecosystem."

This is identical to the logic by which Netscape pushed JavaScript into "standard" status in 1995 — ship it into the market, let developers adopt it, force competitors to catch up. MCP was released open-source in November 2024, and within six months had achieved adoption from every major AI player.

Chapter Six: Mapping History onto the Present — Five Principles

Let us now lay the Web era (1993–2005) and the AI era (2024–2026) directly on top of each other. The structural similarity is striking.

Principle 1: "The First to Run Across the Unmapped Field Makes the Standards"

In 1993, Behlendorf and his peers learned HTML in a field with no textbook. They shared knowledge on the WWW-Talk mailing list, critiqued each other's patches, and built their understanding through practice rather than curriculum.

In 2026, we're learning AI agent orchestration, MCP server design, and prompt engineering best practices on GitHub, arXiv, Discord, and X. The learning venue shifted from mailing lists to Slack and X. The structure is identical.

As the Open Source Initiative's records show, before open source became a movement, its participants didn't even have a word for what they were doing. Terms like "freely distributable," "cooperatively developed," and "sourceware" competed before "open source" won. The concept moved before the vocabulary did.

The AI agent world is the same. "Harness engineering," "Rippable Harness," "Agent OS" — these terms are being coined right now, in real time. Concepts move first. Language catches up.

Principle 2: "Solve Your Problem, Then Give the Solution to the World"

Behlendorf solved HotWired's problem and built Apache. Hashimoto solved his consulting problem and built Vagrant; solved his cloud infrastructure problem and built Terraform. Anthropic solved its own AI integration problem and built MCP — then released it as an open protocol.

Anthropic's announcement specifically notes that Claude 3.5 Sonnet is adept at quickly building MCP server implementations — they built a thing they needed, and it became the world's standard. This is the Apache logic, applied in 2024.

The person who solves the problem makes the next standard.

Principle 3: "Open to Spread, Close to Earn"

Netscape gave the browser away and sold the server software. Microsoft bundled IE for free and earned from Windows and Office. Red Hat, HashiCorp, and other open-source companies opened the core and monetized enterprise support, security, and reliability.

HashiCorp's Wikipedia article records that IBM acquired HashiCorp for $6.4 billion — one of the canonical "exits" of the open-source business model.

The AI era follows the same structure. Anthropic opens its API and releases MCP as an open protocol. Revenue comes from commercial Claude usage and enterprise-grade trust, security, and support. OpenAI mirrors this structure.

"Open to spread, earn somewhere else" — this model has not changed in thirty years.

Principle 4: "Evangelists Determine Standards"

Netscape made JavaScript and cookies the world's standard through evangelism — working the developer community, releasing early, watching competitors follow.

The MCP vs. A2A battle follows the same playbook. Agnt.one reports that one key reason MCP has gained the lead is "community-driven momentum" — developers spontaneously created MCP servers for Slack, GitHub, PostgreSQL, Google Drive, Stripe, and dozens of other platforms, forming a self-expanding ecosystem on GitHub.

An evangelist is not one passionate preacher. When the entire community becomes evangelists, that's when a technology becomes a standard.

Principle 5: "The Infrastructure Builders Survive the Bubble"

What the dot-com bubble destroyed were application-layer companies. The infrastructure — Linux, Apache, MySQL, PHP — survived and became the foundation for Web 2.0.

What counts as "infrastructure" in the AI era is not yet settled. But the candidates are visible:

MCP and A2A (the protocol layer)
Vector databases: Pinecone, Weaviate, Chroma, pgvector (the persistent memory layer)
Agent evaluation frameworks: Langfuse, Weights & Biases, Braintrust, Phoenix (the quality assurance layer)
Observability tools: Langfuse, Helicone, OpenTelemetry AI extensions (the traceability layer)

The people quietly building these layers today are the ones who will build the world after whatever AI bubble comes and goes.

Chapter Seven: The One Thing That's Decisively Different — "The Tool Itself Changes"

Having argued for the structural similarities between the Web era and the AI era, I want to be precise about the one fundamental difference.

In the Web era, engineers were learning tools — stable artifacts whose behaviors were fixed. Learn HTML today, and it still works the same way next year. Master CSS in 2000, and that knowledge stays valid for several years. Apache's configuration files written in 1999 still largely made sense in 2005.

The technology evolved, certainly — but engineers were adapting to tools, not adapting alongside tools that were themselves continuously learning.

In the AI era, the tools learn and change.

Take prompt engineering. Best practices established in 2022 were partially invalidated by model improvements in 2023. Multimodal capabilities arrived in 2024 and changed the design space again. Agentic task decomposition became standard in 2025. The ground beneath best practices shifts with each model generation.

This is why "Rippable Harness" matters as a design philosophy — not just for agent systems, but for how we hold knowledge itself.

MCP's specification document encodes this philosophy at the protocol level. MCP aims to be a universal interface that doesn't depend on any specific LLM implementation. An MCP server built for Claude should, in principle, work with OpenAI's models. The protocol is rippable — designed so that when the underlying model changes, the integration layer doesn't have to be rebuilt from scratch.

But the Rippable Harness concept extends beyond protocols.

Your mental models themselves need to be rippable. The "best practice" of 2024 is the legacy pattern of 2026. The "right answer" of 2025 may have its premises overturned entirely in 2026.

The engineers who will thrive in this environment are not those who master the deepest details of a specific framework. They are those who can distinguish between what is TCP/IP-level stable (lasting 30 years) and what is application-layer transient (replaced in 2–3 years) — and who resist the temptation to over-invest in the transient.

Web-era engineers learned "adapt to changing technology."

AI-era engineers must learn something harder: "continuously update your premises along with the technology."

Chapter Eight: A Global View — How the AI Infrastructure Race Looks from Outside the US

The open-source revolution of the Web era began in America but radiated globally in ways its founders could not have predicted.

Linus Torvalds was Finnish. Guido van Rossum (Python) was Dutch. Rasmus Lerdorf (PHP) was Canadian. Developers from across the world exchanged patches across language and national boundaries on mailing lists, and this genuinely global participation was not incidental — it was structural.

How does the AI era compare?

Currently, foundation models are dominated by American companies (Anthropic, OpenAI, Google, Meta) and Chinese competitors (Baidu, Alibaba, DeepSeek). But diversity at the infrastructure layer is increasing rapidly.

In France, Mistral AI has emerged as the champion of European open-weight models, carrying the "AI sovereignty" ambitions of the EU. In Germany, EU policy backing for "AI made in Europe" is fueling a new generation of startups. In Japan, NTT's tsuzumi, CyberAgent's CyberAgentLM, and Lightblue (a Tokyo University spinout) are developing Japanese-language-specialized models.

In India, an LLM democratization-centered startup ecosystem is growing rapidly. A pattern is emerging: American research institutions and companies produce the technical breakthroughs; India provides cost-effective engineering implementation; the results are deployed into Southeast Asian, Middle Eastern, and African emerging markets.

This mirrors exactly how open-source spread in the Web era. Technical invention came from American research institutions and companies. But the global propagation of that technology required contributions from developers across every cultural and linguistic context. Japanese Wikipedia exists. Swahili Linux distributions exist. Americans didn't build those.

MCP and A2A will follow the same path. The organizations and developers who localize, extend, and adapt these protocols for regional contexts and industries will become indispensable nodes in the global AI infrastructure — exactly as regional Linux distributions and Apache configurations became indispensable to local web ecosystems.

Chapter Nine: Who Survives? Reading the AI Infrastructure Competition

Applying the dot-com era's most important lesson to the AI era yields concrete predictions.

Candidate 1: The Protocol Layer

MCP vs. A2A is the Apache vs. NCSA battle in a new form.

MCP's Wikipedia article documents that OpenAI formally adopted MCP in March 2025, with ChatGPT apps supporting third-party MCP access by September 2025. Microsoft collaborated with Anthropic to build an official C# MCP SDK. AWS joined the steering committee.

It took Apache roughly one year from its first public release (April 1995) to overtake NCSA as the #1 web server (December 1995). For MCP to be established as the definitive de facto standard for AI agent protocols will likely take 1–2 more years.

The players who build, govern, and extend this protocol layer hold the "foundation" of AI-era infrastructure.

Candidate 2: The Vector Database Layer

AI agents need memory. Conversation context, past decisions, user preferences — without a mechanism to persist and rapidly retrieve this information, every agent restart is amnesia. Vector databases — enabling semantic similarity search at speed — are the infrastructure that makes persistent agent memory possible.

Pinecone, Weaviate, Chroma, pgvector (the PostgreSQL extension) — these are competing to become the "MySQL/PostgreSQL" of the AI era.

Every modern web application has a relational database underneath it. The winner(s) of the vector database layer will be underneath every AI application the same way.

Candidate 3: The Evaluation Framework Layer

"How do you verify that an agent is working correctly?" This is the core quality assurance question of the AI era.

In the Web era, Selenium enabled automated browser testing. JUnit enabled unit testing. The tooling for "confirming that code does what it's supposed to do" matured over years and made large-scale software development tractable.

AI agent testing is harder: you're testing probabilistic outputs, not deterministic ones. You need a framework that can assert "given this prompt, this agent takes the intended action at least 80% of the time." The frameworks competing for this layer — Langfuse, Weights & Biases, Braintrust, Phoenix — are still in the early standardization stage.

Whoever wins here gets embedded into every AI engineering organization's CI/CD pipeline. JUnit-level ubiquity for AI.

Candidate 4: The Observability Layer

"What is the agent doing right now, and why did it make that decision?" — this is the observability question.

In the Web era, New Relic, Datadog, and Prometheus created the infrastructure for monitoring application behavior in production. Today, almost no production web service can operate without these tools. Datadog alone is a company worth tens of billions of dollars.

AI agents require the same layer: tracking which tools were called, which data was accessed, how many tokens were consumed, which sub-agents received which delegated tasks. Without this traceability, running agents in production is functionally impossible.

The winners of AI observability could, over the next decade, reach the scale that Datadog reached for web observability.

Chapter Ten: The Conditions for Being an Evangelist — "The Person Who Gives the World a Language for Its Own Experience"

Let me think a bit more carefully about Web-era evangelists.

Behlendorf built Apache. That was an act of giving code.

When Eric Raymond wrote "The Cathedral and the Bazaar," that was an act of giving a concept — made legible through language.

When Christine Peterson coined "open source," that was an act of giving a frame — a mental model that could be carried into any boardroom, any conversation with a journalist, any developer conference.

Technology propagation requires three distinct types of "givers":

People who give code (the Behlendorf type)
People who articulate concepts (the Raymond type)
People who create frames (the Peterson type)

When all three are present, a technology becomes a movement.

In 2026's AI era, who fills each role?

Code givers are abundant. MCP from Anthropic, A2A from Google, open API libraries from OpenAI, LangChain, LlamaIndex — code is everywhere.

Concept articulators are beginning to emerge. "Harness engineering," "Rippable Harness," "Agent OS" — these are concepts that a handful of practitioners have articulated from direct field experience.

But the frame maker — the person who, with a phrase as simple and potent as "open source," changes the mental model of an entire developer culture — that person, or that phrase, has not yet fully emerged.

Just as "open source" was born on the evening of February 3, 1998, when Christine Peterson landed on two words between strategy sessions — it's possible that somewhere right now, someone has already written the defining phrase in a Slack message or a Discord thread. The world just hasn't found it yet.

Chapter Eleven: The Philosophy of the Rippable Harness — Updating Your Premises as the Premises Change

One final return to the core question.

Web-era engineers learned to "adapt to changing technology." The deep structure of their approach was: lock down the foundation, update the superstructure as conditions change.

TCP/IP, designed in the 1970s, still underlies every internet communication today. HTTP, designed in the 1990s, still supports the modern web. The infrastructure layer doesn't change. The application layer does.

The AI era's "Rippable Harness" philosophy is this principle, applied to AI agent systems.

MCP's specification embeds this philosophy at the protocol level. MCP aims to be a universal interface that doesn't depend on a specific LLM implementation — so that when the underlying model changes, the integration layer doesn't have to be rebuilt from scratch. The harness is rippable.

But "Rippable Harness" as a philosophy extends beyond protocol design.

Knowledge itself needs to be held rippably.

The "best practice" of 2024 is the legacy pattern of 2026. The right answer of 2025 may have its entire premise overturned in 2026. In this environment, the engineer who thrives is not the one with the deepest mastery of the current stack. It is the one who can tell the difference between:

What is TCP/IP-level stable (lasts 30 years, worth deep investment): foundational reasoning, systems thinking, the ability to read specifications, the ability to recognize structural patterns across technology generations.

What is application-layer transient (replaced in 2–3 years, invest lightly): specific framework APIs, particular prompt templates, the implementation details of any given model version.

Web-era engineers learned: "Adapt to changing technology."

AI-era engineers must learn something one level harder: "Update your premises continuously, along with the technology."

The ability to learn how to learn in a rapidly shifting field — this, more than any specific technical skill, is the meta-capability the AI era demands.

Conclusion — The Question Hasn't Changed

Behlendorf didn't post his patch to the WWW-Talk mailing list because someone asked him to.

He'd been solving his own problem, and it turned out his problem was also the world's problem.

Hashimoto didn't build Terraform because he saw a market opportunity. He wrote a blog post in 2011 saying "someone should solve this," waited years for someone else to do it, and when no one did, built it himself.

Anthropic didn't release MCP to be altruistic. They built a thing they needed to solve their own integration problems, and released it openly because open standards create the ecosystems that benefit everyone — including the protocol's originator.

Christine Peterson didn't coin "open source" to become famous. She was looking for a cleaner way to explain something in a strategy meeting, and the phrase she landed on that week changed how an entire industry talked about itself for the next thirty years.

The chain is always the same.

"Can you turn the problem you face at work today into a solution the world can use?"

What has changed is the speed at which solutions travel. Behlendorf distributed patches over a mailing list. Hashimoto used a blog and an open-source repository. Today, someone can post their solution on Discord on Monday morning and have 5,000 engineers around the world testing it by Tuesday.

What has changed is the speed of transformation after solutions arrive. Apache took roughly a year to become #1. MCP achieved major platform adoption in months.

And what has changed — perhaps most importantly — is the sheer accessibility of participation.

In 1995, becoming a webmaster required specialized knowledge that was genuinely hard to come by. In 2026, building an MCP server requires no PhD in machine learning. You read the docs, use the SDK, solve your own problem, put it on GitHub.

The question is unchanged.

"Is the thing I'm frustrated by something that someone else somewhere is also frustrated by?"

"Can the solution I found become a solution for them too?"

These two questions, answered with "yes" — and acted on — are what have built the world's technical infrastructure since 1993.

In 2026, they're waiting for you again.

Sources and References

All sources used in this article are listed below. Only verifiably accessible links are included.