At a party, if you notice someone has food stuck in their teeth, you probably wouldn’t go “HEY! You have food stuck in your teeth and it looks GROSS! I hate it. I think you should go brush your teeth right now!”
But we do that all the time in open source.
Someone writes a new blog post or a new piece of code or forgets to post something … and we criticize them in public. Because it’s open source, right? Instead of emailing them we think their blog post is wrong, we leave a blunt, often rude comment. Instead of IMing them and asking if they’ve considered the privacy implications of their change, we write a public blog post that details how wrong their strategy is. Instead of congratulating them on their new product website and emailing them a few suggestions that would make usability better, we write a long critique in a blog post of our own.
When we do this, this public criticism, we change their ability to respond to it. Now they must respond in public, often defensively. If the feedback was private first, it would be easier for them to change quickly and nimbly. (Or maybe they don’t need to change at all. Maybe we missed something.)
There is a time and a place for public critique. But it’s often not the first place the critique should happen if we want to effectively influence projects.
Most effective people on open source projects communicate privately first.
They communicate via private emails, IMs and even public IRC channels, which are less public than web pages and public mailing lists because they aren’t archived.
So the next time you read something and have burning feedback, consider your audience and how you might most effectively drive the change you are looking for.
Who – or rather, which company – is holding all your email?
Photo by Louis Abate
If you couldn’t login tomorrow, do you have a copy of your email? Many webmail services, like Gmail, make it easy to download a copy of your mail using POP or IMAP but if you use their web client, it’s an extra step you have to think about and do on a regular basis. It’s not something that most people can do easily. Especially if they share a computer with others.
While there’s a good chance, as a reader of this blog, that you are a do-it-yourself kind of technical person and use Thunderbird or Evolution to read your mail on your own computer, most of us don’t. Most of us trust our webmail to be there when we need it. We are trusting a single company to hold and take care of years worth of personal correspondence.
We need a way to backup our data, data like our email, to a trusted place.
P.S. I use Thunderbird to backup all my mail from my email web service providers to my computer. It’s not what it was designed for but it works for now.
At Kids on Computers, we’ve spent a lot of time and energy getting computers to kids that have no access to technology. Many of these places (rural Mexico, Africa, India) have cell phones before they have phone lines or even power. (The second time you blow the power for an entire school trying to set up a couple of computers, you realize how much we take power for granted in developing countries.)
So the new devices coming out right now are really exciting.
These devices, using open source software and open web technologies are going to bring the web – and the world – to more people everywhere.
Disclaimer: I work at Mozilla. At Mozilla we are working on making sure everyone has access to the web and that it stays open and accessible for everyone.
One of the things I love most about the open source communities I’m a part of is that when I ask a question, I just don’t get the answer, I get taught how to find the answer.
A few weeks after I started as executive director of the GNOME Foundation, I asked Dave Neary for someone’s contact information. Actually, it might have been the third or fourth time I asked him for someone’s contact information. He sent me back an email with the contact info I wanted. And a detailed explanation of how he found it. So the next time, I was able to find info like that myself.
I love that when you ask someone in open source a question, they not only answer it, but explain how they found the answer. (I realize some people find that annoying. I really appreciate “learning how to fish.”)
It’s the same empowering attitude that drives people to blog about a problem and how they solved it or found the answer. They are teaching others how to fish.
Photo by DennisSylvesterHurd
Think of the last time you walked up to a complete stranger, stuck out your hand and said, “Hi, my name is …” Depending on how often you do that, it was probably a scary moment. Before you walked up to the person, you had to steel your nerves, decide what you were going to say, and then approach them.
Joining an open source software project is a bit like that. You have to send a mail to a huge list of random people. Or file a bugzilla bug that goes to a ton of random people.
And then imagine the immediate response is “WONTFIX” with no comments. That’s like if the person you got up the nerve to introduce yourself to said, “Not interested.”
I once spent weeks convincing a friend she should help out on an open source software project. She did. And she sent in her work to the mailing list and the first response was full of harsh critique. None of the follow up messages made up for that first message. I never did convince her to push her work forward. Nor to participate in open source again. (She does know exactly what she’d say to that first critic if she ever met him in person!)
What can we do to make sure people trying to shake our hands get a better reception?
When I first started using email, I had a part time job in the computer science department at Rice University. A new grad student joined the department and a few days after he started, I noticed it was his birthday. Knowing he was unlikely to know many people in town, I sent him an email that said, “HAPPY BIRTHDAY” all spelled out in big letters made out of asterisks. He wrote me back “Thanks a lot”. Now in my world, “Thanks a lot” was always said “Thanks a *lot*” with a slightly sarcastic twist to it. I emailed him right back to ask him if he really liked it or if he was being sarcastic. He said no, of course, he really liked it.
So if one happy birthday email can be that confusing, imagine what can go wrong with a complicated email about project directions and motivations … Especially when it’s going out to a mailing list that has hundreds of people on it. That’s what most of us in the open source space deal with every day. Some of us do it better than others. Some days we do it better than others. But we all work at it every day. It’s the way we communicate with our friends, peers and co-workers.
Please meet the Mozilla Conductors
A few months ago, several of us at Mozilla had a conversation about how we could best help people learn how to communicate well online. We have new people joining the project all the time and they have to learn how to communicate on mailing lists, IRC and bugzilla. Those of us helping them realize daily what a challenge it can be. As much as we don’t think about it, cc’ing the right people, quoting previous mail messages and keeping the conversation from getting argumentative are not easy things.
We were looking for a way to help everyone communicate better, exploring all sorts of crazy options like classes and consultants, and realized we had the best resources right inside our project. We have people that are really good at fostering online conversations. They’ve been doing it for years; quietly (and not so quietly) leading and directing the conversations and projects they are part of.
So we sent out a bunch of emails, came to a consensus and created the Mozilla Conductors!
Mozilla Conductors help Mozillians with difficult online conversations. We offer advice, suggestions, a listening ear, moral support and, in the case where the discussion is public, occasionally direct intervention. But the goal is to help everyone communicate effectively, not to be enforcers. If you end up in a difficult online situation, you can reach out to Conductors via the mailing list or to any individual in the group to ask for help. Maybe you just need a sounding board or help figuring out how to phrase a particular idea or how to make someone particularly difficult go away. The Conductors will help brainstorm, ask questions, provide ideas and help. And where we are on mailing lists, we commit to helping keep the conversations constructive.
We are not an officially appointed group. We are a peer nominated group. We are a group of people from across the Mozilla project. We are a Mozilla Module.
Please help us make online conversations productive and Mozilla a success!
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.)
The most amazing thing about this process was that an all volunteer hiring committee was formed and made a recommendation to the board in just two months. We received a number of high quality candidates and we were committed to moving quickly through the interview and decision process.
Executive Director Hiring Process
Here’s the process we used to hire an executive director:
- We put together a great hiring committee.
- We created a mailing list and set of private wiki pages for the hiring committee.
- We drafted and posted the job description.
- We collected resumes; conducting phone screening as we went. We were quite excited at the number of quality candidates that we got.
- On the wiki we tracked candidates, who was phone screened, who was set up for follow up interviews, etc.
- The phone screener for each candidate was responsible for managing that candidate for the rest of the process.
- All communication that involved decisions went through a GNOME board member who was also part of the hiring committee.
- We recommended three candidates to the board.
- The board interviewed the top candidate and negotiated an offer.
- She accepted! To carry on the tradition, we made her write her own press release. (Actually, Luis Villa helped me with mine.)
The GNOME Executive Director Hiring Committee
The group that agreed to help out and did an awesome job is:
- Bradley Kuhn, Executive Director at Software Freedom Conservancy. Member of the Advisory Board representing FSF, former Executive Director of FSF. Bradley offered a lot of free software and nonprofit expertise to the hiring process. Bradley has a personal friendship with Karen, which he disclosed to the committee as soon as her application arrived. Other committee members carried out the initial interviews with Karen, and Bradley recused himself on 14 March 2011 when Karen became the top candidate.
- Dave Neary, Neary Consulting. GNOME contributor, former Director of GNOME Foundation. Dave brought us a lot of GNOME experience and understanding. He was involved in recruiting me for the job several years earlier.
- Germán Póo-Caamaño, Director of GNOME Foundation. Germán was our board member contact. He pulled us all together and was our communication point with the board of directors. Og Maciel and Brian Cameron, two other board members, joined him midways through the process. We had board members communicate all official decisions to candidates and that turned out to be quite a bit of work. Og did great sending out a lot of emails – some fun and some hard.
- Jonathan Blandford, Manager of the Desktop team at Red Hat. Member of the Advisory Board representing Red Hat, former Director of GNOME Foundation. Jonathan brought us not only GNOME experience but hiring experience in the open source world.
- Kim Weins, OpenLogic. Senior VP of Marketing at OpenLogic. I invited Kim to the committee because Kim makes things happen! She brought a wealth of team building and hiring experience as well as strength in execution that kept us moving along whenever we started to stall.
- Luis Villa, Greenberg-Traurig. Attorney at Greenberg-Traurig, formally attorney at Mozilla, former member of the Advisory Board representing Mozilla, former Director of GNOME Foundation. Luis joined to help us part time. He did not interview candidates but leant his GNOME experience – and he’s the one that hired the former GNOME Executive Director (me!).
- Robert Sutor, IBM. Vice President of Open System and Linux at IBM. Bob brought a history of GNOME but also ties to the greater industry and a lot of hiring experience. He also drove us to keep moving at times when volunteer orgs tend to slow down.
- Stormy Peters, Head of Developer Engagement at Mozilla. Former Executive Director of GNOME Foundation, former member of the Advisory Board representing HP, now Director of GNOME the GNOME Foundation (but not at the time of the hiring committee).
Here’s the actual time line of how it worked:
- I gave notice on October 20, 2010 and said we should work on hiring a replacement right away.
- At the Boston Summit, the board decided to hire an executive director to replace me.
- The board appointed Germán as the board member in charge.
- Germán posted the job description on November 7, 2010.
- On November 29th, Germán involved me in the hiring committee formation.
- On December 27th, we introduced the hiring committee.
- We started screening resumes and doing phone interviews.
- On February 2, 2011, the hiring committee made a recommendation to the board.
- On March 11, 2011, the board told the hiring committee they were ready to make an offer to the top candidate.
- Discussions, clarifications, negotiations and communications.
- On June 21, 2011, we announced that Karen Sandler would be joining the GNOME Foundation!
The process went well and I’d recommend it to others trying to hire in a virtual, global, nonprofit environment. There are parts that could have been more efficient but we learned and adjusted as we went. We talked to a large number of high quality candidates and hired a new executive director in an a very efficient manner – all done by a volunteer board of directors and a volunteer hiring committee!
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.
So if you start a project and send email to a bunch of folks and ask them to just jump in and contribute, which group do you think will get going more quickly? The low context culture folks. As long as you define the process and procedures, they are willing to work alone and with people they don’t know very well. That’s how open source works. So our projects are optimized for low context cultures.
What happens to the high context folks when invited to participate on a mailing list? They have a hard time sending emails and contributions to people they’ve never met and have no relationship with. (Imagine walking up to a random person on the street and critiquing their dress style. It’s that kind of awkward.) Would they make good contributors? Absolutely! Do we need to find other ways other than “join the mailing list” to get them involved? Absolutely! For an example of what’s worked well, see the great work that Emily Chen, Pockey Lam and Fred Muller and others have done with GNOME Asia.
As I think about developer engagement at Mozilla, I realize we need to have different plans for different cultures. It’s even more important to be present in person for high context cultures. To establish a personal relationship before you invite them to join your project. (Or ask them to use open technologies or spread the word.) We should be following up in different ways, setting up different programs for different countries. Luckily the Mozilla Reps program will help provide the infrastructure for this.
How do you think we should encourage high context cultures to get involved with open source? If you are from a high context culture, how did you get started?
Transparent voting is an idea that is ideally really useful but also completely useless in GNOME.
Some people in GNOME have been asking for transparent votes. When the board votes, they would like to know who voted which way. I totally agree with them – it’s important to know how different board members think so that you can make educated choices. However, I also agree with the people that say that it would be totally useless.
For example …
Yesterday and today the board discussed where GUADEC 2012 will be. It’s a big decision and not one we took lightly. We discussed it, we invited the potential hosts to come and talk to us, we debated it and we debated it some more. Many hours in total.
And yet when the vote happened, it was unanimous.
So what happened? If the vote was unanimous, why all the discussion? Because it wasn’t really unanimous. We all liked different points of different bids. And some of us weren’t sure which way we wanted to vote to start with. Then we discussed and some people changed their positions, others remained firm. We discussed some more. And although it was a unanimous vote in the end, I believe several board members still might have preferred a different bid. (They were all awesome.) The unanimous vote was the way for everyone to say “I’m behind the group decision.” More than half of us were 100% behind one bid and the few of us that weren’t were signalling that they agreed. They were willing to go with the group decision. They signaled that by the way the voted. You’d have to see their body language to understand.
So while it would be interesting for people to know how individual board members feel about issues (like maybe copyright assignment), seeing the results of votes is unlikely to be informative. We need to figure out how to convey the conversation, not the vote results.
Firefox is visiting us for a while before he heads to Brazil with me. He’s been a big hit so far.
I was asked if he came in kid sizes. I foresee a request for a Firefox Halloween costume. Luckily I have experience making Firefox costumes too …