← Back to context

Comment by mindslight

17 hours ago

> at what size or capacity should you be required to document and publish these things?

The reason there is an opaque number in that open source utility is precisely because of a lack of open documentation for that register definition. Independent black box analysis of the messages only got as far as "write this value to do effect X". Whomever developed that utility would have loved to spell that bitfield out, but not at the cost of more days reverse engineering.

But manufacturers aren't reverse engineering register definitions, they're working off of vendor datasheets or protocol definitions they themselves created. All of this documentation has already been produced, as it was used to develop the tractor from its various subsystems. It just needs to be published!

I’ve worked on enough internal and third-party SOA to know that documentation could be in an email, a slack chat, or a hallway conversation. The public docs go through writers and reviews. How many software teams could make their service or library docs public based only on internal documentation and produce anything useful?

  • Documentation for hardware subassemblies produced by different manufacturers isn't getting conveyed through hallway conversations. Pure software can indeed be quite sloppy, but for vehicles we're talking about large scale cross-stakeholder projects where these things do get formally documented.

    At any rate, for things a manufacturer doesn't consider important enough to document themselves then there can be a clear alternative requirement - release whatever upstream documentation they did use to create it, plus the software source code they developed on top of it. If it's not important enough to have been documented as its own product, then it also isn't a significant part of the value they're actually selling, right?