Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Future direction of BoxBilling #934

Closed
John-S4 opened this issue Aug 8, 2021 Discussed in #933 · 34 comments
Closed

Future direction of BoxBilling #934

John-S4 opened this issue Aug 8, 2021 Discussed in #933 · 34 comments
Labels
needs discussion

Comments

@John-S4
Copy link
Contributor

John-S4 commented Aug 8, 2021

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
Copy link
Collaborator

  • 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
Copy link
Collaborator

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
Copy link
Collaborator

BelleNottelling commented Aug 8, 2021 •
edited

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 :)

@evrifaessa evrifaessa pinned this issue Aug 9, 2021
@BelleNottelling BelleNottelling mentioned this issue Aug 24, 2021
Open
@Tenebras50
Copy link

Tenebras50 commented Sep 2, 2021 •
edited

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
Copy link
Collaborator

@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
Copy link

Can you add a pterodactyl intergration

@evrifaessa
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

@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
Copy link

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
Copy link
Collaborator

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
Copy link
Contributor Author

John-S4 commented Oct 23, 2021

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
Copy link
Collaborator

timothygwebb commented Oct 24, 2021 via email

@timothygwebb
Copy link
Collaborator

timothygwebb commented Oct 24, 2021 via email

@bradjtrammell
Copy link

@evrifaessa is there any current API documentation that exists? Or would it still be similar to the previous API documentation?

I would like to see about starting to test out some extensions for Server Management.

@timothygwebb
Copy link
Collaborator

@evrifaessa is there any current API documentation that exists? Or would it still be similar to the previous API documentation?

I would like to see about starting to test out some extensions for Server Management.

@bradjtrammell @evrifaessa This documentation needs updating but here is the only location I know of as current regarding all API, Server Manager, and BoxBilling. If either one of you need support please directly contact me @timothygwebb.

https://docs.boxbilling.org/en/latest/

https://docs.boxbilling.org/en/latest/reference/service-hosting.html

https://docs.boxbilling.org/en/latest/reference/extension.html#extension-server-manager

https://docs.boxbilling.org/en/latest/reference/api.html

https://docs.boxbilling.org/en/latest/reference/api-guest.html

https://docs.boxbilling.org/en/latest/reference/api-client.html

https://docs.boxbilling.org/en/latest/reference/api-admin.html

@evrifaessa
Copy link
Collaborator

@evrifaessa is there any current API documentation that exists? Or would it still be similar to the previous API documentation?

I would like to see about starting to test out some extensions for Server Management.

Our documentation was last updated somewhere between 5 and 10 years ago. Even though, some of the stuff there might be up-to-date. I'd directly look at the code-base as we're trying to document every function right in the code-base.

@evrifaessa
Copy link
Collaborator

Also, you can check the "CWM" manager as @BenNottelling recently wrote and tested it. It may be the only nearly-fully working server manager.

@BelleNottelling
Copy link
Collaborator

Yes, when I wrote the CWP server manager everything was working as it should with it. Except for one specific API function which to the best of my knowledge is just my server not working correctly, not the BB integration.

This is the code for it https://github.com/boxbilling/boxbilling/blob/master/src/bb-library/Server/Manager/CWP.php and personally I'd point people to that as a starting point / template since it's the only manager that I know is up to date.

I based it off of the "custom" manager and a few of the other ones we had in our source. Minus some old or deprecated PHP functions being used they were helpful just as something to base my work off.

The documentation is likely still 90% accurate, there haven't been a lot of changes.

On the subject of our out of date / unmaintained documentation, I think we should consider stuff like doxygen.
It's more likely someone is to update the documentation at the top of the function they are updating rather than docs in an entirely separate repository.

Then I'm sure we can have it auto update with CI on every commit to master, or just manually update them every once in a while

@evrifaessa
Copy link
Collaborator

I like the idea of documenting functions and classes right inside the code and generating documentation pages off of them.

We can use phpDocumentor for that:
https://phpdoc.org/
https://docs.phpdoc.org/3.0/guide/guides/docblocks.html

@Neustradamus
Copy link

@John-S4: Thanks for this issue, I have not seen before...

@John-S4
Copy link
Contributor Author

John-S4 commented Nov 21, 2021

@John-S4: Thanks for this issue, I have not seen before...

I have not been around very much over the last months since I created this issue, I had planned to be a lot more, but have not been able to for personal reasons.

There is definite activity from other people though and the codebase is moving forward. I just think it all becomes a lot easier and clearer if there is an agreement about the direction that something is heading in, rather than everyone trying to do things in their own way and submitting pull requests that pull things in different directions and contradict each other.

@andpavlenko
Copy link
Collaborator

andpavlenko commented Apr 7, 2022 •
edited

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!

@gOOvER
Copy link
Contributor

gOOvER commented Apr 7, 2022 •
edited

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
Copy link
Collaborator

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
Copy link
Contributor

gOOvER commented Apr 7, 2022 •
edited

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
Copy link
Collaborator

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
Copy link

Are applications open? 👀

@BelleNottelling
Copy link
Collaborator

Are applications open? 👀

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

@m4rkstevenson
Copy link

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
Copy link
Collaborator

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
Copy link

Mkoje commented Apr 19, 2022 •
edited

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

@Coo-ops Coo-ops converted this issue into discussion #1322 May 18, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Assignees
No one assigned
Labels
needs discussion
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests