After offshoring and near-shoring, there is a new outsourcing trend: domestic outsourcing. For example, a company in California outsources work to a company in Indiana or Wisconsin. A New York Times article sheds some light on the reasons for domestic outsourcing.
First, agile development rules.
But today, companies in every industry need mobile apps and appealing websites, which can be made smarter with data and constantly updated. That software is best created by small, nimble teams, working closely with businesses and customers — not shipped to programmers half a world away.
Second, “rising labor costs abroad also make domestic sourcing more attractive”.
A decade ago […] an American software developer cost five to seven times as much as an Indian developer. Now […] the gap has shrunk to two times. The standard billing rate for [the] engineers [of the US company Rural Sourcing] is $60 to $70 an hour, compared with $30 to $35 in India […]
I think that domestic sourcing is a bigger trend, where work moves to the people and not the people to the work.
Grimme moves the HMI for changing the nominal values of the 80 most important harvesting parameters from the driver terminal(s) to an extra piece of hardware – called ErgoDrive. Four rotary knobs next to a small display enable the driver to change the nominal values of the 80 most important harvesting parameters.
As the driver looks at the display at a flat angle, he will probably have difficulties to see anything on the display. He must either memorise which of the four knobs does what or bent forward. Is this really more ergonomic and easier to use than showing the direct-access parameters on the terminal screen and changing them through a special rotary knob?
Another thing is clear: Moving software functionality into dedicated hardware is certainly more expensive or less economic for the customer.
The Qt Company published a guest post “Qt QML v HTML5 – a practical comparison” and a whitepaper by the Austrian Qt consultancy Sequality. Sequality had one developer writing a simplified application for controlling a bottling plant first with Qt and then with Web (AngularJS). The developer had 160 hours for each implementation. The application had to run on a tablet, a PC and a Raspberry Pi 3 with different resolutions.
Here are my favourite findings of Sequality’s experiment.
- The developer finished considerably more functionality with QML than with Web.
- Higher efforts to use OpenGL acceleration for Web: “Enabling GPU rendering on Chromium […] doesn’t fix the HTML5 demo’s performance problem. In fact, the CPU is utilized even more, which leads to overheating.”
- Higher efforts for testing Web: “The fact that HTML5 applications can be executed on a number of platforms – and a number of browser engines on each platform – multiplies the testing time correspondingly.”
Just three years ago, this would have been unthinkable. GM publishes an SDK (NGI SDK) to write apps for the infotainment systems of its cars and an app (GM Dev Client) to run the app in the car.
General Motors has launched GM Dev Client, an industry-first app that gives approved developers who have created in-vehicle applications the ability to test them in a real GM vehicle. In-vehicle app testing is the next step for app developers who have already created a proof of concept using GM’s next-generation infotainment software development kit (NGI SDK).
Of course, you need a car or at least access to a car from one of GM’s brands, which is a bit tricky in Europe. And, it is must be a model from 2017 or newer.
For Nathan Tennies from Barr Group, the answer seems to be a resounding “yes”:
It’s frankly hard to see how automakers using AGL—or other infotainment platforms—will be able to keep up with Google. […] And for some automakers, putting the kibosh on Google may ultimately be more important than providing customers with the best IVI experience […] But mobile giant Samsung provides a cautionary tale about the difficulties of competing with Android.
Samsung and the other Android handset makers provide a cautionary tale why using Android is a bad idea. The premium handset market is heavily dominated by Apple’s iOS. Customers are willing to pay prices of 700 Euros and more for an iPhone, because iOS is the big differentiator from Android.
Why should customers pay 700 Euros for Android phones, if 300 Euro Android phones are good enough for them! Android OEMs can only differentiate on price. And their average selling prices have been declining for years.
Car OEMs would be stupid to bet on Android. They would give away an easy and compelling way for differentiation. I can’t see this happening for premium car makers like Daimler, BMW, Porsche and Tesla. They are currently investing heavily in operating systems other than Android.
Ten years after the iPhone and several years after its competitors like John Deere and AGCO, CLAAS announces that its CEBIS terminals will sport a touch display (see their press release).
Mark Hatch, the COO of the Qt consultancy ICS, gives four strong arguments, why projects should pay for Qt Commercial instead of using Qt under LGPLv3 for free:
- Reduced obligations/greater flexibility of distribution
- Additional features
- Technical support
- License negotiation
Mark’s argument would be so much stronger, if The Qt Company published its license fees or at least gave some ballpark figures. If potential customers had a rough idea of the costs, they would think something like this: “Wow, Qt Commercial is much cheaper than I thought. I get some killer features on top of the free license. I have absolute peace of mind when deploying my application on devices. Let’s contact sales. I am sure I can get a good discount.”
Now compare this with the current situation: “I hate calling sales people to get a first quote. They’ll call me twice a week for the next four weeks. I really hate this. OK, I’ll call them next week.” It is unlikely that Qt Sales will ever hear of this potential customer.
We have succeeded in building embedded Linux with Yocto for a quad-core NXP i.MX6 (ARM Cortex-A9). Next, we want to cross-compile our own Qt application. As we use CMake for building our Qt application, we must create a CMake toolchain file. I am going to give a line-line by line explanation of the CMake toolchain file. I used Yocto Morty and CMake v3.5.1 (as it comes with Ubuntu 16.04 LTS).
It is not easy to find hard data about how much the QtQuick compiler can speed up the startup of real-life application. As I had some time on my hands this weekend, I measured the startup times of the HMI of a maize harvester running on a quad-core NXP/Freescale i.MX6 (Nit6Q_W_BCOM). Using the QtQuick compiler from Qt 5.7 brings the startup time from 2.72s down to 1.91s – a speedup of 30%!
Tuukka Turunen from The Qt Company shared some fantastic news in his post Aligning with the Yocto Project.
We have created a separate Boot to Qt meta layer, meta-boot2qt, which takes care of building the images and toolchains for the reference devices. The meta-boot2qt layer integrates all the required BSP meta layers, so there is no manual configurations necessary when starting Yocto build for one of the Qt reference devices. The layer was previously available only for our commercial customers, but with Qt 5.7 we have open sourced it as well.
The Boot2Qt meta layer comes with support for all three versions of the Raspberry Pi, many i.MX6 boards (Nitrogen6x, SABRE, Colibri, etc.), the NVIDIA Drive CX and for the Intel NUC. This should make the live of embedded Qt developers a lot easier. Thank you very much, Trolls!