Why work in the open?

What prevents you from working in the open?

I work for an open source company on an open source project and still I encounter on a daily basis that people who are working on open source software prefer to work in private (from time to time). They do not discuss technical questions on public mailing lists, the normal chat goes on in internal chat rooms instead of public IRC, and new features are rather demoed on private video conference channels than as e.g. Hangout on Air.

There are of course good reasons that communication has to be in private: if customers or customer data are involved, then (especially for a public company) private conversations are needed. Similar for sales numbers or other financial aspects. The reality is though that engineers most of the time don't hear any sales numbers. And most customer cases are just general software problems that can be openly discussed when not mentioning the customer name. Which brings me to the question why people are not collaborating in the open—especially when the resulting source code is published to a public repository like GitHub.

Fear of leakage

When you are working with customers, there are always groups like customer support that cannot work in the open, which means they do not join public IRC channels but private ones, to keep customer data private. Engineers working on such a customer case may always have a latent fear that discussing case details may leak customer data and discussions on them always happen on internal channels no matter if any customer specific issue is discussed or not. Which brings me to the next point.

The effort of selection and switching

When you work on internal channels for customer related data (and because the respective colleagues are only available that way), one has to constantly think and decide if a certain message can go to public channels or not. One can understand that such case comments are made on the internal channels and to get a coherent stream of thought should still stay on the internal channel. Talks about other non-customer related issues should on the opposite go to the public channels, which means switching channels all the time. Such selection and switching of channels certainly is an effort which people try to avoid.

Uncertainty

There may also be cases where engineers are working on a feature request or bug of a customer that is not specific to any customer at all. And still there is a lingering uncertainty if the work can be discussed in the open or not. So that in doubt the discussion happens in private again.

Fear of distraction

While community contribution is (said to be) always welcome, it can also be seen as a source of distraction. A core member of a project has to possibly interrupt her work, start thinking into the point of view of the community member, and then get back into the original work. This can be from time to time distracting, especially when you have some time boxed releases, so this may not be welcome.

Perceived lack of benefit

Our project has a rather small community, which may bring up the question why to discuss things in public if no one seems interested? Why go through all the above hoops? Does a tree really fall in the woods if there is no observer?

Lack of self-confidence

Another possible reason may be a fear of accountability and traceability. This may sound funny at first as the source code ends up in the public repository. The more underlying cause here may be a lack of self-confidence. Discussions in public that are recorded as chat-logs, videos from feature demos, or blog posts allow others to give critical feedback and can make the person feel unconfident.

I am a firm believer that working in the open is good. Even with a small community. Doing work in the open allows you to get input from community members, which enriches the knowledge of the problem domain. Others give a totally different perspective and probably list use cases you have never thought of. Also if community members are included in the overall community, they feel better and start contributing more. For ideas on how to contribute in ways other than code, see my article: 10 ways to contribute to an open source project without writing code.

My encounters with community members have been very good, as everyone is very friendly and meeting community members in person is always fun. So what can we do to overcome the obstacles I've listed above?

• First, set up a policy that all communication has to be on public channels by default unless there are good reasons against.
• Remind yourself to start the day on public channels. When you start there, it sets sort of a default for your self. And it encourages others to chat there as well, so building a critical mass to get talks going.
• Remind people from time to time about the above policy.
• Dissociate customer information from the technical information as soon as possible. Perhaps directly on the level of the support person. A NullPointerException is a NPE no matter if it is reported by a paying customer or a community member.
• Record public channels so that community members get the possibility to re-read what was discussed.
• If you need to work quietly, then don't shut out external community only. Switch external comms off, do your work and then come back—a distraction is a distraction no matter if from another community person or from a co-worker.
• If you feel uncomfortable writing (e.g. a blog post explaining your work or a new feature) first pass it by another person you trust. Unless you did not even try to deliver a good result, there are no bad posts. The greater community always appreciates any additional information.