The OPNsense Plugins System Situation

[Majx]

I would first like to thank the OPNsense team for all of their hard work and the consistent support they provide to the community.

I'm not sure whether this topic has been discussed before. I searched the forum but couldn't find a clear discussion about it. If this has already been addressed, I would appreciate being pointed to the relevant resources.

Introduction

Many of us invest our free time developing plugins for OPNsense.

From what I have observed, there are currently two ways to publish a plugin for public use:

• Host your own repository
  Developers can maintain a separate repository, host the plugin themselves, and provide users with command-line instructions to add the repository to their system. Once added, the plugin appears under System → Firmware → Plugins.
  
• Submit the plugin to the official repository
  Developers can contribute their plugin to the opnsense/plugins repository, allowing it to appear directly in the default OPNsense plugin list without requiring users to add external repositories.
  

Where Is the Problem?

If a developer wants their plugin to be easily discoverable by users, the most practical route is publishing it under the official opnsense/plugins GitHub repository. However, doing so requires compliance with the BSD-2-Clause license and effectively places the code under the project's governance and license. For some developers, this creates concerns about licensing flexibility and long-term control over their work.

On the other hand, publishing plugins in private repositories significantly reduces their visibility, meaning many users may never discover them unless they happen to find them independently and manually add the external repository to their system in order to install the plugin.

This creates a trade-off between visibility and accessibility versus licensing flexibility and control.

Possible Solution?

One possible approach would be to implement an official plugin registry or indexing system within OPNsense, enabling third-party developers to register plugin metadata (name, description, version, repository URL) and have these plugins displayed via the "Show Community Plugins" section of the GUI.

This approach would maintain developer ownership and licensing flexibility, improve the visibility of third-party plugins, and enhance the user experience. It would also strengthen OPNsense as a platform, since there are plugins that expand its capabilities currently exist outside the official repository and are not widely known. Furthermore, it could reduce maintenance overhead by enabling plugin-related issues and support to be managed by their respective maintainers instead of being centralized within the opnsense/plugins project.

I would be very interested to hear the thoughts of the OPNsense team and the community on this matter.

[franco]

> licensing flexibility

Hmm, you want to contribute 2-Clause BSD code? Sure. You want leeway? Nope.

Third party repositories reachable through the plugins are allowed for business partnerships. We only have one such vendor which is SunnyValley a.k.a. Zenarmor. Intentionally we avoid having non-reviewable binaries in our core, plugins and ports. The vendor repo plugins are the only way to deliver this natively to users. The threshold for another vendor repository are very high, not something for normal BSD license users to achieve.

The biggest issue with the plugin system at the moment is that we don't have enough time to vet PRs and submission and even cover the use cases of the plugins proposed. AI is used more and more to generate full plugins in a heartbeat. We will likely have to say "no" more than before to make time for other submissions.

On the subject of binaries... if you have the source code in the open addition to FreeBSD ports is the usual way to get it intergrated as a plugin because that adds peer review to the functionality and reduces risk over security concerns (now or in the future). In some cases binaries for OPNsense are allowed (ndp-proxy-go, opnsense-filterlog) because their scope is narrow or a trusted source on top of open source code (and the open source license there doesn't matter).

The question I'm asking me is how much non-permissiveness you want in a free product that ships your code?


Cheers,
Franco

[Majx]

Thank you for your reply Franco.

I believe there may have been a small misunderstanding and that I may not have expressed my point clearly enough in my original post.

> Hmm, you want to contribute 2-Clause BSD code? Sure. You want leeway? Nope.

I completely understand and agree that OPNsense is licensed under 2-Clause BSD and that any contribution to core, plugins, or ports must follow that same license. I am not looking for exceptions or alternative licensing inside the official repositories. The integrity of the project depends on consistency, and I respect that.

> The biggest issue with the plugin system at the moment is that we don't have enough time to vet PRs and submission and even cover the use cases of the plugins proposed. AI is used more and more to generate full plugins in a heartbeat. We will likely have to say "no" more than before to make time for other submissions.

Regarding the current pressure on the plugin system and the limited time available to vet PRs, I fully understand the challenge as the volume of contributions can easily exceed what is realistically reviewable. That is one of the reasons why I was thinking about a new structural separation instead of the current broad inclusion.

> On the subject of binaries... if you have the source code in the open addition to FreeBSD ports is the usual way to get it intergrated as a plugin because that adds peer review to the functionality and reduces risk over security concerns (now or in the future).

My proposal is not about introducing non-reviewable binaries into core. Instead, what I am trying to explore is whether plugin discoverability must necessarily require governance and code inclusion.

In other words, there could be a conceptual difference between "official plugins" that are reviewed, merged, and maintained under the OPNsense umbrella, and "community-listed plugins" that remain entirely owned and maintained by their original developers. These would not be part of the official repositories and not maintained by the OPNsense team. They would simply be discoverable through a structured registry mechanism inside the GUI. Installation could require an explicit opt-in action from the user, such as enabling a "community sources" section or confirming a clear trust warning, without requiring manual command-line repository configuration.

Such a separation would preserve the strict review standards and security model of OPNsense, while avoiding additional maintenance burden for the core team. It would also make the trust boundary explicit to users, for example by clearly distinguishing official plugins from externally maintained ones. That would provide visibility without transferring responsibility.

If even listing external plugins creates an implied endorsement that the project is not comfortable with, I completely understand that position. My goal is not to argue against the current standards, but to explore whether there is room for a middle ground between full integration and practical invisibility.

Thank you again for taking the time to respond and for making OPNsense reliable and trusted.

/Majx