If multiple proprietary software packages are talking to each other at all, there must be either an implicit or explicit specification they're talking over. And if that interaction is broken, that implies that either (1) the spec is ambiguous/wrong or (2) one or both parties are implementing the spec wrongly.
It seems to me that engineers from the relevant companies ought to be able to get together, talk over the problem and figure out which of those is the case, even if they're not looking at the same source code.
In any case, a well-defined spec/API is critical to effective integrations between pieces of software maintained by different teams, even if both components are open source.
If multiple proprietary software packages are talking to each other at all, there must be either an implicit or explicit specification they're talking over. And if that interaction is broken, that implies that either (1) the spec is ambiguous/wrong or (2) one or both parties are implementing the spec wrongly.
Yes. Aerospace takes that seriously. So does the military. That's why Rolls-Royce engines can be taken off a B-787 and replaced with GE engines. The software industry rarely takes interoperability seriously enough to make such things work.
Many years ago, at the dawn of the TCP/IP era, I worked for a large aerospace company. We had a pre-Berkeley TCP/IP implementation from 3COM, originally intended only to talk to itself over Ethernet I brought it up to compatibility with the spec, and added a logging mechanism which logged every packet which was either wrong or which did not advance the connection.
Every day, I read through this bit bucket, and wrote emails along the lines of "Your TCP implementation is not compliant with para. xxx subparagraph yyy of the standard. See this dump of packet zzz where value aaa is incorrect due to bbb." After a while, interoperability improved.
We could do this was because, as a large aerospace company, we were bigger than the networking companies we bought from. So we could pound them into complying with the published spec. We also had backing from DoD in this; they wanted interoperability. Back then, many vendors didn't; they wanted their own dialect of networking. This was the era of SNA (IBM), DECnet (DEC), ARCnet (Wang),
and a whole bunch of incompatible PC-oriented LAN systems. Mixed-vendor shops were unpopular with the old-line computer makers. The idea of everything talking to everything else, and it all just working, was new then. It took a lot of effort on the buyer side to make that happen.
In the field I'm in, companies that are effectively running a lot of infrastructure are comically bad at providing developer support. Like, they actively go out of their way to avoid providing documentation (that they themselves certainly have).
The reason? They do big enterprise installs and it is probably safer just to treat all their gear as black-boxes than to allow any other companies to potentially botch site integrations.
Then again, everyone else ends up just packet sniffing production networks anyways, and that's a lot safer, right?
"...you have teams as well as individual employees in companies able to manage the technology, but these tech-savvy people are never high enough in the company's hierarchy. What happens time and again is that those who have the expertise get overruled by those who don't."
Remember that that's been written by someone who never worked at that kind of job, and then Stallman, who is even further far removed from that environment, making a generalized statement that he wants to apply to all companies and employees.
Even when tech-savvy people is high enough in the company's hierarchy, the business culture usually is to avoid fixing a bug until the bug costs more money than its fix.
In my honest opinion this sucks, but oh god, most companies live with a "only money matters" mindset...
> Even when tech-savvy people is high enough in the company's hierarchy, the business culture usually is to avoid fixing a bug until the bug costs more money than its fix.
That's not quite 100% correct.
> In my honest opinion this sucks, but oh god, most companies live with a "only money matters" mindset...
That's quite 100% incorrect.
Good businesses will do risk assessment. If the risks are communicated correctly, the choice of mitigating them for a few man-hours is obvious.
There's bad businesses, but I don't think that's most businesses.
But in my experience, companies tend to look down at issues which affects customers, but don't affect the company directly, the risks are understood perfectly, but the choice almost always is "we will be as negligent with our customers as we can be, no matter if our customers die".
An old example which features "no matter if our customers die" is the Ford Pinto[1].
Fortunately, there is not a current example as fatal as the Ford Pinto, but the practice to overlook what affects customers remains in effect. At the end of the day, Risk Assessment is just a way to say "what matters to partners and investors", which is was what I tried to summarize with my previous point of "only <s>money</s> profits matters".
The Takata airbag and GM ignition switch issues are comparable, IMO.
"If the air bag housing ruptures in a crash, metal shards from the air bag can be sprayed throughout the passenger cabin—a potentially disastrous outcome from a supposedly life-saving device."
We had Windows XP Systems that had explorer.exe crashing randomly when specific Users ran Outlook 2003, the release of SAP GUI we used and the release of SnagIt we had licensed at the same time. These crashes only occured when the users had all 3 programs running at the same time. The programs did not talk to each other in the sense you think of.
It did not depend on the hardware installed, so we suspect it was something in the roaming profile of the specific user, but we never figured out what it was. Perhaps a registry key related to some shell extensions? In the end we cycled those people through various PCs, deleted the temporary and configuration files several times till they could work again.
Today, with "agile" being popular, that specification almost certainly is implicit, and it _was_ in the heads of both parties when they were writing the systems (but probably not completely; if both parties fully understood the protocol, chances are there would be little reason to look into it).
Also, the heads the specification _was_ in may have left the company.
But I agree that "closed source" most of the time is only a small part of the problem. Having the source of your shell script that talks to my perl script helps, but only a bit.
As someone who has worked in various agile ways, I can assure you that agile certainly does not mean "do not provide your users with explicit specification of a public api".
In the Agile manifesto (1), the phrase "we value ... Working software over comprehensive documentation" refers to the big upfront waterfall design and architecture documents that precede implementation and are usually obsolete before the software is working.
If you are working in an agile way and you find that your system's behaviour is under-specified to people trying to use it, then you have a problem, and agile methods encourage you to change your ways of working to fix the problem. For instance, by providing sufficient specification with each piece of working software. See: Definition of Done (2)
You could however just be using "agile" to mean something else such as "lazy", "sloppy", "hasty" or "inexperienced".
Such a "spec" would not be able to describe how systems interact: protocols, failure modes, SLAs, etc. In other words, the kinds of things you want specified when engineering a system. These are also specs
It seems to me that engineers from the relevant companies ought to be able to get together, talk over the problem and figure out which of those is the case, even if they're not looking at the same source code.
In any case, a well-defined spec/API is critical to effective integrations between pieces of software maintained by different teams, even if both components are open source.