The Warpicity Proposal

By Lynn H. Maxson lmaxson@ibm.net

A Brief History

At WarpStock98 I presented the Warpicity Proposal. That proposal came as a result of a frequent and often intense exchange of CompuServe responses between John Soo Hoo and myself and with other brave enough at times to chime in. Somewhere towards the end of this exchange Stanley Sidlov, the WarpStock98 program chairman, suggested that we had an interesting topic that we should present. John demurred. I concurred. History will probably show him the wiser.

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.

What is Warpicity?

The Warpicity Proposal offers a systemic solution protecting users' OS/2 investment, wresting control of OS/2's future away from any dependency on IBM, and enhancing its capability in terms of features, functions, device drivers, and applications. It is a proposal that deals strictly with software, its development, maintenance, and support. As such it deals with three aspects of it: (1) an organization, (2) its staffing, and (3) the methodology for the staff to use.

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.

The Organization

We need a fee-based organization. It needs regular income. Base it on an annual subscription fee. Make it affordable to all. Set the fee at some low rate, say $20/year. Have the members function as a board as a whole. No officers. No middle wear. Just the board and the staff. Minimal overhead.

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 Staffing

The staff shall consist of only two "responsible" contract employees, the Chief Communicator and the Chief Developer. Regardless of who screws up the buck stops here. With that responsibility goes the authority. Complete authority.

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.

The Methodology

50,000 members. $20 each. $1,000,000 budget. A responsible staff of two. How do you compete with vendors with staffs hundreds of times larger and corresponding budgets? By working smarter. By not repeating their mistakes. By making them have to copy you instead of vice versa in order to survive. That's how.

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 of theirs.

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.

Reality check

By this time you should have a new appreciation for the term "systemic". In truth the DA does not exist. SL/I is only partially defined. The UND is full defined, but not implemented. That's why it has gone from the Warpicity Proposal to the Warpicity Project. But that is about the greatest distance it has gone thus far.

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 economic equation.

A Final Perspective

We have a goal of reducing the cost of software development and maintenance to an individual affordable level. If we do that, then it is obviously affordable to any group of such individuals. Individually or as a group the will have the ability to protect their existing software investments as they seek other software investments, including enhancements to existing. They will be able to move as rapidly as technology moves. Their software will be scalable to any level that best matches their needs.

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 ones.

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 lmaxson@ibm.net. If you are of a mind to challenge anything in this, that's an exchange I would welcome.

editor@os2voice.org
[Previous Page ] [ Index] [Features] [Next Page ]
VOICE Home Page: http://www.os2voice.org