
Ask HN: How can I get involved with Linux/OpenSSL/GnuPG/etc - ancarda
What would it take to be involved in $bigScaryOpenSourceProject? I&#x27;m passionate about cryptography, security, and privacy so projects like Linux, Firefox, OpenSSL, etc... might be perfect for me to get more involved with. Outside learning C or possibly Rust (for Firefox development in future) I have no idea how I&#x27;d start with any of these projects, partly as my day job is all web based so it&#x27;s what I&#x27;ve been focused on for years.<p>Are there valuable contributions I can make outside writing code? For example, SSL can be tricky to setup but tools like SSL Test and the Mozilla Server Side TLS wiki page are invaluable in making us all safer. What&#x27;s something in security that&#x27;s too difficult or time consuming that I could work to automate or make easier?
======
rekado
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.

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

~~~
akeck
[https://en.wikipedia.org/wiki/Nemawashi](https://en.wikipedia.org/wiki/Nemawashi)

------
lvh
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](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.

------
secure
Mozilla has documentation on this, see [https://developer.mozilla.org/en-
US/docs/Mozilla/Developer_g...](https://developer.mozilla.org/en-
US/docs/Mozilla/Developer_guide/Introduction)

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 :).

~~~
mgv11
Very nice, lots of documentation and for different skills.

------
deadfece
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](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.

------
benshu
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](https://youtu.be/-TdrFjDJn5E)

------
jbob2000
$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.

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

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

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

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

------
reikonomusha
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).

------
loeg
Linux — [http://eudyptula-challenge.org/](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).

------
crc32
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!

------
danielcid
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](http://dcid.me/notes/2013-may-12)

That I hope can be useful for you.

thanks,

------
tbrownaw
For the Linux kernel specifically, I think the "aspiring new developer" entry
point is [https://kernelnewbies.org/](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.

------
ancarda
Thank you everyone for your comments and ideas!

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

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

[https://www.youtube.com/watch?v=LLBrBBImJt4](https://www.youtube.com/watch?v=LLBrBBImJt4)

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

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

Also, check out Kernelnewbies:

[http://kernelnewbies.org/](http://kernelnewbies.org/)

