Chronological Scaling

I would like to say a few words about the challenge I think we face which I would like to call “chronological scaling”. Let me describe this in terms of a question a high school student might ask:

Will I still have what I write today
when my children enter high school?

This is a technological question which trades off complexity against longevity in a way that doesn’t fit nicely into the entrepreneurial formula. I have been working this problem since I built the first wiki, a wiki for pattern languages, a place that spawned many printed volumes, most volumes now regrettably out of print. My pattern language distribution has outlived the print distribution maintained by publishers. Of this I am proud. And I have learned a lesson. It is an economic reality that if today’s student wants to save their work they are going to have to save it themselves.

Let’s set a goal for chronologically scaling Innovate Oregon. Let’s assemble the parts and practices that will be needed. Let’s help schools build systems that they can legally own and afford to operated for a generation. Let’s call this the 25 year solution. Let’s make sure that every student, teacher and administrator can take what they do with them and share it with others even after they leave the school. This is not a business as usual proposition. Nor can we predict the technological future. But we can establish a tradition of honest respect for the digital lives that start in our schools.

How hard do we stretch our imagination now so as to not think one generation is an impossible goal?

.

We have discussed longevity among wiki developers.

My inspiration for federated wiki was a position paper called Folk Memory. The question remains, how can we remember digital anything in a way that outlives ourselves? In modern technology the question comes down to who is making the backups and why do they keep doing it? matrix

Federated wiki survived the conversion from Ruby to Node. This worked because it is simple minded json and all computation (at the time) was pushed to the client. Wiki is made more brittle with server-side components and even more brittle with transporters that depend on remote administration. matrix

Wiki needs to exist in the world full of remote resources. But we can't expect a farm operator to keep all of that remote content up and running. We've survived map services disappearing because we just held lat/lon and other map services appeared. We've survived authentication services disappearing but this has been more work. Fortunately this is only required to write, not read. But what would happen to all those youtube videos if youtube went away? We think we have them but we don't.

.

Bush's vision for Memex is often cited as inspiration for the link but in his example of the bow he also illustrates longevity and sharing. See As We May Think

Google helped me find a page I'd given an unusual name, Plate Blading, 20 years ago. It included a perl script that checked off my progress photographing licence plates. This still worked. See Plate Blading Remembered