On Open Source Trolls

We all use open source projects to complete our daily jobs. We all stand on the shoulders of giants. However it seems as though there are many who take the hard work of others for granted. They’ve come to expect enterprise level support and stability from projects that are given away for free from generous people.

Since I’ve started developing with React Native/JS, I’ve begun to actually contribute back to some of the projects that I use. Not nearly enough, but something is better than nothing.

As my involvement in the community has increased, so too has my empathy towards those who manage these heavily used projects.

I understand why people may feel frustrated when updates to their dependencies introduce regressions, but why this sense of entitlement? These regressions are never intentional, and breaking changes are generally well communicated especially with large projects such as ReactJS / ReactNative.

There will always be edge cases that the team simply can’t account for. ReactJS in general is downloaded millions of times each week. The distribution is so large that introducing bugs is inevitable.

Bug reports are incredibly valuable, but comments such as:

Yeah … RN is so instable … RN dev spend more time fixing bugs than properly coding

or

I hate React Native now. The basic functionality is not working what the worst team, don’t you know test before release?

This type of response/comment is not helpful to anyone. Instead, let’s try to positively articulate our experience when we issue bug fixes and circumvent negative comments. Let’s not forget that there is a person on the receiving end of these harsh comments.

We need to focus on the issue at hand, offer helpful suggestions to the best of our ability, and if possible offer a code repo / sandbox that duplicates the issue. These are solutions that will benefit others who have the curiosity to learn.

See this post on on how to write helpful bug reports

Here are a few items that I believe are of utmost significance:

Don’t assume that the developer has made a mistake and hence you can use harsh words. Before reporting, it is equally important to check if the same bug has been reported or not.

and

A duplicate bug is a burden in the testing cycle. Check the whole list of known bugs. At times, the developers might have known the issue and ignored it for a future release. Tools like Bugzilla which automatically searches for duplicate bugs can also be used. However, it is best to manually search for any duplicate bug.

In the current world we live in, we need to recognize the developers that are giving away their work to help you improve so let’s pay it forward and show them the respect and appreciation warranted.