VOICE Home Page: http://www.os2voice.org
[Previous Page] [Next Page]
In the May issue of Voice Louis Muollo wrote an article in which he described
a means of users pooling their financial resources to fund known and experienced
talent to write selected device drivers. As this overlapped in part the Warpicity
Proposal someone contacted Louis who contacted me and then contacted VOICE to ask
me to participate in an IRC session. VOICE, namely Mark Dodel did, and I agreed.
I also agreed to write this article so that participants would have both reference
material and time to come up with in depth questions.
Somewhere in all this I was given a section 20 Warpicity Project in OS2CFORUM
on CompuServe which is now underway. There I and my collaborators attempt to do
on a daily basis what sometime in July we will do in an IRC session.
Thus the use of the term systemic. It does not address a part, as do most other
proposals, but the whole with each aspect supporting the needs of the others. Unabashedly
it runs rampant over establish paradigms in all three aspects.
So how do we protect users' OS/2 investment? Through the users funding their
own support. How do we wrest control from IBM? Through doing what IBM does in a
fixpack: replace old modules with updated ones. We have as much right to replace
modules as does IBM. A gradual replacement process over a two- to three-year period
could see the complete replacement of all IBM closed source code. If we were going
to sell this replacement, we would have to give it a different name. That IBM gets
to keep. So we call ours Warpicity. Any new user who wants to join in the interim
simply has to purchase a licensed copy of OS/2. How do we enhance its capabilities?
In the same manner that we provide replacement modules.
That's what we do. What do we need to do it? An organization for funding and
making decisions. A staff to support the needs of the organization. The methodology,
including all tools, to make staff support possible. Three things.
Make it web-based and internet accessible. Make all the business of the organization
available to every member through the website. If it is not on the website it does
not exist or just a rumor and does not count. Make all the financial data available.
Make all the system data available. No member should have to resort to any other
resource when it comes time to make a decision.
With your membership you have full access to and unlimited use of all community-developed
resources including tools and all source. In general membership provides ownership
of duplicates or copies with no restrictions on their use. This makes the open source
movement look like a higher-price spread. You can in fact give away copies and copies
of your copies to your heart's content. You can in fact use your copy to establish
a competing organization.
Furthermore all decisions of the organization, and thus the membership, flows
from direct democracy only: one member, one vote. Majority rules. If a minority
feels neglected, they can set up a competing organization on their own without having
to leave this one.
The estimated size of the organization for self-supporting purposes is 50,000
members at $20 each for an annual budget of $1,000,000.
The Chief Communicator will provide all the administrative support needed, act
as an interface between the board and the Chief Developer, and in general respond
to the needs of the membership. The Chief Developer will develop and maintain software
according to the directions given by the board. A clear division of labor. An even
clearer indicator of fault.
How do you do that? How do you work smarter? By shifting all software clerical
support from manual to machine labor. By doing for your own process what you have
routinely done for client processes for over forty years now. It's more than time
enough to do it on your own. It's reasonable to expect to gain at least the minimal
any client has gained.
What is that minimal gain? 50 times time reduction. 200 times cost reduction.
That makes your staff of two more productive than 99% of the IT staffs worldwide.
Certainly it makes them less costly. It makes your $1,000,000 budget equal to $200,000,000
What manual clerical support do you replace? At least one noted for its slowness,
its inefficiency, its error-proneness, and its high cost. It's called programming.
We call its clerks programmers. Or in Linux, hackers. Whatever we call them we replace
them with something faster (about a million times), efficient, error-free, and cheap.
All in all not a bad exchange. It's about time we got the same benefits as our clients.
It's our technology.
In effect we reduce all the various job descriptions of an IT staff to two, that
of a communicator and that of a developer. The communicator is responsible for accepting
requirements and changes from the users and converting them into formal logic specifications.
The developer takes the specifications through the entire development process, producing
an executable (or executables). The communicator then delivers these along with
any necessary documentation to the users.
Both the communicator and developer require clerical support. This clerical support
exists in a single tool called the Developer's Assistant (DA). Both communicator
and developer write in a formal logic specification language called Specification
Language/I (SL/I). It is the only formal language used. As it is based on a formal
logic known as the predicate logic it is capable of expressing all possible logical
expressions including its own specification. It has none of the limits imposed in
the implementation of any programming language. It has no need for a standards committee.
As the only source used exclusively throughout the process it is impossible to introduce
an incompatibility. Not even contradictions are incompatible.
The DA in fact is a realization of the integrated tool set depicted in the tools
layer of IBM's AD/Cycle. As such it uses also a realization of the integrated data
set represented by the Data Repository of AD/Cycle. The integration of the data
within the Data Repository occurs through the use of the Universal Name Directory
(UND). The UND provides a means of assigning unique names to every referent as well
as supporting an unlimited number of homonyms (same name, different referents) and
synonyms (different names, same referent). Its homonym support also supplies a universal
concept of version control on any name regardless of its referent. This extends
it beyond the scope of existing version control software.
If you take the implications of a successful DA seriously, it means the devastation
of all existing IT staffs. They cannot compete in terms of productivity and cost
as they currently exist. They cannot. The biggest losers are programmers. Of their
population only a few will successfully transition to a developer. Only a few because
that's all that will be needed to supply user demand.
The upside of having a successful DA lies in the vendors who adopt it. They will
now supply their applications for multiple platforms for less cost, significantly
less cost, than current methods do for a single platform. Even if they produce them
in a sequence the difference in time between successive platforms is only a few
minutes at most.
Thus understand the liberal policy of general ownership of community assets,
effectively giving the product away to every vendor willing to spend $20. They will
use it to produce more applications on more platforms at a lower user cost. They
can even afford to respond to an individual need ('build to order') at the same
cost as a single package in a volume production ('build to stock'). It's a different
Now all this occurs as a direct result of using a single specification language.
In that language a particular specification is either machine-independent or machine-dependent.
All machine-dependent specifications describe the architecture (instruction set,
etc.) of a specific target machine. We support two levels of machine-dependent specifications,
the lower for RISC and the next higher for CISC. All code production occurs through
translating the lowest machine-independent specifications into machine-dependent
The past is filled with promises of silver bullets. The estimated gains seem
too good to be true, thus they must not be. The references to what occurs in client
processes seems not to sway the doubters. Warpicity is not a silver bullet. It makes
its gains by doing old things in new ways. That's called process improvement. No
more. No less.
I hope that I have included enough to tease, anger, or otherwise stimulate you
to ask questions and participate in the upcoming VOICE IRC session (July 12th, 8PM
EDT on the WEBBnet IRC network in channel #voice). Every decision, every choice,
every systemic change has as its source the whole of my experience in the last 43
years in software development and maintenance. What you have before you is simple,
neither complex nor complicated. It's an application of the KISS principle throughout.
One software process. One tool. One language. Basically one person. With the tool
and the person forming a team.
I can be contacted on CompuServe in section 20 Warpicity Project in OS2CFORUM.
I can be contacted by email at firstname.lastname@example.org.
If you are of a mind to challenge anything in this, that's an exchange I would welcome.