Why work in the open?

No readers like this yet.
neon sign with head outline and open source why spelled out

Opensource.com

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.
User profile image.
Heiko is a long time open source committer. He currently works for Red Hat on the topic of monitoring and management of server and softwares systems. Heiko has received a master in Computer Science from University of Karlsruhe and has written two books on JBoss AS and Enterprise Java Beans.

1 Comment

I've been doing a lot of opensource stuff since the 90s, from contributing to various projects as well as running my own.

A few years ago i wrote a library, that saw quite some use, I published the library through its own github group, but had a public fork of it that I was working on. The fork was even marked in its Readme.md as "this is an unstable fork, and everything you see here is work in progress, do not use this, use the stable version from link-to-correct repository.
People didn't listen, they cloned my fork, run into problems and incompatiblities, and started creating tons of tickets for stuff that wasn't there yet, so i ended up spending a lot of time with answering tickets, rather than progressing with that library.
The IRC channel I had linked at the time showed a similar picture, people started complaining there, or asking about stuff that wasn't even supposed to be used by them yet.
When i decided to refactor the library to be compliant with the new PSR's in PHP, and to use PHP namespaces and such, i once again forked it, and started working on it. At first it was ok, but after a while, and i still hadn't done any release, people started to send me pull requests (which in itself is good), demanding that while I'm at it, I would do whatever they want changed. One of those guys started a discussion on IRC about something where he felt certain classes should be named differently. It started with him hinting at it, then that hinting became demands, and at some point, even though i had spend a lot of time explaining on why i named it this way and was sticking with the name (and that discussion did cost me over an hour), he send me a pull request with all names changed, and declared I'd have to merge it in, as i gave my code to the community, and now i wouldn't own it anymore, and couldn't make such decisions on my own.

My reaction? i paid github and set the repository to private, then I told him to f*** off.

You are right, working public can be benefiting, but putting stuff you work on out public too early is counter productive, you end up with too many chefs that all want to decide on what soup you are cooking. In my experience it is better to do work first, and then iterate over it with community input (no matter if PR's or comments), as people will be able to base their discussions on something working, rather than on assumptions. It also allows you to take the time to take care of your work, rather than spending most of the time in (often pointless) discussions.

Yes it is important to talk to your community, and it is important to be as transparent as possible about what you are doing. But that doesn't mean that you need to do it all open, and it doesn't mean that you should sacrifice your valuable time on trying to please everyone. After all you are doing free work for them.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.