home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / mac / oop / macapp3 / 251 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!olivea!apple!applelink.apple.com
  2. From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: * Takeover Proposal *
  5. Message-ID: <724754122.1168942@AppleLink.Apple.COM>
  6. Date: 19 Dec 92 08:23:00 GMT
  7. Sender: usenet@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 74
  10.  
  11. Are you all as nervous as I am about Bedrock? Here are a few of the things that
  12. have me worried at this point:
  13.  
  14. - Possible exorbitant license fee. ($10K??? Annual, or what?)
  15. - Possible additional exorbitant license fee for source code.
  16. - Possible non-availability of source code. (Anyone who reads MacAppTech$ will
  17. agree that any substantial project will definitely need read-access to source
  18. just to figure out how to use some of the framework's features, and will almost
  19. certainly need write-access to repair framework bugs.)
  20. - Questionable degree of direct Apple involvement, per one recent report -
  21.     - bad, because Apple should definitely be involved for timely introduction
  22.       of new managers, etc.
  23.     - good?, because Apple has such a dismal track record of standing behind
  24.       its frameworks after convincing us developers to use them
  25. - Questions about WHICH former MacApp creators are helping create Bedrock. (All
  26. of the names I recognize from the past 3 years of MacAppTech$ and MADA
  27. conference reports now have "Taligent" in their e-mail addresses, not
  28. "Symantec".)
  29. - Delivery date????
  30.  
  31.  
  32. So maybe I should plan on keeping my Mac app in MacApp 3.0x forever, and worry
  33. about picking a separate platform for the eventual Windows and UNIX versions.
  34. But the problems with MacApp 3.0x include:
  35.  
  36. - Uncertainty whether bug-fix releases will continue, and for how long. (A
  37. recent posting from Kent Sandvik seemed to suggest that at least some "fixes"
  38. are simply going to be added to the "Known Bugs" document, rather than to the
  39. code itself.)
  40. - Growing obsolescence of the framework, as it falls further and further behind
  41. Mac OS development.
  42.  
  43. Now, maybe the Component Workshop will blow both of these frameworks from
  44. consideration. If not, though, then I have a SERIOUS proposal regarding MacApp:
  45.  
  46.       ****************************************************************
  47.       * Somebody, probably MADA, should BUY MacApp from Apple, and   *
  48.       * hire a few good people to maintain and update it. Full time. *
  49.       * Without transfering them to other projects every six months. *
  50.       ****************************************************************
  51.  
  52. I'm *not* proposing that MADA create MacApp 4.0. But wouldn't it be nice if
  53. there were SOMEBODY reviewing all of the bug reports and discussions on
  54. MacAppTech$ who would then actually change the MacApp source code accordingly?
  55. A LOT of the bug reports are trivial little fixes, with no worries about
  56. distant side-effects, so why should every MacApp developer always have to
  57. individually modify his/her MacApp source?
  58.  
  59. If somebody writes a new module for MacApp (a QuickTime-displaying window, for
  60. example) or rewrites the source to provide a new feature (Object Model support,
  61. for example), why can't the rest of us benefit from that work? If the creator
  62. doesn't want to give away his/her work for free (and judging by the history of
  63. the Class Room project, that seems to be a problem for some people), then MADA
  64. could BUY the rights to add it to MacApp.
  65.  
  66. I would be happy to subscribe to a quarterly CD from MADA. Or maybe Apple would
  67. be willing to distribute MADA's MacApp on ETO. (Then Apple management could
  68. finish what it has started, and COMPLETELY eliminate Apple's budget for MacApp
  69. support.)
  70.  
  71. My basic proposal is this: if Apple is not going to continue FULL support for
  72. MacApp, then they should sell it to somebody else who WILL. There are plenty of
  73. us out here with financial stakes in our current MacApp work to help subsidize
  74. such an effort.
  75.  
  76. Perhaps some of you will have a reaction?
  77.  
  78. -- Dave Goldman
  79.    Research Software Design
  80.  
  81. P.S. I'll download the archives next week, but in the meantime I would
  82. certainly appreciate your sending a copy of your responses directly to me
  83. (ALink: RSD; Internet: RSD@applelink.apple.com)
  84.  
  85.