Mozilla on Stormy Peters

In order to grow your volunteer community, you must work in the open

Wed, 14 May 2025 14:38:02 -0700

Doing research for my Grow an Organization by Planting Volunteers at SCALE, I ran across Dirk Riehle’s article on the Five Stages of Open Source Volunteering. The whole article is worth a read but I thought I’d call out the open communication piece. He says to support a distributed community and to engage new volunteers, open communication is key.

Public communication ensures that all members of the community have the opportunity to participate, which creates buy-in and trust.

The Good, the Bad and the Ugly of why I don't always work in the open

Thu, 12 Feb 2015 12:00:28 -0700

I was writing a post about why you must work in the open to get more volunteers and I ended up writing this post about why I don’t work in the open.

The Good

So I think there are some very valid reasons for not working in the open:

Personal. Not all projects are open source projects, especially personal ones. Where I’m going for Valentine’s Day or how to get my son to do better in school are not “open” projects. They could be, but they’re not.
Not mine to share. There’s a lot of things I think should be shared with the world but they aren’t my stories or plans to share. I’d be violating someone else’s sense of privacy in order to share. I think your 2015 project goals are good enough to share with the world - and more people would join if you did - but you may not feel the same way.
It’s not an open source project. Lots of projects in this world are not run in an open source way. If you are not looking to build a community, and you are not an open source software project nor a nonprofit nor a public entity, I think this is a totally valid way of working.

The Bad

And then I think there are some reasonable reasons (maybe right, maybe not) for not working in the open:

7 reasons asynchronous communication is better than synchronous communication in open source

Mon, 26 Jan 2015 16:45:32 -0700

Traditionally, open source software has relied primarily on asynchronous communication. While there are probably quite a few synchronous conversations on irc, most project discussions and decisions will happen on asynchronous channels like mailing lists, bug tracking tools and blogs.

I think there’s another reason for this.Â Synchronous communication is difficult for an open source project. For any project where people are distributed. Synchronous conversations are:

Inconvenient. It’s hard to schedule synchronous meetings across time zones. Just try to pick a good time for Australia, Europe and California.
Logistically difficult. It’s hard to schedule a meeting for people that are working on a project at odd hours that might vary every day depending on when they can fit in their hobby or volunteer job.
Slower. If you have more than 2-3 people you need to get together every time you make a decision, things will move slower. I currently have a project right now that we are kicking off and the team wants to do everything in meetings. We had a meeting last week and one this week. Asynchronously we could have had several rounds of discussion by now.
Expensive for many people. When I first started at GNOME, it was hard to get some of our board members on a phone call. They couldn’t call international numbers, or couldn’t afford an international call and they didn’t have enough bandwidth for an internet voice call. We ended up using a conference call line from one of our sponsor companies. Now it’s video.
Logistically difficult. Mozilla does most of our meetings as video meetings. Video is still really hard for many people. Even with my pretty expensive, supposedly high end internet in a developed country, I often have bandwidth problems when participating in video calls. Now imagine I’m a volunteer from Nigeria. My electricity might not work all the time, much less my high speed internet.
Language. Open source software projects work primarily in English and most of the world does not speak English as their first language. Asynchronous communication gives them a chance to compose their messages, look up words and communicate more effectively.
Confusing. Discussions and decisions are often made by a subset of the project and unless the team members are veryÂ diligent the decisions and rationale are often not communicated out broadly or effectively. You lose the history behind decisions that way too.

There are some major benefits toÂ synchronous conversation:

Your competition helps explain who you are

Tue, 27 Nov 2012 02:47:00 -0700

“Where there is no competition, there is no market. This is why start-ups who “have no competition” have trouble engaging partners and making sales.” - Geoffrey Moore, Escape Velocity

Open source projects often shy away from competition. They value collaboration and leveraging existing solutions. But competition is good for more than making you run faster. Competition helps define who you are.

This is why the Nike iPod sensor had such a hard time when it came out. There was nothing to compare it to except pedometers. In contrast, Fitbit and Jawbone’s Up have met with a lot more initial success. And just about every article about them compares them to each other. (Interestingly, Nike has a new, similar product called Fuel Band that is mentioned in very few of the articles.)

How to have hallway conversations when you can't see the hallway

Mon, 04 Jun 2012 20:20:51 -0700

I recently listened to a talk by Michael Lopp about how to be a great manager.

During his talk, he stressed the importance of hallway conversations. Hallway conversations are informal conversations about projects, goals and status. As Shez says, they are great for bouncing ideas off people you might not normally interact with and just letting them know what you are up to.

Here’s how I do “hallway conversations” while working thousands of miles from my colleagues:

How to hire an Executive Director

Tue, 31 Jan 2012 09:04:19 -0700

When I told the GNOME Foundation Board of Directors that I was leaving my job as executive director, I told them my number one priority was to hire my replacement. Before I was hired, the GNOME Foundation went through a long period without an executive director and I wanted to make sure that didn’t happen again.Â At the Boston Summit, there was actually some discussion about whether they wanted another executive director or whether they could hire more specialized individuals for particular tasks. For numerous reasons, they opted to hire another executive director. (I was relieved - speaking as a current GNOME Foundation board member, it would be a lot of work for a volunteer board to manage more staff without an executive director.)

Does open source exclude high context cultures?

Mon, 19 Sep 2011 15:50:14 -0700

High context cultures value personal relationships over process. You have to know someone before you can trust them and work with them. They also tend to be less explicit and rely more on tone of voice, gestures and even status to communicate. Typically Asian countries are more high context than Western countries. Think Korea and Japan.

Low context cultures are process driven. They rely on facts and processes. Their communication style is much more direct and action-orientated. They are orientated towards the individual rather than the group. Western cultures like the US and Germany are considered low context.

The secret to my success in a field of men? All my friends. My guy friends.

Wed, 04 May 2011 21:09:34 -0700

I’ve spent a lot of time over the past few weeks talking about why we have so few women in open source and web development and how to encourage more women to join. (I even got to spend an awesome afternoon with a bunch of girls. I was supposed to be mentoring them but they were already Python game developers and small business owners - at the ages of 10 and 15!)

Learning to write JavaScript

Thu, 10 Feb 2011 12:09:16 -0700

So now that I work at Mozilla, I figured it was time to develop a “web app” just to make sure I understood it all. And since my team is working on educational resources for web developers, I wanted to see what it was like to learn how to use some of them using resources online.

So I decided to use the resources I could find online and write some JavaScript to do a pet project of mine.