Hi David

I doubt that it makes sense at all to think about a livespan of a software for longer than say 10-15 years. It doesn't matter if open source or comercial. 30 years are just too long - 30 years back was the time of Comodore64, remember?

It may be much more important to have a correct data-structure and data model, that allows you to shift to another software when needed.

Tom

Hi David

I doubt that it makes sense at all to think about a livespan of a software for longer than say 10-15 years. It doesn't matter if open source or comercial. 30 years are just too long - 30 years back was the time of Comodore64, remember?

It may be much more important to have a correct data-structure and data model, that allows you to shift to another software when needed.

Tom

Yes.

Open Source is OPEN. It can be maintained by any person (qualified). Of course, the main role will be transfered to Administrators/Programmers. Like usually, in any human activity, we should rely on persons, not robot or other machines.

You can indeed. In fact, a lot of companies are actually doing it. If you map open-source developers to the organizations they belong to, you will find that most if not all of them have interests in participating within the open-source effort since their own company benefits from their progress.

There is some work about this by Mik Kersten or Roberto Galoppini that you could take a look at... enjoy!!

The simple answer is:

If you use proprietary software, it can die any moment without warning. The company may disappear with the source code, or it may simply decide to let the sofware die, or it can be bought by a competitor who has an interest in killing that software. There are numerous examples of such occurrences (FoxPro comes to mind).

If you use open source software, at least you can get hold of the source to maintain it for your own purpose at your own expense if no one else is interested, which does not mean you have to do the maintenance: you can buy it. So if the software is critical for you, use open-source.

And software can live much longer than 15 years. That is one reason there are still cobol programmers, or were not very long ago (I did not check recently).

Many other reasons can be discussed, and have been at length, and can be found on the net. But this one is simple and undisputable.

And if there is a large community of interested user, they can pool their resources to pay for the software maintenance. It may not be cheaper than licencing proprietary software, but you are in control.

The more abstract view is that proprietary software is a supply driven economy, hence controled by the suppliers (for their own interest), in an economic context that tend to create monopolies because of the economic characteristics of software. But open source software is a demand driven economy, thus controled by the users, which is precisely the problem you worry about.

I've had open source software running on web servers and as installed applications for about a decade now that rely on Linux and Perl. These have been very stable, and continue to run both on older systems and new systems. I think that's largely due to the fact that Perl and Linux have both worked fairly hard at backwards compatibility, and remain fairly active projects. I think if you choose a platform or programming language that isn't as established and fades over time, well then you have problems with long term operation.

So, if the goal is to run for decades, you need to choose an operating system and programming language that are likely to endure for that length of time. That usually means bypassing fashionable spinoffs or new languages or platforms that may not last too long. I won't mention any names here, but you can probably think of examples from 10 years ago that just aren't that viable any more, and you can probably make predictions now about new languages that might not endure. Also, the degree to which the language or platform stresses backwards compatibility is a huge issue - I've had very bad luck in this regard with Java, for example, where applications written in Java a few years ago just don't run without modifications after some period of time. I have not had similar issues with Perl, although I am sure that can occur (especially if you use experimental features, etc.). This has also been a big problem for me with Hadoop, but this is still a relatively young project so hopefully it will settle down...?

So, in the end I think I'm saying that if your goal is long term operation (and of course this is a great goal) then you need to look to very stable platforms and languages that have some history behind them, and also a user community that is likely to be supporting them in the future. You also need to look at the degree of commitment to backwards compatibility, which is often a problem. Running ANSI C on Linux, for example, seems likely to be fine for years to come. I've made a bet on Perl and Linux in this regard, and so far that's paid off.

Thanks esteemed colleagues. You have reinforced my belief in the open movement and its relevance in mega system architectures. I hope we will have success convincing the decision makers especially if some are interested in any 'kickbacks' which unfortunately may be a tad too little compared to the alternative closed sourced proposals.

I rely on open source as well for my own software developments. Unfortunately, it depends on a rather large number of packages (Java, C, Prolog, ...) which makes it vulnarable to changes. Before, we had relied on commercial software and indeed it became unavailable after a merger. So my advice would be to control the number of software packages that you rely upon.

Thanks Manfred. I now have a strong case to proceed open sourced.

Open source projects which are community driven rely on the experience and reputation of the developers. But, open source projects which are sponsored by organizations are more likely to sustain.

I have worked with both proprietary and open source library software (Library Management System - the database used to manage the catalogue, circulation, acquisitions and all other processes in a library). By far the most positive experience has been with the Koha OSS LMS - a piece of software developed and constantly improved on behalf of libraries, efficient, versatile, effective both for staff and readers. I even had functionality that my library needed at the time, added at very reasonable cost.

Proprietary systems, on the other hand, tend to be badly out of date, a nightmare to use, and inefficient to a degree where a significant amount of staff time across the organisation is wasted. The big vendors have all been bought by private equity consortia, so are very focused on revenue. It seems once they have won a tender and can safely assume a library won't consider switching systems for years to come, they only invest the bare minimum in the upkeep of their software.

I think I know your case. I my country I have a GIS project that relay in a 20 years technology an it is still working. The reason is we cannot afford the cost of moving all the programs already made to new systems. Fortunately we not only made programs but also we worked on concepts and models, for that reason if funds will appear in a future we can move everything just using our schemes and models. (concepts are more persistent than technology, either standards)

And your question about FOSS impact for a system for now and beyond the main advantage of most FOSS software is they are based on open and well studied standards. in one side good practices related to those standards will help you to maitain certain degree of consistency and structure, in other side using standards garantee to you move data and messages from system to sytem easily. If your system became old with the time it probably can be refreshed with new standarized and open extensions and in a critical case you will probably find the way to make a complete change.