First of all, I would like to thank Jose-Maria for proposing this alternative plan, and to invite anybody who has a new idea to do the same. However, and I hope you will not take this as a negative comment, private notes telling me that "This plan is likely to decrease the level of service provided to the users" and "There is probably a better solution" are not of much help. I am perfectly aware of the fact that my proposed plan is not ideal and that, from a purely technical point of view, it is obviously undesirable. There are a lot of other things, which are undesirable from a purely technical point of view, and which are still going to get done; good examples are IBM's OCO policy, the new "improved" VMFBETTER tools, the use of X.400 which doesn't remove trailing blanks from a message (least of all compress runs of identical characters), etc. If you think there is a better solution, please propose one and let's discuss it - just stating your belief will not help us make progress. Let's get back to Jose-Maria's alternate plan (let's call it plan #2). First, as it was written it is not acceptable to me, as it would mean that I would be accepting money from EARN in exchange for (some form of) LISTSERV maintenance, which is something that I have never accepted and do not plan to accept in the future. However, let's study plan 2 from the technical point of view - maybe it can be further improved to meet my goals. I know of only two persons who can claim to be "LISTSERV specialists" (ie people able to answer questions without having to look at the code) in this network: Jose-Maria and myself. Jose-Maria has about 75% of my LISTSERV-related knowledge, and if I had had to leave the network, I would have liked to hand LISTSERV over to him. Unfortunately, none of these two persons are willing to work for EARN, so let's move one step downwards. I can think of 3 EARN guys who have enough knowledge of LISTSERV to answer some questions without looking at the code, and to know where to look to answer the others. Although I can't speak for them, I know that they have both a full-time job, so that they could only work part-time for EARN (assuming they were interested of course). That might be enough to answer questions, but they would need more time to do the actual maintenance and/or development in case I stopped doing it, so that they could not be considered as a serious "backup" solution; in other words, EARN would not be guaranteeing the continuity of the maintenance (at least not that of a serious maintenance), and the goal wouldn't be met (unless several such persons worked on the code, but synchronizing 2-3 people working 25% of their time on something is not going to be very easy). If you move one step downwards again, you have a large number of people who are competent and experienced enough to do this job, but not at 25%. During the first N months (N=6?), these people would need to look at the code to answer most questions, and quite often they wouldn't know where to start looking at. That basically means they would forward the questions to me and I would have to answer them, which won't reduce the load in my mailbox (again, for the first N months). Since they would not be writing any code (unless I misunderstood what Jose-Maria said), their job would be quite boring: getting experience on someone else's software to answer user questions, or, in other words, playing Help Desk. Besides, I doubt they could really be relied on in case of problems: someone whose knowledge is purely theorical usually has a lot of problems when he is faced with a real life situation (try learning a truck driver's manual by heart and then experimenting on the "real hardware" :-) ). If you want a dependable "backup LISTSERV maintenance staff", you need people who not only read the sources and answer questions, but also do some programming (related to the thing they are learning, of course). This should not be school-like "exercises" which are going to be checked by a teacher and subsequently forwarded to the wastebasket, but real, useful software that people are going to use and to provide feedback about. That is the only way to learn, at least that's my personal experience of learning. To refine this plan, we have to take that into account, along with the fact that I would not accept that an EARN employee did part of the maintenance and development of the code I am working on, while I did the other part (I think the reasons should be pretty clear to anyone who has ever tried to work in an uncoordinated team with someone he didn't choose to work with and who, apart from having a different opinions on almost anything that needs to be done, is paid by an entity whose goals are different from yours). That would probably create more conflicts than there are today, and would catastrophically degrade the quality of the software. Any comment? Eric