Thread View: comp.sys.mac.oop.macapp3
2 messages
2 total messages
Started by Research SW Design, D Goldman,PR...
Mon, 04 Jan 1993 00:12
Takeover - Scope
Author: Research SW Design, D Goldman,PR...
Date: Mon, 04 Jan 1993 00:12
Date: Mon, 04 Jan 1993 00:12
62 lines
3357 bytes
3357 bytes
----------------------------------------------------------------------------
An organization capable of supporting MacApp
properly would have to include at a bare minimum two programmers (one only and
you are at the whim of sickness, vacation, and the attractions of greener
pastures elsewhere), one documentation person, one QA person (two would be
better) and at least one full-time manager (better two, one technical and one
business). And this is bare bones; it assumes, among other things, that tech
support is provided by the programmers, QA, and documentation folks; that
secretarial & etc. are part of some existing business structure; and that
training is provided by third parties.
----------------------------------------------------------------------------
Jeff --
Your idea of "supporting MacApp properly" is NOT AT ALL what I proposed in my
original message of this branching thread. What I DID propose was:
I'm *not* proposing that MADA create MacApp 4.0. But wouldn't it be
nice if there were SOMEBODY reviewing all of the bug reports and
discussions on MacAppTech$ who would then actually change the MacApp
source code accordingly?
Now, on a separate branch of this thread there is a discussion of how much
effort is needed to make a bug fix to MacApp. But if one accepts for a moment
that SOME percentage of bug fixes can be installed by a competent programmer --
working in conjunction with all of the developers on MacAppTech$ [why do all of
these discussions insist that all bug work and QA needs to be done in a
vacuum???] -- then to accomplish what I did propose would require a programmer.
Two, if you prefer. Period.
No documentation person. We're fixing bugs here, not creating a new system.
No separate QA people. That's the bulk of the programmer's job: take a bug-fix
already worked out on MacAppTech$ (or in Apple's existing bug doc!) and study
and test it. Put up a proposed fix on MacAppTech$ and let other brave souls try
it out. Put it on the next CD as a beta version.
No separate tech support function. If tech support means a place to get your
questions answered, the best place is currently MacAppTech$. If tech support
means a place to get MacApp bugs fixed, then we do not have any official tech
support at present.
No manager.
I agree that secretarial support comes from the existing structure, and that
training is not an issue.
Somebody used the phrase "keeping MacApp on life-support". That's what I'm
after. Right now the patient is bleeding from many small wounds, and Apple's
best response is to offer us periodic updates of a first aid manual (the Bug
Doc). And assure us that a healthier patient will be coming next year, along
with better health insurance (from a third party payer).
Why not transfer our current patient to a nurse who can read the first aid
manual and actually apply a few bandages?
-- Dave Goldman
Research Software Design
MA - Takeover or Death
Author: Michael D. Rossetti
Date: Thu, 07 Jan 1993 15:11
Date: Thu, 07 Jan 1993 15:11
46 lines
2637 bytes
2637 bytes
Friends, My thinking could possibly be flawed on this matter but I offer the following observation after having given some thought to the 'death' of MacApp, suggestions to have MADA or some other organization acquire it, etc: Observation: Bedrock will eventually ship. Bedrock _may_ not be the answer many of us are looking for (or maybe it'll just take some of us a bit longer to accept reality). Bedrock will destroy sales of MacApp. MacApp will eventually no longer be supported by Apple. MacApp is not likely to be a money maker for anyone (MacApp framework sales just won't be that high). No one else will pick up MacApp and put the money into it to perform serious bug fixes, enhancements, QA, et al. WHAT COULD BE BETTER? Haven't all of us (MacApp devotees) been reluctant to modify the MacApp sources? Haven't we been taught that if we muck with MacApp (MuckApp?) we stand a good chance of mucking things up when the next release comes out? Well, there isn't going to be another MacApp release! We can muck to our hearts content putting in all those neat fixes and improvements which we've wanted to for years! It's ours to do with as we please! Of course, any enhancements to the Macintosh extensions offerings (ie. Quickdraw GX, OCE) won't automatically get folded in. And we won't get PowerPC support and cross-platform capability. And... So maybe what we need to do is have MADA form a loose organization of MuckAppers who manage a library of changes and enhancements offered by the members, police one another, publicize status, solicit extensions, etc. QA becomes the responsibility of the group as a whole rather than a cost center. Sure, there'll be problems but maybe this deserves a bit 'o thought (because it's a fact MacApp's commercial support is going to dissappear). I'd love to hear some discussion on these thougts. Michael D. Rossetti Internet: mikey@wicat.com Jostens Learning Corporation AppleLink: WICAT WICAT Division CompuServe: 71102,475 1875 South State Street America OnLine: ROSSETTI Orem, Utah 84059-0539 USA (801) 223-3285
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads