In truth only one main issue exists: the aggregate amount of people resources and thus people time to develop and maintain open source. We need to consider for a given set of open source applications the time necessary. Simple division of some average person time, full, part, or some mixture thereof, will give the aggregate number of people necessary to maintain pace: to insure the dynamics of the open source matches that of its user's needs.

In general a mismatch of these dynamics, that the needs outpace the ability to service them, has vexed our profession from its inception. We know that as professionals we expend most of our energy writing in one form or another or in the necessary thinking preceding or associated with it. Open source differs not one iota from closed source in this aspect.

We call the net effect of this mismatch "backlog," i.e. pent up demand. We know it has something to do with the writing time. Every "modern" revolution introduced we embraced as it promised to somehow reduce it in the aggregate. For example, from the first generation of machine language we developed the second generation of symbolic assembler, a first generation higher level language (HLL). From there we went to third generation languages, e.g. C, PL/I, Pascal. And from there we went to fourth generation, e.g. Prolog and SQL.

When these in turn failed to solve the mismatch we decided the problem didn't lie as much with the language as with its application. As a result we developed object-oriented (OO) methods with an emphasis on reuse, one means of reducing writing.

Unfortunately three different OO methods, different ways of doing the same thing, resulted. The using community found this unacceptable, insisting on a "simplification". This simplification came in the form of a unification effort, resulting in the "Unified Modeling Language" or UML.

An unfortunate consequence resulted: an increase in the aggregate amount of writing necessary. This resulted in a greater mismatch of the two dynamics than existed in the previous, non-OO methods.

More recently we have seen the rise of two somewhat related methods: extreme programming and agile modeling. In theory both offer to reduce the amount of writing at the expense of increasing the people time involved, i.e. by increasing the amount of people content. Eventually the long term effects of both of these will result in an increase and not a decrease in the dynamics mismatch.

I offer this as an example of what happens when professionals want to do the right thing but go about it the wrong way. We have the net effect that for a given interval of time it takes more people to achieve less: a net loss in productivity. This is a situation we can't afford.

Basically as more and more closed source software disappears for OS/2, we will come to depend (again more and more) on open source. Given its importance then to our software survival, we should give more consideration to its future direction.

There's a whole system of tools involved with open source: CVS, client support, the source, the compiler, the editor, the makefiles, etc. Techies have accepted this paradigm because it distances them from the riff-raff or wannabes. Unfortunately it provides a barrier to entry that many will not venture to cross. But we must.

We in SCOUG can address this situation. We can introduce a software revolution that minimizes the people resources necessary to maintain the change dynamics of the OS/2 community as well as the overall software using community. We have sufficient representation. We have sufficient talent. We can begin to simplify open source, significantly reduce the number of tools and methods necessary, and put the OS/2 community as whole on the path to near self-sufficiency.

Copyright 2002 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.