Hey @eysein. Thank you very much for taking the time to reply to me. I appreciate it. Since I’m not actively trying to build anything with Mender, I want to emphasize the reason I replied here. When I looked at OTA updaters (Azure IoT, AWS IoT, Ubuntu Core, Resin/Balena) a year or two ago I was really disappointed with all of them except Mender and Mender has stuck in the back of my mind as the first one I’d consider in the future since then. Now the pricing that would scare me off.
The 12 month trial is great and I think that’s a really generous offer for any teams that come in with a specific product they want to build. It’s on the scale of hobbyist, indie, small developers, etc. where I think the new pricing is bit exclusionary.
I’ll use my original suggestion of trying to update something like router7 via Mender. I would never do this since that’s not a production quality firewall, so it’s theoretical, but I have a reasonable knowledge of the market for firewalls in small businesses, so it makes a good use case for me to illustrate some of my thoughts.
After this, the way the plans are intended to be split up is by maturity/complexity of your product.
The problem with this is that it’s never true or evolves to the point where it’s not true. GitLab says the same thing an I always find myself running into issues that would be solved by a higher tier version of the product even though I’m not using it in a big company. In fact, I quit using GitLab because of it.
Taking my router7 example, assume my first two customers are a restaurant and a motel. The ideal time to update a network device at a motel is about an hour after checkout (during the day). At a restaurant it would be late evening Monday-Wednesday. So, by the time I have 2 devices, I already want scheduled updates.
so a startup pre-launch should not critically need the features in the Enterprise plan, for example
e.g. Phased rollout avoids breaking all the devices at once with an OTA update
Not breaking all devices at the same time is the most valuable feature of an OTA updater and it’s in the most expensive tier. As for my router7 example, I would absolutely want phased rollouts from day one. The way I’d do it is to update my own site plus a few high tolerance customers first, then customers within X kilometers next, and finally customers further away than X kilometers.
For something like networking equipment, bricking more than 2-3 sites at once would be a huge deal because you can’t reasonably visit (ex:) 5+ sites in a day to fix things. So in addition to phased updates, I’d go as far as wanting rolling updates where everything would stop and wait for manual intervention after 1-2 broken sites. In this case I’m assuming 1 firewall = 1 device = 1 site.
So my feedback there would be that even though it’s easy to say features are tiered to make sense for different scales of deployments, I’ve never used anything where I didn’t run into technical or manageability limitations because of the feature tiering. There’s always something I want in the next tier and even though that’s good for (your) sales, it’s a big negative for me.
Some fully-scaled deployments are just 200 devices.
Using my router7 example again, getting to 200 devices would take a lot of work. Selling a small business a firewall, updates, etc. usually involves re-implementing a large portion of their network, and doing that once every second week would be a realistic goal IMO. So an IT provider that supports small, local businesses might add ~25 devices per year.
IoT / embedded products come in all shapes and scales, so the intention is not to charge more per device for higher-scale deployments (rather the other way around, with volume discounts as you mention).
To be more clear, I was trying to say I think there’s a lot of value in highly scalable systems and it’s the kind of thing where it makes sense (to me) to pay more. I didn’t mean to suggest you’re charging more for scale. To me, an OTA updater that can support 100 devices isn’t very valuable, but there’s a ton of value in something that scales to 10000s of devices because it’s not easy to hack that together or for someone else to come along and offer a competing service (without a lot of investment).
As for the part about products being different shapes and scales, I agree. That’s also part of the reason I don’t like having technical / management features tiered. Like I said, there’s always something vendors consider a “big business” feature that I want access to. Two factor authentication is a good example of this in your current tiering. Is that actually 2FA like an authenticator for account login or am I misinterpreting? Proper account security isn’t a “big business” feature IMO.
The “size” of micro-services / Docker images is a hotly debated topic in general. 
I definitley understand where you are coming from but we also need to support larger deployments (e.g. our hosted Mender, but also larger on-premise customers) with this.
Yes. I agree with that sentiment. The point I was trying to make is the complex, highly scalable solution provides a lot of value for you as the hosted service provider. However, for me as a consumer of those images, the complexity has negative value. From my point of view, instructions like this look like a how-to guide for someone to come in and start a competing service while it’s not very useful for me.
A monolithic image with feature parity would be a lot more valuable to me in terms of development, testing, and running a hobbyist quality service to see if anything I’ve built could be sustainable. I see you already tier the features in the self-hosted deployment and that makes it much less valuable to me since I would typically self-host something like that in my development / learning environment.
So what I’m saying is that I think it could make sense to have 2 image based deployment solutions. The first would be your current, highly scalable setup. The second would be a simple, monolithic, non-scalable image for development, testing, hobbyists. Personally I don’t think I’d give away the infrastructure recipe as an open source project, especially after seeing what AWS did to MongoDB, etc.
Were you aware of these options already, and do you still think this is too expensive?
Yes, I saw the options. As for price, I look at it this way. I can see the incremental price of a device in the professional plan is $1 per month. I think that’s good value for all the features Mender has, but it’s too hard to get there and it’s a really bad deal if I have a very small number of devices.
So, to be clear, I don’t think that pricing is bad if you’re an enterprise customer with an existing product to deploy. It’s more on the hobbyist / indie developer side where I think it’s a harder sell and the old pricing wasn’t out of reach like I think the new pricing is. The usage based pricing did a really good job of being accessible to small deployments IMO.
I realize it might not be economically viable to cater to small deployments and it’s completely reasonable for large deployments to be your primary focus. I’ll end by saying I don’t think your pricing is out of the ordinary. There seems to be a trend in the tech industry where SaaS pricing is increasing and getting out of reach for hobbyists, enthusiasts, indies, small businesses, etc…
Thanks again for taking the time to reply to me. If you ever decide to re-visit your pricing I hope my feedback is useful in some way.
). So we will ensure to meet the pricing expectations anyone who are in production, or planning to scale with Mender and encourage reaching out to