MANY of us have had the experience or the displeasure of having to interact with if not use appalling tools which are neither needed nor desirable, usually because those are imposed by somebody else. That does not have to be imposed by a boss; sometimes it's a peer.
"The developers aren't happy. They don't truly feel productive."Intel is alienating its very own developers. Intel is recruiting the wrong people and it is partnering with the wrong companies. We've already discussed a great deal of material in the introduction, interlude, Part I, Part II, Part III, Part IV, Part V, Part VI, Part VII, Part VIII, and Part IX.
In Part IV we've already shown this part:
So, as one can see, developers who are meant to work on technical projects that are as distanced as can be from Microsoft are somehow compelled to deal with horrible things, even though perfectly fine Free software- and standards-based tools already exist and are already in place (at Intel).
"I do have firsthand experience with people refusing to use a changed/new process," somebody told us. "However, I was surprised to experience the resistance of using Free and Open Source Software - by developers working on GNU Linux Projects."
"Understanding the learning curve may have been a challenge for some," we were informed, but "the engineer refusal was unexpected."
It's true that not everyone at Intel loved the workflow, but we're told that the technical people -- i.e. those doing all the work which matters -- did like it and those who did not were in the minority (putting aside "DX").
A person familiar with Intel (from the inside) said s/he would not comment on "Intel's use of proprietary Microsoft formats, but it's standard practice at companies that are partnered with Microsoft and have the company's technologies deeply embedded in their desktop infrastructure, which again hints at the fact that Intel doesn't really support free software but rather tolerates it to prevent other semiconductor companies from taking up a prominent role in the free software world [and] as for vapourware we only have to look at Itanium and Larrabee derived architectures such as the Knights Landing/Mill add-in cards, which were total failures in the marketplace, but because it's Intel people pay attention to them -- and worse waste precious time developing for/with them when they really shouldn't..."
Just a day ago Michael Larabel wrote about Intel's VPU work which targets Linux. "This Intel Vision Processing Unit enablement has now ballooned to nearly 22 thousand lines of code," he wrote, "on top of all the existing Keem Bay SoC support upstreamed, compared to the 15 thousand lines for the VPU code in December."
Our series shows a lot of what's really going on in this department. The developers aren't happy. They don't truly feel productive. ⬆