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.

Speak their language: communicate in the right tool

One of the best pieces of advice I got was “Find out if they are an email person or a phone person and communicate with them that way.” These days you have to add text messages, hangouts, whatsapp, irc, etc to the list, but the same principle holds true.

I’ll give you an example of how this can go wrong if you don’t “speak the right language.” Someone recently called the GNOME Foundation Board and identified themselves as press and asked to speak to me. Note that the board doesn’t have a phone. It’s just a virtual mailbox because organizations are supposed to have phone numbers.

If he had emailed the list, I’m confident he would have been forwarded on and gotten an answer (or been told no) within 24-48 hours. Instead he called.

I read about it in the board meeting minutes.

Here’s an overview of the proposed agenda/topics for this meeting:

* Adboard meeting at FOSDEM 2015
* Next steps for the Outreach Program
* Responding to a phone press inquiry asking to reach S. Peters

I replied back that if he was looking for me, he should be able to find my contact information easily on the web but that they were welcome to forward him to me or to the press list. Now note that they can’t forward it. It’s a voice mail in a virtual voice mail box.

So the next week I read in the minutes:

Deferred:
* Responding to a phone press inquiry asking to reach Stormy Peters
* Comment from Stormy: “There is a press mailing list to deal with press inquiries. And if they are looking for me, they should be able to find me but you are welcome to point them my way.”
* ACTION: maybe Rosanna can check with the caller to see what he wants and see if we need to get back to him by press contact, or if he really wanted to reach Stormy in particular?

Now, before you say how absurd, why didn’t they call him back, I want you to think back on all your communications over the past week. If you are like most people, I bet there’s at least one email, text message or voice mail you haven’t answered yet. And one of those unanswered messages is probably in a medium you don’t like to use much. People that know you well, know whether to send you a text message or an irc ping if they need a quick answer from you.

I think this is especially important when it comes to team communications.

If your team usually communicates over mailing lists and irc, and you set up a video meeting, does that fit their culture? If you set up an irc meeting, does that fit their culture? And if not, are you purposely trying to drive cultural change? Did you tell them that?

I tried holding all my extended team meetings as irc meetings instead of video meetings last year in order to involve more volunteers. It didn’t work. I’m guessing it’s either the meetings themselves that are either not in the culture or the meetings were not useful or our internal structure of teams didn’t match what volunteers thought of as projects.

Project communication goes beyond meetings and includes things like announcements, discussions and decisions. Should announcements be emails from a single person or newsletters or blog posts in your project’s culture? Should discussions happen on irc or mailing lists? Should they be logged? Should decisions be made on mailing lists, in meetings or in bug tracking tools?

How does your team communicate? How do you change those channels when you need to? Or can you?

Can or Can’t?

10628746_986665307681_7544861487392315883_o
Can read or can’t eat books?

What I love about open source is that it’s a “can” world by default. You can do anything you think needs doing and nobody will tell you that you can’t. (They may not take your patch but they won’t tell you that you can’t create it!)

It’s often easier to define things by what they are not or what we can’t do. And the danger of that is you create a culture of “can’t”. Any one who has raised kids or animals knows this. “No, don’t jump.” You can’t jump on people. “No, off the sofa.” You can’t be on the furniture. “No, don’t lick!” You can’t slobber on me. And hopefully when you realize it, you can fix it. “You can have this stuffed animal (instead of my favorite shoe). Good dog!”

Often when we aren’t sure how to do something, we fill the world with can’ts. “I don’t know how we should do this, but I know you can’t do that on a proprietary mailing list.” “I don’t know how I should lose weight, but I know you can’t have dessert.” I don’t know. Can’t. Don’t know. Can’t. Unsure. Can’t.

Watch the world around you. Is your world full of can’ts or full of “can do”s? Can you change it for the better?

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

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

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

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

There are some major benefits to synchronous conversation:

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