SCOUG-General Mailing List Archives
Return to [ 03 |
January |
2003 ]
Content Type: text/plain
svobi,
PMSEEK is not open source. IBM has shown great reluctance
to participate in open source for OS/2 except for possibly
Mozilla. On the other hand PMSEEK might make a good
candidate for an open source project.
We have two more or less active projects with respect to
OS/2 on open source: freeos and osfree. Basically freeos
deals with the OS/2 kernel and API support while osfree
concentrates on OS/2 utility applications included within the
OS/2 package. Thus at the OS/2 API level freeos deals with
what lies below and osfree with what lies above.
We can associate PMSEEK with the osfree project as an OS/2
utility application. In truth at the moment osfree is the more
active. My personal interest lies in freeos, in the OS/2 kernel
support including PM. However, I have no intention of
beginning to code something that basically has no chance of
finishing.
Microsoft, IBM, and Apple make a huge financial investment in
having large numbers of programmers working full time to
develop, maintain, and enhance operating systems. These
numbers in turn get broken down into teams (probably three)
just to maintain a one major version release per year. That
implies a two-year development/maintenance cycle.
With respect to OS/2 IBM opted out of continuing this because
they could not get the money out for the money they put in.
It's obvious that Serenity Systems has neither the money nor
the personnel to keep pace either. Just note how often and
how long enhancements to eCS are in coming.
During my recent SCOUG presentation on open source Randell
Flint of Sundial Systems correctly pointed out that open
source development in general lacks the organizational focus
on which closed source depends. Not only do you have the
lower productivity of part-time versus full-time personnel, but
you don't have the direct project management focus. In short
relative to large programming efforts for something like an OS
open source is almost not the way to go. You don't have to
go any further than LINUX and its relative slow pace of
enhancements (intervals between versions) to use as an
example.
I've taken a KISS (Keep It Simple, Stupid) approach to bringing
open source efforts to a greater par with closed source. The
issue is one of individual productivity, which in any instance is
a ratio of input work over output results. You have the goal
of minimizing the amount of input necessary to produce a
given output.
Now work is energy expended over time. You thus have two
variables, energy and time. You have a need to minimize
both, energy because your principal activity, writing, is
time-constrained, and time because of the need to maintain
pace with the dynamics of change, the change rate, of the
problem set.
Individually our primary concern lies in time management. We
know the very minimal time lies in writing the source code.
We also know that it can never be less than the individual's
keystroke rate, i.e. his typing speed. If you add on to this his
thinking time, his rewriting time, his wait time, and a host of
other time-consuming activities like meetings, coffee-breaks,
etc., you get some idea of what contributes to a loss in
productivity.
You have to reduce the number of people writing. For the
remaining people you have to reduce the amount of writing
necessary. To reduce source maintanance you have to reduce
the number of different writings in specifications, analysis,
design, construction, and testing.
You do that by reducing the number to one: the writing of
specifications. This leaves the writing of analysis, design,
construction, and testing up to software. Oddly enough this
occurs in the shift from imperative HLLs like C, C++, and JAVA
to declarative HLLs like Prolog, Trilogy, Z, and SQL.
If you can also get rid of separate people-writing functions
like compiling, make, link, debugging, UML, flowcharting,
dataflows, structure charts, etc., you can restrict the
necessary source writing to specifications only. Again oddly
enough using an interpreter-based tool instead of a compiler
does this.
So you end up with one source language form, specifications,
and one processing tool, an interpreter, through which one
person can process one application, say an operating system,
at one time with the software providing all the necessary
descriptive output.
So you need a programming/specification language supporting
both imperative and declarative processing statements, which
at the moment doesn't exist. It doesn't exist as a single
language at the moment, but does exist in several. You need
then to merge the several into one which I have in SL/I, my
designation for such a language.
I've simply suggested that you take an open source editor and
an open source compiler as a starting point. You then merge
the functions of the compiler into those of the editor, shifting
the code generation to support interpretive execution as well
as the existing compiled execution.
Now there are other things you do along the way. If you
understand the editor and the compiler, then you will have
the expertise necessary to make the other changes. You can
begin with C and end up with an SL/I equivalent. All along
the way you will increase open source's competitiveness with
closed until you eventually overtake it.
=====================================================
To unsubscribe to this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-general".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
Return to [ 03 |
January |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
| 
