There are pros and cons to this. One con is that the next developer might have to spend considerable time buying into your ecosystem to be productive. A pro is that it is easily maintainable by you since you built it; which is also a con since it's not generally feasible for a single developer to cover all the in's and out's of a web ecosystem. Lets say you pass away tomorrow, and a week from now a major security vulnerability is announced that affects your system. If you had used a mature framework (Such as Laravel) with a auto update system in place, the issue might be patched in 1-2 weeks. Whereas in this hypothetical the company has to hire a developer that now has to ramp up on your software, be familiar with the security vulnerability, know how to patch it, and have some guarantee that your system will behave as expected. This puts the burden on both the employer who might not know how to screen the applicants because it's not their domain, and the developer.
Saying software is clean because it is untangled from a larger code base is misleading for most use cases, but especially so for web development. It is also not fair to treat front end and backend code in the same context as you can easily decouple both without (since you didn't mention if the backend itself is custom built by you or not, but it seems implied)
I had a similar repeated experience and filed a complaint directly with Amazon by calling their support line and elevating it to logistics and implying that the driver might have stolen the package. I'm sure this is a well known tactic and that they log it as it gives them leverage against an unruly contractor.
I wish Amazon would add a $1-3 variable shipping charge to 2 day shipping (which is already very cheap) which gets pooled and awarded to the delivery people based on performance metrics (complaints, delivery times, damaged packages).
Using stackshare stats for software adoption is somewhat disingenuous. Companies aren't required to disclose what they use, and many don't. You are also more prone to finding similar tool stacks in similar companies (new tech, startup, enterprise, etc...), this isn't even mentioning that the only two software solutions you presented for document management take two very different approaches for monetization, and your post implies that you value the convenience of customer-as-a-product models which we don't have the stats available to back which approach is better. That perspective is also not valid anymore as even Office, and the likes of Libre Office now provide similar conveniences of cloud backed storage and web interfaces.
I worked for a electric meter data analysis company that worked with local government owned utility companies. This is a complicated issue with a lot of potential reasons. My professional opinion is that yes, it often is cheaper to for municipalities to install solar in the long run, but there is a lot of uncertainty about the technology and the fragility of the proposed systems.
Depending on the energy generation, utility companies have long term fuel contracts which often work against long term investment in renewable energy generation. Local tax payers will have to pay for the deficit or potential contract penalties if the city reduces their energy generation requirements while still having a fuel purchase contract. That coupled with the investment cost of installing solar/wind generation infrastructure is a hard sell for elected officials who depend on short term impact to maintain their constituents happy.
There is also the question of legality, as some states have strict laws on who can generate electricity and who can store it/sell it. Typically the smaller and less progressive the region, the more likely they are to go towards the path of least resistance and just let the homeowner brunt the cost.
So some consumers install it for the long term gains without placing any bets on how local utilities will react, while others might do it as an investment on the property itself. These are just a few scenarios (without talking about commercial energy consumption) out of the hundreds being discussed.
It is becoming more common now for utilities to have energy surplus buy back programs that reduce the energy cost to the end user while they wait for the industry to progress past their latest infrastructure investment (a lot of local municipalities had huge infrastructure investments in the 90s / early 2000s that they are still paying for)
Only the parts that they took from other reverse engineered header projects are opensource (because they have to). They answered on one of their Github issues that the actual core code is not open source. I wouldn't touch this.
Unfortunately you touched on what makes this specific case a problem: Their solution is non-patentable. They failed to do a appropriate post-mortem of their business and instead resorted to blaming Apple for their failure.
Yep, it didn't seem like a viable business model. It's also a major security concern since it's not specifically selling a VPN solution, so the laymen user might not comprehend how the app works despite the app attempting to inform the user. I personally think it's naive to claim Apple copied their idea, since this was already something iOS and Android had support for from their related power management stats tracker.
Saying software is clean because it is untangled from a larger code base is misleading for most use cases, but especially so for web development. It is also not fair to treat front end and backend code in the same context as you can easily decouple both without (since you didn't mention if the backend itself is custom built by you or not, but it seems implied)