I think its worth taking a moment to read the guidelines I posted recently on how we are evaluating feature requests these days. I’ve been saying this in various places now for quite some time, but this write-up helps explain our stance pretty clearly. We love feature requests. If money, time and developers were unlimited there’s a million things I’d love to also add to the product, even just for my own selfish reasons. But since thats not reality, we have to be pretty pragmatic with what we pick and chose to go implement. And what the opportunity cost is if we pick X instead of Y to do.
In response to the comments about us being restrictive on what settings or features we expose.. I’d also like to make the point (again) about TrueNAS being an appliance. Not a Linux distro. Yes, we sometimes have restrictions on features, configuration settings, API calls, etc. Also this isn’t some generic Linux install where you can go tweak systemd or change conf files in /etc at will. We have to test almost every single combination of knobs (of which there a LOT) and guarantee that on each upgrade your system comes back healthy and things don’t break. There’s always going to be some tension between the super experienced folks who want to get under the hood and twist all the knobs on their own and those who want a product “that just works”. Because we’re an appliance, we skew towards the “it just works” end of the spectrum as a default. We expose the more advanced things only when and where it makes the complete sense to do so. Where we aren’t going to be pointing a loaded gun at somebodies foot in the process. We did that far too often in the past, usually to make the small, but vocal, uber technical minority happy. Often at the expense of too many others who then inadvertently broke things because they didn’t have that technical depth to know how to do so safely.