Subscribe to the mailing lists of one of these projects and try to build the project from source. Check the bug trackers for things that are not very interesting but need fixing anyway. Then prepare a patch and try to upstream it (the method depends on the project).

As you work on the little things you will slowly gain a better understanding of how the code base is organised and how you could contribute more significant changes.

Valuable contributions outside of writing code differ across projects, but most lack current or understandable documentation. As you learn about the project and read whatever documentation might already be there you will certainly find things that can be clarified.

I've contributed to open source software, and done a little maintenance work too. The number one thing I recommend is that you email the project mailing list before you start work. Tell them that you're new, but you want to help. People are usually happy to help newcomers find an appropriate project and answer questions along the way.

What I've seen going wrong in the past is where people decide that they want to contribute to a project and don't tell anyone else about it until they've written hundreds or thousands of lines of code that are never going to be accepted, because the maintainers don't like their overall design (or the maintainers don't agree with the direction of the patch, or something else that could have been caught early but is way too late now).

Communicate early, communicate often. And if a community doesn't like that, leave and find a different one. Your time is more valuable than that.

P.S. and be sure you're contributing to a project that you are passionate about, not just one that sounds cool. Having your own intrinsic motivation will make a huge difference.

You should consider working on some of the PyCA projects, including any of cryptography, PyNaCl, PyOpenSSL. They are smart people with solid engineering practices and a lot of experience.

The reason you should consider it is twofold:

- Code is only good if it's used, and ideally, usable. - This gives you a great opportunity to learn a lot about OpenSSL in an environment that has more (resources for) mentorship and unit tests.

https://www.github.com/pyca

Disclaimer: While I was around when it was founded and am still officially its resident cryptographer, I don't really do much of the work. I just occasionally show up and say "Frobenius" a lot.

Mozilla has documentation on this, see https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...

For the other projects you listed I’m not aware of such documentation, but I’d recommend you just go ahead and ask them directly :).

Very nice, lots of documentation and for different skills.

You could help open source projects get their code into Coverity, a static analysis tool. It helps if they have a github repo, and it's even better if they use Travis-CI. Using Coverity will help identify some security issues that can be mitigated right away.

Secondly, you can fuzz FLOSS software, using something like afl-fuzz, American Fuzzy Lop. The following tutorial has some pointers to get started, and obviously software written in C is easier to get started with. If you need help with something, feel free to ask on the afl-users mailing list. You can fuzz on a CPU-heavy VM somewhere, like DigitalOcean, an Amazon spot instance, or a Google preemptible instance.

https://fuzzing-project.org/tutorials.html

In fuzzing, once you get the hang of it, you'll find that your keyboard time is the limiting factor. You'll set up a test case in 15-20 minutes, leave it fuzzing for a day, and come back to spend at least 1-2 hours working through crashes and reporting the bugs through their channels.

You may be saying "Wait I don't know anything about C," but honestly, I don't know anything about C either, and I've found hundreds of bugs with fuzzing. There are some crash dump investigation tools that give you an idea of the nature of the crash (gdb's exploitable.py) and that's usually enough to report to the maintainer. When the maintainer has a fix released, you can send an email to the oss-security mailing list detailing what you know about it. MITRE can assign a CVE on the mailing list if you describe the bug appropriately when you ask for one.

I'd like to recommend Raymond Hettinger's talk from last month, Where he talks about how to contribute to the Python project. I think it's a great talk even if you're not coming from the Python world and can serve as general tips for contributing to a large open source project.

https://youtu.be/-TdrFjDJn5E

$bigScaryOpenSourceProjects are very picky about how contributions are made and are unfriendly to newbies. Most of your time will be spent arguing over one or two lines of code. If you haven't contributed to open source before, your best bet is to start on smaller open source projects who have forgiving maintainers.

"picky about contributions" doesn't mean unfriendly to newbies. For instance, with Firefox, you need to be able to build the project, open bugs, use diff/patch, and that's about it. You open a bug or pick up someone's open bug for an issue you care about. You attach a patch to the bug, possibly discussing it in IRC or on a mailing list. When you think the patch is ready, you ask for a review. The review is a picky but not unfriendly process. That will help you get your patch up to the project's standards. Then you get a super-review. And your patch gets in once that passes.

Newbies can and do meet the standards for contributing, and it's not painful IME.

For instance, Rust. They're the friendliest community around.

Seconded. Try reading the last couple of issues of This Week in Rust, and then look at the most recent "Call for Participation" section.

Some projects do better than others. LibreOffice bends over backwards to welcome new contributors and point them at something useful they can get done easily - everything marked "Easy Hacks". And of course, "I am a LibreOffice contributor" (or other $bigScaryOpenSourceProject) is always a nice thing for one's resume and reputation.

Over the years I've communicated many security bug reports privately to project maintainers and security teams of projects such as OpenSSL, Tor, Python, MITRE. Very pleasant experiences, very kind and thankful and helpful people, so I can't really corroborate this.

Given that you found security bugs in all those project, I'd say you are not a newbie in the sense that parent meant.

How would you compare it to code review at a medium to large tech company? At work there's certainly a lot of back and forth but it never feels hostile, and I usually learn something.

I'd say there's more review on m.o projects than at any medium-large company I've worked at. It's not hostile at all, and I've learned something the times I've cared enough to shepherd a patch through that process.

I don't think it's unfriendly to newbies at all, other than the size of the codebase being so large that it takes considerable time/effort to understand well enough to make a patch you're willing to work through getting integrated.

My $0.02:

* Pick a project you use and like. This way you will already be familiar with some aspects of the projects and you will have an idea for what works and what doesn't. You will be able to use your improvements for yourself.

* It's easier to contribute to a small project than a larger one. Larger projects are usually more complex and require understanding more code. If a smaller project has less people involved with it, it will be easier for you to get to know everyone and for everyone to get to know you.

* It's also easier to contribute to newer projects. Older projects usually have strict guidelines that can take a while to get used to. They often have internal politics that come into play. Finally newer projects have a lot of "low hanging fruits", simple things that anybody can fix.

You can start with commits that fix docs or clarify the code with additional comments. Contribute some unit tests, etc. As you familiarize yourself with the code and the process, you will be able to fix larger bugs and even implement new features.

It would probably take two years of coding in C to do real work for those projects. If you want to make an impact, fill in the gaps in their man-power to do the things that are not writing software features.

Go to their bug trackers and start working on the smallest bugs. Or write extensions for the most popular new languages to use their libraries or apps, so new programmers can take advantage of the existing crypto. Or write or update documentation. Or write user-friendly guides on what people need to use and how. Or fill the holes in their test routines to find new bugs faster, and build new test platforms for wider platform coverage. Or track down performance bugs.

The number one thing you can do is regularly use and exercise the piece of software of interest. Want to contribute to OpenSSL? Use it! Use it in a way beyond that of a "how-to" tutorial on a first Google hit.

Second, I would say start reading the manual, or at least skimming it. Get a better understanding of what the software actually intends to do, not what you think it intends to do. Remember that documentation is a part of software, so improvements are always welcome here!

Then, after, you can learn how to build the software. Make an easy modification (like changing a title, or changing something that gets printed out), and recompile and observe the change. From here you can look at a high level what gets built in what order, and what's important in the project.

Finally, you can start thinking about bugs that have been recorded in a bug tracker, or attempting to implement a neat improvement or feature. Look/ask for guidance, so you don't spend time doing something that ultimately no one will want or care about (which isn't to say it wasn't appreciated, but many projects have specific guidelines/goals/etc. and it's important your changes fit with those).

Linux — http://eudyptula-challenge.org/ is a good place to start.

OpenSSL and GPG — subscribe to relevant mailing lists, find something wrong with them and discuss with upstream / fix it. This could be missing tests/docs or a bug.

Adding new functionality is harder to do as an outsider, but these other areas are somewhat easier to contribute to (in general).

I have contributed to Firefox and Servo and found both communities to be incredibly patient, tolerant and friendly.

You can find bugs in bugzilla (firefox) or github (servo) that are labelled as suitable for newbies, my advice is to try and build it first then pick one up and go for it!

I managed an open source project (OSSEC) for many years and this was a common question I would hear.

I gave some hints here: http://dcid.me/notes/2013-may-12

That I hope can be useful for you.

thanks,

For the Linux kernel specifically, I think the "aspiring new developer" entry point is https://kernelnewbies.org/ .

Are there valuable contributions I can make outside writing code?

Traditionally, documentation has always been rather lacking for the bulk of projects.

Thank you everyone for your comments and ideas!

For OpenSSL, we wrote this: https://www.openssl.org/community/getting-started.html Please send feedback :)

"Write and submit your first Kernel patch" by Greg Kroah-Hartman:

https://www.youtube.com/watch?v=LLBrBBImJt4

Don't worry about working with an important project.

Look for something you care about, and are willing to put the work into improving. Software you use is a good start.

Less popular software is more likely to be happy for help.

Start small (fixing typos for eg), read code and fix issues you notice in the process.

Also, check out Kernelnewbies:

http://kernelnewbies.org/