Published on

Lessons for AI: How Gossip in Distributed Systems Became a Catalyst for Innovation

Authors

Innovation doesn't move in straight lines. Sometimes it circles back, borrowing old tools from forgotten fields, and in doing so, opens entirely new possibilities.

Innovation is messy. That is not the kind of line that sells in pitch decks or quarterly strategy reviews, but it is the reality. We like to imagine progress as a clean upward line, each step a forward march into the future, but in practice, innovation more often looks like a tangled thread. Sometimes a step forward introduces pressures that unravel the very fabric it was meant to reinforce. Sometimes the most important advances are not steps forward at all, but steps backward into forgotten domains, borrowing from old knowledge that suddenly feels new again.

The history of distributed systems brims with paradoxes. And one of my favorites, both for what it reveals about technical creativity and how it connects to the broader pattern of innovation, is the story of gossip protocols. So let us gossip about gossip.

RPC: When Remoteness Pretended to Be Local

In the early days of distributed computing, the dream was to make the network invisible. What engineers meant by invisible was not that the wires or packets disappeared, but that the messy details of distribution such as addresses, failures, timeouts, and retries could be abstracted away. This dream was formalized in the concept of transparency in distributed systems. Transparency meant that a distributed system should look and feel like a single unified system, no matter how many machines or network hops actually separated its components (Distributed computing transparency).

Developers should not have to think about sockets, packet loss, or timeouts. They should be able to call a function on a remote machine exactly the way they call one locally. That was the idea behind Remote Procedure Call (RPC), first laid out by Bruce Jay Nelson in his 1981 doctoral thesis at Carnegie Mellon, and later systematized with Andrew Birrell in the influential 1984 paper Implementing Remote Procedure Calls.

RPC was elegant. It gave developers a simple mental model: call a procedure, let the underlying system handle the messy bits. As Birrell and Nelson wrote, “The main goal of the RPC design is to make distributed programming easy.” They achieved that by abstracting away the details of marshalling arguments, transmitting data across a network, and unmarshalling responses. To the programmer, the remote call looked indistinguishable from a local function call.

For a while, it worked. These ideas powered systems like SunRPC, a core component of Unix networking, and the Andrew File System (AFS), one of the first large-scale distributed file systems. The industry quickly adopted RPC like mechanisms in CORBA, DCOM, Java RMI, and other distributed object frameworks that promised seamless transparency.

The appeal was obvious. If you could hide the messy reality of distributed communication, you could scale the abstractions of local programming across a network. Suddenly, building client server applications, file systems, and even early distributed databases looked tractable.

But elegance often hides complexity. By pretending remoteness was local, RPC introduced dangerous assumptions. Remote calls looked like local calls, but they were not. A local method call might take nanoseconds. A remote call might take hundreds of milliseconds. A local call might always succeed. A remote call could fail silently if a packet was dropped or if the network partitioned. These differences were not cosmetic. They were fundamental.

The problem was not just latency. It was tight coupling. RPC made services feel like extensions of each other. A client that depended on a remote service behaved as if the service was always there, always reliable. But in a real network, machines crashed, cables got cut, routers failed. If the remote side was down, the client could be left blocking indefinitely.

The illusion of transparency carried a hidden price. What felt seamless at small scale revealed cracks under real wide-area network conditions.

By the 1990s, as organizations began stitching together larger and more complex distributed systems, they discovered that the RPC model, which had made development so easy in the beginning, was now a trap. It solved the problem of getting distributed systems off the ground, but created a new and deeper problem: how to make them survive at scale.

Messaging: Decoupling the Conversation

The answer was to stop pretending. Instead of hiding the network, acknowledge it, and design around its unreliability. Enter message oriented middleware.

In the early 1990s, companies like IBM and TIBCO brought messaging into the mainstream. IBM’s MQSeries, introduced in 1993, promised “once and once only” delivery by moving messages through queues with guaranteed persistence. In financial services, TIBCO Rendezvous became legendary for its ability to shuttle market data with low latency and high throughput. Later came RabbitMQ, ActiveMQ, and the juggernaut Apache Kafka, which powers much of today’s real-time data movement infrastructure.

The conceptual shift was profound. Messaging systems embraced asynchrony. Instead of a client making a call and waiting, the client dropped a message into a queue and moved on. The message broker guaranteed eventual delivery to a consumer. If the consumer was slow, the broker buffered. If the consumer crashed, the broker retried. If the message failed repeatedly, it was routed to a dead letter queue for later inspection.

This model introduced a set of benefits that RPC could not easily provide:

  • Decoupling: Producers and consumers no longer had to know about each other’s availability or even existence. A producer could fire messages into the system without worrying who would consume them or when.

  • Load balancing: Multiple consumers could share the work by pulling messages from the same queue. The broker became the traffic cop, distributing work evenly.

  • Fan out: A single producer could send a message once, and the broker could replicate it to many subscribers. This was the birth of the publish-subscribe pattern, where consumers expressed interest in certain classes of messages and the system took care of routing.

  • Resilience: Messaging systems built in retry, backoff, and persistence. A message might survive disk crashes, process restarts, or transient network outages. The system as a whole could bend without breaking.

In short, messaging added breathing room. And that space was exactly what distributed systems needed.

It is worth pausing here to acknowledge that messaging did not make RPC obsolete. The two models coexisted. RPC remained useful when you needed a direct, synchronous request and response, especially for small and tightly controlled services. Messaging, however, gave developers a way to think about distribution differently. It let them accept that the network was unreliable, and instead of hiding that fact behind a veil of transparency, they could design systems that absorbed failure, tolerated delays, and scaled more gracefully.

That shift opened the door to entirely new styles of architecture. Enterprise Service Buses in the late 1990s and early 2000s were built on top of messaging. Later, event driven architectures and microservices drew from the same foundations. Messaging was not just a technical tool, it was a cultural one. It taught developers to think in terms of events and flows, not just calls and returns.

But as with RPC, the very success of messaging revealed new challenges. When you had only a handful of services, queues were manageable. When you had hundreds or thousands of services, the volume of messages exploded. And underlying all of this was the network itself, with its own stubborn limits.

Broadcast, Multicast, and the Scarcity of Bandwidth

Networks of the 1990s mainly relied on unicast and broadcast. Unicast meant a one-to-one conversation: a message traveled from one node directly to another. Broadcast meant one-to-all: a message sprayed across the entire local network, hitting every machine regardless of whether it cared.

Both approaches were workable at small scale. If you had a dozen machines on an Ethernet segment, broadcasting a message to all of them was not especially costly. If you needed to send a request to one server, unicast was efficient. But as distributed systems grew into hundreds or thousands of nodes, both models showed their cracks. Broadcasting wasted precious bandwidth because most nodes did not care about most messages. Unicasting separately to many consumers was even worse, because the sender had to replicate the message again and again for each destination.

This was not just an inconvenience, it was a fundamental scalability issue. Bandwidth was scarce. The early commercial internet was still in its adolescence. Connections were slower, routers were less powerful, and capacity was expensive. Pushing redundant traffic across the wire strained both the physical infrastructure and the software systems riding on top of it.

Network researchers had been thinking about this problem for years. In 1989, Stephen Deering’s dissertation Multicast Routing in Internetworks and Extended LANs introduced the concept of IP multicast. The idea was elegant. Instead of sending one thousand identical copies of a message to one thousand recipients, you could send it once and let the network itself handle replication at the branching points. Routers could maintain membership lists of who had expressed interest in a given multicast group and only forward traffic where it was needed.

For a moment, multicast looked like the perfect compromise. It was not wasteful like broadcast, and it was not burdensome like repeated unicast. It was a middle path, a network level publish-subscribe.

The promise was real enough that the internet community experimented with it at scale. In the 1990s, researchers built the MBone, or multicast backbone, to demonstrate that live video and audio could be streamed across the internet using multicast routing. The MBone carried everything from research seminars to live concerts, including a famous broadcast of a Rolling Stones performance in 1994. For a brief moment, it seemed multicast might become a standard feature of the internet.

But multicast never crossed over into mainstream deployment. Routers had to cooperate, and internet service providers were reluctant to enable multicast because it complicated their infrastructure without generating clear revenue. Membership management was technically tricky. Security was a minefield. Who gets to join a multicast group? How do you prevent abuse or denial of service?

The theory was sound, the experiments were exciting, but the practice fizzled. By the late 1990s and early 2000s, engineers building distributed applications could not count on multicast being available across the open internet.

This left them in a familiar bind. The tools that worked in the lab did not work in the wild. They needed a way to deliver messages to many consumers without overloading the network. If the network itself would not provide a scalable broadcast primitive, then the application layer would have to step in.

And so the focus shifted to overlay networks.

Overlay Networks and the Flooding Problem

An overlay network is a logical structure built on top of the physical network. Instead of relying on routers to provide efficient dissemination, engineers build their own virtual topology among the participating nodes. In an overlay, the edges do not necessarily correspond to physical connections but to application level relationships. Think of it as a private map layered over the messy geography of the internet.

The first overlays were often tree-based. Imagine a producer node sitting at the root of a tree. When it wanted to send a message to many subscribers, it would pass the message down the tree, and each internal node would forward it further. This worked reasonably well when the tree was small and stable. But it introduced inefficiencies. Internal nodes were forced to carry traffic meant for others. A machine in the middle might spend more bandwidth relaying data to leaves than consuming it itself. Researchers began calling this the farmer carry problem, because these internal nodes hauled loads they did not need.

Tree overlays also had another weakness. They were brittle. If a node in the middle of the tree failed, everything below it was cut off. Reconfiguring the tree required expensive coordination, and coordination itself was challenging at scale.

One alternative was flooding. In its simplest form, flooding means that whenever a node receives a message, it forwards it to all of its neighbors except the one it came from. Flooding guarantees that the message eventually reaches every node, as long as the network is connected. It is a brute force solution.

The trouble is that flooding does not scale. In any network with degree greater than one, messages multiply rapidly. A single broadcast can turn into an exponential storm of duplicates as each neighbor forwards to all of its neighbors. The network drowns in traffic, and nodes waste cycles discarding messages they have already seen.

Researchers tried to tame this storm. They borrowed ideas from graph theory and network design. One approach was to use hypercube topologies, which connected nodes in such a way that messages could be routed in O(log n) hops (Hypercube networks). Another was Chord, the distributed hash table introduced in 2001, which arranged nodes in a logical ring and used consistent hashing to find data in O(log n) steps. Systems like Pastry and Content Addressable Network (CAN) explored other geometric overlays, mapping nodes into multidimensional spaces.

These structures were clever. They improved routing efficiency. They reduced duplication. They showed that you could build scalable overlays in theory. But in practice, they came with heavy costs. Maintaining the structure required coordination. Nodes had to join and leave gracefully. The more regular the structure, the more fragile it became in the face of churn, failures, and unpredictable network conditions.

In other words, the structured overlays were like carefully engineered machines. They worked beautifully when everything was in place. But real networks are messy. Machines fail. Links flap. Peers appear and disappear. Structured overlays often collapsed under that messiness.

The search was still on for a fundamentally different approach, one that could thrive in the wild instead of resisting it.

Gossip: A Solution Emerges From Outside the Room

By the early 2000s, distributed systems were straining under their own weight. Messaging had given developers breathing room, overlays had provided some structure, but neither solved the scale problem completely. Large services were growing beyond what carefully engineered trees or optimized flooding could manage. Peer to peer networks like Gnutella and Kazaa showed what was possible with millions of nodes, but they also showed how quickly naive broadcast techniques could swamp a network.

Engineers and researchers were restless. The problem was clear. They needed a way to spread information to enormous numbers of machines. They needed something that was simple, cheap, and fault-tolerant. They needed a way to harness randomness without collapsing into chaos.

In 2004, a group of researchers led by Márk Jelasity, Alberto Montresor, and Ozalp Babaoglu published a paper called Gossip based Peer Sampling. It described a set of protocols for building and maintaining random peer-to-peer overlays. The trick was to let nodes exchange small samples of their neighbor lists periodically, like trading gossip. Over time, this simple exchange created a robust, random network structure. That random structure could then be used to spread messages quickly and reliably across vast, dynamic systems.

The beauty of this approach was its looseness. Instead of carefully preserving a rigid structure like a ring or a tree, the network accepted churn as a given. Nodes came and went. Links appeared and disappeared. Gossip shrugged and adapted. It did not require central control or global knowledge. Each node only needed to talk to a few peers at random, and the whole network stayed connected.

At first glance, it seemed like a fresh breakthrough. But the more one looked, the more familiar it felt.

The reason was that gossip was not new at all. It was a resurrection.

Back in 1987, long before web scale systems, researchers at Xerox PARC had been studying a very different problem (albeit still within the realm of distributed systems): how to keep replicated databases consistent. Their solution was described in the paper Epidemic Algorithms for Replicated Database Maintenance by Alan Demers, Dan Greene, Carl Hauser, Wes Irish, and John Larson. They borrowed their language and inspiration from epidemiology, which at the time was urgently modeling the spread of diseases like HIV.

Their insight was disarmingly simple. Think of an update not as a message to be routed, but as an infection to be spread. Each node is either susceptible or infected. At random intervals, infected nodes contact peers and pass on the update. Over time, with high probability, nearly every node becomes infected.

This was the original gossip. It was not designed for millions of nodes or modern internet scale workloads. It was a thought experiment in robustness. But the Cornell and Bologna researchers of the early 2000s rediscovered it and asked a different question: what if we applied this epidemiological idea not just to keep replicas in sync, but to build entire communication substrates for distributed systems?

That was the turning point. What looked like an academic curiosity from the 1980s became, in the new context of large-scale distributed computing, a lifeline. Gossip protocols were sloppy, redundant, and probabilistic. But those qualities turned out to be strengths. In a messy, failure prone, ever-changing network, a little randomness and redundancy could be the difference between collapse and resilience.

The suspense had broken. The unexpected answer to the scalability crisis was not another layer of engineering complexity. It was, quite literally, gossip.

The Whisper that Built Giants

For a while, gossip remained an academic curiosity. The 1987 PARC paper was respected but lived mostly in the world of theory. The 2004 Jelasity work showed how gossip could create scalable overlays, but it was still a research direction. What would it take for gossip to move from the pages of conference proceedings into the beating heart of production systems?

The answer came when the web itself scaled beyond anyone’s expectations.

At Amazon in the early 2000s, engineers faced a particular nightmare. The shopping cart, the simple place where customers stored items before checkout, had to be available all the time. If a cart disappeared, a customer might abandon a purchase. If a cart was locked by one server and inaccessible from another, the experience broke. The scale was staggering: millions of customers, global traffic patterns, and relentless demand. Traditional databases could not keep up.

The solution was Dynamo, described in the 2007 paper Dynamo Amazon’s Highly Available Key Value Store. Dynamo was not a single monolithic database but a distributed key value store built to favor availability and partition tolerance over strict consistency. In other words, Dynamo leaned into the CAP theorem, the famous result articulated by Eric Brewer that said you cannot simultaneously guarantee consistency, availability, and partition tolerance. Something has to give, and Amazon decided that availability mattered most.

How did Dynamo keep itself coherent without a central coordinator? The answer was gossip. Each node maintained information about which other nodes were alive, which partitions they owned, and what version of data they held. Rather than rely on a single master to tell everyone what was happening, nodes simply gossiped with one another. They spread information about membership and state, just as epidemiologists had once modeled infections spreading through a population.

This design choice mattered. Gossip allowed Dynamo to scale horizontally. As Amazon’s business grew, engineers could add more nodes, and the gossip protocol would eventually converge to a new consistent view of the cluster. There was no single point of failure. No central bottleneck. Just a swarm of nodes, constantly trading information in the background.

Inspired by Dynamo and by Google’s earlier Bigtable, engineers at Facebook built Cassandra in 2008. Cassandra combined Dynamo’s decentralized design with Bigtable’s column oriented data model. Today, Apache Cassandra uses gossip for nearly everything that requires coordination across nodes. Schema changes, partition ownership, liveness detection, and cluster topology are all spread through gossip exchanges. Each node is equal. No masters, no dedicated coordinators. Gossip keeps the system coherent.

Cassandra was quickly adopted in industries that needed enormous write throughput and global replication. Netflix, Apple, Instagram, and many others turned to it for workloads where traditional relational databases simply could not keep up. Gossip was not just an implementation detail, it was the reason the system could scale across continents.

The pattern spread. Riak, another Dynamo inspired database created by Basho, used gossip for cluster membership and hinted handoff. Consul from HashiCorp built its entire service discovery model on gossip, allowing agents to spread information about available services without a central registry. CockroachDB uses gossip to propagate metadata about ranges and nodes across the cluster. Redis Cluster employs gossip to keep track of which nodes own which shards. Even Hyperledger Fabric, a blockchain framework, uses gossip to disseminate ledger updates among peers.

And then there is Apache Kafka, the backbone of modern event streaming. Kafka did not adopt gossip in its original incarnation, but its group coordination protocols for consumer groups, brokers, and partitions drew heavily on gossip like ideas. Later research and implementations around SWIM style membership influenced the resilience and elasticity of these systems.

In less than two decades, gossip had evolved from an epidemiological metaphor to a practical substrate that underpins the largest distributed systems and data platforms in the world. What had once been an oddity in the literature became the circulatory system of distributed computing.

Innovation as Recombination

And here lies the lesson: gossip was not brand new. It was a step backward in time and a sideways leap into an entirely different domain, the world of epidemiology, recombined in a new context.

Innovation is rarely pure invention. More often, it is recombination. RPC → Messaging → Gossip is not a straight line. It is a loop.

This looping quality is one of the most persistent truths about technological progress. We do not usually conjure breakthroughs out of nothing. Instead, we take fragments of older knowledge, metaphors borrowed from other disciplines, and lessons learned through painful trial and error, and we braid them together into something that suddenly feels transformative.

History is full of these recombinations. Johannes Gutenberg’s printing press was not an ex nihilo creation. It fused the screw press used for winemaking, the techniques of coin punch metallurgy, and the chemistry of oil based inks into a new whole. The result reshaped literacy, religion, and politics in Europe. James Watt did not invent the steam engine from scratch. He improved on earlier Newcomen designs, borrowing from metallurgy and mechanical engineering, and in doing so ignited the Industrial Revolution.

Computing has always followed the same pattern. The graphical user interface that defined modern personal computing was not invented at Apple. It was inspired by decades of work at Xerox PARC, where researchers combined advances in windowing systems, bitmap displays, and pointing devices into a vision of interactive computing. Tim Berners Lee’s World Wide Web was another act of recombination: he linked together hypertext, which had been studied since the 1960s, with the packet switched internet protocols of the 1970s to create a global information fabric.

Gossip protocols tell the same story. What began as an epidemiological model in 1987 was rediscovered in 2004 by peer-to-peer researchers, and then pressed into service by Amazon in 2007 to keep the shopping cart alive at global scale. A year later, Facebook combined Dynamo’s design with Google’s Bigtable to create Cassandra, and gossip became the glue holding it together. By the 2010s, gossip was quietly humming inside Consul, Redis Cluster, CockroachDB, and Hyperledger Fabric.

The historian of ideas Matt Ridley has argued that progress comes from “ideas having sex”. When one field collides with another, sparks fly. The researches at Xerox PARC were not thinking about key value stores or market data feeds. Yet the language of infection and susceptibility they borrowed from the models of HIV transmission turned out to be the missing metaphor for scalable communication in distributed computing.

The philosopher of science Thomas Kuhn reminded us in The Structure of Scientific Revolutions that paradigms rarely evolve smoothly. They fracture, and new paradigms emerge in the cracks. In distributed systems, the paradigm of transparency fractured under the weight of scale. The paradigm of structured overlays fractured under the churn of the internet. Gossip did not belong to either camp, but it slipped into the void that opened between them.

Biologist Stuart Kauffman called this dynamic the adjacent possible. At any given moment, only certain combinations of ideas are reachable. When the conditions shift, new combinations come into play. Gossip was an adjacent possible for distributed systems in the early 2000s, even though the raw material for it had been lying dormant in epidemiology for nearly two decades.

Seen this way, innovation is not a story of relentless forward motion. It is a story of recombination, reframing, and return. The tools that drive the next revolution may already exist, hidden in plain sight in some other field, waiting for someone curious enough to borrow them.

The AI Parallel

We cannot talk about innovation today without talking about artificial intelligence. The past decade has seen AI move from a niche field into the cultural mainstream, and the arrival of large language models has pushed it into boardrooms, classrooms, and living rooms across the world. Like RPC in the 1980s or message-oriented middleware in the 1990s, AI has given us a new abstraction that feels deceptively simple.

LLMs are our modern RPC. They are elegant, powerful, and they make something impossibly complex look effortless. You type a sentence in plain English, and the model answers. The layers of probability distributions, embeddings, gradient descent, and transformer architecture vanish behind a curtain. What you see is a conversation.

For a while, it works. You can ask a large language model to summarize a research paper, write a piece of code, or even draft a business plan. The model responds instantly. It feels like magic. It feels like transparency, the old dream of distributed systems, resurrected in a new domain.

But elegance often carries a hidden price. Just as RPC pretended that remote was the same as local, LLMs pretend that probabilistic next word prediction is the same as reasoning. They are astonishing at pattern recognition, but they also hallucinate facts. They are confident in their errors. They consume enormous amounts of energy. They sometimes fail in ways that are difficult to anticipate or explain.

In the early excitement, we forget those cracks. We treat the model as if it is a mind. We call its outputs knowledge. We build applications as if its answers are always reliable. But as scale grows, as more people rely on these systems, the hidden costs surface.

And once again, the industry is reaching backward.

When LLMs hallucinate, one solution is retrieval augmented generation (RAG), which combines the model with classic information retrieval techniques first studied in the 1970s (Salton and McGill, Introduction to Modern Information Retrieval). When LLMs need to be aligned with human values, one solution is reinforcement learning with human feedback (RLHF), which borrows directly from behavioral psychology and decades of research into reward shaping (Christiano et al 2017). When LLMs need to reason or plan, researchers return to the traditions of symbolic AI and planning systems that stretch back to the 1960s and 1970s (Newell and Simon, Human Problem Solving).

In other words, the story is the same. A breakthrough creates a powerful new abstraction. That abstraction works wonders for a time. Then cracks appear. And when they do, the next leap forward comes not from something entirely new, but from reaching backward into older domains and recombining their ideas in a fresh context.

The lesson of gossip is that the next leap may not be new at all. It may be something borrowed, rediscovered, and remixed.

The Messy Map of Progress

Innovation is not a ladder. It is not a hockey stick. It is a messy map, winding trails, dead ends, loops, and surprises.

The linear story of progress is seductive. It promises clarity. It promises that each generation will build on the last in a clean sequence, like steps up a staircase. But the reality, as we have seen, is that technology meanders. It tries something, succeeds for a while, then fails in new and unexpected ways. Engineers respond not by discarding the past, but by scavenging it. Old metaphors resurface. Abandoned research suddenly becomes essential.

The story of distributed systems is a perfect case study. RPC hid the network to make life easier for programmers. Messaging reintroduced the network, but softened its rough edges by providing queues and buffers. Multicast promised elegance but never arrived at scale. Structured overlays offered beautiful theory but proved fragile. Gossip, a decades old idea from epidemiology, arrived as the unlikely savior. Each step was not just forward. Each was a turn, a retracing, or a sideways leap.

We can see the same pattern in other fields. In biology, the structure of DNA was not discovered by starting from scratch. James Watson and Francis Crick famously built on Rosalind Franklin’s X-ray crystallography data, which itself drew from advances in physics and chemistry. In aviation, the Wright brothers learned from the glider experiments of Otto Lilienthal, who in turn built on centuries of observation of birds. The path was not straight, it was a weave of experiments, failures, borrowings, and recombinations.

The ouroboros, the ancient symbol of a serpent eating its own tail, captures this dynamic. Progress is not a march but a loop. Each time the snake circles back on itself, something is consumed and something new is born.

When you look at distributed systems through this lens, the paradoxes make sense. RPC was not wrong. Messaging was not wrong. Multicast was not wrong. Each was the right idea for a particular scale and context. Each also created the conditions for the next step. Innovation is not about permanence. It is about motion, adaptation, and willingness to repurpose old tools when the environment changes.

Conclusion: Creativity, Curiosity, and Gumption

The story of gossip protocols is more than a nerdy anecdote. It is a parable of innovation.

Gossip, born in epidemiology, became the bloodstream of distributed computing. Today, it powers systems we take for granted. Your phone talks to services that gossip. Your bank account is backed by databases that gossip. Your favorite streaming platform coordinates its data centers with gossip running quietly in the background.

Tomorrow, some equally unexpected backward step may unlock the next leap in AI. It might be a return to symbolic reasoning, a revival of cognitive architectures, or even a rediscovery of ideas from linguistics or neuroscience that have been sitting quietly on the shelf for decades. The point is not to predict which idea it will be. The point is to notice the pattern.

Innovation is not about marching forward. It is about curiosity, about pattern recognition, about the courage to borrow shamelessly from anywhere if it works.

Sometimes the shortest path to the future runs through the forgotten tools of the past.