Getting started on contributing to open source and making software

Question

I’m just graduated high school. I learnt java in high school, but the java I learnt was taught on bluej and we weren’t taught to create any software or anything. I want to start contributing to open source software, but when I look at the source files, it’s so overwhelming. It feels like the java I learnt in school did not make any difference at all.

Where should I get started?

Answer 1

I would suggest not rushing into trying to contribute unless you have a very willing mentor: I suspect it's relatively unusual for people to contribute to packages/programs that they themselves don't use (indeed, I would be worried if this wasn't the case). That is, if you are not actually consuming any open-source Java packages/programs, then you probably are not well placed to contribute to them because you don't understand their purpose, design, and usage, so you'll have little hope understanding the context of the code you might see.

(Anecdote: I got into open-source by accident when a library I was using was missing a feature I wanted. It was a totally natural thing for me to report the missing feature, and then proceed to implement it: despite having never looked at the code-base before, I already knew my way around the APIs, I knew how I would actually use the feature (so it was already designed in my head), and I knew which other feature I would copy-and-paste to get myself going.)

As such, I would strongly suggest - if you are not already - working on some personal projects where you can use some open-source packages: you will naturally become familiar with their design, and either you'll find problems you want to fix (which is ideal), or you'll be able to understand the context of other people's issues which is often necessary to produce a useful contribution.

You should also use your own projects to teach yourself how to use the tools you'll need to make open-source contributions: version control (e.g. git), IDEs (e.g. IntelliJ), built-tools (e.g. Maven), testing (e.g. JUnit), etc. (it's unlikely that a high-school education has equipped you to use all of these tools well, though I could be wrong)

Finally, contributing to open-source is a great and noble goal, but I'd further suggest not rushing into it because your contributions may just create work for the maintainers if you're not up-to-scratch, and that can be a miserable experience for everyone. My experience has always been that maintainers and other contributors will want to help you make your contribution, but this doesn't mean they actually have time to help you. As said in the comments on your question, issues marked 'good-first-issue' or 'easy' or whatever probably signal good issues for someone contributing to the project for the first time, but that doesn't necessarily mean they are suitable for someone contributing to any project for the first time.

Some obligatory notes on how to put a contribution together, because there is a lot more than just writing code:

• Read all the documentation on how to contribute: you may need to agree to a license, or perform other 'house-work' the first time around
• Look at other contributions to see what they look like: read 'resolved' comments in code-reviews to see what the maintainers are saying so that you don't make the same mistakes
• Take time to configure your development environment: you must run style-checkers and automated tests yourself if possible, otherwise you waste CI and maintainer effort (which may translate into your contribution being rejected/ignored)

In sum: if you are looking at the source files without the necessary context, you're liable to get stuck: this is true for everyone, even when they have years of experience with the language, because there is so much more to building software software than just the choice of language. Instead, build your confidence and competence by making your own software, steadily introduce the tools you'll need to contribute to open-source projects, and find open-source packages that can help you with your own projects: you will inevitably find issues with them, and because you ran into this issues as a consumer, you will be in a much better position to report and deal with them.

Once you've got your hand in, then it'll be much easier to pick up other people's issues on the same (or similar) projects, because you'll understand the context, have some familiarity with the codebase and tooling, and you'll hopefully understand the (non-trivial) workflow of making a contribution. Also, there is a good chance that if you find a problem, that other people will run into it as well (or indeed it may already have been reported): there is nothing selfish about only fixing issues that affect you.

Answer 2

VisualMelon's answer is a good one; I wanted to extend the suggestion to start on solo projects.

Every team sport consists of members who need to both be individually skilled and fit, and work well together as a team. All of these things are hard to learn, and therefore more often than not it is better to learn these one at a time. Therefore, a team is composed out of players who are already individually skilled and fit, so that they can then learn to work together without also having to learn the basics at the same time.

The corollary here is that you should first hone your own development skill, before you start trying to take on team-based efforts. There are many conventions and (sometimes unspoken) rules about how to develop, which have no technical bearing (i.e. doing it in other ways works as well) but we've communally decided to all follow the same style just so your code and your colleague's code merges to form a codebase with a cohesive style and structure.

Based on where you are right now, I suggest focusing on personal projects, and firstly focusing on getting things to work, even if the code is not pretty. Prettier code is obviously better, but if you're struggling to get things to work, having to also jump through the "pretty code" hoop at the same time isn't going to make your life easier.

I would suggest a sequence of steps along the lines of this, only moving to the next step once you feel confident about your skills in the previous point.

• Making it work - Create personal projects, keep it simple, write most things yourself.
  • I suggest tackling at least a few projects. They don't have to be big, but it's good to start several projects from scratch, because you will see that your initial approach improves with experience, and you will avoid mistakes in later projects from the get go.
• Making it better - Learn to improve and refactor your code. Could you have done things better? Is there a reusable method you could've added to avoid needless repetition? Were you using OOP correctly?
  • Revisit the projects from the first bullet point, preferably chronologically. You'll probably be able to immediately improve things based on what you've learned during the other projects you did.
  • Ask someone to review your code when in doubt.
• Making it conventional - Try to apply generally agreed upon clean coding guidelines to your code. For OOP, a good start is SOLID and DRY.
  • Definitely consider code reviews here. Conventions often don't make sense when you're by yourself (everyone has their own style), but will start making a lot more sense when you hear others' points of view.
• Working with existing code - Find some open-source libraries and create some personal projects that make use of these libraries. The goal here is to learn how to write code that works with a pre-established library/codebase. This is a subtly different skill from when you wrote everything yourself.
  • Do not change the other person's code. The goal is to learn to work with the existing code, not rewrite it.
  • If you struggle with any of the first three bullets point here, revisit them for these personal projects that implement other people's libraries. Using other people's code, which you cannot change, can bring to light mistakes you made in your personal projects (where you were able to rewrite parts to fit with your mistake).
  • You can also find closed-source libraries to work with. This adds to the challenge by removing your ability to read the library code, meaning you can only learn from documentation and the interface the library has chosen to expose.
• Extending existing code - Once you feel ready to write "conventional" code (i.e. following the commonly agreed upon guidelines), find an open-source library, preferably one you've already worked with or closely understand the purpose of. Fork it, and try to develop a new feature.
  • If you're struggling to get started on adding new features, focus on bug reports instead. This will help familiarize you with the codebase, and it's usually easier to spot a mistake in existing code than it is to develop something from scratch.
  • You may want to do some ghost development, where you develop the fork but never intend to check it in. That being said, if you're confident about your work, definitely feel free to get someone to review it or, if you're really confident, offer it up via a pull request.