I own a small farm and work in tech. We are struggling with this issue right now as we look at the options for a new tractor vs an older serviceable model. While many of the larger corporate farms are content to buy new equipment every 10 years, those of us at the small end of the scale have begun a push to keep older equipment up and running.<p>My tractor is from 1996, my hay baler from the early 70s and my hay cutter is even older. These all work just fine even if a little slow. The challenge of not being able to work on my equipment currently outweighs the marginal speed gains I would see on a farm our size. The same goes for nearly all of my neighbors.<p>The last "new" tractor in the local area was bought a couple years ago by one of the older guys who was buying the last tractor he will ever own and he thought it would be nice to have a top of the line, new, tractor just once.
I work in the embedded field and this drives me nuts. I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for.<p>The embedded field is strange because the lock-in is generally on the side of the hardware design and tooling. Nobody is going to try to clone a tractor because they have the source code for it. They also need the CAD drawings, machine paths, tooling, supply chain, etc... Yet just about every company in the space feels that their code is absolutely sacred above all else. Just about everything you own running embedded software that has some update functionality has a bootloader containing cryptographic keys such that the firmware patches/images cannot even be disassembled. For a few devices like routers, some toys, a couple handheld radios and the like, people have been able to modify them through exploits that cause firmware dumps from the uC's memory but otherwise it's typically prohibitively time intensive to rewrite new firmware from scratch without having access to the device schematics (and even then). Worse, just about all these devices have some access to JTAG ports such that you could easily program them yourself if you wanted to and had something useful to flash them with. I've run into so many products I use on a regular basis with bugs or simple but badly needed features that I could have easily fixed/hacked in with access to the source code but alas, I cannot.
As a software engineer with an embedded systems background this kind of OEM behavior driver me up the wall.<p>I've had OEM's:<p>- refusing to provide interface specs of a device of which we just ordered hundreds of units. (But hey, here is the binary windows (!) driver for this embedded device)<p>- refusing to provide the calculation method of a checksum value their device returned.<p>- Stopping software development (tooling, firmware, drivers) on embedded products, even when there are known issues.<p>- Dropping support on a device, even when hundreds of them are still being used in the field.<p>It's not just tractors, its everywhere.<p>From a business standpoint, it's just so dangerous to work with hardware vendors who don't offer implementation details or source code. If they drop support or stop existing, you're screwed...
Companies generally don't want you in the software for safety reasons. While true there is intellectual property around the guidance and swath generating algorithms, companies hate lawsuits. Lawsuits tie up resources, can cause stop shipments, generally lost profits, and tarnish the brand. Look at the Chrysler Jeep news...<p>You hack or change software on a vehicle and cause the auto-guidance to run over and kill someone or you circumvent a safety check in software unbeknownst to you due to your software changes and a spinny sharp thing that should have stopped doesn't and hurts or mames you or calibration changes cause engine to to over-heat and burn up and generally the company is held responsible for it.<p>As much time is spent testing software as is writing software. All our testing is there to make sure the software works as expected. Millions are spent on test equipment and millions of hours and man hours are spent making sure software works as expected.<p>I happen to work for a major agricultural company and I'm a lead software architect for their guidance + autonomous vehicles + precision farming embedded devices. We are one of John Deere's major competitors.
I'm "excited" about the day that I'll be forced to choose between getting a life-saving medical device implanted, or instead throwing a hissy fit about getting the source code to something that's going in my body. I hope we can figure this shit out with tractors instead...
I've done contract work for a manufacturer of electronic control systems for excavation and mining equipment. They've aggressively implemented DRM in their new products to support renting time-limited and geofenced access to optional features. Their revenue models for the newest generation of equipment are based in large part on the recurring revenue stream enabled by DRM.
There was an article about these John Deere hacking farmers a year ago, and this is a follow-up. There was good discussion on HN back then: <a href="https://news.ycombinator.com/item?id=13925994" rel="nofollow">https://news.ycombinator.com/item?id=13925994</a>
A similar situation exists for consumer grade WiFi routers in the US. For about a year now, it's well-nigh impossible to flash routers with DD-WRT, OpenWRT, and friends due to the new FCC conditions manufacturers paid^H^H^H^H lobbied to get put in place.
This story comes up quite often. It seems an opportunity for someone to launch a farm equipment business that makes it's margin on the initial sale instead of the service.<p>Even if it's just refurbished pre-drm tractors.
This practice is pretty much rampant across all industries ranging from cellphones to luxury cars. One simple answer is big companies just want to extend their profits. Another reasons is they want their distributors or dealerships or middleman to thrive as well without which their business may get stagnant.
According to the video lawyers from Microsoft and Apple showed up at the legislature to voice their objections to the Right To Repair bill. Interesting that these 2 companies would be so anti-consumer.
What if there was a law that any device containing embedded software would have to either be (a) open source, with source code and docs freely available, or (b) closed source, with source code and docs in escrow in the event that the manufacturer ceases support, at which time the code and docs would immediately become open source?
A similar/related thread:<p><a href="https://news.ycombinator.com/item?id=14074894" rel="nofollow">https://news.ycombinator.com/item?id=14074894</a><p>Risking to cite myself:<p><a href="https://news.ycombinator.com/item?id=14077327" rel="nofollow">https://news.ycombinator.com/item?id=14077327</a>
This is only going to get worse. A company called Blue River Technologies, which hopes to automate weeding was acquired by John Deere(the company being discussed in the article). Their software is obviously more complex than simple firmware which can be 'hacked' by the average joe.<p>If this weeding systems is profitable and becomes popular, these farmers are screwed.<p>Here's[1] a nice longread on that company. It's a bit fluffy, but I recommend it.<p>[1]: <a href="https://www.bloomberg.com/news/features/2018-01-11/this-army-of-ai-robots-will-feed-the-world" rel="nofollow">https://www.bloomberg.com/news/features/2018-01-11/this-army...</a>
Is there any farm equipment (from China perhaps) that isn't DRMed? In addition to discussing the responsibilities of vendors, maybe we can also discuss the responsibility of customers to understand what they're buying.
I'm involved in the design of embedded systems for a relatively consumer market, and I've looked into making my company's designs more accessible to modification/software manipulation. There are a few (sometimes major) costs to allowing the modification of software that people tend to ignore in this discussion:<p>- Support: If you want to make your product more accessible to repair, you need to provide support for that. This costs developer time (making the code nice enough to be externally visible, maybe putting together an SDK, making sure any actual secret sauce or anti-counterfeiting systems are blocked off), customer support time (you WILL get calls when somebody buys a used system with modified firmware that doesn't work), and increases the hardware costs (want to provide a JTAG port? that's PCB space and BOM cost).<p>- Brand reflection: We've all seen how much of a ripple the wrong person having a bad experience with a product can have on the market. Say somebody buys a modified Initech Widget (tm) that has a bug or burns some other expensive equipment that it has to work with. That person complains on their friendly local social media network that Initech Widgets have a habit of (say) turning off furnaces in the middle of winter so the user's pipes freeze. Suddenly Initech is dealing with a media <i></i><i></i>storm because they allowed modification of their software, which brings us to...<p>- Liability. What happens if somebody modifies the software in my product and somebody dies, burns down their house, or (<i></i>* forbid) makes it possible to cause harmful interference and the FCC finds out? How do I prove to that user's (or the FCC's) lawyers that I shouldn't have to pay the damages? Let's assume that, as in the case of tractors or mobile baseband modems (which seem to get brought up a lot in this case) that software is a FUNDAMENTAL part of ensuring the safety/compliance of the unit.<p>Every time I've been through that calculus, the answer at the end has been, "I should do everything in my power to prevent the firmware of my devices from being modified".<p>I can understand and sympathize with the arguments in the other direction, and as a consumer I'm both qualified and interested in modifying the software on my widgets, but it would take a lot of change in the way our society works before most companies will put themselves at risk by supporting or even allowing it for their products.
A low tech alternative, depending on one's needs could be draft horses. My wife's family worked teams of belgians for about 80% of their 400-acre farm.<p><a href="https://www.motherearthnews.com/homesteading-and-livestock/farming-with-horses-zmaz87jazgoe" rel="nofollow">https://www.motherearthnews.com/homesteading-and-livestock/f...</a>