Future direction of BoxBilling

[John-S4]

Discussed in #933

^{Originally posted by John-S4 August 7, 2021}
I think that the direction of this software is currently a little bit unclear, and I am curious what other people actually expect or want from it.

At the moment it seems to not really know what it wants to be.

I guess essentially the question is whether people are looking for a big piece of software that does everything, or a light framework that does all of the core functions really well, and is easily extensible with additional 'modules', 'plugins', or whatever you choose to call them.

Personally I would like to see it move towards the second of those options.

For example:

• I don't think that file manager belongs in there - I think that is something for a server control panel, not for a billing and client management portal.

• I also don't think that the forum should be installed by default, if it is there as part of the core at all then it should definitely be an option on install. It's far from the best forum solution out there and I think it would be better to have nice integration with something better if you want a forum at all.

It would be good to ship with a limited number of payment integrations, control panel integrations, etc. and have a clear well-maintained repository of others that can be added.

What are your views on what you want from BB and what direction the codebase should go in?

[BelleNottelling]

• I don't think that file manager belongs in there - I think that is something for a server control panel, not for a billing and client management portal.

Done as of last night ;)

Now, in my opinion BB needs to be a solid, stable core that provides the essentials for most people out of box, with the intent that extra features can be loaded in via extensions.

Core:

• Billing, invoicing, and maybe ticketing
• Server management and control panel integration for a handful of popular control panels
  • Extensions available for others, these would probably be community maintained
• Well tested payment gateways that are maintained, VS the current option which is many, untested and unmaintained gateways
  • Thinking PayPal, Amazon Pay, and Stripe would be some good out of the box payment gateways
• Regular security and update patches to ensure the core is always a solid foundation people can grow upon

Optional:

• Forums
• Knowledge Base
• Possibly the ticketing system

Extensions:
I believe that extensions should more-or-less be community maintained. That doesn't mean we won't contribute, but in my opinion it's our job to provide a really solid core first and then anything else comes secondary. If an extension is part of someone 's business, I don't think it's unreasonable for them to pay a developer to maintain it, especially since most are probably integrations with pre-existing services or fairly simple, I don't think it would cost the person all that much money.
Therefore, I feel that building and maintaining the core application while providing good documentation for anyone who wants to write their own extension should be enough in most cases. - This is probably the opinion that will get the most argument, but I'm happy to hear people's thoughts

[evrifaessa]

Hey guys, sorry that I don't have active time to dedicate to the development part. I have a working schedule that only keeps me some free time in the late evening, so I can't really help much for now.

Anyways, I also think we should make a bulk cleanup in the core. For example, as you also said, file manager shouldn't really be a part of the core of a "billing system". Keeping some unnecessary extensions a part of the core repository makes it hard for us -the core maintainers- to maintain, maybe we could just split them from the core, possibly to their own dedicated repositories for each extension, or remove some extensions at all.

Community should have a larger role at the extensions that core maintainers don't have time to maintain, and we should get the extension store up and running again. That way, it'll be easier to maintain the core.

To sum up, I agree with @BenNottelling and @John-S4. I'll try coming for help whenever I get to find some more free time. Good luck :)

[BelleNottelling]

we should get the extension store up and running again.

Agreed, I was thinking about this today and I think we could actually do this from the extensions repository.
Thoughts:

• A master or development branch for testing and development.
• A stable branch for actual extension releases that are stable and bug free
  • This branch should include a "db" file file, perhaps in a json format
  • This file could include the name of every extension, the current version, a description, and URL for another json file that has all of the specific data for that extension.
    • Not completely sure what all info would be needed, but it should at least have a list of all files and appropriate location to update it from. Here's an example assuming the extension has 3 files. core.php, request.php, and handle.php.

branches{
   stable{
     "version": "1.0.0",
     "files": "StableFiles"
   },
  development{
    "version": "dev",
    "files" "DevFiles"
  } 
}

StableFiles{
   "core.php": 'https://raw.githubusercontent.com/boxbilling/extensions/stable/example/core.php',
   "request.php": 'https://raw.githubusercontent.com/boxbilling/extensions/stable/example/request.php',
   "handle.php": 'https://raw.githubusercontent.com/boxbilling/extensions/stable/example/handle.php'
}

DevFiles{
   "core.php": 'https://raw.githubusercontent.com/boxbilling/extensions/master/example/core.php',
   "request.php": 'https://raw.githubusercontent.com/boxbilling/extensions/master/example/request.php',
   "handle.php": 'https://raw.githubusercontent.com/boxbilling/extensions/master/example/handle.php'
}

We could have BB pull all of these files straight from github which can help avoid issues like where we're at not with a broken boxbilling.com website and old installs that are still linked into it.
I'm sure I got the formatting wrong on that code example, but I feel like a solution similar to this could work.

Also, I'm glad to see you come by and be active, even if it's just for a bit :)

[Tenebras50]

I have tried few months back to put this project back on track poking people a bit to see if there was interest but havent received any positive confirmation as of yet,

Think the problem as of now there aint a track of what need to be done. the priority and whos assigned to what if anyone

Without that organizing anything will be very difficult for anyone even if they willing to contribute.¨

I also support the basic core fuction, Some main billing module, Few domain reseller api and a ticket system, Rest it can be developed by the end user / company pvoided the documentation for doing that does exist.

[BelleNottelling]

@Tenebras50 Hi, if you're interested in helping with BoxBilling's development feel free to join the slack and talk to us https://join.slack.com/t/boxbilling/shared_invite/zt-w8gkztcx-9iz0WtV7OrKbVgrUSKZKsA

[BOT-Neil]

Can you add a pterodactyl intergration

[evrifaessa]

Can you add a pterodactyl intergration

Probably not. You are free to create and maintain the services you wish to have support for.

We're already having troubles maintaining the stability of the core and none of us are probably willing to maintain any custom adapters integrations in the future.

[bradjtrammell]

I don't think that file manager belongs in there - I think that is something for a server control panel, not for a billing and client management portal.

Personally I have to disagree. The less a user has to go into the control panel the easier it is for them to use. For a billing system, you should have the option to do everything you can do from the control panel (within reason). It makes it easier for novice customers to manage their website like a professional, but from the billing system, one they are maybe a bit more familiar with.

[evrifaessa]

Personally I have to disagree. The less a user has to go into the control panel the easier it is for them to use. For a billing system, you should have the option to do everything you can do from the control panel (within reason). It makes it easier for novice customers to manage their website like a professional, but from the billing system, one they are maybe a bit more familiar with.

We're talking about the core functionalities of BoxBilling here. As a maintainer of the core, I personally don't want to (and don't have to) maintain something that does not have to be in the core.

Side functionalities like this one can be achieved with extensions. It's just unfair to put all the burden on our shoulders.

Do you want to integrate your not-so-popular server manager to BB? You can.

Do you want to implement a file manager to a billing panel? You can.

But I just want to keep the core functionality as simple as possible to avoid BoxBilling dying as it did back in time.

It's not easy to maintain sanity inside the project when things change.
We're still using an old version of Twig, a version of jQuery from 2011 (wow) and lots and lots of outdated dependencies with probably tens of vulnerabilities.

In short, I don't want to add complicated and useless stuff before getting to a stable place. I don't like working with stuff from a decade ago, and I also doubt other developers out there would love trying to revive an old system like this. So if you're not going to help me do this, please don't expect me to do all this stuff by myself.

However, thanks for expressing your opinions. I appreciate it.

[bradjtrammell]

We're talking about the core functionalities of BoxBilling here. As a maintainer of the core, I personally don't want to (and don't have to) maintain something that does not have to be in the core.

I couldn't agree more. No where in my statement did I state that it should be a core function, however nor did the OP say anything about it being core or not, but saying it doesn't belong at all is a statement I disagree with. Most certainly not as a core function. I will say, as I get more familiar with the system, I plan to assist in development. I've never used the system, but always seen it's potential as a great piece of software.

I am doing my research on the best way to develop for BoxBilling, as I don't know if once it becomes stable, coding will change or anything like that, so I prefer to take my time, learn the system, and grow as a developer along with it, then start coding for it. As we all know, as systems mature, they change framework. I don't know if that's a plan for this project, but as it was so out of date, I can imagine certain things about it will change.

[evrifaessa]

@bradjtrammell I appreciate the nice reply :)

Yes, there definitely will be a lot of changes and rewrites in the future. We need more developers/reviewers for the project. I'd love to see you in the team :)

I'm also a junior developer, so don't worry about being a beginner. We all will learn and teach each other along the road. We all try to review each other's code before merging them, so even if you don't want to start developing right away, you can help by reviewing PRs and expressing opinions about issues.

[bradjtrammell]

I'm also a junior developer, so don't worry about being a beginner.

I wouldn't consider myself a beginner. Ha. Far from it actually, I've been coding PHP for what feels like forever. Just never coded for BoxBilling, so it's new to me. I have it installed on a crash box, so I'm looking it over to see what way would be best to contribute. I'd love to see some extensions for some lesser known panels, and maybe an affiliate system. Perhaps I can start with that.

Tried to send you a DM on Twitter to touch base on what needs to be done, but wasn't able to do so, is there a discord for this project?

[evrifaessa]

I wouldn't consider myself a beginner. Ha.

Awesome! We definitely need more experienced people in the project :)

Tried to send you a DM on Twitter to touch base on what needs to be done

Tell me your username, I'll follow you

Is there a discord for this project?

Yeah. There you go.

[John-S4]

Hi @bradjtrammell, nice to see someone new with idea and opinions taking part in the discussion :)

As the OP, I just want to clear up my point about file managers. I still stand by my opinion that a file manager really doesn't belong in a product like BoxBilling. I simply see billing and client management as one thing, and server management (which would include a file manager) as something else.

Having said that I also think that the whole point is to have a flexible and extensible framework so that BB can be used for different purposes and with different workflows by different people. I would never use it, but I'm absolutely not against there being a file manager module as an extension, my original point was that it has no place in core.

[timothygwebb]

I am in agreement unless we are building a framework to include server manager in core and not as an extension then anything server manager related should not be in core. Unless we plan on supporting all framework including ones such as https://pterodactyl.io/ and many others then anything server manager related should not be in the core.

…

On Sat, Oct 23, 2021, 3:34 PM John @ S4 ***@***.***> wrote: Hi @bradjtrammell <https://github.com/bradjtrammell>, nice to see someone new with idea and opinions taking part in the discussion :) As the OP, I just want to clear up my point about file managers. I still stand by my opinion that a file manager really doesn't belong in a product like BoxBilling. I simply see billing and client management as one thing, and server management (which would include a file manager) as something else. Having said that I also think that the whole point is to have a flexible and extensible framework so that BB can be used for different purposes and with different workflows by different people. I would never use it, but I'm absolutely not against there being a file manager module as an extension, my original point was that it has no place in core. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#934 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD24K7PA3HGUZFL42BR32N3UIME3LANCNFSM5BX7ICQA> .

[gOOvER]

Absolutely agreed with topic starter. Project will be easier to develop if it becomes modular. But what's with technical part?

Some time I thinking how could be install Boxbilling extensions with composer require organisation/repository, but don't dig the code for that. Anybody have ready idea about this?

p.s. Project need the official roadmap!

Why using composer for plugins? I think this is not needed. In my eyes too big a security risk. Not 1 big project use composer for installing plugins & Addons. An own Extesion System is better. I love the way, how Woltlab handle plugin/extension installs

I agree with you and the opinion of the creator. At the moment, everything is a bit confused because there are no clear structures.

There is definitely a lack of a roadmap here.

What is really needed is first of all a community structure:

• Projectleader
• Devs
• Docu Team
• Community Manager
  • Community Team

With a strict division of roles, some things are better. I was community manager for VHCS/ispCP/i-MSCP for almost 10 years.

[jaapmarcus]

What is really needed is first of all a community structure:

• Projectleader

• Devs

• Docu Team

• Community Manager

  • Community Team

Please keep it small.. Unless you have have xx active contributors it makes no sense to set it up. Keep it small and flexible. Maybe in the future it is needed but currently not...

Why using composer for plugins? I think this is not needed. In my eyes too big a security risk. Not 1 big project use composer for installing plugins & Addons. An own Extesion System is better. I love the way, how Woltlab handle plugin/extension installs

I agree with you and the opinion of the creator. At the moment, everything is a bit confused because there are no clear structures.

Grav CMS, Magento all work with composer.. It has the advantages / disadvantages

[gOOvER]

What is really needed is first of all a community structure:

• Projectleader

• Devs

• Docu Team

• Community Manager

  • Community Team

Please keep it small.. Unless you have have xx active contributors it makes no sense to set it up. Keep it small and flexible. Maybe in the future it is needed but currently not...

Lesser people, means lesser support. Boxbilling have a, sry to say shit reputation, from the last owner. See how he act, when people talk about to remove that shit registration in an opensorce Project.

Why using composer for plugins? I think this is not needed. In my eyes too big a security risk. Not 1 big project use composer for installing plugins & Addons. An own Extesion System is better. I love the way, how Woltlab handle plugin/extension installs
I agree with you and the opinion of the creator. At the moment, everything is a bit confused because there are no clear structures.

Grav CMS, Magento all work with composer.. It has the advantages / disadvantages

Grav is not really big :D

[jaapmarcus]

What is really needed is first of all a community structure:

• Projectleader

• Devs

• Docu Team

• Community Manager

  • Community Team

Please keep it small.. Unless you have have xx active contributors it makes no sense to set it up. Keep it small and flexible. Maybe in the future it is needed but currently not...

Lesser people, means lesser support. Boxbilling have a, sry to say shit reputation, from the last owner. See how he act, when people talk about to remove that shit registration in an opensorce Project.

I never have any experince with Boxbilling and personally don't use it my self. So I don't really care what route the developers are going..

How ever I have experience with Hestia / Vesta and Vesta happend the same thing until they decide to "drop" 1.0.0 and it is still broken. Vesta was dead we had at least 100 / 200 switchers a month.. And we Hestia grew from 2k users 2 years ago to about 20k currently. Even without an "Documentation" / Dev / Translations manager it still possible...

There are issues:

1. There is a limited number of persons who are willing to invest a lot of time/money into a project
2. Users that are available have limited time
3. There is no backup for users if they fall out... for any reason there need to be users available who can take over the jobs..

I think the focus for Boxbilling need to be on a "stable" build first instead before rigging up a full "staff"

And it makes sense to set a "point" so where Boxbilling need to "be" and it makes maybe a sense have a public roadmap for it.. Consider "removing" some current features as forum, FAQ and so on will not hurt... Boxbilling doesn't need to be a one trick pony that can be everything. It takes a lot of time to make it perfect for every thing... Keep in mind that maintainability in the future should have priority...

[GatoVuelta]

Are applications open? 👀

[BelleNottelling]

Are applications open? 👀

I mean, nobody is going to be paid anything but we welcome contributions

[m4rkstevenson]

I've used Boxbilling since the early days when Hosting24 were giving away free licences (I'm pretty sure, the same licence still in my unmodified bb-config file).. I'm glad to see some interest in developing this and I think the most important thing is providing a stable platform that supports the most common server panels and payment providers. I'm no dev, far from it but I'm committed to this project... mhosting.co.uk has been riding on it for years lol

[evrifaessa]

I've used Boxbilling since the early days when Hosting24 were giving away free licences (I'm pretty sure, the same licence still in my unmodified bb-config file).. I'm glad to see some interest in developing this and I think the most important thing is providing a stable platform that supports the most common server panels and payment providers. I'm no dev, far from it but I'm committed to this project... mhosting.co.uk has been riding on it for years lol

Thanks for your input. Even if you're not interested in contributing to the source code, I'd love to see you in our Discord server.

We're trying to keep in touch with our old and new users and shaping the future of the project depending on their opinions. If you're also interested, click here. :)

[Mkoje]

So I would like to integrate some part of boxbilling on my web... I started a reseller hosting web and needed to just add the payment and integrate it to work with my site... unfortunately boxbilling over rights every other content on my site changing my navbar, footer and showing all the boxbilling content... I have tried to find a way to edit all that out with no success. Can someone help?
I mean I just want the domain search, pricing and creation of a cpanel from boxbilling, I have tried to get a tutorial or documentation with no success

[John-S4]

Not 1 big project use composer for installing plugins & Addons.

Flarum (forum software) does it very successfully.

[evrifaessa]

Flarum (forum software) does it very successfully.

Hey @John-S4 , welcome again. We've decided to continue the project under a new organization and had new people joining the team. I'll grant your Discord account access to the team channel, please join the conversation, we're forming the future of the project together.

[tobsowo]

Please can you add me to the new organization I will like to keep updated and see how I can contributed regarding no-code.

[Neustradamus]

@tobsowo, and all: It is @FOSSBilling:

• https://github.com/FOSSBilling

[tobsowo]

Thank you

[xaoseric]

Hi,
Just looking at this project as I've used BoxBilling in the past. Perhaps it might be a good idea to create a boxbilling/framework repository which would hold the core, and use this repository to hold the skeleton and require boxbilling/framework similar to how Flarum (https://github.com/flarum) is structured.

[evrifaessa]

Hey @xaoseric. We're moving. See https://github.com/FOSSBilling/FOSSBilling. You can also join our Discord server using this link.

[John-S4]

As the original poster of this discussion, I feel it is appropriate to also bring it to a close.

Many things have changed since my first post here. While the BoxBilling project still remains as is, several of the people who were most recently involved in it, including myself, have chosen to depart from it and to create a new project forked from this one, which we were unable to take in the direction that we felt was needed.

You can find that at https://github.com/FOSSBilling/FOSSBilling

I'm going to go ahead and lock this conversation now, since I believe, for me at least, that the future is no longer in this project but in FOSSBilling.

Both projects have merit and we can only hope that both will continue to grow and succeed because there is no such thing as too many options when it comes to open source software.