Open Source Software (OSS) is becoming more important each day. While in the early days, most software written was offered as proprietary products, today large products are available as OSS. On one hand this often includes the ability to use it for free and change it if needed. On the other hand, those projects rely on contributions by personal and corporate volunteers to maintain the software. But the process for that can be intimidating, since those big projects seem to large and professional for anyone to make a meaningful contribution.
Bricking my Elasticsearch cluster
I am using OSS for almost all my projects. For personal projects, I simply don’t have the resources to adopt large scale enterprise systems, and for professional projects it’s great to be able to save cost and help those projects grow. Like I’ve described before, I use Elasticsearch whenever I need to process logfiles or vastly different types of data in the same system.
A while ago, I upgraded my Elasticsearch cluster that I use for Smarthome and Logfile purposes. The process itself was painless (apt-get update & upgrade) and quick, documents got indexed and became visible in Grafana and Kibana. So, everything seemed just fine.
But a few days after that, Elasticsearch became unstable. Of the three nodes I had, one after the other started crashing. This seemed weird, given that they are decently sized and nothing changed configuration-wise. Reducing indexing-load seemed to slow down the process, but ES started crashing even without any documents being indexed!
The error itself was the dreaded Java-Out-of-Memory (OOM) error. While this confirmed my Java aversion, it seemed to be fixable by giving more memory to ES or changing the way it uses it. So this is what I did, doubling the memory on the VM and playing around with memory settings (find some more details in the docs). But nothing helped.
Being close to reinstalling ES completely, I took my issue to the forums, describing the issue and what I tried so far, including logs. This was the first time I did something like this, so I was not sure I described everything in enough detail. But within two days, one of the ES Team Members reached out and was able to nail down the issue immediately. With his help, my cluster went back to a stable state immediately.
The problem was caused by a new config parameter, which is ignored if there is a user-modified version of the config installed (at least on Ubuntu). This destabilized the whole cluster. Because this change potentially needed user action which was not documented, the amazing ES-guys opened a ticket to deal with the situation.
Contributing without coding
So, I contributed to one of my favorite OSS projects without writing a single line of code. All I did was find a problem and bring it to the developer’s attention, describing what I tried to fix the problem myself. This inspired me to write this post and point out some of the ways to help with large projects, even without coding.
While providing feedback and user experience is valuable, there are many other ways to contribute. Just think about the different parts of large scale projects: Besides the code itself, users need technical documentation and practical examples, business cases and integration paths. Those can be provided by anyone! And to manage all that contribution and feedback, some moderation is needed as well. This gives plenty of opportunities to help, no matter what your background is.