Balancing IRC and email, the secret of success for open collaboration

Are seasoned contributors to OpenStack giving too much importance to IRC, and is that creating bad side effects in other areas of the community?

Since I started contributing more to working groups outside of the OpenStack upstream contributor community, I noticed that email is used in a limited way, with a couple of lists having either very low traffic or low signal/noise ratio. The email lists are often used to share calendar notifications for meetings and their agendas with often little to no discussions. Have we insisted so much in holding weekly meetings “like developers do” that now people think that email discussions are less important?

This weekend a couple of posts on Planet OpenStack talk about IRC: one very good source of information on how to use IRC better from Chris Aedo who suggests to stay more on IRC. He argues:

If you are interested in becoming an OpenStack contributor, having a persistent IRC presence might be one of the most important secrets to success. Anyone who spends time in one of the more active project channels will immediately see the value of synchronous communication here where problems are sometimes solved in minutes.

On the other hand of the spectrum Chris Dent who highlights the chaotic nature of IRC. He mentions that too  much IRC leads to:

no opportunity to be truly away, frequent interruptions, an inflated sense of urgency, and a powerful sense of “oh noes, I’m missing what’s happening on IRC!!!!”—but the killer is the way in which it allows, encourages and even enforces the creation and expression of project knowledge within IRC, leaving out people who want or need to participate but are not synchronous with the discussion.

This last point is crucial: not everybody can be online all the time, some of us have to sleep or go see a movie at times. IRC is often mentioned as a blocker to new community members. I advocate using a bouncer only to get personal messages, not to read the backlogs.

While synchronous communication is crucial for distributed collaboration, a sane habit of using email is as important. The OpenStack community has put so much emphasis on using IRC to hold weekly meeting and to resolve the most controversial conversations in real-time that some new comers now think that synchronous communication is more important than async email.

A sane balance of sync-async communication is more crucial to success of open source collaboration, mixing email and IRC (which is what most of OpenStack upstream developers do, by the way.)

All in all, I think there is also a need to teach people how to hold conversations via email, with proper quoting, no top posting and other nice things to do… but also email sorting and filtering client-side, what not to say (hint: “me too” messages are generally considered noise)… a lost art, as much as using IRC.

How do companies do OpenStack?

I’m cruising Silicon Valley these days asking “how does your company do OpenStack?”  to collect best practices and notable mistakes from various leaders of OpenStack corporate community. I’m hoping to build a ‘how to’ manual to help managers build better dev teams, more effective at collaborating while shipping products to their customers. This is an effort that goes hand-in-hand with training new developers with Upstream Training and other initiatives aimed at sustaining OpenStack growth.

I often have to explain to managers of OpenStack corporate members how and why to contribute to the project. The level of complexity reached has now exceeded the simple answers, like ‘fix simple bugs’ or ‘read the wiki pages’. For example, the participants to the Upstream Training in Atlanta had difficulties finding low-hanging-fruit bugs to work on: by the time they were ready to commit, someone else had already fixed it. Too much is going on at the same time, newcomers are confused at many different levels.

While we will keep training developers through Upstream Training (and other initiatives), we’re going to start talking to managers too.  I’d like to know how development teams are organized, how they balance shipping products to customers with contributing upstream, what incentives are in place that help or prevent contributions to go upstream, how career paths are influenced by contributions to the open source collaboration, etc.

If you’re managing a team of developers or devops, you’re a CTO, a HR executive or are managing in any way a team of engineers contributing code to OpenStack, I would like to talk to you: email me and vote for my talk proposal “How to maximize effectiveness of your developers contributing to OpenStack”.

The sad state of free software collaboration tools

My post yesterday sparked a little conversation on G+. The content of that conversation reminded me that free software collaboration tools are in a very poor state. Email clients for Linux (well, also on Mac OS X and Windows) suck badly, address book managers are awfully ancient, voice/video chat systems compare poorly to proprietary alternatives (technically, not just because none of our friends use them).  Some fellows of FSFE recently tried to hunt for Skype alternatives. The published results are depressing.

It’s a hard to solve. Hopefully we can put behind the quest for the ‘perfect desktop’ and start building tools for the free digital citizens again.