I do not agree that Rhino should specialize or focus on what is already good. It’s already the best (I think) surface modeling tool, improving it isn’t going to help them too much. It’s true that they have (very important) work pending here, but just focusing on it will only satisfy those who have already paid. What they need to do more or better is to measure the industries and users they impact so as not to base their movements on their subjective experience, which no matter how expert it is, if it’s not the real data that makes you take the best decisions. I don’t know to what extent they measure this, I hope they don’t just settle for the profession the user assigns when creating the account or some survey of key people every 5 years or the thermal sensation of the community’s demands. I believe that their development strategy is very dependent on the development decisions they make, therefore they should be obsessed with having the best inputs to evaluate timing and thus efficiently balance the dilemma between opening up new markets or improving existing ones.
I believe that specific industries have specific problems with Rhino and that some of those problems will be common. By measuring the impact on these, they can prioritize solving them and include in the planning some room for innovation in other areas. They may be doing this already, but I wonder how valid or improvable the data is that justifies their moves.
Going to the web (Rhino.Compute) and embedding its application in others (Rhino.Inside) have seemed to me very necessary moves that should be made as soon as possible (at least Rhino.Compute). I’m extremely curious to know what results they’ve gotten, but I think it’s an investment for the long term that means a lot to consolidate their software. But I agree with others that opening more projects this big sounds like forgetting too much about the problems that current users have, especially considering that the SubDs are also quite fresh there.
On the other hand, from the user-developer side, if Rhino were an OS, I would say that it is like Linux, because it allows you to customize it quite a bit but from the deepest terrible darkness. I’m exaggerating, but I’m seeing other new APIs that are well documented, that everything works at first glance, that the SDK tells you to use it because it exposes everything you need without requiring years or being an expert to build on top of it. I don’t feel that the core or Rhino (at least the .Net face) is designed for generality to allow building on top, I think it is designed only for scripting (making calls to existing things) and some rhino features are left open so that they can be adjusted slightly, but they are not intended for others to continue their development, to extend them. Something that also demonstrates this, is that they don’t offer design guidelines so that your plugins have a coherent appearance with the rest of the software or other integration patterns. It is kind of friendly but within the chaos. It’s something I don’t understand, they have a community of developers that instead of encouraging them to build for them, they write code that you have to fight with or make ugly hacks to extend what they’ve done for Rhino. I believe that the sooner they change this culture from an ambiguous development to one that is truly extendable, the more return they will receive. But my impression about the way these heads understand the development of their software, is that they don’t want to. To some extent I understand, because making a generic functionality instead of a specific purpose can mean several times more time and errors. However, there is a very unbalanced balance that gives me to understand that making the functionality extendable is discarded by default. I believe that it is more intelligent to leave something halfway and extendable than to wait for a time to develop it properly that never comes.
I don’t think it’s been mentioned here, in case I’m saying it, the meshes need a lot of improvement. I understand that they are not the main purpose of software, but they are necessary for manufacturing and web applications. One of those improvements that would mean for several industries I think is a volume calculator that doesn’t depend on joining all the geometry together because nowadays boolean operations can’t be automated because they don’t always work, sometimes moving one of the pieces a 0.001 units is solved, but this is something impracticable when automating complex geometries, besides being terribly expensive computationally. Other tools such as offset or filet are not friends of automation either.
Depending on the day, I am happy with Rhino or not, but it is almost always a yes. Although I still see it as the mother of my girlfriend (Grasshopper) 
. As long as they don’t raise their price, I want what they can get the most return so that they have enough mattress to be able to dedicate some time to change things in the UI/UX or/and so many other things that need improvements for years but are not done because they are not profitable and are important for me. I trust they will do well, unless they don’t measure enough.
)… and a community next to nothing 
-)