# How to get involved with open source if you're a cat We humans are social creatures, and we're really smart and advanced, so there's no need for us to read an article about how to get involved in open source. Cats, on the other hand, are socially awkward, sometimes aloof, sometimes overly sensitive, and a little jumpy. When a cat tries to get involved with open source, it often comes on too strong, or gets spooked by an unpleasant experience, or they fail to communicate properly.  This article is meant for cats interested in getting invollved in open source, but since cats can't read, you should read it aloud to yours, especially if your cat ever shows an interest in computers. ## Scratching posts and bug reports If you want something done in real life, the usual petitioning process is something like this: find a person, yowl at them, scratch the sofa, knock things off the shelf, and generally be a nuisance until they stop what they're doing to satisfy your demands. In software development, these are also valid tactics when trying to get, say, a closed source application to change something that doesn't work for you. You post on social media, you complain on the publisher's forum, you threaten to stop buying their product unless they do what you want. You don't even have to follow through, because the publisher probably makes its real money on corporate accounts, anyway, and won't respond to you. In open source software, however, the process is completely different. First, you file a bug on whatever bug tracker a project uses. Some use their own install of a formal bug tracker, like Bugzilla or Mantis. Others use issue trackers in Gitlab or Github.  If you have coded a solution for your problem, then attach the patch. That's it, you're done! You've just become an open source developer, which is impressive for a cat. If you don't have code fixes, track your bug's progress. Just because you filed a bug report doesn't mean that the project's developers automatically agree with your assessment of a problem, or that they'll suddenly find the time to fix it, so be patient and be ready to communicate. Most importantly, be honest. If a developer says they've changed the application based on your feedback and asks you to test the change, but you don't know how to install an update, then say so. This isn't a competition, it's a discussion forum. The developer probably won't have time to step you through the process, but at least they'll know not to rely on you for immediate feedback on the fix. The important thing to know is that filing a bug and providing feedback is an important and significant form of contribution, because, frankly, it's hard work. Navigating bug trackers, signing up for accounts, keeping track of outstanding issues, being patient agains differing point of views; it's no small task, but it's feedback and data for developers, and it's greatly appreciated. If you do this, you're a legitimate, full-fledged open source QA (Quality Assurance) contributor.  Maybe you're looking for something a little more permanent, a place to call home. If you're looking for a project to really sink your teeth into, it's smart to front-load your effort. ## Survey your territory These days, it's not hard to find a good open source project whether you're looking for one or not. A casual glance at [gitlab.com](http://gitlab.com) or [github.com](http://github.com) renders quick results. Something a little more curated, however, is simetimes nice. [OpenHatch](http://openhatch.org) is a site dedicated to connecting open source contributors like yourself to open source communities, tools, and education. It's not just a list of open source projects in need of help, it's a training resource with actual [training missions](https://openhatch.org/missions/) that you can do to learn the basics of software development. In addition to training, they maintain a list of [volunteer opportunities](https://openhatch.org/search/), searchable by programming language, project size, difficulty level, and more. If you feel overwhelmed by the number of opportunities out there, OpenHatch is for you. Go there, settle in and get the training you need, and then start contributing! But which should you contribute to? How do you decide? ## Studying your target In the same way you study crickets, mice, other cats, and people, you must also study prospective open source projects.  There are lots of great projects out there, each with exciting communities. Most of them are very inviting, and their passion for a project can be contagious. But you're just one cat, and you spend most of your day sleeping, so you can't join each and every one as a contributing member. Get to know the community around an open source project by frequenting their mailing lists, bug reports, and forums. Get to know the key players, look at how they treat each other and their visitors, and decide for yourself whether their behaviour aligns with your own. ## Starting with small gifts There's an inherent familiarity and trust that comes along with being the first few people to design and write code for an application. It's natural that people who have been with a project since its inception are trusted members of the project's community, not only because they've put a lot of time and effort into it, but also because they've simply stuck with the project through thick and thin. You may be eager to integrate yourself into a project, but you have to show the project that you have its best interests in mind and that you're going to stick around for a while. Your first contributions to an open source project will probably be small and mostly casual. A dead or mostly-dead mouse or bird on their doorstep might seem like a good start to you, since you're a cat, but more useful are fixes to documentation, minor patches, or, if you're a trained programmer, picking up that enhancement request from two years ago that keeps getting ignored in favour of more pressing matters. A small contribution doesn't shows just an interest to help, it shows your *ability* to help, and that's what matters the most to any project. For every contributor who makes an actual commit, there are 5 that wanders into an IRC channel or an issues tracker saying that they'd like to help but never do. The trick is: * listen to what is needed * announce that you intend to make a change * make a change * commit your change Do that several times, and eventually a project's participants starts to see you as a reliable contributor and as an active member of their community. There isn't usually an initiation ceremony, so if you're a Schrödinger cat, don't be afraid to definitively declare yourself a part of that project. Get to know the other members of the community, and grow with the project you're helping sustain. ## Dealing with rejection There are two brands of rejection: there's the meatware kind, and the software kind. Meatware rejection is like cat food that's gone off: get away from it or it'll make you sick. Should you have a bad experience with a project based solely on personal grounds, take a step back, review how you approached the project and how you presented your contribution. If you feel you did everything right but were treated poorly, then walk away, fast. No matter how important or influential the project, it's not worth enduring abuse. Rejection based on code, on the other hand, happens so frequently that it's literally *to be expected*. Especially in your initial contributions, there's a high likelihood that what you give the project just isn't exactly what the project wants to get. Maybe your coding style doesn't match existing code. Maybe the tone of your documentation fix is out of place. Maybe you got something wrong. Maybe the maintainers don't want to commit to supporting your additions themselves. There are many factors that can lead to rejection. This kind of rejection doesn't mean you haven't contributed. It just means that your contribution didn't get rolled into the master branch, but it still serves as a contribution. Who knows? maybe your contribution will get rewritten by a maintainer and added in any way, or maybe your contribution forces attention on an area of the project that had been otherwise neglected, or maybe it will get added later, once you've proven that you intend to stick around to support what you're adding to the codebase. In the game of probability, rejection is a good thing. Accept it with the same grace that you would accept a merged branch, and then turn your attention to your next contribution. You should be good at this sort of thing; after all, you're a cat, so you always land on your feet. ## Open source like catnip Once you've started contributing, the next step is to learn more and contribute again. One of the greatest appeals of open source is that there is no ceiling: you can keep learning new tricks, building better things, and you'll never run out of possibilities. It's like catnip that way, you'll love it.