[PROPOSAL] Require plugins to be uploaded to Plugins repo

Lately I’ve been thinking more and more about a rasing issue about plugins.

The fact is that on the development thread there are a lot of third party plugins available (and this is awesome!), however when someone goes to the plugin facility built into volumio, there are really few plugins there.
At first we tried to solve this by creating the plugin helper, which makes it super easy for people to create and then publish the plugins on the repo. However the situation has not been changed much really.

This concerns me because I would find more user-friendly if plugins could be downloaded directly from the Volumio plugin facility, instead of going to find them into the Forum.

The second issue is that I see more and more plugins that are crashing the whole Volumio, sometimes for bad practices, some other times for mistakes that could have been avoided by requiring a bit of review by the core team. My fear is that the unstability of those plugins is undermining the Volumio experience for some.

Therefore I am thinking to solve the above two issues by disabling the plugin uploader of Volumio, and require plugin developers to submit their plugins to be published.
This will bring the following benefits:

  • Users will immediately find the plugins that are available directly inside of Volumio
  • When a plugin gets updated by developers, users will be able to update it inside Volumio (not possible with plugin packages)
  • There will be a review done by the team before publishing a plugin, ensuring its stability and that it does not break Volumio installs
  • This will make plugin management and discovery in one place, putting the bases for the plugin shop (a feature we are thiking since some time, such as the possibility for developers to choose if their plugin is free or paid, something like an app store)

The downsides are:

  • There will be some delay before the publishing of a plugin from a developer, and the actual visibility in the plugin facility (since the review will take time, and there might be some back and forth between the developer and the Volumio team to optimize it).
  • Some will see it as Volumio getting “more close”

So, looking forward to what you guys think. Suggestions? Ideas?

Hi!
This is a great thing for volumio!
It was something problematic finding plugins.

But we lose the advantage of wide user base for testing. Even if I’m confident in volumio team, sometimes issues only occur with a combination of hardware or even software. How without a testing phase with certain users to be sure everything will work as expected?

I’m waiting for this new feature! Good job!

Definitely the first. This is how I was expecting community developed plugins to be made available. Of course, this makes them officially sanctioned, so they would need some sort of quality control.

Disabling plugin uploads is quite a big step. How will people test plugins, and what about people who want to tinker with custom plugins that might not have general interest? Perhaps better education of users (“use uploaded plugins at your own risk”), and a separate forum section would help.

As an end user, this would be a huge improvement to have all the plugins directly available into Volumio.

An end user will never know that’s the plugins that crash. He will come to the conclusion that Volumio is not a finished product.

Introducing delay between the posting by a plugin dev and the visibiliy by the end user is totally acceptable. Although, this could introduce some frustration on the plugin devs side.

Enlarging the devs circle by naming some additionnal “trusted devs” among plugin devs could speed up the review process though. Some of them did a tremendous job working on additional features missing in Volumio core.

Anyway, thanks to all the community. You’re doing an amazing work on Volumio (and plugins :p)

For the majority of users, getting quality plugins for “store” is good, and expected experience (as long as it never becomes linked to some service plan obligation).

Maybe we can just keep the plugin install within /dev page, but remove it from main part of UI (anyway, we still did not find why bogus uploads&install happens twice for a long time).
Keeping it in /dev page will obviously signal adventurous users that if they install that way, they do something not supported.
Developers will still have a way to develop, test and call for advanced users tests.

Now, in parallel, I think we need to make sure there is some sort of review-time commitment towards developers for feedback by plugin maintainers.
Would sth like 1 week acceptable?

Or using the /dev functionality to allow beta plugin install to make early community testing possible

Sent from my iPhone using Tapatalk

I’m totally up for filling the store with plugins that have at least a BETA status. This makes it easier for many people to test and submit issues.

I’ve found that supporting the plugins takes more time and effort than building them, this is why I’ve tried hard to submit readme’s with explanation to clarify stuff. However in the store, people are not likely to read anymore, whereas the github page should invite to read a bit. If the plugins are in the store, remember people will ask the Volumio team for help, rather than the plugin author. At least, that’s what I think.

If the upload is to be disabled for the majority, then please make it still possible in dev mode. I always test the installations a few times before committing on github.

I must also admin that I have not looked into the plugin helper function, I’ve been quite busy just maintaining the plugin itself. Also, I’ve been busy figuring out github and how to use it like it’s designed. I still take many shortcuts out of laziness (incomplete commit texts etc.).

From a developer perspective the disable of the upload is killing, but I can imagine it’ll force some order in the wild growth of plugins (and their respective versions). I do like the update function that comes with the store, this should help iron out bugs that have been found easily.

In short, I think the hybrid version is the way to go:

  • dev mode allows for the upload of plugins

  • ‘normal’ mode only allows the users to use tested and published plugins

You can opt to making it a little (not too for me please) hard to enter dev mode, as a precaution, else everyone will run dev mode because it allows for all the newest plugins, gadgets, widgets etc. and there’s no down side.

And finally, I’m no developer, so there’s no clear pattern that I follow (which frustrates me sometimes). Because I want too much in too little time… So a code review might iron out bugs that I have missed, or even optimise the code I’ve written. :unamused: I’m definitely in favor of code reviews and testing done by people who understand the code and have an idea of what is happening. This makes it easier to debug too, because the reviewers can supply you with the relevant logging. :wink:

Thank you guys for the very constructive suggestions. I feel we can make the most balanced decision together.

Some very interesting points were made:

  • Sometimes plugins may crash in rare circumstances, so having a bit of field testing is always a good thing.
  • Developers want an easy way to test their plugins
  • We need to ensure an high quality standard of plugins
  • Some skilled dev can help the team to review the plugins
  • Supporting plugins is the real deal, and we need to get feedbacks from users

We could do the following:

  • To properly encourage high-quality development and controlled environment, we can disable the upload function (everybody agrees on that)

  • Adding a function to plugin helper that allows the install of a plugin. This will simulate the same install from the repository, so devs can simply launch this command via SSH and install the plugin as it was downloaded. This should be enough for the casual user to not get in contact with early or unstable code but will be ok for most of our users to type some commands in SSH and test a plugin (and those more-than-average skilled people can also revert a potential crash while in SSH), and the devs can properly test their plugin before submitting.

  • Forcing people trough the plugin-helper will also help us standardize and optimize plugin creation, publication and testing.

  • The DEV mode will work for plugins as well, allowing to download and test beta releases of an already installed plugin (this will come probably later, as lot of backend code is involved)

  • If there is any volunteer within skilled plugin developer, wishing to help us review the plugins, that would surely increase our approval speed (and will be a tangible help)

  • We could insert a rating function in the plugin facility and a way to signal an issue directly to the developer, to streamline issue detection (long term plan as well, as lot of work is required)

What do you guys think? Are there other actions which might improve the situation?

PS: For the pending PR on plugins, I am committing to review and publish asap
PPS: This can be a good time for developers who think their plugins are ready to be published to send us a PR. See here how to do it:
volumio.github.io/docs/Plugin_S … lugin.html

I would suggest looking at other successful open source projects and how they approached plugin management. Wordpress is a good example - with an ecosystem of over 50,000 plugins.

developer.wordpress.org/plugins … uidelines/

I like the idea of letting users rate plugins, displaying the number of downloads, having some kind of approval badge, user comments, etc. And the notion of separating a directory of approved plugins from the ability for people to upload any plugin (not in the directory) they want.

The Drupal project has the notion of contributed modules, which are somewhat like plugins, and there’s over 30,000 of them. Again, they show the number of downloads, active sites using them, etc. But they also have a group that validates the security of a subset of the modules.

In both of the above cases, users are free to install any plugins they choose, from any source. But they also have guidance regarding “vetted” plugins.

Agreed.

Team Kodi does a great job also:

Another thing I’ve been having trouble with is the platform, not all plugins work on all platforms.
This is something the store will have to sort out too, if a platform is not supported, the plugin needs to be hidden.

Some examples:

  • Kodi; the repo I have added probably doesn’t work for x86 (or anything else than armhf really)
  • Snapcast; should be supported, but I’m not sure, since you’ll probably have to build from code (not my forté in Linux)

And there are probably many more examples you can think of. We might even want to split the packages to reduce size and script for the different platforms. Just thinking out loud here…

I have to say I appreciate the move to get a bit more structure into the currently rather chaotic set of plugins.

In my opinion it would be perfectly fine to not be able to upload plugins yourself from the plugin section. It is however crucial to be able to upload from the /dev page.

I would suggest to adopt some features of Apples AppStore:
If users like to test plugins before their official publication, they can register as beta testers. Whether it is on a per app basis or in genera … don’t know.
Furthermore, the plugin (package.json?) should specify on which platforms it is known to be supported. In the plugin section you can then select whether you only want to show plugins for your platform or all. Just like in the AppStore on iPad you can select whether you want apps optimized for iPad or also for iPhone. If you select the latter you must expect it not to work properly.

Maybe we could use something like github.com/dkhamsing/new_issue (5 sec google, maybe there exist better options) to streamline github issue creation directly from within volumio. Using a dedicated Volumio issue account, users would be able to just enter a problem message and the script would be adding some more informations about platform, build version, etc. and create a Github issue. This would simplify bug tracking for both sides, in my opinion.

Ok, today we’ve implemented a way to simulate a real install (and therefore to install :smiley: ) from the plugin helper.

This way devs would have an easy way to try their plugins and to install them :wink:

Just go into the folder where the source of the plugin is and type:

volumio plugin install

More info:
volumio.github.io/docs/Plugin_S … lugin.html

This will be part of next release, due soon

I also posted a call to action for all plugin developers to start publishing their plugins:

To all plugin developers: in order to streamline the plugin discovery process and make life easier for our users, please start publishing the plugins which are reasonably stable. You can do it easily with the plugin helper. See: volumio.github.io/docs/Plugin_S … lugin.html

Once you send the Pull Request, your plugin will be reviewed and eventually published for all the available platforms.
More info: require-plugins-uploaded-plugins-repo-t8

Thanks to everyone contributing :wink:

Hi, your link is shocking me :smiley:

On the topic of plugin development, would it be possible to avoid having the clone the entire volumio plugin repo for some simple dev work?
i.e look into keep each plugin in its own repo à la Atom packages which is based on npm.

This would really help in making issue reporting and general package maintenance much more stream lined.

I agree with most points in here. It would be good to have more consistent quality of the plugins and more plugins in the store.

I have been a bit inactive on here, meaning the development is at a standstill but I try to give support and make sure the plugin still works when volumio is updated.

The new plugin helper looks interesting. I have a question however; does it support selection of architectures? If a plugin is only for some platforms and doesn’t work for others?

I’m also very much in favour of more plugins via the Volumio plugin page. I have tried out one or two plugins from the forums in the past, but some installation issues and doubts about quality and updates makes me reluctant to try again.

A reviewed and approved set of plugins installable via the Volumio web interface would make life much easier for the majority of users, who, I think, often don’t even know exactly what variety of great plugins is available.

BTW, an (auto-) update mechanism for the plugins would be essential.

(Someone who agrees :wink: multiroom-and-synced-multiroom-should-built-t8264.html)

I am happy we are all converging to a common goal.
I’ve invited devs to submit their plugins to the repo, but so far no joy… I think that the removal of plugin upload will happen in next release, and hope that will give the extra bit of motivation needed.

2 questions on new release & enhancements:

  • will install from Volumio2 /dev page be also possible?
  • will pluginhelper allow developer to resume plugin development from a new/reset Volumio2 install (i.e not create a new plugin, but pull an existing one to do further work on it)
  • No, but plugins can be installed from command line
  • Yes absolutely