When I tell people that I’m a community manager, the most common comment I receive is something along the lines of “Wow, it must be hard dealing with all the rude, mean people online.” However, what most people don’t understand is that the number of people who are just awful for no reason is relatively small and they’re normally pretty easy to deal with. When they violate the rules, you give them a warning. Then they go even further immediately after or in response to the warning and you ban them.
The more challenging situations are people that are not familiar with or used to participating in open source projects. Their expectations can be unrealistic because the open source model is not what they’re used to. It can be frustrating for both sides of an exchange because it is hard to meet in the middle when there is a disagreement about where the middle is. In this article, I’m going to talk about the negative patterns that I’ve seen people fall into when first participating in open source and some more productive approaches that should help everyone involved.
How does open source differ from traditional production?
The first thing to understand is that open source is a fundamentally different means of production than traditional software development. Traditional software development has customers who pay money for the software because it solves a problem for them. Open source software has creators, contributors, and collaborators who help build the software or help get the software built well because they need a problem solved. The fundamental difference between the two is the fuel that powers the engine. Traditional methods use money. Open source uses the creative drive and cooperation.
You might be saying to yourself that open source software has customers too. It is true that open source software has people who use it. However, there aren’t “customers” in the traditional sense because open source software doesn’t cost money to use. Additionally, even if very few people use it, open source software still gets built and maintained. Just look at most of my personal projects . When traditional software has no customers paying for it, it is quickly abandoned.
How does removing customers from the equation change things?
Removing customers from the system takes away money as a motivator. Most people who aren’t familiar with open source development assume that the people building open source software are doing it out of some altruistic drive. While this is true for some, most people contributing to open source efforts are doing it because they need a tool or want a problem solved. They’re contributing out of enlightened self-interest. Everyone is contributing to the project to make it better for themselves and if that effort helps someone else, that’s great too! Because open source pools all of that effort, everyone wins.
On the other hand, this means that if you’re not contributing in some way to making the project better, then you aren’t supplying it with what it needs to move forward. As a matter of fact, if all you’re doing is asking for one thing or another and not contributing back, you’re being a drain on the limited resources of the group. People may still decide that your suggestions or requests are a good idea and implement them, but they have no obligation to do so simply because you asked.
In essence, if you want to be able to influence the direction of an open source project, you have to contribute back. Because money isn’t the motivator, open source is completely driven by contributors’ own willingness to solve problems and give back to the project. The way to give back is by finding out what needs to be done and doing it. It doesn’t have to be big. It doesn’t have to be code. Most projects are more in need of design or documentation help than code. On the projects I help administrate, some of the most valuable maintainers are the ones that help triage issues. Everyone has some skill that can benefit an open source project; all it takes is time and willingness to help.
Some common misconceptions and how to improve your contributions
Filing a bug is always a meaningful contribution
Yes, filing issues can be a great way to help a project. Good bug reports can be very useful but they take a lot of time and effort to write. If you’re filing a bug that contains no information that could be used to help track that bug down, then it is probably not going to help fix the bug. Since reading and responding to it takes time away from other efforts, you may be costing the project more forward momentum than you’re giving it in return if you’re not filing a detailed, well-thought-out and -researched issue.
- Always search the open and closed issues to ensure you’re not creating a duplicate issue
- Learn how to report bugs that help developers fix those bugs (I wrote a guide on how to write good ones that should be helpful)
- Always supply all the information that the developer asks for (especially if they’re using the issue template feature)
A maintainer is obligated to fix a bug I report or implement a feature I request
Actually, they aren’t. As I mentioned before, the way open source works is that everyone contributes based on their own needs. If your needs don’t align with anyone else’s, then it may be completely up to you to figure out how to fix or implement something. Even if you need the same thing as other people involved in the project, that doesn’t mean that what you want will be others’ top priority.
- Ask how you can help get a bug fixed or feature implemented
- Be willing to submit a pull request for something that is important to you
- If the project offers an extension mechanism, see if you can write an extension first before asking for it in the main project
All of my contributions must be accepted
This is a tougher situation and one that took me a while to figure out when I was first contributing to open source. You may have a great idea for something and have figured out an amazing way to build it. You spent a lot of time coding it up, writing tests for the code, even documenting it all according to the contributing guidelines! However, it still may not be accepted. Why? Because maybe your great idea doesn’t fit in with the other contributors’ ideas for the project. Maybe the way you wrote the code is more complex than the project owners feel comfortable maintaining. Maybe it is so brilliant they just don’t get it! Whatever the reason, a project is under no obligation to accept a contribution no matter how well-crafted it is or how much work went into producing it.
Offering a contribution is sometimes like giving someone a puppy as a gift. It may be exactly what they wanted, but they still have to take care of it forever. Don’t be offended if they’re not ready to take care of the puppy you chose for them.
- Read the closed issues and closed or merged pull requests in a project to get an idea for the intended scope of the project
- Be willing to maintain your own fork of a project if your change is out of scope
- Consider asking for an API in the main project that will allow you to customize the behavior as an extension
Open source is becoming a much bigger part of how software development is done. Understanding how to participate in it is becoming crucial to many companies’ livelihoods. Open source is driven by creators, contributors, and collaborators; people who want to work with others to make something awesome. Learning how to be a better collaborator or contributor is key to getting what you want and need out of the open source projects you become involved in.