It’s true: because you can travel, you have to

I once sat on an airplane for 20+ hours in order to spend a day in Italy. I spent the whole trip wondering why we had to meet in person when we have all this technology like video calls, email, irc. While having my surreal foreign driving experience where a gazillion lanes merged into a few and all the signs were in Italian, I tried not to let my jet lagged brain wander and I wondered what I was doing.

Why, when we have so much technology, do we have to travel so much to work together?

MDN Hackfest, March 2015

And the secret is to flip the question around. It’s because we have all this technology that we have to travel. Because we can communicate and work with anyone around the world, we do. And when you work with people, you need to meet them. You don’t need to see them every day, but you need to understand how they talk, how they hold themselves, what’s important to them, what makes them raise their voice in excitement. Once you meet them, you’ll read all their emails differently. You’ll get what they are trying to say in that pull request so much faster. You’ll be a team.

Once you’ve met them, had a beer with them and learned that they too have a five year old kid, you’ll be more likely to be willing to get up at 6:30am for a meeting with them. You’ll be more likely to tell them you think something’s wrong with their idea and believe that they’ll really listen to you. You’ll be more likely to ask them for help. Because of how the human brain works, you’ll be more likely to remember them in another conversation where something they are working on will go together wonderfully with the idea a new friend is talking about.

Meeting in person is key to working well together. Technology lets us work with more people in more places and so now we travel further to meet each other.

10 Ways Community Managers Make Sure Projects are Healthy

Community managers must make sure their projects are healthy. Before they can help foster and grow a community, they have to make sure it’s a well functioning, welcoming place.

Photo from the Library of Congress.

While community managers and project leaders often don’t explicitly talk about what’s not working well, you will often find them doing a wide variety of things. They are doing whatever is needed — filling in the gaps — to make their project work well so that new people can join.

Here are some of the things that an open source software project needs in order to be healthy and grow community.

  1. Getting Started. In order for new people to join, here has to be an easy way to get started using the project and an easy way to get started contributing. Usually 30 minutes is the maximum amount of time someone will try to install and use your product for the first time.
  2. Clear Goals. A project needs clear goals before its community can grow. New members need to know what problem the project is trying to solve and how they plan to do that. Without a clear vision and set of goals for the project, someone who hasn’t been involved with the project won’t know what contributions might be welcomed.
  3. Target Audience/Market. As part of its vision and goals, a project needs to know who it’s for. Is it for enterprise software developers or elementary school kids?
  4. Project Lead. The project lead can be a single person (like Linus Torvalds) or it can be a small group of people (like Samba) or it can be a group of people (like Apache) but it really helps the project identity, the decision making process and the goal setting to have leadership.
  5. Release Management. Every project produces something and there needs to be a way that “something” gets produced and published for people to use. And a place where people know to find the latest version.
  6. Project Infrastructure. Every project needs some amount of infrastructure. Most projects need source code control, bug tracking and mailing lists. They also probably need a website, a place to publish documentation and a way to manage finances.
  7. Roadmap. Sometimes a project’s roadmap is simply a backlog of issues. Sometimes it’s a Trello board. Sometimes it’s a detailed 2 year roadmap. Whatever form it takes and however much detail it has, it’s important to the project to know what’s next.
  8. Governance. A well-defined project has clear processes for how decisions are made and who gets to make them. Some projects have well developed governance processes. Others have light weight, undocumented processes. But without some sort of governance, the project is likely to stall often.
  9. Advocates. In order for a project to grow, someone must be talking about it. These advocates may be users or contributors. They may be spreading the word on the internet or at in person events.
  10. Events & Outreach. More advanced projects will start to participate with a talk or a table at existing events and may even start to hold their own events.

If any of the above things is not working, it will be hard for a project to attract new users. A good community manager or project lead will focus on making the project run well first before inviting new people to join.

3 ways open source software communities could learn from Crossfit

Photo by Anthony Topper.

This week I am participating in the opensource.com community blogging challenge: Encouraging New Contributors!

Crossfit gyms are great at creating community and welcoming new members. Here are 3 things that Crossfit boxes do that open source software communities could also do to encourage new contributors:

  1. Say hi to the new person. I drop in at gyms around the world, and no matter where I go, everyone in the class comes up to say hi to me and introduce themselves. How awesome is it that I can go to a gym in Frankfurt and have 10 total strangers walk up and introduce themselves and say how happy they are that I’ve joined them?
    For open source: When you see a new person on your mailing list or IRC channel, stop and say hi. Introduce yourself and tell them they are welcome. You can do it publicly or privately. (If you do it publicly, you might set a good example for others!)
  2. Celebrate daily accomplishments. When we finish a workout at my Crossfit gym, we all post our scores in an app. It gets ordered from best to worst but no matter where you are in the line up, everyone will  give you a virtual fistbump and most of them will notice when you’ve had a spectacular work out based on your skill level and they’ll congratulate you for it.
    For open source: Have a place where people can note what they’ve done, maybe point out what they are proud of or what was hard for them, and get kudos from others. Sometimes this happens on source code control systems. Sometimes on IRC. I think most open source software projects could do better at this.
  3. Allow for off topic interactions. To really build community, you have to know each other. Sometimes that’s hard to do if you just focus on the work all the time. There has to be a place to chat, to share goals, ideas and maybe every once in a while, a non-project focused thing. In my Crossfit box, we do this in a Facebook group. Usually, it’s fitness related but sometimes it’s just chatting about life in general. The group gets noisy and I turned off notifications, but I still visit at least once a day to congratulate, commiserate and just visit. It’s a place new members can ask questions, learn more about the community and get to know each other.
    In open source communities: Find a channel where people can chat. A place where they can ask all their questions, express frustration over a piece of code or complain about the weather. Sometimes it’ll get noisy but usually it will bring people together and, more importantly for the new people, help them “see” the community they are joining. Most open source software projects do this on irc or Slack.

How do you think open source software communities can Encourage New Contributors? What have you learned from the other communities in your life?

Our World Depends on Unseen Labor: Open Source Software

Our digital infrastructure is all open source. It’s built and maintained by a relatively small community of open source software developers. Right now the open source software work is funded by a variety of methods: volunteer time, nonprofit corporations and donations of time and money by a few corporations. Is that sustainable? Or should we be looking for ways to fund our digital infrastructure much like we do our roads and bridges through government or community efforts? This is the question that Nadia Eghbal poses in her very comprehensive paper covering her research funded by the Ford Foundation.

About a year ago, at the recommendation of a friend, I met with Nadia Eghbal. Diane Tate introduced her as someone “who recently left her role in venture capital to explore ways to support developers working on early infrastructure projects.” We had a fascinating conversation. Nadia was trying to expand the venture capital world and when she went looking for projects that venture capital doesn’t fund but that really need funding, she found the world of open source. In particular, she found that the infrastructure behind most of our current technology is based on open source software maintained by a small community of developers. Some of them work for nonprofits that pay their salary (like the Linux Foundation now sponsors OpenSSL), others have corporate patrons who pay the salary of maintainers who work on projects they use (like HPE and Google) and others are completely volunteer based.

Nadia believes that our policy makers, grantmakers and activists are unaware of the role that open source software plays and, when they have heard of it, they erroneously believe that it’s well funded. As an example, the IRS is no longer granting 501(c)(3) status to organizations that primarily produce open source software with the argument that software is not a public good and they can’t guarantee that people won’t profit from it.

Nadia’s report, funded by the Ford Foundation, is a great read. I highly recommend it to anyone interested in learning more about open source software, how it works and how it’s funded. Warning: it is very long! Think about it more as a short book than a blog post!

Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure

The code review culture kills new ideas

First published on Medium.

Many open source organizations start around code. Someone has an idea and they write some code to express it. If people like the idea, they add more code. That code gets reviewed and incorporated.

This works great while the project rallies around the original idea. However,when they go to add new products or plan new features, the culture of code reviews gets in the way of a culture of new ideas.

Why’s that? Because code reviews look for flaws. You need to make sure you don’t introduce bugs. Ideas, on the other hand, need a whole team of input before they are strong enough for the risk analysis. New ideas get stronger when people add to them, figure out ways they can help. Once ideas become a plan they need something like a code review but not before they become a plan.

Reviewing Code is about Eliminating Risk

When new code is submitted, it’s always reviewed before it’s accepted. And often there are very clear guidelines. You are reviewing to make sure that your project’s guidelines are met, that the code is well written and that it introduces no new bugs. Often this means you are looking for things that are wrong. You may also suggest improvements, but the focus is on looking for things that are wrong.

Reviewing Ideas is about Exploring Opportunity

When new ideas are reviewed, they are often not fully formed. Ideas, especially new product ideas, need the entire organization to help figure out the full potential, what each team could bring to the table and how people might react to it. New ideas need to be fully developed before you start poking holes in them. And new ideas cannot be fully developed by one person. They need a whole team of people to say, “yeah, that’s great, and I could help by linking it to this other thing I’m working on” or “yeah, I like that and it makes me wonder if we did this, if that would be even better.”

What happens when you apply code review techniques to ideas?

When you apply code review techniques to ideas, you kill them before they are fully developed. You look for everything that is wrong in an idea. You look for all the risks, all the holes, before you add your strengths to it. Just when the idea needs you to help figure out how it could succeed, you poke a hole in it.

Next time you see someone in your organization propose an idea, make your first reaction an additive action. Challenge yourself to make the idea even better instead of looking for the bugs.

What’s in a good developer relations plan?

Developer relations is the combination of activities, programs and tactics to get developers using or developing for your organization’s product or ecosystem. The goal of a good developer relations team is often to make your organization’s product or ecosystem the first choice for developers. (You may be doing this just to sell more of your product or you may be doing this because you believe your product’s mission helps make the world a better place. You are still trying to get more developers using your product.)

What’s the goal of a good developer relations plan?

Your developer relations plan needs a goal that you can focus on. You need to be able to measure the results of your activities so that you know what you should do more of and what you can do less of.

Some potential goals for a good developer relations plan might include: (Some of these by Patrick Chanezon.)

  • Increasing the adoption of your organization’s product. Example: more people using Firefox.
  • Increasing the number of available complementary goods. Example: more 12 factor apps running on Cloud Foundry.
  • Providing an opportunity for developers to profit. Example: an app store for developers to list their applications.
  • Growing the number of people that benefit. Example: training companies, consultants, app providers.
  • Reducing the cost and risk of using your product.
  • Increasing the percentage of developers that are developing only or mostly for your product.
  • Increasing the network effects in your ecosystem.
  • Decreasing the cost of adopting your platform or increasing the cost of leaving your platform.
  • Creating an environment where developers just assume they’ll use your platform.
  • Encouraging third party tools, trainers and consultants for your platform.
  • Creating a community of volunteer advocates.

Some developer relations groups also act against the competition. I don’t think that’s a long term strategy. Your product and ecosystem have to be good.

What are the stages of a developer relations audience?

Screenshot 2015-08-13 15.04.58

You can move from one stage to the other using many different techniques. Breaking down the stages a bit further, you can map how specific evangelism activities like blogging or talking, might take you from one to the other.

2015-08-13 15.13.55

Who should you have on your developer relations team?

While we usually talk about developer relations as teams, we also need to look at their functions. While each team has a primary function, functions are often shared between teams. Mozilla has outreach and content teams. Google is also organized this way, as presented in a talk by Patrick Chanezon.

  • Outreach. Creating awareness of the product or ecosystem among developers. Most outreach efforts include evangelists. These are people that go out and speak, engage with others, teach enough to get people started, write blog posts, let large numbers of people involved. They are typically most involved in the outreach and awareness part of the program.
  • Content. This includes tutorials, documentation and examples. Making sure that developers that are interested in the platform have the materials they need to learn it. This team should include technical writers, educational experts and programmers. These are the people that are most involved in the online training part of your program. They write documentation that lets people learn how to use the technology. Sometimes they write the examples. Sometimes they create training or online tutorials.
  • Support. When developers start using your product, they will need people to help answer their technical questions or help resolve the bugs they find. This team usually consists of support engineers. They are around to answer questions, help people get going, create code examples. Often when bootstrapping, this function comes from the evangelists but it’s really a different type of personality and role. This team is most likely to provide valuable feedback to the product teams.

There’s another couple of roles worth calling out.

  • Program managers. A successful developer relations program often relies on programs. These might be things like a world wide community run, simultaneous events or a “free phones for apps” program.
  • Key stories/participants/case studies. These are people that have a story that successfully highlight what you are trying to do. And, while they might not be evangelists, they are competent spokespeople. You talk about them, point people at them, highlight them, enable them to tell their story and help them spread it.
  • Event managers/coordinators. Smaller groups might have several volunteers. Larger organizations might have lots of volunteer meetup or hackathon organizers and maybe even a paid staff team to support them.
  • Community management. Whether or not you have an official community manager, there are probably numerous people helping out with “community management” whether it’s onboarding new contributors, reviewing patches or answering questions on the mailing list.

What are the key components? What types of tools and projects are useful?

It’s useful to first look at your project’s strengths. Do you have a large community? Strong contributors? A highly followed blog? A strong culture of global meetups? A clear brand?

Some of the projects and tools you might consider are:

  • Programs that support your goals. For example, Mozilla ran Phones for Apps.
  • Messages/materials. Developer relations can either include product marketing and press or work closely with those teams to develop messaging and materials that support the goals and the audience.
  • Events. Events can include everything from monthly meetups to hackfests to large annual conferences. Many teams often divide events into the organization’s events, sponsoring others events and sending speakers to events.
  • Training. As people join your ecosystem or start using your product, they are more likely to stay if they can get the training they want. Cloud Foundry has “dojos” – a place at several member organizations where interested developers can go train with a more experienced member for six weeks.
  • Examples. A key component of learning is being able to see how something is done and copy it. At Mozilla we created Demo Studio to allow people to share and build on others work on the web.
  • Documentation. Documentation is key to a project for two key reasons. One is discoverability and the other is learning and support.
  • Contributors. Depending on the type of product or organization you are supporting, you may want programs in place to specifically support contributors. This may be as simple as swag or as involved as official titles and budget for programs and travel for them.
  • Feedback mechanisms. An important part of many developer relations teams is providing feedback mechanisms for users to give feedback to the product teams. It helps to put into place objective tools and mechanisms for this.
  • QA forums. Question and answer forums like StackOverflow have become critical to how developers expect to find help when they are working. Having a standard place where your experts will be will help.
  • Membership. Often membership can support the different groups you want to grow. You can have users groups, contributor groups, advocacy. You can use titles, mailing list membership, swag and travel funds to distinguish and reward them.
  • Discussion. A place where people can come and chat and “hang out” with your community is important. Q&A forums often give them answers but not a sense of belonging. Also discussion groups are often an easier way for really new users to get started.
  • Advocates. Recognize our key advocates and give them a megaphone. Connect them with the press and speaking opportunities.

What does your Developer Relations plan and group look like? What would you add to create your ideal plan?

What labels are applied to you every day?

When you hear that a 13 year old, black girl is giving a keynote at OSCON, what do you think?

  1. Wow, she must be a child prodigy, what did she do?
  2. Who are her parents?
  3. She got that keynote because she’s a 13 year old, black, girl.

I’ve heard all three options and a few in between.

The truth is that Keila Banks is pretty awesome. She’s an accomplished blogger/technologist and her 10 minute keynote (to a 4,000 person audience!), “The Undefinable Me”, is well worth watching.

And Keila’s parents are pretty awesome too. They have given Keila lots of support and encouragement as she explores the opportunities around her. They are as inspirational to me as a parent as Keila is.

“Just do it” vs “Make it count”

I was standing on stage last week when I realized that the words out of my mouth were in direct contradiction to advice I normally give. Nothing like having a couple hundred people and a video camera staring at you as you try to figure out what you really mean.

Just do it

In the past, I’ve pointed out that it’s really hard for people to make their first contribution. Think back to that very first time you posted to a mailing list or newsgroup. It was a bit intimidating. You don’t know how many people will read it. You don’t know how people will respond. And it will be public forever. That’s pretty intimidating.

So I urge that you just have to do it. And community managers and mentors need to help people to Just Do It.

Make it Count

And then last week, I said first impressions count. So make sure your first point is one you want people to remember you by. And in the context of my talk, I said you should especially pay attention to first impressions if you are in the minority. Do you want to be remembered for that crazy red shirt? Or for the great question you asked about the target audience that started an awesome debate?

When I first started at GNOME, they added me to Planet GNOME and my very first post was about traveling alone. I wish I could take that back. It’s not a bad post. It just has nothing to do with GNOME and it’s not what I wanted the whole community to know first about me.

You can recover from less than stellar first impressions. All the GNOME posts I’ve written since then about the GNOME Foundation and projects have surely made up for that first off topic post.

Finding balance

The balance between Just do it and Make it Count is even harder in some circumstances.

  1. Representing multiple groups. If you feel like you are representing others, especially as a lone representative of a minority group (the only woman, the only American, the only Asian), you will feel like your actions have to be even better, and that your first impression has to be good.
  2. More experience. I also think that more experience makes it harder to “just do it”. Once you are seen as an expert, posting to a mailing list is probably no longer scary. However, you might feel like your work is held to a higher standard and that more people are watching you. (And I think this ties directly to the Impostor Syndrome.)
  3. Other disadvantages. I also think it’s hard to just do it if you have another disadvantage. For example, if you first language is not English, it’s much harder to make that first post.

What’s your balance?

How do you find balance between “Making it count” and “Just doing it”?

 

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

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:

  • 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?

Join the Open Source Track at Grace Hopper this year!

There’s a Free and Open Source Software Track at Grace Hopper this year! Submit your proposal now and come join us.

Grace Hopper is the largest gathering of women technologists and it’s a super energizing conference. They are expecting 11,000 people this year – which I find kind of scary. But my experience at Grace Hopper has always been very welcoming – a place to see old friends and a great place to meet new people. I always see quite a few women from the industry that I know and I always meet a couple of more – usually a couple each time that I still remain in contact over the years. It’s how I met the HFOSS folks and where I met Corey Latislaw who is now a Kids on Computers volunteer. I also always see at least one speaker who makes a huge impact on me. One year a keynote speaker made me cry and laugh several times all in one talk. Another year, the President of Harvey Mudd College was on the imposter panel. She talked about how she felt like an imposter asking for a $25 million donation when the people all around her were much more successful and wealthy. GNOME owes part of its financial success that year to her. Because of her stories, I had no problem going and asking all of the advisory board member companies if they could double their contributions.

Heidi Ellis and I are co-chairing the Open Source track and we’re both excited to bring the new things happening in the open source world to a larger audience. We want to get more of the women at Grace Hopper involved in free and open source software. Or at least aware of the opportunity. Please consider submitting a proposal to the track. Formats include presentations, lightning talks, panels, workshops, and birds of a feather.

Men and women are welcome at Grace Hopper although I warn you (both men and women!), if you’ve never been, it feels very strange at first to be at a technical conference that is almost all women! There are also a lot of students at Grace Hopper and that too adds to the energy and the unique feel of Grace Hopper.