Hello,
please excuse the long message - and read it though, should be interesting for you. Or at least start reading... I will first describe the technical idea (after all, you're all developers, aren't you? ;-) ) and then discuss the neccessary efforts by and the probable advantages for SuSE.
I just had a discussion of the following proposal with the deputy head of your German support centre. She asked me to write it down and let you know by this way, too. It would be very nice if I got some real feedback about this idea (yes, this seems really difficult with such non-personal addresses like this feedback form...).
Hint for the German speaking among you: I have published this proposal in German usenet yesterday which has resulted in a quite interesting discussion. I have posted the article in several de.comp.os.unix.* groups with a follow-up to de.comp.os.unix.discussion. The message ID of the article is <ajtm9v$r71$1@news.online.de>
I would like to suggest that SuSE helps to initiate a new open source project (because I do not have the neccessary technical capabilities) which should offer two advantages for SuSE: First, a serious decrease in support costs (hmm, are you the ones to be expected to support such an idea ;-)) ), second, a little image improvement (like the "What does this .rpm mean...?"-effect).
I suggest to develop a tool which mainly offers two application interfaces (one "down" and one "up") and one or two (console and X) user interfaces (to propably be replaced by e.g. versions for KDE, Gnome and so on). The down interface should allow to easily write some (very small) piece of software (probably a shell script but C or whatever should also be possible) which is capable of detecting (and maybe solving, if asked to) a certain (not too complex) problem. The meaning of "problem" is very broad here. I think of both distributor-specific problems (like bugs in the boot scripts or the configuration tools) and configuration and runtime problems with all kinds of software (i.e. distribution independent).
This tool should define a certain header (for shell scripts or an info file for compiled programs) which describes the kind of problem this script cares about. This might contain the following information: distribution and version (if specific to that); category of the problem (like those in your support database), e.g. booting, networking, printing, whatever; affected program (if applicable); supported languages ; and so on.
The tool I suggest would ask the user what kind of problem he has (again, similar to the support database). After he has entered the neccassary information the tool would check all locally installed scripts for applicability and if possible try to download the newer scripts from the distributor (or wherever) which fit the problem description. Next, the tool would start all the found scripts, one after another. The scripts would tell the calling tool if they have found a problem. Certainly, most will not. If some scripts find something their output would be shown to the user. Let's sum up what has happened until now: We have, probably within a couple of seconds the same result which a time consuming search in several support databases, Google and maybe an additional request in usenet would have brought.
The tool would also offer the user to have the script fix the problem if the script offers the capability to do so. Now (if not already) the next main task of the tool comes up: Security. Remember, I want everyone to contribute to the pool of scripts which the tool uses. Wouldn't be too clever to believe in a script promising to solve all your problems with some minor changes to some files you never heard of (shadow, inetd.conf, SuSEfirewall2...). Thus the tool would incorporate several stages of security. This would include things like chroot, sudo, systrace and so on on the one hand and digital signatures on the other. This is a good example to explain the need for this organizing and supervising tool: Somebody like me would be willing and capable to write such scripts but does not know enough about security issues to get things right.
The next part: neccessary efforts by and probable advantages for SuSE
The point: SuSE saves costs if a customer who has a problem can and does solve this problem alone if he otherwise would have contacted some support person (of course, without having to pay for this like for the free basic/installation support) or if he needs less time of personal looking after though paying the same price for the support.
Thus the question is: Would an active support for the tool I suggest by SuSE reduce the number of phone calls and e-mails to the free support or ease the payed support in the long run? Additionally we might ask: Are there side effects?
For obvious reasons it is quite difficult for me to assess the financial consequences for your support team. Important aspects are though that neither the tool itself nor the scripts (not even the ones specific to the SuSE distribution) would have to be developed by SuSE alone. Don't we all like OSS for this effect that somebody starts off a project and other ones help finishing it? I have no clue how much manpower would be neccessary to get things going, you might, though. Of course, the more is done by you, the earlier usable results would be there. And as your finance people will tell you earlier cost savings and revenue increases are worth more than later ones. Getting difficult ;-)
Given a working technical solution, let's say a tool and script pool which cover 60% of the non-individual problems that you are confronted with. Will the users, now enabled to solve their problems alone, really do without calling or e-mailing the support staff at SuSE? Who knows? We should take into account that the most important influence for the user's decision which support channels to use is comfort, probably succeeded by social effects (like to talk/write so somebody rather than reading anything). I doubt myself that the first call/e-mail can be prevented but getting an answer like "Have you already tried 'unix-fix'(TM) ;-) , no, OK, please click the (whatever) icon. See, it's just given you the answer you wanted to get." would probably teach the people. That would be kind of politely embarrassing. Not finding a solution in the SDB or not being able to use the solution description is not embarrasing. Not even clicking the icon is, though.
The non-free support services might profit from such tool by you developing more complex scripts for more complex problems which you do not give to the public but only to those who pay you. You might extend YaST to be able to download, execute and remove ;) such scripts which a contacted supporter offers to the customer. This might - I have no idea if "typical" problems exist in your support service and if so what they look like - save time in some cases without those scripts getting out to the public (too soon).
Last point, side effects.
I have a sincere hope that such a tool would start a revolution in Unix support of day-by-day problems. This would result in, first, a certain image for SuSE by being the one who started this off, this adding a new quality to Linux in contrast to just new features, and second, this would make Linux/Unix as a whole more attractive. This might be one of the main challanges for a distributor, getting the technical requirements for administrating a typical Linux machine to a much lower level, thereby vastly broadening the market for your products. Everyone who has never tried Linux, knows that it's terrible to use and even more terrible to fix 8-) Changing at least the latter might increase Linux' market share and revenues - not only but also for SuSE.
And after all, don't we all want to create some real progress from time to time...?
BTW, for those who are still there... I am a student of computer science an management at the TU Berlin (and also work there as an administrator). You can reach me at hauke@laging.de I would appreciate any feedback.