Thanks for advocating for these issues. They are important.

I'm the CTO of a small software studio who has worked almost exclusively in the IoT space for the last 8 years. We've worked on large, Fortune 500 companies, all the way down to startups. Half our projects have been for consumer IoT, the other half for B2B projects.

There are two core financial realities that regulators need to understand:

1. From a purely financial perspective, most manufacturers do not have financial models that make perpetual, ongoing updates possible. Without a recurring revenue stream tied directly to a device, any software update reduces the return on investment for a product. For example, say you make a consumer IoT device and sell it without a subscription. The BOM might be $50 and the NRE is $50. You might sell it for $200, and make $100 profit. However, without a revenue stream of some sort, that profit needs to somehow support all the software updates those devices will receive in the future. Say each update costs $5 to build and deploy, and you release once a year. After 4 years you've spent $20 in updates, likely more due to inflation. At some point this becomes a losing proposition. The fact that GAAP says non-recurring engineering can be capitalized, but the maintenance cannot, creates even more issues. And due to the maturity of security, it's difficult, if not possible, to guess upfront how many updates a device might require.

This problem is compounded by the poor software practices at most manufacturers. It is non trivial to set up a software practice that keeps the cost of ongoing development in check. More model numbers and large fleets increase the development and QA costs. The per unit costs go down, but the absolute dollars go up.

2. The second issue is that IoT devices have a symbiotic relationship with other systems, and the financials for the overall product are tightly coupled. For example, consider cold chain monitoring systems. These devices are simple: measure the temperature, and send the data to a cloud-based pipeline. Alerts are forwarded to another. The value is in the outcome: alerting users to problems. However, to be competitive, the manufacturer might sell the hardware at a loss. If the _system_ is unprofitable, the vendor might turn off the system. In this case, it's hard to demand that the vendor provide updates for a defunct system. In the worst case, companies will go out of business and all the regulation in the world won't really help the consumer. Or the large companies will simply set up shell corporations to shield themselves.

Some in this thread suggested that all the software be open sourced. This is a fool's errand, IMHO. Forcing manufacturers to do this isn't viable because they often don't own the entire software stack: they have suppliers who own the IP, who in turn have their own suppliers. And it's really hard to draw the line in embedded systems. The BSP, RTOS/kernel and applications are all tightly coupled.

"But I bought the software!" you say. Yes, you did. You bought a binary snapshot in time of a software system. Unless you're paying for perpetual updates, you didn't buy unlimited free updates into perpetuity. And you definitely didn't buy source code.

So, what's the solution? I don't have any silver bullets, but here are some thoughts:

1. For many devices, allowing the user to replace the microcontroller outright is the ultimate consumer safeguard, while protecting IP. If the vendor doesn't provide updates, or goes out of business, the owner can replace the MCU or SOC. And it protects the IP of the manufacturer's supply chain. This requires a clean separation of concerns, and it also would allow competitors into the market. But this is the best actual safeguard to consumer protections and respecting IP. There are a lot of ramifications to this. The user instantly voids the warranty, and would need to take responsibility for the security and safety of the system. But for a lot of use cases, this is fine.

2. Incentivizing a secondary market to encourage third-parties to take over failed systems. For example, if a vendor winds down a failed IoT project, give them a tax break to sell the system to a third-party, or open source it. This would give vendors a lot more reasons to try and own/license all the IP to make it open source-able. There _are_ knock on effects: the third-party might charge for updates, or raise prices.

3. Incentivizing common hardware/software platforms. Here's the reality: most manufacturers don't really want to write their own software. They want to sell hardware: it's what they're good at. Encourage more generalized software architectures for IoT devices. This will reduce the costs and enable parts of the system to be updated, without requiring access to the entire system.