> So you have zero sympathy for the fact that this creates an unequal playing field?

I have, it creates an unequal playing field between you as a company and me as a user. It reduces my ability to adapt a product to my needs. It reduces my ability to learn from it. And yes, it also reduces my ability to reverse-engineer it, improve it and then become your competitor. It stifles progress.

You've completely ignored all my arguments and made a counter argument... =S

To address it, I think that when you say "creates an unequal playing field between you as a company and me as a user" that's a bit of an apples to oranges comparison. When I say playing field - I'm comparing two potentially competing software companies (one just happens to have a mechanism to physically separate you from the code you in-effect use)

You have no ability to learn from Google even though you use their search engine - you can't reverse engineer it or improve it. Does this upset you? (again, you will probably ignore my question)

> You have no ability to learn from Google even though you use their search engine - you can't reverse engineer it or improve it. Does this upset you?

I do, in so far as it interacts with my machine. I can look at the APIs, at the traffic patterns, at whatever code is shipped to my browser. But yeah, the secret sauce stays on their servers.

But then again, comparing Google to VW is apples-to-oranges too. Google is a software company, VW is a car manufacturer that incidentally has to write code for their engines. They are not competing with each other, they are not playing on the same field. So VW having no way to use SAAS for ECUs (thank God) is as much unfair to them as their DMCA restrictions are unfair to me (the user).

Well actually they compete for the same workforce

So if you run a SAAS company you have the ability to create a giant monopoly make billions and buy up all the talent, and if you run a device/native-code-based company you should be relegated to fighting on the margins making returns in the window between your code-release and your competitors' reverse-engineering?

I'm not even sure what to say other than.. don't you think that's .. silly?

I think you can see the effect of this on VCs, where most funded startups are SAAS-ish, and you'll never get funding to make a product that's native.

This distorts the whole industry

A simple example is face identification. Facebook has some secrete sauce for doing an amazing job. You upload a photo and it almost always knows which one of your friends it is. I'd love to have a native app that does that for all the photos on my phone. Am I ever going to see it? No, b/c anyone who is half way decent at that stuff will go work for a SAAS company and make a lot of money by keeping his/her innovations as "secret sauce"

If you want an apples-to-apples comparison, why not look at the actual physical devices that Google is selling? To the extent that Google and VW are "competing for the same workforce", the folks writing code for the Nest, OnHub, or heck even Android are the ones you want to be thinking about anyway...

...And more importantly, the implications for the folks buying and installing these products are a hell of a lot closer to those pertaining to VW's ECUs.

If you're gonna argue for a level playing field, it probably helps to start with teams that are playing the same game, or at least one that's reasonably similar. Right now, you're arguing that Google's bobsled team would unfairly compete with VW's baseball players, ignoring that Google fields a cricket team as well...

> ...you should be relegated to fighting on the margins making returns in the window between your code-release and your competitors' reverse-engineering?

One's ability to profit from reverse-engineering a competitor's hard/soft/firmware is not unlimited. IIRC, if the purpose of the product of the RE isn't to be compatible [0] with the RE'd 'ware, then you absolutely have to do a dirty room RE and documentation followed by a completely independent clean-room reimplementation. This raises the cost of the endeavour by at least 2x.

See, the original holder of the copyright on that 'ware still potentially has a real claim on the product of a solely dirty-room reverse engineering endeavour.

Additionally, AIUI, many software licensing agreements make the situation a little more difficult and uncertain for our would-be reverse engineers.

And, if the thing you're RE'ing makes use of patented material, I suspect that things get rather expensive rather fast.

[0] That is, to work alongside or enhance the 'ware.

Regarding an equal playing field, if all actors in the same space have the same constraints, I don't see how it distorts anything. There are already plenty of standards for aeronautics, healthcare, automotive, (MISRA, DO178,...) that don't apply to other fields. Does it creates an unequal playing field ?

Well I'd argue that in general companies that have been able to shift their business into remote servers are doing much better.

In fact I can't think of something that runs native on a device and is better than all it's competitors that run "in the cloud"

B/c the biggest difference is that by having the secret sauce physically in the hands of competitors, you aren't able to create a vast difference in the quality of your product.

Following standards creates horrible barriers to entry and to innovation, but at the end of the day you aren't spilling the beans on how you do all your tricks. You can't make some fancy new valve control system no one will ever figure out.

Then you look at someone like Google, and it's 100% driven by secret recipes no one knows about

Maybe there should be indignation about trade secrets, but I feel like the physical distance to the code you are running is irrelevant.

When I search for a word or phrase on Google, I'm running code remotely on their server. Yet no one feels like I should have the right to see that code. Why?

> When I search for a word or phrase on Google, I'm running code remotely on their server. Yet no one feels like I should have the right to see that code. Why?

Because I have not paid money to Google purchasing a tangible thing. If I buy any tangible thing, it should honor the doctrine of first sale, and I should be able to modify my tangible thing as I see fit. It is my property.

Google is akin to a remote service provider; I send in a thing, modifications to my thing are made, and then I get the thing back. I don't ask my warranty repair firm or any other entity that provides a remote service how they did it. I simply make a request at an agreed-upon price (or agreed upon terms: you'll provide ads in exchange for the service) and if the terms are not satisfied I will not hold up my end.

For small businesses it does. There's a huge cost to be compliant with the regulations in medical and aviation space, so you don't see many successful startups and not much progress as a result. We are still flying WWII rockets and use crude antibiotics.

> There's a huge cost to be compliant with the regulations in ... aviation space, so you don't see many successful startups and not much progress as a result. We are still flying WWII rockets...

SpaceX would like to have a word with you. IIRC, they've designed and built -from the ground up- their own rockets that get payloads to orbit at 1/3 the cost of anyone else.

The other players are still flying rockets either largely designed in or actually from the 1960's [0] because not many of the folks who need things in space understand how to build rockets. This means that -much like the telecommunications "market" in the US- incumbent players can put next-to-nothing into R&D and new tech and just sit around and watch the fat paychecks come in.

It's an industry that's in dire need of a shakeup.

[0] WWII was from 1939 to 1945. ICBMs [1] are substantially more sophisticated than any rocket from WWII.

[1] Which are effectively what was transporting the astronauts in the Apollo program.

Regulations are not what is responsible for us flying WWII rockets and using crude antibiotics; they're responsible for those rockets not exploding too often or those antibiotics not killing us in most painful ways imaginable. Rocketry and medicine are hard.

Some fields are more capital intensive than other. It is much easier to launch a mobile app than an oil refinery. It does not distort the competition between companies who have to follow the same rule book.

I understand where you are coming from but you need to have a minimum threshold for software that is going to be a matter of life and death.

Google isn't responsible for software that could glitch out and apply your accelerator directly into a concrete wall.

Like the GP said, physical devices that have a use that is in some way responsible for a human's safety or some element of real risk (cars, medical equipment, fridges, ovens etc.) should have inspectable source code. It need not be open source, just able to be viewed.

That said, if companies are willing to cheat emission schemes they'll probably obfuscate their code to "protect IP" or something.

I'm not saying that it's impossible for cloud software to harm a human, but every example I can think of is fairly contrived and would probably result in somebody reading the code and going "Why does this x-ray query a server for this person's safe dose?"

Dear shill, if you don't want to see the code for your device, don't look at it.

The right of other less optimistic consumers and government agencies are more important than the desires of your device maker.

Additionally, if companies lease devices they are no less accountable for the code on them.

Well, the company could rent a device instead of selling it. Just like google provides services, instead of selling its code.