I don't think low cost is really a major factor. It is convenient to boost the margins a bit but not really necessary. The primary reason to hire them as contractors is that don't really want the talent in-house.
From my perspective, the primary reason for shifting talent from in-house to contractors, is per cost reasons (get permanent employees off of the payroll, as their tasks have been reduced to less than is required for a full time employee <cost savings is more than just wages>).
There isn't that much time needed for the MP, but cycling people to and from the various devices to service the MP line hurts their more profitable device market.
So instead of hiring on full time employees that may only work 6 months or less isn't attractive vs. using contractors that do this sort of design work regularly.
You are getting caught up on what companies name is the the badge. That's relatively immaterial.
Actually, I don't care about the name on the badge. Rebranding happens all of the time generally speaking.
If Apple management retasks the associated software folks ( who happen to be Apple employees ) to other projects why would they fund the hardware half of the system. They either engage the whole system or they don't. There are mix of resources that can be (and probably were ) deallocated. That's personnel , material , and money. In the contractor case the "money" nukes them.
I think there's a misunderstanding here as to what I was referring to.
My comment was aimed to the effect of pulling in software and key developers (from a software company buy-out) for a ready to go or nearly so (add a few UI tweaks) as a means of offering additional value to the platform. By doing so, they can attract new users in the professional market as they've done before.
The other key point to this, is it also allows them to have complete control over the development rather than running the risk of partners or external contractors that could make a mess of it, or leak/steal their IP.
With the Mac Pro they have a slow moving market base. Most users only update every 4-6 years. For the folks 1-4 years into their Mac Pro they probably aren't moving anyway.
Which is part of the problem in regard to the poor growth figures as they've lost the former enthusiasts in this segment due to being priced out of the market.
To keep the product around, they need growth. One way to do this is via pricing, but I don't expect this to be the case without a reduction in level of CPU (shift from the enthusiast socket to something from the mainstream line). Second is to add value through features that give a better overall user experience and TCO, which from what I've seen of Apple's history, is more likely to be how they'd approach it, assuming they genuinely plan to stay in this particular market long term.
early 2013 Sandy Bridge , skip Ivy , and catch Haswell (presumably in 2014) " [ I think there is an assumption that Haswell Xeon E5 is coming ~Q3 2014. That probably is quite aggressive ]
Given the delays in releasing SBE5 and the lack of competition from AMD in this segment, I don't expect Haswell to be out that soon either (expect more like H2 2015).
"long term" gap in these contexts is less than 1-2 quarters (not even a year) behind the vendors who do "releases" along Intel's schedule.
Keep in mind however, that there will be a board change during this process (SB comes on late, and that board is to last through IB, then a new board needed for Haswell).
If Apple continues to try and sell IB systems when the PC counterparts are selling the newer Haswell based systems, then they will either lose sales, or those buyers will wait for the newer hardware causing a negative effect for that particular quarter or two. If the previous quarters are good enough to make up for this, then great.
I'm just not convinced that this particular market segment is large enough for Apple that such an instance would be possible however. Thus my belief that Apple would need to add value to this particular market to maintain a sufficient sales volume (retention at a minimum, but better yet, if it's good enough, it should attract new customers as well).
The gap between the 2010 Mac Pro and the 2013 Mac Pro was a mistake. If they repeat it then that would be a problem.
Definitely.
Unfortunately however, I'm not convinced that they see it that way (intentional, as they've already decided on a fundamental shift in what they're going to offer in this segment).
I genuinely expect Apple will take a crack at SP variants only before other vendors. And if their goal is to pick up additional users, that this could realistically be based on a mainstream part, thus starving professional users of the PCIe lanes they tend to require for over-all system performance.
Eh? AutoCAD title ports to OS X are up over last 6 years. There is movement to OS X this is being driven by OS X's increase share of the PC market. Most of the vendors whose software costs as much or more than a entry Mac Pro (and/or have GPU requirements that only a bleeding edge Mac Pro can meet ) probably aren't coming over the near term. That's is something Apple doesn't really control. Frankly, creating an environment for smaller, more nimble alternative vendors to rise up and wipe those slow moving software vendors out is a better move for that class of software.
I'm talking about true professional software that would require a MP to run it properly, and specifically, expanding into areas they have little to no presence in right now.
Take Electronic Design Automation (EDA). LabVIEW is the only thing that comes to mind that runs natively under OSX (industry standard) regarding this area. Even National Instrument's own MultiSIM package doesn't offer an OSX variant at all.
Not impossible to run on a MP, but it won't be directly under OSX (either natively under Windows or VM'ed).
And you can forget Synopsis, Altium, or any of the other suites most would be using.
some of the "enterprise" shrink is being driven by global economic drama.
1. Getting back to a regular release cycle would be easy to do. IHMO if decoupling from Intel's schedule would increase regularity then that would be a better move. Predictable targets for ports and predictable devices to buy is a "hook".
2. the "hook" being just one ( or two ) Apple software titles is a huge mistake. One of the sources of workstation decline is myopic focus on a small subset applications. Unless that subgroup is growing a hyper rates ... it just isn't going to lead to long term growth.
It's in Intel's best interest to get back on a stable cycle IMHO, and hopefully, this is just a hiccup on their end. Unfortunately, I'm not sure this is the case due to the increasing issues that occur with shrinking dies, and secondly, due to AMD's lack of competition (less motivation).
Now I get your point on Apple not sticking with Intel's cycle at all, but to me, it goes back to what I mentioned above.
As per software, I'm talking about creating a presence either directly (acquisition), or by enticing existing software developers in areas that aren't currently available for a Mac user. The latter would require Apple to be more willing to work with them better than their history demonstrates (better development environment, and more importantly IMHO, a much better attitude <rather than "take it or leave it">).
Depends on software. Software that scales linearly without some nonlinear increase in costs will get better bang for the buck out of 20 cores than 10.
My SP comment was aimed at Apple, not every vendor. DP systems have, and will continue to have a place for the foreseeable future.
Where I do expect the SP versions to take over however, is for both single-user workstations and GPGPU processing, so long as it's more cost effective than doing this with DP based systems (let's assume that the lane counts will continue to scale linearly with CPU count; so if 40 lanes on an SP board, 80 lanes on a DP board).
This "core count" war is going to stop or at least slow down either after Haswell or Broadwell.
I actually agree with this, particularly given the general state of software (very little can leverage all the available cores).