The cost of things...

[TrojanHorse]

Okay, not sure where to start or even where I'm going, but here I go...

Subscription vs. one-time purchase models.  There are recent discussions here about Weather and Apps related to the cost, end of life, abandonment. etc.  Here are my thoughts.  And spoiler alert - I'm coming around to a "subscription fee" model over one-time purchase as I think it could ultimately be best for both developer and customer.  This isn't really my area of expertise but I do understand economics and (rational?) human behavior...  The subscription model better aligns revenue and expenses for the developer, and in some ways gives customers an easier option to walk away with their wallet.

Let's start with weather.  I get that the weather module is basically not economical for UDI.  I often wondered how it could be.  It was an up-front revenue model with an unending cost structure (as I understand the subscription annual costs).  I considered buying this module but at that time the data provider was being switched over.  So that gave me pause on it.  Anyway, so now it's going away and there are legal and commercial considerations here.  I would be frustrated by this EOL if I had tightly integrated this into my system.  If there was a simple button that would "replace old weather module with node server X", then it's maybe no big deal, but that doesn't exist.  So a user has to re-write their programs, which could be a pain, or even a problem if they don't (I suspect some will even be unaware of the end of life and it could cause other problems...)  And a customer doesn't know if the new data will be different than what they were using that could require additional intervention.  So the data provider raised prices (correct?) and it's not economical.  They also could have gone out of business or some other problem.  Either way, the existing setup then doesn't work for UDI.  Having a subscription fee (and a lower or $0 upfront cost) could help the economics here.  

Agave - I don't use it, and I'm glad I didn't buy the "lifetime package" or whatever it was.  I saw people get excited about that and wondered what they were expecting over the lifetime.  If I had tried Agave I would have preferred to basically rent it with a subscription fee, so that when the developer decides he has other better uses for his time than to update the app (good for him I suppose) then I could just go to Mobilinc.  

Mobilinc - I use this on iOS.  I like it, but don't yet want to go to Mobilinc X for a variety of reasons.  I think I'd rather use UDI portal vs. Mobilinc portal or whatever it's called.  If I want to change at some point, I'd like the option to be able to pay a subscription rather than pay upfront for direct IP access.  My existing Mobilinc will I suppose always work, until Wes decides that it's not worth it anymore and I need to update my phone itself or the iOS and it won't run anymore...

Node Servers - I had an issue with one and  @markv58 stepped up to fix them which I'm grateful for.  Yet, again I'm hesitant to tightly integrate node servers in general because there's no [financial] incentive for developers to keep them up-to-date.  Let's take Hue bulbs for example - let's say I've done a bunch of cool stuff with my ISY/Poly/Hue and then Phillips decides they need to change things for some reason (and I update my hub without realizing how this will affect the node server?).  So now it's broken and maybe the Hue node server developer can't or won't help for some reason?  or Tesla?  Trying to think of examples that may require more frequent updates.  PLEASE NOTE - I'm only using these as examples and not suggesting anything negative about these developers or their node servers.  

Polyglot itself - What prevents this from abandoned?  My understanding is UDI did not develop it?  Is it open source?  Clearly I'm just trusting that it's all good since I'm' running it...

Nodelink doesn't yet run on Polisy?  If I'm using Nodelink on an RPi then I don't want to be Polisy right now it seems.  

Okay, so I think we should be willing to pay for things we use.  And I'm starting to lean towards a subscription model since in many circumstances it makes more sense for everyone.  As things can change so quickly and frequently I think it's important for developers to have a revenue source to fund future updates and a customer should have the ability to decide to cease the subscription if they decide that they don't like the bargain/deal anymore.

Thinking about this subscription vs on-time model - a developer may need additional financial capital up front to offset the development costs (since they won't get the same lump sum effect up front).  But the benefit is a revenue stream.  Thinking back to the Weather Module or tother examples where there's clear ongoing expenses then ongoing revenue is essential.  And I'm also assuming that a developer won't start by charging 1X per month and later raising the price to 10X or 100X or whatever per month.  Of course there would need to be competitive options so a customer's not stuck there.  

Anyway, I could think of other examples but I think I'll stop here and listen to what others have to say.  In some ways I wish that UDI had more control over these modules and node servers and apps and whatever else applies here.  It feels like a bit of a mess right now to me.  

So those that are closer and know more about the tradeoffs for these business models, what say you?

[madcodger]

An ongoing subscription model is the only thing that makes sense for an ongoing service. If you are buying hardware or software that doesn't need to be maintained in terms of upgrades or ongoing services (e.g., a toaster), then one-time purchases make sense. But if there is a need for ongoing service such as security updates or enhancement, then ongoing revenue is essential. 

I've always thought of it as the difference between a glider and a plane. One-time purchases are gliders, relying on initial altitude to enable the length of flight. Subscriptions are planes, with engines (and even in-flight refueling capability). One is a fun little ride, but used only for fun. The other is reliable transportation.

 

[Teken]

8 hours ago, TrojanHorse said:

Okay, not sure where to start or even where I'm going, but here I go...

Subscription vs. one-time purchase models.  There are recent discussions here about Weather and Apps related to the cost, end of life, abandonment. etc.  Here are my thoughts.  And spoiler alert - I'm coming around to a "subscription fee" model over one-time purchase as I think it could ultimately be best for both developer and customer.  This isn't really my area of expertise but I do understand economics and (rational?) human behavior...  The subscription model better aligns revenue and expenses for the developer, and in some ways gives customers an easier option to walk away with their wallet.

Let's start with weather.  I get that the weather module is basically not economical for UDI.  I often wondered how it could be.  It was an up-front revenue model with an unending cost structure (as I understand the subscription annual costs).  I considered buying this module but at that time the data provider was being switched over.  So that gave me pause on it.  Anyway, so now it's going away and there are legal and commercial considerations here.  I would be frustrated by this EOL if I had tightly integrated this into my system.  If there was a simple button that would "replace old weather module with node server X", then it's maybe no big deal, but that doesn't exist.  So a user has to re-write their programs, which could be a pain, or even a problem if they don't (I suspect some will even be unaware of the end of life and it could cause other problems...)  And a customer doesn't know if the new data will be different than what they were using that could require additional intervention.  So the data provider raised prices (correct?) and it's not economical.  They also could have gone out of business or some other problem.  Either way, the existing setup then doesn't work for UDI.  Having a subscription fee (and a lower or $0 upfront cost) could help the economics here.  

Agave - I don't use it, and I'm glad I didn't buy the "lifetime package" or whatever it was.  I saw people get excited about that and wondered what they were expecting over the lifetime.  If I had tried Agave I would have preferred to basically rent it with a subscription fee, so that when the developer decides he has other better uses for his time than to update the app (good for him I suppose) then I could just go to Mobilinc.  

Mobilinc - I use this on iOS.  I like it, but don't yet want to go to Mobilinc X for a variety of reasons.  I think I'd rather use UDI portal vs. Mobilinc portal or whatever it's called.  If I want to change at some point, I'd like the option to be able to pay a subscription rather than pay upfront for direct IP access.  My existing Mobilinc will I suppose always work, until Wes decides that it's not worth it anymore and I need to update my phone itself or the iOS and it won't run anymore...

Node Servers - I had an issue with one and  @markv58 stepped up to fix them which I'm grateful for.  Yet, again I'm hesitant to tightly integrate node servers in general because there's no [financial] incentive for developers to keep them up-to-date.  Let's take Hue bulbs for example - let's say I've done a bunch of cool stuff with my ISY/Poly/Hue and then Phillips decides they need to change things for some reason (and I update my hub without realizing how this will affect the node server?).  So now it's broken and maybe the Hue node server developer can't or won't help for some reason?  or Tesla?  Trying to think of examples that may require more frequent updates.  PLEASE NOTE - I'm only using these as examples and not suggesting anything negative about these developers or their node servers.  

Polyglot itself - What prevents this from abandoned?  My understanding is UDI did not develop it?  Is it open source?  Clearly I'm just trusting that it's all good since I'm' running it...

Nodelink doesn't yet run on Polisy?  If I'm using Nodelink on an RPi then I don't want to be Polisy right now it seems.  

Okay, so I think we should be willing to pay for things we use.  And I'm starting to lean towards a subscription model since in many circumstances it makes more sense for everyone.  As things can change so quickly and frequently I think it's important for developers to have a revenue source to fund future updates and a customer should have the ability to decide to cease the subscription if they decide that they don't like the bargain/deal anymore.

Thinking about this subscription vs on-time model - a developer may need additional financial capital up front to offset the development costs (since they won't get the same lump sum effect up front).  But the benefit is a revenue stream.  Thinking back to the Weather Module or tother examples where there's clear ongoing expenses then ongoing revenue is essential.  And I'm also assuming that a developer won't start by charging 1X per month and later raising the price to 10X or 100X or whatever per month.  Of course there would need to be competitive options so a customer's not stuck there.  

Anyway, I could think of other examples but I think I'll stop here and listen to what others have to say.  In some ways I wish that UDI had more control over these modules and node servers and apps and whatever else applies here.  It feels like a bit of a mess right now to me.  

So those that are closer and know more about the tradeoffs for these business models, what say you?

First, well thought out and expressed. When I have more time this week I'll put pen to paper and offer my insights.

[lilyoyo1]

For me it's a combination of both. When selling hardware that is connected, updates should be known and expected by the company. This cost should be considered into the price of every unit sold with current and future sales paying for that development 

I buy things for what they do today not what I hope/want tomorrow. Because of that line of thinking, I don't expect software updates that completely transform a system. However, I don't think there should be a subscription just to receive standard updates for things it's supposed to do such as new firmwares for devices and security.

I'm good with a 1 time fee to upgrade to the newest system such as 4.0 to now, but not a subscription just for updates for new products and security updates as things change.

For example, UDI built the Isy knowing it would be connected to the internet and would last for years. At the time the 994 came out it was insteon only. I shouldn't have to pay a fee every month or whatever just to be able to add a new insteon device. With them adding zwave, buying the module was a defacto upgrade. With 5.0 bring so much different than 4.0, I would've been ok with paying to upgrade to that. Subsequent updates however I don't think should come at a cost. 

IMO, I think UDI did us a solid with how they've handled upgrades. That's why I defend them when I hear people complaining about the time frame. They are getting for free what most companies charge for

[Teken]

43 minutes ago, lilyoyo1 said:

For me it's a combination of both. When selling hardware that is connected, updates should be known and expected by the company. This cost should be considered into the price of every unit sold with current and future sales paying for that development 

I buy things for what they do today not what I hope/want tomorrow. Because of that line of thinking, I don't expect software updates that completely transform a system. However, I don't think there should be a subscription just to receive standard updates for things it's supposed to do such as new firmwares for devices and security.

I'm good with a 1 time fee to upgrade to the newest system such as 4.0 to now, but not a subscription just for updates for new products and security updates as things change.

For example, UDI built the Isy knowing it would be connected to the internet and would last for years. At the time the 994 came out it was insteon only. I shouldn't have to pay a fee every month or whatever just to be able to add a new insteon device. With them adding zwave, buying the module was a defacto upgrade. With 5.0 bring so much different than 4.0, I would've been ok with paying to upgrade to that. Subsequent updates however I don't think should come at a cost. 

IMO, I think UDI did us a solid with how they've handled upgrades. That's why I defend them when I hear people complaining about the time frame. They are getting for free what most companies charge for

I just have the urge to argue with you but you make it so hard stating FACTS! 

[oberkc]

Perhaps this is another reason to avoid systems which rely on continuous (and costly) services to operate.

[Bumbershoot]

47 minutes ago, lilyoyo1 said:

IMO, I think UDI did us a solid with how they've handled upgrades.

+1

[Teken]

Just now, oberkc said:

Perhaps this is another reason to avoid systems which rely on continuous (and costly) services to operate.

Example?

[oberkc]

10 minutes ago, Teken said:

Example?

I am making an attempt to differentiate between systems that require cloud services to operate and those that don’t.  Clearly, cloud services represent a continuous cost to the vendor.  If those can be avoided, then the need for subscriptions is reduced.

[simplextech]

6 minutes ago, oberkc said:

I am making an attempt to differentiate between systems that require cloud services to operate and those that don’t.  Clearly, cloud services represent a continuous cost to the vendor.  If those can be avoided, then the need for subscriptions is reduced.

I'm following this and am very interested.  So I pose this question.

What about NodeServers?  Should those be a per version cost or a subscription?  Industry normal "drivers" are a per controller cost with fixes included but version upgrades are paid for.  If a NS has a cloud requirement/dependency then there's an ongoing cost and seems it should fall into a subscription model?

The current model so far is free for all everywhere which is not sustainable for anyone.

[Teken]

2 minutes ago, oberkc said:

I am making an attempt to differentiate between systems that require cloud services to operate and those that don’t.  Clearly, cloud services represent a continuous cost to the vendor.  If those can be avoided, then the need for subscriptions is reduced.

Given the whole local first vs cloud first movement is ever changing toward the cloud. My position on (specifically) the cloud debate is the vendor needs to be clear as to their intent and future goals. I don't have to point out any of the small to large companies that have literally folded and stopped offering X cloud service and hence left the consumer holding the virtual bag.

There are no less than 20 that have impacted the consumer in various degree's

Services which are free in my mind I always set my expectation that it's going to explode and go away or later ask for some kind of annual fee. This is really the switch and bait or dangle a carrot where you have all of your eggs in one basket and over Y period are tied to them. Which makes it extremely hard with out an outlay of finances to switch over. I should clarify for a consumer if it's free 

ca·ve·at emp·tor

/ˌkavēˌät ˈem(p)ˌtôr/

 

It's free so there is no expectation something will continue or doesn't change which assumes this was even called out. If it's called out and defined in the TOS (Terms Of Service) well you need to read the TOS and understand what you're getting into vs what you're going to get over the long run.

 

Now, if I pay for a subscription (cloud service) there are basic expectations which have now in 2020, are blurred.

 

Why??

 

Just because, no real reason, just because . . .

 

I call this mentality *Pushing Stupid* as we consumers see this everyday with respect to fuel prices. There is no relationship to demand vs actual costs it's *Just Because* I can! Anytime someone has told you and I that gas prices are simply based on the price they receive and do their part of mark up is literally none sense and horse sh^t. Because if that were true how does one explain fuel that has literally been pumped into the ground say on Monday 01, 2020 and it cost $1.00 and that same fuel is still in the ground on Friday 05, 2020 and the prices sky rockets to $1.25 - $1.45?!?

 

You know those eggs I purchased at the local Circle K for a $1.00? When I placed them in the fridge they still cost a $1.00! Those eggs don't automagically increase in price to $1.45 because you know why??? I already paid for it and its in my fridge!

 

To scale this same example as it pertains to fuel every city, town, Province, State, has a storage facility where fuel is literally stored. Guess what? That fuel was refined, processed, and is now in storage bins which have a defined cost which in this case lets just say $100.00 That same fuel doesn't just automagically increase to $200.00 because there was some kind of **** in the world!

 

But, the people in these so called in the know and so called smart people will relay, inform, and tell us lowly uninformed people. Yes, gas costs $1.45 because the price of fuel went up over night!!!

 

No, just say you're a greedy SOB and move on.

 

Now, with respect this whole (specific) point on the cloud if I pay for something and the TOS is well defined - Don't keep moving the goal post! Because every one of those TOS's have the all too famous (Just Because) these terms are subject to change blah blah blah. In plain English this simply means I want an out and get out of jail free card:

 

Wait for it: JUST BECAUSE . . .  

 

[mwester]

12 minutes ago, simplextech said:

I'm following this and am very interested.  So I pose this question.

What about NodeServers?  Should those be a per version cost or a subscription?  Industry normal "drivers" are a per controller cost with fixes included but version upgrades are paid for.  If a NS has a cloud requirement/dependency then there's an ongoing cost and seems it should fall into a subscription model?

The current model so far is free for all everywhere which is not sustainable for anyone.

Great question!  No answer from me, but let me add another point to consider around this, which is (succinctly) that users have expectations around "stores" (e.g. Google Play, Microsoft, Apple, etc).  I would expect that users would likewise expect that node servers in the UDI store would be vetted in some way, meeting some baseline of functionality, quality, and hopefully security.  This would require resources from UDI -- which would imply ongoing costs incurred by UDI as node servers are added, updated, etc. by their authors.  This adds to the question posed by @simplextech -- how does UDI recover their costs?

[simplextech]

4 minutes ago, mwester said:

which is (succinctly) that users have expectations around "stores" (e.g. Google Play, Microsoft, Apple, etc). 

I would hope any "store" would be more inline with review/acceptance like Apple does rather than Google where anyone can push any garbage and have it available.  This does require review/vetting which all requires resources and has a cost to it. 

A "normal" method would be a flat or percentage based publishing fee.  This would either be a one time publishing fee or a percentage of each sale.  Sometimes both might be necessary to cover things like cloud expenses?  These fees no matter how they are extracted will always increase the cost to the end consumer of the product so it's a balancing act for all parties involved.

[simplextech]

Follow up on this.... With the "store" thoughts I think in-store purchases of "features" should not be allowed for NodeServers.  I hate the download for free and then nickel-dimed for functionality or death by Ads for an app you're trying to use.  NodeServers could have multiple versions available that define CLEARLY the features and limitations of each version.

[Teken]

Just now, simplextech said:

Follow up on this.... With the "store" thoughts I think in-store purchases of "features" should not be allowed for NodeServers.  I hate the download for free and then nickel-dimed for functionality or death by Ads for an app you're trying to use.  NodeServers could have multiple versions available that define CLEARLY the features and limitations of each version.

Preach . . . ?

[Teken]

With respect to Node Servers once they have been installed can they be remotely disabled / removed?

[oberkc]

9 minutes ago, simplextech said:

What about NodeServers

I am not even sure that I fully understand what a “node server” is.  I understand that things that I use like alexa and nest and hue and harmony all rely on some level of cloud services to operate.  I have a polisy, but am a little uncertain how much workload is divided between the polisy and the cloud.  I understand that integration with alexa and things by my ISY is based upon cloud services.  I enjoy that integration, but have avoided allowing my system to be reliant on alexa, etc, to properly operate.  I would still be willing to abandon all that.  I subscribe to the ISY portal, but hesitantly.  I am very sensitive to the proliferation of monthly fees (cell phones, internet, tv streaming services, netflix, amazon prime, apple cloud storage and news, cbs all access, office 365, not to mention utilities) that really start to add up.  (Ihave so far refused to pay the $5 monthly fee associated with the ring doorbell.)  I only purchase surveillance cameras able to operate independent of cloud services and subscription fees.

At this point, I am looking at the portal fee as an ongoing cost that falls above the cut line and as one that I hope makes the polisy and node servers an economically viable operation.  I am, personally, near my limit to additional monthly fees for home automation.

I don’t know whether this answers your question, but hope it gives you some sense of one customer’s perspective.

[simplextech]

1 minute ago, Teken said:

With respect to Node Servers once they have been installed can they be remotely disabled / removed?

Not currently.  Today there's no control or restrictions in any form.  Everything is distributed in source form as well.  So anyone can take the NS and modify or copy and re-distribute or do literally whatever they want with it.

Polyglot Cloud has possibility of being able to remotely disable but that's it and AFIK there's no functionality for that currently. 

[oberkc]

I think, too, that if there starts to be fees for these node server things, they must move beyond a hobby/passion for some.  These need to “just work”, have full user manuals, clear-and-detailed explanation for all the provided display fileds and why I should care and what all the different options mean.  While I appreciate all the effort that went into them, it is nowhere near the polished experience it needs to be for the masses.

[simplextech]

3 minutes ago, oberkc said:

I am not even sure that I fully understand what a “node server” is.

A NodeServer is that plugin, driver, add-on that you run on Polisy that gives you the ability to use Hue with the ISY or Harmony.  Those are pieces of software developed by independent developers.

NodeServer's aka drivers running on Polisy run on Polisy and NOT the cloud.  There are NodeServers that do run in Polyglot Cloud but that has nothing to do with Polisy.  Things running on Polisys are mostly local unless they reach out to a cloud service for information. 

Examples:

• Hue is local
• Harmony is local
• Weather providers (Ambient Weather, Weatherbit, etc) those RUN local but GET information from the cloud.

[Teken]

1 minute ago, oberkc said:

I think, too, that if there starts to be fees for these node server things, they must move beyond a hobby/passion for some.  These need to “just work”, have full user manuals, clear-and-detailed explanation for all the provided display fileds and why I should care and what all the different options mean.  While I appreciate all the effort that went into them, it is nowhere near the polished experience it needs to be for the masses.

100%

Which is why with anything that is first starting you try to attract talent like @simplextech @bpwwer et all. Once there is some kind of acceptance from the developers it's going to move into free vs paid. As you noted if it's going to be paid I expect a heck of lot more than what is offered. I also don't subscribe to the whole concept this is just beta or it's a finished product yet you all know its not even close to being finished.

[Teken]

12 minutes ago, oberkc said:

I am not even sure that I fully understand what a “node server” is.  I understand that things that I use like alexa and nest and hue and harmony all rely on some level of cloud services to operate.  I have a polisy, but am a little uncertain how much workload is divided between the polisy and the cloud.  I understand that integration with alexa and things by my ISY is based upon cloud services.  I enjoy that integration, but have avoided allowing my system to be reliant on alexa, etc, to properly operate.  I would still be willing to abandon all that.  I subscribe to the ISY portal, but hesitantly.  I am very sensitive to the proliferation of monthly fees (cell phones, internet, tv streaming services, netflix, amazon prime, apple cloud storage and news, cbs all access, office 365, not to mention utilities) that really start to add up.  (Ihave so far refused to pay the $5 monthly fee associated with the ring doorbell.)  I only purchase surveillance cameras able to operate independent of cloud services and subscription fees.

At this point, I am looking at the portal fee as an ongoing cost that falls above the cut line and as one that I hope makes the polisy and node servers an economically viable operation.  I am, personally, near my limit to additional monthly fees for home automation.

I don’t know whether this answers your question, but hope it gives you some sense of one customer’s perspective.

100% Again!

Unlike some the vast majority don't have endless finances never mind those on fixed incomes. I'll pay for a subscription only if it has value or there is literally no other choice in that respective field / industry.

[simplextech]

1 minute ago, Teken said:

100%

Which is why with anything that is first starting you try to attract talent like @simplextech @bpwwer et all. Once there is some kind of acceptance from the developers it's going to move into free vs paid. As you noted if it's going to be paid I expect a heck of lot more than what is offered. I also don't subscribe to the whole concept this is just beta or it's a finished product yet you all know its not even close to being finished.

Absolutely correct.  This exact discussion is happening with UDI as well on HOW to make this a polished offering what is needed to get there.  Frankly this is A LONG WAY off and requires FAR MORE resources (people, time, money) than are actually available today.  First part is always research to even make a determination if this is viable or not.  Why put in a lot of time/money if it's not of interest, use, need to consumers?

[lilyoyo1]

1 hour ago, Teken said:

I just have the urge to argue with you but you make it so hard stating FACTS! 

Come on Teken. I'm sure you can come up with something

[Bumbershoot]

I don't know how you differentiate pricing for various functionality that nodeservers provide: some provide data only (weather nodeservers are an example) while others provide 2-way interactivity with devices.

I would happily pay a one-time fee for nodeservers that allow me to interact with my devices, with the possibility of additional fees for upgrades.  For nodeservers that provide ongoing data but no interactivity, then I'm happy with a small subscription in order to keep the data coming.

Regarding spit/polish/fancy documentation, I'm not that concerned, but I do want nodeservers to work as intended.  I have several that I do not want to live without, so as soon as a mechanism for payment is devised, I'll pay.