3 important things to consider when measuring your success

Photo by Thomas Leuthard.
  1. Figure out what to measure. How will you know if your open source software project is wildly successful? What will be different with the world? What problem will it have solved? If you don’t know the answers to these questions, you won’t know what to measure.
    Often when projects start out, they measure what ever is possible. For example, you start a blog and you measure web site visitors. But that in itself is not a measure of success. It might be a measure of popularity or reach, but not of success. Why’d you start the blog? Maybe you want people to know Linux is an awesome operating systems. In that case, a measure of success might be how many people use Linux. Or how many people try Linux after reading your blog. Or how many repeat visitors are now on Linux instead of an alternative operating system. Obviously, some of these things are harder to measure than others. But defaulting to number of visitors is a crutch you should only use temporarily while you figure out better metrics.
  2. Change your metrics over time. What you measure will also change over time. As your project evolves, you’ll be able to measure more sophisticated things that more accurately reflect your goal. You might start out measuring number of visitors and evolve into number of people who convert within a month of visiting your blog. Both the way you can measure things and what your project can do might change. And your goals themselves might change. Maybe you started out to create a login widget and then realized what was really needed was a user management tool. You should never be afraid to change your metrics. If you are afraid of losing data over time, you can keep measuring the old metrics.
  3. Keep it simple. It’s much better to have one or two key metrics than to worry about all the possible metrics. You can capture all the possible metrics, but as a project, you should focus on moving one. It’s also better to have a simple metric that correlates directly to something in the real world than a metric that is a complicated formula or ration between multiple things. As project members make decisions, you want them to be able to intuitively feel whether or not it will affect the project’s key metric in the right direction.

And then, make sure your metrics are working. Double check that when you are closer to your goal when your metrics get better. If not, time to figure out what else you could measure. For example, maybe you were measuring number of contributors, but signing up more contributors does not seem to be getting you closer to your goal. You might want to look at measuring monthly contributions or active contributors.

If I was going to recommend one book for getting started in thinking about metrics, it would be Lean Analytics. Thanks to Luke Crouch for the recommendation and the many good conversations.

Create better processes to avoid difficult conversations

The best way to handle difficult conversations is to prevent them from ever starting. The way to prevent them from happening (or at least to keep them less painful) is to have good governance. Governance is the solution to difficult conversations and trolls.

My motto is that you’ve done the best job you can do when you work yourself out of a job. When you have solved the problem, you eliminate the need for anyone to need to work on it again in the future. So the best solution to difficult conversations is one that means we no longer have them. We’ll still have differences of opinion and a need for conversation but hopefully it won’t happen in painful ways. In order for that to happen, you need to have clearly defined ways to bring up new ideas, discuss differences of opinions, to make decisions and to execute on them.

Why do difficult conversations happen?

You maybe tempted to say difficult conversations happen because some people are awful. But nobody really likes to go out and argue. Worst case they are lonely or feel misunderstood. However, in open source, difficult conversations usually happen because people feel passionate about something and are missing either the tools, the communication skills or the place to do something about it. Maybe a decision was made without giving people a chance to comment. Maybe they didn’t even know a decision was being made about something they thought was really important. Maybe they felt like their opinion wasn’t getting heard. Maybe they felt like everyone was rehashing the same conversation for the 100th time and nothing was getting done. Maybe they want to get something done and there’s no obvious way to sign up or just do it. Maybe they made a decision they feel applies to the whole community and nobody is listening. Maybe …

So how do you fix that?

In order to prevent difficult conversations, or to make conversations easier and more productive, you make sure your project has governance, processes and tools to let people express their ideas, debate the merits and work out the details. Sometimes you are able to create them before you have problems. Often they are created in reaction to problems. But no matter when you create them, creating good governance is an opportunity for your community to discuss and agree on culture, processes and mission.

Some of the components of governance, which may overreach into ethics and culture, are:

  • Leadership. Who leads? How are they selected? By whom? What if they do something wrong? Who succeeds them?
  • Decision making processes. When are decisions made by the leader? When are they made by a vote? What if someone doesn’t like the decision? How are things proposed? How long and where does discussion happen.
  • Codes of conduct. What behavior is expected? What behavior is inappropriate? What happens if someone misbehaves? Who decides that it was misbehavior?
  • Communication. How does it happen? Online vs in person? Who can attend? Who is expected to attend?
  • Mission & Vision. Who defines them and through what process? How can they change?
  • Money. Can your project make money? Accept money? Can individuals in your community make or accept it for work they do in relationship with your project?
  • … what else would you add?

Often governance grows like culture. Slowly, without anyone noticing. So it’s helpful to stop and take a look at what governance you have, what’s explicitly defined and what your project might need moving forward, especially if it’s growing.

For an example of how governance and cultures evolve in communities, you can follow along as Fedora redefines its mission, Gluster decides who is a maintainer and Drupal evolves its governance.

Can your community get too big?

Open source software communities, like companies and cities, can come in all sizes. They don’t get too big but they can grow faster than their infrastructure and processes.

Take for comparison, the size of companies and cities. Companies come in sizes from one person LLCs to 100,000 employee megaliths. Cities come in sizes from a single person farm to enormous cities with 10’s of millions. Are some big companies too big for some people? Absolutely. Are big companies good at getting certain types of tasks done? Yes. Some people prefer some companies and small towns (maybe not the same set of people) and some people prefer big cities and large companies (again, maybe not the same set of people.)

So, can open source software communities get too big? Not really. But they can grow too fast. They can grow faster than their infrastructure; they can outgrow their governance; they can leave their mission behind.

So how can a community grow productively? By considering things like:

  • Onboarding processes. I’ve actually heard of communities having so many new people show up that to answer all their questions would have meant nobody would have time to get work done!
  • Infrastructure that scales. Where are you going to put all those new people? Will your source code control system, your chat system, and your blogging system scale?
  • Governance. As you have more people involved, you may want different ways of deciding membership and making decisions. OSI moved to individual membership from a self elected board. Gluster is moving to a new maintainer model as it grows. The evolution of process takes time and thought.
  • Mission statements that evolve. Sometimes you accomplish your original mission and you’ve moved on to something else and you need to state that for new and existing contributors like Fedora is doing now.

What else needs to grow along with your community?

Part of the OSS Communities series — maintaining existing community. Contribute your stories and tag them on Twitter with #osscommunities to be included.

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?

Life at Red Hat: Week 1

I just finished my first week at Red Hat! I flew out to Raleigh last Sunday night and attended New Hire Orientation (NHO, in Red Hat speak) Monday and Tuesday. There were 18 of us in the class from across Red Hat functions and business units. Most of us were a bit apprehensive of what 2 days of orientation would look like and all of us were anxious for our new laptops and email addresses which didn’t come until the end of the second day. We were all impressed – we got a good overview of Red Hat functions and Red Hat culture. Red Hatters are proud of their open, participatory culture.

Picture of group of new hires wearing red fedoras.

 

Just about every speaker, from legal to HR to strategy, talked about the open source way and how things are always circulated and discussed at Red Hat before they are decided. They even promised we’d get to see one of those discussions that very day on memo-list, the company wide mailing list. While everyone admitted that having very participatory, open processes was sometime painful, everyone spoke highly of the value of being transparent and open to feedback.

We had several speakers on open source specifically, including Michael Tiemann who spoke to us about how he first got involved in open source by starting Cygnus and how people and companies make decisions. To me, he was a very fitting first day Red Hat speaker, as he is one of the people I primarily associate with Red Hat – certainly he was the first that I used to see walking around with the red fedora at conferences!

At the end of the first day we had a social to meet our teams within Red Hat. I was super excited to see Scott Peterson and to learn he was working at Red Hat! Scott and I worked together at HP and he is the reason that I think open source legal issues are fascinating. He thought they were fascinating and was willing to spend lots of time explaining them to me. Although we’ve known each other for 15 years and worked together for a good number of those, this was only our 3rd time meeting in person.

At the end of the second day, we got our laptops. Luckily for me, using a Linux desktop wasn’t new. Unluckily for the IT team, I am keyboard or password challenged, so they had to wait around for 30 minutes to reset my password which I couldn’t reproduce. I am now signed up for a gazillion and one mailing lists and irc channels and learning how Red Hat does strategy, goals and finances.

I was very glad to get to meet with Joe Brockmeier in person as its his previous position that I’m taking over. I spilled my glass of water all over him at lunch, so I figure that should bring some kind of luck if it doesn’t alienate him forever. At least it wasn’t wine!

After I got home I continued the meetings. I’ve learned about the infrastructure tools that the Red Hat OSAS team is working on providing some of the open source upstream projects, as well as meetings with Red Hat community managers and others working with upstream projects. The Open Source and Standards (OSAS) team that I have joined, led by Deborah Bryant, directly supports CentOS, Ceph, Fedora, Gluster, oVirt, Project Atomic and RDO. They also work with Red Hat teams working with other upstream projects as well like OpenShift, OpenDaylight, PatternFly, Foreman and ManageIQ.

My first day at Red Hat!

Today is my first day at Red Hat! I am so excited to be joining this terrific open source software company, its communities and all the great people that work here. In some part, I feel like I’m coming home as many of the people I’ve worked with and admired in open source over the years will now be my colleagues at Red Hat. I met many of them while I was setting up the Open Source Program Office at Hewlett-Packard, had great community manager conversations with them and got good advice as I set up OpenLogic’s Expert Community, worked closely with them as Executive Director of GNOME and saw them often at events while at Mozilla and the Cloud Foundry Foundation – even getting to speak at the Red Hat Summit Women’s Leadership event last year. I’m looking forward to working more closely with friends and colleagues and meeting the Red Hat community!

What will I be doing at Red Hat?

I’ll be joining The Red Hat Open Source and Standards (OSAS) team leading the team of community managers. My job will be to guide community growth and success in upstream projects that Red Hat works with. I’ll be managing (i.e. supporting and enabling!) the team of community leads, as well as those that are embedded in projects, who work directly with upstream projects and coordinate with other stakeholders within Red Hat.

In the first few weeks, I’ll be working on understanding the open source software projects, their goals and communities, Red Hat’s goals, how communication happens between upstream projects and Red Hat teams, how teams communicate, grow and learn, what’s working well for them and what they could use more help on. Learning. I’ll be spending my first couple of weeks learning!

If you are working closely with one of the open source software projects that Red Hat works with and have insights or input for me, please reach out to me!

Changing roles …

As the world transitions to cloud native, Cloud Foundry is an important part of a new open source software ecosystem. Because of the open source Cloud Foundry project, companies and governments large and small are able to change the way they work, build on the knowledge of others and use technology to vastly improve the solutions they offer. Who would have thought we’d have open source software running on big windmills or as a fundamental part of the IT system at large insurance companies or as part of the new digital transformation of US, Australian and UK governments? Or that automotive, insurance, and finance companies would all collaborate on software?

I’ve enjoyed helping to make this new open source cloud world a reality by leading developer relations at the Cloud Foundry Foundation. As the next step in my journey, I will be transitioning from a paid staff role at the Cloud Foundry Foundation to a volunteer community role.

We have been putting community and processes in place at the Cloud Foundry Foundation to enable self-governing programs. Using my experience at Mozilla running and expanding the Mozilla Developer Network, as well as my experience setting up the OpenLogic Expert Community, I set up processes that will enable the Cloud Foundry community to continue to grow as the project and its large community of corporate sponsors continues to grow. For example, we created the Cloud Foundry Ambassadors, a self-sustaining program of volunteers to welcome and grow the community that is now growing organically. Cloud Foundry has grown by leaps and bounds and we now have contributors and product managers from our member companies creating and running self-governing programs for outreach and technology. I am proud of the programs we’ve created together for the Community to own and run.

The Cloud Foundry project is a vital part of our open source ecosystem and I will continue to be an active member in it, as I have with all my favorite open source software projects!

More news coming soon on what’s next for me!

P.S. Come learn about Cloud Foundry Dojos in my talk next week at All Things Open.

Would you be friends with a racist?

Photo by mad artichoke.

The election period is putting many friendships to test. If you are going to vote, you have to pick one of the candidates and neither candidate is perfect. Most people, especially in this election, believe strongly that the other candidate is terrible. And since they believe one candidate is terrible, they feel compelled to campaign for their candidate.

And this campaigning has led to many discussions and arguments. On Facebook, I’ve seen many of my friends saying they are unfriending people who support the other candidate, whomever that other may be.

Which led me to the question … could you be friends with someone who held at least one belief you felt was wrong? Could you be friends with a racist? Could you be friends with someone who is pro-life if you are pro-choice? Or pro-choice if you are pro-life? Could you be friends with someone who owns guns if you are anti-guns? Could you be friends with a hunter if you are a vegan? Could you be friends with someone you found out carried a gun in their jacket at all times? Could you be friends with someone who thinks all guns in hands of civilians is wrong? Could you be friends with someone who believes in a god if you are an atheist? Could you be friends with an atheist if you believe in God?

Some of my friends are adamant that the answer is no. If they can’t respect someone’s entire belief system, they can’t be friends. They often defend that view point by saying they are defending their personal freedom or the rights of others. To me, that feels like I’d be insisting I’m right about everything and missing out on lots of great people who’ve had different experiences that have led them to different viewpoints. By having diversity in my friendships, I’m more likely to be able to help us come up with solutions to some of the very difficult problems our world is facing.

Where do you draw the line?

Originally published on Medium.