BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles The Technology Adoption Curve, Twenty Years On

The Technology Adoption Curve, Twenty Years On

Listen to this article -  0:00

InfoQ launched on June 8, 2006, with a particular editorial bet: the most valuable thing a software developer publication could do was identify ideas in the innovator and early adopter stages of the technology adoption curve, get practitioners to write about them honestly, and put that material in front of senior engineers before the early majority showed up. The focus was on adoption and real-world experience, not hype.

Today, June 8th, InfoQ celebrates 20 years. That framing of innovators, early adopters, early majority, late majority, and laggards is still on the About page because it remains central to InfoQ's editorial approach. It continues to guide our coverage and trends reports, helping map emerging technologies and practices against the technology adoption curve.

InfoQ's story is not only visible in broad movements like Agile, cloud, or AI. Technologies that later became mainstream surfaced on the site while still in their formative years: Doug Cutting discussed MapReduce and Hadoop in 2007, and Salvatore Sanfilippo (Antirez) shared his vision for Redis.

Java deserves a mention, being a constant presence on InfoQ from day one. When the site launched in 2006, Sun Microsystems was still an independent company. Over the next two decades, InfoQ followed Java's evolution through enterprise frameworks, cloud-native architectures, containers, microservices, GraalVM, and virtual threads. The journey stretches from some of InfoQ's earliest Java coverage to recent community phenomena such as the One Billion Row Challenge. Twenty years on, Java developers are still finding new ways to push the platform to its limits.

What follows is not a comprehensive history. It is a deliberately selective walk-through of the trends InfoQ called early, where they are on the curve in 2026, and how the curve may evolve over the next five to ten years.

Agile (2006): from contested practice to a vocabulary that the whole industry shares

When InfoQ launched, Agile was one of its five founding community streams, led by Deborah Hartmann and Scott Ambler. The 2006 framing was that "a vast number of process and tooling innovations" were emerging from the Agile community faster than any individual practitioner could keep track of. The mission was to help readers keep up.

Where it is now: late majority, possibly laggard.

Agile won so completely that the word has lost most of its specificity. Agile and DevOps practices have become so integrated into industry standards that they are now "the air that we breathe," with platform engineering emerging as the next evolution, bringing product and design mindsets to developer tooling.

The interesting questions have moved to what comes after: product thinking for engineers, platform-as-product, and the architecture advice process. All of them are descendants of the original Agile thesis, even when they do not carry the name.

Service-Oriented Architecture (2006): the idea was right, the implementation was early

The 2006 SOA community thesis described an industry "plagued by a scattered collection of blogs and small conferences, but no place for these personalities to call home." SOA itself, as branded in 2006, did not survive the decade in its original form. But the underlying question survived and remains valid today: how do you design systems when service boundaries keep changing, and how do you govern integration without slowing it down?

Where it is now: the SOA brand is now a laggard.

The SOA problem is at the center of every conversation about microservices, service mesh, and now agent orchestration. By 2026, SOA is rarely the headline anymore. Still, the architectural problems it described remain central, as agent orchestration becomes part of mainstream software architecture.

Cloud (2008–2012): from "is this real?" to "what isn't?"

InfoQ began covering cloud computing in earnest while it was still genuinely contested whether serious enterprise workloads would ever leave the data center. The early coverage focused on architectural patterns rather than vendor announcements, which is why it aged well.

InfoQ captured foundational practitioners while the future was still uncertain: in 2007, Werner Vogels, CTO of Amazon, presented the "Amazon.com technology platform" at QCon, starting with a then-not-rhetorical question: "Do you guys know what S3 is?" Amazon S3 had been announced only a couple of months before InfoQ was born.

A year later, InfoQ editors started to cover what at the time were called Windows Azure and Google App Engine, with Abel Avram comparing for the first time Amazon's EC2, Google's App Engine, and Microsoft's Azure, highlighting how at the beginning they were "not really competing against each other."

By 2012, AWS and other cloud providers were moving beyond raw infrastructure to managed platforms and higher-level services, with internet companies such as Netflix becoming proof points for cloud-native architecture. In 2012, Netflix open sourced Chaos Monkey, flipping the traditional mindset: do not assume failures are rare; assume they are inevitable, and design for them.

Where it is now: late majority. The frontier has moved to the questions that cloud created — FinOps, multi-region resilience, cost-aware architecture, sovereignty, and the carbon footprint of inference. InfoQ's Green IT coverage is a direct descendant of the cloud thread. Three years ago, Adrian Cockcroft highlighted the importance of tracking energy consumption and establishing carbon footprint standards to monitor the commitments of the largest providers, a practice that is even more relevant for future AI workloads.

DevOps (2010–2014): the cultural shift that ate the org chart

DevOps was harder to cover than cloud because the technical surface (CI/CD pipelines, infrastructure as code) was only half the story. The other half was a cultural change inside engineering organizations, and the InfoQ Culture & Methods category matured around exactly that problem.

The DevOps movement crystallized in 2009 with the first DevOps Days conference, founded by Patrick Debois. During the formative years of DevOps, Puppet founder Luke Kanies explained how software was eating organizational silos, and Adam Jacob, the creator of Chef, discussed the evolution and future directions. The DevOps maturity curve was already a topic in 2014.

Where it is now: early majority shading into late majority.

Platform engineering is the current articulation, with the platform-as-product framing, golden paths, and internal developer platforms. The "ironies of automation" thread, recently amplified by AI, is the next sub-question: every layer of automation removes toil while creating new dependencies, abstractions, and failure modes.

Containers and Kubernetes (2014–2018): a rare clean win

Docker and then Kubernetes moved through the adoption curve faster than almost anything else InfoQ has covered. The editorial bet here was straightforward: get the practitioners who were running containers in production to write about what actually broke.

In 2014, InfoQ published "Scaling Docker with Kubernetes," its first article explaining Kubernetes concepts, cluster setup, pods, services, and deployment. While the 2019 eMag, "Kubernetes: Past, Present and Future," set the tone for the next few years, the latest InfoQ Cloud and DevOps Trends Report highlights how "Kubernetes is now the stable, de facto substrate for cloud-native deployment."

Where it is now: Kubernetes is firmly in the early majority and arguably the late majority for cloud-native shops.

The interesting frontier moved up the stack to service mesh, eBPF, multi-cluster, and edge, and is now being reshaped again by AI workload patterns that do not fit the assumptions on which Kubernetes was built. In 2023, InfoQ already discussed the silent platform revolution and how eBPF is transforming cloud-native platforms.

Microservices (2014–2020): from contested term to default architecture, then to a more honest conversation

Microservices is the trend where InfoQ's "best, not first" editorial value paid off most visibly. By the time microservices were on every conference track, InfoQ had years of case studies, including failure modes, already in hand. The site was one of the first places where the honest version of the microservices conversation could happen and where questions regarding their adoption were raised. InfoQ's "Microservices: Are They Still Worth It?" explored whether a middle ground exists and how teams learned to manage operational complexity.

Where it is now: late majority, with a healthy and overdue counter-current.

In 2021, James Lewis, who defined the microservices architectural style with Martin Fowler, discussed how the meaning and practice of microservices had evolved beyond early enthusiasm. The current articles are about decomposition you can defend, modular monoliths where they make sense, and how agentic systems force a rethink of service boundaries.

Machine learning as engineering (2014–2020): the bet that aged best

The About page notes that in 2014, InfoQ "began ramping up our coverage of data science and machine learning." That was a deliberate editorial bet made years before the transformer paper, years before ChatGPT, at a point when the practitioner audience was small. The bet was that ML would become an engineering discipline, not a research one.

Engineers, not researchers, would need a venue to share what they were learning. "From The Lab To The Factory" indeed: building a production machine learning infrastructure has challenged practitioners since the early days in finding strategies for data integration, large-scale machine learning, and experimentation.

At that time, another clear theme already emerged: data science was becoming a hybrid discipline, requiring both strong foundations in mathematics and statistics and the engineering skills needed to build and operate systems on modern big data platforms.

Where it is now: early majority.

ML in production is no longer exotic. The frontier has moved decisively to AI engineering as its own discipline.

AI engineering and agentic systems (2023–today): the current innovator/early-adopter band

This is where the curve is most active right now, and it is where InfoQ readers are spending the most time. The current homepage gives a good cross-section: AI gateways and centralized inference, WebRTC architecture for voice agents at scale, multi-agent systems for engineering support, MCP tunnels for private agent access, AI governance as a primary determinant of risk — the ironies of A² I² — automation's old paradoxes amplified by AI.

Within this broader shift, several distinct sub-threads stand out.

Context engineering and spec-driven development. Baruch Sadogursky's recent argument — that with sufficiently rigorous context artifacts, specifications become the source of truth and code becomes a disposable intermediate language — is exactly the kind of claim InfoQ should be tracking. It might be the next architectural paradigm, or it might be 2026's version of MDA. Either way, the practitioner community needs a venue to argue it out.

AI-native development patterns. Patrick Debois's four patterns — producer to manager, intent over implementation, delivery to discovery, agentic knowledge management — name something real about how senior engineering work is changing. These are innovator-stage ideas in 2026. Whether they will be early majority by 2028 is the question.

The reliability story for AI systems. Production AI is producing a new category of incidents and a new conversation about what reliability even means when the system is non-deterministic by design.

What the next ten years on the curve will probably look like

There are a few predictions worth being held accountable for in 2036.

Agentic systems will follow the microservices arc.

A period of over-application, followed by a more honest conversation about when they actually make sense, followed by the kind of mature patterns that look obvious in retrospect. InfoQ's job is to be the venue for honest conversation, not the over-application.

Spec-driven and context-driven development will either be transformative or a footnote, and we probably do not yet know which. The early signals are strong enough that they belong in the innovator band, not the dismissed band.

Reliability engineering for AI systems will become its own discipline, the way SRE did for distributed systems. The practitioners doing this work today are writing the playbook.

Green IT and the sustainability of compute will move from the innovator band to the early adopter band, as the economic and regulatory pressure on inference compute increases.

Something we are not currently covering will turn out to matter most.

This is the most important prediction, and the hardest editorial discipline to maintain. The reason InfoQ has called as many trends correctly as it has is not that the editors are clairvoyant. It is because they have stayed close to practitioners and listened to what was getting harder, not what was getting hyped.

Twenty years in

The adoption curve is the same shape it was in 2006. The names on it have changed completely. What has not changed is the editorial bet: find the practitioners, get them to write honestly, peer-review the result, and put it in front of the senior engineers who need to decide what to adopt next.

To the 550,000 senior developers who read InfoQ every month, and to every editor and contributor who has helped move an idea from innovator to early adopter to the rest of the industry: the curve continues. Thank you for the first twenty years.

About the Author

Rate this Article

Adoption
Style

BT