Open source software is tricky business. One might think a volunteer project that gives you free software is the greatest thing ever, however making such a project work is complex. Creating open source software is quite simple for a small project with only a few hobbyist maintainers, where making decisions comes down to only one person or a very small group, and if users don’t like it they can fork the project and continue on their way without many hurdles. Things are not so simple for large projects with multiple stakeholders, where priorities are frequently conflicting but the health of the project still relies on all contributors behaving as, well, a community. This is what I’ll be writing about, and more specifically the do’s and don’ts when contributing to large open source projects.

But first, let’s talk about the kind of community that makes up an (large) open source project.

Four main types of contributors for an open source project

1. The full timer who usually works for a company which utilizes/backs the project. This person is employed by the company to work on the project, usually directed by the company to work on specific bugs and features that are affecting them, and also on larger feature sets. They often work in a team within their company who are also working on the project. In some cases, these full-timers are not dedicated to writing code but more dedicated to the managerial side of the project. Part-timers similar to these also exist.
2. The part-timer who has a vested interest in the project. Mostly these are consultants, but could still be from companies who use the software but don’t have enough resources to contribute full-time. Generally, they contribute to the project because it heavily influences their day jobs, and they see users with a certain need. Usually have a very good understanding of the project and will also contribute major features/fixes as well as smaller improvements. They may also just be very well versed users who contribute to discussions, helping other users, and documenting the software.
3. The part-timer who has some interaction with the software during their day job, but is not dedicated to working on the software. These people often contribute patches related to specific issues they encounter while working with the software. Typically these people are sysadmins or developers. I’d sum these up as “the people that encounter something that annoys them and fix it”.
4. The users. No point having all this software if there is no one to use it. Users contribute on mailing lists and ancient IRC’s, helping other users get on board with the software. They also give important feedback to the developers on improvements, bug fixes, and documentation, as well as testing and reporting bugs they find. Typically in a large project, they don’t drive features significantly, but it can happen.
   

There are many other types of contributors to a project, but these (to me) seem to be the main ones for large projects such as Apache Cassandra. You’ll note there is no mention of the hobbyist. While they do exist, in such large projects they only usually come about through extraneous circumstances. It’s quite hard to work on such a large project on the side, as it generally requires a lot of background knowledge, which you can only really grasp if you’ve spent countless hours working with the software already. It is possible to pick up a very small task and complete it without much knowledge about the project as a whole, but these are rare, which results in less hobbyists working on the project.

It’s worth noting that all of these contributors are essentially volunteers. They may be employed full time to work on the project, but not by the project. The company employing them volunteers their employees to work on the project.

Now there are a few important things to consider about a large project with a contributor-base like the above. For starters, priorities. Every contributor will come to the project with their own set of priorities. These may come from the company they work for, or may be itches they want to scratch, but generally, they will be directed to work on certain bugs/features and these bugs/features will not always coincide with other contributors priorities. This is where managing of the project gets complicated. The project has a bunch of volunteers, and these need to be organized in a way that will produce stable, functioning software that meets the needs of the user base, at least in a somewhat timely fashion. The project needs to be kept healthy and needs to continue satisfying the users needs if it is to survive. However, the user’s needs and the needs of the people writing the code often don’t intersect, and they don’t always see eye to eye. On a project run by volunteers this is important to consider when you’re asking for something, because although you may have a valid argument, there might not be someone who wants to make the contribution, and even if there is, they might not have a chance to work on it for a long time/ever.

Do’s

1. Take responsibility for your contributions. I’ve noted it’s a common opinion that developers are only beholden to their employer, but this is not true. If you wrote code in an open source project, you’re still responsible for the quality and performance of that code. Your code affects other people, and when it gets into an open source project you have no idea what that code could be used for. Just because you’re not liable doesn’t mean you shouldn’t do a good job.
2. Be polite and respectful in all discussions. This is very important if you want to get someone to help you in the project. Being rude or arrogant will immediately get people off-side and you’ll have a very hard time making meaningful contributions.
3. Be patient. Remember OSS is generally volunteer-based, and those volunteers typically have priorities of their own, and may not be able to be prompt on your issues. They’ll get to it eventually, nudge them every now and again, just don’t do it all the time. I recommend picking up a number of things to do that you can occupy yourself with while you wait.
4. Contribute in any way you can. Every contribution is important. Helping people on the mailing list/public forums, writing documentation, testing, reporting bugs, verifying behavior, writing code, contributing to discussions are all great ways to contribute. You don’t have to do all of them, and a little bit of help goes a long way. This will help keep Open Source Software alive, and we all want free software don’t we?

Don’ts

1. Don’t assume that just because you have an idea that other people will think it’s good. Following that, don’t assume that even if it is good, someone else will be willing to implement it.
2. Don’t assume that OSS is competing with any other software. If something better comes along (subject to licensing), it would make sense for the effort to be directed towards the new software. The only thing keeping the project alive is that people are using it. If it stops being relevant, it will stop being supported.
3. Don’t expect other volunteers to work for you. If you have a great idea you must still be prepared to wait and get involved yourself to get it implemented. The nature of large OSS projects is that there is always more ideas than there is people to implement them, and the contributors are more likely to prioritize their own ideas over yours. If you can do some of the legwork to getting your ideas in place (proof of concepts, design documents, validation, etc) it will go a long way to making your idea a reality.
4. Don’t expect to show up and be listened to. It takes years of working with a large project before you have enough knowledge (and wisdom) to make significant improvements. If you just show up and throw your ideas about like they are better than sliced bread you’ll likely put existing contributors on edge. Start small and incrementally build yourself a reputation of which people will give your ideas the consideration it deserves.
5. Don’t waste people’s time. It may seem harsh but things like not having enough details to diagnose problems or when reporting bugs are huge time wasters and generally lead to your problems getting lost in the backlog. Make sure you always search the backlog for existing related issues and make sure you are prepared to provide all relevant information for the maximum chance of your request being implemented.
   

Hopefully, this gives a good overview of the kind of community that makes up an open source project and gives you a good idea of what you’re dealing with when you’re looking to contribute to <insert favorite OSS software here>. If you follow these simple do’s and don’ts you’ll have the best chances of success when making contributions. Don’t hold off, contribute today!