Meeting Protocol
By David Alan Grier

speaker at conferenceOver the past month, I’ve been doing a little work to help one of the IEEE software conferences. I have a very small role on the organizing committee. I have spent a little time raise some money, get the support of a local education ministry and inspect the likely conference site. In all, I feel that I am spending most of my time in communications and trying to follow the IEEE conference protocols. Complete a form. Contact a minster. Draft a notice. I think that we spend more of our time coordinating our efforts than we actually spend working. We may even spend more time in coordination than the speakers spend in research.

We have long known that conferences play a special role in computing, a role that may have come from the fact that the field had conferences before it had publications. The early computer pioneers started holding meetings at the end of 1945, fully seven years before anyone starting publishing a computer periodical. They held four conferences the following year, including one – the Moore School Lectures – that defined the discipline of computing.

Of course, for nearly 40 years, the major event in computing was the joint IEEE/ACM conference, a large meeting that was held twice a year and was managed by the American Federation of Information Processing Societies. If you look at the proceedings of these meetings, you can find the fundamental papers of almost every part of computing. Programming Languages. Operating Systems. Multi-processing. Computer Networks. Graphical User Interfaces. All of these ideas were first presented at a conference and were published in a journal only later.

The joint IEEE/ACM conference ceased operation at the end of the 1980s and was replace not by a single conference but by many. The IEEE alone has over 230 computing conferences. While many of my peers have complained that we need a single focus for the field, they recognize that we are never again going to get the all computer scientists and engineers and software developers to attend a single meeting. Computing is now far too diverse. Theoreticians, for example, have little to say to those involved with Human-Computer interfaces and perhaps vice versa.

In our age, computer conferences have a certain kind of narrative arc, a single story that they tend to follow. Generally, all new conferences start as an offshoot of another conference. A small band of researchers break with the old to establish a new institution. For the first year or so, the conference is only lightly attended and the presentations are scattered.

I recently viewed the proceedings from a new conference that was involved in new forms of software development. True to form, the proceedings has a lit of intriguing papers but it had none that really unified the field or provided a foundation for the subject. It had a paper that described work being done in Brazil, another that voiced concerns about the new field and a third that really should have been given at a cloud computing conference. In all it was not a bad start, but it was only a limited contribution to the field in the best of lights.

After this kind of start, a conference will start to mature in its third or fourth year. At that point, a couple attendees will present papers that will be the foundation for the conference. They will describe the field, identify key problems, and present the intellectual tools that will provide answers to the questions that the group faces. For the next few years, the members of the conference will apply those ideas to outstanding problems and will get some useful results.

At some point, usually five to six years after those fundamental papers, the conference will start to falter. The ideas that were presented in that third or fourth year will have run their course. They will have solve all the problems that they can solve. The students who learned those ideas have become researchers in their own right and moved to other problems.

At this point, the conference has two choices. Occasionally, it gets a new burst of life from new papers, new theories, new ways of working on problems. In many of these cases, the basic focus of the conference will change. It will move from one kind of problem to another. A new generation of students will be inspired by the topic and the conference will get another five or six years of life.

Those conferences that don’t get this kind of inspiration start a slow decline. Generally, they start attracting vendors and teachers who are more interested in applications of ideas than in developing new theory. Soon, the conference will tutorials and sessions on best practices. It will develop an exhibit hall that provides a great deal of revenue. Ultimately, it will become a trade show, a place to demonstrate new products. All the research and new ideas will be gone.

I reviewed the most recent proceedings of my software conference at the end of the summer. I had not been able to attend the meeting this year. I was struck by the number of papers that dealt not with software but with protocols. It had papers on protocols for coordinating debugging mobile apps, communicating between cloud services, and even running electric trains or packing cars.

Strictly speaking, protocols are not software. They are communication rules that are implemented by software. Yet, in our age of mobile computing, they have become a dominant topic of research. IEEE has many conferences entirely devoted to protocols, including one that puts the name “protocol” in the middle of its name.

I suppose that it is proper that protocols have taken a prominent position in computer research. After, we have less and less interest in software that runs in isolation and has no contact with other systems, physical devices, or even human beings. The current goals of computing all involve networking, mobility, and security. All of these topics require communications protocols.

Two of the original network pioneers have argued that “protocols will rank among the major innovations of the 1970s” and perhaps be the last great invention of the computer age. “For the first time,” the claimed “the design of computer systems puts the emphasis not on the internal management of resources, but on communication between resources of different systems.”

Of course, the rise of protocols was not as dramatic as its inventors anticipated, nor did it move into software conferences with the kind of speed that I have regularly observed in the published conferences. Instead of taking 6 or even 12 years to become a dominant technology, they required nearly thirty. The late 1970s, afterall, was the start of the software era, the years that marked the founding of companies such as Microsoft and Oracle.

Nonetheless, protocols have become a major topic of most software conferences. We have apparently established a great body of knowledge that allows us to build processes and systems. We are now most interested in the problems of coordinating systems. In some sense, they have also become the basic tools of conferences themselves. We run conferences with independent boards that can meet only rarely. We need formal ways of coordinating our conference planning. We write memos. We raise funds. We visit ministers. We follow budgets. We file reports. All of this we do in a carefully managed way with well established protocols.

We do this, of course, because we have abandoned forever the idea that we will ever have a single conference for the entire field of computing but have to settle for a couple hundred smaller meetings that deal with the vast topic of computing.

David Alan Grier circle image

About David Alan Grier

David Alan Grier is a writer and scholar on computing technologies and was President of the IEEE Computer Society in 2013. He writes for Computer magazine. You can find videos of his writings at He has served as editor in chief of IEEE Annals of the History of Computing, as chair of the Magazine Operations Committee and as an editorial board member of Computer. Grier formerly wrote the monthly column “The Known World.” He is an associate professor of science and technology policy at George Washington University in Washington, DC, with a particular interest in policy regarding digital technology and professional societies. He can be reached at