Herein you’ll find articles on a very wide variety of topics about technology in the consumer space (mostly) and items of personal interest to me. I have also participated in and created several podcasts most notably Pragmatic and Causality and all of my podcasts can be found at The Engineered Network.
Patent Bile Part 3: Lodsys pushes ahead with Lawsuits anyway
Well now, Lodsys is back firing again at the relatively helpless App Developers and is now suing 7 of them for Patent Infringement. Their blog article rejects Apples position and their response. So it seems they are intent on exploiting that which they did not develop or enrich or create themselves.
Apple is now in a difficult position. It has really two options: 1) If possible - engineer out anything that is covered by the Lodsys patent from their product offerings; or 2) Hit Lodsys with a lawsuit of their own. If Apple don’t do anything, the potential implications are that developers the world over working on iOS applications will inevitably be charged a levy to Lodsys and draining their incomes.
That said, is it a platform problem? I don’t believe it is due to the vague detail of the patent as Lodsys will simply hit Android and Windows Phone 7 next. There will certainly be less developers keen to work in mobile due to Lodsys, but it may well be a case where Google, Apple and Microsoft have to band together to fight Lodsys or risk failing individually.
I think Apple really have to option to respond forcefully, legally, to Lodsys and their claims. They would be wise to seek help from their peers if they can.
Patent Bile Part 2: Apple Hits Back at Lodsys
After my previous article I waited (as many others did) to see whether or not Apple would stand by its developers. Yesterday it did with a formal response to Lodsys: the full text is found at MacWorld but if you’d like here’s the summarising paragraph: “…Apple requests that Lodsys immediately withdraw all notice letters sent to Apple App Makers and cease its false assertions that the App Makers’ use of licensed Apple products and services in any way constitute infringement of any Lodsys patent.”
It was so very important that Apple stand up for its developers: there’s little evidence to dispute the fact that developers have helped to make the iOS revolution possible in a way that is currently beyond any other operating system.
With the ball back in Lodsys’ court they can either push on and dispute Apple’s claim that Apple do not in fact have the usage rights to their patent(s) or to shrink back into their shell. Stay tuned.
The Looming Android Apocalypse
I have previously written about Googles problems with updating their Android operating system over the air - especially when the carriers will often customise their phone-specific builds of Android to give the end user a carrier branded experience - usually after the handset manufacturer gets their hands on it. Nothing much has changed on this front practically speaking. These problems are real, but they suddenly became glaringly apparent last week when a vulnerability in Android was found.
Since then Google has been able to patch most of the server sides to correct the problem. 99.7% of Android users wiped the sweat from their collective brows and moved on with their lives.
Here’s the thing: what if it was not possible to fix the vulnerability on the server? What then? Google would be in the near impossible situation whereby phones of different OS revisions would need a patch/fix/update to fix that vulnerability. That’s fine - they could create forks in the OS at different points and publish the fixes but then how to ensure/enforce the manufacturers and carriers to push the updates through to the end customers?
No software and therefore no operating system is infallible. Eventually Android will have a major issue that can not be resolved with a server-side fix. At that time, it’s fragmentation and approach to updating will come back to bite them, and their customers will be left hanging in the breeze.
That’s okay though, because they’re “open” remember?
Supportability and Trust
If a customer asks me how best to provision spare parts and on-going support for their control system, the first question I ask is: “What kind of mean time to repair are you able to live with?” The second question is: “Does your control system hardware and software have a single integrator or multiple integrators able to support it?” Why is it no-one else thinks about these things?
Technology will always die in the end. Capacitors and resistors drift, dry and die over time and these are failure mechanisms that can not be prevented. Whilst every effort is made to protect equipment from damage, lightening strikes do occur, as do power surges and brown-outs and all of these are outside the control of the customer and can cripple their control system assets. Hence it is not a question of: “Well it’s really reliable and we’ve never had a problem with it” or “So and so have always supported us so that’s all we need to worry about”. Natural events, external factors, businesses going out of business are always going to happen. The real question is have you invested wisely in your control system software and hardware: beyond price and features? Most customers don’t.
I recently visted a process plant with a somewhat rare control system. When asked, “Do you keep spares on site?” their answer: “Why would be do that? The supplier/integrator (same people in this case) keeps them all for us”. Problem was, this supplier/integrator are the only people that supply, service and maintain their equipment and software and are thus a sole source of supply. If they decide to close up shop tomorrow they will have a completely unsupportable control system. This didn’t seem to bother them.
In the long run these ideas of an expensive single source of supply and support simplify the management side of the site, but leave the business depending upon that control system with no options if something ever goes wrong. It’s short-sighted. It’s dangerous. In the end, it will catch up to the customer and they will lose.