TERRY@SPCVXA.BITNET (Terry Kennedy, Operations Mgr) (02/04/90)
Leonard D Woren <LDW@USCMVSA.BITNET> writes: | On Tue, 30 Jan 90 13:55:24 EST, | Michael Johnson <michael@MAINE.MAINE.EDU> said: |> I would like to see the BITNIC charged with developing, or contracting to |> develop, software to implement BITNET RFC standards and with making that |> software available to all the member institutions (VMS, Unix and VM). If this > Why does everyone on Bitnet (except RAF) seem to forget that there are > 169 MVS systems on the NJE network? And those 169 systems probably > have as many users as 3 times that many VM or 20 times that many VMS > systems. I am aware that there are a wide variety of machine types on the net. As I read Michael Johnson's note, he is also (having said "all the member insti- tutions"). It just looks like his itemized list is a little short. He's omit- ted MVS (which seems to upset you) as well as CDC, etc. systems. I think the point he was making was that standardized tools should be available to all members, a point I agree with. Whether a site chooses to run one of these or a local tool, as long as the local tool conforms to any relevant BITNET stan- dards, is up to the local site. I certainly wouldn't want to see a dictate saying "you must run X", but I don't think that's going to happen. As far as the statement about numbers of user accounts goes, I have 5129 (I just checked) on our VAX. I'll concede you probably have more, but I think it unfair to classify the "desirability" of implementing tools based on raw user counts. In the cases I've observed (both at my site and several other BITNET sites) the number of users who actually use the BITNET connectivity is a small subset of the total user base. The decision to implement a standardized tools for a particular machine type should be driven (in no particular order) by a) The presence or lack of sim- ilar, compatible tools from both public-domain and commercial sources, b) A request from users of that machine type that such a tool be made available, and c) whether the number of BITNET users (_not_ systems) makes the creation of such a tool worthwhile. Lest I be accused of disenfranchising the "little guy" with an oddball sys- tem, let me state that I run directly-connected RSTS/E (DEC PDP-11) machines on the net, and to the best of my knowledge I have the only such systems on the net. I know what it's like to create these tools... |> means slightly increased dues for all member institutions, so be it. It is |> certainly more fair than having a few places carry the bulk of the financial |> load that comes from product development time. > I disagree with basically everything quoted above. First of all, > software developed by end users typically does what they want. > Software developed by vendors (and in the above scenario, Bitnic would > be a vendor) typically does not do what you want, the way you want it > done, and it takes just short of forever to get the vendor to change > it. [text deleted] There are a few problems here. As you point out, users who are happy with the tools they now have probably don't want to help foot the bill for one they'll never use. Next, BITNET is perceived as the "low-cost" way to get into dedicated net- working (at least, that's why we joined). Since that time, the cost of a direct Internet connection has dropped due to new hardware, lower phone costs, and things like SLIP. If we raise costs, we may face a serious drop in new member applications. However, in my opinion, the _most_ _serious_ problem is that BITNET does not have a standards mechanism in place which is actively generating official stan- dards. True, we have the technical committee - but from what I've read it seems to provide documents that read "it would be nice if". We also have the informal BITNET standards list, which unfortunately does not seem to have Board support. If we had such standards the NIC could approach various vendors who were per- ceived as having potentially useful products and ask for any changes deemed necessary for BITNET use, and also negotiate a better purchase price, since the NIC would have already surveyed the potential market for the product. It's a lot easier to get a discount when you say "I have 25 sites who want your pack- age if..." The down side to standards is that some sites may not be able to pay for a commercial product, and a public domain one may not be available. It seems that these would be the smaller, less well-connected sites (since any site also on the Internet should be capable of generating RFC822, as an example). We don't want to disenfranchise small sites. However, if we can get a feel from the survey step of how many sites and machine types we're talking about, the NIC could then approach a vendor and attempt to convince them of the mar- ket and work with them to determine a price at which the product would sell. Lest you think I'm in the clouds here, I'll give an example. PMDF (a RFC822 package for VAX/VMS systems) is under $1000 for the worst-case price (biggest CPU, commercial customer). For educational sites, it's something like $150. It also comes with full source, and vendor support is excellent. Maybe it's an exception - but it works... Terry Kennedy Operations Manager, Academic Computing St. Peter's College terry@spcvxa.bitnet