FIELD NOTE / 2026.09.213 MIN READ / 5 SOURCES

The Minds Behind Remote Procedure Calls and Distributed Object Interfaces – 7 People Redefining Software

Seven researchers helped create remote procedure calls and distributed-object interfaces while also revealing the limits of pretending that a network call is just a local function call.

TL;DR

Seven researchers helped create remote procedure calls and distributed-object interfaces while also revealing the limits of pretending that a network call is just a local function call. [1][2]

Why you should read it anyway

RPC was one of distributed computing’s most seductive abstractions: make remote communication look like ordinary programming. That dramatically simplified application code, but it also forced engineers to confront serialization, naming, retries, partial failure, latency, idempotency, and version compatibility.

Imagine where Remote Procedure Calls and Distributed Object Interfaces would be without them

Without RPC, distributed systems would still communicate through messages and sockets, but interface-definition languages, generated stubs, remote-object systems, and service frameworks would have evolved more slowly and with more application-specific protocol code.

Time Estimate of how many years we would be hindered without them for human progress

Editorial counterfactual estimate: 6–10 years. This is not a measured historical fact. It is an editorial estimate of how much slower the field might have matured without this cluster of people, institutions, specifications, and tools.

The 7 people behind Remote Procedure Calls and Distributed Object Interfaces

1. Bruce Jay Nelson

Why they matter: co-developed the modern remote procedure call model at Xerox PARC, showing how a network invocation could be made to resemble an ordinary procedure call.[1]

2. Andrew Birrell

Why they matter: co-authored the classic 1984 paper Implementing Remote Procedure Calls, turning RPC from an architectural idea into a concrete systems design with stubs, binding, marshaling, and failure semantics.[2]

3. Jim Waldo

Why they matter: helped shape distributed-object thinking at Sun and co-authored A Note on Distributed Computing, a landmark warning that remote calls are fundamentally different from local calls because latency and partial failure cannot be hidden.[3]

4. Ann Wollrath

Why they matter: co-designed Java Remote Method Invocation, helping adapt remote-object invocation to Java’s type system, serialization, garbage collection, and object model.[4]

5. Roger Riggs

Why they matter: co-designed Java RMI and helped define its architecture for invoking methods on objects across virtual machines.[5]

6. Sam Kendall

Why they matter: co-authored A Note on Distributed Computing and contributed to the conceptual distinction between local object-oriented programming and distributed systems.[1]

7. Geoff Wyant

Why they matter: co-authored A Note on Distributed Computing, reinforcing the architectural principle that location transparency has limits when networks can fail independently.[2]

How they each differ from one another

Nelson and Birrell established practical RPC; Wollrath and Riggs brought remote invocation into Java objects; Waldo, Kendall, and Wyant supplied the crucial architectural critique that remote interactions cannot fully inherit local-call assumptions.

Final Take

RPC gave distributed software a usable programming model, but its most important lesson may be the boundary it exposed: networks are not memory buses, and remote calls must be designed for failure.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.

Contribute / Corrections

Improve the record.

Use this moderated submission form to suggest a correction, provide a source, challenge a priority claim or identify a missing contributor. Submissions are treated as research leads, not automatically published comments.

Submit a research lead

Please do not submit confidential material or claims you cannot support.