SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Wed, 4 Apr 2007 17:03:40 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Other choices

Content Type: text/plain

At Warpstock98 in Chicago others presenters in other sessions
offered their approach to supporting OS/2 application
development. Among them was a group which was a
forerunner to ODIN. Continually we had those who wanted
IBM to release OS/2 source code to the community.

ODIN has produced mixed results, but nowhere new the
universality it sought. Few users cared to find themselves a
test bed for an "as is" solution which may or may not work
for an application of interest to them.

While I had my doubts about the ultimate effectiveness of
ODIN I had no doubts about the dangers and disappointment
engendered by IBM's releasing the OS/2 source. Sometimes
you have to exercise care in what you ask for.

If you accept that OS/2 and now eCS is a software "package"
and not an application (program) or application system (set of
related programs) but a somewhat more extensive
hodgepodge of software, you can relate it to our experience
in open source support since that time. We have lesser
application systems like Mozilla (and its offsprings) and
Openoffice in which we continue to lag behind in terms of
versions with respect to Windows and Linux.

That lag behind represents the changes we have to make to
each to catch up. That's another definition of backlog. We
have it in readily available open source...and we still cannot
maintain pace. What chance would we have if IBM could have
released the OS/2 source?

What chance do we have in continuing within a process, using
the same tools in the same manner as other open source
projects, of either catching up or maintaining pace? More
specifically of falling ever farther behind?

Rumor has it that IBM had an 18-month development cycle for
each fixpak. In order to maintain a 6-month release schedule
it had to have three maintenance teams working concurrently
on different fixpaks. Then yet another team had to come up
with patches, so-called PTFs (Program Temporary Fixes), for
critical customer situations, providing a short-term solution for
later inclusion in a longer-term one. Note once more that the
process IBM utilized then which it still maintains with respect
to software releases did not and does not make a dent in the
ongoing change backlog.

I didn't invent the backlog problem. IBM devoted considerable
resources to addressing it, the most recent being the switch to
"current" OO programming technology. This had the intent
with its possibilities of reuse, class libraries, methods, and
inheritance of addressing the backlog problem. If anything,
today the problem grows at a rate (measure in terms of
software costs and intervals between versions) greater than
the OO technology it replaced.

Now what causes a backlog? When the time to respond to
change requests exceeds their average arrival rate. it's that
simple. That time to respond depends upon the number,
sequence, and synchronization of the different source changes
which must (or should) occur through the various SDP stages.
In third-generation, in fact for all imperative programming
languages the source maintenance occurs manually. The only
exceptions occur for software productions from source like
flowcharting programs.

Here we have an example of two productions from a single
program source code, an object module and a visual
flowchart. So why not increase it from two to three or four
or more? We have vendors advertising to do the same for
UML documentation, all 16 different documents. What we do
for creating flowcharts we can do for creating UML
documentation.

Note that these rely on a single source solution based on
software and not people. Note also that going from an
imperative (third-generation) to declarative
(fourth-generation) language further employs software
replacing manual source maintenance.

The Warpicity Proposal offered the logical conclusion of the
previous facts. One language. One source. One
repository/directory. One tool. One improved process.

More importantly the enhanced degree in which it empowered
one person. That makes even more feasible a boosted aspect
of open source: the ability of an individual to pursue his
interests without dependence on others for a customized
solution.

So what do you propose to a threatened and diminishing
software community that lies within their available people
resources to reduce their dependence on third-party sources
and increase their level of self-reliance and -sufficiency?
ODIN? IBM OS/2 source code? No. Something intended to
eliminate backlog. That's how you keep pace with the
competition.

As long as they stick with their software processes, you not
only keep pace but actually move into the lead.

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

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 [ 04 | April | 2007 ]

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.