Open Source – Eugene Eric Kim

Doug Engelbart, Human Systems, Tribes, and Collective Wisdom

Published December 18, 2018 by Eugene Eric Kim

Sunday, December 9 was the 50th anniversary of Doug Engelbart’s The Mother of All Demos. There was a symposium in his honor at The Computer History Museum and much media and Twitter activity throughout.

Among the many things said and written that caught my eye that weekend was a Twitter exchange between Greg Lloyd and Mark Szpakowski. Greg tweeted a quote from this Los Angeles Review of Books article:

“At the very heart of Engelbart’s vision was a recognition of the fact that it is ultimately humans who have to evolve, who have to change, not technology.”

Mark responded:

And yet 99% of the Engelbart tribe work has been on the techie Tool System. http://www.dougengelbart.org/firsts/human-system.html … used to say “coming soon”; now it has disappeared. Time to join up with recent progress on Social Technologies for Complex Adaptive Anticipatory Human Systems?

I agree with Mark, with one caveat: It depends on how you define the “Engelbart tribe.” Let’s explore this caveat first.

Tribes and Movements

There are many folks specializing in process design (what Doug would have categorized as “Human Systems”) who consider Doug a mentor or, at worst, an inspiration. I’m one of them, although I didn’t start (exclusively) from this place when I started working with him in 2000.

Three others in this group have been direct mentors to me: Jeff Conklin, who spent a good amount of time with Doug, and Gail and Matt Taylor, who didn’t, but who knew of him and his work. David Sibbet, the graphic facilitation pioneer, came across Doug’s work in 1972 and worked some with Geoff Ball, who was on Doug’s SRI team doing research on facilitating groups with a shared display. Those four people alone make for an impressive, accomplished, world-changing group.

There are also many, many more folks doing important work in human systems who aren’t familiar with Doug’s work at all or who don’t identify with him for whatever reason. Doug himself thought that lots of what was happening in both open source software development communities and in the Agile Movement were highly relevant, although he had nothing to do with either. At the Symposium celebrating Doug, Christina Engelbart, Doug’s daughter and the keeper of his intellectual legacy, connected the Lean movement to her dad’s work and invited Brant Cooper, the author of The Lean Entrepreneur, to speak.

An effective movement is an inclusive one. What matters more: Seeing Doug’s vision through, or establishing tribal boundaries? If the former, then it’s important to acknowledge and embrace the work of those who may not have the same heroes or conceptual frames of reference.

I don’t think many of us who loved Doug and were inspired by his vision have been very good at this, and unfortunately, our tribalism has extended to technologists too. After the Symposium, I had drinks with my friend, James Cham, who is a long-time fan of Doug’s, but who wasn’t lucky enough to spend much time with him. James told me that Dylan Field (co-founder of Figma Design) was inspired by Doug and that he had hosted his own celebration of the Demo that same Sunday that 300 people attended. Amjad Masad (founder of Repl.it, a tool that Doug would have loved) gave a thoughtful toast about Doug’s work there.

I didn’t know either Dylan or Amjad, and I certainly didn’t know that they tracked Doug’s work and were inspired it. I’m fairly certain that the organizers of the official celebration didn’t either. That’s pretty remarkable, given how small of a place Silicon Valley is. Now that we know, I hope we can start making some fruitful connections.

Capabilities and Collective Wisdom

The movement of folks committed to Doug’s larger vision is much larger than the “official” tribe to which Mark referred in his tweet. But even if we take into account this larger group, I think Mark’s criticism still holds.

Doug sought to make the world collectively smarter. He believed the path to achieving this would be a co-evolutionary process involving both tool and human systems. In other words, new tools would give us new capabilities, assuming we learned how to master them. Those new capabilities would inspire us to create even better tools. Rinse, and repeat.

As my friend, Travis Kriplean, pointed out to me this morning, we can already test this hypothesis. Technology has already evolved exponentially. Have our collective capabilities — or even more importantly, our collective wisdom — evolved with it?

Let’s narrow the question. Our ability to capture, store, and share information has improved by leaps and bounds since Doug’s Demo in 1968. Has our collective memory increased as a result of that?

If you were pinning me down, I would guess, “no.” The mere existence of those tools don’t guarantee that we remember more. Furthermore, the tools have a nasty side effect of overwhelm. But, these tools certainly create the potential for us to remember more — we just have to figure out how.

Right now, my eight- and 14-year old nephews have access to this blog, where they can read many of my innermost thoughts, including stories I wrote about them when they were younger. Right now, they can explore my Flickr, Instagram, and YouTube accounts without even having to ask for permission. If they asked for permission, I would probably let them go through my Google Maps Timeline, which is automatically harvested from my cell phone’s location data and which contains a comprehensive journal of my every day travels over the past few years. They already have access to lots of information about me, including my efforts to distill little bits and pieces of my experience. Most of this is purely the result of technology, with a little bit coming from my occasional discipline of sharing thoughts here and there.

But does any of this help them become wiser? If not, is it because our technology has not evolved enough, or is it because our human practices have not evolved with the technology?

The best example I know of a human system that evolved with the technology are wikis in general and Wikipedia in particular. Not enough people realize that wikis and Wikipedias aren’t just tools. They are a wonderful marriage of human and tool systems that created fundamentally new collective capabilities, exactly the type of thing that Doug envisioned. They are also 20-year old examples. I think this speaks very much to Mark’s critique.

White House Year in Photography

Published December 31, 2014 by Eugene Eric Kim

Pete Souza, the official White House photographer (who also served a similar role under Reagan) posted his Year in Photos on the White House website this week. I loved poring over these! As you might expect, Souza’s photos tell a powerful, insider’s story of President Obama’s 2014. They also serve as a primer on masterful photojournalism.

The photo above offered a brief look at Obama’s propensity to be present. Souza’s caption:

Surrounded by Secret Service agents, the President views the Golden Gate Bridge in San Francisco. Rather than immediately board the Marine One helicopter at Crissy Field, the President instead walked right past the helicopter to see a better view of the bridge on a clear summer day.

Here are some other nice examples of this.

Masterful photography and storytelling is nothing new. What I especially love is how the White House uses the Internet and social media to share these pictures. All of the pictures above (and many more) are shared more or less in real-time on Flickr. If you click through on any of the photos, you’ll notice that all of the camera metadata is there. (Souza uses a Canon 5D Mark III, often with a 24-70mm f/2.8 zoom.) Lots of professional photographers hide their metadata, a ridiculous, misguided attempt to maintain some kind of competitive edge.

You’ll also notice the licensing: U.S. Government Works. By law, federal work is not protected by copyright. However, that does not mean the work is in the public domain, as federal work is protected by other government statutes. For example, you cannot use government work to imply endorsement by a government official. No such luck with public domain or even Creative Commons.

I had never seen the U.S. Government Works statement before. It has very nice language around publicity versus privacy rights, an issue that has flummoxed me.

Souza also maintains an excellent Instagram account, where he shares iPhone photos and insider stories, including his thought process behind how he curated his 2014 photo essay. He also recently gave an excellent interview about his process.

This is what working openly looks like. This is what getting it looks like.

Happy New Year, everyone!

Blue Oxen Barnstars

Published March 24, 2009 by Eugene Eric Kim

I just started a podcast over at the Blue Oxen Associates web site entitled, Blue Oxen Barnstars. The name comes from the Wiki notion of Barnstars, and it’s an opportunity for me to tell the stories of people doing remarkable collaborative work in my community. The first episode is with Jeff Conklin, whom I have mentioned many, many times here. Take a listen! (N5G)

I had a great time putting the podcast together, and now that I have the basic mechanics of it down, and I plan on doing it often. The tools that are available for this are amazing. I used the Open Source Audacity for the sound editing, and I used Creative Commons music recommended by Paul Youlten. (N5H)

While you’re over there, I’d encourage you to subscribe to the Blue Oxen blog, as I’m starting to post many of my stories and insights into collaboration over there. (N5I)

The Unexpected Pleasures of Open, Transparent Processes

Published December 18, 2008 by Eugene Eric Kim

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)

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)

The Chandler Project

Published February 28, 2008 by Eugene Eric Kim

Almost 20 years ago, in my old stomping grounds at Dr. Dobb’s Journal, Mitch Kapor published an article on software design. He wrote: (MU0)

The lack of usability of software and poor design of programs is the secret shame of the industry. Given a choice, no one would want it to be this way. What is to be done? Computing professionals themselves should take responsibility for creating a positive user experience. Perhaps the most important conceptual move to be taken is to recognize the critical role of design, as a counterpart to programming, in the creation of computer artifacts. And the most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience. (MU1)

His manifesto stuck with me over the years, and when I started organizing the first FLOSS Usability Sprints with Aspiration, one of the first people I contacted with Mitch. Mitch not only agreed to sponsor our event, but he put me in touch with Mimi Yin and Katie Capps Parlante, two of the leads of the Chandler project. Both Mimi and Katie were enthusiastic about working with us, and Chandler became one of our first participating projects. (MU2)

At the time, Chandler was a lot of design and very little code. What intrigued me, though, was their design approach. They were aggressively committed to User-Centered Design, which was totally unique for an Open Source project. In many projects, Open Source or otherwise, interface design plays a secondary or worse role in the overall project. The interface is often designed after the fact. With Chandler, interface design played a core role in the overall design. (MU3)

Last fall, Chandler participated in the fifth incarnation of our sprints, and it was amazing to see how much progress the team had made. Not only was there working code, but there was an active developer and user community, and there was an ongoing commitment to their design approach. The project was also about to face a major transition, having reached the end of its incubation phase under Mitch. (MU4)

After reconnecting with Mimi and Katie, I decided it was time for me to start using Chandler. The timing for me was good. I had been a very happy user of todo.txt for personal use and a reluctant user of Basecamp for group projects. I wanted something that could replace both. The fact that it was a cross-platform desktop application was also appealing, because I regularly use three different platforms (Linux, Mac, and Windows) and because some of the people I’m currently working with do not have consistent access to the Internet. (MU5)

The Why of Chandler (MU6)

At its core, Chandler is a task manager in the spirit of David Allen‘s Getting Things Done methodology. You have items that you can organize into collections and prioritize as “Now,” “Later,” and “Done.” If you add a date to an item, it will appear on your calendar. And you can assign items to others. (MU7)

You can view your list of “To Do” items by collection, in a calendar (if they have dates), or in a dashboard view that provides an overview of all the different things you have to do. (MU8)

Simple, right? Well, yeah. That’s a good thing. But if you dig a bit deeper, you can see that this simple design has some very powerful consequences, and it all centers around this notion of the item. (MU9)

Items have titles and descriptions, which are free-form text. They have priorities and possibly dates. Items can belong to as many or as few collections as you’d like. Items can be shared with or assigned to others. (MUA)

The notion of an item is pretty generic, and in fact, you can see it in a lot of other applications as well. Email is the classic example. An email message can be thought of as an item. In fact, many people use their email as task managers. If they want to share an item, they email it to others (which is how Chandler works as well). If they want to categorize an item, they move it to a folder. If they’re lucky (for example, if they use Gmail), they can give an item multiple tags. (MUB)

But email has downsides. The interface is not optimized for task management, although there are plugins that help. Most clients do not support tagging, which means that you have to copy items to multiple folders, and those items do not stay in sync. And email messages are static, whereas an item should be able to evolve over time. (MUC)

Other applications that use this exact concept of an item are, well, other task managers: Basecamp, Remember the Milk, Bugzilla, RT, Trac, etc. In many ways, these are competing products, but in the Chandler world, they are actually complementary products. (MUD)

This is the hidden beauty of Chandler. Chandler recognizes that people will be using a lot of different tools, from email to RSS to other task managers. It doesn’t try to be The One Tool. Instead, it is designed to be interoperable. You can write plugins that synchronize items in other applications with items in Chandler, so that you can use Chandler to do what it does best, and other applications to do what they do best, and all the data stays in sync. (MUE)

Chandler essentially becomes a dashboard for knowledge work, a place where Knowledge Workers can live and get things done. Right now, email fulfills that role for most people. A tool like Chandler has a very good chance of supplanting email in this department, because it offers an interface that is more in line with what Knowledge Workers want to do. More importantly, it works with email rather than trying to replace it. (MUF)

Chandler works right now. I use it every day, and I’m productive in it. However, its great potential is still largely unfulfilled. The interface is still rough, and there are very few plugins that take advantage of the synchronization capabilities. Every once in a while, I find myself longing for todo.txt (although it should be relatively straightforward to write a command-line based interface to Chandler that emulates it). (MUG)

However, I believe that this roughness still works in Chandler’s favor. Why? Because as I noted earlier, Chandler is perhaps the only Open Source project in existence that aggressively integrates Open Source development principles with user-centric design. What we’re seeing right now is a spike, a product of Release Early And Often. But if you follow the design discussions — and you can, because it’s Open Source — you can see the ethos of User-Centered Design come through. The interface for the upcoming 1.0 release is going to be significantly better than the current design (0.7.4.1), and that will merely be scratching the surface of what is to come. (MUH)

Chandler has the potential to be a really great tool relatively soon. It’s not there yet. But if you’re excited about the idea that an Open Source development process can actually result in better software for real people, you should take a look now. More importantly, you should participate in the community, which is fantastic, thanks largely to the expert guidance of Ted Leung and the development team’s active participation. Chandler is definitely a project to watch. (MUI)