There are millions of PHP developers, but only a (large) handful of contributors, authors and maintainers of open source software. Packagist reports a little under 50,000 packages in the PHP ecosystem. This is a huge number of open source packages, but is a small number compared to the PHP developers in the world.
The truth is, many developers who use open source never contribute to it. Whether that’s out of lack of interest, fear of failure or other considerations, I want to present The Definitive Guide To Contributing to Open Source*.
How do you get started? Where do you get started? And what do you have to do? Let’s dive right in…
Many if not most open source projects are on GitHub. There’s also others (like BitBucket), but for now, let’s focus on GitHub.
If you don’t have a GitHub account, go get one. Now.
Getting started in open source
The biggest challenge for many people is “where do I start?”
Well, that’s actually the simplest answer: start with what you’re using now!
Chances are good you’re using at least one open source project or tool. And I’d bet you’re using several. Have you ever thought, “it’d be nice if X did Y”? Yes? Congratulations. You have a feature to build.
Ever wondered why the documentation wasn’t clearer on a particular subject? Congratulations. You have documentation to write.
Open source contributions don’t need to be huge
You don’t need to write a package or a library or a framework to be an open source contributor. Correcting a spelling mistake is enough. Fixing a documentation mistake is enough. Adding a test is enough. The old adage, “A journey of a thousand miles begins with a single step” applies here: taken together, small actions make a huge impact.
Even reporting an issue with a package can be a useful contribution. Many bugs go unreported. Believe it or not, writing a good bug report is really hard: you have to know what you expected, and describe what actually happened, and be able to communicate that thought to another person in writing. These are skills that can be rather challenging even for skilled developers. If you have this ability, use it! Take the time to report issues so that they can be fixed.
Be ready to hear “no” from time to time
There are times when contributions to open source projects aren’t accepted. There can be many reasons for this, and it’s okay. I’ve had it happen to me. Everybody who contributes has had it happen to them. And it will happen to you.
It’s impossible for us to read the minds of a person or a group that builds a project. A feature or a documentation change may not align with their intent, or might not fit with their views of the project. It may be out of scope. They may reject your suggestion. And that’s okay.
When that happens you have a few choices. You can accept their decision and move on to the next thing. You can fork the project, add your fix, and release it as your own (assuming the license lets you do that). But please, don’t leave open source! A momentary setback isn’t a reason to quit!
Small steps, big impact
The only way you’re ever going to contribute to open source is just by doing it. Start small. You’ll eventually see bigger needs, and work on bigger projects, and you’ll wonder why you took so long to start contributing at all. Happy contributing!
* The title of this post is facetious; there are many more tips for contributing to open source beyond what I have shared. Share your favorites in the comments!
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."