# 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.
