Hacker News Reader

>But trust me on this,...

isn't a way to make a good argument.

From TFA "Only dealerships have the software to make those parts work, and it costs hundreds of dollars just to get a service call. Schwarting worries about being broken down in a field, waiting for a dealer to show up with a software key."

and from a comment above

"Plus, many of them don't get any update after the product launch. When you are in rush to plant or harvest you just can`t afford to wait for an authorized dealer. And if they fail, good luck trying to find a replacement that is not 100x overpriced because it has been discontinued one year after you bought it."

the problem seems to be that the process of updating software (a) takes too long (b) is too expensive (c) sofware is not updated once the tractor has been sold.

In an ideal world, where such a break down can be instantly fixed by JD for a reasonable fee, and JD actively updates the software on the equipment they sell till End of Life, this problem wouldn't exist.

Farmers don't care about open source etc. They just want to do their jobs. I'm astounded by the fact that JD takes no responsibility for updating software till end of life of the tractor.

This may be related to farmers not taking the tractors to repair shops.

The automotive component I worked on was firmware updated every time the customer took the car to a service for eg. to change oil, and an update was necessary.

The tools needed for this were pretty expensive though, and needed some expertise, as the process was somewhat complicated. I understand why this is not trusted to owners.

If the lack of updates inconveniences their customers and potentially causes loss of earnings, isn't the onus on JD to improve the update mechanism? Make it as simple as inserting a USB stick, and then ship out those sticks periodically? It doesn't have to be OTA or anything fancy.

> The tools needed for this were pretty expensive though, and needed some expertise, as the process was somewhat complicated.

There's a pretty good chance that was done intentionally.

Yes, but not in the sense you suggest. Ironically to save costs for the consumers, and improve reliability. Making the system suitable for safe updates without proper disconnecting and partial disassembly and tolerant to untrustad (also in electrical not only in software sense) peripherials would have added a lot to the piecewise cost. (think: more I/O protection electronics, more testing of upgradeability testing with untrusted tools with many failure modes, durable upgrade connectors fitting the size and other constraints).

Still no user could and should upgrade that software, as any complication or untrusted software would be a safety hazard, and lengthy official regulatory evaluation and approval process is needed needed for every new version. (think: Road Permission Level revalidation may be needed (overseen by authorities) to allow a firmware to take part in traffic)

The repair shops can save lots of cost compared to end users, as these tools are not cheap, but compatible with most manufacturers, so are needed anyway.

> The tools needed for this were pretty expensive though, and needed some expertise, as the process was somewhat complicated.

This is a problem.

I can guarantee you that all of these tractors will have the POSSIBILITY of over-the-air telemetry and software updates within a few years. The question still comes down to paying the support fees and getting the updates or modifications, but the physical act of "waiting for a tech" for software will be a non-issue very shortly, if not already.

Can someone speak definitively about updates from JD? It would really surprise me that JD "doesn't update" their software after the sale. It's probably covered by a service contract you need to keep paying for, but I strongly suspect that they update and patch software for many, many years after the product release.

Source: I work for a certain, huge diesel manufacturer, and am starting at a slide about telematics right this very moment.

> If a team of hundred of engineers struggle with their codebase internally, Joe Farmer isn't going to have a fucking clue how to repair their software correctly.

> But trust me on this, locking this down is a very good idea.

Joe Farmer may not know, but Joe farmer has "the internet", and ability to pay an independent software engineer. And people would absolutely find and fix bugs that john deer is missing.

Honestly, your argument sounds so ridiculous, it sounds like saying "it's to protect the children from terrorism."

What happens if this independent fix results in a death? Do you really think JD will escape liability?

This is not exactly uncertain ground. Car manufacturers don't have liability when their customers modify their cars. Whoever made my clothes dryer doesn't have liability for any unsafe condition I may or may not have created when I removed that stupid annoying buzzer.

Life is full of risks. This is, or may be, one of them. Allowing a handful of opaque corporations to monopolize the tools of food production and dictate their after-sale use is another risk.

Of course they will. If a hit man cuts your brake lines, Ford will not be liable.

I absolutely think JD would escape liability. Consider the more egregious cases of any number of high-profile companies who have had significant customer data breaches in recent memory. Regardless of how negligent they may have been (lets say they stored user passwords in plain text), have you ever heard of a company being held responsible for even the most egregious/reckless behavior?

Yes, for exactly the same reason that if I overclock my intel CPU then if it starts a fire intel won't be blamed because they expressly put that if I overclock or modify the CPU settings from the factory default they wont be liable into the terms of service and unlike many software SLAs it is accepted by courts around the world

Independent mechanics have been repairing machinery for as long as machinery has existed. This is not an exotic legal problem.

Also, if it's built on open source as he says, that likely means linux, and tons of code that John Deer is not reviewing, so... trust you that john deer needs to protect farmers from letting people fix the code THEY WROTE. lol.

So semi related, been in software for 20 years and contemplated getting a Motec w e-throttle for my (road legal) race car "no f-king way" is my thought process, I've got a race engine management system but no way I'm having anything other than a cable between me and the throttle body. I love software, I love engineering, I love what an e-throttle can do for traction control. But there will always be bugs with software ...I'd trust a road car with massive engineering teams, I struggle with the thought of a smaller team and how it could possibly go wrong. I personally get where he's coming from ... I can't imagine single engineers being able to test and have foresight on the umpteen permutations of "what-if"

I have worked in automotive and the testing of a software release took about 1 month for a ~150 member team. Yes, documentation because legal requirements was as much as 10% of the human labor, but the tests ran for a month in simulated environment.

This was not a particularly large software, about .5MLOC total with 3rd party RTOS as well (not in our test scope).

The tests did find unexpected bugs, as the dynamic behaviour of the system was much harder to reason about than about the single components, and sometimes pretty weird system effect kicked in.

I'd also not trust this to small teams, this is simply way more complicated than one presumes prior to experiencing it personally.

> I can't imagine single engineers being able to test and have foresight on the umpteen permutations of "what-if"

Maybe the answer to this is to have the software unit tests open source as well, and document the hardware integration tests (including spectacular failures) on Youtube.

Sorry, but you sound like someone who never worked with complex and safety critical software.

May I hope that this "independent software engineer" will also test everything after his changes?

I'm out here in the soybean/corn/dairy fields of Wisconsin. I'm not originally from here but i'll tell ya, some of these farmers are brilliant! These rednecks have their trucks and their tools and are frequently more ingenuitive and resourceful than anyone anywhere else in the world. Most of these folks would outfit their tractor with bucket seats, two cup holders, falcon wing car doors, and a keggerator if it didnt come standard.

If Joe Farmer doesnt know, he will figure it out.

If you could explain in reasonable detail a few common scenarios faced by the average farmer with an issue that would necessitate JD engineering expertise, I would very much appreciate it. Specifically, I'd be interested in hearing how the repair work orders that come in to JD engineering most frequently justify the claim that 'locking this down is a very good idea'.

Who, aside from the operator of the machine, is being put in such grave danger? Why am I, someone with no knowledge of combustion engines/cars in general, allowed to do my own work on the car that conceivably endangers thousands of fellow commuters each day, but a farmer driving a tractor (that lets say he's changed the engine timing on) in his own empty fields is somehow a great threat to society?

I would wager that Joe Farmer has a significantly stronger 'fucking clue' how to repair the issues they encounter with their tractors than Joe Developer at John Deere. Mostly because unless they're doing an aggressively poor job on the software (that you're convinced is too complicated for the unwashed masses to wrap their feeble minds around), the farmer shouldn't even need to be aware of its existence.

Additionally, I think you and I both know the vast majority of farmers adversely affected by these business practices are not dealing with 40 ton death machines, but rather the low-end John Deere products that do little more than an equivalent machine from 30 years ago could do. I'd also be interested to hear how ordinary farm machinery necessitates a codebase as complicated as you purport the JD software to be. The problems these machines have to deal with are not difficult, and were largely solved years ago. I can imagine there are some rather complicated hardware engineering efforts involved, but I'm skeptical that the software component would require anything beyond the skills of an enterprising group of skilled undergrads. I realize embedded dev work in safety critical applications is not so easy, but I nevertheless feel like you're dramatically overstating the complexity.

I'm sure the engineers on these projects are veritably concerned with the safety of their customers, and I don't mean to suggest otherwise. Just keep in mind the considerable imbalance of power between JD (and its engineers) and their farmer customers -- particularly in these types of debates.

edit: upon reading my submission, I came off as a bit of a jerk, and for that I apologize. In my defense, before getting into the software industry, I grew up working on a farm, and as a result am a bit reactionary in the face of any sort of "I'm a big bad developer, these guys are glorified lawn mowers who need to be protected from themselves." lines of reasoning.

At least some of these vehicles can be run without an operator in the cab, they use GPS and a set of waypoints to do their job independently.

edit: I have hopefully fixed all of the places where I incorrectly parsed "worked on software for" as indicating employment.

> They have a real potential to end peoples lives in the event of failure

I hope the lessons[1] learned from the Therac-25 are part of the design. Anything that dangerous needs to have defense in depth. If there are hardware limiters, interlocks, etc adding redundancy to the software check, the risk should be no worse than repairing any other dangerous machinery. Alternatively, if John Deere is relying on the software alone for safety checks - which requires that they (and the OEMs!) write bug-free software - then I don't want to be anywhere near the affected products.

> these tractors do (in testing) fail in spectacular ways.

So it's software only. I'm amazed at the hubris of thinking it's even possible can guarantee a software project large enough to requires a couple hundred engineers that maintain "the largest, most complex codebase [you] have ever interacted with". The very existence of tests failing in "spectacular ways" is evidence that bugs do exist in the software.

> These are not riding lawnmowers.

I'm not aware of anybody that suggested they were.

> They are 30-ton combines, and 20 ton tractors tilling fields

Yes, just like the older combines and tractors that didn't require complicated software.

> Joe Farmer isn't going to have a fucking clue how to repair their software correctly.

This, really, is the key point: the farmers in question *are not trying to repair the software. The only reason it is involved at all is because John Deere the company) chose to add the dependency.

[1] http://sunnyday.mit.edu/papers/therac.pdf

There is definitely defense in depth but, I never said the software was bug-free. :)

Also you're doing the unfortunate thing of associating me as part of John Deere. I'm not. I had a small hand is writing a small part of this software, a long long time ago. I don't give a shit if they sell tractors or not. I don't care if farmers modify the software or not. I don't really have a dog in this fight. I'm just a guy with an opinion who's seen how the sausage is made.

We know that you are just a guy with an opinion. But you could counter the arguments if you still hold the opinion, otherwise you could concede.

> these tractors do (in testing) fail in spectacular ways.

Aren't there any hardware failsafes to prevent the software from controlling the machinery in an unsafe manner?

Hey, I do high-assurance systems too. High-assurance security where input or environment might be malicious. Even in my constraints, the systems are designed so the parts can be replaced without magic software. The big complaint about JD seems to be them using software constructs to prevent fixing tractors or common extensions. The former should not be hard as JD just has to allow products with certain specs for what will work. The second might require a combination of that with a more manual, operating mode with some automation disabled. Less complexity than what JD is putting in there.

So, Im not buying it even if you worked on the team. They could design it for cheap fixes for parts easily. They could allow more extensions than they let on by turning off some automation. They are instead applying the well-tested concept of lockin both with software and their request to copyright office to make mods illegal. This is to increase profit of their near monopolistic dominance of a lot of the market (esp rural areas).

What, specifically, is a threat to kill people in the software? I'm sorry but that just reads like a John Deere shill here to defend the cause. We got by for literally two hundred years without magical software in tractors, and we were just fine.

What if we compare the number of people involved in producing the same amount of food two hundred years ago and today?

These things drive themselves. There are foragers that follow other equipment autonomously.

It's not obvious how an errant piece of large, heavy, machinery could kill someone?

There's a software bug in one of my tractors (not John Deere) where it won't always immediately disengage the clutch when put in gear (yes, even the transmission is fully computerized). One time during a long day in the field I accidentally left it in gear, not noticing because the tractor was at a full stop with no signs of moving. A few minutes after I got out of the cab it decided to kick in. Luckily it was in a low gear and I was able to safely get it stopped, but it's easy to see how that could have ended up tragic. While that one was ultimately my error, without that bug it wouldn't have been an issue in the first place.

I'm sure you can come up with arguments as to why that software shouldn't exist – although I have to say it's wonderful when it works – but it's easy to see why bugs can be dangerous.

It doesn't sound like the farmers are asking to rewrite or replace that software. It sounds like they are just asking to be able to make the same kind of repairs that their local dealer makes.

And what kind of repairs are that? As a software developer I don't understand what equipment is failure needs software change. Software don't wear and tear. Hardware does.

All software ships with bugs. Some of them cause real problems, and are patched in the next firmware rev. Farmers (rightfully) resent being held over a barrel in both time and money for fixes that should be part of already owning the machine. For example, if Ford discovers a flaw in their cars' ABS code that is recall-worthy, that's what happens, and Ford, not the customer, foots the bill.

From a different article on this subject [1]:

> "If a farmer bought the tractor, he should be able to do whatever he wants with it," Kevin Kenney, a farmer and right-to-repair advocate in Nebraska, told me. "You want to replace a transmission and you take it to an independent mechanic—he can put in the new transmission but the tractor can't drive out of the shop. Deere charges $230, plus $130 an hour for a technician to drive out and plug a connector into their USB port to authorize the part."

[1] https://motherboard.vice.com/en_us/article/why-american-farm...

Thanks. This was the kind of answer I feared

I don't know about tractors, but I do know some examples from cars that might be relevant.

The security system on some cars talks to keys electronically, and relies on a chain of trust between components. Kinda makes sense - you don't want a thief to be able to reach under the car, plug into a cable and issue the unlock doors command. The practical upshot of this is replacement doors won't unlock the central locking, unless you have them installed by the stealership. This happened to my father, when someone reversed into his car in a car park and dented his passenger side door.

The go-to example used by car manufacturers when they want to advocate for this lock-in is 'counterfeit' airbags. You can google and find reports of this sort of thing - authentic-looking airbags selling for $200 when the manufacturer charges $400. Some of them aren't as good as manufacturers' parts - and short of discharging the airbag, buyers have no way to check their quality.

The car manufacturers would then argue that unscrupulous second hand car salesmen might not tell you the car had a non-original airbag.

Looking to the future, in some articles about self-driving cars you'll hear that cars of the future will communicate with one another, allowing drafting between cars at highway speeds, and intersections without traffic lights [1]. If such a system comes to exist, I sure hope bad actors wouldn't be able to remotely crash my car - and I'm sure car manufacturers will use this as an excuse to lock out owner and third party repairs.

[1] https://youtu.be/4CZc3erc_l4?t=22s

The airbag example is an excellent analogy.

Replace a transmission. It's in tfa.

Let people run their own software. If they kill someone, hold them liable. If deaths become endemic, then consider locking them down.

As many comments on these stories demonstrate, farmers have as much valid reasons to have control over their equipment as John Deere has for preventing it.

Technology is always about trade-offs. It's just that John Deere took things too far.

> If deaths become endemic, then consider locking them down.

As much as I dislike John Deer's strategy, your statement is just stupid. Waiting for people do die before you regulate to make it safer doesn't work. Look at Ford who calculated that saving $x on a component was worth it if only y people die and their relatives sue.

That component you refer to was necessary for the safe usage of the vehicle. If it fails, bad things would happen (and they did).

Having control over your tractor does not necessarily kill people. Death is not inherently implied by farmers merely having access.

Apples and oranges. Equating the two is silly.

Most people won't be adding in gotos and if statements, they'll be replacing borken parts and getting their tractors working again.

Those few who actually do end up writing code for it, and those who opt to run it, will do so with the full knowledge that it'll be their asses on the line when something goes wrong.

Either way, my point was that people won't die from access unless they do something really stupid, and death due to stupidity is going to occur regardless of whether the tractor is locked down or not.

> Those few who actually do end up writing code for it, and those who opt to run it, will do so with the full knowledge that it'll be their asses on the line when something goes wrong.

In a world where extremely dangerous phone chargers are getting bought just because they are cheap, I cannot imagine that your views are correct. People are putting active fire hazards into their homes and other people are building them in full knowledge that the components used are inadequate.

Yes, people should be able to repair their machines and change single components but it should be guaranteed that basic safety functionality is working. I'm not talking about something where a farmer personally modifies their own machine. I'm talking about manufacturers that build cheap replacement parts.

It does and can work.

Source: The aerospace industry

Think about what you just said for a second. "endemic" deaths of innocent people are the litmus test for whether software should be locked down? How is that in any way acceptable?

My bet is that the few deaths that will initially occur, will be due to stupidity, rather than the ability to fix your property.

If people thought like you did, we wouldn't have kitchen knifes.

Traffic accidents happen. According to your reasoning, we should forbid people from owning and driving a car.

No, that is not my reasoning. I'm not talking at all about people operating or using devices that carry inherent danger to themselves or others. I'm specifically responding to the parent's argument about what counts as an acceptable threshold at which it becomes okay to compromise an owner's ability to modify these machines. The parent said that its only acceptable AFTER some nontrivial number of deaths, presumably of people in addition to the owner of the machine.

A related question I want to ask is: what is inherent about software that makes it not okay to have restrictions on modifications where lives other than the owner's may be at stake? I see other comments here that say things like "oh these machines should have mechanical limiters etc. that prevent them from being dangerous." But isn't that essentially the same thing, just implemented in hardware and not software?

I'd like to note that I'm not saying that John Deere is in the right here. I just feel that the argument in the parent comment is, for lack of a better word, inhumane.

> John Deere tractors run on open source software

Out of curiosity, what range of open source licenses appear in the code base? Do they use any software whose license requires source distribution? If so, are you aware of a "source code" page buried in John Deere's website, or some other mechanism by which they satisfy any distribution clauses?

I couldn't possibly comment. This would be close to me breaking NDA ground here, so sorry about that. I know that the legal department took software licensing very seriously and we had a narrow range of licenses we could use.

NDA on open source libraries? Don't those licenses usually require attribution at the very least? Where can we find the license file? Surely JD is complying with license requirements, which would require disclosing the libs used...

I don't think it's fair to assume an ex-employee knows the details of the software licenses or where to find them. If he knows more concrete details (like a link to the license file) I imagine he would share, but otherwise invoking NDA is a safety measure to avoid sharing potentially incorrect/outdated info.

Instead of now even hiding behind some lame excuses like NDAs, how about answering the most asked question:

How does replacing hardware parts does risk lives? Why is the situation different for JD than for eg. car manufacturers?

https://github.com/JohnDeere

Sounds like you're talking about the code that handles safety features.

What does that have to do with the code specifically written to force farmers to pay John Deer for maintenance and repairs? The stuff they could normally do themselves?

There is an obvious trend to make simple things complicated. Like how you have to remove the whole front end of a car to change a headlight. This sounds exactly like that.

Actually, that latter is a trend to make things more compact. The engine compartment of my current car, which has the very requirement that you mention, has nowhere near the amount of extra unused volume as the engine compartment of the car that I was driving a couple of decades ago had, permitting access to many components without other components being in the way. The engine compartment is also, itself, smaller overall.

Don't try to bullshit us.

Your code is deliberately user-hostile. Farmers aren't trying to hack their tractors for the sake of it; they need to hack the parts of your code that prevent them from performing routine maintenance. Replacing a fuel pump is not going to turn a tractor into a rampaging death machine.

You are using spurious safety arguments to justify profiteering. Software lock-outs are being used to prop up a business model, just like the chips in printer ink cartridges.

>Don't try to bullshit us.

Us? Who is "us"? Why are you trying to shout down an opposing view? You want prefer the echo chamber?

>Replacing a fuel pump is not going to turn a tractor into a rampaging death machine.

Am I going to be able to replace whatever parts I want on my Model 3? Because "we" certainly love that company here!

Your comparison to Tesla doesn't get better just by repeating it a few times. If your Tesla breaks down you wont have any problem to get a comparable replacement car. Much luck to get a replacement for your tractor during harvest season.

>Your comparison to Tesla doesn't get better just by repeating it a few times

Your hand-waving also does precisely zero.

>If your Tesla breaks down you wont have any problem to get a comparable replacement car

What does this have to do with anything? I want to work on something I bought; isn't that what we're arguing about? The availability of a replacement is a straw man. Why are you apologizing for other companies that do precisely what is being described in the article?

While I think you have a valid point about Tesla's availability, this is a "Tu Coque". I mean, regardless if Tesla does/does not do it, this is considered bad and bringing Tesla in the discussion does not change nor challenge the validity of this view, only, maybe, reveal a little hypocrisy or favoritism in the audience.

>While I think you have a valid point about Tesla's availability, this is a "Tu Coque". I mean, regardless if Tesla does/does not do it, this is considered bad

aka https://en.wikipedia.org/wiki/Whataboutism

>reveal a little hypocrisy or favoritism in the audience.

Precisely my point in bringing it up. Someone, who apparently worked at John Deere, offers an opposing view and some clown shouts him down like a bully. Why should anyone listen to the arguments of hypocrites?

If you're against this sort of thing, you're against it.

> Why should anyone listen to the arguments of hypocrites?

Because even though they might be hypocrites the may offer good arguments. And while I understand the point of the JD employee myself (I also work writing software for vehicles) and I think he speaks honestly, I think that goods should be easy to fix and all the means fo this should be at the disposal of whoever needs it. Reconciling safety and the need for open software (because this is what is basically boils down to), right to repair and right to modify is a real issue. One that should not be invalidated necessarily by personal traits of a subset of supporters of either side.

> I want to work on something I bought; isn't that what we're arguing about?

This might be what you are arguing about, but then you are in the wrong discussion. Farmers complain that they have to wait for an authorized JD mechanic to fix even the most simple stuff. And during harvest time they just can't wait.

>but then you are in the wrong discussion

Maybe you are.

>Farmers complain that they have to wait for an authorized JD mechanic to fix even the most simple stuff

Actually, it says in the article that they can fix simple things.

Yes - you can change the windshield wipers, replace the fluid, change the tires. You may not be able to replace the battery or any of the high voltage electrical system yet. Although if you are experienced in high-voltage maintenance, you may be able too. See this[1] description of one fix that your "software" would prevent.

[1] http://imgur.com/gallery/j8Bcp

>Yes - you can change the windshield wipers, replace the fluid, change the tires.

Are you unable to change these components on your John Deere vehicle?

FTA:

""Maybe a gasket or something you can fix, but everything else is computer controlled and so if it breaks down I'm really in a bad spot,"

If product owners are given the ability, they will gladly retune the engine software to output more power, and defeat aftertreatment systems, both to the breaking of emissions laws, and the detriment to the environment. It's a tricky business trying to lock down only parts of the software. Once the cat is out of the bag, all bets are off, to mix my metaphors, so manufacturers err on the side of caution. It's not PURELY to screw the customer. ;-)

What does any of this have to do with repairing a transmission? You're moving the goal post.

Your post smacks of "PR". The majority of people that I've talked to regarding their tractors have the issue of needing a replacement part and requiring the JD tech to come out and authorize its replacement or fixing every single time. This is just crazy expensive and time consuming.

If you want people to not modify your hardware or software then you make it so easy that the alternative doesn't look good.

How many lines of code does it take to register as the largest you've dealt with? The largest I dealt with took 45 minutes to grab the repo. I don't state that as a point of honor, more like a point in needless over-effort.

I would say the JD's tractor software (if taken in it's entirety) is on par with the modern Linux kernel in size, if not larger. Worse yet, the codebase is spread along many different repositories, teams, and build systems.

I've seen integration builds take days to finish (not including running of unit tests).

Look I get it, John Deere is evil. But this codebase is beyond any one person or team's comprehension. It's very massive, and it's very complicated.

All the more reason not to trust it.

Did you see this comment?

https://news.ycombinator.com/item?id=14076318

I don't think the customers need or want to modify the software. Just open it up for hardware replacements

You said there were 150-300 engineers working on this code. That is at least an order of magnitude less than the number of people developing Linux.

Yes, but they're getting paid, which is going to easily make up for the larger number of individuals developing Linux. Not to mention that 10x the devs does not come close to 10x the productivity.

For next time: if you don't know how something works (in this case, how linux is developed and by whom), ask! It's better than assuming and jumping to conclusions.

Most linux developers are paid to develop linux. Based on Jonatan Corbets stats less than 15% of the changes could possibly be from volunteers. More than 1200 developers affiliated with ~200 companies contributed to the last release alone. There are nuances here (some developers might not be full time _kernel_ developers) but the argument that linux development isn't professional and mostly paid work has been invalid for years.

How is possible that a software developed for a very specific purpose is comparable in size to a general purpose OS? I see this as an indication of a bad developed/vastly overcomplicated software. Correct me if you think otherwise.

I've worked at Deere as a contractor. Not on the tractor software as I didn't have access, but I would put most of what I saw as towing the line of over engineered.

There were certainly parts that were exceptionally easy to work with. Many, many, many repos all over the place doing various different things and inside of some of those you would find some very cleanly written code with excellent tests, examples, and documentation. The problem was once those nice little libraries, tools, etc got brought together it became a mess.

Regardless of all the negative feedback this comment has received, this is one of the reasons I find Hacker News to be totally cool.

Where else do you get an engineer who wrote the code commenting on the article in question?

> This software is by FAR the largest, most complex codebase I have ever interacted with.

This is a problem.

Edit: I want to add something.

Serious 3rd party serious mechanical shops have had the ability to intervene on this kind of equipment - I suppose. The same way that independent serious and competent car repair shops exists.

One problem we are about to all observe, and which actually has already began, is not typically that owners would like to rewrite the software and run their car/tractor/whatever with the modified/rewritten version.

The problem is that vendors are taking the dangerousness argument and (mis)using it as an economic weapon in the same time to gain anticompetitive in the maintenance market -- like the comment to which I'm replying to does, in effect (concentrating on the risks of unrelated open changes, instead of discussing the initial problem! )

And moreover in the same time, car vendors, for example, have proven several time we can not trust them with critical software.

Thank you. I work in Ag and it seems crazy that someone should be able to buy a machine like those Deere sells and be able to modify the controls SW. Can United Airlines update the controls SW on Boeing 747? I'm not sure how tractors are any different.

I also work in ag, and own John Deere equipment. Is anyone truly asking for source code? I've read that narrative here and there, but it seems what is really being sought after is access to the tools and manuals that the authorized dealers have access to. The service techs repairing these machines aren't going to be modifying the code either, and they don't need to.

As an aside, I remember the last time I had a John Deere tech out. Even for him to access the service manual (to fix a mechanical part), which was fundamentally not much more than a simple search tool that displays PDFs, required a surprising level of authorization to access each document, with everything encrypted. It seemed a little extreme just to get a simple diagram. I can sort of see why some worry about where the company is headed.

I think documentation is the right way to handle this. Require enough documentation that 3rd party repair shops can fix the machines. Even if they can't do much with the embedded controllers, at least document the sensors and the wiring. Otherwise, these machines are completely useless without the manufacturer and their dealers.

United Airlines is not really farmer Joe and something tells me that even United Airlines doesn't send its 747 to Boeing for all the maintenance work...

Can confirm that United Airlines directly employs aircraft mechanics who are free to service as they see fit, and they use hardware that is not DRM'd to the plane.

Can also confirm that aircrafts can do more damage than tractors if things go wrong.

Like the JDs in the article that are so complex that they can steer themselves, aircrafts also do this!

I don't see how tractors are any different either. So JD should cut out this rent-seeking bullshit and stop pretending it's in the best interest of anybody other than their shareholders.

From all the articles that I have read, the repairs of the United Airlines planes are heavily regulated. The mechanics can't replace a part with another unless the new part is certified, and certification is very expensive. The mechanics also have to be certified and fill a lot of paperwork.

The changes checks are not enforced by software, but by strict FAA rules.

Wow the public relations sock-puppetry on HN is getting very clever and sophisticated. I really love the green account - nice touch. It really helps your authenticity to pretend like you are afraid of retribution from John Deere when you are totally kissing their asses.

Let me ask you this -- why in the world do the lines of software you write prevent a qualified mechanic from changing a transmission? You know people used to do that all the time when tractors had zero lines of software in them.

After all you are trying to very cleverly change the subject here. You are doing it very deftly, as you should, because you are not a software developer, you are a PR drone and it is your job to deftly change the subject.

The question here is not about the quality of the John Deere software, so it does not really matter how many engineers worked on it or how hard they worked on it. The problem is that the John Deere software takes away an essential right of property ownership that people take for granted.

No one is accusing the JD software of being faulty, i.e., incapable of serving it's intended purpose. People are accusing the software of having nefarious purposes and serving them all too well.

Not on either side here, but I feel like you're missing the point there. Let's say someone does modify the code, then the machine messes up and ends up killing someone. Who would be the culprit there? I guess they could have something that detects when the software is modified, but even if they did, I bet it would still be poor publicity for them (similar to when people misuse Tesla's assist and getting in accidents).

Also, honest question here about changing transmission. You make it sound as if it's completely unrelated with the code, but is it? The code may very well be tuned for the hardware as it is, and changing any of it could also lead to unexpected results.

Of course there's much better ways of going about it, but from a lawsuit protection perspective, I think you're simplifying an issue which is much more complex than it may seem at the surface.

No.

JD is a knife manufacturer who puts countermeasures to prohibit knives owners from sharpening second side of the blade (among others things). Because it can be dangerous.

It sounds like you can't sharpen the first side either. Or more aptly, replace the handle of the knife when it gets worn.

>Let's say someone does modify the code.

Let's not. These farmers don't want to change the software. They only want to fix their hardware.

And because of the close tightness with the software, they can't.

Do you think I can pull the electric motor from my Model S to replace it?

When John Deere does this, HN is up in arms. When Tesla does it, it's part of an "innovative business model".

I think if you had the part and replaced it, your car would turn on without a Tesla engineer recertifying it.

>your car would turn on without a Tesla engineer recertifying it

I think you're going to be disappointed.

As someone in the car repair industry I can assure you that Teslas hostility regarding non-authorised-repair is a big issue and will only blow up when Teslas become more common. At least here in Europe, this won't fly.

Both the OP and the reply seem a bit over-the-top, but it's a fair call to say that the goal was changing the subject from "who owns the tractor" to "think of the children!"

People repair stuff they own all the time, and if they do a bad job of it, they are liable for any damages caused. All that's really needed here is some clear way to indicate that this factory-issued X has been modified by the owner to be an X1 model. End of story.

We can't continue down this path of people developing software and somehow in the process picking up vast quantities of physical goods that buyers think they actually own. Not only is it evil, it's nonsensical from the viewpoint of the average informed person. The only reason it's worked as long as it has is that most people aren't informed enough about it. Tractors might be the straw that breaks the camel's back on this issue. People don't think much about the inner workings of their phones, but Joe Farmer fixing his tractor is a concept most folks don't have difficulty getting their head around.

> Let's say someone does modify the code, then the machine messes up and ends up killing someone. Who would be the culprit there?

People repair and modify their cars every day - and these are driven on public roads among other drivers and pedestrians. Farm equipment is operated on private property and among workers who are mostly aware of the risks. In the end, if the vehicle is unsafe, the driver is responsible.

Most of the folks on HN haven't worked on anything more complicated than a web app.

Although that comment is unconstructive and probably wrong, I'll just point out that pretty much all of Google is a "web app".

While I agree it seems the above comment was intended as a swing at HN which is not constructive or useful debate, I would suggest that as per the stack overflow developer survey web programmer was the most common job title by a very large margin (72.6%, with next closest being Desktop applications developer at 28.9%)

While I would suggest that this forum demographic likely differs somewhat from stack overflow as a whole, its certainly an interesting question.

Also as an anecdote, web technologies stories seem to appear disproportionately often on the front page. This would suggest at least some interest by the majority of HN

I'm pretty sure prior versions had no software. Adding software without showing exactly what that software does seems more dangerous than trying to handle everything without explaining how it is handled.

I mean, it used to work like X. Now it works like Y. Which you could inspect via the code. The reality is it works like ?. Because only god and the parent throwaway know.