I think this is a great idea Justin.

Cheers

Mary

I like the idea of a searchable "commercial" badge/tag, it would save some time when searching for commercial plugins first. 

Sounds like a good idea, Justin. I'm behind it.

Fernando

I think this is a great idea, with a few caveats:

> It would be up to the plugin developer/publisher to decide if their plugin is "commercial" or not.

No I'd just make this part of the review process, and do a quick retro check of all existing plugins. It's pretty obvious and easy for a reviewer to check. If the data isn't accurate and trustworthy then it is worse than not having it at all.

Also there might need to be some grayer middle ground, there are plenty of 'free' services which cost as you scale. Or plenty of fully open source services but where you'd mostly want to just use the paid cloud version anyway.

> My own experience has been that organisations want their key 3rd party plugins to be professionally supported and maintained.

I wish it wasn't so but I could (but won't) give counter examples. But generally it is good and the bad ones are getting better.

> So I think its reasonable to charge for the use of the "commercial" badge

I disagree with this based on the previous comment. I've dealt with vendors that frankly couldn't give two #*@$ about moodle and their plugins for moodle are often behind an authenticated customer login. Across the board they are slowly moving to sticking them on github and putting them into the plugin dir and I would not want to jeopardize that process at all. The amount of $$ HQ would get from these listings would be not worth the hassle.

There is also a legitimate use case for having a moodle plugin dir listing, but not having the source code attached, for when a 3rd party plugin has not been distributed and is not open source. ie it's just more or less an ad / placeholder which points off to the vendors site for paying and downloading the plugin. This could make more sense as a paid offering, but again I doubt whether it's worth HQ's time to implement (let alone if they'd want to). I've dealt with a couple clients in this position who are selling standalone plugins, rather than a thin plugin around a paid cloud service. Moodle doesn't seem interested in supporting this type of ecosystem in the same way as say Wordpress already is (which is cool I'm not judging just observing). 

Also why shouldn't all the various 3rd party services available over LTI not be represented in some way inside the moodle plugin dir? From a users point of view there can be little difference, and it would be great to have visibility of these when searching.

I could write a few specific comments on this, but I don't have time now.

In summary Justin: great idea.  I support it.  The detail is always the sticking point.  What does HQ say?

-Derek

As a bit of a counter-example to this 'commercial' badge - I don't consider any of my plugins to be 'commercial' they are all completely free and do not require any additional services in order to work. On the other hand, should anyone wish to pay for expedited support for them or wants to pay for new features to be developed (the first of which has not really happened, but the second has happened a number of times), then I'd pass them onto my employers to arrange for that to take place.

In my case, I don't think the lack of a 'commercial' badge should be any disincentive for a company to use it.

So really, this seems to be trying to conflate two separate ideas:

• the idea of a plugin that (potentially) has additional costs associated with it just to use it normally
• the idea that a plugin has, if required, the possibility of offering paid support (whether fixes or additional customisation)
  

It was also mentioned in passing that some plugins might not be open source, that is not possible for a Moodle plugin (as far as I understand it) - all plugins are directly tied to the Moodle code, so are covered by the GPL. It may be that for a plugin developed for a particular client neither the developer nor the client chooses to distribute it further; it may also be that a developer might request that anyone paying for a plugin does not distribute it further, however the GPL would not allow that to be enforced legally (just politely requested).

Thanks Justin for opening this discussion, and thanks everybody for your comments.

Moodle plugins directory has the support for descriptors (labels, tags) implemented. Some of these descriptors are exposed via the new UI on the front page - that is what allows to filter plugins by purpose, for example.

Not all of these descriptors were fully exposed via the UI yet, but we already started to assign them to some plugins. Among these, we have descriptors that mark the plugin as requiring an external service. And we distinguish between free integration and paid (subscription based) integration.

The idea was that we will able to clearly inform the user that the plugin does not work out of the box itself, that it needs an external application or service to operate. And that the external service may or may not be available for free. In reality, these things are not black & white as often there are multiple plans ranging from free to premium subscription. So the plugin can actually receive both these "requires free integration" and "requires paid integration" labels.

We plan to improve this during the next phase of Plugins directory upgrade (not scheduled yet).

I believe this feature will address significant part of your proposal.

Justin I totally agree with you. Plugins can be totally free and can be distributed from moodle.org but the support service is totally different and could be commercial in some cases.

Adaptable is free, and will be free forever, but to provide support for some clients can't be free. Mainly because some type of clients (universities, companies, large academies. ...) need other kind of support that a simple forum as moodle is.

That's the reason we developed a new web site to provide support to all the Adaptable users. The site was published last week and in a few days will have a Premium Support service for those that need it.

It includes also several sections related to the theme but the main is a ticketing system. This option will allow us to provide better support and split free and premium support. Technical support will remain free for those that need a simple support and can wait some hours to get the response and the premium support will have a cost for those that need a fast response time and even not only support also custom development.

So add a badge in the MPD for plugins that can have some commercial services or extensions is very important for users before install the plugin. This is very common in other scripts like Joomla, where the JED (Joomla Extensions Directory) display if the extension is free or paid and you can filter the search for this item.

But I don't agree with the idea that plugin developers to contribute to moodle. And the reason is very simple. The service is commercial, but not the plugin that remains free and under GPL. If developers must pay to moodle for the support service then the easiest is to move the plugin outside moodle and even sell the plugin.

A theme needs thousand hours of development (this is not a simple block) and needs hundred hours to provide support (that almost all the plugins do not provide). So it is not fair that some plugins pay and others not just for the complexity of the plugin, number of installations and/or the target user.

Other plugins directories are just directories that show extensions for its script like Wordpress or Joomla. Developers DO NOT PAY for add his extension to the directory. And at the end, who wins is the script, moodle in that case, because users will go directly to the directory to find the plugin instead search internet and go to other site to find the plugin needed.

I agree with you Justin. It's only fair for users to know what they are getting into and if any future cost is involved. It's not a perfect analogy, but when I download apps from the Apple AppStore I like being informed about any "in app purchases" so I can make an informed decision. I believe your suggestion would add to transparency and prevent unwanted surprises.

I'm all for clarity at this point. If a plugin depends on a subscription to an external (commercial) service, or if it depends on another plugin which in turn depends..., etc., then it would be beneficial to indicate this as clearly as possible; and if one can narrow the search by that, even better.

Also, I think it would be best if plugins were not allowed to change category in this respect. That is, if someone were to publish a subscription-based version of a previously free-to-use plugin, then they should do that as a separate plugin under a different name and plugin DB entry; not least because of Moodle's automatic update feature. Unfortunately this is a situation only too common in the mobile "app stores": an app is advertised as free to use, attracts a lot of downloads, users, "likes", etc., moves up in the listings and search results - and once it's near the top, it suddenly changes to "premium" or heavily ad-based via the automatic updates. (Of course, in that form it would never have made it to its position.) This has always struck me as dishonest.

Reopening this discussion thread by request...