Sounds like had a QA issue maybe Scott ford www.identityforge.com from my IPAD
> On May 8, 2014, at 8:54 PM, zMan <[email protected]> wrote: > > Another anecdote: the vendor I worked for in 1988 bought a product line > from another vendor (who is gone, but was colloquially known as "gruel and > garbage"). It turned out that the binaries they were shipping and the > source code they sent us didn't match--not even close (major missing > function: one of the components wouldn't even come up once it was > reassembled!). One of our guys spent 18 months working to reconcile them; > at that point, we found another sucker^wcompany to unload the product on. > Never heard from it (or them) again. > > I don't think the vendor we bought it from did this on purpose: I think > either they'd lost the ability to build, or had done so many binary patches > without matching source patches that things had drifted. > > > On Thu, May 8, 2014 at 8:44 PM, Charles Mills <[email protected]> wrote: > >>> how does your scenario differ from hiring a new programmer and telling >> him >> he has to support an application that has been around for years >> >> Obviously we could invent hypothetical scenarios which were the same or >> different. I think it is at least plausible that in your scenario there >> would be some documentation and appropriate tools such as compilers, and >> perhaps in-house skills. ("Your" scenario application is written in COBOL >> and the shop has COBOL programmers; the escrowed application is written in >> FORTRAN and there are no FORTRAN skills in-house.) But Yes, best case, your >> scenario is similar to identical. But of course there is no preceding >> drawn-out court fight and hopefully no crisis (unlike "it blew up and we >> finally figured out the vendor is out of business"). >> >>> they were taken to court by a competitor, and the competitor won the case >> >> Interesting. The competitor must have been a licensee, with an escrow >> agreement, and the vendor must have breached the support agreement. Unusual >> to say the least. >> >>> bankruptcy is typically financially oriented. Contract language for >> "real" property ... >> >> Bankruptcy is bankruptcy. Software is intellectual property. Bankruptcy >> basically trumps contracts. If I were a creditor of a bankrupt software >> company I would be in court arguing that the source code should be sold to >> the highest bidder to help satisfy the software company's debts to me and >> others, not given away due to an executory agreement. What would the court >> say? We would be paying lawyers to find out, wouldn't we? (Meanwhile, the >> poor customer's critical processing is still waiting on a bug fix.) >> >> Escrow may work in certain circumstances. I think it is problematic to the >> point of having little benefit. Your mileage may vary. >> >> Charles >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of Mitch >> Sent: Thursday, May 08, 2014 5:12 PM >> To: [email protected] >> Subject: Re: Vendor Source Code >> >> Charles, >> >> My first question is this: how does your scenario differ from hiring a >> new >> programmer and telling him he has to support an application that has been >> around for years, but none of the previous developers or support staff are >> with the company any longer? However, your point about what happens if and >> when you do have to get access to the code from a no longer existent >> vendor. >> This is true, but also I would be surprised if any company would put >> something into a production environment without first testing it, whether >> it >> is if the vendor product "blows up" or something changes in the client's >> environment. >> >> I represented a vendor (who shall remain unnamed) and a situation happened >> where they had their product code in escrow, they were taken to court by a >> competitor, and the competitor won the case. The vendor then had to make >> their current version of their product available as per contract. A end >> user organization should ensure that any escrowed source is always the >> latest version as per contract stipulations. >> >> Lastly, bankruptcy is typically financially oriented. Contract language >> for >> "real" property is handled differently than financial obligations. Again, >> I, unfortunately, learned this first hand. BTW, IMHO, any vendor that is >> worth their salt will keep their various versions held in escrow up to >> date. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > > > > -- > zMan -- "I've got a mainframe and I'm not afraid to use it" > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
