Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Would you be willing to run "Beta" software on your Model S?

This site may earn commission on affiliate links.
The talk about software and bug tracking in another thread got me wondering:

Would I be willing to run beta software on my Model S? I'm assuming, for now, that problems with the main computer don't affect locomotion, so even if both dash screens are dead I can still drive (this may not be true).

However, given all the things that _could_ go wrong, are any of us so committed that we'd be willing to endure buggy or unreliable software in order to help Tesla get the software tested and perfect?

As for me, I'm not really sure. I've participated in beta tests for CAD software, Tivo, and numerous applications at work - nothing mission-critical. An automobile is a different thing, and we all have some expectation of reliability in the cars we drive.

So: would you let Tesla treat you as a guinea pig, in return for more direct access to engineers to provide your feedback?

/Mitch.
 
.....would you let Tesla treat you as a guinea pig, in return for more direct access to engineers to provide your feedback?

/Mitch.

I would run beta software and write up reports to help Tesla. However, I would have to have the capability to reflash the production software if needed. And, it would have to be completely regression tested by Tesla first. No "Alpha" software for me.

GSP
 
  • Like
Reactions: markn455
Being that I live 8 hours from the closest Tesla service dept I'd be a bit hesitant unless there was reassurance that a simple reboot would get me back to the old software or that there was some simple recovery mode. I'm not afraid of occasional tech glitches in order to try new stuff.
 
I agree with most of the points above. The big reason I would be willing to beta test is having a closer tie to the engineers. I've done LOTS of beta testing over the years and have a good idea of what to expect. My current car is a 2011 Ford Edge with MyFord Touch. Given the current stability of that software, I feel like I already am a beta tester but with no engineering access to do anything about it. :cursing:
 
Would I be willing to run beta software on my Model S? I'm assuming, for now, that problems with the main computer don't affect locomotion, so even if both dash screens are dead I can still drive (this may not be true).

I presume you mean beta Tesla software, not third-party stuff. I don't believe I would, in either case, though. I don't know how critical the software will truly be to basic functionality (beyond just "can the car start/can I drive"...other stuff's pretty critical too, e.g., proper charging, other systems), but even non-beta software isn't always 100% perfect ;-) so I'd rather not risk problems by using software that's not at least supposedly ready for prime time.
 
I'm in. Totally. My career has been Sys Integration by which I mean taking the developers software and shaking it down in the Integration environment. I love looking at it and looking for problems and working with the developers. I would not mind if that last version left me on the side of the road. I'd like a phone number, daytime only is fine.

But you can't get there from here. This is a car. You bought the car. You registered the car in the state. You insured the car. If there is any safety question at all then you can't do it. If anything bad happenned ...

Maybe if you are talking about the radio or the gps as a unit that is totally isolated from it, we could do that. Maybe.

I hear what you said and am totally with you, I would like it, but I think the only way is to be an employee and play on the back lot inside the fence. Ask the lawyers, I think they will have an opinion.
 
Sorry, not in a car for me. I'm a software guy and know that "beta" could sometimes be a catch-all for the crappiest of software, quality-wise. It'd be hard to isolate/sandbox things like apps well enough from the rest of the system that you could go production-quality on one and beta-quality on the other without compromising something. That said, I'll gladly chime in on your discussions on this forum of any new beta stuff that you might be testing for Tesla :wink:
 
I'd do it. IF they give me a direct-line to the engineers. (e-mail counts)

I'd also like them to be able to OTA update the FW. That way if I find a bug, I e-mail them, they troubleshoot/debug, update FW, repeat as needed. (Sorta like what we are doing with the OVMS.)
 
You think you'll have a choice? ;)

Companies will ship to meet a deadline regardless of the code status. Since pretty much every product is late, pretty much all released code is beta (or sometimes alpha). Then they patch it later.

I'd hope they would have the discipline to ship less functionality in exchange for fewer bugs and a better overall experience. So: if it's buggy, don't ship it, remove the feature and get core functionality 100% solid. Judicious use of 'No' by software managers can make a good product great.

"Beta" software people (who sign up and know what they're getting into) get to shake out the stuff that didn't make it for the current golden release.

/Mitch.
 
I was referring to code quality and stability, not formal phases in a release cycle. In my experience standards have been slipping over the years. The fact that users have simply become accustomed to relentlessly patching their software (games, OS's, business software, you name it) implies there has been a distinct move away from writing stable code and towards jamming as many features as possible into a release. At my company, if QA finds a major bug that delays a release then that just gives mgmt time to jam more features in. I know my company is not alone in this regard. So yesterday's alpha is today's beta and yesterdays beta is todays released code (as far as stability goes).
 
I was referring to code quality and stability, not formal phases in a release cycle. In my experience standards have been slipping over the years. The fact that users have simply become accustomed to relentlessly patching their software (games, OS's, business software, you name it) implies there has been a distinct move away from writing stable code and towards jamming as many features as possible into a release. At my company, if QA finds a major bug that delays a release then that just gives mgmt time to jam more features in. I know my company is not alone in this regard. So yesterday's alpha is today's beta and yesterdays beta is todays released code (as far as stability goes).

In a less cynical light, the mere fact that games and software can now be patched usually means that deadlines can be met, and that by the time you install your software or run your game updates are available to enable functionality or find bugs that were found after shipping.

I remember how long it took to ship games in the past because of how long the test cycles were. Now they can test, less thoroughly yes, but find most bugs, and if any others arise (usually minor), patch them OTA. Surely that's better than delaying the product 6 months or more?