This topic was started on FOSSBilling GitHub Discussions, and was moved to this forum on 17/03/2023. Original post authors and dates are preserved.
jaapmarcus - May 21, 2022
Before we restart deleting everything we need decide things:
In the Discord chat we had some discussion(s) regarding how we are going to maintain Modules:
Suggestion 1:
Keep as is
Suggestion 2:
Move each module to its own repo so:
For Server modules:
Cpanel: Fossbilling/serverCpanel
Directadmin: Fossbilling/serverDirectadmin
Hestia: Fossbilling/serverHestiacp
And so on
For Payment modules:
Paypal: Fossbilling/paymentPaypal
Stripe: Fossbilling/paymentStripe
For Domains modules:
Enom: Fossbilling/domainEnom
Off course we can decide to remove the underscore
For Modules that are not required for their core function:
KB: Fossbilling/KB
Forum: Fossbilling/Forum
ServiceHosting: Fossbilling/ServiceHosting
And "load" the required modules with composer / Provide prebuild packages with the "Core" of current FossBilling
Suggestion 3:
A mix of 1 and 2
Remove each server / payment / domain module to each repo. And do the same with modules that doesn't belogin in the core for example: SolusVM and other "Connection" modules but leave things like KB, ServiceHosting in place
Preference for me is option 2
BelleNottelling - May 21, 2022
I vote option 2
evrifaessa - May 21, 2022
If we can, I'd also want to go with the 2nd. We should also decide on the naming for the repos though.
John-S4 - May 23, 2022
I think the second option is the way to go.
Create a lean, stable, and extensible core framework that is not bloated and easier to maintain, then add things back in as modules/extensions which are separately maintained (although often by the same core maintainers) and can be added and removed as needed.
Composer seems a very sensible way to include modules and again is much easier to maintain than any kind of custom extension installer.
Flarum (forum software) is a really good example of a project that follows both of the above. The core is very light on features but does everything essential, and all other functionality is installed as 'extensions' using Composer. There are people on their forums moaning that x and y should be in core but the maintainers largely ignore that and stick to their philosophy of building something light and extensible and it really works. There are also people who complain about having to use Composer to install extensions but as long as there is clear and easy to follow documentation I don't see that as a problem at all.
0x6b-dev - May 23, 2022
And there’s nothing to stop people making their own modules outside of the core ones we provide.
And we can totally keep a table of official and unofficial modules that are endorsed by us.
But it’s important that we keep a rock solid set of core modules maintained by us. And if that means dropping a few of the lesser used ones, that will be worth it.
jaapmarcus - May 23, 2022
I think with the "move" to more separated "based" system it will be easier to allow "users" to write their own modules.
As a user just can run composer require jaapmarcus/fossbillig-hestia instead of download file and upload it to ....
John-S4 - May 25, 2022
I think with the "move" to more separated "based" system it will be easier to allow "users" to write their own modules.
Exactly, we just need to be sure to provide clear documentation, and probably also an example template for the most common extension types - server panel, domain registrar.
jaapmarcus - May 25, 2022
Everything stands by the documentation...
