From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bbn!rochester!PT.CS.CMU.EDU!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.lang.ada Subject: Commercialization - Part 2 Message-ID: <327@ajpo.sei.cmu.edu> Date: 2 Mar 88 14:13:32 GMT Organization: Ada Joint Program Office Keywords: Commercialization, Ada List-Id: In the very early 1980s, the U.S. Department of Defense (DoD) let it be known that they were very serious about Ada technology. They justified the switch to the new technology in a number of ways -- one of which was the (somewhat long term) promised financial benefits to the U.S. taxpayer. Quite a number of large DoD contractors followed the Ada effort back then for business reasons (e.g., an Ada capability would mean a greater potential for winning contracts). However, without the efforts of the vendors of Ada-related products and services, the the introduction of Ada technology would have been very slow and painful indeed. The Ada Joint Program Office (AJPO) encouraged these vendors. They knew of, and appreciated the efforts of, organizations such as TeleSoft, DEC, New York University, Verdix, and others. In fact the DoD was delighted when the activities of the Ada vendors "took on a life of their own." Today, the AJPO can point to a list of well over 100 approved Ada compilers, a thick Catalog of Resources for Education in Ada and Software Engineering (CREASE), a growing number of Ada-related organizations and meetings, and a significant increase in Ada courses at colleges and universities. This is made all the better by the fact that the government has not had to fund these efforts -- it had only to encourage them. In my last message, I said that it was time for the Ada community as a whole to begin thinking seriously about the use of Ada technology for non-weapons systems. This, I feel strongly, will benefit all involved. I will not attempt to enumerate the reasons for my thinking again, but will instead make some observations and recommendations. At present, the Ada community in the U.S. justifiably places most of its emphasis on DoD-related matters. While there has been a growing use of Ada technology in the commercial sector, there is not, as yet, been any indication that there should be a significant investment of resources for Ada technology in the commercial sector. The mindset of many Ada vendors is largely focused on the DoD. I can't blame them for this. What I am saying is that we need to begin seriously directing our efforts to the commercial sector. Karl Nyberg gently chided me about my original message. He correctly brought up the work that he has done on run-time license fees, and indicated that many, if not all, of the vendors he contacted had "third party programs." I have read his report, and while I am impressed with his efforts, I am not impressed by the "third party programs" offered by many Ada vendors. A program which requires third party vendors to pay a royalty of say fifty dollars per copy of product sold leaves a little to be desired. For example, consider the low-end third party vendors who want to create binary versions of software products to sell for one hundred dollars or less. A run-time license fee of fifty dollars has a large negative impact on such a market. Imagine the shock of the traditional software product vendors who have been using Turbo Pascal or Lightspeed C, who having expressed an interest in using Ada, are informed that there is an additional fee (and its accompanying paperwork) for using a PC-based Ada compiler. I would not make such a big deal of this issue, if there was some added benefit. I think Ada compiler vendors should be rewarded for their efforts, but the size of this reward should be balanced against the perceived value of their product and their product support. I have found that the current state of Ada technology also presents additional difficulties to third party vendors. If one attempts to create binary versions of Ada program units which are intended to be used by Ada software engineers, one must go beyond simple hardware and operating system considerations. A separate binary library must be created for each different Ada compiler. I recently found that even if the developer attempted to do this, there were difficulties in integrating these libraries into a user's system. Karl also correctly observed that "It helps ... if the commercial products that are being developed, and the support that is requested from the Ada compiler vendors is geared towards the furtherance of their products as well." I definitely agree. In other third party programs with which I am familiar, potential third party vendors must formally apply for admission to the program. The potential vendor must demonstrate to the primary vendor just how the product will be of benefit to both parties. The questions for the potential vendor go beyond a simple description of the proposed product, they include questions on compatibility with other products, marketing capabilities and strategies, and the financial health of the potential vendor. I would not think that these questions would be out of line for Ada compiler vendors to ask prospective third party vendors. Specifically, the burden should be placed on the potential vendor to justify why they should be included in any third party program. Again, based on my experiences with other third party programs, once accepted into the third party program, the developer is given active support. This support can include such things as pre-releases of relevant software, active technical support (by phone and/or electronic mail), discounts on additional purchases (any discounts must be justified based on the fact that the products purchased will be used to help develop the product), regular newsletters and bulletins, product-related classes and seminars (often paid for by the third party developer), and assistance and advice in marketing the product. Companies such as Apple even go so far as to provide booth space for some of their third party vendors at trade shows. Finally, there are even organizations which will actively sell and market the products of their third party vendors. Because of the relative immaturity of the commercial Ada marketplace, only a few Ada vendors have active, well-thought-out, third party vendor programs. I hope that this will change in the near future. Karl is again correct in strongly suggesting that if the Ada community wants a more open newsgroup or mailing list, that someone must sponsor it. I marvel at how such blatantly commercial organizations such as Apple, IBM, and AT&T end up with many mailing lists and newsgroups for their products. Further, much of the traffic on these electronic conduits would never make it on the current comp.lang.ada/info-ada mailing list. The organizations I mentioned (i.e., Apple, IBM, and AT&T) of course did not create the mailing lists. It was done by interested parties. I think that it is past time for the creation of a more open mailing list. I do not have any accounts other than the one generously provided by AJPO. However, if someone would either provide me with an account somewhere for the purposes of creating a more commercially-oriented Ada mailing list, or would like to moderate such a list themselves, please let me know. The issues I brought up in my earlier message still stand. In essence, for the Ada community to grow and improve we must begin to think in commercial terms. I realize that it is still early, and I do not fault the Ada compiler vendors for their (currently) limited efforts in the third party area. I would also like to see the Ada community as a whole give increasing attention to the commercial use of the technology. -- Ed Berard (301) 695-6960 P.S.: I would like to thank Karl Nyberg for taking the time to respond to my original message. I found his comments useful and informative.