Software products neither grow old, nor fade away. They keep changing and improving (?) overtime. Generally, the design ideas, the patterns and the functions embodied in them are retained and reused frequently over long lengths of time. In this presentation, we explore some avenues of creating software systems, which can retain both the original functional and intellectual components with the objective of sustaining their use for a very long time. This implies they should be easily maintainable (e.g., by remote updating and maintenance through the Internet) or modifiable by users themselves. It is well known that maintenance accounts for largest fraction of the life-cycle cost in any software system. Of late, open systems environments and their development techniques have become very popular, particularly with the advent of the Linux operating system. Open systems ideas have been adopted by major software developers like Sun, and IBM, and by mobile communication product manufacturers. The most critical concern and issue with the open system products has been their maintenance. This is because the components of the software are developed and modified by several different designers who do not follow proper documentation and collaborative procedures and standards. The resulting system may be highly unstructured requiring further invasive modifications and thus creating more spirals of unstructuredness in their wake. There is no quality guaranty, and no one accepts responsibility for flaws. It is important that the open source/system software components must embody not only crucial application ideas and functions but also should support useroriented values such as ease of use; crash free operation and ease of maintenance (by the user, if possible) within the specified (wellunderstood) constraints. We consider a software malfunction as an instance of a disaster, however small or harmless it may be. Based on our previous studies on disaster engineering systems, we apply the ideas developed in preventing and mitigating disasters to design and develop all software systems, and more specifically for those intended for the open systems environment, because such systems are been unfortunately error-prone and unreliable. We show the commonality and transferability of several methods and approaches that can be carried over effectively between disaster engineering and software engineering.