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

Dirk Riehle outlines 4 principles of open communication:

• Public. All communication should be public and not take place behind closed doors; any private side-communication is discouraged.
• Written. All communication should be in written form; if this is not possible, any relevant communication should be transcribed or summarized in writing.
• Complete. Communication should be comprehensive and to the extent possible, complete. Assumptions are made explicit and key conclusions are summarized.
• Archived. All communication should get archived for search and later public review. Thus, previous conversations are available for posterity.

The benefits he lists are some of the same reasons I gave in my Asynchronous vs Synchronous post. It enables distributed work, people whose first language is not English have more time to read and understand, it gives a common understanding and increases transparency around decision making.

Reading it, I was struck that this is not how I am starting projects at Mozilla these days. We have many ideas for things we can do in 2015 and usually we discuss them as a small group, decide whether or not they are viable, figure out if it needs a budget, whether it moves our 2015 goals ahead and then we bring the topic to a wider, more public audience. There are several reasons for that. One is that it takes time to figure out how to accurately describe an idea, what you mean and why you want to do it. It helps to get feedback from a few people to help make your initial communication clearer. Another is that we don’t want to be seen as announcing things before we are committed to them. I’m not sure if that’s a valid concern or not. Third is that it feels distracting. All of us are suffering from too much email, too much information and too much communication. Adding random ideas seems to create more churn. I wonder if this could be solved by having people focus more on smaller projects. Right now it feels like we all have to follow most of what Mozilla is doing because we are part of Mozilla. Everyone wants to know about Firefox OS and tiles and privacy. I do!

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post In order to grow your volunteer community, you must work in the open appeared first on STORMY PETERS.

The world lost a great math teacher this week. Mimi Geier not only loved math, she loved teaching math and delighted in watching kids discover solutions. If I had a picture to share here, it would be of Ms. Geier with a grin on her face, holding out a piece of chalk so that a student could teach.

My first day at BFIS, Ms. Geier asked me if I was in first or seventh period math. I wanted to ask which one was the advanced math class, but I didn’t. Instead I said I didn’t know. She told me to come to both and we’d figure it out.

I got worried during the first math class. I could solve any quadratic equation in the world with the quadratic formula but Ms. Geier didn’t think too much of that method. She wanted us to factor, to pull the problem apart and understand the pieces that solved it.

Walking up the stairs after lunch, a girl who later became my friend told me, “You don’t want to be in the seventh period math class.” So it was with trepidation that I entered seventh period. Is this where they sent the kids that had never learned to factor? To my surprise I found a much different class. It was a small classroom of relaxed students and a very different Ms. Geier. This was not the homeroom teacher Ms. Geier. This was not the Ms. Geier who could take forever to make a simple point. This was not the Ms. Geier who was always misplacing that paper that she’d just had. This Ms. Geier grinned a lot. She loved it when we came up with a hard problem. She delighted in solving problems with us. She was thrilled when we figured it out. Ecstatic when we could teach each other. This was Ms. Geier the math teacher. I got to stay in seventh period, advanced math.

One day, we were all having trouble with some calculus. We could solve all the problems but we were struggling with the why. We got the formulas but not how they worked. The next day, a kid in my class whose dad was an engineer at IBM came in and said, “I got it! My dad explained it to me.” Ms. Geier, who had probably spent hours figuring out how to teach it to us, just grinned, held out the chalk and said “Show us!”

Several years after that first day of school, Ms. Geier was out of town for a few weeks. Her substitute pulled me aside during break. Sitting at Ms. Geier’s desk, he asked me for help with a math problem and said Ms. Geier had told him that if he had any problems with the math, he should ask me. Me, the kid who was afraid to ask which class was advanced, now trusted to help the math teacher!

Unknown to me, Ms. Geier also intervened on our behalf in other areas. We were having trouble with our science teacher. Several of us were banned from asking questions. One of my classmates was banned from asking questions because her questions were too stupid (she’s now a food scientist) and I was banned because my questions were too ridiculous (too much science fiction?). In all fairness, she did explore my ridiculous questions outside of class, even consulting her college professor. Things eventually got better. Several years later she told me that Ms. Geier had helped her figure out how to cope with us.

Ms. Geier taught me many things. Among them were that it’s ok to love math just because it’s math, that it’s ok to be the expert and let somebody else teach you – not just ok but exciting, that it’s ok to be the expert and not know all the answers, that sometimes people learn best from peers, that solving problems together is fun, and much more. I owe a lot of who I’ve become in my career to Mimi.

I, and many generations of math students, will miss Mimi Geier.

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post Mimi Geier, a great math teacher appeared first on STORMY PETERS.

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:

• Partners. At Mozilla, we often cite partners as a reason why we can’t share plans. I think partners just make it much harder. You either have to figure out how to do it in a way that doesn’t expose their identity or you have to convince them. It’s a valid reason but one that could often be different if you worked on it.
• Buy in. It takes time to figure out how to accurately describe an idea, what you mean and why you want to do it. It helps to get feedback from a few people to help make your initial communication clearer. Simon Phipps opines that if there’s a strong majority in a project, discussing an idea first with a few is a way to get something enough backing to push it forward.
• Getting clear. Sometimes you have to float your idea by a few people to get clear about what you really need to do.
• Not enough time. Some times we don’t do things in the open when we are out of time. For me, this is especially true when it’s not my project but I really think it could benefit from being open. Like a fundraising project at school. If they created a web page and a mini social media campaign, I’m sure they could be tons more successful. But I don’t always have time to help them figure out how to do this. I think this crosses into “The Ugly” when it is your own project. If it should be in the open, and you want a community to help you out, you have to take the time to grow that project. You’ll recoup your time later.

The Ugly

And then I think there are some not so great reasons for not working in the open:

• Not enough time. I hear this one a lot. We have to get this out next week or next month. There’s not enough time to articulate it clearly enough to open it, to answer everyone’s questions, to mentor, to accept contributions. This might be ok once in a while but I hear it more and more.
• Not distracting people. I feel this one a lot at Mozilla. Mozilla is a huge community now and we all want to keep up with everything. So every time you float a new idea and a million people weigh in, you feel like you are distracting them from everything else. But I think it’s ultimately their decision whether or not to be distracted.
• Not announcing other people’s plans. I put this in the ugly category because I often feel like my hands are tied in sharing until someone else shares their plans. Especially in technical documentation and evangelism, you are supposed to talk about other people’s work but not until they are ready. And you want to plan projects, outreach or events around their news.
• Not committing to something. Especially for your organization. It takes great skill to “float an idea” in the open. To not commit to it while still considering it. To be able to say, we are considering this and then to be clear if you decide not to go forward. The fear is that it makes you look indecisive. It makes people waste their time. It causes inappropriate press cycles. But if you can’t float ideas in the open, if you only talk about things that are already committed to and planned, you miss a huge opportunity to include people in the creative cycles and to make them feel like it really is their project.
• Not having company commitment. Especially when you are getting paid to work on an open source software project, it’s hard to float random ideas before you have your company’s or your boss’ commitment.
• Not making inappropriate news waves. There’s a lot of stuff I’d really love to talk about in the open and I don’t because I don’t want to read about them in the press. Right after I started at Mozilla we had a couple of these incidents. People’s personal blog posts turning into major news cycles. It wasn’t fun for them. I don’t want it to happen to me. (Unless it’s something I want in the news!)

When you choose not to work in the open, what are your reasons? Are they Good, Bad or Ugly? What are your suggestions for how those of us who want to work more in the open can all do better?

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post The Good, the Bad and the Ugly of why I don’t always work in the open appeared first on STORMY PETERS.

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:

• Relationships. You build relationships faster. It’s much easier to get to know the person.
• Understanding. Questions and answers happen much faster, especially if the question is hard to formulate or understand. You can quickly go back and forth and get clarity on both sides. They are also really good for difficult topics that might be easily misinterpreted or misunderstood over email where you don’t have tone and body language to help convey the message.
• Quicker. If you only have 2-3 people, it’s faster to talk to them then to type it all out. Once you have more than 2-3, you lose that advantage.

I think as new technologies, both synchronous and asynchronous become main stream, open source software projects will have to figure out how to incorporate them. For example, at Mozilla, we’ve been working on how video can be a part of our projects. Unfortunately, they usually just add more synchronous conversations that are hard to share widely but we work on taking notes, sending notes to mailing lists and recording meetings to try to get the relationship and communication benefits of video meetings while maintaining good open source software project practices. I personally would like to see us use more asynchronous tools as I think video and synchronous tools benefit full time employees at the expense of volunteer involvement.

How does your open source software project use asynchronous and synchronous communication tools? How’s the balance working for you?

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post 7 reasons asynchronous communication is better than synchronous communication in open source appeared first on STORMY PETERS.

Kids on Computers is planning a trip to the Huajuapan de Leon, Mexico area in June. If you can, please join us! If you can’t, please consider donating to help the labs we’ll be working on.

Most of us will be going down for a week or so. There are travel stipends available for those willing to spend a month helping in the area.

What could I possibly do to help? I ask myself this every time I go. Especially since I usually drag my kids along. Here are the things you can help with.

1. Technical skills. If you can plug in computers, troubleshoot basic hardware problems, install Linux on lots of different kinds of old hardware, figure out why a mouse isn’t working, any of those things, you’ll be very much appreciated! We have to have at least one Linux guru on every trip. The rest of us follow directions. Upgrading 20 old computers in a school with no internet can be a long, manual process; it goes faster with more hands.
   
2. Language skills. This trip is to Mexico. A large majority of the volunteers will not speak fluent Spanish. None of the kids and teachers in these schools will speak much English. If you can help translate, that’s a huge benefit. Not just when setting up the labs but when figuring out where to get supplies or going out for dinner. And if you don’t know the Spanish words for technical gadgets, it’s sometimes a really funny experience, especially when you’re not sure what you are trying to describe might look like. I’d never used ethernet crimpers until a trip to Mexico.
3. Teaching skills. When we teach a class, we like to have lots of helpers. Helpers to show people how a mouse works, how to double click and how to change windows. Often neither the kids nor the teachers have used a mouse or a keyboard before, much less opened an app or saved a file.
   
4. Logistical, herding cat skills. When you have 4 or 5 schools you are trying to work with, all spread out in different towns and 8 or 10 volunteers with different skills and you need a Spanish speaker with each group and someone who can figure out why the network is down in this school and someone who can update Linux on 4 laptops in another school … you need some logistical people. People who can help track who is where and what needs to be done.
5. Documentation and note taking. We have all sorts of things we should and try to document. What computers are in which school? What’s installed on them? What finally worked to get Linux installed on that computer that had no USB drive? What should we bring next time? What worked in that class? What didn’t? What apps did the kids use the most? Every evening we try to spend some time working on this, but having someone dedicated to documenting what we’ve done, what works and what still needs to be done, who could do it while we are at the schools, would be great.
6. Errand runner, make things out of paper clips person. We are always missing something, short something, need something. We soldered ethernet cables at one school! After stringing them across a road!
   

Besides just logistical efforts, there’s the benefit to you and what your support brings to the area.

1. Support local efforts. I recently read this effort that said international volunteers are often just in the way. I agree, that sometimes local resources exist and if they are there, you should use them. In our case, I think there are very few people with technical skills in the little towns we go to. We do try to pull in local university students and technical people whenever possible. And we have to go back frequently, because going once, setting things up and then leaving isn’t helpful. They get new teachers, forget passwords, computers break.
   With the travel grants, we hope to get local university students from nearby towns involved. But the other major benefit of bringing in outside people is that you get local people excited about it.When we set up 18 de Marzo, because we were there, we were able to bring in local media, the local school district, the mayor … because we visited the school, the school got more interest from local supporters.
   
   Unfortunately, they still don’t have internet access nor an accessible high school. But they do have a super involved parent organization and a full time computer teacher funded by student families!
2. Spread the word. If you go on vacation to Huajuapan de Leon, you’re going to have the experience of a life time. And you are going to share your pictures and stories with all your family and friends. A few of them may join us next time. Or donate. Or just be more aware of the world.
3. Spread your horizons. I take my kids so that they can see that kids have fun without Xboxes. They have a blast playing soccer and making new friends. And, yes, they did find the only arcade machine within miles. In the back corner of a little tiny store tucked away on a side street.
   

What to expect?

1. It’s slow. Most of us are used to scheduling every minute of our time and being as efficient as possible. It doesn’t work that way on a volunteer trip to rural Mexico. Just getting there takes a while. We fly down to Oaxaca, spend the night. Walk across town the next day, get a van ride, drive through the mountains, walk to our hotel. Work doesn’t start until 2-3 days after you leave home!
2. It’s not perfect. This is a volunteer run trip. And each trip presents different challenges. And not everyone has phones. Almost no one has internet. Getting from school to school means coordinating rides, arriving to find out they weren’t ready for you or the teachers were on strike, figuring out what equipment you need, what some of you can do while a couple of people drive all the way back to town to buy as much ethernet cable as they can, waiting around while your most seasoned Linux guru figures out why the installs aren’t working, … if you enjoy the people, what you are trying to do and use the time to get to know each other and the schools better, it’s great. If you came just to do technical work, it’d be frustrating.
3. Friendly people. The other volunteers and especially the teachers, families and students are awesome. Everyone is appreciative, helpful and outgoing. Just super. The parents usually feed us. Lots of people give us rides. Some people open up their houses. My kids make friends everywhere. Terrific people.
4. Not completely modernized. We stay in Huajuapan which is a decent sized small city. It’s got lots of restaurants and a few hotels. Grocery stores and mobile phone shops. And the water is often not hot. And the sidewalks can prove challenging. You might end up riding in the back of a pickup truck. Or walking a long ways in very hot, humid weather. On the good side, there’s no McDonalds and all the little shops are very interesting and very reasonable.
   
5. Beautiful. The area around Huajuapan de Leon is gorgeous mountainous country side.
   
6. Pretty inexpensive. Airfare is a bit pricey but after that it’s not expensive. Hotel rooms run $10-40/night. Dinners might run $3-15/person depending on what you decide to eat. So you can stay there pretty inexpensively. The van ride to Huajuapan is so cheap, I can’t figure out how the price of the ride from Oaxaca can cover gas. I spent a good hour of the trip doing math in my head and I have no idea how they are making a profit. Cabs around town are just $1-2, but cabs out to the other towns where are labs are can be quite pricey. (The cab drivers are friendly though. Avni and I took a cab out to Saucitlan de Morelos once and the cab driver was not just worried about leaving us there when we couldn’t find our friends, he was worried about the whole town because they had no phones and no cell service!)

So should you come? If any of that sounds fun, absolutely. We need you and you’ll be doing good in the world while having fun. If you can’t, no worries. If possible, contribute to some cause to make the world a better place. You can donate to Kids on Computers!

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post Use your vacation to do good in exotic locations appeared first on STORMY PETERS.

“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.)

GNOME and KDE defined each other by competing in the Linux desktop space. Without an option between KDE and GNOME, very few Linux desktop users would know what a “desktop” was or what part of the Linux desktop was created by GNOME or KDE. By defining each other as competition, they helped explain who they were and what problem they were trying to solve. They also constrained themselves to the Linux desktop. That was good as it let them shine in a defined space, but if they want to move to new markets – like mobile, they’ll have to be careful to define new competition to explain to partners and users who they want to be.

Firefox, Internet Explorer, Safari, Opera and Chrome have a long history of competing. They’ve helped define each other and the web.

So don’t be afraid of the competition. Choose your competitors wisely and let them help explain your story.

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post Your competition helps explain who you are appeared first on STORMY PETERS.

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:

• Chat informally. While most people will tell you it’s important to have an agenda for every meeting and to stick to it, I think that if you never see your colleagues at the water cooler, you need to build in some time for rambling. Maybe you’ll gripe about the latest project, maybe you’ll share the cool project you’ve been working on with your kids, maybe you’ll just talk about what you had for lunch. Or maybe you’ll have a great shared idea that inspires you to write that blog post that changes the whole project. It’s those relationships that enable you to informally share how you feel about the projects you are working on.
• Send that trivial piece of feedback. Often I’ll send an irc message or an email that just says “I liked how you did this” or “here’s a piece of feedback I heard about your project”. Sometimes they seem too trivial for an email message. But if I don’t send the email, and I store them all up for the next time we talk in person, I might not send them at all. (I also keep a file where I keep track of things I want to talk to people about next time I interact with them. Things I think are easier to explain via interactive chats.)
• Keep open channels. If at all possible, have some sort of real time channel where you can reach your colleagues. Best is a something like IRC where you can hang out and have informal chats. But if not a standing room, at least know how to find them via IM or txt messaging.
• Be available. Be available in as many channels as possible. I’m regularly on irc, Skype, IM, email, txt messaging, Twitter and Yammer. And I try to respond in a timely fashion. Why? Because when someone thinks of something they want to tell you, you don’t want them to have to remember what they had to say until they get back to their desk. Right then, while they are standing in the hallway, you want them to be able to ask you “what do you think about …?” (You also need to make sure you aren’t letting your life be completely interrupt driven, but that’s for a different post.)
• Get help. Ask others for help. I’ll regularly ask people I talk to what it feels like in the office or what they think about a paritcular project. What the mood is like, what people are talking about. Or I’ll say, “the next time you chat with so-and-so, can you ask him what he thinks about xyz?” I’ll also tell them I’m worried about a particular person or project and ask them to check in for me. After a meeting, I’ll check in with other folks that were at the meeting to share perceptions on how it went.
• Meet regularly. If there are projects you care about, make sure you meet with the principal people on those projects regularly.
• Meet in person. GNOME folks go out of their way to attend GUADEC – often taking vacation and time away from their families. It’s an important event because it’s the one time a year when much of the GNOME community gets together. Meeting people you work with in person is invaluable for community building. I love how humor in email makes much more sense after you’ve met someone in person.
• Ask them. Ask how others are doing, how they are feeling, what’s top of mind, what keeps them up at night, what makes them feel so passionately that they are working at 3am, ask them – you never know what you’ll learn or what you’ll be able to do together.
• Communicate effectively. I used to say “over communicate” but I now believe you have to communicate effectively. If you publish everything in the world on your blog and nobody reads it, or the important pieces get lost in the noise, you haven’t communicated. But it’s key to make sure people hear what you are worried about and the ideas you have for solving problems.

How do you effectively have hallway conversations when you don’t share a hallway with your colleagues?

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post How to have hallway conversations when you can’t see the hallway appeared first on STORMY PETERS.

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.
• German Poo-Caamanyo, Director of GNOME Foundation. German 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).

The timeline

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.
• German 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!

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post How to hire an Executive Director appeared first on STORMY PETERS.

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?

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post Does open source exclude high context cultures? appeared first on STORMY PETERS.

But the more I think about it, the more I realize that I am in this field because I really like the people. And 95% of those people are men and I appreciate them. I appreciate all the help they’ve given me whether they knew they were helping or not!

So I decided it’s time to thank all the men that I appreciate, who have helped me in my interests and my career.

First, there’s my dad. He not only told me I could do whatever I wanted to do, but promised to make sure I had the opportunities. I think he’s always been secretly disappointed I didn’t want to play football.

To my grandpa. He told me it was his sandbox, so I could play in it. He taught me how to defend my right to participate with out a leg to stand on — it wasn’t his sandbox. (And to Chris who taught me how to play toy soldiers in that sandbox. I still consider that to be one of the most boring games I know but it taught me how to steer the game or the conversation in the direction I wanted it to go.)

To my uncle John who saved all his computer magazines. He asked me once if I wanted to organize conferences. I stand by my firm answer of no, you’d have to be crazy. (But I do help out occasionally!)

To my uncle Larry who used to save me boxes of science fiction books. Boxes! Boxes of science fiction books! When you live in Spain and can’t get them that was a treasure.

To my great uncle Ted who was more delighted than I was when I finally managed to beat him in a game of cards.

To my boyfriend Frank who projects complete confidence that I can do anything. Except mow the lawn. But he is willing to get in a small boat in a big ocean with me. And he listens to my excited stories and my gripes and promises to beat up anyone who bothers me. I know he’s got my back.

To all my friends that I hang out with online and at conferences. I couldn’t possibly hope to list you all in one blog post but you’ve made all the difference. Especially those that welcomed me in the beginning. Meeting all the HelixCode guys. An afternoon hanging out with Havoc Pennington and the Eazel guys in Copenhagen trying to stay awake. Dave Neary encouraging me not just to be GNOME Foundation member but to run for the board! I didn’t run for the board then but he did later convince me to apply for the executive director job.  Dinner with Bastien Nocera, Jeff Waugh and Glynn Foster.  A cab ride with Daniel Veillard during which he explained why he didn’t trust OpenOffice. An afternoon hunting for saffron with J5. Conversations with Bradley Kuhn about free software and community and who was always helpful even when I was causing him great grief. All the questions that Vincent Untz answered for me when I started as Executive Director of GNOME – he was probably starting to get worried there! For Luis Villa, Brian Cameron, Lukas Rocha, German Poo-Caamanyo, Behdad Esfahbod, Diego Escalante Urrelo, who took all my suggestions seriously and never acted like any question was stupid even when they were. For Jeff Schroeder who regularly pings me and encourages me on the ideas I’ve mentioned. For Paul Cutler for always making time to meet in person even when I delayed his trip home! For Ragavan Srinivasan who taught me we can be the ones to start something. And for all my new friends in the world of JavaScript and web development. Dave Herman, Christian Heilmann, Trevor Lalish_Menagh, Robert Nyman, Peter Svensson … Even after I’ve shown I have no clue how to write good JavaScript, you’ve still made me welcome.

And a whole bunch more people that I’ve talked to on IRC, IM, in hallways, over lunch or a beer, … I’m not leaving you out. But I do have to get back to work at some point.

Thanks to all of you. For all the conversations, for all the ideas you’ve shared, ideas you’ve given me feedback on, questions you’ve answered, trust you’ve shown, … I thank you. Hopefully I am successful in returning the favor or passing it on because I think it’s what makes our communities great. It’s what will continue to bring more men and more women to our communities.

That’s why I’m part of these free and open source software communities and why I’ve chosen this career path. For the people in the communities and the way we are making the world a better place together.

And I love the 5% that are women too! But I feel like I owe the guys a special thank you as we don’t often mention how encouraging and helpful they are.

Stormy

Stormy Peters works at AWS on open source strategy and communities. She has spent her career at GitHub, Microsoft, Red Hat, Mozilla, and the GNOME Foundation building the programs and communities that help people be successful with open source software. She speaks regularly on open source, community strategy, and developer relations. Find her speaking history and past talks at stormyscorner.com/speaking.

stormyscorner.com/

The post The secret to my success in a field of men? All my friends. My guy friends. appeared first on STORMY PETERS.