SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Tue, 23 May 2006 17:24:20 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Moving right along

Content Type: text/plain

Greg,

Thanks for the biting input. It gives a lingering taste.

Two things.

One, when I participate in a democratic process I do what I
can to insure it stays that way. Thus people should feel free
to offer their input, engage in discussion, and then reach a
consensus on actions. In all this I have only one vote. So it
may very turn out that Steven has "predicted" the results. He
doesn't dictate them. Nor do I.

Two, you are very nearly on in your assessment of the effect
of the DA in combination with the language, the
interpreter/compiler option, and use of the data
repository/directory. I suspect you doubt such productivity
gain possible requiring no more than a process improvement
involving existing technology. Why should I have discovered
something that seemingly no one else looking at the same set
of features and functions managed to come up with as well?

In truth I haven't and they have. We have facts. And we
have what underlies them. I would only ask you to think
about the consequences of your assessment, if true, upon
software tool vendors, contract software providers, and
package software vendors. As for me I only go back to a
prediction by Richard Hamming in the mid-60's that in the
future 10 system developers would be responsible for all the
software written worldwide.

The group present from the Orange County Chapter of the
ACM, at which time I served as program chair, managed to
snicker and mumble among themselves at such foolish
"nonsense". I guess I had a bit more respect. I took it as
something of a challenge to understand what had to occur to
make that possible. Or else just how close could we come.

Now I won't go through the other presentations I have made
internally within IBM which met with similar resistance and
doubt along the lines that you express. At the same time it's
important that you realise other such attempts have occurred,
e.g. AD/Cycle, and yet another ongoing, ECLIPSE.

If a single difference exists between those attempts and mine,
it lies in my lack of interest in placing vendor needs, and thus
their continued existence, above that of the user. Thus
vendors will fight for and preserve their piece of the pie,
cooperating only to the extent it doesn't affect their
existence. Theirs then offers a piecemeal approach while
mine offers a systemic integration of pieces in which no
separation or isolation of features or functions occur. They
offer a set of packages, not necessarily designed with any
other in mind, while I offer a package which is a whole with a
seamless set of parts.

Theirs will not produce the productivity gains of mine. Theirs,
as they are profit-dependent ventures, will obviously cost
more than mine. They expect to continue as packages while
mine exists as a package.

Now you have two means of producing software. You can
"build to stock", i.e. package. Or you can "build to suit", i.e.
custom. In either case the cost gets distributed over the
number of units, which is N for "build to stock" and 1 for
"build to suit".

Now affordability gets down to the per unit price. Package
software pricing depends on a specific volume sold. Any
volume above that which recovers your cost then allows you
to make a profit. Actually you have to recover on a ongoing
basis other costs like support costs, maintenance costs, and
product upgrade costs. Either you price them separately, for
example on a subscription basis, or you somehow absorb them
in the package and individual package upgrade pricing.

We in the OS/2/eCS community know full well what happens
when a market cannot sustain the volume to make a package
profitable: vendors drop unprofitable markets. A dropped
market then must somehow fend for itself. If it cannot attract
another vendor, then it needs to act as its own.

That decision, however, comes with a "gotcha". The
difference between open source and closed source
(propietary) lies in one, closed source, has a business model
with money and profit in the equation, while the other, open
source, does not. To compare them then we need to take
money out of the closed source equation leaving only
resources, people and tools, as their common variables. So
you come down to variables of experience, skill levels, work
habits, and organization with people and features, functions,
and efficiencies of tools. On balance the organizational
efficiency of closed source gives it an advantage over open
source. That means for equivalent work output on any given
effort open source requires more people resources than
closed source.

Now specifically Greg and Steven I hope the consequences of
the previous doesn't get lost on you or frankly anyone else
who have managed to make it this far. If an open source
community uses the same tools as the closed source, for the
same source code it will need more people resources to
produce, i.e. develop and maintain, software within the same
intervals of time. Thus in the instance of an operating system
like either OS/2 or eCS, or web browsers like Mozilla,
Thunderbird, Firefox, or SeaMonkey, or office suites like
OpenOffice, if it cannot muster the resources, it must rely on
the "kindness" of strangers. Lately their "kindness" quotient
seems to have fallen off scale.

So if you don't want to have to depend on the "kindness" of
strangers, you want instead to rely on your own people
resources. If you as a market have fallen off the scale,
chances are you in the aggregate don't have enough people
resources to provide the concurrent development and
maintenance to allow you to keep pace. That means you
continually find yourselve here and there falling behind.

So why, I would ask anyone, would I want to use a tool set
which has productivity limits below what I need for the people
resources I have? Back in WarpStock98 in Chicago when I
made the Warpicity Proposal I viewed those believing that all
we needed was to release the OS/2 source to open source as
something of a deathwish. In parallel from that time to this
we have the development and maintenance experience of
Serenity Systems as well. We have no OpenOffice 2.0 for
OS/2/eCS. Where has all the "kindness" gone?

So if you want to use a version control system like CVS, you
can add it as an optional member of your tool set. That
differs from a tool set in which versioning, more than CVS has
even considered offering, is not optional, but integral. We
have an editor integrated with syntax and semantic checking
and code generation, something which exists with any
interpretive language system. We add the option for compiled
output from code generation which as an integrated package
doesn't exist for any compiler. We use a two-stage proof
engine with an exhaustive true/false proof based on predicate
logic, which on the basis of a 2 to 1 ratio of test to
development time means a savings of 2/3rds of total time.

We do it because we, acting as our own vendor, have no need
within our tool to preserve the existence of any other. So we
have seamlessly integrated features and functions, not a set
of features and functions in which we roam about editors,
compilers, languages, command line utilities, interpreters,
compilers, and version control systems.

Thus in open source we make up for loss of organizational
efficiency with the need for less aggregate people resources
due to productivity increase of our tool set. In that manner
we insure that we do not have to drop our own community as
others have as "unprofitable" due to the ongoing people
resources required.

As a final note Greg should have mentioned as another
consequence that the economic balance favoring "build to
stock" currently with the DA shifts to "build to suit". That
economically disadvantages "volume" package software
vendors. As a further consequence of self-sufficient,
requiring no additional administrative or management
overhead, organizations of 1 to 7 skilled member teams means
larger contract software and services providers become
competitively uneconomical.

Maybe in the end we will find that Hamming was not that far
off. You see, I didn't snicker.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 23 | May | 2006 ]

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.