The politics of the free MV project

Building a community;
Preventing history's repetition

In 1983, the R-83 PC version of the Pick Operating System (what we today call a MultiValue database environment) was released. At the time R-83 was released, MultiValue was a mini-computer based database environment with the various vendors selling near-100,000 seats annually. In the next four years, the PC version went from 0 to 300,000 seats, and the mini-vendors grew also, as new entrants went "up market" for larger systems.

Then in 1986/7 something went terribly, terribly wrong. Pick systems raised the price of their mini-product about 50% in a little less than two years ... and started trying to actively go "up-market." After a year's hiatus as customers fulfilled their obligations in the channel, found new-sales resistance, went up-market for larger, higher-value system sales (that sold fewer ports per man-hour of work), and in some cases retooled their products for non-MultiValue tool sets, sales of R-83 and its related PC products began to fall, and continued to do so over the next 15 years, amplified by a series of price increases that raised the price of the Pick brand products faster than the rise of college tuition in the USA (cumulatively, about 8x on a 5-year life-cycle basis over 20 years) to parity with the rest of the community (and to where the rest of the community had been at the start). As a result, the industry cumulatively only does about 130,000 seats a year as of this writing (i.e. in 2004), but all are extremely high-value seats (with a 5-year lifetime total tools cost approaching $2,000 per license user; and with solution costs generally exceeding $5,000 per user) going into environments where, practically, no other database can solve the business problems solved by MultiValue.

Fundamentally, the users at the top end of the MultiValue industry are extremely healthy, when compared with other industries. On averages, there is "success." But when you look at the business model for most database engines, you find two shocking facts. The first is that for any database model, "smaller" systems, the entry-level retail price in almost every instance is $100 per user, +/ $40, even though the top-end of all of these database industries price at or above the current MultiValue norms. Similarly, you generally find that 90 percent or more of all ports sold by a database industry are sold at the entry-level price-point. There is a very simple reason for this.

The first, and most obvious, reason is that more than 99.9% of all businesses, by count, are "small businesses" with 10 or fewer employees. The other reason is that the vast majority of businesses do not want to, nor need to, install complex integrated systems to be successful. Rather, all they want to do is to solve immediate and pressing problems. Put in dollars and cents, the average business is not willing to invest more than $300 to $1,000 of capital per (affected) employee on software-based automation at any one time (though they may cumulatively spend a good deal more over time in support, changes, and selective additions). Obviously, the price of database tools needs to, and in other industries does, adjust to this reality.

As important, not all systems developers are capable of selling, or indeed of fulfilling, complex, large, high-value systems. The vast majority of developers, even after 10 to 30 years of professional experience, will either be incapable of some aspect of the sales/delivery cycle, or in large numbers of instances just will not want to do it. (It is surprising how many people over time realize that they are better off and happier selling their individual services to customers rather than managing myriads of other individuals.)

And the most important thing is to recognize that anyone beginning in business -- a "Newbie" if you will -- is almost by definition totally incapable of selling or fulfilling complex systems.

The consumers of the goods or services of any industry consists of a bunch of individuals and businesses in a birth-maturation-death/retirement cycle. The MultiValue industry has had plenty of maturation over the last 15 years, as well as retirement and death, but it has had no births, and no room for people who's mature state was to serve small business.

To correct this lifecycle problem, the core presumption must be that every other database model has the pricing system right, and that MultiValue, as an industry had it "right" beginning in 1983, but that it went "wrong," beginning with that first pricing misstep by Pick Systems in 1986/7.

Actually, we should not say that the current supplier participants of the MultiValue industry are "wrong." Obviously, the providers of those large numbers of ports of "big-ticket systems" are taking care of and satisfying their customers. But their cost structures, and evolved ways of doing business have made their approach inappropriate for a significant part of the industry, or what could have been the industry.

Rather, what we should say is that there is a void in the industry that needs to be filled by someone for the good of all. This includes the good even of high-ticket vendors, because some of today's Newbies will, inevitably, become their most successful customers in 5, 10 or 20 years, as they evolve from Newbie to large systems supplier.

If we postulate the presence of such a new "right priced" entrant, we can infer that the industry, based upon the breadth of its top, and based upon the perseverance of that top, in spite of a 15 year absence of new blood, should consume more than one million ports a year in the relatively "short term" (i.e. less than a decade), and millions a year in the long term (as measured in decades), as the MultiValue adjusts to a normal birth, maturation, and death cycle.

For the good of all, the Open MultiValue Initiative set out to overcome the following problems.

1.	Delivering a complete set of tools at a price-point that is consonant with other databases: not more than $140 at retail price per licensed user for the entire set of tools, consisting typically of the engine, 4GL or other tools for further-accelerating development, and any terminal emulators, GUIizers or similar presentation tools.
2.	Assurance that prices cannot and will not be jerked up again as they were in 1986/87.
3.	Maximized cost control, and proper pricing methodology, in order to assure that cost pressures cannot undercut the achievements made.
4.	Encouragement of new methodologies and techniques that will keep the industry technologically current, but consistent with its core mission of driving down the costs of application development.
5.	Prevention, where possible, of the splintering that has been seen in the sales and support efforts of the Linux community, in order to prevent the diminution of effort inherent in such things.
6.	To the extent permitted by cost, and to the extent that there is long-term elasticity of demand (we believe there is plenty of historical precedent to suggest an overall elasticity of somewhere between 1:2 and 1:3 within the software tools business), to further drive down prices either selectively or globally for the benefit of the community and of ultimate users.

What you have not seen in the above are the words "open source" or "free" (as in "free beer") anywhere!. What you have seen is problems, opportunities, and necessities discussed. Open Source is only one tool to further solution of those problems. Lets talk about all of the tools and the reasons for their existence. In our opinion, the overall solution is to use the inherent mechanisms of Open Source to create a structured, but power-limited, oligarchy who's purpose is service to the community. This is intended to create a system that on the one hand prevents monopolies, but on the other has structure for basic services, as well as a system that inherently maximizes cost control.

Preventing totalitarianism and anarchy

The first, and most important component of this has been making the OpenQM MultiValue database environment available for license under the General Public License (GPL). Martin Phillips of Ladybridge Systems has done so with full fore-knowledge of everything that the GPL means. What most users don't understand about the GPL is that release of source under GPL puts knowledge, methods, and techniques into the public domain (the GPL is specifically intended to do so exactly this), rather than bottling this knowledge up in secrecy. Instead, it says that Copyright alone protects the specific expression that embodies these ideas. Thus, were there ever a need for a new MultiValue engine - for instance, because Martin were to raise his fundamental pricing significantly - there would exist the possibility to create a totally new product with near-identical capabilities from scratch, just as long as it was written with totally new words not plagiarized even in part from the original work. There is nothing wrong with a socially beneficial monopoly. Everyone benefits from having similar standards in such an environment. It is only when a monopoly becomes either overbearing or inefficient rather than enlightened that it causes a social problem.

This does not mean that the GPL or even more so the Library GPL (LGPL) is by itself desirable or actually socially beneficial in all instances. For instance, the Maverick MultiValue database engine being slowly developed for the MultiValue industry is provided under an LGPL license, meaning, effectively that it can be used by anyone for "free" (as in free beer). The problem is that due to the absence of assured revenue, development of such projects can often be totally volunteer, and consequently, timely development response, and an adequate support organization, may not develop.

A clear example of this can be seen in the battle between mySQL and PostgreSQL for mind share in the Linux community. MySQL is licensed under GPL, which effectively requires that all commercial development relying upon it must be done with mySQL's commercial license, rather than via GPL. Conversely, PostgreSQL is thought to be the more technically useful, robust, and scaleable product, but it is licensed under BSD terms (which are even more liberal than LGPL) and development is financed totally by charitable contributions. In the relevant market place, mySQL has an 85% market share, and PostgreSQL only has 15%. While one might attribute this to the fact that mySQL is a more-memorable name, I suspect that more fundamental issues are involved, because people choose their products based upon the long-term utility that they think that they can get from them, and an email discussion group belonging to a charitable organization just is not as "safe" as a stable business that has a phone number that can be called for support, and a sales force that can help turn a tool into a business.

This said, I hope that Maverick continues, in part because its development will provide useful ideas to the community, and in part because it acts as one basis on which to react to problems that "might" occur.

Assuring reliable service

Having prevented a recurrence of history, the next step was in setting up a worldwide service structure for the products.

In a centralized corporate approach, the way to do this would be to find venture capital and build an international sales and support force, while also assuring that product manuals and such were available in the myriad languages of the world. But doing so has both practical and strategic problems.

The first of these is that Martin Phillips does not want to be a businessman. What he wants to be is an engineering project leader, and to focus all his energies on producing the best product available.

The second of these is that while QM is an essential element, there are many third party components that go into delivering a complete system. The most obvious of these are various Tri-mode or single-mode 4GL and 3.5GL solutions. But there will also be niche components and specialized hardware, as well as the training needed to pull all of these together into a delivered "system."

The third is that large organizations need a lot of additional management at the top, have a strong tendency to accumulate "fat" at the top and middle, and have a strong tendency towards other wasteful expenditure. In short, if a plurality of local organizations can take care of the community needs for a given product, these will do so more efficiently than one massive top-down organization.

Thus, plurality serves many processes.

But, conversely, exclusivity is desirable because the local organizations will have to make significant investments in the development of their local communities.

In most parts of the world, the first of these will be massive translation efforts, making all the MultiValue-related documentation available in a local language. This is important because, while English may be the international language of programming, the bulk of the best system developers in any given language are likely to not-be foreign-language facile.

But beyond the problem of foreign-language support, there are all the daily activities of supporting an infrastructure. These include minimally, support of the product, including finding and training of competent individuals to do support. It also includes "waving the flag" by doing advertising and promotion to make sure that people are aware the product exists. Finally, it includes selling the product and helping the buyers to market their composite products effectively. Most importantly, it includes "mentoring" customers. The typical customer is an independent person or small group that wants to make a living by providing a specific software solution. While they may be a highly competent programmer and analyst, a successful business includes many properties beyond the created product itself. Minimally, these include marketing, sales, and support. In larger organizations, other issues will be added. The local distributor must therefore nurture his customers through mastering these related disciplines ... if the developer customer wants the advice.

The problem is on the one hand to assure that the local entity can do all these jobs profitably, through exclusivity, and on the other to assure that the local organism does not abuse the developer customers. Historically, this has been a major problem within the MultiValue community. For instance, some International distributors were known to charge 3 times the USA price for there products, and many charged dramatically more.

Lets talk about some of the basic principals of distribution relationships inherent in this system:

1.	All distributors will have a country or language group that they are responsible for selling to. In almost all cases, there will be only one distributor for the region in question. Other distributors are prohibited from setting up sales offices in territories of other distributors.
2.	Distributors will receive generous margins through discounts from the published prices. Thus, there should not be a need for them to charge more than the world price for the product.
3.	Where a distributor must do translation to make this knowledge available to the local community, the translation Copyright will belong to the distributor, but the distributor must also make the translation available under the GPL, in order to further local knowledge. This is not as burdensome as one might think. The purpose of translation is not to sell books. Rather it is to deliver product and service. Those who might compete are precluded from delivering the GPL'd work with non-GPL'd product (i.e. commercial product), thus cannot steal the work for commercial advantage, and as such are at a disadvantage.
4.	Customers are permitted to buy from any distributor. This assures the local distributor will provide "honest value." The distributor has their own local monopoly, so they should derive the maximum legitimate benefit from their invested energies, but ready availability elsewhere permits local users to go elsewhere if they are dissatisfied with the local value offered, but can live with the lesser quality of practical service that will be available from those others.
5.	Distributors are encouraged to totally separate the prices for products and for services. For instance, a distributor in Lithuania of Azerbaijan is likely to have very different costs of labor than does someone in the USA or the U. K. Similarly, service is a function of what the developer or user needs, and does not abuse. For instance, service provided to end-users almost always needs to be "complete service." If someone offers "authorized service for the database only" the average small-systems end-user will treat something he knows in advance to be a "broken disk drive" as a service problem for the database vendor to solve, rather than properly going to a hardware technician who would charge him for the support. Conversely, service for developers is likely to vary widely based upon not only their core competence, but the number of systems under support.
6.	Distributors are the only "authorized" service organizations in their area. By this, we mean that they are the only people authorized to pick up the phone and call the various software engineers involved to work for a rapid solution.
7.	Distributors should, where possible, distribute the entire line of MultiValue related products, rather than limiting themselves to the core high-profit product. This creates single-sourcing convenience for the developer or user, and generally assures that the full technological spectrum will be available everywhere.

Practically, in most nations of the world, the local distributor can be a very small and lean organization, consisting of 1 or 2 highly competent people. The reason for this is very simple. The history of the MultiValue community demonstrates that when simple systems are built using this toolset, general support costs tend to be very low. For instance, analysis of Pick Systems known in-house and distributor-based support network in 1987 suggests that only one backup support person per 25,000 new "users" purchased, or 60,000 active users is needed. By "backup" we are not talking about someone directly supporting the end user, but of someone supporting software developers, and answering the questions that an individual developer has not mastered the answers to. Similarly, this number only includes database support, and not O/S or hardware backup support, but it is still a very low number.

Advertisement: If you think you have the "right stuff" to be one of these national distributors, please contact both us at EasyCo, and Ladybridge Systems. EasyCo holds world distribution "in trust" from Ladybridge, but only for the purposes of assuring that anyone who needs product and support can have it. We will happily divest ourselves of this responsibility for all countries other than the United States, including the responsibility for service of any pre-existing developers in the region, to anyone who is willing to provide better availability and service than we can.

Controlling service costs; keeping things simple

We have already talked above about a methods of minimizing overhead costs related to product distribution. Now, we want to talk about how you can help to control the total costs of service.

Obviously, if you participate in a range of self-help projects, such as contribution to a wiki, news group, or email distribution list, you will save a lot of "paid support."

But there is something more fundamental than this: "don't get in over your head." At any given time in your life, you will be competent to do some things, and incompetent to do others. Stick to what you are good at, and stick with customers for whom you can provide the greatest value. The slow upward spiral of MultiValue costs was largely a chain-reaction. Prices rose. Therefore, people "had to" do more complex things in order to survive. Doing more complex things necessitated more support on the one hand, and on the other encouraged customers to be more willing to ask for it, rather than solving the problems themselves. If you are a dealer, you will see that our system is conversely designed to award competence, as expressed as volume.

The true beauty of the MultiValue approach is that it is intentionally simple. The languages are designed to adapt to your manner of expression. Similarly data is directly inspectable, and can be conveniently organized for easy access rather than being in many places. The goal of "saving time" and reducing complexity informs every provider activity be that 4GLs, any other tool, or even the training regimens.

Please don't think of this as art for art's sake. If you are competent in Windows, and incompetent elsewhere, stick with windows. If you can engineer a basic solution, and this satisfies your customer's needs, stick with that solution. Don't add useless bells and whistles. These only increase the time your customer must spend learning things, as well as the time you must provide, and the support you need from others.

Encouraging new methods and techniques

This renascence of the MultiValue approach principally comes from two core elements. The first is the availability of a low cost database engine. The second, and more important, is the emergence of low-cost Tri-Mode 4GL products, that allow a further 5x to 10x practical increase in productivity, but with adaptation of the presentation layer to the modes desired by users, or applicable to specific needs.

This change is just one step on an evolutionary path. and many more will follow. While some pieces will be added to the general engine, and others will be simple and small enough to evolve as supportable GPL or free components, the vast majority of these are likely to involve the invention of many "for fee" products and services. This will happen either because they require a great deal of energy to build and support, or because they are niche products used only by a few. Please respect the rights of these creators to be, and encourage them. Avoid theft, and understand that just as you need to do well in life, so do they. The GPL approach which is an integral part of this initiative is not about "free beer" but rather about the use of liberation to create.

Long term driving down of prices

This company, and Ladybridge, are committed to further driving down the total costs of database driven solutions. You will see that the first steps of this: a lower basic price, free training and development aids, tiered prices for volume use of single user systems, and free- or reduced-price use for charitable organizations, are already in place. But we think that more can be done over time to make the use of simple database environments ubiquitous by driving down all, or selective portions of the pricing matrix, further. Achieving that goal depends upon you in two major ways. The greater your independence, the lower your support costs will be. The more units consumed, the wider is the consumption base over which fundamental costs can be spread.

Please don't use this approach to simply make a high-priced product less expensive to build, and thus line your pocket. Such an approach long term is likely to cost you business in ways that you cannot imagine. Rather, use it as a tool that lets you penetrate new markets, and create new products.

Finally, tell your friends. The more people who use this product family, the better it will become. Similarly, when you tell your friends, you do them a service as well. Building a good life for one's self is fundamentally dependent upon how efficient or effective one can be. At the time of this writing, many parts of the software industry is at very high unemployment: >10% due to outsourcing and other factors. As a result, for instance, Newbies, just out of college are only able to earn $15 to $25 an hour as independent contractors. Showing them how they can do a lot more in the same amount of time gives them the ability to ask for, and get, more for each of the hours they spend working for others.