Software ist häufig "Verbrauchsmaterial". Die meisten PC-Anwender rechnen nicht wirklich damit, in fünf Jahren noch mit den selben Programmen zu arbeiten. Schließlich kommen ja spätestens alle 2 Jahre neue, "bessere" Versionen auf den Markt. Und wer weiß, ob die übernächste Version überhaupt noch meine alten Daten lesen kann? Für viele Anwendungen mag das OK sein. Software ist für viele Firmen, Institutionen, Organisationen aber inzwischen "businesskritisch". Und einige dieser "Geschäfte", Anliegen und Projekte ziehen sich über Jahrzehnte hin. Da kann es eine Katastrophe sein, wenn die vor Jahren einmal entwickelte Software auf neuer Hardware nicht mehr läuft, keiner notwendige Änderungen vornehmen kann o.ä.
Für normale Anwender hört sich das alles wenig dramatisch an. Aber in dem Maße, in dem unsere Wirtschaft und die ganze Gesellschaft mehr und mehr von einwandfreien Funktionieren bestimmtes Software abhängig wird, ist das eine wirklich relevante Fragestellung. Ein paar hochspannende Gedanken dazu sind in neuesten Essay von Dan Bricklin zu finden: Software That Lasts 200 Years.
The world is different now than it was even just a decade or two ago. In more and more cases, there are no paper records. People expect all information to be available at all times and for new uses, just as they expect to drive the latest vehicle over an old bridge, or fill a new high-tech water bottle from an old well's pump. Applications need to have access to all of the records, not just summaries or the most recent. Computers are involved in, or even control, all aspects of the running society, business, and much of our lives.Ich denke, die Beschreibung der Ausgangssituation ist sehr zutreffend. Und viele Verantwortliche in Organisationen, die längst von irgendeiner Software abhängig sind, machen sich darüber viel zu wenig Gedanken. Ich bin mir nicht sicher, ob Bricklin mit all den Schlüssen, die er daraus zieht, recht hat. Erstklasssiges Gedankenfutter für jeden in der Branche, der über den Tag hinausdenken will/muss, ist es allemal.We need to start thinking about software in a way more like how we think about building bridges, dams, and sewers. What we build must last for generations without total rebuilding. This requires new thinking and new ways of organizing development. This is especially important for governments of all sizes as well as for established, ongoing businesses and institutions.
Interessant ist, dass Bricklin zu dem Schluss kommt, dass das beliebte Allheilmittel "nimm doch einfach Open Source" in diesem Zusammenhang nicht ausreicht ... wenn auch einen wichtigen Baustein darstellen könnte.
Ein paar Details mehr ...
The needs of Societal Infrastructure Software
Let us look at the needs for societal infrastructure software. They include the following:
- Meet the functional requirements of the task.
- Robustness and long-term stability and security.
- Transparency to determine when changes are needed and that undesired functions are not being performed.
- Verifiable trustworthiness of all three of the above.
- Ease and low cost of training for effective use.
- Ease and low cost of maintenance.
- Minimization of maintenance.
- Ease and low cost of modification.
- Ease of replacement.
- Compatibility and ease of integration with other applications.
- Long-term availability of individuals able to train, maintain, modify, determine need for changes, etc.
The structure and culture of a typical prepackaged software company is not attuned to the needs of societal infrastructure software. The "ongoing business entity" and "new version" mentality downplay the value of the needs of societal infrastructure software and are sometimes at odds.
...
A new style of development
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. Bridges and water systems are usually funded by governments, not by private entities that will run them for generations. The long-term needs of the funders must be more inline with the project requirements than the investment return needs of most private sources of capital.
- The projects need to be viewed as for more than one customer. A system for tracking parking tickets is needed by many municipalities. There is little need to have a different one for each. As a result, the funding should also be able to come from a combination of multiple sources. 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. Best-practices must be established, tracked, and revisited.
- There is the whole issue of data storage and interchange standards that is critical to the long-term success and ability to do migration. Impediments such as intellectual property restrictions and "digital rights management" chokepoints must be avoided. ....
- Another critical issue is platform (hardware and software) independence. All development of long-term software needs to be created with the possibility of new hardware, operating systems, and other "computer infrastructure" in mind.
- The actual development may be done by business entities which are built around implementing such projects, and not around long-term upgrade revenue. Other entities are needed for providing the ongoing services with a mentality of keeping existing systems running. (The two entities may or may not be related.) Many such companies already exist.
- 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. Much has been written with regards to open source and its value for bug finding, security checking, etc., which is why this is needed. The added benefit here is that society as a whole may benefit in unforeseen ways as new applications are found for programs, be they in the private or public sector. 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. Some governmental agencies may be precluded from licensing their results under licenses that are most appropriate for the long-term health of the projects. For example, they may be required to release the program code into the public domain where it may then be improved by others (and re-released under restrictive licenses) without a return benefit to the original funders.
- 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. Educational and other institutions may be employed with the appearance of volunteer labor as students and other interested parties are used, much as courts and other governmental agencies have used interns and volunteers for other activities. 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. ...
Recent Comments