From: Lynn H. Maxson [mailto:lmaxson@...]
Sent: Saturday, July 24, 2004 10:42
To:
osFree@yahoogroups.com
Subject: RE: [osFree] Project Definition
John,
The project control itself has a documentation dynamic that
increases the people resources required as activities and their
relationships increase and change. Having been associated
with project control since its introduction in the 50's as PERT I
question its viability as a "management" tool in a purely
volunteer effort.
I don't question that some things, activities, precede, follow,
or overlap others. That understanding and agreement among
participants can lead to a more orderly process. I do question
the ability to set either dates or duration in any meaningful
manner. At this point you do not have the ability to control or
allocate volunteer resources to maintain critical path
schedules as the future need may arise.
You offer some hint at understanding the hypermedia
capabilities of using a website and html. You will not find the
skill in doing so evenly distributed, either easily learned or
applied. When they discover that the people cost in writing
documentation, its development and maintenance, easily
exceeds that of writing source code (programming) and that
testing which requires the synchronization of both again easily
doubles the people cost, we will have a better grasp on the
need for maintenance contracts.<g>
I don't say these things to detract from what you have started
here. I have always found the OS/2 replacement project
doable, but I see no need to introduce elements (activities)
before their "time". Such an "unfinished" set can seem
overwhelming and discouraging however factual.
Now I'm working on a software tool called the "Developer's
Assistant" to drastically reduce the people cost in numbers
and in effort. It uses the same database, as opposed to a file,
system for both source text and code. It not only allows full
"literate programming" a la Donald Knuth but applies it
globally to all documentation, including user guides, general
information, and reference manuals.
As long as you use the same tools as M$, IBM, and others you
will incur the same or greater people costs. IBM decided with
respect to OS/2 that it would no longer sustain the same level
and transition its support to eventually remove it from the
marketplace. The OS/2 community has neither the numbers
nor the financial wherewithal to assume what IBM found
necessary to sustain OS/2.
In short that means we cannot use the same tools and
methods in creating an OS/2 replacement...or compete with
whatever new incompatibilities M$ chooses to introduce. We
cannot work harder. Therefore we must work smarter.
You have chosen a project management style which to the
best of my knowledge no other open source project has
attempted. It's one that even closed source finds difficult to
manage and maintain. It requires both an additional skill set
as well as people resource.
I would probably suggest that we consider only development
a project control scheme for a sub-project like "Design an
OS/2 Replacement" with general activities like "Gather
Requirements", "Document APIs", etc.. Then we could break
this general activities as we gain familiarity into the more
detailed activities of the "information units", e.g. each API.
In my examination of the APIs I found particularly disturbing
the generic use of the variable name "rc" for "return code".
As the same values have different meanings depending upon
API involved it appears to me that each different set of return
codes have a unique name. I also don't happen to have C's
penchant for multiple fancy names for the same data types,
of which two dominate, a full word binary value or an
address. As a PL/I person not given to confusing things I'm
inclined to define the first as "dcl xxx fixed bin (31);" and the
second as "dcl yyy ptr;".
Just a few thoughts for your consideration.