home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / oop / macapp3 / 279 < prev    next >
Encoding:
Internet Message Format  |  1992-12-25  |  2.9 KB
  1. Path: sparky!uunet!olivea!apple!applelink.apple.com
  2. From: LENOIL@CATALOGIC.COM
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re: * Takeover Proposal *
  5. Message-ID: <9212251317.AA01223@apple.com>
  6. Date: 25 Dec 92 13:15:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 47
  10.  
  11. From: Robert Lenoil <lenoil@catalogic.com>
  12. Organization: Catalogic, Mountain View, California [Voice:
  13.     415-961-4649]
  14. To: MacApp3Tech$@AppleLink.Apple.com
  15. Cc: RSD@AppleLink.Apple.com (Dave Goldman)
  16.  
  17. Dave,
  18.  
  19. I like the idea of keeping MacApp alive for the scores who committed to it
  20. as a platform. But I'm not optimistic that MADA could effectively take over
  21. that maintenance role. Yes, just rolling in bug fixes that come in could be
  22. a one-man job, but that doesn't include testing on all supported Macintosh
  23. configurations, and it certainly doesn't include upgrading MacApp to
  24. support QuickTime, AOCE, AppleScript, and QuickDraw GX. And let's not
  25. forget the cross-platform thing. In short, it's one matter to maintain
  26. MacApp on life support but quite another to keep it current, let alone
  27. leading-edge. MADA could not undertake a project of that scope without a
  28. significant increase in its operating budget, which would probably require
  29. MacApp maintenance to be a fee-based service (members that have moved
  30. beyond MacApp would not want their dues being used to fund a MacApp
  31. lifeline).
  32.  
  33. What MADA is good at is publishing and distributing information and
  34. software. If a coalition of individuals took on the task of integrating and
  35. testing bug fixes and rolling in support for new technologies to MacApp, I
  36. think MADA could play a role in coordinating that effort and making the
  37. results widely available. There are successful instances of distributed
  38. development projects like that (GNU and Linux come to mind), but those
  39. projects have not been widely adopted by business users, who are
  40. justifiedly unwilling to stake their businesses on systems that are
  41. maintained by a loosely-coupled network of volunteers. My hunch is that the
  42. bulk of MacApp developers fall into that business user category.
  43.  
  44. So how can MacApp live on? It probably can't as the commercial framework
  45. that it is today. But it would be a shame to let the technology wither and
  46. die. I would like to see Apple release the MacApp code into the public
  47. domain, or to retain copyright but grant a no-fee license to use the code
  48. and to create derivative works. This simple act would likely make MacApp
  49. the overnight favorite framework among students and tiny developers. With
  50. that new expanded base of users, enough interest could probably be
  51. generated to keep the framework current via contributed modules and bug
  52. fixes. MacApp would become a learning tool for aspiring object-oriented Mac
  53. programmers that will create the amazing applications of tomorrow. That's
  54. not a bad retirement home for a venerable old framework.
  55.  
  56. Robert Lenoil
  57. MADA Vice President and Treasurer
  58.