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 fails to communicate properly.
This article is meant for cats interested in getting involved in open source, but because 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.
opensource.com
If you have coded a solution for your problem, 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.
You've just become an open source developer, which is impressive for a cat.]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 against 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 or GitHub renders quick results.
Using open source often provides paths to contribute to open source. Follow the projects you use, and you're bound to find something they need. Whether it's promotion, or artwork, wiki or website maintenance, documentation, or code, there's always something to be done.
You probably use a lot of open source software, and you certainly can find plenty of software out there on the Internet. So which should you contribute to? How do you decide?
Study 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 as you're just one cat, and you spend most of your day sleeping, you can't join each and every one as a contributing member.
Get to know the community around an open source project by frequenting its 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 behavior aligns with your own.
Start with small gifts
There's an inherent familiarity and trust that comes along with being among 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 that you have its best interests in mind and 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 its 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 favor of more pressing matters.
A small contribution doesn't show 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 five that wander into an IRC channel or an issues tracker saying 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 start to see you as a reliable contributor and 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.
Deal 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 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 some 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, 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.
This article was updated in March 2020.
6 Comments