My first take on this: You really must be loving these community plugins, dont you? (because this will surely be a hit to the ecosystem of community developed plugins - less ppl installing, less feedback, less motivation, less etc.)
My second thought: Well, i can easily envision a benevolent thought process behind all this when pulling the alledged concerns/needs of your paying customerbase into the bigger picture.
So ā¦ i would like to abstain from asking anything but:
Were your users (non- and/or paying) integrated into the decisionprocess to invest into developing this MMF?
This MMF was driven by security concerns. You may be aware that in 2020 a number of SonarQube instances were found to be exposed on the internet with the default admin credentials still in place (reference). While that was purely user error, it caused us to step back and take a fresh look at the security of SonarQube instances.
One thing we realized is that while we can ensure the integrity of what we (SonarSource) provide, we canāt do that for community plugins. And, given the fact that (a ālongā time ago) we used to provide our functionality through the Marketplace (nee Update Center) itās possible that some users may not be aware of the distinction.
So our goal here was to provide a tiny wake up call to make sure that people are aware that theyāre using non-SonarSource functionality, and they do so at their own risk. I understand your concern about a negative impact on plugin maintainers and users. But if we had delivered this tiny wake up call as a mere disclaimer in the interfaceā¦ Well, surely you know how often such things are actually read.
At the same time I want to assure you that we are concerned with fairness in our handling of the plugin ācommunityā (maintainers and users). Please know that the goal is not to inhibit this community. Merely to make sure the cards are on the table.
What are the reasons behind this being implemented in the commercial editions only ? and why donāt you want to make it configurable for the commercial editions, so that the customers themselves can decide if they want to āstickā to the old way of installing plugins or the new manual (and very very time consuming) way via for example a startup property ?
You implement a āforceā mechanism without asking the customers of the commercials editions if this should be configurable and I donāt get why this manual installation should āonlyā be for commercial editions. Itās a āone-size-fits-allā (one size fits nothing as I tend to say) approach - where you decide whatās best for customers. Thatās a no-go
In our company I am the person in charge of the update of SonarQube ā another person is in charge of the plugin updates and all the UI settings (rulesets, portfolios etc). The other person do not have access to the filesystem, so on every update of a plugin or when adding new plugins the other person needs to have me to work. (Dev and Ops seperation right ) - thatās a really annoying extra process. Think about if Atlassian did this on their Jira, Confluence and Bitbucket products without asking the customersā¦ Itās the first product ever where I see this approach on the plugin eco-system. Give the power to the people and remove the force mechanism in the commercial editions via the possible to configure this as a system startup property. Thanks.
When I need to update to the new manual way of installing plugins I need to find all the ādownload urlsā for the plugins and put them into our Ansible configs. Itās really a āheadacheā for us in our company.
So once more (also asked to our account manager): Why donāt you want to make it configurable for the commercial editions (like the community editions), so that the customers themselves can decide if they want to āstickā to the old way of installing plugins or the new manual (and very very time consuming) way. I havenāt found that answer in the supplied information.
TBH it wasnāt clear to me that you were actually looking for answers, especially since - as you say - you asked your account manager, who Iām confident has gotten back to you. I provided the main motivation above. Nonetheless, Iāll expand a bit with a snippet lifted from an internal discussion:
In our commercial editions we are providing an enterprise-ready solution, one that is scalable and works well. We can not support what is or isnāt happening with some of the plug-ins in the community and we want there to be a clean line between what we are providing you and what is not part of SonarQube.
Regarding this:
I understand that the extra steps are annoying. I think most people find changing procedures for security compliance irritating at first . But if this is happening very often, I would wonder at your use case. Since Iām the one who manually processes Marketplace updates, Iām well aware that new plugin versions donāt come out every day.
You make a fair point about the discoverability of plugin download URLs - one weāll hopefully address soon. In case it helps, hereās where the metadata for Marketplace plugins is kept.
Maybe an idea was to enrich the documentation with a link to GitHub - SonarSource/sonar-update-center-properties to ensure that the users of the commercial version is quickly able to find the plugin urls - not some fake āman in the middleā urls but approved by SonarSource as plugin urls. Just input.
I respect that you would not like to support community plugins in the commercial version - but I still think the decision should be one the customers should take. For example by enabling a system property and thereby being able to download the plugins without fiddling with the filesystem. By enabling this system property the customer themselves take the security risk. For customers with a commercial license but without support license (as us) this would be a 100% match.
Some reflections:
Imagine if Atlassian or other vendors took the same decision as SonarSourceā¦ Jira, Bitbucket and Confluence without community pluginsā¦
Itās a strategy for a product and I respect your strategy but IMHO I think you should really treat the commercial customers with great care and not take decisions on behalf of them. Take my advise as input for a more customer centric strategy
Sadly you found no words to address the following question:
Also: If your last sentence is truly ment that way ā¦ than (in my opinion) some warnings plus ārequiring and documenting consentā would have put all ācards on the tableā as you stated.
Actively destroying convenience has - to me - a rather strong smell of inhibition, tbh.
But of course, your product, your choice.
If i may, iād like to suggest some kind of questionnaire sent to your customers to find out how well recepted(?) this new feature is and what might be done in consequence to mitigate any negative perceptions.
This is really a downer for administration. Since for us, the maintenance of tools like SonarQube is made not by an entire IT department, but by some developers here, that are doing this work on top of their normal work.
At least you should have left the option to reenable this feature and leave the decision on that to the user, after initially disabling it.
Maybe good for bigger departments (I doubt) but not for us here and as I heard in other posts, for many other people also not.
maybe you rethink this and give us the ability to reenable this again.
(because this will surely be a hit to the ecosystem of community developed plugins - less ppl installing, less feedback, less motivation, less etc.)
) - thatās a really annoying extra process. Think about if Atlassian did this on their Jira, Confluence and Bitbucket products without asking the customersā¦ Itās the first product ever where I see this approach on the plugin eco-system. Give the power to the people and remove the force mechanism in the commercial editions via the possible to configure this as a system startup property. Thanks.
. But if this is happening very often, I would wonder at your use case. Since Iām the one who manually processes Marketplace updates, Iām well aware that new plugin versions donāt come out every day.
