search

clutcher / bh

Issue tracker for Better Highlights Intellij IDEA plugin
7 stars 0 forks source link

Split this plugin into 3 plugins #135

Open mgroth0 opened 3 weeks ago

mgroth0 commented 3 weeks ago

We touched upon this in https://github.com/clutcher/bh/issues/102 but I wanted to give it a dedicated thread.

Wikilinks has been a pleasure to add to my project and to my workflow. Its a brilliant idea and I am happy to continue supporting it.

The other features of this plugin are great too, but feel completely unrelated. Being forced to install them makes them feel like bloatware. Not because they are bad, just because wikilinks provides such an essential feature that you can't live without it (and can't replace it with any other plugin) and so you have no choice but to have the other stuff.

I see potentially 3 different plugins here. Below I categorize features based on how they are listed in the settings panes.

Plugin 1: Wikilinks

Plugin 2: Better Highlights

Plugin 3: Cognitive Complexity

I would ask this: Technically speaking, aren't the 3 categories I listed above interdependent? Couldn't they be isolated? In general, I would argue that features being made by the same developer or being loosely related under a single umbrella theme is insufficient reason to package them into a single plugin.

Wikilinks provides a unique feature that can have a significant impact on project structure and workflow.

Fine grained control over code highlighting is a great idea and I support it but don't need it. I just don't think it addresses overlapping concerns with wikilinks. They are separable. Code highlighting just provides visual cues, whereas wikilinks has an action associated with it (jumping between different code).

Cognitive Complexity seems even more distant, being a static code analysis. Programming languages usually have specialized tools for static analysis. For example, kotlin has detekt. It feels out of place here. Its a valuable feature, just seems out of place.

I recognize this is a big ask, and for a single devloper that publishing one plugin might be easier. But from the user perspective, seeing these features together makes this plugin bloated. And from a business perspective, separating them into multiple plugins gives each more growing space and makes it clear what people want to pay for.

Even if this is rejected, thank you for hearing me out.

mgroth0 commented 3 weeks ago

I also wonder this. From a financial perspective, you could ask people to subscribe to each plugin individually (and potentially make more money). But if there is any concern of losing customers from this, I am curious if there is technically any way to sell a subscription to a "plugin suite" of some sort. This means that one subscription still buys all these features, but users can still install only what they need. No idea if something like this is provided by Jetbrains. But in any case, you could always sell them as separate subscriptions but then tell people that if they buy one, you'll give them a special code to get the others for free (I am sure this is possible since you can give discount codes)

clutcher commented 1 week ago

For everyone, TLDR:

@mgroth0 Based on our previous conversations, it looks like you are pretty long in IT industry, and you can read "longreads", and discuss things using logic and facts, so below I will answer personally for you)

History on plugin evolution

First of all, I'm working on this plugin to add/fix things, which I need personally. I'm always open to help others, if I have time and ability for that.

Initially I created this plugin to higlight comments with "!" and "?", because plugin Better Comments stops working with Java. I named it "Comment Highligher", open sourced on github and it was free for use. I was adding some functionaliy around comments in my free time, when other people asked for it.

Next big thing - I added possibility to highlight "public" keyword on method levels. Projects, which I work with usualy have a bunch of "Util" classes without Interface implementation and with mix of public and private methods, what makes it difficult to fastly see, which methods are designed for public usage (yes, there is such thing as Structure view, but I were not able to adopt it). Again I added various functionality around it by request of other people in my free time.

Next thing - I added wikilink functionality. I'm working with SAP Commerce for last 10 years, which is basically a 2,5 GB of zipped Java code, provided as a "platform", which you can't change, but you can extend and replace things there. And it is a regular thing to see comments, which mention some "platform" classes, which you need to look into. So I implemented wikilink stuff to save time in searching such classes (you can use Ctrl+B to get directly into implementation) and to get rid of case, when classes in comments are renamed/removed etc and you spend tonns of time in git history to find out that class. On this stage plugin is still free and I add various functionality on user requests in my free time.

And finally - I added cognitive complexity. I got on a project with strict SonarQube rules and a lot of legacy code with 500+ lines of code in methods, where easiest "extract" method refactoring lead to blocking PR for merge by SonarQube. So I needed something to see that directly in Intellij, while working on code. There were 3 plugins with such functionality, one worked only in Rider, another one were not working with SAP Commerce plugin and with third one I had an "estetical" issues (there is also SonarLint plugin itself, which can be used to resolve that issue but it provides totally different dev experience). On this stage plugin already become freemium, with only keyword highlight functionality hidden under paywall.

Monetization

As I said above, I created this plugin as an open source solution to solve my personal issues with Intellij. Don't want to go deep in details, but year ago I had financial issues related to my force "relocation" from Ukraine in 2022, so I decided to "monetize" everything I could, including this plugin. After one year of monetization, after all discounts, commission, taxes etc, I receive ~100$ a month from this plugin. And I spend on this plugin 20-40 hours per month, mainly dealing with other user requests. From financial point of view there is more sense for me to remove this plugin from marketplace and spend that time with wife and daughter.

My main point here - is that I'm solving my personal issues with this plugin, doing my best to help others with this plugin in my free time. Current amount of monetization doesn't even cover the time I spend on plugin, so I'm considering current income as a donation on coffee, which I drink during time spend on working on user requests :)

Splitting vs Bundling

For me it is just different approaches for developing/shipping products, which we can see everywhere around in IT world. The most obvious example would be Windows vs Linux with its Unix philosophy. Personally I'm using Linux system as my main OS since 2007+- and I like idea of having things, which are doing one thing good. I remember Nero Burning Rom, which were awesome for writing on CDs before it become unusable combine with audio listening, mp3tag editing etc.. But I think that in the real life most people prefer to have one software for everything and that`s one of the reasons, why we have Windows, emacs and various software, which becomes a combine of everything like Nero, ACDSee etc.

My main point here - is that highlevel I don't really care if it is one "toolbox" plugin or three different plugins with tendency to split it on 3.

Consequences after splitting on 3 plugins

First thing to say is that all 3 piece of functionality reuse same "core" implementation for "highlighting" and settings (UI and persisted configuration). So if there is some bug in rendering of color, or icon, or settings - I would need to do commits in 3 repositories and do release for each plugin(which also means description, what's new etc).

Another interesing similar thing related is support of different version of IDEs. Most plugins or drop support for old versions, or use different branches with different releases for each major IDE version (2024.1, 2024.2 etc). To not deal with different branches/releases and still support various IDE versions I have a bunch of classes with Reflection/MethodHandle, which are shared between all 3 pieces of functionality.

Next interesting thing would be performance for users of all 3 plugins, as there would be enough code duplicated 3 times.

Financial perspective is also complicated as Jetbrains doesn't provide anything for such cases. You can take a look on that plugin developer - at the end he supports 3 plugins + 1 separate plugin with other 3 together to provide "discounts".

All above things are technically solvable. Like I can create some automation for releasing plugins, extract all common code into one more plugin, design some simple pricing strategy for all plugin and just do not provide "discounts" for buying all 3 plugins together etc. But it would require tonns of my additional time to deal with all of that to return at the end to the same point as I am right now with additional overhead on supporting automation itself and having 5 repositories with 5 plugins (core plugin, 3 plugins with each functionality and one more plugin with everything together to provide discounts).

My main point here - is that technically I can deal with all this consequences, but I don't see any reason to complicate my life with all of that right now.

Conclusions

In general, I support idea of splitting it on few plugins, but I don't want to spend time on all additional overhead, which I would recieve with that splitting. I can reconsider that decisions, if/when income from plugin would reach +-500$ per month and Jetbrains would add something to provide discounts on plugin packs. Theoretically it can happen in 3-5 years.

mgroth0 commented 1 week ago

I appreciate this answer. I'm actually not nearly that experienced in the field, actually less than you. I won't go into too much detail about myself in a public thread but I think its more of an obsessive attention to detail with me that you might be picking up on. You seem to have your priorities straight in life and that's the most wise thing, and something I am working on with myself. :)

I fully support your decisions above, and I won't comment directly on your points besides to say thank you for providing so much insight into your experience.

I just want to give my own ancedote as possible inspiration for your work on wikilinks. The reason the wikilinks feature is special for me is that I've found some ways to use it that enabled me to do things I otherwise would not. I have a lot of code, and mostly kotlin/jvm. I usually find my way around it by using the "Find Usages" action. But in the last couple of years I have also added lots of python and native code and have developed frameworks for calling python or kotlin/native methods from kotlin/jvm or vice versa. Basically, created some software using multiple languages talking to eachother (over JNI or sockets) which breaks the workflow of being able to use IntelliJ's "Find Usages" action to get around logically. But that's where Wikilinks really changed everything, because it supports any language in theory. Like for python, for example, I generate python code from kotlin which is bound to kotlin functions over a socket connection, and I include the wikilinks comment directly with each generated python function linking it to its kotlin function. So I can jump from any function to any other function associated with it in a systematic way, right in the IDE without having to develop a plugin or anything. I do the same thing for Kotlin/Native functions connected to their kotlin/jvm counterparts over JNI. My point is, wikilinks feels like something with big potential, maybe for generated code and code that connects to eachother without directly calling eachother especially. I think if I didn't have these comments to navigate with, I probably wouldn't have continued to pursue integrating multiple languages because navigating would be too much of a hassle.

I've benefited a lot from the work you generously put into this plugin and hope it continues to be successful, in whatever form it takes.