*Recently a friend of mine asked me to contribute to a free book that collates together the experiences of various people involved in Open Source. She asked me to write about what I would tell myself ‘if I knew what I know today’. I was pretty intrigued by this, so was happy to take part, and I asked if I could re-print my contribution here. She was happy with that, so here it is. It is quite long (because it is for a book), but it might be of interest, particularly for those of you interested in community management. Oh, and these are my views, and not the views of my employer, Canonical*.

I first learned of Linux and Open Source back in 1998. While the technology was gnarly and the effort required to get a smooth running system was significant, the concept of this global collaborative community transfixed me. Back then I had no knowledge, limited technical skills, and zits.

As an angsty teenager complete with long hair and Iron Maiden t-shirt, my path was really already mapped out for me in the most traditional sense; I would go to school, then college, then university, and then a job.

Fourteen years later, the path I actually took was by no means traditional, and that intrinsic fascination with community has taken me around the world and thrown me into some engrossing challenges. It is interesting to sit back and reflect on this period of time. Well, it might be interesting for me…you might want to skip to the next chapter… 🙂

…

Still with me? OK, let’s roll.

### Science vs. Art

I have always believed that community management is less of a science and more of an art. I define science as exploring methods of reproducing phenomena through clearly understood and definitive steps. In the science world if you know the theory and recipe for an outcome, you can often reproduce that outcome like anyone else.

Art is different. There is no recipe for producing an incredible song, for creating an amazing painting, or sculpting a beautiful statue. Similarly, there is not really any reproducible set of steps for creating a thriving community. Sure, there are tricks and techniques for achieving *components* of success, but the same happens for other art-forms; we can all learn the notes and chords on a guitar, it doesn’t mean you are going to write the next *Bohemian Rhapsody*. The formula that generates Bohemian Rhapsody is *one part learned skill and one part magic*.

*Sometimes magic plays a cruel joke on us*.

Now, I am *not* suggesting that community management is this frustratingly hip and introverted artform that only the blessed few with such talents can achieve. What *I am* instead lamenting is that there is no playbook for how to create a wonderful and inspiring community; it is still *one part learned skill and one part magic*, but the *magic part* is not divinely anointed to you by the gods, but instead obtained by trying new things, being receptive to feedback, and getting a feel for what works and what doesn’t.

Rather frustratingly, this means that there *is* no single recipe to follow for the magic, but there is still an opportunity to share the *learned skills*, as I have sought to do with [The Art of Community](https://www.artofcommunityonline.org/) and the annual [Community Leadership Summit](https://www.communityleadershipsummit.com/).

Before I get started reflecting, and for those of you who have not bored yourself into oblivion by following my career, I will summarize the communities I have worked with so we can define the context. In a nutshell, I started out in my hairier days by producing one of the UK’s first Linux community websites called Linux UK and got involved in the Linux User Group (LUG) community. I went on to create my own LUG in Wolverhampton in the UK and founded the Infopoint project to encourage LUGs to advocate Linux at computer fairs across the UK. I then went on to contribute to the [KDE](https://www.kde.org) community, founded the KDE::Enterprise site, got the KDE Usability Study going, and contributed to a few little apps here and there. I then founded the PHP West Midlands user group and started also getting interested in [GNOME](https://www.gnome.org). I wrote a few apps (GNOME iRiver, XAMPP Control Panel, Lernid, Acire) and also co-designed and wrote some code for a new simplified audio app called Jokosher. Around this time I co-founded the [LugRadio](https://www.lugradio.org/) podcast which would run for four years with over 2million downloads and spawning five live events in the UK and USA. At this time I also started work as an Open Source consultant at the government-funded OpenAdvantage where I really got a chance to cut my teeth in community and working with organizations across the West Midlands to help them to move to Open Source. After a few years at OpenAdvantage I moved on to join [Canonical](https://www.canonical.com) as the [Ubuntu](https://www.ubuntu.com) community manager and developed a team of four and together we are involved in a wide variety of projects in Ubuntu and Canonical.

Still with me?

Wow, you are persistent. Or bored. Probably bored. There will be an exam at the end; that’ll learn you… 🙂

### Reflecting

So this brings me to the focus of this piece – the curios question of *if I knew what I did today, what would I tell myself?* Over the course of my career so far I believe that everything I have learned can be boiled into two broad buckets:

* **Practical** – the tips and tricks of the trade; e.g. approaches to communication mediums, using technology in different ways, event planning techniques, project management approaches etc.
* **Personal** – core life lessons and learnings that affect the approach you take to your world.

I am not going to talk much about the *practical* – you should should [read my book](https://www.artofcommunityonline.org) for more on that topic (the book also covers *a lot* of the personal too).

Today I am instead going to focus on the personal life lessons. Approaches and practices will always change, but the life lessons don’t so much change but grow and evolve as we get wiser.

*Not wise.*

### The Importance Of Belief

Communities are fundamentally *networks of people driven by belief*. Every community has an ethos and a focus. This could be something as grandiose as documenting all human knowledge or changing the world with Free Software, or it could be as humble as providing a local group for people to get together to talk about their favorite books. Whether life changing or just a bit of fun, each community has a belief system; the humble book club still sees tremendous value in providing a fun, safe and free environment to share reading preferences and recommendations. It might not change the world, but it is still *a good thing* and something people can get behind.

The underlying often unwritten rule of community is that *every contribution from a community member must benefit the wider community*. This is why it is fun to write a patch that fixes a Free Software bug, contribute documentation, run a free event or otherwise, but it is rare that anyone is willing to contribute as a volunteer if their contribution only benefits a single person or company.

Of course, I am sure all of you cynical bastards are now going to try and find an exception, but remember that this decision is typically deeply personal – the community member decides how comfortable they are that their contribution will benefit everyone. As an example, some would argue that any contribution to [Mono](https://www.mono-project.com/Main_Page) would only benefit Microsoft and the ubiquity of their .NET framework, but hundreds of contributors participate in Mono because they don’t see it this way – they see their contributions as a valuable and fun way of making it easy to empower Free Software developers to write Free Software more easily.

If I was talking to the Jono of 1998 I would really emphasize the importance of this belief. I had a hunch about it back then, but I have since seen countless examples of belief truly inspiring people to participate. I have often talked about the story of the kid from Africa who emailed me to tell me how he would walk three hours to and from his nearest Internet cafe to contribute to Ubuntu. He did this because he *believed* in our mission to bring Free Software to the masses. The same can be said for the tremendous growth in [Wikipedia](https://www.wikipedia.org/), the incredible coming together of the GNOME community around GNOME 3, the success of [OpenStreetMap](https://www.openstreetmap.org/) and many other examples.

Belief though is not a PR stunt. It has to be real. While each of us has different belief systems, some map their belief systems to software, some to education, some to knowledge, some to transparency or whatever else, you can’t concoct a belief system unless it serves a valid goal that a group are likely to care about. Sure, it can be obscure, but it has to be *real*. With the success of Open Source, we have seen some examples of some companies trying to use similar language and approaches around belief, but applying it to self-serving needs. I could invent a belief of “*let’s all work together to help Jono get rich*” and concoct some nonsense of the benefits of this belief (e.g. if I am rich I can focus on other work that would benefit other communities, my future kids would get a wonderful education and upbringing and this will benefit the world), but it would be rubbish.

*No one wants to be this guy. Or that guy.*

As such, belief is a strong driver for collaboration and contribution, but it must be met with respect and balance. While it can be a trigger for incredible change, it can also be hugely destructive (e.g. some television preachers who use religion as a means for you to give them money, or fake psychics who use cold reading to latch onto your belief to desperately try and re-connect with a lost loved one).

### Your Role

Community managers play an interesting role these days. In the past I have talked about there being two types of community managers; those who go out and give presentations and wave their hands around talking about a product or service, and those who work with a community of volunteers to help them to have a fun, productive and enjoyable collaborative experience. I am more interested in the latter – I feel that is what a *real* community manager does. The former is a fine and respectable position to have, but it is more in the area of advocacy and public relations, and requires a different set of skills. I have a few tips here I think are interesting enough to share.

The first and probably most important lesson is having a willingness to accept that you *can and will be wrong sometimes*. In my career so far I have got some things right and some things wrong. While I believe I am generally on the right path and most of my work is successful, there have been a few turkeys here and there. These screw-ups, mishaps and mis-steps have never been out of maliciousness or carelessness, they have instead typically been from me overshooting the target of what I was trying to do.

This seems like a pretty obvious point, but it gets less obvious when you have a fairly public role. By and large, community managers are often seen as representatives of a given community. As an example, I know that I am personally seen as one of the public faces of Ubuntu, and with that responsibility comes the public pressure of how people perceive you.

For some community leaders, having the spotlight shone on them causes a defensive mechanism to kick in; they cringe at the idea of making mistakes in public, as if the chattering masses expect a perfect record. This is risky, and what has been seen in the past is that we get public leaders who essentially never accept that they have made a mistake due to this fear of public ridicule. This is not only a fallacy (we *all* make mistakes), but it also doesn’t set a good example to the community of a leader who is honest and transparent in both the things they do well and the things they do less well. It is important to remember that we often gain respect in people *because of their acceptance of mistakes* – it shows a well rounded and honest individual.

Not entirely rounded.

I remember when I first became a manager at Canonical and at the time Colin Watson and Scott James Remnant, two original gangstas from the very beginning of Canonical and Ubuntu, were also managers on the Ubuntu Engineering Team. We would have our weekly calls with our manager, Matt Zimmerman, and on these calls I would hear Colin and Scott openly accepting that they were not good at this, or had made a mistake with that; they were stunningly humble and accepting of their strengths and weaknesses. As a rookie manager I was a little more tight-lipped, but it taught me that this kind of openness and honesty is not only good as a manager but as a community leader and since then I feel no qualms in publicly admitting to mistakes or apologizing if I screw up.

### Listening

In a similar way, while openness to mistakes is important, another lesson is the importance of being a good listener and learning from our peers. In many cases our communities look to community managers and leaders as people who should always be providing guidance, direction and active navigation of the project and it’s goals. This is definitely a responsibility, but in addition to the voicing of this leadership, it is also important to be a passive listener, providing guidance where appropriate and learning new lessons and insight.

Our community members are not just cold, hard, machines who perform work; they are living, breathing, human beings with thoughts, opinions, feelings and ideas. I have seen many examples, and I have accidentally done this before myself, where someone is so used to providing guidance and direction that they sometimes forget to just sit down and listen and learn from someone else’s experience. Every industry is filled with thought leaders and scholars…famous people who are known for their wisdom, but in my experience some of the most revolutionary life lessons that I have learned have come entirely from non-famous, day-to-day, meat-and-potatoes community members. Being a great listener is not just important to help us learn and be better at what do, but it is critical in gaining respect and having a great relationship with your community.

### On vs. Off Time

While on the subject of how we engage with our community, I have another take-away that I only truly processed in my own mind fairly recently. Like many people, I have a number of different interests that fill my days. Outside of being married and trying to be the best husband I can be, and my day job as the Ubuntu Community Manager, I also have projects such as [Severed Fifth](https://www.severedfifth.com), the [Community Leadership Summit](https://www.communityleadershipsummit.com/), and some other things. As you would naturally expect, my days are committed to my day job – I don’t spend time at work working on these other projects. As such, as you would naturally expect, when my work day ends I start working on these other projects. The lesson here is that *it is not always clear to your community where the lines are drawn*.

Over the years I have developed a series of online facilities that I use for my work and viewpoints. My [Twitter](https://twitter.com/jonobacon), [identi.ca](https://identi.ca/jonobacon), [Facebook](https://www.facebook.com/jonobacon) pages, [this blog](https://archivedblog.jonobacon.com), and some other resources are where I talk about what I do. The challenge is that if you take into account these public resources, my public representation of the Ubuntu project, and the wealth of timezones across the world, it does not take an Einstein to confuse whether I am writing about something as a Jono thing or a Canonical thing.

*”Einstein was best known as a badass Hungry Hippos player”. [citation needed]*

This has caused some confusion. As an example, despite my repeated clarifications, [OpenRespect](https://openrespect.org/) is not and never has been a Canonical initiative. Of course, some idiots choose to ignore my clarification of this, but I can see how the confusion could arrive nonetheless. The same thing has happened for other projects such as *Severed Fifth*, *The Art of Community* and the *Community Leadership Summit*, of which none are, or ever have been part of my work at Canonical.

The reason why I consider this a lesson is that I have seen, and at one point shared the view that “*of course it is a spare time thing, I posted that at 8pm at night*” and shrug of concerns of the lines blurring. When you have a job that puts you in a reasonably public position, you can’t have the luxury of just assuming that; you have to instead assume that people are likely to blur the lines and you have to work harder to clarify them.

### Don’t Travel Too Much

On the topic of working for a company that employs you to be a community leader, you should always be aware of the risks as well as the benefits of travel. This is something I learned fairly early on in my career at Canonical. I would see the same faces over and over again at conferences, and it was clear that these folks had clearly communicated the benefits of travel to their employer, as I had done, but I also came to learn the risks.

I would travel and it would not only be tiring work and emotionally exhausting, but I would also be away from my email more, on IRC less, unable to attend many meetings, and have less time to work on my work commitments. As such, my role would largely become that of getting out and visiting events, and while fun, this didn’t serve my community as well as it should have done. As such, I fairly dramatically cut my travel – if fact, I went to the Linux Collab Summit a few days ago, and outside of Ubuntu events that I needed to attend, I had not made it to conference for a nearly a year. Now I feel the pendulum has swung a little too far in the other direction, so it is all about balance, but I also feel I serve my community better when I am able to take to the time to be at the office and be online and accessible.

### Planning

For some folks, the role of a community leader or community manager is one that is less about pre-disposed structure and instead more interrupt-driven. When I started out, I used to think this too. While there is absolutely no doubt that you do indeed need to be interrupt-driven and able to respond to things that are going on, it is also essential to sufficiently plan your work for a given period of time.

*Apparently, awesome at laying plans.*

This planning should be done out in the open where possible and serves a few functions:

* **Shares plans** – it helps the community to understand what you are working on and often opens up the doors for the community to help you.
* **Assurances** – it demonstrates that a community leader is doing something – your community can see your active work happening. This is particularly important, as much of the work of a community leader often happens out of the view of the wider community (e.g. having a one-on-one conversation with a community member), and this lack of visibility can sometimes generate concerns that little is happening in key areas, when instead a lot is going on behind the scenes.
* **Communicates progress up and down the ladder** – this is relevant if you are working for a company – having some solid planning processes in place demonstrates your active work to your management, and it also re-assures your team that they will always know what to work on and create great value for the community.

Over the years I have put more and more importance in planning, while still retaining enough time and flexibility to be interrupt-driven. When I started as the Ubuntu Community Manager my planning was fairly personal and ad-hoc – I took the pulse of the community, and I applied my time and resources to tend to those areas as I saw fit.

Today I break goals into a set of projects that each span an Ubuntu cycle, gather input from stakeholders, put together a roadmap, track work in [blueprints](https://blueprints.launchpad.net/), and assess progress using a variety of tools and processes such as my [burndown chart](https://people.canonical.com/~pitti/workitems/natty/canonical-community.html), regular meetings, and more. While the current approach requires more planning, it helps significantly with the benefits covered in the above bullet points.

### Perception and Conflict

One thing I often hear about in the world of community management and leadership is the view that *perception is everything*. Typically when I hear this it is in response to someone getting the wrong end of the stick about something, often in a conflict period.

Of course, perception *does* indeed play an important part in our lives, but what can fuel incorrect or misaligned perceptions is lack of information, mis-information, and in some cases, heated tensions and tempers. This can be some of the most complex work for a community leader, and I have come away with a few lessons learned in this area too.

Communities are groups of people, and in every group there are often common roles that people fill. There is usually someone who is seen as a rockstar and hero, someone who is sympathetic to concerns and worries and a shoulder to cry on, someone who is overtly outspoken, and often someone who is…well…deliberately difficult. Heroes, sympathetic ears and outspoken folks are not particularly challenging, but deliberately difficult people can be complex; if someone is being overtly difficult to deal with, it can cause tensions to form with other members and bring conflict to an otherwise happy community. We need to nip those issues in the bud early.

*Not how you nip something in the bud.*

Part of the challenge here is that people are people, groups are groups, and it is not uncommon for a single person or a few people to become known and complained about behind closed doors as difficult to work with. In addition to this, most people don’t want to get involved in any conflict, and as such the person being complained about can sometimes never actually know that people see them this way, as no-one wants to confront them about it. This results in one of the most dangerous situations for a community members – a reputation is spread, without the knowledge of the person who it applies to, and because they never know, they never have an opportunity to fix it. That is a pretty sucky position to be in.

A common response to this conclusion is the view that “*they are so difficult to deal with that trying to reason with them will fall on deaf ears anyway*”. While this certainly does happen from time to time, don’t be so quick to assume this will be the outcome; there has been a few times when I have had the uncomfortable experience of feeling I need to share with someone the reputation that they have developed, and in virtually all cases it has been a real surprise to them, and they have almost all modified their behavior based on the feedback.

On a related note, while often not a common part of the daily routine of a community leader, conflict will often raise it’s head here and there. I just wanted to share two brief elements about conflict.

The first is understanding how conflict forms. To introduce this, let me tell you a little story. Last week a friend of mine flew out to the Bay Area for a conference. He arrived in the evening, so I picked him up from the airport and we went to the pub to catch up. While there he started telling me how disappointed he was with Obama and his administration. He cited examples of health care reform, Wall Street reform, digital rights and more. His agitation was not with the policies themselves, but with Obama not doing enough. My perspective was a little different.

I am not a democrat or a republican; I make my decisions on each issue, and I don’t align myself with either party. Where I differ to my friend though is that I am a little more sympathetic to Obama and his daily work. This is because I believe that he, and anyone else in a public position, whether as internationally recognized as the president, or as obscure and specific as a community manager, realizes that the story read and understood by the public is often only a fragment of the full story. There has been cases in the past where something controversial has kicked off in the communities that I have been a part of, and many of the commentators and onlookers have clearly not had a full knowledge of the facts either because they have not picked up on the nuances and details of the topic or some parts of the story have not been shared.

Now, I know what some of you are going to say – some parts not shared?! Surely we should be transparent? Of course we should, and we should always strive to be open and honest, but there are some cases when it would be inappropriate to share some parts of the story. This could be because of private conversations with people who don’t want their comments shared, and also just being classy in your work and not throwing dirt around. As an example, I have always had a very strong policy of not throwing cheap shots at competitors, no matter what happens. In the past there has been some questionable behavior from some competitors behind the scenes, but I am not going to go out and throw dirt around as it wouldn’t serve a particularly useful purpose, but with that I have to accept that some community critique will only have part of the picture and not be aware of some of the behind the scenes shenanigans.

*Not a competitor*.

Finally, on the topic of conflict, I believe a real life lesson I have learned has been the approach in which critique and successful outcomes should be approached. Although blogging has had a hugely positive impact on how people can articulate and share opinions and perspectives, there has been a dark side. Blogging has also become a medium in which much overzealous opinion can sometimes be expressed a little too quickly. Unfortunately, I have a rather embarrassing example of someone who fell into this trap: yours truly.

First, a bit of background. There used to be a company called Lindows that made a version of Linux that shared many visual and operational similarities to Windows. Microsoft frowned at the name “Lindows,” and a fight started to change the name. Lindows initially resisted, but after mounting pressure, changed their name to Linspire.

Now to the issue. Let me take the liberty to explain in the words of the article itself:

> Recently a chap named Andrew Betts decided to take the non-free elements out of Linspire and release the free parts as another Linspire-derived distribution called Freespire. This act of rereleasing distributions or code is certainly nothing new and is fully within the ethos of open source. In fact, many of the distributions we use today were derived from existing tools.

> Unfortunately, Linspire saw this as a problem and asked for the Freespire name to be changed. Reading through the notice of the change, the language and flow of the words screams marketing to me. I am certainly not insinuating that Betts has been forced into writing the page, or that the Linspire marketing drones have written it and appended his name, but it certainly doesn’t sound quite right to me. I would have expected something along the lines of “Freespire has been changed to Squiggle to avoid confusion with the Linspire product”, but this is not the case. Instead we are treated to choice marketing cuts such as “To help alleviate any confusion, I contacted Linspire and they made an extremely generous offer to us all”. Wow. What is this
one-chance-in-a-lifetime-not-sold-in-stores offer? Luckily, he continues, ‘they want everyone who has been following my project to experience ‘the real’ Linspire, FOR FREE!!!”. Now, pray tell, how do we get this “real” version of the software “FOR FREE!!!”?

> “For a limited time, they are making available a coupon code called ‘FREESPIRE’ that will give you a free digital copy of Linspire! Please visit https://linspire.com/freespire for details”. Oh…thanks.

I gave Linspire a pretty full-throated kick in the wedding vegetables in my blog entry. I told the story, objected to what I considered hypocrisy given their own battle with similar-sounding trademarks, and vented. I wish Guitar Hero had existed back then: it would have been a better use of my time.

I was wrong. My article was never going to achieve anything. Shortly after the article was published, then-CEO Kevin Carmony emailed me. He was not a happy bunny. His objection, and it was valid, was that I flew off the handle without checking in with him first. My blog entry was my first reaction. The reality of the story was far less dramatic, and Linspire were not the ogres that I painted them to be. I apologized to Kevin and felt like an idiot.

Many conflict scenarios are resolved in private discussions where people can be open and focus on solutions without the noise. Over the years I have seen many examples of a furious public blogging war going on while behind the scenes there is a calm exchange of opinions and the focus on solutions.

### Wrapping Up

When I started writing this it was much shorter, but I just kept adding one more thing, and then one more thing and so on. It is already long enough that I can probably count the number of people reading this bit on one hand, so I am going to hang it up here. I could go on forever with little tidbits and experiences that I have been fortunate enough to be involved in and expand my horizons, but then I would end up writing *The Art of Community II: This Time Its Personal*.

Life is a constant on-going experience, and I hope your investment in reading this has added to it a little. I look forward to hearing from your experiences in the comments.