Everything that Elastic builds is free and open and we love to receive contributions from the community. Not sure how to contribute or get started? We’ll share a few tips on how to contribute with code.

We created the <a href="https://www.elastic.co/community/contributor">Elastic Contributor Program</a> 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: <a href="https://www.elastic.co/blog/elastic-contributor-program-how-to-organize-an-elastic-meetup">event organization</a>, <a href="https://www.elastic.co/blog/elastic-contributor-program-tips-for-speaking-at-an-event">presentation</a>, <a href="https://www.elastic.co/blog/elastic-contributor-program-tips-for-creating-written-content">written content</a>, <a href="https://www.elastic.co/blog/elastic-contributor-program-how-to-create-a-video-tutorial">video</a>, translation, and code.
In this blog post, we’ll cover how to contribute code in the many free and open projects that Elastic maintains.
<h2>Getting started</h2>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 <a href="https://github.com/elastic">Elastic’s organization on GitHub</a> 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 <a href="https://www.elastic.co/community/contributor/rules">Elastic Contributor Program rules page</a> 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.
<h2>Which project should I contribute to?</h2>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 <a href="https://github.com/elastic/beats">Beats project</a> 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 <a href="https://github.com/elastic">GitHub organization</a> 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:
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt11b655515aa198cc/5feb456ba7955d1a6a891869/blog-community-contribute-code.png" data-sys-asset-uid="blt11b655515aa198cc" alt="" style="display: block; margin: auto; width:700px;">
Alternatively, you can execute the same search in the browser by using <a href="https://github.com/elastic?q=&type=public&language=java">this query</a>.
<h2>Making an impactful contribution</h2>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. <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/modules-plugins.html">Elasticsearch</a> and <a href="https://github.com/logstash-plugins">Logstash</a> 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 <a href="https://www.elastic.co/community/security">here</a>.
<h2>Ready, set, code!</h2>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 <a href="https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md">CONTRIBUTING</a> that is available in the project’s repository. Likewise, guidelines for testing are also available in the <a href="https://github.com/elastic/elasticsearch/blob/master/TESTING.asciidoc">TESTING</a> 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 <a href="https://www.elastic.co/blog/how-we-handle-pull-requests-at-elastic">How We Handle Pull Requests at Elastic</a> 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 <a href="mailto:contributors@elastic.co">contributors@elastic.co</a>.

elastic-contributor-program-banner.jpg

elastic-contributor-program-thumbnail.jpg

Elastic Contributor Program: How to contribute code

Knowledge sharing is an important part of the open source community, and written content is a great way to share your knowledge. Not sure what to write about or how to get started? We’ll share a few tips on writing about your Elastic experience.

At Elastic, we believe in the <a href="https://en.wikipedia.org/wiki/Democratization_of_knowledge">democratization of knowledge</a>. This is part of our open source roots. The open source model advocates that everyone should have access to code that represents knowledge — which entails research, experimentation, testing, and time. Code is important, but what really makes the difference is the knowledge behind the code, and thanks to open source, this knowledge becomes available for anyone to use, build on, and evolve.
There are tons of ways to share knowledge besides contributing with code, such as <a href="/blog/elastic-contributor-program-how-to-organize-an-elastic-meetup">organizing meetups</a>, <a href="/blog/elastic-contributor-program-tips-for-speaking-at-an-event">speaking at an event</a>, or creating content. We created the <a href="/community/contributor">Elastic Contributor Program</a> to encourage knowledge sharing in our community and to recognize and reward the hard work of our awesome contributors.
In this blog post, we’ll cover a few tips on how to get started sharing your experiences with the community in writing.
 <h2>Getting started</h2>First, let’s clarify what qualifies as written content for the Elastic Contributor Program. In order to receive points the written content must be at least 200 words (or roughly 10 lines) and must be centered on Elastic products or solutions. If you happen to speak more than one language, you can also translate <a href="/blog">elastic.co blog posts</a> for the chance to earn additional points in the Contributor Program! Be sure to check out the <a href="/community/contributor/rules">Elastic Contributor Program rules page</a> for the full rules.
The good news is that the rules are pretty open ended — there’s no limit to what you can create! But you might ask yourself: Why should I spend my time writing? One reason is that written content is a great way to showcase your work and build your career. It’s not uncommon for developers in the community to struggle to get acknowledgement because, ultimately, there’s no easy way to verify their work and experience. Sharing your work by putting your experiences into writing is an effective way to demonstrate your abilities while also helping other developers learn from you.
 <h2>Finding a topic to write about</h2>So you’ve decided to take the leap and write something — but where do you begin? You might think that the first step in writing something is to get creative. But instead of focusing on creativity, try focusing on your personal experiences. Carefully observe what you’re building in your work every day. Take a closer look at the small things you create, change, and improve to get something done. You’ll probably find lots of interesting things to talk about.
Writing based on personal experience is powerful because it allows us to share practical experience, which everybody loves. For example, a blog post that talks about controlling memory usage for aggregations in Elasticsearch is good — but a post that discusses which knobs you had to switch to achieve faster aggregation results is way better.
As you start to think about putting your experiences down in writing, consider telling your story in one of the following ways:
<ul>
	<li>Journey: A journey is one of the most popular story types. Your journey captures the decisions, struggles, and consequences that you went through in order to accomplish something. To tell an effective story, you’ll want to explain the trajectory you took to get to your desired outcome — for example, maybe you had a project where you migrated from single indices to data streams to handle time series data more efficiently using hot, warm, and cold data nodes. Be sure to explain the desired outcome before getting into the details of the journey so your readers can understand the steps you took. Your readers might be trying to accomplish the same thing and they’ll want to know if your journey is applicable to them.</li>
</ul><ul>
	<li>Use case: A use case story is a variation of a journey, but is more structured and usually has four main sections: context, problem, solution, and results. Use case stories are good for sharing the history of a project, and they tend to be more successful when they focus on a specific industry. For instance, two companies adopting Elastic APM will end up with the same benefits, but if they’re in different industries their individual use cases will be unique. Capturing this uniqueness is key for telling a use case story.</li>
</ul><ul>
	<li>Lessons learned: This type of content focuses on the things that you’ve learned while working with a specific technology. It’s impossible for a technology to foresee all possible scenarios where it will be used, so if you’ve discovered something new during your work with the technology then this is a great opportunity to write something up. It’s common to use a cause and effect framework for this type of story. The effect is what readers are looking to understand. For example, do you know how Elasticsearch may behave when used with the new garbage collector from the JDK 12? What are the pros and cons? If this piqued your interest, then it may pique someone else’s, too.</li>
</ul> <h2>Turning ideas into action</h2>So far we’ve covered how to come up with ideas for what to write about. But how do you actually start the writing process?
First, before you even get your first word down, remember: writing isn’t about producing something that’s perfect. Instead, focus on creating something that will be useful to your reader. In order to do that, it’s important to understand your target audience. Properly understanding your audience will help a lot in managing your expectations about how much effort and time to put in your work — which hopefully will lead to less frustration.
For example, if you’re planning to write about a lesson learned, then you need to evaluate whether the subject you’re writing about is a well-known concept. If it is, then your content doesn’t need to provide a detailed overview before getting into the guts of the story. If you’re writing a blog targeting Java developers, you don’t need to explain what the JVM is.
Next you’ll want to think about the best format for your content. Although there are many types of writing out there, it might be easiest to think in terms of two main types: longer-form, formal articles and more casual pieces like blog posts. For more casual writing, such as a post on your personal blog, it’s best to keep it short and high-level and focus on a specific topic, like this one that shows <a href="/blog/how-to-run-elastic-cloud-on-kubernetes-from-azure-kubernetes-service">how to run Elastic Cloud on Kubernetes from Azure</a>. Formal articles are usually longer, provide deeper context, and may explore different facets of a topic or multiple topics, like this one about <a href="/blog/benchmarking-and-sizing-your-elasticsearch-cluster-for-logs-and-metrics">benchmarking and sizing Elasticsearch clusters for logs and metrics</a>.
If you’re writing about a journey, then you might want to write a longer piece, because you’ll need to provide a good amount of details before jumping into any conclusions. The tone for longer pieces tends to be more educational and scholarly. Use cases and lessons learned can be written in a more informal, blog post style, as they tend to be short and sweet and use a tone that is more laid back and sometimes even witty.
Your unique communication style also plays a key role in your writing. We all have different communication styles and ways of expressing our thoughts. This is a great thing — in fact, it’s part of <a href="/about/our-source-code">Elastic's Source Code</a>. So whatever your communication style, please embrace it! The unique way you create emphasis, how you break down concepts into bite-sized chunks, and even your sense of humor is what makes good content. If you’d like to refer to guidelines for how we write at Elastic, feel free to check out our <a href="https://brand.elastic.co/302f66895/p/072ccc-naming-guide">naming guidelines</a> and our <a href="https://brand.elastic.co/302f66895/p/194a3b-writing-style-guide">writing style guide page</a>.
Finally, make sure to proofread your writing before you publish. This means making sure that the grammar is impeccable and your thoughts are clear. Try reading your writing several times and revisiting problematic areas. If possible, ask a friend to provide feedback as well. Be open to feedback, especially feedback on areas that might be unclear.
We hope that this blog post has helped you to start your journey in contributing written content to the community. If you have any questions about how to contribute, please feel free to reach out to us at <a href="mailto:contributors@elastic.co">contributors@elastic.co</a>.

Articles by Ricardo Ferreira

Elastic Contributor Program: How to contribute code

Elastic Contributor Program: Tips for creating written content

Products & Solutions

Company

Resources

Featured topics

News

Articles by Ricardo Ferreira

Elastic Contributor Program: How to contribute code

Elastic Contributor Program: Tips for creating written content