The incumbent car manufactures, by which I assume you mean GM, Ford, Chrysler, Honda, Toyota, and the like, are operating a far different market segment. They face a much more difficult market, where profit margins are tighter, because they by default aim to the mass market.
Tesla is operating in the upper luxury end of the market, where margins are fatter, where vehicles sold can be lower but the margins maintained. They are making very large cars, even their follow up model to the S is the same wheel base. Why is that? Most likely because Musk knows they cannot deliver the range needed at cost and more importantly, a size, that a smaller car will be.
There are many self driving efforts going on in the market, both Mercedes and Infiniti have vehicles on the market that offer some limited form of self driving. Mostly lane departure and the like but they are pushing distances.
Tesla should be the one who worries most, because they have a unique product only for a short time and they won't get into the smaller sized car market because the technology path they have followed is not progressing fast enough.
If they made a car the size of standard midsized car, lets pick Fusion or Accord, the wheelbase shrinks by ten inches on average, width comes down too. All that shrinkage will take away from battery capacity, hence range. That is one reason many of the offerings by the incumbents have less range. Many use a battery solution not all that different, just restrained by size and technology.
There was a reason Musk went for the price point he did, it allowed larger vehicles which current technology requires. Never bet on the incumbents sitting still, Musk certainly is not. It just comes down to, can Tesla execute well in the mid size market, should they ever get there. Who knows, he made cede that space by licensing tech to let other people work the small margin sales
It depends what market segment you're looking at. If it's the 'Electric Car' market, Telsa are pretty much the leaders in this segment apart from a handful of super-micro city cars.
If you mean the 'Performance Car' market, apart from one or two niche offerings and prototypes, the usual manufacturers should be spooked by Tesla's potential to realise and implement new technology.
Musk makes no secret of his positioning in the market and going for the price point that they have. But there are hundreds of different cars at the same price point of the Model S, none of which are even in the same ball park.
The necessity for the incumbents to appeal to the mass-market is exactly why they should be worried, they're business relies on so many manufacturing synergies to reduce price, adapting all of those chassis and systems to cope with electric drive and self driving is going to be a challenge if they're to sell to their exist mass-market customers, at a price they expect. Tesla doesn't have that problem.
Tesla leads the electric car market in technology, but not in volume; there are many more LEAFs on the road today than there are Teslas. Total sales for the LEAF are about 65,000.
Tesla is delivering 550 cars per week[1], which is about 2357 per month. In August Nissan sold 2420 Leafs[2]. So seems like sales are just about equivalent. Except that Tesla is supply constrained and sells direct to consumers, so that 2357 underestimates actual sales. And many of those Leafs are sitting in dealerships, while none of the Teslas are.
Now Telsa only sold 5k cars in 2012, so it's doubtful they have on the road more than half of the 75,000 Leafs that have been sold[3]. But the Leaf started shipping in December 2010[4] whereas the Model S started shipping in June 2012[5] so it's not exactly a fair comparison.
The Chevy Volt actually did better than either in August, with 3351 sales[2]. Although their year-to-date sales were the same as the Leaf (14k) which suggests they had some late resurgence.
You're comparing US LEAF sales with worldwide Tesla sales. Worldwide LEAF sales are around 4,500 a month. In the US, at least, LEAFs are in high demand. In Atlanta dealers have only 120 hours of supply. Before the Model S, Tesla sold the Roadster, but the numbers were so low they don't affect the comparison.
At this point one can only talk about installed base as both Nissan and Tesla cannot meet demand. Nissan makes its own batteries but cannot make them fast enough. And of course the markets are fairly different. The LEAF is much, much cheaper, and is in no way a luxury or performance car.
Tesla is trying to catch up to other manufacturers here: Mercedes has sold cars with lane assist (preventing drifting out of lane) since 2009 and Ford has a self-parallel-parking system for a while.
A lot of companies with a "hardware" background have trouble writing software - they simply do not grok the management mentality and organizational culture that is required to do it efficiently. More to the point, they have difficulty distinguishing between ill-disciplined cowboy development and the agile, fast-moving (albeit highly disciplined) approach that you really need to have to develop complex systems without exponentially sky-rocketing costs. This culture may be changing (slowly) - but my gut instinct is that Tesla stands a chance to throw them some surprises before they do.
A lot of the difference between the (for want of a better word) "software" mentality and the "hardware" mentality comes from how we approach risk. One approach emphasises mitigating the impact of adverse events by emphasising flexibility and agility; the other approach emphasises minimising the chances that adverse events occur at all, by emphasising predictability and control.
In other words, do you design so you can fix it quickly when it breaks (at the expense of having it break often), or do you design it so it very rarely breaks (but when it does, it is more expensive to fix)?
The answer to this question not only depends on how safety-critical the system is, but how complex it is too. The prediction-and-control approach rapidly becomes untenable when you have systems that reach a certain level of complexity -- the cost of accurately predicting when failures are going to occur rapidly becomes larger than the cost of the failure itself. As the complexity of the system under development increases, the activity looks less like development and more like research. The predictability of disciplined engineering falls apart in the face of sufficient complexity. Worse; complexity increases in a combinatorial manner, so we can very easily move from a predictable system to an unpredictable one with the addition of only a small number of innocuous looking components.
Most forms of mechanical engineering emphasise the second (predictive) approach, particularly for safety critical equipment, since the systems are simple (compared to a lot of software) and the costs of failure are high. On the other hand, a lot of software development emphasises the first (agile/reactive) approach, because the costs associated with failures are (normally) a lot less than the costs associated with development.
Of course, a lot of pejorative terms get mixed up in this, like: "sloppy engineering", and "cowboy developers", vs "expensive failures" and "moribund bureaucracy" but really, these approaches are just the result of the same cost/benefit analysis producing different answers given different input conditions.
Problems mainly arise when you use the wrong risk-management approach for the wrong application; or for the wrong part of the application. Things can get quite subtle quite quickly.
One of the challenges in developing automotive ADAS systems is that a lot of the software is safety critical, and therefore very expensive to write, because of all of the (necessary) bureaucratic support that the OEMs require for traceability and accountability.
Equally, a lot of the advanced functionality for machine vision / Radar / Lidar signal processing is very advanced, and (unfortunately) has a lot of necessary complexity. As a result it is very very costly to develop when using the former approach; yet may be involved in safety-critical functions.
This is not by any means a solved problem, and very much requires detailed management on a case-by-case basis.
Certainly testing infrastructure becomes much more important as the sensor systems that we develop become more complex. (Disclaimer: my area of interest). Indeed, my experience indicates that for sophisticated sensor systems well over 80% of the effort (measured by both in hours of development & size of the code-base) is associated with test infrastructure, and less than 20% with the software that ends up in the vehicle.
Perhaps the word "test" is a misnomer here; since the role of this infrastructure is not so much to do V&V on the completed system, but to help to develop the system's requirements -- to do the "Data Science" and analytics that are needed to understand the operating environment well enough that you can correctly specify the behaviour of the application.
