I work on it. Quite a few differences. Different business theory, different development theory...and, unavoidably, different era, all which change the likely "f

I work on it. Quite a few differences. Different business theory, different development theory...and, unavoidably, different era, all which change the likely "feel" of the project as it matures. To my mind, the biggest alteration is who does changes, and why: unless people show a lot (really, a surprising level) of code contribution interest, substantially, Ubicloud staff will make the changes and collect bugs from hosting the software in production. This, alone, is a big departure from how OpenStack has evolved. It was my experience that engineering staff assessing bugs in hosted software they had design responsibility for gave it much of its distinctness. OpenStack's main contributions seems to be consortia in the system integrator space. This distance between operation and design changes makes a big difference in how a project shakes out. There are some ramifications: one, is that more administratively complex services, like databases, tend to be out of scope for OpenStack, but in-scope for us. Secondly, OpenStack has an interest in broadening the number of mechanisms to support one kind of functionality, to handle varied and complex enterprise installations (that purchase service contracts). We are probably much more cautious about doing this, instead preferring one implementation that covers our target platforms well...and as simply as possible. Finally, there's era. It's somewhat unavoidable. For example, you would not design a system around IPv6 network underlays in 2010 (OpenStack's formative years), but you might in 2023 (as we did). This simplifies things. You couldn't use SPDK (established 2015, and you might have been brave to rely on it at inception) to have a gentler ramp to implement more advanced block device support and decide: "that's the implementation, unless we replace it totally." Many useful kernel features were developed between 2010 and 2023. Systemd is an obligate dependency of ours, and it has a lot of connections to the more advanced cgroups and namespace feature of Linux...and, brand new in 2010. Bare metal providers were not as advanced in 2010. And so on. Path dependency is inevitable, and we will have a different one, and that will make it a very different device. So, I haven't written much about what the project "is," but perhaps allowing you to anticipate how it "will be." And why some people found it worth their while to start building it.