Being active in communities

If by a pure coincidence someone ever watched this blog, he may think for example that I gave up writing new posts. It's not quite like that. Maybe I got a little lazier, my priorities changed over time. But I was also a little bit more active in communities - and this is the topic I would like to write about this time - to give you some ideas of what and why, plus some real life examples.

Active in communities - what's that?

If you haven't guessed already, I mean software communities. And by being active in them, I mean direct communication with the authors or other users of a concrete piece of software, being it an application, library, framework or whatever else. Such communication is done via authors' bug tracking system, forum or for example by email if there is no better way.

When you do this, you typically report a problem, help to solve a problem, vote for solving a problem, or simply just ask a question. Some call this a contribution and such a contribution is usually expected to be useful - no trolling nor unintended stupidity is welcome. So better be prepared to formulate your thoughts well in this area.

Why being active?

Just a few paragraphs and we are already getting to the core of what I want to share with you. I'm so proud of my conciseness sometimes! ;)

So what's the point of being active in the communities? I can see several reasons:

1. Better than to curse. Contributing has usually more positive effect than just to curse the software or their authors.
2. Improvement of the software. More or less directly, your action may lead to improvement of the software or its documentation. If nothing else, then at least you somewhat increased awareness of some problem. And if there are enough people claiming the same, someone grabs the it and fixes it. A nice example: Eclipse 4 broken perspectives (Thanks to Andrey Loskutov for undertaking this software maintainers' nightmare!).
3. Learning. You learn more about the software you use and you learn to express your thoughts in a clear way. You may also improve your language skills.
4. The effect you wish. You may blog, tweet, etc., about the problem, but depending on your impact area this doesn't have to have the effect you wish. An example: I blogged about a very unwelcome Maven artifacts resolution "feature", but as I know that no one actually reads this blog, I linked to the post from the corresponding bug tracker issue.
5. Easier than maintaining your local clone. It's not unusual that when you work with open source software, you make your locally maintained clone of it and put your custom features or bug fixes into the clone. Depending on your or your company strategy, this may suffice.
   But it turns out that contributing your patch to the original authors may be better because of all the positive side effects of doing so (easier or no merging of the changes when upgrading, authors or the community may give you a helpful feedback, maybe even tell you you are doing it wrong, etc.).
6. Good feeling from doing something for the people and for the world. :) This may sound like a cliche, but let's have a deeper look at this...
   This is probably a topic for a separate post, but have you ever heard about Green Computing / ICT? Unfortunately there is plenty of software in our daily use that consumes resources for no good reason. Take for example all those background processes which start up your computer fan when you leave your computer idle for a while - this is nothing wrong if it takes some finite time. But when it has no end, such software needs to be considered broken, senseless and thrown away. It's like ordering a service for your company and the supplier tells you that it can deliver the service only when you stop all the work for 4 hours every day! Again, an example taken from an open source product which I quite appreciate otherwise: Alfresco CMS and its Solr indexing craziness.

More examples from practice

In the preceding text you could already read some real life examples of interaction with some of my favorite software products like Eclipse, Maven or Alfresco. Let's have a look at another interesting ones:

Activity with Jira

Well, Jira is surely a great bug tracking and projects management system, even when it isn't open sourced. Still, it has got some gotchas - long outstanding issues which kinda surprise me. (Add to this that Jira authors recently decided to completely "modernize" the good old main menu, which was quite loudly rejected by lots of users - I haven't watched the story for some time though...)

I think Jira is an example of where the results coming from community activity are often close to zero - a typical resolution of many issues is Won't Fix, without any useful explanation or workaround. And this is done even for issues which are both seemingly easy to resolve as well as highly upvoted, even by paying customers.

It starts with relatively small feature requests like:

• Mousing over custom field name on view issue page shows only the field name in the tooltip, not the field description - JRASERVER-28503 (from 2012)
• Unable to change issue link type - JRASERVER-3097 (from 2004!)

And it ends with some long outstanding WTF bugs (I mean: "How can they even exist in such an application?".). To name some that I have also participated in:

• Unable to edit an issue when the user is deactivated - JRACLOUD-38412 (from 2014; after 5 years things seem to start moving - success finally?!)
• Changing Default language and creating a new project creates unwanted Issue Types and Resolutions - JRASERVER-43539 (from 2015; a duplicate was created in 2018 and closed as well; hopefully a minor impact though)

Activity with KeePass

I don't use KeePass for that long, but after using it for a while I noticed an apparent security issue with passwords still being visible after KeePass restart - #2462. Even though I had to remind the issue to authors, a new option was implemented pretty quickly afterwards. The old behavior was not changed as I suggested, but be prepared that you can't always get all what you want - the final decision is always left to the authors.

And that was probably the final thought of this blog post. What do you think about the community contributions? Do you have some other or different experience?