Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!elroy!cit-vax!ucla-cs!zen!ucbvax!AI.AI.MIT.EDU!JBVB
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Networks & vendor upgrades/fixes
Message-ID: <290522.871124.JBVB@AI.AI.MIT.EDU>
Date: Tue, 24-Nov-87 01:07:13 EST
Article-I.D.: AI.290522.871124.JBVB
Posted: Tue Nov 24 01:07:13 1987
Date-Received: Sat, 28-Nov-87 00:24:25 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26

In my own judgement, a vendor might be justified in restricting distribution
of the source code for "version control" only under the following
circumstances:

1. Vendor support personnel have access to source code themselves, and the
skills and tools to use it.  These people don't have to answer the phone,
but you need to be able to get a call back in a day or two, at most.

2. These vendor support personnel work in an environment in which most
or all customer problems can be conveniently duplicated.

The 2nd condition rules out restrictions on most network source code, since
not even IBM can maintain a current copy of *every* vendor's TCP/IP hardware
and software, and thus there are many problems that can't be duplicated at
the vendor's site.  Maybe TCP/IP sites are exceptional, but the large TCP
users we've sold source to have been quite well equipped with competent
personnel, and I've found working with them to be quite productive.  We
have had to teach some of our OEMs quite a bit, but they weren't users when
they started out.

James B. VanBokkelen
FTP Software Inc.

PS: I've realized that I'm talking from sort of a vendor/management
perspective.  If this bothers a mostly (?) engineering list, tell me
and I'll shut up except for technical issues.