FERGUSON@BKNLVMS.BITNET (11/15/88)
God Dammit Apollo! Would you please stop jerking us
paying customers around?!?!?!?!?!?!?
We work hard on our graphics software, I put it in your
stupid ADUS free software library, and you can't even
give us the graphics support? What kind of jerks have you
people turned into?
Did the graphics developers have any say in this decision
to charge extra for GPR?
Charging extra for GMR 2D, and 3D have been bad enough, but
now GPR?
I'll bet you're about to pull one of those IBM/Microsoft moves
and make the current GPR calls incompatible with the next
version like you did with GMR2D, so that we'll absolutely
have to buy it.
I think I'm going to stop telling our potential Sun customers
to consider Apollo before buying. Why should I do you people any more
favors?
A note to you Apollo R&D folks responsible for the development
of GPR, GMR2D and GMR3D: I would like to hear from you on this net
to explain whose brilliant idea this is, and whether you agree or
not.
Scott Ferguson
Bucknell University
Tired of putting up with corporate bull____
ferguson@bknlvms.bitnet
Note: Although a high percentage of my colleagues share my
view on this matter, it does not reflect any official
viewpoint of Bucknell University.krowitz@RICHTER.MIT.EDU (David Krowitz) (11/16/88)
Whoa, pardner ... I've been speaking to some of the people at Chelmsford, and although no one has been able to give a clear picture of everything that has been going on, I have been able to glean a little information. 1) First of all, GPR is still bundled with Domain/OS and will remain there for the fore-see-able future. The DM requires it, as does X-windows, DSPST, and others. 2) I am told that Domain/OS includes a right-to-execute license for the 2-D GMR runtime library, but that you have to buy the manuals and media (on the order of $100) because not everyone uses it and wants to pay for it. I'm still trying to find out what other graphics products have run-time licenses bundled with the OS. Our current nodes came with 2-D GMR bundled with the hardware, so I suspect that current customers all own 2-D GMR development licenses in addition to the runtime licenses. I'm waiting for a reply on this one, though. We *will* have to start paying maintenance on 2-D GMR seperate from the OS, *and* we will have to start paying maintenance for the OS seperate from the hardware. We will no longer have to pay for TCP/IP, as that has been bundled with the OS. I am waiting for a revised series of contracts to get to me (sometime next week) so I can total up the changes and see what the new overall cost will be. I expect it to be higher. 3) Back around SR9.2 - SR9.5, 3-D GMR was bundled with the OS, which in turn was bundled with the hardware. We bought at least one or two machines in this period, and we got a copy of manuals and media for the SR9.5 version. We have not paid maintenance on the product, as no one was using it. I'm trying to find out whether this means that we still own a runtime and/or development license for this product and can simply order another set of manuals and media. Apollo has been extremely (VERY EXTREMELY!) out of line in not providing current customers, their field service offices, and even the sales force with the information about how they are restructuring their licenses. We have received no (absolutely none) letters, flyers, or even phone calls about this matter until the flaming began on this mailing list. Now that it has, I've received a couple of calls from people I know in Chelmsford who are trying their best to get out the correct information. The people who started this whole mess, however, should be getting their Xmas bonuses from Sun shortly. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
dj@dorsai.cognet.ucla.edu (David J. Wells) (11/22/88)
The recent flames don't seem to be appropriate for this news group. These flames have been directed at Apollo's marketing decisions, whereas the Apollo people who read the group are likely to be engineers. If you *really* want to flame Apollo marketing decisions, do it right! Get the address of the Apollo person who handles user complaints, and write a letter to him/her. It may not feel as good as a hot flame to comp.sys.apollo, but your letter is more likely to get something changed. David J Wells dj@cs.ucla.edu w213/206-3960
casey@admin.cognet.ucla.edu (Casey Leedom) (11/25/88)
| From: dj@cs.ucla.edu.UUCP (David J. Wells) | | The recent flames don't seem to be appropriate for this news group. These | flames have been directed at Apollo's marketing decisions, whereas the | Apollo people who read the group are likely to be engineers. Just to let you know that there still some dissent available from this quarter, I'll make this one last followup (I'm thankfully moving on to a new job that doesn't require working with Apollos). Some of the flames have dealt with marketing decisions, most notably the unbundling of some of the graphics libraries, the down grading of some previous Apollo functionality (eg. Fortran library support) towards that of UNIX, and the unannounced nature of some marketing decisions. I definitely like David Funk's suggestion that Apollo simply include the graphics libraries in their distribution and charge extra for the manuals. I think Apollo should seriously consider this suggestion. Two suggestions have already been made to accommodate the Fortran library support using the COFF object file format (compiler switch -split and extended COFF headers). It's easy to let something slip through the cracks when trying to describe all the new/different features of a release as large as an operating system and one which is as drastically changed. The question is how the company deals with the resulting problems and user complaints. I'd give Apollo an ``F'' on this one. Finally though, I want to point out that a majority of my complaints have been and continue to be the technical quality of Apollo's product: both hardware and software. SR10 has made some major inroads towards fixing software problems in previous releases, but is still a long way off the mark and some of the ``fixes'' have evidenced an incredible amount of ``Not Invented Here''. It's unbelievable to me that a company with as many resources as Apollo can't do any better, but that's not my problem any more. Casey
oj@apollo.COM (Ellis Oliver Jones) (12/06/88)
In article <8811160706.AA01866@umix.cc.umich.edu> FERGUSON@BKNLVMS.BITNET writes: > Did the graphics developers have any say in this decision > to charge extra for GPR? Once again with feeling! HERE'S THE SCOOP ON UNBUNDLING! GPR is bundled. The whole kit and kaboodle, including /lib/gprlib and all the header files, is bundled with the system software. I just rechecked the software release areas for SR9.7.1, SR10, SR10.p (DN10000), and SR10.1, and I know this to be true. GPR will also be included with SR10.1.p. If it isn't I won't sign off on it. I cannot imagine a Domain/OS system in which GPR was not present. I don't think it would work at all. Everything I can think of in the way of graphics and text software depends on GPR, including the DM, X, DSPST, the debuggers, CRP (create_remote_process), the VT100 emulator, the dumb terminal emulator, the 4014 emulator, GNU Emacs, etc, etc, etc. GPR IS BUNDLED. WE HAVE NO PLANS TO UNBUNDLE ANY PART OF GPR. PERIOD. --- -- ------- -- ---- -- ----- -- -------- --- ---- -- --- ------ > Charging extra for GMR 2D, and 3D have been bad enough ... We've charged extra for 3dGMR almost since its beginning. It's a lot of code, it's costly to develop and support, the two large manuals are expensive to print and ship, and not everybody wants it. At SR10, 2dGMR did get unbundled. However, every node still has a license to use 2dGMR at runtime. That's still bundled. If you want to use 2d GMR with SR10, you have to get the bits and the manual somewhere. If you get the bits and the manual from Apollo, we charge you $180 at most (sorry, I don't know prices or order numbers) for a media kit. You don't have to buy one kit per node, you just have to get the bits and the manual somewhere. By hook or by crook! Multiple node sites usually buy just one runtime kit, at most. Lately we are charging substantially more for the 2d GMR DEVELOPMENT kit to new customers. Anyone who was a 2dGMR user before Feb 1st, 1988 is "grandfathered," however. These customers (including Scott Ferguson at Bucknell and David Krowitz at MIT) can, if they wish, order the developer's media and documentation kit (again $180 at most). I'm sure there are less formal and equally good ways of getting the bits and books as well. If you have 2dgmr-dependent software which you wish to give to someone else, give them the gmrlib too if you like. They're not violating their license agreement by running 2d gmr on their nodes, even if they don't get the bits straight from Apollo. Please do take care to make sure you run the right version! Otherwise you're not taking advantage of a lot of Apollo's hard work in configuration testing, and you may get bizarre errors. Many customers will buy a runtime kit so they can be sure about this, although you don't have to if you know someplace else you can get it. > I'll bet you're about to pull one of those IBM/Microsoft moves > and make the current GPR calls incompatible with the next > version like you did with GMR2D, so that we'll absolutely > have to buy it. Baloney. Speculation. FALSE. We put a lot of effort into GPR compatibility, and it would be over the dead bodies of many engineers here that we'd pull such a stunt. Plus, many key OEMs and software vendors would drop us like a dirty syringe if we were so stupid. Plus, we're not unbundling GPR. This is not to say that we couldn't clean up the GPR interface a lot if we could make incompatible changes. From the point of view of the cleanliness and ease-of-use of the GPR interface, it's too bad we can't change GPR. > I think I'm going to stop telling our potential Sun customers > to consider Apollo before buying. Why should I do you people any more > favors? Please don't do that! We do need your support! > A note to you Apollo R&D folks responsible for the development > of GPR, GMR2D and GMR3D: I would like to hear from you on this net > to explain whose brilliant idea this is, and whether you agree or > not. Hey, I'm not going to break ranks (any more than I've already done in this message :-). Seriously, I do agree with the current policy as it stands. I don't agree with charging extra for GPR or 2d GMR runtime. Fortunately, that's not the current policy. It is, however, a great shame that we didn't get the word out sooner and more clearly about the 2d GMR change. Just finding it gone, without explanation, certainly eroded your confidence, and for a really dumb and avoidable reason. No one person's to blame. Now we have to work to regain the trust we lost. You all can help! Quit with the false rumors about unbundling GPR, willya plluueeezze? If we at Apollo can give any further clarification on these issues, please ask. Thanks again for your business, and thanks for taking the time to help straighten this out. /Ollie Jones Graphics Software Engineer, Apollo Computer, Inc.
oj@apollo.COM (Ellis Oliver Jones) (12/06/88)
In article <40147143.d5b2@apollo.COM> oj@apollo.com (Ollie Jones) writes: >In article <8811160706.AA01866@umix.cc.umich.edu> FERGUSON@BKNLVMS.BITNET writes: >> Did the graphics developers have any say in this decision >> to charge extra for GPR? > >Once again with feeling! HERE'S THE SCOOP ON UNBUNDLING! > >GPR is bundled. The whole kit and kaboodle, including >/lib/gprlib and all the header files, is bundled with the system >software. I just rechecked the software release areas for >SR9.7.1, SR10, SR10.p (DN10000), and SR10.1, and I know this to be true. >GPR will also be included with SR10.1.p. If it isn't I won't sign >off on it. > >I cannot imagine a Domain/OS system in which GPR was not present. I don't >think it would work at all. Everything I can think of in the way of >graphics and text software depends on GPR, including the DM, X, DSPST, the debuggers, >CRP (create_remote_process), the VT100 emulator, the dumb terminal emulator, >the 4014 emulator, GNU Emacs, etc, etc, etc. > >GPR IS BUNDLED. WE HAVE NO PLANS TO UNBUNDLE ANY PART OF GPR. PERIOD. >--- -- ------- -- ---- -- ----- -- -------- --- ---- -- --- ------ > >> Charging extra for GMR 2D, and 3D have been bad enough ... > >We've charged extra for 3dGMR almost since its beginning. >It's a lot of code, it's costly to develop and support, >the two large manuals are expensive to print >and ship, and not everybody wants it. > >At SR10, 2dGMR did get unbundled. However, every node still has a license to >use 2dGMR at runtime. That's still bundled. If you want to use 2d GMR with SR10, >you have to get the bits and the manual somewhere. If you get the bits >and the manual from Apollo, we charge you $180 at most (sorry, I don't >know prices or order numbers) for a media kit. You don't have to buy one >kit per node, you just have to get the bits and the manual somewhere. >By hook or by crook! Multiple node sites usually buy just one runtime >kit, at most. > >Lately we are charging substantially more for the 2d GMR DEVELOPMENT kit to >new customers. Anyone who was a 2dGMR user before Feb 1st, 1988 >is "grandfathered," however. These customers (including Scott Ferguson at Bucknell >and David Krowitz at MIT) can, if they wish, order the developer's media >and documentation kit (again $180 at most). I'm sure there are less formal >and equally good ways of getting the bits and books as well. > >If you have 2dgmr-dependent software which you wish to give to someone >else, give them the gmrlib too if you like. They're not violating >their license agreement by running 2d gmr on their nodes, even if they >don't get the bits straight from Apollo. > >Please do take care to make sure you run the right version! Otherwise >you're not taking advantage of a lot of Apollo's hard work in configuration >testing, and you may get bizarre errors. Many customers will buy a runtime >kit so they can be sure about this, although you don't have to if you >know someplace else you can get it. > >> I'll bet you're about to pull one of those IBM/Microsoft moves >> and make the current GPR calls incompatible with the next >> version like you did with GMR2D, so that we'll absolutely >> have to buy it. > >Baloney. Speculation. FALSE. We put a lot of effort into GPR compatibility, >and it would be over the dead bodies of many engineers here that we'd pull >such a stunt. Plus, many key OEMs and software vendors would drop us like >a dirty syringe if we were so stupid. Plus, we're not unbundling GPR. > >This is not to say that we couldn't clean up the GPR interface a lot >if we could make incompatible changes. From the point of view of the >cleanliness and ease-of-use of the GPR interface, it's too bad we can't >change GPR. > >> I think I'm going to stop telling our potential Sun customers >> to consider Apollo before buying. Why should I do you people any more >> favors? > >Please don't do that! We do need your support! > >> A note to you Apollo R&D folks responsible for the development >> of GPR, GMR2D and GMR3D: I would like to hear from you on this net >> to explain whose brilliant idea this is, and whether you agree or >> not. > >Hey, I'm not going to break ranks (any more than I've already done >in this message :-). Seriously, I do agree with the current policy as it >stands. I don't agree with charging extra for GPR or 2d GMR runtime. >Fortunately, that's not the current policy. > >It is, however, a great shame that we didn't get the word out sooner >and more clearly about the 2d GMR change. Just finding it gone, without >explanation, certainly eroded your confidence, and for a really dumb >and avoidable reason. No one person's to blame. Now we have to work to >regain the trust we lost. > >You all can help! Quit with the false rumors about unbundling GPR, willya >plluueeezze? > >If we at Apollo can give any further clarification on these issues, >please ask. Thanks again for your business, and thanks for taking >the time to help straighten this out. > >/Ollie Jones Graphics Software Engineer, Apollo Computer, Inc.
oj@apollo.COM (Ellis Oliver Jones) (12/06/88)
One of my colleagues (who prefers not to post this himself) had these remarks when he read my first reply to Scott Ferguson's posting. > I'll bet you're about to pull one of those IBM/Microsoft moves > and make the current GPR calls incompatible with the next > version like you did with GMR2D, so that we'll absolutely > have to buy it. The decision to change GMR2D was not made to force people to pay for it! It came about after _much_ deliberation only after we had decided that there was no way to fix certain deficiencies without introducing incompatibilities. We were hearing enough about these deficiencies to convince us that we had to respond to them, that their overall cost was hurting our customers more than what it would cost to fix them. It's always painful to impose a transition cost; it's an admission that the original product was not perfect in design, and it's an imposition on the customers. We took this step only after convincing ourselves that it was the right thing to do and taking care that the transition problems would be minimized. > A note to you Apollo R&D folks responsible for the development > of GPR, GMR2D and GMR3D: I would like to hear from you on this net > to explain whose brilliant idea this is, and whether you agree or > not. The folks in R&D worked closely with Marketing and Customer Support to agree on a sane approach to the unbundling issue. EVERY Apollo customer was contacted and warned that this would be happening with a letter dated 12/8/87 which outlined the reasons for the changes and the steps we were taking to ease the process. We followed with a telephone campaign this past summer and fall. What we found was that most sites had not managed to transmit the 12/8/87 letter to the people most interested, so that, despite our efforts, there was a lot of surprise and anger out there. We certainly didn't want that. /Ollie Jones Graphics Software Engineer, Apollo Computer, Inc.