continuous communication

Different projects within the KDE and Qt worlds and their leadership have different viewpoints on how external communication could or should work. By and large, we do pretty well in our extended community in this regard. However, there has been an increasing number of lost opportunities as well as unfortunate incidents related to the way communication is being handled by some projects in our community. I certainly do not have all the answers and there is no "One True Approach", but in general I am a believer in continuous communication beyond one's borders.

I'll try and describe in this blog entry what "continuous communication" means, its benefits and its challenges from my point of view. I'll try and be thorough, so if some of the time spent in definition is a bit tedious, I apologize in advance. I hope you find something of use for your own projects and that you can also add to the following ideas so that everyone, including myself, can benefit from new ideas and personal growth.

What Is Continuous Communication?

Continuous communication is a consistent application of information flow from within the project's core community, to its extremities and beyond into the wild unknown beyond the core members' awareness horizon.

(An "awareness horizon" is what you are able to perceive from your point of view. In communication the horizon is limited by the size and diversity of one's social network as well as the resources available to take in information from both the social network and additional sources of relevant information not directly a part of that network such as news organizations.)

The two key points are consistency and broad reach. People often fault on these two aspects of communicating their project's status either by communicating exclusively (rather than inclusively) to those close to them or by communicating very sporadically.

With continuous communication, the goal is to build an audience, keep an audience and increase your relevance within the topic(s) your work covers. By doing so, one can hope to increase the level of usage of your work, open new opportunities for coordination with others and be ready to not only address challenges as they arise but to avoid them in the first place.

How does it work?

"Are You Asleep?" And Other Questions You Can't Answer With "Yes"

States of inactivity are only identifiable to an outside observer by a lack of activity. A living animal may stay perfectly still and appear at first inspection to be asleep or even dead despite being quite alive. A sleeping animal has a hard time emulating a non-sleeping one, and a dead one simply can't emulate a live one.

That means that no visible activity, even if one is alive and awake, is often indistinguishable from a sleeping or dead entity. Given that there is no way for the sleeping or dead to say otherwise, the awake and living tend to assume the worst in those cases. Usually very little deeper investigation is done to see the actual state of the organism in question due to a lack of time or interest.

This is why the trick of "playing dead" works so well for animals that employ it.

When a project is kept "under the radar", it is for all intents "playing dead". Others will tend to assume that it is, indeed, no more. Those who did know about your project will tend to assume it has become an ex-project and go elsewhere, and those who didn't know about your work will remain blithely ignorant of it.

So what, right? You'll come back later with lots of news once your project is nearer ready for prime time! That plan rarely works, however.

Most People Prefer To Party With The Living

People will not wait for a project to magically (re-)emerge at some inflection point. That can be a harsh reality check as to our own importance, but it's true. People will find others who they perceive to be alive and well to engage with. Bonus points can be earned for being easy to approach and subsequently get along with, but to even get into the running one needs to be open for engagement.

In F/OSS projects engagement means users and contributors. It means other projects may end up cooperating with your project. More people will adopt it. More people will use it. More people will contribute to it.

Conversely, lack of engagement means people will stop using it. They will drop it. They will take up with other projects and make them successful instead.

It is, in fact, better to engage with others even if your project isn't quite ready because that will help you get the resources needed to get it to completion than to play it conservative and subsequently starve your project of resources. All that results from the non-communicative strategy is creating your own special island that nobody else cares about. If there are competing projects that do engage others, even if they aren't as good, they will eat your lunch.

To Make An Entrance, You Need An Audience

There's often the desire to make a big splash all at once with a Big Bang Announcement. We often see companies that product proprietary software do such things, after all. A common misunderstanding of this methodology, however, is that those Big Bangs is the meat of the strategy. But they aren't, they are simply the sizzle around the actual meat of communication.

Imagine making a grand entrance at a fancy ball. You dress up fabulously, have a great partner lined up to walk in with and you've even practiced your dance step. If you show up to an empty ballroom, it hardly matters. Show up when there's people actually there and you can have the effect you were hoping for.

One builds an audience by communicating with them regularly before (and after) Big Bang announcements. This is why continuous communication is so important: it ensures that you have an audience when you really need one the most.

Continuous, Not Constant

One quite understandable objection to continuous communication is one of resources: how much time and effort does it take? An important understanding is that it isn't constant communication, it's continuous. You really don't have to invest a lot of project resources into communication, the most important thing is that it's regular.

It is far more useful to have 500 words of text published at the start of every month for a year than it is to have 6000 words (or even twice that) published once and then having nothing said again for the rest of the year. Breathing, and many other bodily functions, happen every so often. They may not be completely predictable (it would be a bit odd if one used the toilet at 14:38 every day on the dot, for instance) but they tend to be expectable.

When communication can be expected, this helps others feel confident you exist, you're alive, doing well and that there's something to engage with. As a result, they will.

Communication Eases Discomfort

Sometimes communicating is uncomfortable. People may take what is said or written the wrong way or the may react poorly in response. These events are often kept to a minimum, however, when communication is continuous. A continual flow of information allows others to gauge how to engage with their own efforts in a way that will compliment your own as well as help avoid nasty surprises that lead to poor response. In this sense, communication is as much a preventative measure as anything else. In a big community like KDE, this is priceless.

There have been a few unfortunate incidents recently where one project runs broadside into another project's plans and creates a mess. These cases could almost certainly have been avoided through continuous communication from the earliest points of those efforts. An additional and important hint is that these same situations are being dealt with by practicing continuous communication between the affected parties and beyond.

You Don't Know What You Don't Know

There are projects who do an awesome job of communicating .. to themselves. Everyone currently involved knows exactly what's up, contributors are connected to each other and the milestones are being met. Isn't that enough? It could be, but often it isn't and usually it's certainly contributing to that project losing out on opportunities. The thing about opportunities is that they rarely remain unfilled; they are like vacuums: something nature abhors and which get filled whether or not you show up.

Another aspect of opportunities is that we rarely know what all the opportunities are until we start throwing out lines of communication and broadcasting. This reaches people who may be have or know of opportunities that were previously beyond the awareness horizon of the project.

If you think you know all, or even most, of the interesting (let alone possible) opportunities out there, you have a vastly overinflated view of your own knowledge, connectedness and insight. Unfortunately, this is exactly what some projects will claim and then use that as a reason to not engage in more continuous communication practices.

Being Part Of Something Bigger

Being part of something bigger like KDE gives us the opportunity to do something bigger with our smaller, individual efforts. When we go silent, however, it doesn't help the larger community and the various projects, even the ones who are communicating continuously. When communication happens, everyone benefits. We find new chances to coordinate and cooperate between ourselves an our collective reach is extended that much further as people outside of our community are able to more accurately measure the overall health and wellbeing of the community.

In many ways, it comes down to the "weakest link" principle: a project will often be measured by the lowest height achieved. It is often unfair, but it is very often true. One project's refusal to communicate will often reflect on others under the umbrella they share as a community.

A project doesn't have to be the shiniest or the loudest or the most sexy, but it shouldn't appear dead when it isn't, either. Some of the smaller and more niche projects within KDE do a great job of communicating on a regular basis and in my experience dealing with people from beyond KDE those efforts really do help a lot. It also gives us a way to bond better and have more fun as a community.

Limits

There are limits to all of this; the universe isn't perfect, after all. Continuous communication doesn't require perfection, just a reasonable amount of transparency that extends beyond the project's own borders at least somewhat demonstrated on a regular basis.

Sometimes we aren't allowed to say anything because of commitments you've made to others. Often one can find creative ways to communicate about related things that stays within the boundaries of those commitments, but if you can't such is life.

Sometimes we don't have the time or ability to communicate effectively. In that case, reach out into the community and ask for help to communicate. There are often people who are able to help out, sometimes much closer than we'd expect at first.

There are a number natural limits and potential blockers to effective continuous communication, but very rarely do they prevent all and any communication. Every project can do some communicting and, most importantly, do it on a regular basis.

Does Continuous Communication Work?

Continuous communication is not, by itself, a guarantor of success or smooth sailing. It is an important tool, but a project still needs to deliver on features and quality as well as be open and welcoming to newcomers. As a tool to achieve the benefits talked about above, however, continuous communication can be extremely effective.

If one looks around the current F/OSS landscape it becomes very apparent how much continuous communication plays a role in the success or lack thereof in a project. Take most any F/OSS technology category, be it a software project or a packaging effort, and compare the perceived front runner and the "also rans" in the category. Often a key difference is continual communication, sometimes to the point of making up for functional deficiency. It's also interesting to watch what happens to a project when it stops continual communication as a practice; they almost always slide off sideways into the proverbial ditch (though which comes first, the problems or the lack of communication, is often not clear).

Whether I can write about the topic convincingly or not, looking around the F/OSS landscape should help you decide for yourself.

So What Now?

If you are part of a team that isn't communicating regularly beyond your own borders, perhaps it's time to make a conscious effort to do so. Track what changes and improvements, if any, result when a regular practice of communication is put into place. I find it takes at least one release cycle to really get the hang of it and to see results start to emerge, so stick with it.

For the companies involved with KDE, I doubly urge you examine how you interface with the community and how the community interfaces with you. Be the good examples for others to look towards for guidance and help everyone reap the benefits of communicating early and regularly.