Connecting Past and Present

Doug Engelbart’s passing earlier this summer has me reflecting a lot on our friendship, the work we did together, the influence he had on my life and my career, and also larger issues around connecting past and present. Talking with my former HyperScope teammates reminded me of how much fun we had together. I’m proud of what we did, but I’m even prouder of how we did it.

We worked in two ways that were particularly innovative. First, we were an open project. Anyone could participate in any of our meetings, including the face-to-face ones. We even provided food.

Several people (but not Doug) were nervous when I first proposed doing this. They were concerned about people disrupting the process. I wasn’t worried about disruption, because we had a strong core team, and I knew how to facilitate an open process. In particular, “open” does not mean everyone is equal. As I explained to everyone who joined us, I invited everyone to speak up, but we had a task we needed to complete, and I reserved the right to direct the conversation and kick people out if they didn’t respect the ground rules.

I had to assert that right a few times, but otherwise, the openness overwhelming improved the project. We had a number of people make really valuable contributions, and Craig Latta in particular came out of nowhere to become an important part of our core team.

Second, I proactively invited members of Doug’s original lab to join us. I wanted the team to learn everything we could from the people who had done it before us, and I also wanted these folks to understand how much we valued them. The whole team agreed that this was one of the best parts of the experience. Not only did we learn a ton, but we felt like an extended family.

I’m constantly amazed how rarely this occurs. People don’t think to reach out to their forebears, and they miss out on a huge learning opportunity. The HyperScope project was an unusual situation (although Silicon Valley is rife with these opportunities, given how compressed the history of our industry is), but these opportunities also apply to projects where people have recently left.

I think that most of the time, it simply doesn’t occur to people. Sometimes, there are tricky politics and emotions involved. Often, it’s because we don’t value the hard-earned knowledge that we can learn from those who came before us. This is why so many companies often lay people off without taking into account the loss of institutional knowledge.

Regardless of the reasons, I think it’s unfortunate that connecting the old with the new is such a rarity, and I’d love to see this shift.

The Unexpected Pleasures of Open, Transparent Processes

Every project has a team. How those teams form is an interesting question. For the most part, the “leader” of a project decides who is on or off a team, and then they go off on their merry way.    (N2B)

If that work is done openly and transparently, then that opens up the possibility of attracting other contributors. This is the essential goal of movement-building, where the desire is to get other people to act. It’s also what makes Open Source software projects and Wikis work.    (N2C)

The question is, how open and transparent should the process be? Being fully open invites distraction. When the Chandler Project was first announced, list activity went through the roof, and the signal-to-noise ratio was very low. People were galvanized by Mitch Kapor‘s involvement and, of course, everyone had an opinion. It was a dangerous time for the project, because the goals were not concrete, and the process for how to reach concreteness had not yet been established.    (N2D)

How do you balance the desire to be open (and attract outside contributors) with the need to get things done? The key is clarity of vision and process, as well as a realistic assessment of the risks and rewards.    (N2E)

When Doug Engelbart asked me to lead the HyperScope project in 2006, I knew that it was imperative that we deliver. (Visionaries have a sometimes deserved reputation for never actually delivering a product.) At the same time, we really wanted to spread the core ideas widely and galvanize the community.    (N2F)

We had already decided that the project would be Open Source, which meant that some of the processes would inherently be open — open source code repository, open mailing list, open Wiki, and so forth. We also instituted good practices — regularly posting summaries to the community, carrying on much of our activity online (a key principle of the Apache community), and so forth.    (N2G)

I also decided that our weekly face-to-face meetings would be open as well. This was the biggest risk for a few reasons. Doug was going to attend the meetings, and there was a possibility that people would come just to meet Doug. This, in my opinion, was actually a good thing, as long as we weren’t overwhelmed with people and as long as guests did not prevent us from getting things done. I reasoned that we wouldn’t be for two reasons. First, Doug isn’t as much of a household name as he should be, certainly not as much as Mitch Kapor for example. (This is sad and the topic of a future post.) Second, neither was I. I have a large social network, but it’s not enormous, and it’s fairly intimate with lots of trust. I didn’t think a huge number of people would see my announcement, and I trusted those who did to do the right thing.    (N2H)

I was confident in my ability to tightly facilitate the meetings, and I also felt strongly that the rewards of openness, in our case, far outweighed the risks. I was also prepared for the possibility that no one would show up, despite the openness.    (N2I)

I was blown away by who did show up. We had a lot of folks from the old Augmentation Research Center, which was an absolute delight. Many people told me afterwards what a delight it was for them to have us pepper them with questions about their 50-year old work. We had many friends and friends-of-friends visit, all of whom greatly added to the conversation.    (N2J)

Before each meeting, I welcomed our guests, but I also explained that it was a working meeting, and I asked that they respect our need to get things done and participate accordingly. For the most part, that’s all the facilitation I needed to do. I occasionally had to reign people in, but I usually found myself actually encouraging our guests to participate.    (N2K)

At our launch party, I gave special T-shirts to each team member. Two of the people on the team and on the T-shirt were people from the community who found out about our work on their and dropped in. One was John Deneen, a long-time fan of Doug’s, who videotaped and photographed all of our meetings. The second was Craig Latta, a Smalltalk guru who had worked on a variety of old-school hypertext projects in the past and who ended up helping us tremendously on a variety of technical challenges.    (N2L)

https://i0.wp.com/static.flickr.com/97/236665573_2b0e38419e_m.jpg?w=700  T    (N2M)

When I work with groups, I often encourage them to challenge their own assumptions about openness and transparency. Extra effort is required, and sometimes, the hoped-for benefits do not occur. However, more often than not, folks are pleasantly surprised — sometimes even amazed — by what emerges.    (N2N)

purple-include: Granular Transclusions for the Common Man

Many thanks to Jonathan Cheyer, Craig Latta, and Kaliya Hamlin for coming to the HyperScope sprint this past weekend, and special thanks to Christina Engelbart for hosting. Also thanks to Thom Cherryhomes and others who hung out with us on IRC. The notes from the day are up on the Wiki, and I put up some pictures as well.    (MEL)

https://i2.wp.com/farm2.static.flickr.com/1134/681861752_857ef74d28_m.jpg?w=700    (MEM)

The big news, though, is that Brad, Jonathan, and I wrote a cool hack called purple-include, based on Mark Nottingham‘s most excellent hinclude. It lets you transclude granular chunks of content from any web site by using an img-like tag. Check out the examples. I think this will go a long way in making Transclusions more common on the Web.    (MEN)

You address granular content either by using a fragment identifier that the document author provides (such as a Purple Number) or by using an XPath expression. Thanks to Tony Chang for his cool interactive XPath tester.    (MEO)

The planned next step is to create a Firefox plugin that adds a “Transclude” option when you right click inside of a browser text widget. This will allow you to transclude copied content, rather than paste it. Don’t know whether any of us will get to this soon, so we encourage the lazy web and all you Firefox hackers to beat us to the punch.    (MEP)

This was my first non-trivial foray into JavaScript, and I was disturbed by what I saw. The language itself is not horrible, although its object system makes Perl 5 look like Smalltalk. What’s shameful is its API support. We had to use a very ugly, although apparently common hack to get a DOM of external web pages. This is pure silliness. The browser is already doing the hard work of parsing broken HTML and XML and turning it into a DOM. Why not easily expose that functionality to the developer?    (MEQ)

As Brad dryly noted, “Welcome to my world.”    (MER)