material-ui
material-ui copied to clipboard
mui
[website] Add new FAQ to pricing page
Per https://www.notion.so/mui-org/MUI-X-Pricing-changes-2022-f17df701bf10406884a3204dcb8a3a3f#f50eb9adbc33495b8876d69cc69350d1 and per @joserodolfofreitas's point on how this point is confusing based on the sales analytics on the number of licenses sold. This effort is part of https://github.com/mui/mui-store/issues/136.
Preview: https://deploy-preview-33553--material-ui.netlify.app/pricing/
User questions
-
https://mui.zendesk.com/agent/tickets/4208
Sorry, I can't get behind this PR. The notion of "creating silos" is more confusing than what we already describe – all developers that work on the front end code require a license. Period.
Also, "indirectly" refers to developers that use X by way of a wrapper, for example an internal design system that includes both MUI Core and MUI X.
Also, "indirectly" refers to developers that use X by way of a wrapper, for example an internal design system that includes both MUI Core and MUI X.
@mbrookes The way you are phrasing this sentence makes me wonder. To be clear: these developers need to have a license too under the current terms. It's not because the component is wrapped, that the developers using it don't need great documentation, to ask questions, to ask for new features, etc. What do you have in mind?
To be clear: these developers need to have a license too under the current terms.
Correct. Whereas, "to be clear", you appear (based on the llink to https://www.notion.so/mui-org/MUI-X-Pricing-changes-2022-f17df701bf10406884a3204dcb8a3a3f#f50eb9adbc33495b8876d69cc69350d1, the argument about creating silos, and subsequently by the comment her https://mui.zendesk.com/agent/tickets/4208) to be using "indirectly" to refer to developers that work on a codebase that includes the MUI X, but don't edit sections of code containing MUI X components.
I think this is an important question to cover in our FAQ
The design system question isn't frequently asked – I think it has been asked exactly once. But there's no harm in answering it (it might be a frequently unasked question! 😁), so let's hone the wording that you've proposed.
Interesting, it sounds like that I missed my objective. OK, let's ignore the notion of "silos" there are two pushbacks. The problem I'm trying to solve is managers considering the product but thinking:
"WUT, why not only license the developers using the software directly? It doesn't make sense, it seems to be only about my willingness to pay more".
It's how I used to feel about Vaadin or AG Grid clause. But since, https://www.notion.so/mui-org/MUI-X-Pricing-changes-2022-f17df701bf10406884a3204dcb8a3a3f#f50eb9adbc33495b8876d69cc69350d1 changed my perspective. I get it. By doing such, we create a higher upfront cost to adopt the software, a downside, which we limit with open source, the scope of the project, and a cap on the number of licenses. In exchange, the pros, and team using MUI X Commercial get less friction on day-to-day when building screens. They don't have to think about how many licenses they have, It's closer to how open source licenses work. Anyone in the team can start to use the software. Indirect users of the software also benefit from us improving the documentation and answering support questions, building new features.
@joserodolfofreitas I have given a second try at this problem. Taking into account your suggestions.
I have just noticed the tradeoff of Qt. It's interesting, it's equivalent for us to change how we count developers to all use of @mui/ packages. MUI Core included. https://www.notion.so/mui-org/MUI-X-Pricing-changes-2022-f17df701bf10406884a3204dcb8a3a3f#edded8cd49fb4fb6a01e3345cee9fdf7. Now, the why might not make sense in regards to the current why of the current setup: optimizing to make it easy to determine the quantity + more stable overtime.
@mbrookes What's the downside of 854bfd6? I get that it's off-topic on the legal area, but why not on the pricing page