An example of how to not reach your user base

3 points by fioan89 3 years ago · 2 comments · 4 min read

Greetings everyone, I'm Ioan, creator and maintainer of Sourcesync - a plugin for Jetbrains products to sync files to remote targets.

Around 2015 I was working for a company that had an inhouse build system running in the cloud. The development cycle was really painful, we had to write code locally, and then using a tool like scp/winscp to copy the code to the remote building machines and start compiling. Manually moving files between local/remote target was tedious & error prone. And so I started to write a plugin for IntelliJ, my favorite IDE from Jetbrains to improve my life.

I released it to the public and also made it open-source. It turns out that a fair amount of developers were in "the same boat" as myself. Around the end of 2016 I left the company, but I kept addressing issues and features as often as possible I could.

During the years some of the feature requests and bugs that needed a lot of effort to implement started to pile up. I tried to find a way to allocate more time so that I could move the plugin at a faster pace. It's at this point that I thought of trying a freemium model. Keep maintaining the open source version but also publish a "pro" variant that included the most requested features. The open source version was going to benefit from all the bug fixes from the pro version and from time to time some new features.

But before starting the actual work I wanted to validate my idea, see what other features might be needed, and even discuss a pricing strategy with the active users of the plugin. So I needed a way to find who uses the plugin and how to contact them. Unfortunately the Jetbrains plugin marketplace doesn't help too much on this matter. At least not with free plugins. But I devised two ways of reaching some of the users:

1. Release a new version that contains a notification banner which redirects users to a Github discussion around the matter. It has the benefit of reaching the actual active users, but it can disrupt their work. 2. Grok all open and closed Github issues, compile a list of users contributing to the issues, open a discussion and mention the users. Obviously, there was no longer a need to do a new release with unwanted banners, but it also suffered from reaching out to users that no longer have an interest in the plugin.

I definitely would not want my dev workflow to be interrupted by pesky banners in the middle of something so I just went with option nr. 2. I've compiled a list of over 80 users which I could mention in the discussion. Surely a good chunk of them were still active.

A week or so ago I posted a discussion on github and..., well a couple of users that were no longer active, and who were also not very pleased with past support, reported the discussion to Github as spam. The same day Github flagged my account, which made it inaccessible to the public, and also limited my actions on all my repositories on Github. The account is still flagged for 8 days now.

https://drive.google.com/file/d/1wvrxOgjYRDLqO5pWMYWNiegqUaWJG2WT/view?usp=share_link

I'm not entirely sure what conclusions to draw. Actually I now have more questions than before. There was definitely no discussion about a pro version, we derailed a lot from the topic as you can see, but I'm also left with some "existential" questions: - what Github policy did I broke by mentioning users? Users which at some point in time were involved with the plugin. - why do some people think that open-source is a one way street? - there are so many things that spam us daily (unwanted newsletters, social media, linkedin, targeted ads, etc...), why would anyone get angry with a Github post where help is requested? - would it have been better to just start working on a "pro" version? - or maybe it would have been better to disrupt user flows with banners asking them to provide feedback?

https://github.com/fioan89/sourcesync

https://plugins.jetbrains.com/plugin/7374-source-synchronizer