Elastic Contributor Program: How to contribute code

We created the Elastic Contributor Program to encourage knowledge sharing in our community and to recognize and reward the hard work of our awesome contributors. There are six different contribution types accepted in the program: event organization, presentation, written content, video, translation, and code.

In this blog post, we’ll cover how to contribute code in the many free and open projects that Elastic maintains.

Getting started

First, let’s clarify what qualifies as code content for the Elastic Contributor Program. In order to receive points, the code must be submitted to one of the projects that are available in Elastic’s organization on GitHub and be approved by one the project maintainers. This means that the provided code ultimately aims to improve technologies provided by Elastic. While we appreciate any type of code contribution, only the ones whose purpose is to improve Elastic technologies will be accepted. Make sure to check out the Elastic Contributor Program rules page for the full rules.

But what if you build code that doesn’t improve an Elastic technology, but instead is used to demo a certain feature or concept? While you won’t be able to submit your work as a code contribution to the Elastic Contributor Program, you could submit as a blog post, video, or as a presentation that demonstrates your code and teaches people how to use it.

Which project should I contribute to?

A quick peek at the repositories listed on Elastic’s organization on GitHub will show that there are many projects available. While this is exciting in theory it also poses an important question that you should ask: which project you should contribute to?

Likely, you will contribute to the project that is behind the stack that you use in your work. Most code contributions start from users that are already working with a specific technology and they feel so comfortable enough with them to the point where they also feel comfortable in improving them. Most contributions are actually based on scenarios that users have worked with so frequently that they have discovered better ways to solve the problem and want to make sure their solution belongs to the project.

When you start thinking about how to contribute to the project, you may realize that choosing to contribute based solely on the fact that you use it might not be enough. You’ll also need to evaluate whether you have mastered all the tools needed to contribute.

By tools we mean the technologies that are needed to write, compile, test, and build the code on the project. As an example, let’s suppose that you are a Java developer that is comfortable with the tooling in Java to build applications. In this case, contributing code to the Beats project may be a little hard because the project is based on Go and the tooling will be different. For this reason we recommend that you pick projects written in a programming language that you’re comfortable with.

In GitHub you can filter projects based on programming language. Go to Elastic's GitHub organization and filter the public repositories for your programming language of choice. For example, if you are interested in Java then you can search for all projects that are public and based on Java like this:

Alternatively, you can execute the same search in the browser by using this query.

Making an impactful contribution

Whether fixing bugs or building new features, developers love when their efforts positively change the project — which is why they want to know how to make their contributions impactful. Working on the core of a given project may be tempting, but there are other ways to make an impact as well. Working on code that is consumed by end users is a good example.

Any part of the code that is exposed to users, such as APIs, SDKs, and plugins will generate more issues because there is no way to anticipate all the possible scenarios that developers may come up with. For this reason, focusing on code that developers interact with during their implementations makes the contribution particularly more useful for the project, as well as for the maintainers.

Building reusable extensions is another way to make an impact. If you identify a particular problem that many developers struggle with and build a reusable solution for it, that will certainly stand out. Elasticsearch and Logstash are good examples of projects where you can explore things like this because they both use plugins.

Lastly, give some love to security issues. At Elastic we take security very seriously and we want to make sure that our software is as secure as possible. If you find a vulnerability in any of our software don’t think twice — share your findings and help us to build a fix for it. You can find more information on how to submit security issues here.

Ready, set, code!

Let’s discuss a pragmatic view of the process. First, make sure to carefully read the licensing details of the selected project. This may seem unnecessary since most of us just want to contribute and we feel comfortable with whatever license the project is using. But this is important because your code may introduce dependencies into the project and these dependencies may not follow the same licensing rules.

This will force you to revisit not only your code, but also the way you solve a particular problem. Contributions can be rejected because the dependencies are not inline with the project’s license.

In order to contribute code, developers usually fork a repository, create a branch that will contain the code for the contribution, and then file a PR (Pull Request) in the project. We recommend that you resist the temptation of building a PR right off the bat. Instead, create an issue in the project to discuss the need of the PR.

This is important because some PRs may not be well received. Sometimes the PR may fix a feature that will be soon deprecated and the maintainers don’t want to encourage the usage of that feature. Maybe the new feature that you are coming up with is on the roadmap already. Or maybe the PR can’t be accepted because the code that you are trying to change is blocked by some other features that need to be addressed first, or it may impact other modules that require you to provide code. The point here is that before you spend energy in building a PR, you first discuss the need for it with the project maintainers. This will save you from the possible disappointment of getting your PR rejected.

If, after discussing the issue, your PR is welcomed by the project maintainers then go ahead and do your best while writing the code content. This means writing clear, simple, and maintainable code, using the right data structures and algorithms to ensure execution efficiency. Whenever necessary, provide enough comments, mind any security vulnerabilities that either your code or the dependencies may introduce, and lastly provide some testing code given the guidelines of the project.

Keep in mind that every project usually has a set of guidelines that you’ll need to abide by when contributing code. For example, the Elasticsearch project guidelines for contributing can be found in a file called CONTRIBUTING that is available in the project’s repository. Likewise, guidelines for testing are also available in the TESTING file.

Once your code is ready create a PR in the project, and ask the maintainers to review it. If you need help handling PRs, our blog How We Handle Pull Requests at Elastic provides a good overview. If someone approves your PR you can submit the code contribution to the Elastic Contributor Program, where you will share the link of the PR. After submitting we also encourage you to post about it on social media. This is a lot of work and your efforts deserve to be appreciated.

We hope that this blog post has helped you to start your journey for contributing code to the community. If you have any questions about how to contribute, please feel free to reach out to us at contributors@elastic.co.