Ladies and gentlemen, boys and girls, welcome to another Six Degrees column. As usual, get your feedback into the comment box, and within the spirit of this specific column, I hope to see you all at All Things Open October 19-20 in Raleigh. I will be there with many other folks who write for Opensource.com, and I will also be giving a keynote, a presentation, and a lightning talk.

This month I want to share an important insight that I have developed in recent months. To start though, we need to wind back the clock…

In 2006 I joined Canonical as the Ubuntu community manager.

My first few years there were a whirlwind. I spent months on the road traveling to almost every open source technology conference in the world. I was getting out to meet people, grow the community, get a sense of needs and concerns, and more. Back then I wasn’t married and didn’t have a kid, so it was viable for me to spend months on end on the road.

Outside the conference grind we also had a key Ubuntu event every six months: the Ubuntu Developer Summit, also known as UDS.

My first UDS was in November 2006 in Mountain View, California, at the Google campus. There were around 100 people and the goal and focus of the event was to identify requirements for the next release of Ubuntu, map out plans, and document these plans as a series of specifications. These specifications would form the backbone of the work over the forthcoming six-month development period.

A short while later I started managing the editorial and structural content of UDS.

Rather unsurprisingly, as Ubuntu and Canonical grew, so did the event. Eventually UDS attracted around 700 people, required extensive venue, content, and logistical attention, and became very expensive to to run. While the event grew and added more plenary and networking content, the same core purpose of the event remained: to map out what we wanted to do in the next release of Ubuntu.

Unfortunately, as the event grew, the value of UDS in terms of core planning output seemed to hit a ceiling. Back in the early days UDS achieved solid plans with a relatively limited investment, but in the later days it was a lot of money for what we saw out of it.

Thus, Canonical leadership proffered the notion of moving UDS to an online setting. But could we replicate the notion of UDS online?

I called a meeting with my team to plan what it could look like. We put together an interesting concoction of Google Hangouts (for live discussions) mixed with IRC, integrated note-taking, and specification development. The result was http://summit.ubuntu.com, which at the time was a pretty innovative way to have an online summit (if we say so ourselves!).

Before long we ran our first Ubuntu Developer Summit online and it carried many of the same elements of the in-person event. I gave the intro, Mark Shuttleworth keynoted, we had multiple tracks, plenary presentations, and the wrap-up.

Did it work? Well, kinda.

From a content and logistical perspective, it worked great. In fact, it was arguably better than the in-person event. Now everyone could join UDS, not just those who could travel to the event (although for many it was at an awkward time in their location). All of the content was recorded, which made it easier to share, and it provided journalists, bloggers, and social media folks with the ability to embed videos of the Ubuntu development process into their content and write-ups.

The challenge, though, was not the content and logic; it was the focus, culture, and social elements, and here the online event was sorely lacking.

Core ingredients

You can break all communities down into three core ingredients: capabilities, experience, and relationships.

The capabilities ingredient refers to the skills, knowledge, tools, and potential that the community possesses. Many collaborative events, such as UDS, focus extensively on those pieces. We have discussions for how to improve our capabilities, our tooling, to refine our approaches, and to deliver better results.

The experience ingredient refers to the shared body of knowledge and practical experience that the community has developed. Any grouping of people—whether it is a company, community, family, or otherwise—will do things, learn from outcomes, and develop wisdom around what works and what doesn’t. Invariably these experiences are shared in keynotes and formal presentations at events.

The relationships ingredient refers to building strong connections with people you work with so you feel a sense of engagement, morale, and belonging. At in-person events this often happens in the much touted hallway track (people catching up and chatting over a coffee in the corridor) as well as in restaurants, bars, and elsewhere. This is where online events commonly fall short.

While there are often attempts in companies to provide functional methods of building relationships (such as those cheesy team-building exercises most of us have suffered through), relationships usually form in more organic ways. Getting to know someone is often a mixture of chatting in the hallway, having breakfast together, sharing ideas at the end of a presentation, having a couple of drinks together in a bar, and other ways of getting to know each other.

The venue and proximity are not the only important pieces though. Relationships also typically form when there is a sense that personal barriers have been dropped a little. When people feel comfortable sharing experiences, expressing concerns, riffing on ideas, and confiding in each other, genuine relationships and alliances form.

It is these relationships and alliances that are at the backbone of a great community. Yes, we can get people online for meetings and to plan and map out work, and we do this every day in companies and businesses across the world. We have to augment these functional meetings though with real opportunities to build real relationships; if we skimp on this, we skimp on a real sense of community.

Face-to-face is essential

The challenge with all this, particularly for companies who are often footing the bill for these in-person events, is that relationships offer intangible value.

Most companies operate under economic theory and economists like to put numbers in spreadsheets to determine a Return On Investment (ROI). It is fairly straightforward to determine ROI in terms of content (keynotes, talks, practical output, etc.), but it is far more difficult to measure the impact of relationship development. Here’s the catch though: when the relationships are not developed we sadly see the results in very measurable ways…a loss of employees and community members.

This puts a lot of organizations in a tough spot. On one hand, they typically don’t want to be spending money on social activities such as dinners, drinks, and mixers, but the reality is that if you don’t do this, you don’t foster those kinds of relationships.

This is particularly important when it comes to open source. The open source world is a fabric of interconnected personalities, relationships, and expectations. It is critically important to not just get work done but to also ensure the people doing the work feel a sense of connection. To this end, face to face communication and collaboration is essential.

…and this is why I changed my perspective on the value of face to face events. I always believed they were important for strong communities, but I considered them something of a “nice to have.” From my experience in my career though, they are not merely a “nice to have.” They are an essential part of building a healthy collaborative culture.

Six
Degrees

This article is part of Jono Bacon’s Six Degrees column, where he shares his thoughts and perspectives on culture, communities, and trends in open source.