Hello fellow members of the MOD Community
I bring good news to you all.
As many here know, we have lots of exciting plans and ideas regarding the Plugin Store. Commercial options, community generation and management, mixed models (paid open source) and so forth are some of them.
One of the launches we will do in the near future is the support for commercial plugins at the Plugin Store. The gears for these have been turning, albeit slowly, for some time and recently the pace got faster. We now have a developer dedicated to this task. More news on this is coming soon.
But this is not the actual reason for me writing here 
The reason for this message is to announce to you that we’re finally rolling down the processes necessary for the management and maintenance of the community plugins.
The main goal is to enable the co-existence of different models - commercial, free but officially supported and community managed - in a single ecosystem. It is quite a challenge to guarantee a great user experience while trying to maximize the communitary collaboration.
As a first phase, we’re avoiding any kind of technical implementation and focusing on the processes themselves. Once those are fine-tuned we can move on to further developments.
The processes depicted here apply to FOSS plugins generated by the community. No binaries or any kind of closed-source file are allowed in this framework.
The overview can be seen in this diagram:
First of all, we are renaming the former repositories - Stable / Unstable - to Official and Community respectively. Having a repository called “Stable” automatically names the other “Unstable” and this has proven to be quite misleading.
When a customer buys the MOD Duo, it will come with only the Official repository enabled by default and a subset of it already built in the device. Upon the release of version 1.5, users will be able to go into a “Settings” area and enable the Community repository.
The processes
As a directive, we are focusing on the initiative of the developers and also the community for these processes to work properly. We are going to rely on the forum a lot for the actual management and operation of them.
The following forum sub-categories are being created under the Plugins category.
Permanent categories for plugin feedback and user/developer communication:
- Official Plugins
- Community Plugins
Transitory categories for developer/MOD communication plus user feedback:
- Publishing
- Promoting
- Updating
The processes are:
1 - Publishing to Community.
This is the first step for a community plugin to get into the MOD ecosystem. The developer that wishes to have a plugin published will start the process by posting a topic in the “Publishing” sub-category containing basic plugin info plus what is needed to build it. Requirements for publishing are plain and simple:
- the code builds;
- the plugin loads on the Duo without breaking
The idea here is to use the forum topic as some sort of documentation. Getting these two requirements already involves a series of steps, from standard LV2 to the requirements of our build system, and we want this discussion between the developer and our team to be openly documented to serve as a reference for the other developers.
Once these two conditions are satisfied, the plugin will be published and an entry on the “Community” category will be created.
2 - Promoting a plugin
Again, the initiative to promote a plugin must come from a developer who is willing to maintain it. He will start the process by posting a topic in the “Promoting” sub-category containing detailed plugin info. Here’s an overview of the requirements for promotion:
- complete metadata
- stability and performance
- graphical Interface and usability
- community feedback and interest
- usefulness
Not all of these requirements are tangible and straightforward. One of the technical developments we are going to do is to add a rating system for the plugins (0 to 5 stars) to ease the voting from users.
Further details on these requirements will be pinned on the top of the Promotion sub-category.
While we see the audience of the Publishing sub-category to be mostly comprised of developers, for the Promoting sub-category we envision an audience of non-developers that will be providing feedback and comments for the Promotion process.
3 - Updating / Upgrading a plugin
Updating and Upgrading are not predictable, as it will depend on the size and nature of the changes. Again, the Forum sub-category will serve as a space to reach a conclusion on the procedure to be adopted in each case.
All of these processes are based on communication between a developer and member of the MOD Team. Our “Plugin Master Keeper” is going to be @jesse. Since we really want to scale this up without bottlenecks, Jesse will need to limit his actions to commanding the servers and instructing the developers. Once the process is established we will move to technical developments to have distributed credentials, but that will only happen in a later phase.
I also would like to point out the “organic” nature of such processes. We have ideas and beliefs on the performance of our proposed model, but optimum behaviour will happen only after some maturing time.
We count on the engagement of this amazing community towards building an incredible collection of open source plugins.
I wish everyone the coolest sounds ever!