It is not really a script.
Our install process starts with a script, but the script just detects the OS, sets up the OS repositories and installs the dependencies…all the work is handled by the yum groups or metapackages (for dependency installation) and virtualmin-config for configuration.
There is no reasonable equivalent to yum groups or metapackages on FreeBSD, AFAIK (though there has been a new pkg system introduced since I last tried to support installation on FreeBSD, which may provide something similar), and virtualmin-config would need some minor tweaks to work on FreeBSD. But, I would almost certainly reject any patches to make FreeBSD supported in our installer, even if it cost me no time or effort to include it.
The reason I stopped supporting FreeBSD (aside from the extreme lack of paying customers using FreeBSD) was because I couldn’t make it nice. Package management was an awful experience for a variety of reasons (no way to offer a third party package repo, for instance, which is absolutely necessary for us to sell Virtualmin Pro), ports are unpredictable in that it’s easy for changes to one package to break other packages. The straw that broke the camels back was finding that upgrading a system to current libraries from the OS repos broke Postfix, requiring a rebuild from ports (i.e. I had installed everything from binary packages, when possible, but then a later upgrade broke the OS-provided binary packages because Postfix didn’t get updated when libraries it depended on did). That happened enough times and with enough really important packages that I just couldn’t deal with the kind of support load FreeBSD generated when we made it easy. Every FreeBSD user/developer I talked to insisted that this never happens and that ports is infallible and superior to all other package managers, but, I could reliably reproduce all sorts of ugly problems, so…I found the responses unhelpful.
When FreeBSD is hard, we almost never hear from FreeBSD users because they know a lot about their systems. Most serious FreeBSD users are very good system administrators and they know how to use FreeBSD better than I do, so as long as it’s hard, we’re happy that there is a path for FreeBSD users to use Virtualmin. But, if I were to automate it, people who should not be using FreeBSD would begin using FreeBSD with Virtualmin, and we’d go bankrupt or insane trying to support them.
In short: Porting the current install process to FreeBSD is probably an endeavor I would not participate in nor would I encourage it. But, it wouldn’t be a huge ordeal for someone that knows FreeBSD well. And, it may even be that it doesn’t suck anymore. FreeBSD raised the default limit on secondary groups to something reasonable several years ago (historically we had to build a damned custom kernel to work well on FreeBSD!), we no longer use suexec (which required rebuilding Apache), so it’s probably that you can get everything in binary packages now. Probably most of the pain is historic. I still don’t trust packages on FreeBSD, as I’m not convinced FreeBSD developers know what “package manager” means, in terms of handling dependencies and updates, etc. (They probably do by now. Even Microsoft has figured out how to build package manager as of a year or so ago. I think Apple still has no reasonable package manager, though, so I guess it’s possible for smart people to still not understand their utility.)