As far as ideas that came out of discussions at HotOS’09, this one I can’t really take credit for: credit goes to Colin Dixon at The University of Washington. But as far as I know he doesn’t have a blog1, so I get to blog the idea!

I remember this idea emerging out of the one of the typical conversations carried out by young CS researchers after meeting, which is animated by the irritation associated with the feeling we get at times from more senior people that “everything old is new again.” All great systems research was done in the 70s and 80s. There’s no such thing as a new technology. Every idea you have someone had before. Every system you build is just a reflection of earlier glories. And on and on. It’s pretty depressing, really, and makes you wonder why anyone would get excited about a future building systems listening to some of these voices. This sort of attitude also tends to leech away any enjoyment we (junior people, that is) get from new, to us at least, discoveries and revelations. Who cares if I’m late to the party? I’ve arrived! I made it! Let’s party!

It also seems, at least to me, that an overdeveloped concern for intersection with the past seems to emerge from a type of technological (over)determinism that’s hard to justify once bared. It’s the sort of thinking that believes that, if we are ever at point A, then we are going to be next at point B. So if you find yourself at A, why brave ahead yourself? Save yourself the trouble, cut out the middle man, join the conversation at B. This sort of thinking also seems linked to considering the act of building a system in an overly-scientific way as an experiment, rather than as a set of design decisions made in a certain (time varying) context. I can certainly imagine that sciences that seek to develop an understanding of a (at least, fairly) fixed universe, like Physics2 would frown on performing the same experiment twice. After all, it’s unlikely that the laws governing the universe have changed much sense (Newton, Bohr, Insert Favorite Famous Physicist Here) performed it (centuries, decades) ago. (If they had changed, would they be laws?)3

Of course, in Computer Science everything needs a (t) attached to it, since our world does change. We are simultaneously building and studying it. So rather than being at point A, we are at point A(t), and then we make a bunch of decisions at times t + Δ1, t + Δ2, etc., and we end up at B(t + Δtotal). So what? Well, if at some later point, say t’, we again start at A(t’), we might not end up making the same choice. We might end up somewhere else, maybe at C(t’+Δtotal). We might deploy a different set of ideas, which maybe have been around for some time, but maybe now we’re ready to take this whole journey seriously. This time.

So what can we do here? Is there a way to simultaneously accomplish two things:

  • Encourage researchers, particularly younger ones, to take the past seriously and avoid making the same mistakes over and over again.
  • Ensure that ideas aren’t excluded from the present discourse simply because they might have been explored in a similar, or different, context years ago, on the premise that some of those ideas might simply not have found their time yet?

I wasn’t sure there was, but Colin made a brilliant suggestion: a statue of limitations on old ideas.4 The idea is simple: we set a reasonable time period, say 10 years, after which ideas go “out of scope”, meaning that they are no longer fair game for dinging a new paper for repeating. Individual conferences could each set their own “novelty timeout”5, with some venues emerging out a desire to reexamine the quite recent past (low novelty timeout), and others preferring a high bar on originality (high novelty timeout).

To those that might fear that this would further reduce the burden on authors as far as understanding and citing related work, I would argue that it might have the opposite effect. With an understanding of the pertinent novelty timeout, authors will be less afraid of finding out that some guy at Xerox PARC scribbled out the outline of my SOSP’09 paper on a napkin in a bar in 1972. A novelty timeout could also be paired with a recommended reading list for each conference. Essentially, Sensys might say to submitting authors: we expect you to be familiar with work that appeared in Sensys, IPSN, DCOSS, HotEmNets, etc. for the last 5 or 10 years, as we will be and will penalize those who have missed pertinent related efforts.

A novelty timeout seems like a reasonable way of balancing competing goals: ensuring that researchers have enough time and rope to do fresh things, even if they revisit old ideas; and incentivizing proper consideration of the past.

  1. 1. Pourquoi pas, Colin? []
  2. 1. Where I started. []
  3. 2. I have a separate set of ideas brewing about Computer Science as science or art, but those will brew until another day. []
  4. 3. There's probably a snappier way of phrasing this... ideas? []
  5. 4. Another attempt at a name, maybe an iota snappier than the first? []