The following are only a few lines of excerpts from an extremely important argument about the “culture of design” surrounding software. It is a critical aspect of any effort to design “software that works the way society works,” to cite the credo of the decentralized software architecture crowd.
It may have an important impact on how CommerceNet Labs refines its own mission, too…
In many human endeavors, we create infrastructure to support our lives which we then rely upon for a long period of time…
By contrast, software has historically been built assuming that it will be replaced in the near future (remember the Y2K problem). Most developers observe the constant upgrading and replacement of software written before them and follow in those footsteps with their creations…
In accounting, common depreciation terms for software are 3 to 5 years; 10 at most. Contrast this to residential rental property which is depreciated over 27.5 years and water mains and brick walls which are depreciated over 60 years or more… I can go to city hall and find out the details of ownership relating to my house going back to when it was built in the late 1800’s.
[Dan Bricklin] will call this software that forms a basis on which society and individuals build and run their lives “Societal Infrastructure Software”. This is the software that keeps our societal records, controls and monitors our physical infrastructure (from traffic lights to generating plants), and directly provides necessary non-physical aspects of society such as connectivity.
What is needed is some hybrid combination of custom and prepackaged development that better meets the requirements of societal infrastructure software.
How should such development look? What is the “ecosystem” of entities that are needed to support it? Here are some thoughts:
* Funding for initial development should come from the users…
* The projects need to be viewed as for more than one customer… Funding or cost-sharing “cooperatives” need to exist.
* The requirements for the project must be set by the users, not the developers. The long-term aspects of the life of the results must be very explicit…
* … Impediments such as intellectual property restrictions and “digital rights management” chokepoints must be avoided…
* The actual development may be done by business entities which are built around implementing such projects, and not around long-term upgrade revenue…
* The attributes of open source software need to be exploited. This includes the transparency of the source code and the availability for modification and customization… The availability of the source code, as well as the multi-customer targeting and other aspects, enables a market for the various services needed for support, maintenance, and training as well as connected and adjunct products.
* The development may be done in-house if that is appropriate, but in many cases there are legal advantages as well as structural for using independent entities..
* Unlike much of the discussion about open source, serendipitous volunteer labor must not be a major required element. A very purposeful ecosystem of workers, doing their normal scheduled work, needs to be established to ensure quality, compatibility, modifications, testing, security, etc… The health of the applications being performed by the software must not be dependent upon the hope that someone will be interested in it; like garbage collecting, sewer cleaning, and probate court judging, people must be paid.
The ecosystem of software development this envisions is different than that most common today. The details must be worked out. Certain entities that do not now exist need to be bootstrapped and perhaps subsidized. There must be a complete ecosystem, and as many aspects of a market economy as possible must be present.