Hi everyone,
Over the last several months, we have received an increasing number of
pull requests introducing new OpenSIPS modules. We are very happy to see
this level of interest and commitment from the community.
These contributions bring valuable features and integrations to
OpenSIPS, and we want to make them available to the community as quickly
as possible. At the same time, reviewing an entirely new module,
however, is substantially different from reviewing a focused change to
existing code. New modules may contain large amounts of code, unfamiliar
designs, integrations with external services, or code produced through
AI-assisted—or "vibe coding"—workflows. Fully understanding and
validating every aspect of such a module before merging it requires
considerable effort from the OpenSIPS core team and may significantly
delay otherwise useful contributions.
To address this, we are considering introducing a new concept in
OpenSIPS: the **Contributed modules**!
Contributed modules would be primarily maintained and supported by their
authors and the wider OpenSIPS community. The core team's involvement
would focus on best-effort build and integration supervision, including
licensing, documentation, build-system compatibility, and obvious
security or stability concerns.
This would allow valuable community work to become available sooner
while clearly establishing the corresponding maintenance and support
expectations.
Contributed modules would be kept under the `modules-contrib/` directory
in the source tree. Placement in this directory would represent a
different maintenance model from modules in the main modules/ directory.
Responsibility for implementation, external integrations, ongoing
maintenance, issue handling, and user support would remain primarily
with the module's authors and interested community members.
Contributed modules would not be built by default. They could be built
explicitly using:
`make modules-contrib`
To build all configured module collections, including contributed modules:
`make all-modules`
The proposed packaging model follows the same distinction:
* `opensips-modules-contrib` would contain contributed modules requiring
no additional external dependencies.
* ` contributed module requiring external dependencies would have its
own package named `opensips-module-contrib-<module>`.
Inclusion under `modules-contrib/` would not represent a complete audit
of the module's code, functionality, or external integrations. It would
indicate that the module passed the applicable integration checks, while
its functional validation and long-term maintenance remained
community-driven.
Issues and fixes would therefore be handled primarily by the module's
authors and users. A contributed module could later move into the main
module tree after gaining active maintainership, broader adoption,
sufficient review, and proven operational experience.
The proposed build-system and packaging implementation is available for
review in the modules-contrib branch:
* https://github.com/OpenSIPS/opensips/tree/modules-contrib
At this stage, this is an intention and a proposal—not a final decision.
We would appreciate feedback from contributors, maintainers, packagers,
and users, especially regarding any technical, maintenance, or
distribution concerns we may have overlooked.
If no significant concerns or showstoppers are raised, we intend to
adopt this model and finalize the implementation.
Thank you to everyone contributing code, testing modules, reporting
issues, and helping the OpenSIPS ecosystem grow.
Best regards,
The OpenSIPS Team
--
Răzvan Crainea
OpenSIPS Core Developer / SIPhub CTO
http://www.opensips-solutions.com / https://www.siphub.com
_______________________________________________
Devel mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
