Ok, so their homepage design unintentionally omits that pertinent information. I’ve wasted a couple of hours installing a FOSS package for a personal project only to find out one of the most heavily presented features was a paid add-in. Even if it’s bad communication design add not intentional, it feels like a salesey bait-and-switch tactic in that situation, and they probably want to know that.
What is it that you think is the most heavily presented feature that is actually behind a paid addin? Because they're quite vocal about the fact that most people should not ever need the pro license... They actively dissuade people from buying it.
not the OP, but a lot of the referenced functionality looks like I might use it. The problem is I'm not going to bother trying this and investing any effort with even the looming possibility I'll need to pay to keep going. I don't think too many people approach this space with a purchase evaluation mindset like say, "I'm going to test out this grid to see if we should buy it". In that case pay-for advanced functionality is part of the approach from the start.
Also, I can't see this approach working. Getting enterprise adoption of a front end framework is almost impossible outside of React, let alone paying for a niche one, and the "contact us" approach is a non-starter.
If the core of the framework fits what you need, you could write those additional plugins yourself, rather than relying on the official "pro" ones. My understanding so far is the plugin architecture is intentionally designed for this usecase, so you aren't beholden to the official maintainers to add/tweak features for your specific usecase.
This makes the investment in the tool a lot safer, because you can always swap out pieces that don't fit your usecase, rather than start from scratch with a new framework.
In an enterprise setting, I don't believe the cost alone will be the factor that drives the decision. It'd be weighing up the value of the framework (e.g., UI framework/programming language agnostic stack, simpler architectures, delivery speed, performance, cost of using the framework on users) against the license cost.
> Getting enterprise adoption of a front end framework is almost impossible outside of React, let alone paying for a niche one, and the "contact us" approach is a non-starter.
Two questions on this:
1. Why do you think it's impossible to get org buy-in?
2. Why do those same orgs pick frameworks like Next.js, whose full benefits can only be realized with sophisticated and paid infrastructure?
as i've said in many comments and the devs say ad-nauseum, there's very little need for anything in the Pro license. the fully open-source library is sufficient for almost all needs. And it is easily extendable with plugins if you want more functionality than it provides.
i went looking for pricing info and it's the last item in the last menu on the website... it's not exactly up front. i was looking for a "pricing" top-level menu item first, which is pretty standard nowadays.
As ive said in many other comments - YOU DO NOT NEED PRO. The devs are very adamant about this - even aggressively so. 99% of apps will work just fine with the free library. Pro is for some bells and whistles, or just to support people who have invested many thousands of hours into making a genuinely innovative framework, and given it away
OK, then this approach will needlessly discourage adoption AND consume way more resources than it brings in. Under this structure the team needs to deliver the highest level of quality to the smallest paying audience without community support. Further, enterprise is very hesitant to pay for this as a product but are way more receptive to paying for support. Everyone would be much better served without a tiered free/pay product and paid support options.
>> or just to support people who have invested many thousands of hours into making a genuinely innovative framework, and given it away
I've never seen a corporation do this even with projects that don't try and encourage like here.
If an enterprise won't want to pay for the product, what makes you think they're more likely pay for support?
If you're implying they'll only pay when they've seen the value of the product, then the non-pro part of the framework is incredibly feature-rich and can easily do that.
Yeah support model for a lit of projects like this doesn't work. Even companies like the one behind NATS struggle. It's almost contingent on you building a bad product that needs support.
Ok, so their homepage design unintentionally omits that pertinent information. I’ve wasted a couple of hours installing a FOSS package for a personal project only to find out one of the most heavily presented features was a paid add-in. Even if it’s bad communication design add not intentional, it feels like a salesey bait-and-switch tactic in that situation, and they probably want to know that.
Why is pro pertinent info? You probably don't need it. It's just a set of plugins and tools anyone could write if they needed.
What is it that you think is the most heavily presented feature that is actually behind a paid addin? Because they're quite vocal about the fact that most people should not ever need the pro license... They actively dissuade people from buying it.
Which feature are you referring to?
not the OP, but a lot of the referenced functionality looks like I might use it. The problem is I'm not going to bother trying this and investing any effort with even the looming possibility I'll need to pay to keep going. I don't think too many people approach this space with a purchase evaluation mindset like say, "I'm going to test out this grid to see if we should buy it". In that case pay-for advanced functionality is part of the approach from the start.
Also, I can't see this approach working. Getting enterprise adoption of a front end framework is almost impossible outside of React, let alone paying for a niche one, and the "contact us" approach is a non-starter.
Fair enough! That's up to you
If the core of the framework fits what you need, you could write those additional plugins yourself, rather than relying on the official "pro" ones. My understanding so far is the plugin architecture is intentionally designed for this usecase, so you aren't beholden to the official maintainers to add/tweak features for your specific usecase.
This makes the investment in the tool a lot safer, because you can always swap out pieces that don't fit your usecase, rather than start from scratch with a new framework.
In an enterprise setting, I don't believe the cost alone will be the factor that drives the decision. It'd be weighing up the value of the framework (e.g., UI framework/programming language agnostic stack, simpler architectures, delivery speed, performance, cost of using the framework on users) against the license cost.
> Getting enterprise adoption of a front end framework is almost impossible outside of React, let alone paying for a niche one, and the "contact us" approach is a non-starter.
Two questions on this:
1. Why do you think it's impossible to get org buy-in? 2. Why do those same orgs pick frameworks like Next.js, whose full benefits can only be realized with sophisticated and paid infrastructure?
as i've said in many comments and the devs say ad-nauseum, there's very little need for anything in the Pro license. the fully open-source library is sufficient for almost all needs. And it is easily extendable with plugins if you want more functionality than it provides.
i went looking for pricing info and it's the last item in the last menu on the website... it's not exactly up front. i was looking for a "pricing" top-level menu item first, which is pretty standard nowadays.
As ive said in many other comments - YOU DO NOT NEED PRO. The devs are very adamant about this - even aggressively so. 99% of apps will work just fine with the free library. Pro is for some bells and whistles, or just to support people who have invested many thousands of hours into making a genuinely innovative framework, and given it away
OK, then this approach will needlessly discourage adoption AND consume way more resources than it brings in. Under this structure the team needs to deliver the highest level of quality to the smallest paying audience without community support. Further, enterprise is very hesitant to pay for this as a product but are way more receptive to paying for support. Everyone would be much better served without a tiered free/pay product and paid support options.
>> or just to support people who have invested many thousands of hours into making a genuinely innovative framework, and given it away
I've never seen a corporation do this even with projects that don't try and encourage like here.
If an enterprise won't want to pay for the product, what makes you think they're more likely pay for support?
If you're implying they'll only pay when they've seen the value of the product, then the non-pro part of the framework is incredibly feature-rich and can easily do that.
Yeah support model for a lit of projects like this doesn't work. Even companies like the one behind NATS struggle. It's almost contingent on you building a bad product that needs support.
This is irrelevant to my comment. You claimed they're not hiding pricing and I'm simply saying it was a little hard to find ¯\_(ツ)_/¯