Community

The Key to Open Source Effectiveness: “We Before Me”

You want to be an active open source contributor, but how do you do that effectively? Here’s one way to look at it: think “we before me.”The “we” here includes the open source developers you know and work with, but it also embraces your customers and all of the partners involved in a project you don’t yet know. With that in mind, here are eight tips for putting your community first in ways that will help you be successful yourself.

  1. Bring your whole self to the project: The first thing you need is an expansive view of your own capabilities. Open source is not just about code; it’s about documentation, community building, use cases, testing, issue tracking, performance, user experience, security and compliance. If you have experience with any of these, you can make a significant contribution to a project. So, don’t be afraid to bring your whole self when you get involved – you will be much more impactful if you do.
  2. Be inclusive: Open source is like stone soup. Someone has carrots, someone has peas, someone has onions, and so on. And from that we can make a soup that everyone can share and be nourished by. In the same way, people with different capabilities, needs and experiences can join together and make projects happen faster and more efficiently through an open source framework. But it’s not your job to decide what everyone else brings. This is especially true when it comes to decisions about howyou are going to build. If you try and limit the project to one kind of database solution, or one kind of hardware, authentication, monitoring or cloud framework, you are limiting the number of people that the project will help. Better instead to always be as inclusive as you can.
  3. Build your community: Community keeps open source projects going, especially through the inevitable rough patches where it’s hard to see a light at the end of the tunnel. So, it’s essential that every contributor supports community building. We grow our community by being inclusive; by inviting people in; by educating each other about what everyone needs to know. Mentor new people and help them build confidence. Blog about your project to inform people of its existence, value, use and field trials. Host meetups, build tutorials and give talks. All of these bring us a larger set of contributors and help drive the success of our projects.
  4. File your issues: When you are developing software internally, your job is pretty clearly defined, which means you may not be expected to hunt for issues or file the ones that you come across. In open source, however, these are jobs everyone is invited to do. So, if you see an issue, file it and give it a level: critical, medium or low, to indicate how urgent it is.
  5. Review code (beyond your own features): Open source is powerful because it lets you work with brilliant developers who are being paid by someone other than your own employer. That comes into play in a big way with code review. If you’ve taken time to build out your community, you’ll have more pairs of well-trained eyes catching bugs than you could ever hope for with an internal project. But you also need to do the same for other people, otherwise the system falls apart. When you can, bring your expertise to review code, related to other features or even on other projects.
  6. Babysit your patch: Whenever you contribute a patch to open source, be sure to watch over it. Someone will likely have an idea about how it could be improved, applied more broadly or just written slightly better. Every little suggestion adds up, so address the comments you receive. You don’t have to go crazy and drop everything to respond, but practice putting time aside to respectfully engage with anyone who has taken the time to respond to your work, and then address and integrate what is relevant.
  7. Address technical debts: This is unglamorous and tedious work, but it needs to be done – and we all need to take our turn doing it. Improving documentation improves workflow. It reduces the number of cycles that people have to go through to make changes. It increases product quality and, in doing so, brings value to the whole community. It also increases the credibility of the team you are working on and builds your own reputation within the project.
  8. Perform maintainer magic: Lastly, when you are a maintainer, the “we before me” concept has a slightly different spin. It’s more like: “we but also me.” Maintaining is a big job that can be incredibly demanding and stress-inducing. But as a leader, you also set the tone for the community. You really need to watch yourself to avoid getting over-stressed and bringing that stress into the project. If you have a choice between working even longer without a break or telling people that you will respond to them in a few hours or at a later date, opt to walk away from your computer. Come back when you have relaxed and are more capable of responding in an even-handed, polite and community-enhancing way. In the longer term, look at what you can automate and what you can delegate. This empowers people to do the work themselves without you micromanaging them.

Of course, open source projects also depend on the dedication and specific contributions that each of us bring as individuals. Hopefully, these eight tips make clear that open source projects can only really begin to have an exceptional impact when each of us puts our collective interests first. For more on how to be a great open source contributor, stay tuned to our blog and follow us on Twitter (@vmwopensource).