I would like to propose that we add some sort of icon or badge to be displayed in the plugin listing, that indicates it is not free. Or that it represents a paid service.
Right now the overwhelming majority of plugins on the plugins database are utterly free. But there are others that represent paid services or require a subscription or license of some sort. My own Poodll plugins fall into the non free category. It would be up to the plugin developer/publisher to decide if their plugin is "commercial" or not.
The justification for this badge as I see it is:
i) it alerts the user that the plugin they are considering installing is not free or has paid components.
ii) it encourages the distribution of commercial plugins on the Moodle.org plugins database.
iii) it provides a possible revenue source for Moodle
To expand a little, its been mentioned previously that Moodle prefers to have a single plugins database (ie an official one and no unofficial ones). It makes sense then to cater to plugin vendors, to avoid alternate plugin marketplaces arising. My own experience has been that organisations want their key 3rd party plugins to be professionally supported and maintained. And I think a healthy commercial plugin ecosystem will be good for Moodle and for its users, and should be encouraged.
I also think that those making money from Moodle, or using Moodle.org as a distribution network for their product, should be contributing back to Moodle. So I think its reasonable to charge for the use of the "commercial" badge, or to require users of such to be Moodle partners, and possibly to specify guidelines for which a plugin might be deemed "commercial."
(Just because its relevant, let me say that I think that the collection of money from users is not a role that should be carried out on Moodle.org. That could skew things and would probably cause more overheads and hassles than revenue would compensate.)
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.
Thanks David, thats really good news and pretty much what I wanted to hear.
I know the topic of commercialising plugins raises a lot of questions and differences of opinion. So I am really happy we got comments from some of the plugin warriors in the community. My position is pretty clear and I guess I have a sort of working model already in place. Happy to share information on that if anyone is interested.
Hi Justin,
As a thought, there does now stand the business model with apps where 'this app contains in game purchases' etc. So, could there be two types of badge? One for pure commercial and another where the plugin is free but contains 'in-plugin' options to purchase additional functionality?
Cheers,
Gareth
Hi,
I doubt just 'this app contains in game purchases' would do for Moodle.
Personally I think it might also be interesting to add a "There is a company behind this plugin that can provide commercial support" or something.
Although I do wonder about what HQ's stance is on this kind of commercialisation.
Personally, I (as CEO of a company that also has a couple of plugins here) would like to see the following tags or badges:
- Free plugin (entirely community supported)
- Free plugin with commercial support available *
- Freemium that can work without paying *
- Freemium that cannot work without paying (having 3rd party services or something) *
That way, people can choose more clearly to go for a plugin that has paid (or priority) support available and/of that doesn't.
As for HQ, my company is not a Moodle partner at the moment, and until there is more clarity about a couple of things, I don't see that happing really quickly. Although, I wouldn't mind having to pay, like for example what Apple does with the development 'license' for being able to use the badges with the *. If for example, it's just 99 USD per year or something, it's not much, the plugin infrastructure might benefit from it, and all parties from all countries can pay an amount like that without it being too much or too little.
Although, as plugin developer, when paying, I would not only like to have the ability to use the badge, but also for example be able to have earlier access to certain roadmap elements or important changes that are likely to happen, or extra documentation on certain elements...
What do you think about that?
Kind regards,
Sebastian Berm
I agree with pretty much everything you said Sebastion.
So I will just speak to the point about paying money back to Moodle. I kind of think this is important. Mainly because otherwise we are freeloading. There is a cost associated with the review process and development /maintenance of the plugins database, not to mention Moodle itself. And it just seems fair that we contribute at least to cover those costs. There are flow on benefits too from being a revenue stream for Moodle, some of which you mentioned.
I personally like the idea of a "plugin partner" where you pay $X annually and pay back X% of turnover to Moodle. I really don't like the idea of payments processing on Moodle.org. So I would prefer, much like the existing partner program, an offline reporting and payments requirement.
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.
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.
Henning, I think the point you raise is quite interesting and important. And thanks for making it. The analogy to the app store free->premium is real. Thats exactly what I did with Poodll.
But I was very concerned about people upgrading from free into commercial unwittingly. Because I did not want that at all. Right up until the last minute I was considering distributing via ZIP files to avoid that. The issue is part of the reason I began this thread in the first place.
I considered, and ruled out, publishing alternate versions of the plugin with different component names. The disruption that would be caused to users by having to uninstall the old plugins then re install new ones, and do the configuration again would have been significant, and an obstacle to adoption. The whole thing would have been confusing and the related support would also have been overwhelming.
Prior to going commercial I built in a free registration requirement. That gave me a channel with which to communicate with my users. So I sent out a number of emails, posted blog posts and got publicity on Moodle news, that the transition to commercial was taking place. And I advised the users not to upgrade if they wished to stay "free."
Of course not everyone got the message and when users contacted me having upgraded mistakenly, I just passed on a valid registration key. So thats how I did it.
I think its likely that more than a few plugins which start out free, will go commercial. This is partly because of the greater demands on the developer to support and maintain their plugin through the different Moodle versions for free. And partly because of the financial advantage to the developer, who can then justify putting in more dev. time to add features and spend more time adding quality to their plugin.
Not everyone will think this is a good thing, but I think its win - win. So I don't think that we should discourage developers from taking their plugins commercial, nor should we put blocks in the way of users from upgrading into commercial. I think that the best way to avoid mistaken upgrades from free to commercial versions of the same plugin, is to add warnings in the upgrade process and the option to "permanently forget" upgrade to commercial notifications.
We also have few plugins which are free right now for several reasons. We need feedback from people, we are still adding features, plugins are at beta state etc. To build such a service/plugin, it could take several years. I am not sure how to best handle these cases, maybe also separate cases which require external services (cloud) or are freemium?
Reopening this discussion thread by request...